From issues at kolab.org  Tue Nov  3 16:33:16 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 03 Nov 2009 15:33:16 +0000
Subject: [Kolab-devel] [issue3933] A large wholeday event is not shown at
	all days in	dayview.(rt#5884)
In-Reply-To: <1257262396.83.0.949020471713.issue3933@kolab.org>
Message-ID: <1257262396.83.0.949020471713.issue3933@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

observed with Kontact e35 20091030.1042738-kk1

Test:
1. Create a whole day event which spans over 6 month.
2. Look in dayview at one day of the last month of the event.
=> The event is not shown.

The estimation is kkc.
Ask for ok, before further work as kkc.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22155
nosy: allen, ludwig
priority: bug
status: unread
title: A large wholeday event is not shown at all days in dayview.(rt#5884)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3933>
______________________________________


From bernhard at intevation.de  Wed Nov  4 10:24:18 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 4 Nov 2009 10:24:18 +0100
Subject: [Kolab-devel] On SF (was:  z-push Kolab backend)
In-Reply-To: <20091029114227.261434vnec1ixy8k@webmail.pardus.de>
References: <200910222123.55612.phil@shellweb.homeip.net>
	<4AE6EBA5.5000804@libertech.fr>
	<20091029114227.261434vnec1ixy8k@webmail.pardus.de>
Message-ID: <200911041024.18380.bernhard@intevation.de>

Am Donnerstag, 29. Oktober 2009 11:42:27 schrieb Gunnar Wrobel:
> considering the possible alternatives I guess placing the code on ?
> sourceforge for now is the best alternative.
>
> So I started a new project at https://sourceforge.net/projects/

The FSFE still recommends to not use sourceforge for being too proprietary,
I still agree with this assessment.
http://fsfe.org/news/article2001-10-20-01.en.html
Beside that I almost find it unusable for the problems of javascript, 
advertisment and speed. 
So putting anything on SF is not something I recommend.

At intevation we do have wald.intevation.org which is running an old version
of FusionForge, which we will upgrade in the near future. This is a 
possibility and already has Kolab related products registered, but there are 
others, if you do not like or us running it. ;-P 

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/20091104/beb6a77d/attachment.bin

From bernhard at intevation.de  Wed Nov  4 10:26:12 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 4 Nov 2009 10:26:12 +0100
Subject: [Kolab-devel] z-push Kolab backend
In-Reply-To: <4AEB7207.6090801@libertech.fr>
References: <200910222123.55612.phil@shellweb.homeip.net>
	<20091030205336.18196w5ug9quca4o@webmail.pardus.de>
	<4AEB7207.6090801@libertech.fr>
Message-ID: <200911041026.12429.bernhard@intevation.de>

Alain, Gunnar,

Am Samstag, 31. Oktober 2009 00:08:55 schrieb Alain abbas:
> we have put the code on your production server this friday.

thanks for starting the initiative, z-push for Kolab is really something 
exciting!

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/20091104/cecd117b/attachment.bin

From bernhard at intevation.de  Wed Nov  4 10:27:27 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 4 Nov 2009 10:27:27 +0100
Subject: [Kolab-devel] kimap (imap library) Re: annotations patch in
	c-client what is the status?
In-Reply-To: <200910251357.22005.ml@radoeka.nl>
References: <b756c91fbfb72929d5f269992f6968ab.squirrel@webmail.xs4all.nl>
	<200910251357.22005.ml@radoeka.nl>
Message-ID: <200911041027.28148.bernhard@intevation.de>

Richard,

Am Sonntag, 25. Oktober 2009 13:57:21 schrieb Richard Bos:
> > Still not a techbase page, sorry, but I just pushed a blog post about how
> > libkimap got created. That's hopefully a good place to start as I tried
> > to provide insights on its design:
> > http://ervin.ipsquad.net/2009/10/22/libkimap-the-genesis/
>
> I stored the information here:
> https://wiki.kolab.org/index.php/Server_component_UW_imap_c-client#C-
> client_replacement_with_libkimap
>
> An search on the wiki now results at least in something:
> https://wiki.kolab.org/index.php/Special:Search?search=libkimap&go=Go

thanks for doing so, this is really helpful!
(As is any help with the wiki by others - hint hint hint. :) )

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/20091104/2d1f78ad/attachment.bin

From issues at kolab.org  Wed Nov  4 12:26:59 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 04 Nov 2009 11:26:59 +0000
Subject: [Kolab-devel] [issue3934] Reply of mail with signature removes the
	signature	(rt#5887)
In-Reply-To: <1257334019.38.0.95268741671.issue3934@kolab.org>
Message-ID: <1257334019.38.0.95268741671.issue3934@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 20091030.1042738-kk1

Test:
1. A sends B a mail with mail signature.
2. B syncs, looks at the mail and presses reply.
=> The mail just have B's signature, but A's mail signature is lost.

In proko2 the signature was not cut, said the user.
I think a solution could be to make it configurable if the signature of A get
cut or not.

Please estimate. (estimation is kkc).
Wait for an ok before fixing this issue.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22158
nosy: allen, ludwig
priority: bug
status: unread
title: Reply of mail with signature removes the signature (rt#5887)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3934>
______________________________________


From thomas at btspuhler.com  Thu Nov  5 05:22:57 2009
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Wed, 4 Nov 2009 21:22:57 -0700
Subject: [Kolab-devel] Path in building package
In-Reply-To: <s7w3a5eja8x.fsf@intevation.de>
References: <s7w3a5eja8x.fsf@intevation.de>
Message-ID: <200911042122.57817.thomas@btspuhler.com>

I am working on packing Kolab on the Mindriva Distribution.but need to change 
some path to get /usr/share/kolab/scripts into the path. I believe I saw this 
a while ago but cannot find it anymore. Tried Google too.

-- 
Thomas


From wrobel at pardus.de  Thu Nov  5 10:01:22 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 05 Nov 2009 10:01:22 +0100
Subject: [Kolab-devel] kimap (imap library) Re: annotations patch
	in	c-client what is the status?
In-Reply-To: <200911041027.28148.bernhard@intevation.de>
References: <b756c91fbfb72929d5f269992f6968ab.squirrel@webmail.xs4all.nl>
	<200910251357.22005.ml@radoeka.nl>
	<200911041027.28148.bernhard@intevation.de>
Message-ID: <20091105100122.12505lyvl7gb0uck@webmail.pardus.de>

Quoting Bernhard Reiter <bernhard at intevation.de>:

> Richard,
>
> Am Sonntag, 25. Oktober 2009 13:57:21 schrieb Richard Bos:
>> > Still not a techbase page, sorry, but I just pushed a blog post about how
>> > libkimap got created. That's hopefully a good place to start as I tried
>> > to provide insights on its design:
>> > http://ervin.ipsquad.net/2009/10/22/libkimap-the-genesis/
>>
>> I stored the information here:
>> https://wiki.kolab.org/index.php/Server_component_UW_imap_c-client#C-
>> client_replacement_with_libkimap
>>
>> An search on the wiki now results at least in something:
>> https://wiki.kolab.org/index.php/Special:Search?search=libkimap&go=Go
>
> thanks for doing so, this is really helpful!
> (As is any help with the wiki by others - hint hint hint. :) )

I added my view of the story and post it here for reference and discussion:

===C-client obsolete in Horde 4===

Horde 4 has a completely new Imap_Client library. This library  
implements IMAP access via two different access methods: Either via  
the c-client functions within PHP or via a pure PHP implementation  
based on the PHP socket functions (these are low-level networking  
functions).

As astonishing as it may seem: The pure PHP implementation seems to be  
significantly faster than using the c-client library implemented in C.  
The test script associated with the Imap_Client library uses 50% more  
time when running based on c-client.

The Imap_Client library delegates all calls not supported by the  
c-client functions to the socket based implementation. Metadata  
support has been implemented in Imap_Client  
[http://git.horde.org/h/chora/diff.php/framework/Imap_Client/lib/Horde/Imap/Client/Socket.php?r1=27544c35aa67bdabb93fa22eb5c944109c5aece3&r2=ea1160aa4ed249ceff10dd268d46b8d9dd7dc3b8 recently]. The IMAP access within the Kolab server and the Kolab parts of Horde has also been ported to use Imap_Client. This refers to Kolab_Storage which is the IMAP handler for all elements in the Kolab server and Horde that require access to the Kolab IMAP  
server.

So in Horde4 the need for patching c-client becomes obsolete.

This does however '''not''' mean that libkimap is not interesting for  
the IMAP connectivity of the Kolab server. It could potentially be  
faster than the socket based implementation. Somebody would however  
need to package libkimap in a PECL package (or directly in PHP) and  
implement use of this backend in Imap_Client.

Cheers,

Gunnar

>
> 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 <<
--------------------------------------------------------------------

-------------- 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/20091105/65017190/attachment.bin

From wrobel at pardus.de  Thu Nov  5 10:14:39 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 05 Nov 2009 10:14:39 +0100
Subject: [Kolab-devel] On SF (was:  z-push Kolab backend)
In-Reply-To: <200911041024.18380.bernhard@intevation.de>
References: <200910222123.55612.phil@shellweb.homeip.net>
	<4AE6EBA5.5000804@libertech.fr>
	<20091029114227.261434vnec1ixy8k@webmail.pardus.de>
	<200911041024.18380.bernhard@intevation.de>
Message-ID: <20091105101439.747841rzros1wvc4@webmail.pardus.de>

Hi Bernhard,

Quoting Bernhard Reiter <bernhard at intevation.de>:

> Am Donnerstag, 29. Oktober 2009 11:42:27 schrieb Gunnar Wrobel:
>> considering the possible alternatives I guess placing the code on   
>> sourceforge for now is the best alternative.
>>
>> So I started a new project at https://sourceforge.net/projects/
>
> The FSFE still recommends to not use sourceforge for being too proprietary,
> I still agree with this assessment.
> http://fsfe.org/news/article2001-10-20-01.en.html
> Beside that I almost find it unusable for the problems of javascript,
> advertisment and speed.
> So putting anything on SF is not something I recommend.
>
> At intevation we do have wald.intevation.org which is running an old version
> of FusionForge, which we will upgrade in the near future. This is a
> possibility and already has Kolab related products registered, but there are
> others, if you do not like or us running it. ;-P

The idea behind putting this on SF for now was to get going quickly.  
As the developers involved all had accounts there I considered it -  
and still consider it - the easiest solution. In the long run I see  
the code as a package in the Horde framework. It might not even take  
much time until it gets there.

Cheers,

Gunnar

>
> 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 <<
--------------------------------------------------------------------

-------------- 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/20091105/50564ec5/attachment.bin

From thomas.jarosch at intra2net.com  Thu Nov  5 10:34:38 2009
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Thu, 5 Nov 2009 10:34:38 +0100
Subject: [Kolab-devel] kimap (imap library) Re: annotations patch
	in	c-client what is the status?
In-Reply-To: <20091105100122.12505lyvl7gb0uck@webmail.pardus.de>
References: <b756c91fbfb72929d5f269992f6968ab.squirrel@webmail.xs4all.nl>
	<200911041027.28148.bernhard@intevation.de>
	<20091105100122.12505lyvl7gb0uck@webmail.pardus.de>
Message-ID: <200911051034.38867.thomas.jarosch@intra2net.com>

On Thursday, 5. November 2009 10:01:22 Gunnar Wrobel wrote:
> ===C-client obsolete in Horde 4===
> 
> Horde 4 has a completely new Imap_Client library. This library
> implements IMAP access via two different access methods: Either via
> the c-client functions within PHP or via a pure PHP implementation
> based on the PHP socket functions (these are low-level networking
> functions).
> 
> As astonishing as it may seem: The pure PHP implementation seems to be
> significantly faster than using the c-client library implemented in C.
> The test script associated with the Imap_Client library uses 50% more
> time when running based on c-client.

Very nice! So our Kolab back end code with the ability to switch 
implementations inspired main line :)

> This does however '''not''' mean that libkimap is not interesting for
> the IMAP connectivity of the Kolab server. It could potentially be
> faster than the socket based implementation. Somebody would however
> need to package libkimap in a PECL package (or directly in PHP) and
> implement use of this backend in Imap_Client.

Here comes the troublesome part (sorry Bernhard for not replying earlier):
The library is written in C++ while PHP uses mostly C. We would need a lot 
of wrapper glue here. The new library also depends on Qt and some KDE 
libraries, this is quite a heavy dependency for a PHP module.

Maybe all the added wrapper glue kills the speed advantage, if any?
Just think of the needed string conversions QString <-> PHP string type
which are needed every time you access a message header/body etc.

At least there is already a way to interface Qt/KDE libraries
with PHP as there a Qt bindings for PHP:
http://techbase.kde.org/Development/Languages/PHP-Qt

Cheers,
Thomas


From wrobel at pardus.de  Thu Nov  5 11:32:33 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 05 Nov 2009 11:32:33 +0100
Subject: [Kolab-devel] kimap (imap library) Re: annotations
	patch	in	c-client what is the status?
In-Reply-To: <200911051034.38867.thomas.jarosch@intra2net.com>
References: <b756c91fbfb72929d5f269992f6968ab.squirrel@webmail.xs4all.nl>
	<200911041027.28148.bernhard@intevation.de>
	<20091105100122.12505lyvl7gb0uck@webmail.pardus.de>
	<200911051034.38867.thomas.jarosch@intra2net.com>
Message-ID: <20091105113233.26983shy07jda0g0@webmail.pardus.de>

Hi Thomas,

Quoting Thomas Jarosch <thomas.jarosch at intra2net.com>:

> On Thursday, 5. November 2009 10:01:22 Gunnar Wrobel wrote:
>> ===C-client obsolete in Horde 4===
>>
>> Horde 4 has a completely new Imap_Client library. This library
>> implements IMAP access via two different access methods: Either via
>> the c-client functions within PHP or via a pure PHP implementation
>> based on the PHP socket functions (these are low-level networking
>> functions).
>>
>> As astonishing as it may seem: The pure PHP implementation seems to be
>> significantly faster than using the c-client library implemented in C.
>> The test script associated with the Imap_Client library uses 50% more
>> time when running based on c-client.
>
> Very nice! So our Kolab back end code with the ability to switch
> implementations inspired main line :)

Ah, well... I don't think so :) There were limitations within Imp that  
drove development for Imap_Client.

>
>> This does however '''not''' mean that libkimap is not interesting for
>> the IMAP connectivity of the Kolab server. It could potentially be
>> faster than the socket based implementation. Somebody would however
>> need to package libkimap in a PECL package (or directly in PHP) and
>> implement use of this backend in Imap_Client.
>
> Here comes the troublesome part (sorry Bernhard for not replying earlier):
> The library is written in C++ while PHP uses mostly C. We would need a lot
> of wrapper glue here. The new library also depends on Qt and some KDE
> libraries, this is quite a heavy dependency for a PHP module.

That is the disadvantage this new library has. As long as you are  
working within a context that uses Qt anyhow you are fine. But for all  
server environments you really want a light-weight library doing the  
IMAP access. I don't know if you can package libkimap with a  
lightweight Qt version. But if not I don't see it in the server but  
only the desktop environment.

Cheers,

Gunnar

>
> Maybe all the added wrapper glue kills the speed advantage, if any?
> Just think of the needed string conversions QString <-> PHP string type
> which are needed every time you access a message header/body etc.
>
> At least there is already a way to interface Qt/KDE libraries
> with PHP as there a Qt bindings for PHP:
> http://techbase.kde.org/Development/Languages/PHP-Qt
>
> Cheers,
> Thomas
>
> _______________________________________________
> 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 <<
--------------------------------------------------------------------

-------------- 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/20091105/ef164b7d/attachment-0001.bin

From ml at radoeka.nl  Thu Nov  5 11:57:39 2009
From: ml at radoeka.nl (Richard Bos)
Date: Thu, 5 Nov 2009 11:57:39 +0100
Subject: [Kolab-devel] kimap (imap library) Re: annotations
	patch	in	c-client what is the status?
In-Reply-To: <20091105113233.26983shy07jda0g0@webmail.pardus.de>
References: <b756c91fbfb72929d5f269992f6968ab.squirrel@webmail.xs4all.nl>
	<200911041027.28148.bernhard@intevation.de>
	<20091105100122.12505lyvl7gb0uck@webmail.pardus.de>
	<200911051034.38867.thomas.jarosch@intra2net.com>
	<20091105113233.26983shy07jda0g0@webmail.pardus.de>
Message-ID: <20091105105739.GA33048@xs4all.nl>

On Thu, Nov 05, 2009 at 11:32:33AM +0100, Gunnar Wrobel wrote:
> >Here comes the troublesome part (sorry Bernhard for not replying earlier):
> >The library is written in C++ while PHP uses mostly C. We would need a lot
> >of wrapper glue here. The new library also depends on Qt and some KDE
> >libraries, this is quite a heavy dependency for a PHP module.
> 
> That is the disadvantage this new library has. As long as you are  
> working within a context that uses Qt anyhow you are fine. But for all  
> server environments you really want a light-weight library doing the  
> IMAP access. I don't know if you can package libkimap with a  
> lightweight Qt version. But if not I don't see it in the server but  
> only the desktop environment.

What do you mean with light-weight?  In openSUSE the QT package is 1.2MB
and contains only the following libs:
/usr/bin/qdbus
/usr/lib/libQtCLucene.so.4.4.3
/usr/lib/libQtCore.so.4.4.3
/usr/lib/libQtDBus.so.4.4.3
/usr/lib/libQtNetwork.so.4.4.3
/usr/lib/libQtTest.so.4.4.3
/usr/lib/libQtXml.so.4.4.3
(these are the pure files, I left out the links).  Looks rather light-weight
to me, isn't it?

-- 
Richard


From issues at kolab.org  Thu Nov  5 12:05:26 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 05 Nov 2009 11:05:26 +0000
Subject: [Kolab-devel] [issue3935] Kontacts needs long to open after a
	restart.
In-Reply-To: <1257419126.32.0.665780503064.issue3935@kolab.org>
Message-ID: <1257419126.32.0.665780503064.issue3935@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Kontact windows e4 20091027-1

Test:
1. Start Kontact
2. Switch to calendar plugin.
3. Close Kontact.
4. Strat Kontact again
=> Kontact needs about 30 seconds to open. This is too long.

----------
assignedto: allen
keyword: enterprise4, kde client
messages: 22167
nosy: allen, ludwig
priority: urgent
status: unread
title: Kontacts needs long to open after a restart.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3935>
______________________________________


From issues at kolab.org  Thu Nov  5 12:12:06 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 05 Nov 2009 11:12:06 +0000
Subject: [Kolab-devel] [issue3936] If Kontact is started with calendar
	plugin, the subresources of the Kolab Server will not be displayed.
In-Reply-To: <1257419526.52.0.302354773748.issue3936@kolab.org>
Message-ID: <1257419526.52.0.302354773748.issue3936@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Kontact windows e4 20091027-1

Test:
1. Start Kontact.
2. Switch to calendar plugin.
3. Close Kontact.
4. Start kontact again.
=> Kontact starts in the calendar plugin, but the subresources of the Kolab
Server account are not displayed.

----------
assignedto: allen
keyword: enterprise4, kde client
messages: 22168
nosy: allen, ludwig
priority: urgent
status: unread
title: If Kontact is started with calendar plugin, the subresources of the Kolab Server will not be displayed.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3936>
______________________________________


From wrobel at pardus.de  Thu Nov  5 12:35:22 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 05 Nov 2009 12:35:22 +0100
Subject: [Kolab-devel] kimap (imap library) Re:
	annotations	patch	in	c-client what is the status?
In-Reply-To: <20091105105739.GA33048@xs4all.nl>
References: <b756c91fbfb72929d5f269992f6968ab.squirrel@webmail.xs4all.nl>
	<200911041027.28148.bernhard@intevation.de>
	<20091105100122.12505lyvl7gb0uck@webmail.pardus.de>
	<200911051034.38867.thomas.jarosch@intra2net.com>
	<20091105113233.26983shy07jda0g0@webmail.pardus.de>
	<20091105105739.GA33048@xs4all.nl>
Message-ID: <20091105123522.21061kf3swyeoolc@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> On Thu, Nov 05, 2009 at 11:32:33AM +0100, Gunnar Wrobel wrote:
>> >Here comes the troublesome part (sorry Bernhard for not replying earlier):
>> >The library is written in C++ while PHP uses mostly C. We would need a lot
>> >of wrapper glue here. The new library also depends on Qt and some KDE
>> >libraries, this is quite a heavy dependency for a PHP module.
>>
>> That is the disadvantage this new library has. As long as you are
>> working within a context that uses Qt anyhow you are fine. But for all
>> server environments you really want a light-weight library doing the
>> IMAP access. I don't know if you can package libkimap with a
>> lightweight Qt version. But if not I don't see it in the server but
>> only the desktop environment.
>
> What do you mean with light-weight?  In openSUSE the QT package is 1.2MB
> and contains only the following libs:
> /usr/bin/qdbus
> /usr/lib/libQtCLucene.so.4.4.3
> /usr/lib/libQtCore.so.4.4.3
> /usr/lib/libQtDBus.so.4.4.3
> /usr/lib/libQtNetwork.so.4.4.3
> /usr/lib/libQtTest.so.4.4.3
> /usr/lib/libQtXml.so.4.4.3
> (these are the pure files, I left out the links).  Looks rather light-weight
> to me, isn't it?

That would indeed be okay. I guess Qt-4 is a significant step ahead in  
comparison to Qt-3. c-client is 1.3MB :)

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 <<
--------------------------------------------------------------------

-------------- 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/20091105/2a959e1c/attachment.bin

From issues at kolab.org  Thu Nov  5 12:49:12 2009
From: issues at kolab.org (Thomas Arendsen Hein)
Date: Thu, 05 Nov 2009 11:49:12 +0000
Subject: [Kolab-devel] [issue3938] compiling procmail fails on Fedora 11 and
	Ubuntu karmic
In-Reply-To: <1257421752.55.0.107207226228.issue3938@kolab.org>
Message-ID: <1257421752.55.0.107207226228.issue3938@kolab.org>


New submission from Thomas Arendsen Hein <thomas at intevation.de>:

Kolab Server up to 2.2.2:
See http://www.kolab.org/pipermail/kolab-users/2009-July/010247.html

In file included from formail.c:25:
formisc.h:20: error: conflicting types for 'getline'
/usr/include/stdio.h:655: error: previous declaration of 'getline' was here

(I got a report for the same problem on Ubuntu karmic on IRC)

An updated procmail package from OpenPKG includes this workaround:

    %{l_shtool} subst \
        -e 's;getline;procmail_getline;g' \
        src/formisc.h src/formisc.c src/formail.c src/fields.c

I uploaded the new package to
http://ftp.intevation.de/users/thomas/procmail-3.22-20090727.src.rpm
and if I get positive feedback, I'll include it in server 2.2.3

----------
assignedto: thomas
keyword: patch, release, server
messages: 22174
nosy: martin, thomas, wilde, wrobel
priority: urgent
status: unread
title: compiling procmail fails on Fedora 11 and Ubuntu karmic

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3938>
______________________________________


From ml at radoeka.nl  Thu Nov  5 22:22:49 2009
From: ml at radoeka.nl (Richard Bos)
Date: Thu, 5 Nov 2009 22:22:49 +0100
Subject: [Kolab-devel] Path in building package
In-Reply-To: <200911042122.57817.thomas@btspuhler.com>
References: <s7w3a5eja8x.fsf@intevation.de>
	<200911042122.57817.thomas@btspuhler.com>
Message-ID: <200911052222.50217.ml@radoeka.nl>

Hi Thomas,

Op donderdag 05 november 2009 05:22:57 schreef Thomas Spuhler:
> I am working on packing Kolab on the Mindriva Distribution.but need to
> change some path to get /usr/share/kolab/scripts into the path. I believe I
> saw this a while ago but cannot find it anymore. Tried Google too.

this questions has not sufficient information, to provide an answer.  Which 
application, script?  What path, what do you what change?  Etc.

-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091105/9cd6545c/attachment.html

From issues at kolab.org  Fri Nov  6 15:04:27 2009
From: issues at kolab.org (Thomas Arendsen Hein)
Date: Fri, 06 Nov 2009 14:04:27 +0000
Subject: [Kolab-devel] [issue3940] Deleting users does not work if master
	Kolab server is	not master LDAP
In-Reply-To: <1257516267.55.0.34825330396.issue3940@kolab.org>
Message-ID: <1257516267.55.0.34825330396.issue3940@kolab.org>


New submission from Thomas Arendsen Hein <thomas at intevation.de>:

Kolab Server 2.2.2 and all earlier 2.x versions:

perl-kolab/lib/Kolab/LDAP.pm contains:

        my $masterldap;
        if( lc($Kolab::config{'is_master'}) eq 'true' ) {
          # We are the master, just go ahead
          $masterldap = $ldap;
        } else {
          $masterldap = createMasterLDAP;
        }

If the master LDAP server runs on a separate machine, the code tries to delete
the user on the Kolab master's ldap_uri (by reusing an existing connection)
instead of using ldap_master_uri (reusing the connection only if it is the same
LDAP server).

Should be fixed for 2.2.3 release

----------
assignedto: thomas
keyword: kkc, release, server
messages: 22201
nosy: martin, thomas, wilde, wrobel
priority: urgent
status: unread
title: Deleting users does not work if master Kolab server is not master LDAP

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3940>
______________________________________


From issues at kolab.org  Sun Nov  8 21:01:26 2009
From: issues at kolab.org (Richard Bos)
Date: Sun, 08 Nov 2009 20:01:26 +0000
Subject: [Kolab-devel] [issue3941] patsubst in kolab Makefile.am: non-POSIX
	variable name
In-Reply-To: <1257710486.28.0.629883543315.issue3941@kolab.org>
Message-ID: <1257710486.28.0.629883543315.issue3941@kolab.org>


New submission from Richard Bos <ml at radoeka.nl>:

When bootstrapping the build of kolab, a warning is shown:
patsubst %,%.in,$(generated_executables: non-POSIX variable name

It does not seem to harm the build, but I'm still wondering whether this is
correct or not.

How to reproduce:
Obtain kolab from cvs, perform the following make procedure:

kolab-2.2.2.90_cvs20091108> ./bootstrap
configure.ac:8: installing `./install-sh'
configure.ac:8: installing `./missing'
Makefile.am:167: patsubst %,%.in,$(generated_executables: non-POSIX variable
name
Makefile.am:167: (probably a GNU make extension)
Makefile.am: installing `./INSTALL'

Extract of the Makefile.am:
166
167 EXTRA_DIST += $(patsubst %,%.in,$(generated_executables) $(generated_files))
168 EXTRA_DIST += $(kolabdoc_FILES)
169

The line was introduced with update 1.41 (which was committed by Sascha):
# ~/svn/server/kolabd/kolabd> cvs diff -r 1.40 -r 1.41 Makefile.am  | grep -A3 -
+EXTRA_DIST =
+CLEANFILES =
+
+EXTRA_DIST += $(patsubst %,%.in,$(generated_executables) $(generated_files))
+EXTRA_DIST += $(kolabdoc_FILES)
+
+CLEANFILES += $(generated_files) $(generated_executables)

A grep for patsubst in any of the other files, does no result in a hit.
Is the above correct with patsubst correct or not??

Sascha can you have a look at it?

----------
messages: 22230
nosy: rbos, tspuhler, wilde, wrobel
priority: bug
status: unread
title: patsubst in kolab Makefile.am: non-POSIX variable name

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3941>
______________________________________


From issues at kolab.org  Sun Nov  8 21:32:18 2009
From: issues at kolab.org (Richard Bos)
Date: Sun, 08 Nov 2009 20:32:18 +0000
Subject: [Kolab-devel] [issue3942] Split httpd.conf.template in an kolab
	specific part and a	main part
In-Reply-To: <1257712338.71.0.247670833473.issue3942@kolab.org>
Message-ID: <1257712338.71.0.247670833473.issue3942@kolab.org>


New submission from Richard Bos <ml at radoeka.nl>:

I would like to make the following proposal for the apache configuration file:
split the apache configuration file httpd.conf.template in an application
independent file (the web engine settings) and a kolab specific configuration
file.

More verbose description:
At this moment all apache settings are stored in 1 big monolithic file called
httpd.conf.template.in.  This works and it works well for the openpkg based
version of kolab.  But for others (at least openSUSE), the problem is to keep in
sync with the changes made to this file.  To cope with this type of problem (not
kolab specific) openSUSE provides a main configuration file, that defines the
web engine, to enable packagers to store application specific apache
configuration files in a configuration directory called /etc/apache/conf.d.  All
the files in that directory are sourced in by the main apache configuration
file.  

At this moment I patch the main apache configuration file provided by kolab and
remove all the web engine settings.  This results in a kolab only apache
configuration file.  This works, but as stated before it is hard to keep in sync
with kolab.  The attached patch splits the httpd.conf.template.in file and
stores the kolab specific settings in httpd.kolab.template.in.

For openpkg the file is stored in the apache configuration directory and named
kolab.include.  All files with the prefix .include are sourced in the by main
apache configuration file provided by kolab (last line in the file).

Basically nothing changes, but the location of some variables move to separate
file.  Making it much easier for non openpkg packagers to keep in sync.

It would be nice if this patch can be viewed with in an short time span, as the
patch is now still fresh.  If it takes a long time, it will be more difficult to
process the feedback!

The patch may require a update to spec or debian control files.

The patch can be reviewed by comparing the lines that are removed by the patch
(apache.patch).  All the lines that are removed by the patch should be part of
the file templates/httpd.kolab.template.in

Looking forward to your feedback.

----------
files: httpd.kolab.template.in
messages: 22231
nosy: bernhard, martin, mathieu.parent, rbos, thomas, tspuhler, wilde, wrobel
priority: wish
status: unread
title: Split httpd.conf.template in an kolab specific part and a main part

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3942>
______________________________________
-------------- next part --------------
KOLAB_META_START
TARGET=@webserver_confdir@/kolab.include
PERMISSIONS=0640
OWNERSHIP=@webserver_usr@:@webserver_grp@
RUNONCHANGE=@KOLABRC@ rc apache reload
KOLAB_META_END
# This program is Free Software under the GNU General Public License (>=v2).
# Read the file COPYING that comes with this packages for details.

# this file is automatically written by the Kolab config backend
# manual additions are lost unless made to the template in the Kolab config directory

# FreeBusy list handling
RewriteEngine On
#RewriteLog "/tmp/rewrite.log"
#RewriteLogLevel 9
# Without DOCUMENT_ROOT the rewrite engine uses a real /freebusy directory
# on the filesystem before %{DOCUMENT_ROOT}/freebusy.  This may result in
# unexpected behaviour.
RewriteRule ^/freebusy/([^/]+)\.ifb %{DOCUMENT_ROOT}/freebusy/freebusy.php?uid=$1
RewriteRule ^/freebusy/([^/]+)\.vfb %{DOCUMENT_ROOT}/freebusy/freebusy.php?uid=$1
RewriteRule ^/freebusy/([^/]+)\.xfb %{DOCUMENT_ROOT}/freebusy/freebusy.php?uid=$1&extended=1
RewriteRule ^/freebusy/trigger/(.+)\.pfb %{DOCUMENT_ROOT}/freebusy/pfb.php?folder=$1&cache=0
RewriteRule ^/freebusy/(.+)\.pfb %{DOCUMENT_ROOT}/freebusy/pfb.php?folder=$1&cache=1
RewriteRule ^/freebusy/(.+)\.pxfb %{DOCUMENT_ROOT}/freebusy/pfb.php?folder=$1&cache=1&extended=1

<Location "@webserver_web_prefix@/">
    ErrorDocument 403 https://@@@fqdnhostname@@@@kolab_wui@/
</Location>
<Location "@kolab_wui@">
    SSLRequireSSL
</Location>
<Location "@webserver_web_prefix@/client">
    ErrorDocument 403 https://@@@fqdnhostname@@@@webserver_web_prefix@/client/
    SSLRequireSSL
</Location>
<Location "@webserver_web_prefix@/fbview">
    ErrorDocument 403 https://@@@fqdnhostname@@@@webserver_web_prefix@/fbview/
    SSLRequireSSL
</Location>
@@@if apache-http@@@
@@@else@@@
<Location "@webserver_web_prefix@/freebusy">
    SSLRequireSSL
</Location>
@@@endif@@@

# Redirect from the old Kolab web client location (Kolab-Server-2.2.0)
# to the new one (Kolab-Server >= 2.2.1)                              
Redirect /horde https://kolab2.radoeka.nl/client                      

<AuthnProviderAlias ldap ldap-mail>
  AuthLDAPURL ldap://@@@ldap_ip@@@:@@@ldap_port@@@/@@@base_dn@@@?mail
  AuthLDAPBindDN "@@@php_dn@@@"
  AuthLDAPBindPassword "@@@php_pw@@@"
  AuthzLDAPAuthoritative off
</AuthnProviderAlias>
<AuthnProviderAlias ldap ldap-uid>
  AuthLDAPURL ldap://@@@ldap_ip@@@:@@@ldap_port@@@/@@@base_dn@@@?uid
  AuthLDAPBindDN "@@@php_dn@@@"
  AuthLDAPBindPassword "@@@php_pw@@@"
  AuthzLDAPAuthoritative off
</AuthnProviderAlias>

<Directory "@webserver_document_root@/freebusy">
   AllowOverride None
   Options None
   # Disallow for everyone as default
   Order allow,deny
   Allow from all
@@@if apache-allow-unauthenticated-fb@@@
@@@else@@@
   Require valid-user
   AuthType Basic
   AuthName "Kolab Freebusy"

   AuthBasicAuthoritative off
   AuthUserFile /dev/null
   AuthBasicProvider ldap-mail ldap-uid
@@@endif@@@
   AddDefaultCharset Off  
</Directory>

<Directory "@webserver_document_root@/client">
    AllowOverride All
    Allow from all
</Directory>

<Directory "@webserver_document_root@/fbview">
    AllowOverride All
    Allow from all
</Directory>

<Directory "@webserver_document_root@@kolab_wui@">
   AllowOverride None
   Options None
   Order allow,deny
   Allow from all
</Directory>


From ml at radoeka.nl  Sun Nov  8 21:49:37 2009
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 8 Nov 2009 21:49:37 +0100
Subject: [Kolab-devel] kolab-fbview package
Message-ID: <200911082149.38635.ml@radoeka.nl>

Hi,

at the moment the package kolab-fbview is provided by an rpm that is 26M, 
almost the same seize as its cousing kolab-webclient.

[   ]  kolab-fbview-1.2.0-20081227.src.rpm  19-Feb-2009 18:22    26M   
[   ]  kolab-webclient-1.2.0-20090514.src.rpm  15-May-2009 11:03    27M   

Both packages provide / contain the file horde-webmail-1.2.tar.gz, having a 
size of 26MB.  As I don't want (like) to package horde-webmail-1.2.tar.gz 
twice, ain't it possible to provide the fbview functionality in the same 
package as kolab-webclient?  The package kolab-fbview provides the source 
files: 
- fbview-kolab-conf.template,
- fbview-kronolith-kolab-conf.template and 
- horde-webmail-1.2.0_kolab_fbview_openpkg.patch 
besides the tarbal horde-webmail-1.2.tar.gz.

The first 2 files can perfectly provided by kolab-webclient, but the patch may 
be another beast.  It's a big patch (422kB and 12803 lines!).  Is this the 
cause, that it is delivered seperately?  Is it not possible to combine the 
patch with the patches in kolab-webclient?  Will this be possible in the 
future?

-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091108/8649ae9c/attachment.html

From wrobel at pardus.de  Mon Nov  9 08:51:41 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 09 Nov 2009 08:51:41 +0100
Subject: [Kolab-devel] kolab-fbview package
In-Reply-To: <200911082149.38635.ml@radoeka.nl>
References: <200911082149.38635.ml@radoeka.nl>
Message-ID: <20091109085141.134841ubf9okry80@webmail.pardus.de>


Quoting Richard Bos <ml at radoeka.nl>:

> Hi,
>
> at the moment the package kolab-fbview is provided by an rpm
> that is 26M, almost the same seize as its cousing kolab-webclient.
>
> [   ]  kolab-fbview-1.2.0-20081227.src.rpm  19-Feb-2009 18:22   26M   
>  [   ]  kolab-webclient-1.2.0-20090514.src.rpm  15-May-2009 11:03    
> 27M   Both packages provide / contain the file
> horde-webmail-1.2.tar.gz, having a size of 26MB.  As I don't want
> (like) to package horde-webmail-1.2.tar.gz twice, ain't it possible
> to provide the fbview functionality in the same package as
> kolab-webclient?  The package kolab-fbview provides the source
> files: - fbview-kolab-conf.template,
> - fbview-kronolith-kolab-conf.template and -  
> horde-webmail-1.2.0_kolab_fbview_openpkg.patch besides the tarbal  
> horde-webmail-1.2.tar.gz.
>
> The first 2 files can perfectly provided by kolab-webclient,
> but the patch may be another beast.  It's a big patch (422kB and
> 12803 lines!).  Is this the cause, that it is delivered seperately?

> Is it not possible to combine the patch with the patches in
> kolab-webclient?  Will this be possible in the future?

It will be possible in the future. In some regards my choice of using  
horde-webmail-1.2.0 as a basis for the kolab webclient was pretty bad.  
The problems you describe are one of them. This basically refers to  
the code duplication also described in  
https://issues.kolab.org/issue3293.

This duplication is not necessary but it means we will have more  
packages. This is already being prepared for Kolab-Server-2.3. You  
already have seen all the different PEAR based packages. This will  
also happen with the horde applications. So we will have a horde,  
kronolith, turba, imp, ingo, mnemo and nag package again.

In the more distant future I still hope to combine the fbview  
application into the standard kronolith. It is really not more than a  
stripped down kronolith with two or three patches.

Cheers,

Gunnar

-- 
____ 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 <<
--------------------------------------------------------------------
-------------- 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/20091109/f231e3f1/attachment.bin

From issues at kolab.org  Mon Nov  9 14:05:34 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 09 Nov 2009 13:05:34 +0000
Subject: [Kolab-devel] [issue3943] ldap lookup: new domain name search
	option.
In-Reply-To: <1257771934.22.0.263481109911.issue3943@kolab.org>
Message-ID: <1257771934.22.0.263481109911.issue3943@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Problem:
A user has 10 resources in the lookup and search for "Smith", in a resource
there are a lot of Smiths. So he wants the Smiths which email address contains a
certain
mail domain to appear first.

It should be possible to enter a mail domain in a field which is in the lookup
order dialog. The mails of this domain should be displayed first.

Please estimate and wait on an okay before implementing.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22251
nosy: allen, ludwig
priority: wish
status: unread
title: ldap lookup: new domain name search option.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3943>
______________________________________


From issues at kolab.org  Mon Nov  9 17:24:49 2009
From: issues at kolab.org (Thomas Arendsen Hein)
Date: Mon, 09 Nov 2009 16:24:49 +0000
Subject: [Kolab-devel] [issue3944] Crash when delegating invitation
In-Reply-To: <1257783889.0.0.877022456887.issue3944@kolab.org>
Message-ID: <1257783889.0.0.877022456887.issue3944@kolab.org>


New submission from Thomas Arendsen Hein <thomas at intevation.de>:

Kontact Version 1.2.9 (enterprise35 20090918.1030082)
and probably other versions, too:

Reproducible crash without bomb dialog, so I attached the debug output printed
when using "kontact --nofork".

I (thomas at example.com) received an invitation from inviting.user at example.com via
a server-side distribution list with RSVP=false.
I clicked on [Delegate],
chose thomas at example.com as my identity,
added small comment (reproducible without comment, too),
Added "someone at example.com" as delegate ("keeping informed ..." enabled or
disabled, does not matter)

----------
assignedto: allen
files: kontact.log
keyword: enterprise35, kde client
messages: 22256
nosy: allen, laurent, ludwig, thomas, till, tmcguire, vkrause
priority: urgent
status: unread
title: Crash when delegating invitation

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3944>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kontact.log
Type: text/x-log
Size: 4597 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091109/e30ffc9b/kontact.bin

From bernhard at intevation.de  Mon Nov  9 18:10:09 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 9 Nov 2009 18:10:09 +0100
Subject: [Kolab-devel]
	=?iso-8859-1?q?kimap_=28imap_library=29_Re=3A_annot?=
	=?iso-8859-1?q?ations_patch_in=09c-client_what_is_the_status=3F?=
In-Reply-To: <200911051034.38867.thomas.jarosch@intra2net.com>
References: <b756c91fbfb72929d5f269992f6968ab.squirrel@webmail.xs4all.nl>
	<20091105100122.12505lyvl7gb0uck@webmail.pardus.de>
	<200911051034.38867.thomas.jarosch@intra2net.com>
Message-ID: <200911091810.12801.bernhard@intevation.de>

Am Donnerstag, 5. November 2009 10:34:38 schrieb Thomas Jarosch:
> Here comes the troublesome part (sorry Bernhard for not replying earlier):
> The library is written in C++ while PHP uses mostly C. We would need a lot
> of wrapper glue here. The new library also depends on Qt and some KDE
> libraries, this is quite a heavy dependency for a PHP module.

The KDE dependency is optional and responsible for SSL certificate handling
if I remember correctly. Qt as a general-purpose library is non-gui and quite 
small (thanks Richard for making this point better then I've could).

> Maybe all the added wrapper glue kills the speed advantage, if any?

As PHP is also an object oriented language, C++ should wrap easier than C
(at least with python mapping and object oriented language usually leads to 
something more pythonic.)

> Just think of the needed string conversions QString <-> PHP string type
> which are needed every time you access a message header/body etc.

Yes, this could be an issue. On the point a pure PHP implementation might just 
outperform libkimap. I am no expert on wrapping C++ in PHP, maybe there is a 
different way to shortcut the string handling and delay conversation until a 
string is actually needed.

> At least there is already a way to interface Qt/KDE libraries
> with PHP as there a Qt bindings for PHP:
> http://techbase.kde.org/Development/Languages/PHP-Qt

It's worth a try I guess, thanks for the pointer.
It will even get more interesting if Akonadi is directly used. :)

-- 
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/20091109/b1f8d696/attachment.bin

From wrobel at pardus.de  Tue Nov 10 00:04:54 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 10 Nov 2009 00:04:54 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <20091020172924.577027525.thomas@intevation.de>
References: <20091020172924.577027525.thomas@intevation.de>
Message-ID: <20091110000454.81530rym7x0suhis@webmail.pardus.de>

Hi Thomas,

here is an update on my part:

Quoting Thomas Arendsen Hein <thomas at intevation.de>:

[snip]

> Gunnar:

>   kolab/issue3890 (kolabHomeServer not selected for freebusy due to  
> logic error in Kolab Patch)
>     (patch available)

Bogus report -> closed.

>   kolab/issue3856 (IMP/DIMP folder navigator does not allow  
> creating/deleting/... mail folders)

DONE

>   kolab/issue3610 (Mail to unknown at something.example.com gets  
> accepted and yields kolabmailboxfilter exit 38)
>   kolab/issue919  (kolab server has problems with some characters in  
> passwords)
>     (people wanting to use more secure passwords should not be punished)

Still open and on my TODO list.

>   SyncML issues

This is somewhat too generic in my opinion. We might gain something by  
exchanging the current SyncML library we use by the new version  
provided by upstream. There were many fixes during the last year.  
Nevertheless SyncML relies heavily on the different applications  
(turba, kronolith etc.). Many SyncML fixes were actually done in those  
packages.

As we plan to upgrade the Horde packages in Kolab Server 2.3 anyway I  
consider that a much better target for SyncML fixes than 2.2.3. Or do  
you have any issues on your list that require immediate hotfixing?

> maybe:
>
> kolab/issue3846 (fix recurring events that are counted per week and not per
> incident)
>    (patch available)

In active progress.

[snip]

Finally there was a long standing bug that was missing from the list:

kolab/issue2499 (Notification messages by the resource manager should  
be localized)

This is also completed.


Cheers,

Gunnar

-- 
______ 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 <<
--------------------------------------------------------------------

-------------- 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/20091110/ee745ba8/attachment.bin

From thomas at intevation.de  Tue Nov 10 15:23:09 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Tue, 10 Nov 2009 15:23:09 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <20091110000454.81530rym7x0suhis@webmail.pardus.de>
References: <20091020172924.577027525.thomas@intevation.de>
	<20091110000454.81530rym7x0suhis@webmail.pardus.de>
Message-ID: <20091110152044.360848232.thomas@intevation.de>

Hi!

Thanks for the status update.

* Gunnar Wrobel <wrobel at pardus.de> [20091110 00:05]:
> Quoting Thomas Arendsen Hein <thomas at intevation.de>:
>>   SyncML issues
>
> This is somewhat too generic in my opinion. We might gain something by  
> exchanging the current SyncML library we use by the new version provided 
> by upstream. There were many fixes during the last year. Nevertheless 
> SyncML relies heavily on the different applications (turba, kronolith 
> etc.). Many SyncML fixes were actually done in those packages.
>
> As we plan to upgrade the Horde packages in Kolab Server 2.3 anyway I  
> consider that a much better target for SyncML fixes than 2.2.3. Or do  
> you have any issues on your list that require immediate hotfixing?

I thought some of the patches provided by Univention are about
improving SyncML. You might want to read this as a more generic
"look at the patches from Univention".

Regards,
Thomas

-- 
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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091110/505a3926/attachment.bin

From issues at kolab.org  Thu Nov  5 15:19:47 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 05 Nov 2009 14:19:47 +0000
Subject: [Kolab-devel] [issue3939] A long event is displayed wrongly
In-Reply-To: <1257430787.35.0.754451758541.issue3939@kolab.org>
Message-ID: <1257430787.35.0.754451758541.issue3939@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

observed with Kontact e4 windows 20091027-1

Test:
1. Create an event from 20091105 10:00 to 20091106 11:00
=>The event is displayed wrongly.

See screenshot

----------
assignedto: allen
files: long-event-display.png
keyword: enterprise4, kde client
messages: 22187
nosy: allen, ludwig
priority: minor bug
status: unread
title: A long event is displayed wrongly

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3939>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: long-event-display.png
Type: image/png
Size: 47780 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091105/8975a2f3/long-event-display-0001.png

From ml at radoeka.nl  Tue Nov 10 19:20:55 2009
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 10 Nov 2009 19:20:55 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <20091110000454.81530rym7x0suhis@webmail.pardus.de>
References: <20091020172924.577027525.thomas@intevation.de>
	<20091110000454.81530rym7x0suhis@webmail.pardus.de>
Message-ID: <200911101920.55348.ml@radoeka.nl>

Hi,

Op dinsdag 10 november 2009 00:04:54 schreef Gunnar Wrobel:
> Finally there was a long standing bug that was missing from the list:

Another one that misses on list, issue606 the last update in that issue is:
upgrading to urgent .

The url to issue606.

-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091110/dc27affa/attachment.html

From ml at radoeka.nl  Tue Nov 10 23:41:21 2009
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 10 Nov 2009 23:41:21 +0100
Subject: [Kolab-devel] kolab-fbview package
In-Reply-To: <20091109085141.134841ubf9okry80@webmail.pardus.de>
References: <200911082149.38635.ml@radoeka.nl>
	<20091109085141.134841ubf9okry80@webmail.pardus.de>
Message-ID: <200911102341.21984.ml@radoeka.nl>

Op maandag 09 november 2009 08:51:41 schreef Gunnar Wrobel:
> In the more distant future I still hope to combine the fbview  
> application into the standard kronolith. It is really not more than a  
> stripped down kronolith with two or three patches.

Is it not possible to copy the module kronolith in the kolab-webclient package 
to e.g. a module called fbview and patch that module so it provides the fbview 
functionality?

I diffed the files that are patched in kolab-fbview (via the horde-
webmail-1.2.0_kolab_fbview_openpkg.patch patch) with the same files in kolab-
webclient.  It looks to me that a big part of the diff result is caused, 
because kolab-webclient provides newer files.  The latter is caused by the 
patches in kolab-webclient, because both kolab-webclient and kolab-fbview are 
based on horde-webmail-1.2.0.

Wouldn't that (copy kronolith to fbview and patch fbview) be possible?

-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091110/26fdcf78/attachment.html

From thomas at intevation.de  Wed Nov 11 09:20:45 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Wed, 11 Nov 2009 09:20:45 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <200911101920.55348.ml@radoeka.nl>
References: <20091020172924.577027525.thomas@intevation.de>
	<20091110000454.81530rym7x0suhis@webmail.pardus.de>
	<200911101920.55348.ml@radoeka.nl>
Message-ID: <20091111091700.377568826.thomas@intevation.de>

* Richard Bos <ml at radoeka.nl> [20091110 19:21]:
> Op dinsdag 10 november 2009 00:04:54 schreef Gunnar Wrobel:
> > Finally there was a long standing bug that was missing from the list:
> 
> Another one that misses on list, issue606 the last update in that issue is:
> upgrading to urgent .

And I still agree that it would be nice to have this issue fixed,
but as I wrote in msg18784:

| Then we should not discuss, but publish 2.2.1-rc1 and then start
| working on this. You could already start by:
| - checking if the patch still applies
| - trying to gather translations
| - verify that LDAP searches/imports from clients show the middle
|   name as expected, otherwise people having middle names will get
|   mad at the admins who created their accounts

You are not the "You" in this text, but still you could help with these
points, too. I hope this is not too confusing :)

Regards,
Thomas

-- 
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 wrobel at pardus.de  Wed Nov 11 11:24:56 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Wed, 11 Nov 2009 11:24:56 +0100
Subject: [Kolab-devel] kolab-fbview package
In-Reply-To: <200911102341.21984.ml@radoeka.nl>
References: <200911082149.38635.ml@radoeka.nl>
	<20091109085141.134841ubf9okry80@webmail.pardus.de>
	<200911102341.21984.ml@radoeka.nl>
Message-ID: <20091111112456.16416etko8fo8xs0@webmail.pardus.de>


Quoting Richard Bos <ml at radoeka.nl>:

> Op maandag 09 november 2009 08:51:41 schreef Gunnar Wrobel:
> > In the more distant future I still hope to combine the fbview >  
> application into the standard kronolith. It is really not more
> than a  > stripped down kronolith with two or three patches.
>
> Is it not possible to copy the module kronolith in the
> kolab-webclient package to e.g. a module called fbview and patch
> that module so it provides the fbview functionality?

Not with the current code. With the current code base you need two  
distinct horde base installations. One for the webclient that carries  
the different modules like imp, ingo, kronolith, nag etc.. And the  
second one for fbview. This one only needs to carry the kronolith  
module.

The reason why you need two is basically only that the fbview login  
directly throws you on the fbview page. Installing a complete horde  
code base just for that is of course insane but it has always been  
this way and so far there was no time to change it.

The solution I imagine is to write a small horde application module  
that does the special kolab login. Currently you can select different  
views when logging in. We would simply add fbview there as an  
additional option.

Cheers,

Gunnar

>
> I diffed the files that are patched in kolab-fbview (via the
> horde-webmail-1.2.0_kolab_fbview_openpkg.patch patch) with the same
> files in kolab-webclient.  It looks to me that a big part of the
> diff result is caused, because kolab-webclient provides newer
files.
>  The latter is caused by the patches in kolab-webclient, because
> both kolab-webclient and kolab-fbview are based on
> horde-webmail-1.2.0.
>
> Wouldn't that (copy kronolith to fbview and patch fbview) be
> possible?
>
> -- 
> Richard

-- 
____ 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 <<
--------------------------------------------------------------------
-------------- 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/20091111/5d14a527/attachment.bin

From bernhard at intevation.de  Thu Nov 12 12:05:01 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 12 Nov 2009 12:05:01 +0100
Subject: [Kolab-devel] Client roadmap update
Message-ID: <200911121205.04443.bernhard@intevation.de>

I've just updated the client roadmap for the web (in CVS to go online in a 
couple of minutes):
http://kolab.org/roadmap.html

The most insteresting part is that Prototype-E5 is developing nicely and it 
might just be that it overtakes E4.

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/20091112/d663cfe9/attachment.bin

From thomas at btspuhler.com  Fri Nov 13 06:07:29 2009
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Thu, 12 Nov 2009 22:07:29 -0700
Subject: [Kolab-devel] Kolab Server 2.2.3
In-Reply-To: <200911101920.55348.ml@radoeka.nl>
References: <20091020172924.577027525.thomas@intevation.de>
	<20091110000454.81530rym7x0suhis@webmail.pardus.de>
	<200911101920.55348.ml@radoeka.nl>
Message-ID: <200911122207.30235.thomas@btspuhler.com>

the slpad-conf.template has now:

@@@if ldapserver_modulepath@@@
modulepath     @@false@@
moduleload     back_bdb
moduleload     back_monitor
moduleload     refint
moduleload     unique
@@@endif@@@

Where is this if ldapserver_modulepath set
Mandriva requires to load the modules

-- 
Thomas


From bernhard at intevation.de  Fri Nov 13 14:43:47 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 13 Nov 2009 14:43:47 +0100
Subject: [Kolab-devel] Kolab Server 2.2.
In-Reply-To: <200911122207.30235.thomas@btspuhler.com>
References: <20091020172924.577027525.thomas@intevation.de>
	<200911101920.55348.ml@radoeka.nl>
	<200911122207.30235.thomas@btspuhler.com>
Message-ID: <200911131443.50992.bernhard@intevation.de>

Am Freitag, 13. November 2009 06:07:29 schrieb Thomas Spuhler:
> @@@if ldapserver_modulepath@@@
> modulepath ? ? @@false@@
> moduleload ? ? back_bdb
> moduleload ? ? back_monitor
> moduleload ? ? refint
> moduleload ? ? unique
> @@@endif@@@
>
> Where is this if ldapserver_modulepath set
> Mandriva requires to load the modules

Check the kolabconf code which interprets the templates.

-- 
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/20091113/70c496f9/attachment.bin

From thomas at intevation.de  Fri Nov 13 15:37:55 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Fri, 13 Nov 2009 15:37:55 +0100
Subject: [Kolab-devel] ldapserver_modulepath (was: Re: Kolab Server 2.2.)
In-Reply-To: <200911131443.50992.bernhard@intevation.de>
References: <20091020172924.577027525.thomas@intevation.de>
	<200911101920.55348.ml@radoeka.nl>
	<200911122207.30235.thomas@btspuhler.com>
	<200911131443.50992.bernhard@intevation.de>
Message-ID: <20091113153445.483651069.thomas@intevation.de>

* Bernhard Reiter <bernhard at intevation.de> [20091113 14:43]:
> Am Freitag, 13. November 2009 06:07:29 schrieb Thomas Spuhler:
> > @@@if ldapserver_modulepath@@@
> > modulepath ? ? @@false@@
> > moduleload ? ? back_bdb
> > moduleload ? ? back_monitor
> > moduleload ? ? refint
> > moduleload ? ? unique
> > @@@endif@@@
> >
> > Where is this if ldapserver_modulepath set
> > Mandriva requires to load the modules
> 
> Check the kolabconf code which interprets the templates.

No, look at kolabd/kolabd/dist_conf/*

But it is in CVS HEAD, i.e. not for Kolab Server 2.2.x

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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091113/e43e4db2/attachment.bin

From math.parent at gmail.com  Fri Nov 13 16:30:00 2009
From: math.parent at gmail.com (Mathieu Parent)
Date: Fri, 13 Nov 2009 16:30:00 +0100
Subject: [Kolab-devel] Kolab Server 2.2.3
In-Reply-To: <200911122207.30235.thomas@btspuhler.com>
References: <20091020172924.577027525.thomas@intevation.de>
	<20091110000454.81530rym7x0suhis@webmail.pardus.de>
	<200911101920.55348.ml@radoeka.nl>
	<200911122207.30235.thomas@btspuhler.com>
Message-ID: <960738410911130730g1530aa12qf2158a7153ef12a2@mail.gmail.com>

Hello,


On Fri, Nov 13, 2009 at 6:07 AM, Thomas Spuhler <thomas at btspuhler.com> wrote:
> the slpad-conf.template has now:
>
> @@@if ldapserver_modulepath@@@
> modulepath ? ? @@false@@
> moduleload ? ? back_bdb
> moduleload ? ? back_monitor
> moduleload ? ? refint
> moduleload ? ? unique
> @@@endif@@@
>
> Where is this if ldapserver_modulepath set
> Mandriva requires to load the modules

I don't understand. Can you please reformulate?


You should probably apply same as
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolabd/kolabd/dist_conf/kolab.diff?r1=1.73&r2=1.74
for mandriva. Or something like
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolabd/kolabd/dist_conf/debian.diff?r1=1.29&r2=1.30
if modules are dynamicaly loaded.

Mathieu Parent


From thomas at btspuhler.com  Sat Nov 14 18:51:49 2009
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sat, 14 Nov 2009 10:51:49 -0700
Subject: [Kolab-devel] Kolab Server 2.2.3
In-Reply-To: <960738410911130730g1530aa12qf2158a7153ef12a2@mail.gmail.com>
References: <20091020172924.577027525.thomas@intevation.de>
	<200911122207.30235.thomas@btspuhler.com>
	<960738410911130730g1530aa12qf2158a7153ef12a2@mail.gmail.com>
Message-ID: <200911141051.49295.thomas@btspuhler.com>

On Friday 13 November 2009 08:30:00 am Mathieu Parent wrote:
> Hello,
>
> On Fri, Nov 13, 2009 at 6:07 AM, Thomas Spuhler <thomas at btspuhler.com> 
wrote:
> > the slpad-conf.template has now:
> >
> > @@@if ldapserver_modulepath@@@
> > modulepath     @@false@@
> > moduleload     back_bdb
> > moduleload     back_monitor
> > moduleload     refint
> > moduleload     unique
> > @@@endif@@@
> >
> > Where is this if ldapserver_modulepath set
> > Mandriva requires to load the modules
>
> I don't understand. Can you please reformulate?
>
>
> You should probably apply same as
> http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolabd/kolabd/dist_conf/k
>olab.diff?r1=1.73&r2=1.74 for mandriva. Or something like
> http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolabd/kolabd/dist_conf/d
>ebian.diff?r1=1.29&r2=1.30 if modules are dynamicaly loaded.
>
> Mathieu Parent
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel

Ok, I get a little closer, but I know receive the message that the module is 
already loaded.
I am not a Perl coder, but it looks is if the code loads it twice

See this http://mandriva.pastebin.fr/6001

-- 
Thomas


From thomas at btspuhler.com  Sat Nov 14 22:42:07 2009
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sat, 14 Nov 2009 14:42:07 -0700
Subject: [Kolab-devel] Kolab Server 2.2.3
In-Reply-To: <200911141051.49295.thomas@btspuhler.com>
References: <20091020172924.577027525.thomas@intevation.de>
	<960738410911130730g1530aa12qf2158a7153ef12a2@mail.gmail.com>
	<200911141051.49295.thomas@btspuhler.com>
Message-ID: <200911141442.07881.thomas@btspuhler.com>

On Saturday 14 November 2009 10:51:49 am Thomas Spuhler wrote:
> On Friday 13 November 2009 08:30:00 am Mathieu Parent wrote:
> > Hello,
> >
> > On Fri, Nov 13, 2009 at 6:07 AM, Thomas Spuhler <thomas at btspuhler.com>
>
> wrote:
> > > the slpad-conf.template has now:
> > >
> > > @@@if ldapserver_modulepath@@@
> > > modulepath     @@false@@
> > > moduleload     back_bdb
> > > moduleload     back_monitor
> > > moduleload     refint
> > > moduleload     unique
> > > @@@endif@@@
> > >
> > > Where is this if ldapserver_modulepath set
> > > Mandriva requires to load the modules
> >
> > I don't understand. Can you please reformulate?
> >
> >
> > You should probably apply same as
> > http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolabd/kolabd/dist_conf
> >/k olab.diff?r1=1.73&r2=1.74 for mandriva. Or something like
> > http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolabd/kolabd/dist_conf
> >/d ebian.diff?r1=1.29&r2=1.30 if modules are dynamicaly loaded.
> >
> > Mathieu Parent
> >
> > _______________________________________________
> > Kolab-devel mailing list
> > Kolab-devel at kolab.org
> > https://kolab.org/mailman/listinfo/kolab-devel
>
> Ok, I get a little closer, but I know receive the message that the module
> is already loaded.
> I am not a Perl coder, but it looks is if the code loads it twice
>
> See this http://mandriva.pastebin.fr/6001
 Ok, I figured this out.

But the kolabd has a couple line that may be a problem:
. /etc/rc.status

# Reset status of this service
rc_reset

Mandriva doesn't have this script. I found on Google, Redhat and Debian based 
distros don't have it.
I this important?

-- 
Thomas


From ml at radoeka.nl  Sun Nov 15 18:03:49 2009
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 15 Nov 2009 18:03:49 +0100
Subject: [Kolab-devel] Z-push
Message-ID: <200911151803.49733.ml@radoeka.nl>

Alain,

is it possible to give an indication when version 0.3 will be available:
https://wiki.kolab.org/index.php/Z_push#Roadmap ?
(this month, or year or Q1 2010, etc)

Question about the addition of folders, mentioned in:
https://wiki.kolab.org/index.php/Z_push#Installation
Are al these folders:
KOLAB_IMAP_OPTIONS
KOLAB_IMAP_PORT
KOLAB_INDEX
KOLAB_CONTACT_FOLDER
KOLAB_DIARY_FOLDER
KOLAB_SHAREDFOLDER
KOLAB_USERFOLDER
KOLAB_JUST_DEFAULT_DIARY
KOLAB_JUST_DEFAULT_CONTACT
KOLAB_SHAREDFOLDERS_RO
KOLAB_LOGFILE

to be added in: ./config.php in version 0.2  If that is the case, wouldn't it 
be better to remove the line with "For V0,2" , and state that all these 
variables are to be added to ./config.php, like this:

and add:
KOLAB_IMAP_OPTIONS
KOLAB_IMAP_PORT
KOLAB_INDEX
KOLAB_CONTACT_FOLDER
KOLAB_DIARY_FOLDER
KOLAB_SHAREDFOLDER
KOLAB_USERFOLDER
KOLAB_JUST_DEFAULT_DIARY
KOLAB_JUST_DEFAULT_CONTACT
KOLAB_SHAREDFOLDERS_RO
KOLAB_LOGFILE

-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091115/a0d5c5e2/attachment.html

From alain.abbas at libertech.fr  Sun Nov 15 18:16:23 2009
From: alain.abbas at libertech.fr (Alain abbas)
Date: Sun, 15 Nov 2009 18:16:23 +0100
Subject: [Kolab-devel] Z-push
In-Reply-To: <200911151803.49733.ml@radoeka.nl>
References: <200911151803.49733.ml@radoeka.nl>
Message-ID: <4B003767.60202@libertech.fr>

hi Richard
better like that ?

Richard Bos a ?crit :
> Alain,
>
>
> is it possible to give an indication when version 0.3 will be available:
> https://wiki.kolab.org/index.php/Z_push#Roadmap ?
> (this month, or year or Q1 2010, etc)
>
>
> Question about the addition of folders, mentioned in:
> https://wiki.kolab.org/index.php/Z_push#Installation
> Are al these folders:
> KOLAB_IMAP_OPTIONS
> KOLAB_IMAP_PORT
> KOLAB_INDEX
> KOLAB_CONTACT_FOLDER
> KOLAB_DIARY_FOLDER
> KOLAB_SHAREDFOLDER
> KOLAB_USERFOLDER
> KOLAB_JUST_DEFAULT_DIARY
> KOLAB_JUST_DEFAULT_CONTACT
> KOLAB_SHAREDFOLDERS_RO
> KOLAB_LOGFILE
>
>
> to be added in: ./config.php in version 0.2 If that is the case, 
> wouldn't it be better to remove the line with "For V0,2" , and state 
> that all these variables are to be added to ./config.php, like this:
>
>
> and add:
> KOLAB_IMAP_OPTIONS
> KOLAB_IMAP_PORT
> KOLAB_INDEX
> KOLAB_CONTACT_FOLDER
> KOLAB_DIARY_FOLDER
> KOLAB_SHAREDFOLDER
> KOLAB_USERFOLDER
> KOLAB_JUST_DEFAULT_DIARY
> KOLAB_JUST_DEFAULT_CONTACT
> KOLAB_SHAREDFOLDERS_RO
> KOLAB_LOGFILE
>
>
> -- 
> Richard
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From ml at radoeka.nl  Sun Nov 15 19:20:31 2009
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 15 Nov 2009 19:20:31 +0100
Subject: [Kolab-devel] Z-push
In-Reply-To: <4B003767.60202@libertech.fr>
References: <200911151803.49733.ml@radoeka.nl> <4B003767.60202@libertech.fr>
Message-ID: <200911151920.31836.ml@radoeka.nl>

Op zondag 15 november 2009 18:16:23 schreef Alain abbas:
> hi Richard
> better like that ?

Yes, although I changed it a little (because of the wiki markup)
https://wiki.kolab.org/index.php/Z_push#Installation

-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091115/c5106d47/attachment.html

From richard at radoeka.nl  Sun Nov 15 19:44:42 2009
From: richard at radoeka.nl (Richard Bos)
Date: Sun, 15 Nov 2009 19:44:42 +0100
Subject: [Kolab-devel] Z-push
In-Reply-To: <4B003767.60202@libertech.fr>
References: <200911151803.49733.ml@radoeka.nl> <4B003767.60202@libertech.fr>
Message-ID: <200911151944.42651.richard@radoeka.nl>

Alain,

Op zondag 15 november 2009 18:16:23 schreef Alain abbas:
> better like that ?

the file ./doc/readme_nightly.txt on in the sourceforge svn repository 
contains:
define('KOLAB_IMAP_PORT', 4343);

Shouldn't that be port 143?  At least that is what the wiki shows.


And there is also:
****Obsolete*******
define('KOLAB_CONTACT_FOLDER',"inbox.contacts");
define('KOLAB_DIARY_FOLDER',"inbox.calendrier");


Can't that be left out, from the svn file.  It will only result in 
confusion....


-- 
Richard Bos
Without a home the journey is endless

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091115/27e277fb/attachment.html

From alain.abbas at libertech.fr  Sun Nov 15 20:09:21 2009
From: alain.abbas at libertech.fr (Alain abbas)
Date: Sun, 15 Nov 2009 20:09:21 +0100
Subject: [Kolab-devel] Z-push
In-Reply-To: <200911151944.42651.richard@radoeka.nl>
References: <200911151803.49733.ml@radoeka.nl> <4B003767.60202@libertech.fr>
	<200911151944.42651.richard@radoeka.nl>
Message-ID: <4B0051E1.7090006@libertech.fr>

An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091115/ee5a2610/attachment.html

From alain.abbas at libertech.fr  Sun Nov 15 20:12:05 2009
From: alain.abbas at libertech.fr (Alain abbas)
Date: Sun, 15 Nov 2009 20:12:05 +0100
Subject: [Kolab-devel] Z-push
In-Reply-To: <200911151944.42651.richard@radoeka.nl>
References: <200911151803.49733.ml@radoeka.nl> <4B003767.60202@libertech.fr>
	<200911151944.42651.richard@radoeka.nl>
Message-ID: <4B005285.2090203@libertech.fr>

corrected on the 2 files set 143
Richard Bos a ?crit :
> Alain,
>
>
> Op zondag 15 november 2009 18:16:23 schreef Alain abbas:
> > better like that ?
>
>
> the file ./doc/readme_nightly.txt on in the sourceforge svn repository 
> contains:
> define('KOLAB_IMAP_PORT', 4343);
>
>
> Shouldn't that be port 143? At least that is what the wiki shows.
>
>
>
> And there is also:
> ****Obsolete*******
> define('KOLAB_CONTACT_FOLDER',"inbox.contacts");
> define('KOLAB_DIARY_FOLDER',"inbox.calendrier");
>
>
>
> Can't that be left out, from the svn file. It will only result in 
> confusion....
>
>
>
> -- 
> Richard Bos
> Without a home the journey is endless
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From ml at radoeka.nl  Sun Nov 15 22:23:47 2009
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 15 Nov 2009 22:23:47 +0100
Subject: [Kolab-devel] Kolab Server 2.2.3
In-Reply-To: <200911141442.07881.thomas@btspuhler.com>
References: <20091020172924.577027525.thomas@intevation.de>
	<200911141051.49295.thomas@btspuhler.com>
	<200911141442.07881.thomas@btspuhler.com>
Message-ID: <200911152223.48497.ml@radoeka.nl>

Thomas,

Op zaterdag 14 november 2009 22:42:07 schreef Thomas Spuhler:
> > Ok, I get a little closer, but I know receive the message that the module
> > is already loaded.
> > I am not a Perl coder, but it looks is if the code loads it twice
> >
> > See this http://mandriva.pastebin.fr/6001
>
>  Ok, I figured this out.

What did you make of it?


> But the kolabd has a couple line that may be a problem:
> . /etc/rc.status

No idea where this come from:
kolabd> grep -R "rc\.status" *
No result, there is no file in the kolabd module that contains sting.  Neither 
does perl-kolab.

-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091115/ed76f5d9/attachment-0001.html

From ml at radoeka.nl  Sun Nov 15 22:27:05 2009
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 15 Nov 2009 22:27:05 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <20091111091700.377568826.thomas@intevation.de>
References: <20091020172924.577027525.thomas@intevation.de>
	<200911101920.55348.ml@radoeka.nl>
	<20091111091700.377568826.thomas@intevation.de>
Message-ID: <200911152227.06010.ml@radoeka.nl>

Op woensdag 11 november 2009 09:20:45 schreef Thomas Arendsen Hein:
> * Richard Bos <ml at radoeka.nl> [20091110 19:21]:
> > Op dinsdag 10 november 2009 00:04:54 schreef Gunnar Wrobel:
> > > Finally there was a long standing bug that was missing from the list:
> >
> > Another one that misses on list, issue606 the last update in that issue
> > is: upgrading to urgent .
>
> And I still agree that it would be nice to have this issue fixed,
>
> but as I wrote in msg18784:
> | Then we should not discuss, but publish 2.2.1-rc1 and then start
> | working on this. You could already start by:
> | - checking if the patch still applies
> | - trying to gather translations
> | - verify that LDAP searches/imports from clients show the middle
> |   name as expected, otherwise people having middle names will get
> |   mad at the admins who created their accounts
>
> You are not the "You" in this text, but still you could help with these
> points, too. I hope this is not too confusing :)

It's not confusing for me :)  I tried to be smart by not referencing to your 
update.  Unfortunately, you somehow found it ;)

-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091115/f0ea3e47/attachment.html

From ml at radoeka.nl  Sun Nov 15 23:04:43 2009
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 15 Nov 2009 23:04:43 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <200910210904.40593.dusty@qwer.tk>
References: <20091020172924.577027525.thomas@intevation.de>
	<200910210904.40593.dusty@qwer.tk>
Message-ID: <200911152304.44353.ml@radoeka.nl>

Hello Thomas,

Am Dienstag 20 Oktober 2009 17:34:01 schrieb Thomas Arendsen Hein:
> Here is a preliminary list of issues we want to address in Kolab
> Server 2.2.3, we aim to make the release in December:

For the recent cvs commits that made, I want to update the release-notes file.  
But the file contains (including line numbers)
   9 Changes between 2.2.3 and 2.???:
......
 130 Changes between 2.2.2 and 2.2.3:

But 2.2.3 is not yet released.  Is line 9. correct?

I need to add issue3401 and issue3428 for the kolab-webadmin module.  Can you 
add this information?
https://issues.kolab.org/issue3401
https://issues.kolab.org/issue3428

-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091115/52d529ec/attachment.html

From thomas at btspuhler.com  Mon Nov 16 05:28:53 2009
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sun, 15 Nov 2009 23:28:53 -0500
Subject: [Kolab-devel] Kolab Server 2.2.3
In-Reply-To: <200911152223.48497.ml@radoeka.nl>
References: <20091020172924.577027525.thomas@intevation.de>
	<200911141442.07881.thomas@btspuhler.com>
	<200911152223.48497.ml@radoeka.nl>
Message-ID: <200911152328.53646.thomas@btspuhler.com>


On Sunday 15 November 2009 04:23:47 pm Richard Bos wrote:
> Thomas,
>
> Op zaterdag 14 november 2009 22:42:07 schreef Thomas Spuhler:
> > > Ok, I get a little closer, but I know receive the message that the
> > > module is already loaded.
> > > I am not a Perl coder, but it looks is if the code loads it twice
> > >
> > > See this http://mandriva.pastebin.fr/6001
> >
> >  Ok, I figured this out.
>
> What did you make of it?
>
> > But the kolabd has a couple line that may be a problem:
> > . /etc/rc.status
>
> No idea where this come from:
> kolabd> grep -R "rc\.status" *
> No result, there is no file in the kolabd module that contains sting. 
> Neither does perl-kolab.
I am traveling this week and don't have access to my virtual from outside.
But here is a link that describes it:
https://wiki.kolab.org/index.php/Init_Script


From issues at kolab.org  Mon Nov 16 13:38:18 2009
From: issues at kolab.org (Gunnar Wrobel)
Date: Mon, 16 Nov 2009 12:38:18 +0000
Subject: [Kolab-devel] [issue3945] Analyze and split the Horde caching
	directories
In-Reply-To: <1258375098.5.0.416693360951.issue3945@kolab.org>
Message-ID: <1258375098.5.0.416693360951.issue3945@kolab.org>


New submission from Gunnar Wrobel <p at rdus.de>:

This is primarily a reminder to myself:

The different caching directories Horde uses should be managed in a better way
(as well as the "storage" directory btw). They should get a specific directory
outside of the web root and each type of caching should probably get its own
directory. This makes them safer, their function more obvious and might make it
easier to delete specific cache parts.

----------
assignedto: wrobel
keyword: web client
messages: 22319
nosy: martin, thomas, wilde, wrobel
priority: wish
status: chatting
title: Analyze and split the Horde caching directories

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3945>
______________________________________


From issues at kolab.org  Mon Nov 16 16:49:09 2009
From: issues at kolab.org (Sascha Wilde)
Date: Mon, 16 Nov 2009 15:49:09 +0000
Subject: [Kolab-devel] [issue3946] Send invitations to all attendees? should
	be enabled per	default
In-Reply-To: <1258386549.08.0.900056788517.issue3946@kolab.org>
Message-ID: <1258386549.08.0.900056788517.issue3946@kolab.org>


New submission from Sascha Wilde <wilde at intevation.de>:

See subject.  Its default with the native clients and notifying
attendees is what most users would want to do (and expect to happen
without further afford).

FWIW, when deleting events, informing the other attendees is already
default, so currently this is an inconsistency, but it will not have
to be changed to fix this issue.

----------
assignedto: wrobel
keyword: web client
messages: 22332
nosy: martin, thomas, wilde, wrobel
priority: bug
status: unread
title: Send invitations to all attendees? should be enabled per default

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3946>
______________________________________


From thomas at intevation.de  Mon Nov 16 16:53:06 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Mon, 16 Nov 2009 16:53:06 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <200911152304.44353.ml@radoeka.nl>
References: <20091020172924.577027525.thomas@intevation.de>
	<200910210904.40593.dusty@qwer.tk>
	<200911152304.44353.ml@radoeka.nl>
Message-ID: <20091116165001.775395300.thomas@intevation.de>

* Richard Bos <ml at radoeka.nl> [20091115 23:04]:
> Am Dienstag 20 Oktober 2009 17:34:01 schrieb Thomas Arendsen Hein:
> > Here is a preliminary list of issues we want to address in Kolab
> > Server 2.2.3, we aim to make the release in December:
> 
> For the recent cvs commits that made, I want to update the release-notes file.  
> But the file contains (including line numbers)
>    9 Changes between 2.2.3 and 2.???:
> ......
>  130 Changes between 2.2.2 and 2.2.3:
> 
> But 2.2.3 is not yet released.  Is line 9. correct?

It is correct:

2.2.2 -> 2.2.3 is what has been done in kolab_2_2_branch
2.2.3 -> 2.??? is what has been done in HEAD, but not in kolab_2_2_branch

> I need to add issue3401 and issue3428 for the kolab-webadmin module.  Can you 
> add this information?
> https://issues.kolab.org/issue3401
> https://issues.kolab.org/issue3428

I already wrote in one of these issues that you forgot to update the
release notes. Sorry, I did not see your mail before now.

As your change should be done in HEAD and kolab_2_2_branch, the
issue should be mentioned in the 2.2.2 -> 2.2.3 part in both
branches.

We really should create a contributors guide.

Regards,
Thomas

-- 
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 thomas at intevation.de  Mon Nov 16 17:05:52 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Mon, 16 Nov 2009 17:05:52 +0100
Subject: [Kolab-devel] Kolab Server 2.2.3
In-Reply-To: <200911152328.53646.thomas@btspuhler.com>
References: <20091020172924.577027525.thomas@intevation.de>
	<200911141442.07881.thomas@btspuhler.com>
	<200911152223.48497.ml@radoeka.nl>
	<200911152328.53646.thomas@btspuhler.com>
Message-ID: <20091116170224.275771035.thomas@intevation.de>

* Thomas Spuhler <thomas at btspuhler.com> [20091116 05:29]:
> On Sunday 15 November 2009 04:23:47 pm Richard Bos wrote:
> > Op zaterdag 14 november 2009 22:42:07 schreef Thomas Spuhler:
> > > > Ok, I get a little closer, but I know receive the message that the
> > > > module is already loaded.
> > > > I am not a Perl coder, but it looks is if the code loads it twice
> > > >
> > > > See this http://mandriva.pastebin.fr/6001
> > >
> > >  Ok, I figured this out.
> >
> > What did you make of it?
> >
> > > But the kolabd has a couple line that may be a problem:
> > > . /etc/rc.status
> >
> > No idea where this come from:
> > kolabd> grep -R "rc\.status" *
> > No result, there is no file in the kolabd module that contains sting. 
> > Neither does perl-kolab.
> I am traveling this week and don't have access to my virtual from outside.
> But here is a link that describes it:
> https://wiki.kolab.org/index.php/Init_Script

I think you can ignore that script.

On Debian with OpenPKG packaghes it looks like this:

#!/bin/sh
##
##  kolab -- startup/shutdown transfer script for OpenPKG /kolab hierarchy
##

[ ! -f /kolab/etc/rc ] && exit 0
case $1 in
    start ) exec /kolab/etc/rc all start ;;
    stop  ) exec /kolab/etc/rc all stop  ;;
esac


-- 
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 issues at kolab.org  Mon Nov 16 17:45:40 2009
From: issues at kolab.org (Sascha Wilde)
Date: Mon, 16 Nov 2009 16:45:40 +0000
Subject: [Kolab-devel] [issue3947] Some parts of the Web Client decode
	header lines more	than once
In-Reply-To: <1258389940.24.0.553961200649.issue3947@kolab.org>
Message-ID: <1258389940.24.0.553961200649.issue3947@kolab.org>


New submission from Sascha Wilde <wilde at intevation.de>:

While working on issue3464 I had to learn that some components of the
Web Client decodes mail headers more than once.

The instance I stumbled upon:

When viewing the mail with the double encoded From header in DIMP I
see the (start of the) correct decoded Version:

Sonderzeichen: =?utf-8?b?w6TDtsO8w ...

in the "From" column of the mailbox summary window.  But below in the
mail preview window I see:

from Sonderzeichen: ???????? ??? (NICHT VERTRAUENSW?RDIG, der Absender
<user at example.com> ist nicht authentifiziert) <user at example.com>

so in the later case it seems that the from header has been at least
decoded two times subsequently.  (Though I would tend to suspect that
the decoder runs recursively in this case, but I haven't verified
that.)

This is wrong, the header should be decoded only once in all cases.

More speculation: I wouldn't be surprised if this problem would exist
in more than one place, so once the pattern of the described problem
has been discovered, the rest of the Web Client source should be
searched for it.

----------
assignedto: wrobel
keyword: web client
messages: 22335
nosy: martin, thomas, wilde, wrobel
status: unread
title: Some parts of the Web Client decode header lines more than once

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3947>
______________________________________


From ml at radoeka.nl  Mon Nov 16 19:26:42 2009
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 16 Nov 2009 19:26:42 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <20091116165001.775395300.thomas@intevation.de>
References: <20091020172924.577027525.thomas@intevation.de>
	<200911152304.44353.ml@radoeka.nl>
	<20091116165001.775395300.thomas@intevation.de>
Message-ID: <200911161926.44493.ml@radoeka.nl>

Op maandag 16 november 2009 16:53:06 schreef Thomas Arendsen Hein:
> It is correct:
>
> 2.2.2 -> 2.2.3 is what has been done in kolab_2_2_branch
> 2.2.3 -> 2.??? is what has been done in HEAD, but not in kolab_2_2_branch

Was this announced?  In the past people where against branches as it requires 
more work, so I'm surprised that there is a branch now.  Does kolab-webadmin 
really need a branch?  The changes made to it are not really worth a branch?

-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091116/51b2a983/attachment.html

From wrobel at pardus.de  Mon Nov 16 23:14:06 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 16 Nov 2009 23:14:06 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <200911161926.44493.ml@radoeka.nl>
References: <20091020172924.577027525.thomas@intevation.de>
	<200911152304.44353.ml@radoeka.nl>
	<20091116165001.775395300.thomas@intevation.de>
	<200911161926.44493.ml@radoeka.nl>
Message-ID: <20091116231406.15177j3gfwkq71s8@webmail.pardus.de>

Hi Richard,


Quoting Richard Bos <ml at radoeka.nl>:

> Op maandag 16 november 2009 16:53:06 schreef Thomas Arendsen Hein:
> > It is correct:
> >
> > 2.2.2 -> 2.2.3 is what has been done in kolab_2_2_branch
> > 2.2.3 -> 2.??? is what has been done in HEAD, but not in
> kolab_2_2_branch
>
> Was this announced?

I admit I don't remember. We were probably not loud enough about it.  
But it existed for a while now. Basically all the 2.2.* releases stem  
from it.

> In the past people where against branches
> as it requires more work, so I'm surprised that there is a branch
> now.

We still are. But I introduced many changes in the way the web client  
gets installed and how the PEAR based packages are handled. In  
addition this broke some things and so we decided to have a branch for  
the 2.2.* releases.

But we are aiming at collapsing this to just a single HEAD branch  
right after the 2.2.3 release. We had a meeting last friday where we  
agreed on that.

> Does kolab-webadmin really need a branch?  The changes made
to it are not really worth a branch?

No they are not but we branched the complete CVS and not single directories.

We had another customer related branch at the beginning of this year  
where we only branched some directories but this was not really  
feasible for the 2.2.* branch.

Cheers,

Gunnar

>
> -- 
> Richard

-- 
____ http://www.pardus.de[1] _________________
http://gunnarwrobel.de[2] _

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 <<
--------------------------------------------------------------------

Links:
------
[1] http://www.pardus.de
[2] http://gunnarwrobel.de

-------------- 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/20091116/ae566d4e/attachment.bin

From wrobel at pardus.de  Mon Nov 16 23:29:03 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 16 Nov 2009 23:29:03 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <20091020172924.577027525.thomas@intevation.de>
References: <20091020172924.577027525.thomas@intevation.de>
Message-ID: <20091116232903.184470z9qm8t1cg8@webmail.pardus.de>

Hi,

today it was Kolab_Filter bugfixing day and the list for  
Kolab_Server-2.2.3 should have shortened somewhat more. Here is what  
is left for my side:

Quoting Thomas Arendsen Hein <thomas at intevation.de>:

> Hi!
>
> Here is a preliminary list of issues we want to address in Kolab
> Server 2.2.3, we aim to make the release in December:

[snip]

>
> Gunnar:
>   kolab/issue919  (kolab server has problems with some characters in  
> passwords)
>     (people wanting to use more secure passwords should not be punished)
>   SyncML issues
>
> maybe:
>   kolab/issue3499 (creating/modifying users with special characters  
> in name confuses web admin)
>   kolab/issue3654 (Special character issue in Kolab web interface  
> (e.g. vacation message))
>   kolab/issue2991 (The Kolab web client is always in the privileged networks)
>   kolab/issue3567 (Migrate Horde prefs 2.2.0 -> 2.2.1, 2.2.2)
>     (requested by many people, though not customers)

Should be no problem to get the "must-haves" done in time and I guess  
there will be some additional "maybes", too. Tomorrow will be webadmin  
day and next week I'll play around with SyncML.

Cheers,

Gunnar

-- 
______ 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 <<
--------------------------------------------------------------------

-------------- 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/20091116/b47c78c4/attachment-0001.bin

From thomas at btspuhler.com  Tue Nov 17 02:47:47 2009
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Mon, 16 Nov 2009 20:47:47 -0500
Subject: [Kolab-devel] Kolab Server 2.2.3
In-Reply-To: <20091116170224.275771035.thomas@intevation.de>
References: <20091020172924.577027525.thomas@intevation.de>
	<200911152328.53646.thomas@btspuhler.com>
	<20091116170224.275771035.thomas@intevation.de>
Message-ID: <200911162047.47485.thomas@btspuhler.com>

On Monday 16 November 2009 11:05:52 am Thomas Arendsen Hein wrote:
> * Thomas Spuhler <thomas at btspuhler.com> [20091116 05:29]:
> > On Sunday 15 November 2009 04:23:47 pm Richard Bos wrote:
> > > Op zaterdag 14 november 2009 22:42:07 schreef Thomas Spuhler:
> > > > > Ok, I get a little closer, but I know receive the message that the
> > > > > module is already loaded.
> > > > > I am not a Perl coder, but it looks is if the code loads it twice
> > > > >
> > > > > See this http://mandriva.pastebin.fr/6001
> > > >
> > > >  Ok, I figured this out.
> > >
> > > What did you make of it?
> > >
> > > > But the kolabd has a couple line that may be a problem:
> > > > . /etc/rc.status
> > >
> > > No idea where this come from:
> > > kolabd> grep -R "rc\.status" *
> > > No result, there is no file in the kolabd module that contains sting.
> > > Neither does perl-kolab.
> >
> > I am traveling this week and don't have access to my virtual from
> > outside. But here is a link that describes it:
> > https://wiki.kolab.org/index.php/Init_Script
>
> I think you can ignore that script.
>
> On Debian with OpenPKG packaghes it looks like this:
>
> #!/bin/sh
> ##
> ##  kolab -- startup/shutdown transfer script for OpenPKG /kolab hierarchy
> ##
>
> [ ! -f /kolab/etc/rc ] && exit 0
> case $1 in
>     start ) exec /kolab/etc/rc all start ;;
>     stop  ) exec /kolab/etc/rc all stop  ;;
> esac
The script gets called from kolabsrv as far as I remember, but I can use 
service kolab |start, stop, etc|

Thomas


From wrobel at pardus.de  Tue Nov 17 10:16:26 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 17 Nov 2009 10:16:26 +0100
Subject: [Kolab-devel] Source releases
Message-ID: <20091117101626.13471khe1ga98h6s@webmail.pardus.de>

Hi Thomas,

when we met on Friday we briefly discussed the problem that we still  
move from source to RPMs directly for a few remaining packages. As far  
as I can see these are:

  - perl-kolab
  - kolabd
  - kolab-webadmin

To fix this I think it would be sufficient if you designate a download  
location on files.kolab.org where releases for these packages should  
be provided as tar.gz.

I would then fix the Makefiles of these package to add support for  
this intermediate tar.gz step. I don't think the first tar.gz's will  
be beautiful but it will be better than nothing.

Cheers,

Gunnar

-- 
______ 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 <<
--------------------------------------------------------------------

-------------- 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/20091117/c1f29543/attachment.bin

From ml at radoeka.nl  Tue Nov 17 10:48:00 2009
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 17 Nov 2009 10:48:00 +0100
Subject: [Kolab-devel] Source releases
In-Reply-To: <20091117101626.13471khe1ga98h6s@webmail.pardus.de>
References: <20091117101626.13471khe1ga98h6s@webmail.pardus.de>
Message-ID: <20091117094800.GA22584@xs4all.nl>

Hi Gunnar,

On Tue, Nov 17, 2009 at 10:16:26AM +0100, Gunnar Wrobel wrote:
> Hi Thomas,
> 
> when we met on Friday we briefly discussed the problem that we still  
> move from source to RPMs directly for a few remaining packages. As far  
> as I can see these are:
> 
>  - perl-kolab
>  - kolabd
>  - kolab-webadmin
> 
> To fix this I think it would be sufficient if you designate a download  
> location on files.kolab.org where releases for these packages should  
> be provided as tar.gz.
> 
> I would then fix the Makefiles of these package to add support for  
> this intermediate tar.gz step. I don't think the first tar.gz's will  
> be beautiful but it will be better than nothing.

This is already possible for kolabd and kolab-webadmin (for a few year ;) ),
and the tarbals are beautiful.  Try:


kolab-webadmin> ./bootstrap; ./configure; make distcheck

The result is:
======================================================
kolab-webadmin-2.2.2 archives ready for distribution:
kolab-webadmin-2.2.2.tar.bz2
======================================================

The same is valid for kolabd.

Have fun :)

-- 
Richard


From wrobel at pardus.de  Tue Nov 17 11:04:01 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 17 Nov 2009 11:04:01 +0100
Subject: [Kolab-devel] Source releases
In-Reply-To: <20091117094800.GA22584@xs4all.nl>
References: <20091117101626.13471khe1ga98h6s@webmail.pardus.de>
	<20091117094800.GA22584@xs4all.nl>
Message-ID: <20091117110401.18966mpcv51wdyos@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Hi Gunnar,
>
> On Tue, Nov 17, 2009 at 10:16:26AM +0100, Gunnar Wrobel wrote:
>> Hi Thomas,
>>
>> when we met on Friday we briefly discussed the problem that we still
>> move from source to RPMs directly for a few remaining packages. As far
>> as I can see these are:
>>
>>  - perl-kolab
>>  - kolabd
>>  - kolab-webadmin
>>
>> To fix this I think it would be sufficient if you designate a download
>> location on files.kolab.org where releases for these packages should
>> be provided as tar.gz.
>>
>> I would then fix the Makefiles of these package to add support for
>> this intermediate tar.gz step. I don't think the first tar.gz's will
>> be beautiful but it will be better than nothing.
>
> This is already possible for kolabd and kolab-webadmin (for a few year ;) ),
> and the tarbals are beautiful.  Try:
>
>
> kolab-webadmin> ./bootstrap; ./configure; make distcheck
>
> The result is:
> ======================================================
> kolab-webadmin-2.2.2 archives ready for distribution:
> kolab-webadmin-2.2.2.tar.bz2
> ======================================================
>
> The same is valid for kolabd.

Yes, but we don't distribute them and I consider that necessary. And  
I'd never say that kolabd or kolab-webadmin are "nice" packages. But  
I'm a packaging fanatic anyway so that doesn't have to be taken too  
serious ;)

Cheers,

Gunnar

>
> Have fun :)
>
> --
> Richard
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
____ 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 <<
--------------------------------------------------------------------

-------------- 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/20091117/66f12ea9/attachment.bin

From thomas at intevation.de  Tue Nov 17 11:06:49 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Tue, 17 Nov 2009 11:06:49 +0100
Subject: [Kolab-devel] Source releases
In-Reply-To: <20091117101626.13471khe1ga98h6s@webmail.pardus.de>
References: <20091117101626.13471khe1ga98h6s@webmail.pardus.de>
Message-ID: <20091117103319.732447684.thomas@intevation.de>

* Gunnar Wrobel <wrobel at pardus.de> [20091117 10:16]:
> when we met on Friday we briefly discussed the problem that we still  
> move from source to RPMs directly for a few remaining packages. As far  
> as I can see these are:
>
>  - perl-kolab
>  - kolabd
>  - kolab-webadmin
>
> To fix this I think it would be sufficient if you designate a download  
> location on files.kolab.org where releases for these packages should be 
> provided as tar.gz.

Maybe a folder next to ix86-debian4.0, ix86-debian5.0 and sources?

Of course "sources" would be the perfect name, but this is already
taken for the OpenPKG .src.rpm packages.

Sascha proposed "tars" and I second that.

The alternative would be to move the OpenPKG directories into a
separate directory, but I'd say such restructuring should wait until
we have to reorganize the directory layout for other reasons anyway.

Regards,
Thomas

-- 
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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091117/2d0c5814/attachment.bin

From wrobel at pardus.de  Tue Nov 17 11:19:10 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 17 Nov 2009 11:19:10 +0100
Subject: [Kolab-devel] Source releases
In-Reply-To: <20091117103319.732447684.thomas@intevation.de>
References: <20091117101626.13471khe1ga98h6s@webmail.pardus.de>
	<20091117103319.732447684.thomas@intevation.de>
Message-ID: <20091117111910.20185wzjs8cxy3s4@webmail.pardus.de>

Quoting Thomas Arendsen Hein <thomas at intevation.de>:

> * Gunnar Wrobel <wrobel at pardus.de> [20091117 10:16]:
>> when we met on Friday we briefly discussed the problem that we still
>> move from source to RPMs directly for a few remaining packages. As far
>> as I can see these are:
>>
>>  - perl-kolab
>>  - kolabd
>>  - kolab-webadmin
>>
>> To fix this I think it would be sufficient if you designate a download
>> location on files.kolab.org where releases for these packages should be
>> provided as tar.gz.
>
> Maybe a folder next to ix86-debian4.0, ix86-debian5.0 and sources?
>
> Of course "sources" would be the perfect name, but this is already
> taken for the OpenPKG .src.rpm packages.
>
> Sascha proposed "tars" and I second that.

+1

>
> The alternative would be to move the OpenPKG directories into a
> separate directory, but I'd say such restructuring should wait until
> we have to reorganize the directory layout for other reasons anyway.
>
> Regards,
> Thomas
>
> --
> 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
>



-- 
____ 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 <<
--------------------------------------------------------------------



From wilde at intevation.de  Tue Nov 17 16:36:21 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Tue, 17 Nov 2009 16:36:21 +0100
Subject: [Kolab-devel] Brain Dump of the Week: Ideas, Plans and Realities ...
Message-ID: <s7w8we5rwne.fsf@intevation.de>

Hi *,

with this mail I want to give a short report at the current plans and
ideas for Kolab Server and results from the meeting Gunnar, Thomas,
Bernhard (Reiter) and I had last Friday.

Originally I would have loved to write this mail earlier and I would
like to write mails like this (giving some sort of Kolab Server related
"Brain Dump of the Week") way more often, but there is this little
thingy from the subject: reality (you know, it bites)...

Anyways, whats worth reporting?


1. Release Plans

As most developers will have noticed by now: we currently have two
active branches in the server CVS, HEAD and 2.2.x (called
kolab_2_2_branch).  How comes?  Well, like most things in live it just
happened.  ;-)

The main reason is, that Gunnar, to resolve
https://issues.kolab.org/issue3293 had to do some major reorganization
in HEAD, which lead to an rather unstable state for some time and so
we decided to create an (temporary) stable branch, which we could use to
make subsequent 2.2.x releases.

It comes to no surprise that now, that HEAD is reasonable stable to
continue development there, we have a bunch of changes and fixes in the
2.2.x branch only, which we will need to merge -- which in turn made us
wonder if this strategy was a good idea in the first place and if it
wouldn't be best to throw HEAD away and simply re-implement the made
improvements in the 2.2.x branch.  @-)

None the less we made the following decision:

- As already announced by Thomas: the next release will be 2.2.3 and
  made from kolab_2_2_branch

- Starting in parallel, and with highest priority after the 2.2.3
  release, we will merge everything to HEAD and make it the main (and
  hopefully only) development branch again.


2. Packaging and Distribution Future

The current official and only commercially supported platform for Kolab
is OpenPKG -- unfortunately the future of OpenPKG, technically and
politically (read business model), is unknown -- at least to us.  On the
other hand there is the contributed native packaging of Kolab server for
many distributions, with varying grades of functionality and stability.

Currently we are not sure what to make of all this.  It is clear that we
will continue to need one defined distribution with stability and
support standards for our enterprise business -- but this might not
necessary be OpenPKG for ever.  Besides this we want to make Kolab
server as attractive and easy to setup for users and developers as
possible, which not at least would mean to support good native
packaging, but once again the strategy how to achieve this with limited
resources is work in progress.

One thing we agreed upon is, that it would be nice to have all the
sources in a none discriminating package format (can you say "tar"?)
available, distributed and build able, so that one could easily build
Kolab server without having the pre-requisite of OpenPKG -- Gunnar
recently started a thread on this topic.


3. The Web Client

The current web client was a big step forward as it finally gave all
those who can't install an native Kolab client on there systems the
opportunity to joint he happy community of Kolab users.  But lets face
it, the current web client is no beauty queen and the user experience is
not comparable neither to the native clients, nor to the fancy web
clients of other systems (have you seen the zarafa client?).

Well, we had some talking on this and basically we all agreed that we
need some major improvement on this sector (which btw. includes the Web
Admin interface and the Free Busy View, too).  Currently the discussion
is open what the best strategy for the future will be, basically there
are two major options:

- Keep horde as basis for the web client, which would include the switch
  to horde 4.  As there is very little hope that the horde project will
  come up with a polished and shiny modern UI anytime soon, this would
  mean that we will have to invest a serious amount of time and work our
  self to contribute what would basically be a complete new horde UI.

- Alternative: ditch Horde for the web client part (we would keep some
  horde parts for the server functionality like Kolab Filter and Free
  Busy) and pull another, more fancy free software web client into the
  Kolab project.  This would of cause mean to heavily extend what ever
  candidate would be chosen, as currently none of the other web clients
  offers even near complete Kolab support...

The suggestion has been made to take the administrative (web admin)
interface as a kind of playground to test out our capabilities of
creating an modern, appealing and user friendly web UI.

In any case this will be one of the more exciting areas in midterm Kolab
server development.  We are looking forward to your comments...


4. More to Come

Finally there are some more exciting thing going on behind the scenes
which I can't tell you about currently -- stay tuned!  ;-)


That's all folks!
cheers
sascha

PS. Ok, it seems I failed in my attempt to give a _short_ report -- I'll
    try to be more concise next time...
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091117/86ae27b8/attachment.bin

From wilde at intevation.de  Tue Nov 17 16:59:36 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Tue, 17 Nov 2009 16:59:36 +0100
Subject: [Kolab-devel] Source releases
In-Reply-To: <20091117111910.20185wzjs8cxy3s4@webmail.pardus.de> (Gunnar
	Wrobel's message of "Tue, 17 Nov 2009 11:19:10 +0100")
References: <20091117101626.13471khe1ga98h6s@webmail.pardus.de>
	<20091117103319.732447684.thomas@intevation.de>
	<20091117111910.20185wzjs8cxy3s4@webmail.pardus.de>
Message-ID: <s7w4ootrvkn.fsf@intevation.de>

Gunnar Wrobel <wrobel at pardus.de> writes:
> Quoting Thomas Arendsen Hein <thomas at intevation.de>:
>> * Gunnar Wrobel <wrobel at pardus.de> [20091117 10:16]:
[...]
>>> To fix this I think it would be sufficient if you designate a download
>>> location on files.kolab.org where releases for these packages should be
>>> provided as tar.gz.
>>
>> Maybe a folder next to ix86-debian4.0, ix86-debian5.0 and sources?
>>
>> Of course "sources" would be the perfect name, but this is already
>> taken for the OpenPKG .src.rpm packages.
>>
>> Sascha proposed "tars" and I second that.
>
> +1

Hurray, so all that's left to do is to build the tars, write and test an
INSTALL script and push all this up to files.kolab.org...  ;-)

cheers
sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091117/22005d15/attachment.bin

From thomas at intevation.de  Tue Nov 17 17:18:25 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Tue, 17 Nov 2009 17:18:25 +0100
Subject: [Kolab-devel] Kolab Security Issue 25 20091117 (clamav)
Message-ID: <20091117165959.977268444.thomas@intevation.de>

Kolab Security Issue 25 20091117
================================

Package:              Kolab Server, ClamAV
Vulnerability:        various
Kolab Specific:       no
Dependent Packages:   none


Summary
~~~~~~~

ClamAV is prone to multiple vulnerabilities because it fails to properly
restrict certain files after scanning them. A successful attack may allow
malicious users to bypass security restrictions placed on certain files.

Further unpublished vulnerabilities may habe been fixed.


Affected Versions
~~~~~~~~~~~~~~~~~

This affects versions of ClamAV up to version 0.95.1
Kolab Server 2.2.2 and previous releases are affected.


Fix
~~~

Upgrade to ClamAV 0.95.3.

OpenPKG packages for Kolab Server 2.2.2 are available from
http://files.kolab.org/server/security-updates/20091117/
or from the mirrors listed on http://kolab.org/mirrors.html

A binary RPM for Kolab Server 2.2.2 (ix86 Debian GNU/Linux Lenny)
is available as clamav-0.95.3-20091030.ix86-debian5.0-kolab.rpm

A binary RPM for Kolab Server 2.2.2 (ix86 Debian GNU/Linux Etch)
is available as clamav-0.95.3-20091030.ix86-debian4.0-kolab.rpm

The source and binary packages have been verified to work with Kolab Server
2.2.0, so you can upgrade this package without doing a full upgrade.

All other server versions: Please upgrade to Kolab Server 2.2.x and install
the updated package.


You can check the integrity of the downloaded files with:

$ gpg --keyserver keys.gnupg.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


The source package can be compiled and installed on your Kolab Server with:

# su - kolab
$ openpkg rpm --rebuild ...path/to.../clamav-0.95.3-20091030.src.rpm
$ openpkg rpm -Uvh /kolab/RPM/PKG/clamav-0.95.3-20091030.<ARCH>-<OS>-kolab.rpm
$ rm /kolab/etc/clamav/*.rpmsave
$ openpkg rc clamav stop
$ openpkg rc clamav start
$ exit
# su - kolab-r
$ freshclam
$ rm -r /kolab/share/clamav/*.inc

To install a binary package, just skip the --rebuild step.


Details
~~~~~~~

http://sourceforge.net/project/shownotes.php?release_id=688880
	ClamAV 0.95.2 release notes

(bugfix release, only the ChangeLog has been published)
	ClamAV 0.95.3 release notes

http://www.securityfocus.com/bid/35426
	ClamAV CAB/RAR/ZIP File Scan Evasion Vulnerability

http://www.securityfocus.com/bid/35398
	ClamAV Embedded Archive File Scan Evasion Vulnerability

http://www.securityfocus.com/bid/35410
	ClamAV Prior to 0.95.2 Multiple Scanner Bypass Vulnerabilities


Timeline
~~~~~~~~
    20090610 ClamAV release 0.95.2.
    20091028 ClamAV release 0.95.3.
    20091030 Update available via Kolab CVS, started testing.
    20091117 Kolab Server security advisory published.

-- 
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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091117/5c42abb3/attachment.bin

From wilde at intevation.de  Tue Nov 17 17:21:19 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Tue, 17 Nov 2009 17:21:19 +0100
Subject: [Kolab-devel] Source releases
In-Reply-To: <s7w4ootrvkn.fsf@intevation.de> (Sascha Wilde's message of "Tue, 
	17 Nov 2009 16:59:36 +0100")
References: <20091117101626.13471khe1ga98h6s@webmail.pardus.de>
	<20091117103319.732447684.thomas@intevation.de>
	<20091117111910.20185wzjs8cxy3s4@webmail.pardus.de>
	<s7w4ootrvkn.fsf@intevation.de>
Message-ID: <s7wzl6lqg00.fsf@intevation.de>

Sascha Wilde <wilde at intevation.de> writes:
> Hurray, so all that's left to do is to build the tars, write and test an
> INSTALL script and push all this up to files.kolab.org...  ;-)

Ooops, I mean INSTALL text, documenting it should be enough for now.

sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091117/ceef5e6e/attachment.bin

From ml at radoeka.nl  Tue Nov 17 18:47:03 2009
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 17 Nov 2009 18:47:03 +0100
Subject: [Kolab-devel] Source releases
In-Reply-To: <20091117103319.732447684.thomas@intevation.de>
References: <20091117101626.13471khe1ga98h6s@webmail.pardus.de>
	<20091117103319.732447684.thomas@intevation.de>
Message-ID: <200911171847.03836.ml@radoeka.nl>

Op dinsdag 17 november 2009 11:06:49 schreef Thomas Arendsen Hein:
> Sascha proposed "tars" and I second that.

<smile>
or perhaps tears ;)
</smile>

-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091117/5f051dc7/attachment.html

From math.parent at gmail.com  Tue Nov 17 19:35:16 2009
From: math.parent at gmail.com (Mathieu Parent)
Date: Tue, 17 Nov 2009 19:35:16 +0100
Subject: [Kolab-devel] Source releases
In-Reply-To: <20091117111910.20185wzjs8cxy3s4@webmail.pardus.de>
References: <20091117101626.13471khe1ga98h6s@webmail.pardus.de>
	<20091117103319.732447684.thomas@intevation.de>
	<20091117111910.20185wzjs8cxy3s4@webmail.pardus.de>
Message-ID: <960738410911171035p333b3939sa7362a47fb008337@mail.gmail.com>

Hello,


On Tue, Nov 17, 2009 at 11:19 AM, Gunnar Wrobel <wrobel at pardus.de> wrote:
> Quoting Thomas Arendsen Hein <thomas at intevation.de>:
>
>> * Gunnar Wrobel <wrobel at pardus.de> [20091117 10:16]:
>>> when we met on Friday we briefly discussed the problem that we still
>>> move from source to RPMs directly for a few remaining packages. As far
>>> as I can see these are:
>>>
>>> ?- perl-kolab
>>> ?- kolabd
>>> ?- kolab-webadmin
>>>
>>> To fix this I think it would be sufficient if you designate a download
>>> location on files.kolab.org where releases for these packages should be
>>> provided as tar.gz.
>>
>> Maybe a folder next to ix86-debian4.0, ix86-debian5.0 and sources?
>>
>> Of course "sources" would be the perfect name, but this is already
>> taken for the OpenPKG .src.rpm packages.
>>
>> Sascha proposed "tars" and I second that.
>
> +1

+1

Can we also have nightly (or weekly) snapshots ?

NB: We currently use src.rpm as source for Debian native with a
converter script (see for example:
http://svn.debian.org/wsvn/pkg-kolab/kolabd/trunk/debian/uupdate-wrapper)

>>
>> The alternative would be to move the OpenPKG directories into a
>> separate directory, but I'd say such restructuring should wait until
>> we have to reorganize the directory layout for other reasons anyway.
>>
>> Regards,
>> Thomas

Mathieu Parent


From ml at radoeka.nl  Tue Nov 17 22:47:03 2009
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 17 Nov 2009 22:47:03 +0100
Subject: [Kolab-devel] Brain Dump of the Week: Ideas,
	Plans and Realities ...
In-Reply-To: <s7w8we5rwne.fsf@intevation.de>
References: <s7w8we5rwne.fsf@intevation.de>
Message-ID: <200911172247.05037.ml@radoeka.nl>

Hi,

Op dinsdag 17 november 2009 16:36:21 schreef Sascha Wilde:
> with this mail I want to give a short report at the current plans and
> ideas for Kolab Server and results from the meeting Gunnar, Thomas,
> Bernhard (Reiter) and I had last Friday.
>
> Originally I would have loved to write this mail earlier and I would
> like to write mails like this (giving some sort of Kolab Server related
> "Brain Dump of the Week") way more often, but there is this little
> thingy from the subject: reality (you know, it bites)...

Very good.  Almost like a blog :)  When is planet.kolab.org going to arrive ;)


> Anyways, whats worth reporting?
>
>
> 1. Release Plans

skipped this part.  Looks like it is in good hands.


> 2. Packaging and Distribution Future
>
> The current official and only commercially supported platform for Kolab
> is OpenPKG -- unfortunately the future of OpenPKG, technically and
> politically (read business model), is unknown -- at least to us.  On the
> other hand there is the contributed native packaging of Kolab server for
> many distributions, with varying grades of functionality and stability.
>
> Currently we are not sure what to make of all this.  It is clear that we
> will continue to need one defined distribution with stability and
> support standards for our enterprise business -- but this might not
> necessary be OpenPKG for ever.  Besides this we want to make Kolab
> server as attractive and easy to setup for users and developers as
> possible, which not at least would mean to support good native
> packaging, but once again the strategy how to achieve this with limited
> resources is work in progress.

May I point your attention to the openSUSE build service?  Contrary its name, 
the build service is for all mainstream distributions, like the rpm based 
Fedora, Mandrake, Centos and of course openSUSE.  Different rpm distros, but 
at the same with the same sources and in the same repository, packages can be 
build for deb based distributions like: Debian and Ubuntu!  The build service 
uses 1 spec (and a deb control) file, to build packages for different versions 
and architectures of the before mentioned distributions.  The result can look 
like this:
http://download.opensuse.org/repositories/openSUSE:/Tools/
or especially kolab related:
http://download.opensuse.org/repositories/server:/Kolab:/UNSTABLE/

The build service is made so people can Kollaborate in building packages.  The 
service can be accessed with a command line client, that works like cvs / svn.  
But at the same time there is a web interface available.  It all works rather 
intuitive and is very user friendly :)  and oh, the builds can be tested local 
first, and if all works fine the changes can be committed to the repository.

If that is not enough the end product are not only packages, it is also 
possible to define an image (called kiwi) for a live Disc or memory stick.  To 
test the build service you need to ask for account on the build service.  
After that I can e.g. add you to the Kolab repository as maintainer.  The 
sources for the build services are fully open source and packages can be 
downloaded from the build service.  So it can also be used "in house".

openSUSE (being the payed engineers of openSUSE and the community packagers) 
uses it to build its entire distribution with it, hence it is very well 
maintained.

I really hope that you have a look at this superb service, it's very powerful 
and it is a relieve to be able to build packages for many distribution 
versions at 1 time.  More information can be obtained from:
http://en.opensuse.org/Build_Service or from me ;)


> One thing we agreed upon is, that it would be nice to have all the
> sources in a none discriminating package format (can you say "tar"?)
> available, distributed and build able, so that one could easily build
> Kolab server without having the pre-requisite of OpenPKG -- Gunnar
> recently started a thread on this topic.

See above.  The build service does not have an openpkg repository.  That would 
have been nice.   I think that it is a bit hard to set up, besides that it is 
not very known.


> 3. The Web Client
>
> The current web client was a big step forward as it finally gave all
> those who can't install an native Kolab client on there systems the
> opportunity to joint he happy community of Kolab users.  But lets face
> it, the current web client is no beauty queen and the user experience is
> not comparable neither to the native clients, nor to the fancy web
> clients of other systems (have you seen the zarafa client?).
>
> Well, we had some talking on this and basically we all agreed that we
> need some major improvement on this sector (which btw. includes the Web
> Admin interface and the Free Busy View, too).  Currently the discussion
> is open what the best strategy for the future will be, basically there
> are two major options:
>
> - Keep horde as basis for the web client, which would include the switch
>   to horde 4.  As there is very little hope that the horde project will
>   come up with a polished and shiny modern UI anytime soon, this would
>   mean that we will have to invest a serious amount of time and work our
>   self to contribute what would basically be a complete new horde UI.

What do you mean with a polished and shiny UI?  Do you mean that the Horde-4 
won't provide e.g. the Silver theme (the one that kolab-webclient uses now)? 
What is the current state of Horde-4?  Will it be available in 2010 (what 
quarter).  Will it be easier to package (rpm / deb), than it used to be?
If Horde-4 meets its promises, it should be easy to connect / integrate 
Horde-4 with kolab server.  If that is the case the kolab project gets a nice 
web interface almost for free.  Its perhaps not as shiny as the Zarafa or the 
Google mail GUI, but it is still a nice GUI.

If the Horde project will not come up with a polished GUI, ain't it possible 
that kolab project adds this to the Horde project?  That way both projects 
benefit, isn't it?  Building a GUI from the bottom up, is a hell of a job I 
imagine.


> - Alternative: ditch Horde for the web client part (we would keep some
>   horde parts for the server functionality like Kolab Filter and Free
>   Busy) and pull another, more fancy free software web client into the
>   Kolab project.  This would of cause mean to heavily extend what ever
>   candidate would be chosen, as currently none of the other web clients
>   offers even near complete Kolab support...
>
> The suggestion has been made to take the administrative (web admin)
> interface as a kind of playground to test out our capabilities of
> creating an modern, appealing and user friendly web UI.

I have always thought of moving kolab-webadmin into horde as that interface is 
nicer, prettier than kolab-webadmin....


> In any case this will be one of the more exciting areas in midterm Kolab
> server development.  We are looking forward to your comments...

I'm surprised that you're thinking of ditching horde.  Assuming that Horde-4 
delivers what we expect ;) Horde-4 provides a nice and good webinterface to 
the kolab server almost for free.  So, put at least the effort in getting 
Horde-4 connected with the kolab server, and maintain.  After effort can be 
put into another fancier webclient.


> 4. More to Come
>
> Finally there are some more exciting thing going on behind the scenes
> which I can't tell you about currently -- stay tuned!  ;-)

I do :)

> That's all folks!
> cheers
> sascha
>
> PS. Ok, it seems I failed in my attempt to give a _short_ report -- I'll
>     try to be more concise next time...

Thanks a lot for your post, it very much appreciated.

Next time a blog maybe?  So it can be linked from major OSS news sites....  Or 
is this http://kolab.wordpress.com/ your blog already ;)


-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091117/c87b0bd4/attachment.html

From wilde at intevation.de  Wed Nov 18 10:52:54 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Wed, 18 Nov 2009 10:52:54 +0100
Subject: [Kolab-devel] Brain Dump of the Week: Ideas,
	Plans and Realities ...
In-Reply-To: <200911172247.05037.ml@radoeka.nl> (Richard Bos's message of
	"Tue, 17 Nov 2009 22:47:03 +0100")
References: <s7w8we5rwne.fsf@intevation.de> <200911172247.05037.ml@radoeka.nl>
Message-ID: <s7wpr7gyxah.fsf@intevation.de>

Richard Bos <ml at radoeka.nl> writes:
> Op dinsdag 17 november 2009 16:36:21 schreef Sascha Wilde:

>> 2. Packaging and Distribution Future
[...]
> May I point your attention to the openSUSE build service?  Contrary its name, 
> the build service is for all mainstream distributions, like the rpm based 
> Fedora, Mandrake, Centos and of course openSUSE. 

Thanks for your input.  I don't know the openSUSE build service, so I'm
currently not really qualified to judge it -- from what you wrote I have
to admit that it sound interesting but at the same time I'm not sure if
it really addresses our primary problems.

I'll have a look at it (just a matter of having reasonable time, as always).

[...]
>> One thing we agreed upon is, that it would be nice to have all the
>> sources in a none discriminating package format (can you say "tar"?)
>> available, distributed and build able, so that one could easily build
>> Kolab server without having the pre-requisite of OpenPKG -- Gunnar
>> recently started a thread on this topic.
>
> See above.  The build service does not have an openpkg repository.  That would 
> have been nice.   I think that it is a bit hard to set up, besides that it is 
> not very known.

I'm not sure how your comment relates to the paragraph above, I was
talking on classical tar packaging, not OpenPKG -- or are you saying we
would need the tars to use the build service?

[...]
>> - Keep horde as basis for the web client, which would include the switch
>>   to horde 4.  As there is very little hope that the horde project will
>>   come up with a polished and shiny modern UI anytime soon, this would
>>   mean that we will have to invest a serious amount of time and work our
>>   self to contribute what would basically be a complete new horde UI.
>
> What do you mean with a polished and shiny UI?

I mean a UI that can compete with other groupware web clients, in terms
of the user experience.  That means: interactivity, speed and a modern
look and feel.  Good web applications these days do nearly match native
clients in these respects.  Users (and customers for that matter) know
this, they have seen and often used web applications like those of
google, zarafa or open-exchange for example and they expect us to
provide something comparable.

> Do you mean that the Horde-4 won't provide e.g. the Silver theme (the
> one that kolab-webclient uses now)?

No, I mean that Horde-4 will not be up to pair with modern web
interfaces with regard to the UI.

It is said that there will be a new dynamic calendar component, but I
haven't seen it my self yet.  I hope this will be an major improvement
(the current calendar component is very cumbersome to use), but even
then I doubt that the over all user experience will be competitive.

> What is the current state of Horde-4?  Will it be available in 2010 (what 
> quarter).

I don't know -- to my understanding "its ready when its ready".  And
realistically we will not be able to switch the client to Horde4 before 2011...

> Will it be easier to package (rpm / deb), than it used to be?
> If Horde-4 meets its promises, it should be easy to connect / integrate 
> Horde-4 with kolab server.  If that is the case the kolab project gets a nice 
> web interface almost for free.  Its perhaps not as shiny as the Zarafa or the 
> Google mail GUI, but it is still a nice GUI.

I don't know what promises are really made by Horde-4, maybe Gunnar can
give some detailed answers here.  Regarding the GUI we have reasonable
doubts that it will be nice enough to meet the expectations of nowadays
users.

> If the Horde project will not come up with a polished GUI, ain't it possible 
> that kolab project adds this to the Horde project?  That way both projects 
> benefit, isn't it? 

That would be exactly the thing to do!  I thought that was what I
wrote... ;-)

> Building a GUI from the bottom up, is a hell of a job I imagine.

I don't know the current state of Horde-4, but yes, "a hell of a job"
describes very well what I expect to be necessary.

[...]
>> The suggestion has been made to take the administrative (web admin)
>> interface as a kind of playground to test out our capabilities of
>> creating an modern, appealing and user friendly web UI.
>
> I have always thought of moving kolab-webadmin into horde as that interface is 
> nicer, prettier than kolab-webadmin....

That's one possible strategy, which will be evaluated.

>> In any case this will be one of the more exciting areas in midterm Kolab
>> server development.  We are looking forward to your comments...
>
> I'm surprised that you're thinking of ditching horde.  Assuming that Horde-4 
> delivers what we expect ;)

Well, maybe you expect more than we do.  To make it completely clear: we
are just thinking, and we allow our self to think even of drastic
changes, as what we are longing for is a drastic improvement.  But no
decision has been made yet.

>> PS. Ok, it seems I failed in my attempt to give a _short_ report -- I'll
>>     try to be more concise next time...
>
> Thanks a lot for your post, it very much appreciated.
>
> Next time a blog maybe?  So it can be linked from major OSS news sites....  Or 
> is this http://kolab.wordpress.com/ your blog already ;)

To make a long story short: I'm no blog guy.  ;-)
And I like mail much better to carry on upcoming discussions than blog
comments.

Besides: I see the mailing list as primary place for developer
communication.  And its archived, so you can always link to interesting
mails (or the whole archive) if you like...

cheers
sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091118/5f6e2c5a/attachment-0001.bin

From wilde at intevation.de  Wed Nov 18 11:03:50 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Wed, 18 Nov 2009 11:03:50 +0100
Subject: [Kolab-devel] Source releases
In-Reply-To: <960738410911171035p333b3939sa7362a47fb008337@mail.gmail.com>
	(Mathieu Parent's message of "Tue, 17 Nov 2009 19:35:16 +0100")
References: <20091117101626.13471khe1ga98h6s@webmail.pardus.de>
	<20091117103319.732447684.thomas@intevation.de>
	<20091117111910.20185wzjs8cxy3s4@webmail.pardus.de>
	<960738410911171035p333b3939sa7362a47fb008337@mail.gmail.com>
Message-ID: <s7wlji4yws9.fsf@intevation.de>

Mathieu Parent <math.parent at gmail.com> writes:
> On Tue, Nov 17, 2009 at 11:19 AM, Gunnar Wrobel <wrobel at pardus.de> wrote:
>> Quoting Thomas Arendsen Hein <thomas at intevation.de>:
>>> * Gunnar Wrobel <wrobel at pardus.de> [20091117 10:16]:
[...]
>>>> To fix this I think it would be sufficient if you designate a download
>>>> location on files.kolab.org where releases for these packages should be
>>>> provided as tar.gz.
>>>
>>> Maybe a folder next to ix86-debian4.0, ix86-debian5.0 and sources?
>>>
>>> Of course "sources" would be the perfect name, but this is already
>>> taken for the OpenPKG .src.rpm packages.
>>>
>>> Sascha proposed "tars" and I second that.
>>
>> +1
>
> +1

On a second thought we might need at least two sub directories?

tars/kolab     # our stuff, that is: 
               # - original packages from the cvs as for example kolabd
               #   and web admin,
               # - patches to external packages (imapd, php, ...)
               # - repackaged external stuff, so heavily patched that
               #   providing patches is not useful (e.g. the webclient
               #   in the current state?  Not sure on this...)

tars/prereq    # unchanged external stuff, that is needed by Kolab
               # Server and not easy to get, like all the Horde
               # PEAR-stuff in the required versions.

Any thoughts?

sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091118/878ce147/attachment.bin

From thomas at intevation.de  Wed Nov 18 11:46:38 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Wed, 18 Nov 2009 11:46:38 +0100
Subject: [Kolab-devel] Source releases
In-Reply-To: <s7wlji4yws9.fsf@intevation.de>
References: <20091117101626.13471khe1ga98h6s@webmail.pardus.de>
	<20091117103319.732447684.thomas@intevation.de>
	<20091117111910.20185wzjs8cxy3s4@webmail.pardus.de>
	<960738410911171035p333b3939sa7362a47fb008337@mail.gmail.com>
	<s7wlji4yws9.fsf@intevation.de>
Message-ID: <20091118114407.529804857.thomas@intevation.de>

* Sascha Wilde <wilde at intevation.de> [20091118 11:03]:
> On a second thought we might need at least two sub directories?
> 
> tars/kolab     # our stuff, that is: 
>                # - original packages from the cvs as for example kolabd
>                #   and web admin,
>                # - patches to external packages (imapd, php, ...)
>                # - repackaged external stuff, so heavily patched that
>                #   providing patches is not useful (e.g. the webclient
>                #   in the current state?  Not sure on this...)
> 
> tars/prereq    # unchanged external stuff, that is needed by Kolab
>                # Server and not easy to get, like all the Horde
>                # PEAR-stuff in the required versions.
> 
> Any thoughts?

Yes: No.

We already have development-2.2/externals for this and I don't think
that it is a good idea to collect the prereqs per minor version (or
rc/beta/alpha), but only per major development branch.

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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091118/d6ea9b2f/attachment.bin

From wilde at intevation.de  Wed Nov 18 12:39:48 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Wed, 18 Nov 2009 12:39:48 +0100
Subject: [Kolab-devel] Source releases
In-Reply-To: <20091118114407.529804857.thomas@intevation.de> (Thomas Arendsen
	Hein's message of "Wed, 18 Nov 2009 11:46:38 +0100")
References: <20091117101626.13471khe1ga98h6s@webmail.pardus.de>
	<20091117103319.732447684.thomas@intevation.de>
	<20091117111910.20185wzjs8cxy3s4@webmail.pardus.de>
	<960738410911171035p333b3939sa7362a47fb008337@mail.gmail.com>
	<s7wlji4yws9.fsf@intevation.de>
	<20091118114407.529804857.thomas@intevation.de>
Message-ID: <s7w8we4yscb.fsf@intevation.de>

Thomas Arendsen Hein <thomas at intevation.de> writes:
> * Sascha Wilde <wilde at intevation.de> [20091118 11:03]:
>> On a second thought we might need at least two sub directories?
>>
>> tars/kolab
>> tars/prere

>> Any thoughts?
>
> Yes: No.
>
> We already have development-2.2/externals for this and I don't think
> that it is a good idea to collect the prereqs per minor version (or
> rc/beta/alpha), but only per major development branch.

Ok, I agree.  I forgot that we already have a place for external tars on
files.kolab.org.

cheers
sascha
--
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091118/85e2f34a/attachment.bin

From ml at radoeka.nl  Wed Nov 18 23:09:08 2009
From: ml at radoeka.nl (Richard Bos)
Date: Wed, 18 Nov 2009 23:09:08 +0100
Subject: [Kolab-devel] Brain Dump of the Week: Ideas,
	Plans and Realities ...
In-Reply-To: <s7wpr7gyxah.fsf@intevation.de>
References: <s7w8we5rwne.fsf@intevation.de> <200911172247.05037.ml@radoeka.nl>
	<s7wpr7gyxah.fsf@intevation.de>
Message-ID: <200911182309.09092.ml@radoeka.nl>

Op woensdag 18 november 2009 10:52:54 schreef Sascha Wilde:
> Richard Bos <ml at radoeka.nl> writes:
> > Op dinsdag 17 november 2009 16:36:21 schreef Sascha Wilde:
> >> One thing we agreed upon is, that it would be nice to have all the
> >> sources in a none discriminating package format (can you say "tar"?)
> >> available, distributed and build able, so that one could easily build
> >> Kolab server without having the pre-requisite of OpenPKG -- Gunnar
> >> recently started a thread on this topic.
> >
> > See above.  The build service does not have an openpkg repository.  That
> > would have been nice.   I think that it is a bit hard to set up, besides
> > that it is not very known.
>
> I'm not sure how your comment relates to the paragraph above, I was
> talking on classical tar packaging, not OpenPKG -- or are you saying we
> would need the tars to use the build service?

The output of the build service are packages.  Those packages are build from 
tarbals.  So, yes you need tarbals to use the build service.



> > If the Horde project will not come up with a polished GUI, ain't it
> > possible that kolab project adds this to the Horde project?  That way
> > both projects benefit, isn't it?
>
> That would be exactly the thing to do!  I thought that was what I
> wrote... ;-)

Yes, that's what you wrote indeed.   I see it now after reading back that part 
:)


> >> The suggestion has been made to take the administrative (web admin)
> >> interface as a kind of playground to test out our capabilities of
> >> creating an modern, appealing and user friendly web UI.
> >
> > I have always thought of moving kolab-webadmin into horde as that
> > interface is nicer, prettier than kolab-webadmin....
>
> That's one possible strategy, which will be evaluated.

For the user this seems do-able anyway: as the user can use the web-admin for 
updating his / her vacation message and personal information.  Not too much.  
For the administrator it is much more work....


> >> In any case this will be one of the more exciting areas in midterm Kolab
> >> server development.  We are looking forward to your comments...
> >
> > I'm surprised that you're thinking of ditching horde.  Assuming that
> > Horde-4 delivers what we expect ;)
>
> Well, maybe you expect more than we do.  To make it completely clear: we
> are just thinking, and we allow our self to think even of drastic
> changes, as what we are longing for is a drastic improvement.  But no
> decision has been made yet.

You were clear ;)


-- 
Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091118/ea04e756/attachment.html

From issues at kolab.org  Wed Nov 18 23:40:55 2009
From: issues at kolab.org (Mathieu Parent)
Date: Wed, 18 Nov 2009 22:40:55 +0000
Subject: [Kolab-devel] [issue3949] Kolab_Filter testsuite fails on slaves
In-Reply-To: <1258584055.02.0.25270518144.issue3949@kolab.org>
Message-ID: <1258584055.02.0.25270518144.issue3949@kolab.org>


New submission from Mathieu Parent <mathieuparent at users.sourceforge.net>:

Running Kolab_Filter's phpunit tests on a slave fails (as said on IRC).

See attached output.

This may be a Debian native specific problem, can you reproduce it on OpenPKG or
Gentoo?

----------
assignedto: wrobel
files: phpunit.txt
keyword: filter
messages: 22397
nosy: mathieu.parent, rbos, thomas, wrobel
priority: minor bug
status: unread
title: Kolab_Filter testsuite fails on slaves

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3949>
______________________________________
-------------- next part --------------
kolab_test_slave1:~# phpunit  /usr/share/php/tests/Kolab_Filter/Horde/Kolab/Filter/AllTests.php
PHPUnit 3.4.1 by Sebastian Bergmann.

............F........F..

Time: 8 seconds

There were 2 failures:

1) Horde_Kolab_Filter_ContentTest::testContentHandler with data set #3 ('/usr/share/php/tests/Kolab_Filter/Horde/Kolab/Filter/fixtures/forged.eml', '/usr/share/php/tests/Kolab_Filter/Horde/Kolab/Filter/fixtures/forged.ret', '', '10.0.0.1', 'me at example.org', 'you at example.org', 'example.org', array(true))
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-Mailfromsender:me at example.orgMailtorecipient:you at example.orgReturn-Path:<me at example.org>Received:fromlocalhost(fqdn.example.org[127.0.0.1])bydemo.example.org(Cyrusv2.3.9-openpkg)withLMTPA;Sat,10Nov200720:44:52+0100----From:=?utf-8?B?IiAoVU5UUlVTVEVELCBzZW5kZXIgPG1lQGV4YW1wbGUub3JnPiBpcyBub3QgYXV0aGVudGljYXRlZCki?=<me at example.org>To:"You"<you at example.org>Subject:MetoYouDate:Sat,10Nov200722:45:12+0300User-Agent:Gnus/5.1008(Gnusv5.10.8)Emacs/22.1.50(x86_64-pc-linux-gnu)MIME-Version:1.0Content-Type:text/plain;charset=us-asciitest.
+Mailfromsender:me at example.orgMailtorecipient:you at example.orgReturn-Path:<me at example.org>Received:fromlocalhost(fqdn.example.org[127.0.0.1])bydemo.example.org(Cyrusv2.3.9-openpkg)withLMTPA;Sat,10Nov200720:44:52+0100----From:"(UNTRUSTED,sender<me at example.org>isnotauthenticated)"<me at example.org>To:"You"<you at example.org>Subject:MetoYouDate:Sat,10Nov200722:45:12+0300User-Agent:Gnus/5.1008(Gnusv5.10.8)Emacs/22.1.50(x86_64-pc-linux-gnu)MIME-Version:1.0Content-Type:text/plain;charset=us-asciitest.

/usr/share/php/Horde/Kolab/Test/Filter.php:282
/usr/share/php/tests/Kolab_Filter/Horde/Kolab/Filter/ContentTest.php:49

2) Horde_Kolab_Filter_ContentTest::testTranslatedForgedFromHeader
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-Mailfromsender:me at example.orgMailtorecipient:you at example.orgReturn-Path:<me at example.org>Received:fromlocalhost(fqdn.example.org[127.0.0.1])bydemo.example.org(Cyrusv2.3.9-openpkg)withLMTPA;Sat,10Nov200720:44:52+0100----From:=?utf-8?B?IiAoVU5UUlVTVEVELCBzZW5kZXIgPG1lQGV4YW1wbGUub3JnPiBpcyBub3QgYXV0aGVudGljYXRlZCki?=<me at example.org>To:"You"<you at example.org>Subject:MetoYouDate:Sat,10Nov200722:45:12+0300User-Agent:Gnus/5.1008(Gnusv5.10.8)Emacs/22.1.50(x86_64-pc-linux-gnu)MIME-Version:1.0Content-Type:text/plain;charset=us-asciitest.
+Mailfromsender:me at example.orgMailtorecipient:you at example.orgReturn-Path:<me at example.org>Received:fromlocalhost(fqdn.example.org[127.0.0.1])bydemo.example.org(Cyrusv2.3.9-openpkg)withLMTPA;Sat,10Nov200720:44:52+0100----From:"(UNTRUSTED,sender<me at example.org>isnotauthenticated)"<me at example.org>To:"You"<you at example.org>Subject:MetoYouDate:Sat,10Nov200722:45:12+0300User-Agent:Gnus/5.1008(Gnusv5.10.8)Emacs/22.1.50(x86_64-pc-linux-gnu)MIME-Version:1.0Content-Type:text/plain;charset=us-asciitest.

/usr/share/php/Horde/Kolab/Test/Filter.php:282
/usr/share/php/tests/Kolab_Filter/Horde/Kolab/Filter/ContentTest.php:169

FAILURES!
Tests: 24, Assertions: 56, Failures: 2.


From issues at kolab.org  Wed Nov 18 23:40:55 2009
From: issues at kolab.org (Mathieu Parent)
Date: Wed, 18 Nov 2009 22:40:55 +0000
Subject: [Kolab-devel] [issue3950] Kolab_Filter testsuite fails on slaves
In-Reply-To: <1258584055.98.0.152537734611.issue3950@kolab.org>
Message-ID: <1258584055.98.0.152537734611.issue3950@kolab.org>


New submission from Mathieu Parent <mathieuparent at users.sourceforge.net>:

Running Kolab_Filter's phpunit tests on a slave fails (as said on IRC).

See attached output.

This may be a Debian native specific problem, can you reproduce it on OpenPKG or
Gentoo?

----------
assignedto: wrobel
files: phpunit.txt
keyword: filter
messages: 22398
nosy: mathieu.parent, rbos, thomas, wrobel
priority: minor bug
status: unread
title: Kolab_Filter testsuite fails on slaves

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3950>
______________________________________
-------------- next part --------------
kolab_test_slave1:~# phpunit  /usr/share/php/tests/Kolab_Filter/Horde/Kolab/Filter/AllTests.php
PHPUnit 3.4.1 by Sebastian Bergmann.

............F........F..

Time: 8 seconds

There were 2 failures:

1) Horde_Kolab_Filter_ContentTest::testContentHandler with data set #3 ('/usr/share/php/tests/Kolab_Filter/Horde/Kolab/Filter/fixtures/forged.eml', '/usr/share/php/tests/Kolab_Filter/Horde/Kolab/Filter/fixtures/forged.ret', '', '10.0.0.1', 'me at example.org', 'you at example.org', 'example.org', array(true))
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-Mailfromsender:me at example.orgMailtorecipient:you at example.orgReturn-Path:<me at example.org>Received:fromlocalhost(fqdn.example.org[127.0.0.1])bydemo.example.org(Cyrusv2.3.9-openpkg)withLMTPA;Sat,10Nov200720:44:52+0100----From:=?utf-8?B?IiAoVU5UUlVTVEVELCBzZW5kZXIgPG1lQGV4YW1wbGUub3JnPiBpcyBub3QgYXV0aGVudGljYXRlZCki?=<me at example.org>To:"You"<you at example.org>Subject:MetoYouDate:Sat,10Nov200722:45:12+0300User-Agent:Gnus/5.1008(Gnusv5.10.8)Emacs/22.1.50(x86_64-pc-linux-gnu)MIME-Version:1.0Content-Type:text/plain;charset=us-asciitest.
+Mailfromsender:me at example.orgMailtorecipient:you at example.orgReturn-Path:<me at example.org>Received:fromlocalhost(fqdn.example.org[127.0.0.1])bydemo.example.org(Cyrusv2.3.9-openpkg)withLMTPA;Sat,10Nov200720:44:52+0100----From:"(UNTRUSTED,sender<me at example.org>isnotauthenticated)"<me at example.org>To:"You"<you at example.org>Subject:MetoYouDate:Sat,10Nov200722:45:12+0300User-Agent:Gnus/5.1008(Gnusv5.10.8)Emacs/22.1.50(x86_64-pc-linux-gnu)MIME-Version:1.0Content-Type:text/plain;charset=us-asciitest.

/usr/share/php/Horde/Kolab/Test/Filter.php:282
/usr/share/php/tests/Kolab_Filter/Horde/Kolab/Filter/ContentTest.php:49

2) Horde_Kolab_Filter_ContentTest::testTranslatedForgedFromHeader
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-Mailfromsender:me at example.orgMailtorecipient:you at example.orgReturn-Path:<me at example.org>Received:fromlocalhost(fqdn.example.org[127.0.0.1])bydemo.example.org(Cyrusv2.3.9-openpkg)withLMTPA;Sat,10Nov200720:44:52+0100----From:=?utf-8?B?IiAoVU5UUlVTVEVELCBzZW5kZXIgPG1lQGV4YW1wbGUub3JnPiBpcyBub3QgYXV0aGVudGljYXRlZCki?=<me at example.org>To:"You"<you at example.org>Subject:MetoYouDate:Sat,10Nov200722:45:12+0300User-Agent:Gnus/5.1008(Gnusv5.10.8)Emacs/22.1.50(x86_64-pc-linux-gnu)MIME-Version:1.0Content-Type:text/plain;charset=us-asciitest.
+Mailfromsender:me at example.orgMailtorecipient:you at example.orgReturn-Path:<me at example.org>Received:fromlocalhost(fqdn.example.org[127.0.0.1])bydemo.example.org(Cyrusv2.3.9-openpkg)withLMTPA;Sat,10Nov200720:44:52+0100----From:"(UNTRUSTED,sender<me at example.org>isnotauthenticated)"<me at example.org>To:"You"<you at example.org>Subject:MetoYouDate:Sat,10Nov200722:45:12+0300User-Agent:Gnus/5.1008(Gnusv5.10.8)Emacs/22.1.50(x86_64-pc-linux-gnu)MIME-Version:1.0Content-Type:text/plain;charset=us-asciitest.

/usr/share/php/Horde/Kolab/Test/Filter.php:282
/usr/share/php/tests/Kolab_Filter/Horde/Kolab/Filter/ContentTest.php:169

FAILURES!
Tests: 24, Assertions: 56, Failures: 2.


From bernhard at intevation.de  Thu Nov 19 15:53:06 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 19 Nov 2009 15:53:06 +0100
Subject: [Kolab-devel] Brain Dump of the Week: Ideas,
	Plans and Realities ...
In-Reply-To: <200911172247.05037.ml@radoeka.nl>
References: <s7w8we5rwne.fsf@intevation.de> <200911172247.05037.ml@radoeka.nl>
Message-ID: <200911191553.09590.bernhard@intevation.de>

Am Dienstag, 17. November 2009 22:47:03 schrieb Richard Bos:
> May I point your attention to the openSUSE build service? ?Contrary its
> name, the build service is for all mainstream distributions

To me the main issue it testing the components together and controlling the 
quality of the combined solution, not building the packages.
A package for OpenSuse and Debian would both build upon other libraries
from the two GNU distributions. The testing community of Kolab Server would 
get divided or much more effort would be needed.

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/20091119/8050ffd1/attachment.bin

From issues at kolab.org  Thu Nov 19 20:29:17 2009
From: issues at kolab.org (Richard Bos)
Date: Thu, 19 Nov 2009 19:29:17 +0000
Subject: [Kolab-devel] [issue3951] During kolab_bootstrap services are
	started and result in	erros
In-Reply-To: <1258658957.67.0.183952524731.issue3951@kolab.org>
Message-ID: <1258658957.67.0.183952524731.issue3951@kolab.org>


New submission from Richard Bos <ml at radoeka.nl>:

When kolab_bootstrap -b is executed, services are unnecessary started and as
their configuration files are not ready yet, they fail. This results in error
messages that are confusing.  It even looks like bootstrapping has failed.  Have
a loot at the following snippet:

Create initial config files for postfix, apache, cyrus imap, saslauthd
running /usr/sbin/kolabconf -n                                        
DEBUG: Executing command:/usr/sbin/kolabsrv rc postfix reload         
Reload mail service (Postfix)                                                                      
failed
ERROR: /etc/init.d/postfix reload failed                                                                  
Run: kolabsrv rc all stop                                                                                 
to stop all services                                                                                      
DEBUG: Executing command:/usr/sbin/kolabsrv rc imapd restart                                              
Shutting down IMAP/POP3 service (cyrus-imapd)                                                      
done  
Starting IMAP/POP3 service (cyrus-imapd)                                                           
done  
DEBUG: Executing command:/usr/sbin/kolabsrv rc apache reload                                              
Reload httpd2 (graceful restart)                                                                          

Syntax error on line 13 of /etc/apache2/vhosts.d/ssl.conf:
SSLCertificateFile: file '/etc/kolab/cert.pem' does not exist or is empty

The command line was:
/usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -DSSL
                                                                                                   
unused
ERROR: /etc/init.d/apache2 reload failed                                                                  
Run: kolabsrv rc all stop                                                                                 
to stop all services                                                                                      

kill temporary slapd

Shutting down ldap-server                                                                          
done
============================

I assume that this nowadays happens as the RUNONCHANGE directive in the template
files is now working correctly.  However during bootstrapping the RUNONCHANGE
directive should be neglected...

RUNONCHANGE is interpreted by kolabconf. The latter is called twice in
kolab_bootstrap with the -n option.  This option means:

# kolabconf -h
kolabconf - Version @VERSION@

Usage: kolabconf [-d] [-n] [-h]

    Option d (debug) to print out the current config.
    Option n (noreload) to skip reloading services after changing configuration.
    Option h (help) to get this text.

If I interpret this help message correctly the services shouldn't be reloaded at
all by kolabconf in case the -n option is given....  The attached patch
(do_not_reload.patch) takes care of this.

Let me know if it is okay to commit this patch to cvs.

If do_not_reload.patch is okay, the variable $Kolab::config{"reload"} can be
replaced with the variable: $Kolab::reload, if that is better liked.  This
prevents that there will be 2 variables used for the same function...

----------
keyword: server
messages: 22406
nosy: bernhard, martin, rbos, thomas, wilde, wrobel
priority: urgent
status: unread
title: During kolab_bootstrap services are started and result in erros

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3951>
______________________________________


From issues at kolab.org  Thu Nov 19 20:34:34 2009
From: issues at kolab.org (Richard Bos)
Date: Thu, 19 Nov 2009 19:34:34 +0000
Subject: [Kolab-devel] [issue3952] Version in kolabconf is not replaced in
	the build process
In-Reply-To: <1258659274.09.0.459970221068.issue3952@kolab.org>
Message-ID: <1258659274.09.0.459970221068.issue3952@kolab.org>


New submission from Richard Bos <ml at radoeka.nl>:

Executing the kolabconf -h shows @VERSION@ as version.

# kolabconf -h
kolabconf - Version @VERSION@

Usage: kolabconf [-d] [-n] [-h]

    Option d (debug) to print out the current config.
    Option n (noreload) to skip reloading services after changing configuration.
    Option h (help) to get this text.

This is on native opensuse.

----------
assignedto: wrobel
keyword: server
messages: 22407
nosy: bernhard, martin, rbos, thomas, wilde, wrobel
priority: bug
status: unread
title: Version in kolabconf is not replaced in the build process

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3952>
______________________________________


From issues at kolab.org  Thu Nov 19 20:39:42 2009
From: issues at kolab.org (Richard Bos)
Date: Thu, 19 Nov 2009 19:39:42 +0000
Subject: [Kolab-devel] [issue3953] spamassassin conf file,
	with amavisd in runonchange directive
In-Reply-To: <1258659582.96.0.718966275132.issue3953@kolab.org>
Message-ID: <1258659582.96.0.718966275132.issue3953@kolab.org>


New submission from Richard Bos <ml at radoeka.nl>:

The following snippet is a copy of the top of spamassassin template file:
kolabd/kolabd/templates> head local.cf.template.in
KOLAB_META_START
TARGET=@spamassassin_confdir@/local.cf
PERMISSIONS=0644
OWNERSHIP=@amavisd_usr@:@amavisd_grp@
RUNONCHANGE=@KOLABRC@ rc amavisd restart

Is it correct that amavisd is configured in the RUNONCHANGE directive? 
Shouldn't this be spamd?

----------
messages: 22408
nosy: bernhard, martin, mathieu.parent, rbos, thomas, wilde, wrobel
priority: bug
status: unread
title: spamassassin conf file, with amavisd in runonchange directive

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3953>
______________________________________


From benoit.mortier at opensides.be  Thu Nov 19 22:32:15 2009
From: benoit.mortier at opensides.be (Benoit Mortier)
Date: Thu, 19 Nov 2009 22:32:15 +0100
Subject: [Kolab-devel] Brain Dump of the Week: Ideas,
	Plans and Realities ...
In-Reply-To: <200911191553.09590.bernhard@intevation.de>
References: <s7w8we5rwne.fsf@intevation.de> <200911172247.05037.ml@radoeka.nl>
	<200911191553.09590.bernhard@intevation.de>
Message-ID: <200911192232.16069.benoit.mortier@opensides.be>

Le Thursday 19 November 2009 15:53:06 Bernhard Reiter, vous avez ?crit?:
> Am Dienstag, 17. November 2009 22:47:03 schrieb Richard Bos:
> > May I point your attention to the openSUSE build service? ?Contrary
> > its name, the build service is for all mainstream distributions
>
> To me the main issue it testing the components together and controlling
> the quality of the combined solution, not building the packages.
> A package for OpenSuse and Debian would both build upon other libraries
> from the two GNU distributions. The testing community of Kolab Server
> would get divided or much more effort would be needed.

Hello Bernard,

I understand that well, but we should think as distribution as a vehicule 
to get the software more tested than its now, and in return you will have 
more hand to help

Look at the distribution as the "marketing" vehicule of free software ...

Cheers
-- 
Benoit Mortier
CEO 
OpenSides "logiciels libres pour entreprises" : http://www.opensides.eu/
Contributor to Gosa Project : http://gosa-project.org/


From issues at kolab.org  Fri Nov 20 18:29:17 2009
From: issues at kolab.org (Bernhard Reiter)
Date: Fri, 20 Nov 2009 17:29:17 +0000
Subject: [Kolab-devel] [issue3954] A group of selected folders cannot be
	deleted
In-Reply-To: <1258738157.11.0.735979272883.issue3954@kolab.org>
Message-ID: <1258738157.11.0.735979272883.issue3954@kolab.org>


New submission from Bernhard Reiter <bernhard at intevation.de>:

I can select a group of folders in the folder list.
The context menue does not allow to delete the group together.
Can this be changed?

Behaviour verified with 4:3.5.10.enterprise.0.20091103.1044299-kk1.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22426
nosy: allen, bernhard, ludwig, till
priority: bug
status: unread
title: A group of selected folders cannot be deleted

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3954>
______________________________________


From thomas at btspuhler.com  Sat Nov 21 17:43:36 2009
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sat, 21 Nov 2009 09:43:36 -0700
Subject: [Kolab-devel] Kolab Server 2.2.3
In-Reply-To: <200911152223.48497.ml@radoeka.nl>
References: <20091020172924.577027525.thomas@intevation.de>
	<200911141442.07881.thomas@btspuhler.com>
	<200911152223.48497.ml@radoeka.nl>
Message-ID: <200911210943.37247.thomas@btspuhler.com>

On Sunday 15 November 2009 02:23:47 pm Richard Bos wrote:
> Thomas,
>
> Op zaterdag 14 november 2009 22:42:07 schreef Thomas Spuhler:
> > > Ok, I get a little closer, but I know receive the message that the
> > > module is already loaded.
> > > I am not a Perl coder, but it looks is if the code loads it twice
> > >
> > > See this http://mandriva.pastebin.fr/6001
> >
> >  Ok, I figured this out.
>
> What did you make of it?
>
> > But the kolabd has a couple line that may be a problem:
> > . /etc/rc.status
>
> No idea where this come from:
> kolabd> grep -R "rc\.status" *
> No result, there is no file in the kolabd module that contains sting. 
> Neither does perl-kolab.

It's actually in /usr/sbin/rckolabd

# Copyright (c) 2006 Richard Bos and Marcus H?we
# Copyright (c) 2009 Richard Bos



-- 
Thomas


From ml at radoeka.nl  Sat Nov 21 18:00:26 2009
From: ml at radoeka.nl (Richard Bos)
Date: Sat, 21 Nov 2009 18:00:26 +0100
Subject: [Kolab-devel] Kolab Server 2.2.3
In-Reply-To: <200911141442.07881.thomas@btspuhler.com>
References: <20091020172924.577027525.thomas@intevation.de>
	<200911141051.49295.thomas@btspuhler.com>
	<200911141442.07881.thomas@btspuhler.com>
Message-ID: <200911211800.27545.ml@radoeka.nl>

Hello Thomas,

Op zaterdag 14 november 2009 22:42:07 schreef Thomas Spuhler:
> But the kolabd has a couple line that may be a problem:
> . /etc/rc.status
>
> # Reset status of this service
> rc_reset
>
> Mandriva doesn't have this script. I found on Google, Redhat and Debian
> based distros don't have it.
> I this important?

Op zaterdag 21 november 2009 17:43:36 schreef Thomas Spuhler:
> It's actually in /usr/sbin/rckolabd
>
> # Copyright (c) 2006 Richard Bos and Marcus H?we

This is an openSUSE customized script.  It just starts the kolab daemon.  It's 
actually a link to kolab2:~ 
# ls -l /usr/sbin/rckolabd
lrwxrwxrwx 1 root root 18 2009-11-08 22:26 /usr/sbin/rckolabd -> 
/etc/init.d/kolabd

Use or write your own Mandrake specific startup script, is I believe the best 
thing you can do.

-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091121/73a08311/attachment.html

From issues at kolab.org  Mon Nov 23 11:05:50 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 23 Nov 2009 10:05:50 +0000
Subject: [Kolab-devel] [issue3955] Kontact automaticly sends a mail to all
	attendees of an	event without confirming it.
In-Reply-To: <1258970750.45.0.572323346151.issue3955@kolab.org>
Message-ID: <1258970750.45.0.572323346151.issue3955@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

Kontact enterprise35 20091113.1048602-kk1

Test:
1. A sends an invitation to B, C and D.
2. B accepts the invitation with a different mail address.
3. A enters B's update mail and accepts the attendee.
=> An update mail is send automaticly to all attendees.
Never should a mail to all attendees be send without confirming.
So this is wrong.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 22437
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: critical
status: unread
title: Kontact automaticly sends a mail to all attendees of an event without confirming it.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3955>
______________________________________


From wrobel at pardus.de  Mon Nov 23 17:27:40 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 23 Nov 2009 17:27:40 +0100
Subject: [Kolab-devel] How to test the Kolab server (was: Re: Brain Dump
	of	the Week: Ideas, Plans and Realities ...)
In-Reply-To: <200911172247.05037.ml@radoeka.nl>
References: <s7w8we5rwne.fsf@intevation.de> <200911172247.05037.ml@radoeka.nl>
Message-ID: <20091123172740.11291pr4oo2owizo@webmail.pardus.de>

Hi Richard,

Quoting Richard Bos <ml at radoeka.nl>:

[snip]

> > 2. Packaging and Distribution Future
> >
> > The current official and only commercially supported platform
> for Kolab
> > is OpenPKG -- unfortunately the future of OpenPKG, technically
> and
> > politically (read business model), is unknown -- at least to
> us.  On the
> > other hand there is the contributed native packaging of Kolab
> server for
> > many distributions, with varying grades of functionality and
> stability.
> >
> > Currently we are not sure what to make of all this.  It is
> clear that we
> > will continue to need one defined distribution with stability
> and
> > support standards for our enterprise business -- but this
> might not
> > necessary be OpenPKG for ever.  Besides this we want to make
> Kolab
> > server as attractive and easy to setup for users and
> developers as
> > possible, which not at least would mean to support good native
> > packaging, but once again the strategy how to achieve this
> with limited
> > resources is work in progress.
>
> May I point your attention to the openSUSE build service?

[snip]

As pointed out by both Sascha and Bernhard before I also don't think  
that building the packages is our core problem. Let me try to explain  
why and then come back to the core problem we see: testing the server.

The openSUSE build service is of course interesting. It would provide  
one piece of a continuous integration setup - where code commits  
directly lead to an updated server release that could be tested. Using  
something like the openSUSE build service would help in producing  
releases for several platforms simultaneously. Compiling these for  
several distributions would certainly help the package quality.

We have had our problems with supporting the packaging efforts of the  
community in the past and many people from the native ports (of course  
including you) helped the Kolab project to improve in that area.  
Things are still not perfect but I would say they progressed quite  
well in the recent years.

But for the Kolab Konsortium the community cannot be the only driving  
factor. I'm already happy that the process is as open as it currently  
is. But in order to finance the Kolab server we are required to  
deliver a rock solid mail server for the customers. This is simply  
essential in the area of mail services. And that means we need to  
thoroughly test the server.

This has been one of the driving factors for the OpenPKG decision.  
This way the server runs on many Linux base distros while we can still  
test only one specific packaging setup and the corresponsing upgrade  
path.

Providing packages for several distributions won't really help with  
the testing problem. In fact we'd get more setups we'd need to test  
and we already have enough trouble testing the one setup we currently  
support.

So I think the core issue to discuss would be testing. With the manual  
testing scheme we are currently using we can only support one  
distribution. If that is OpenPKG or something else in the future does  
not really matter.

The only alternative I see - and that has also already been mentioned  
- is a test suite for the complete server (or even the Kolab server  
network if we consider slaves).

The advantages of such a test suite would be:

  1) It would be independant of the distribution and at one point we might be
     able to say: A Kolab Server is an installation that runs fine  
with this test
     suite. That would be cool - but also a lot of work.

  2) It would document the server functionality. Right now sometimes the best
     solution to determine how something works on the Kolab server is to check
     the OpenPKG variant. This is not really satisfying.

  3) It would speed up our development process. Having a test suite  
always helps
     developers to point out potential side effects of their commits that they
     did not think of.

  4) It would allow the communities from the native ports to help improving the
     testing. Right now issues from the native ports are problematic because it
     is difficult to determine if a reported issue is a distribution specific
     problem or not.

And the disadvantages:

  1) It would be a lot of work to provide a test suite that covers a lot of the
     Kolab Server functionality.

  2) If such a test suite exists it is tempting to write a new test  
for each new
     issue (if possible). This would slow down the development process.

  3) The test suite would have to be maintained. If it is a large test  
suite then
     it might be hard to do larger rearragements for the Kolab server  
as the test
     suite suddenly fails in many places. This is a particular problem of such
     high level testing as it would be necessary for the Kolab server.

  4) Makes adding new functionality hard as all the additional features need
     testing, too.

The current system also has some advantages:

  1) Tried and tested :) system.

  2) Works well with the available man power.

And the main disadvantages:

  1) Limits us to a single distribution.

  2) Makes adding new functionality hard as all the additional features need
     testing, too (see web client).

  3) Not reliable as we can't possibly test all the different features of the
     Kolab server manually for each release.


This is not an exhaustive overview and my personal view of the topic.  
I just wanted to highlight the difficulties I currently see.

As to a possible solution: The two systems are in no way mutually  
exclusive. There is no reason why we should not have both of them at  
the same time. So why not just start with a very small test suite?  
Something that tests just one area of the Kolab server.

I would suggest to go for the resource management  
(Kolab_FreeBusy/Kolab_Filter) of the Kolab server. In my experience  
this is one of the things that is hard to get right on the native  
distributions and that tends to break easily. So there should be a  
benefit for the OpenPKG version as well.

W could provide a defined way on how to set up and run this test suite  
as well as describing how people can add new tests. By supporting a  
small - or even tiny  - testsuite over several server releases we  
might get what we need to know in order to decide which way to go. We  
might get an idea on whether such a test suite is hard to maintain and  
how much effort adding new tests would be. We might be able to see if  
people are willing and able to contribute.

My 2cents on testing.

Cheers,

Gunnar


-- 
____ http://www.pardus.de[1] _________________
http://gunnarwrobel.de[2] _

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 <<
--------------------------------------------------------------------

Links:
------
[1] http://www.pardus.de
[2] http://gunnarwrobel.de

-------------- 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/20091123/ae94cc2b/attachment.bin

From wrobel at pardus.de  Mon Nov 23 17:27:49 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 23 Nov 2009 17:27:49 +0100
Subject: [Kolab-devel] Brain Dump of the Week: Ideas,
	Plans and	Realities ...
In-Reply-To: <200911192232.16069.benoit.mortier@opensides.be>
References: <s7w8we5rwne.fsf@intevation.de> <200911172247.05037.ml@radoeka.nl>
	<200911191553.09590.bernhard@intevation.de>
	<200911192232.16069.benoit.mortier@opensides.be>
Message-ID: <20091123172749.956249c6qz27xbms@webmail.pardus.de>

Quoting Benoit Mortier <benoit.mortier at opensides.be>:

> Le Thursday 19 November 2009 15:53:06 Bernhard Reiter, vous avez ?crit :
>> Am Dienstag, 17. November 2009 22:47:03 schrieb Richard Bos:
>> > May I point your attention to the openSUSE build service?  Contrary
>> > its name, the build service is for all mainstream distributions
>>
>> To me the main issue it testing the components together and controlling
>> the quality of the combined solution, not building the packages.
>> A package for OpenSuse and Debian would both build upon other libraries
>> from the two GNU distributions. The testing community of Kolab Server
>> would get divided or much more effort would be needed.
>
> Hello Bernard,
>
> I understand that well, but we should think as distribution as a vehicule
> to get the software more tested than its now, and in return you will have
> more hand to help
>
> Look at the distribution as the "marketing" vehicule of free software ...
>
> Cheers
> --
> Benoit Mortier
> CEO
> OpenSides "logiciels libres pour entreprises" : http://www.opensides.eu/
> Contributor to Gosa Project : http://gosa-project.org/
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel



-- 
____ 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 <<
--------------------------------------------------------------------



From ml at radoeka.nl  Mon Nov 23 20:04:10 2009
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 23 Nov 2009 20:04:10 +0100
Subject: [Kolab-devel]
 =?iso-8859-15?q?How_to_test_the_Kolab_server_=28was?=
 =?iso-8859-15?q?=3A_Re=3A_Brain_Dump_of=09the_Week=3A_Ideas=2C_Plans_and_?=
 =?iso-8859-15?q?Realities_=2E=2E=2E=29?=
In-Reply-To: <20091123172740.11291pr4oo2owizo@webmail.pardus.de>
References: <s7w8we5rwne.fsf@intevation.de> <200911172247.05037.ml@radoeka.nl>
	<20091123172740.11291pr4oo2owizo@webmail.pardus.de>
Message-ID: <200911232004.10863.ml@radoeka.nl>

Op maandag 23 november 2009 17:27:40 schreef Gunnar Wrobel:
> [snip]
>
> As pointed out by both Sascha and Bernhard before I also don't think  
> that building the packages is our core problem. Let me try to explain  
> why and then come back to the core problem we see: testing the server.
>
> The openSUSE build service is of course interesting. It would provide  
> one piece of a continuous integration setup - where code commits  
> directly lead to an updated server release that could be tested. Using  
> something like the openSUSE build service would help in producing  
> releases for several platforms simultaneously. Compiling these for  
> several distributions would certainly help the package quality.

I only mentioned the build service, as the OP wrote that someday maybe a shift 
from openpkg could happen (or not).  If that will take place, it is 
interesting to have a look at the build service.  The build is more much more 
than a service that build packages for different distributions, distribution 
versions and architures.  It is a collaboration service.  Packagers can easily 
work together to build packages, just like code version systems allow branches 
this thing allows branches as well.  I'm using the service quite long and very 
often I'm surprised how well it works.  It's difficult to explain if you have 
not worked with it, so I'm not going to do that.

As all of you say, testing is important but at the end of the testing phase 
code is waiting to be delivered and most likely it will be delivered via a 
package...  And this is also true for the testing suite.

If the Kolab Konsortium wants to shift away from openPKG, it will pick one 
other distro, with a long term contract (SLES, Ubuntu LTE, RH, CentOS, etc).  
The disadvantage might be that not all hardware platforms are supported, but 
that is something that will probably be overcome.  Test on that distribution 
and provide a rock solid groupware server.  If now the packages are build in 
the build services (which could be hosted on e.g. build.kolab.org, just like 
cvs) for that distribution, other packages could be build from the same 
sources and spec files at the same time.  Of course without the guarantee that 
it will work flawlessly, the community has to take care for that.  Will that 
happen I can't tell, is it the best solution, don't know.  It is just an 
example of what is possible.

-- 
Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091123/604cdee3/attachment.html

From alex at ap-consulting.co.uk  Mon Nov 23 18:12:22 2009
From: alex at ap-consulting.co.uk (Alex Potter)
Date: Mon, 23 Nov 2009 17:12:22 +0000
Subject: [Kolab-devel]
 =?iso-8859-15?q?How_to_test_the_Kolab_server_=28was?=
 =?iso-8859-15?q?=3A_Re=3A_Brain_Dump_of=09the_Week=3A_Ideas=2C_Plans_and_?=
 =?iso-8859-15?q?Realities_=2E=2E=2E=29?=
In-Reply-To: <20091123172740.11291pr4oo2owizo@webmail.pardus.de>
References: <s7w8we5rwne.fsf@intevation.de> <200911172247.05037.ml@radoeka.nl>
	<20091123172740.11291pr4oo2owizo@webmail.pardus.de>
Message-ID: <200911231712.22729.alex@ap-consulting.co.uk>

On Monday 23 November 2009 16:27:40 Gunnar Wrobel wrote:
> And the main disadvantages:
> 
>   1) Limits us to a single distribution.
> 
>   2) Makes adding new functionality hard as all the additional features
>  need testing, too (see web client).
> 
>   3) Not reliable as we can't possibly test all the different features of
>  the Kolab server manually for each release.
> 

and 4. Makes it hard to keep the openpkg system updated if new dependencies 
are introduced by security updates/bugfixes.

Regards

Alex


From ml at radoeka.nl  Mon Nov 23 21:54:27 2009
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 23 Nov 2009 21:54:27 +0100
Subject: [Kolab-devel] Brain Dump of the Week: Ideas,
	Plans and Realities ...
In-Reply-To: <s7wpr7gyxah.fsf@intevation.de>
References: <s7w8we5rwne.fsf@intevation.de> <200911172247.05037.ml@radoeka.nl>
	<s7wpr7gyxah.fsf@intevation.de>
Message-ID: <200911232154.28310.ml@radoeka.nl>

Op woensdag 18 november 2009 10:52:54 schreef Sascha Wilde:
> > What do you mean with a polished and shiny UI?
>
> I mean a UI that can compete with other groupware web clients, in terms
> of the user experience.  That means: interactivity, speed and a modern
> look and feel.  Good web applications these days do nearly match native
> clients in these respects.  Users (and customers for that matter) know
> this, they have seen and often used web applications like those of
> google, zarafa or open-exchange for example and they expect us to
> provide something comparable.

Something like this? :
http://www.siriusit.co.uk/labs/2009/roundcube-the-worlds-coolest-open-source-webmail-project/

-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091123/0fd1f244/attachment-0001.html

From wrobel at pardus.de  Mon Nov 23 22:24:12 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 23 Nov 2009 22:24:12 +0100
Subject: [Kolab-devel] Moving away from OpenPKG (was: Re: How to test
	the	Kolab server)
In-Reply-To: <200911232004.10863.ml@radoeka.nl>
References: <s7w8we5rwne.fsf@intevation.de> <200911172247.05037.ml@radoeka.nl>
	<20091123172740.11291pr4oo2owizo@webmail.pardus.de>
	<200911232004.10863.ml@radoeka.nl>
Message-ID: <20091123222412.13872ls6l7018eqs@webmail.pardus.de>


Quoting Richard Bos <ml at radoeka.nl>:

> Op maandag 23 november 2009 17:27:40 schreef Gunnar Wrobel:
> > [snip]
> >
> > As pointed out by both Sascha and Bernhard before I also don't
> think  > that building the packages is our core problem. Let me try to
> explain  > why and then come back to the core problem we see: testing the
> server.
> >
> > The openSUSE build service is of course interesting. It would
> provide  > one piece of a continuous integration setup - where code
> commits  > directly lead to an updated server release that could be
> tested. Using  > something like the openSUSE build service would help in
> producing  > releases for several platforms simultaneously. Compiling these
> for  > several distributions would certainly help the package
> quality.
>
> I only mentioned the build service, as the OP wrote that
> someday maybe a shift from openpkg could happen (or not).  If that
> will take place, it is interesting to have a look at the build
> service.  The build is more much more than a service that build
> packages for different distributions, distribution versions and
> architures.  It is a collaboration service.  Packagers can easily
> work together to build packages, just like code version systems
> allow branches this thing allows branches as well.  I'm using the
> service quite long and very often I'm surprised how well it works.  
> It's difficult to explain if you have not worked with it, so I'm
not
> going to do that.
>
> As all of you say, testing is important but at the end of the
> testing phase code is waiting to be delivered and most likely it
> will be delivered via a package...  And this is also true for the
> testing suite.
>
> If the Kolab Konsortium wants to shift away from openPKG, it
> will pick one other distro, with a long term contract (SLES, Ubuntu
> LTE, RH, CentOS, etc).

Hm, I have to disagree to that. Of course this is just my opinion but  
from the discussion we had one and a half weeks ago I had the  
impression that we would not like to throw away the advantage that you  
can install the Kolab server on most base distributions. So we were  
talking about using source based distributions and the favorite one  
seemed to be pkgsrc  
(http://www.netbsd.org/docs/software/packages.html). There was one  
lonely voice pleading for Gentoo - yes, it was me - but I guess I hope  
in vain :)

> The disadvantage might be that not all
> hardware platforms are supported, but that is something that will
> probably be overcome.  Test on that distribution and provide a rock
> solid groupware server.  If now the packages are build in the build
> services (which could be hosted on e.g. build.kolab.org, just like
> cvs) for that distribution, other packages could be build from the
> same sources and spec files at the same time.  Of course without
the
> guarantee that it will work flawlessly, the community has to take
> care for that.  Will that happen I can't tell, is it the best
> solution, don't know.  It is just an example of what is possible.

Are the distributions supported by the build service limited to RPM?

Cheers,

Gunnar

>
> -- 
> Richard
>
>

-- 
____ 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 <<
--------------------------------------------------------------------


From ml at radoeka.nl  Mon Nov 23 22:40:50 2009
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 23 Nov 2009 22:40:50 +0100
Subject: [Kolab-devel]
 =?iso-8859-1?q?Moving_away_from_OpenPKG_=28was=3A_R?=
 =?iso-8859-1?q?e=3A_How_to_test_the=09Kolab_server=29?=
In-Reply-To: <20091123222412.13872ls6l7018eqs@webmail.pardus.de>
References: <s7w8we5rwne.fsf@intevation.de> <200911232004.10863.ml@radoeka.nl>
	<20091123222412.13872ls6l7018eqs@webmail.pardus.de>
Message-ID: <200911232240.50694.ml@radoeka.nl>

Op maandag 23 november 2009 22:24:12 schreef Gunnar Wrobel:
> > If the Kolab Konsortium wants to shift away from openPKG, it
> > will pick one other distro, with a long term contract (SLES, Ubuntu
> > LTE, RH, CentOS, etc).
>
> Hm, I have to disagree to that. Of course this is just my opinion but  
> from the discussion we had one and a half weeks ago I had the  
> impression that we would not like to throw away the advantage that you  
> can install the Kolab server on most base distributions. So we were  
> talking about using source based distributions and the favorite one  
> seemed to be pkgsrc  
> (http://www.netbsd.org/docs/software/packages.html). 

I was not aware of that.  Good to hear this!

> There was one  
> lonely voice pleading for Gentoo - yes, it was me - but I guess I hope  
> in vain :)

:)


[snip

> Are the distributions supported by the build service limited to RPM?

.deb is supported too.  It is unfortenately not possible to convert an spec 
file to .deb control file.  The .spec file and the .deb control file have to 
be maintained manually.  But the sources and .changes file and patches are all 
shared.

BTW, it might even be possible to make instance for openpkg.   But that won't 
be done by the people on build.opensuse.org. But perhaps others will add it to 
the build service, it's opensrc so why not ;)  But the openpkg spec files are 
very different than the regular .spec files, hence those .spec files can 
probably not be used for other distributions :(

-- 
Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091123/fd95c5b3/attachment.html

From math.parent at gmail.com  Mon Nov 23 23:31:55 2009
From: math.parent at gmail.com (Mathieu Parent)
Date: Mon, 23 Nov 2009 23:31:55 +0100
Subject: [Kolab-devel] How to test the Kolab server (was: Re: Brain Dump
	of the Week: Ideas, Plans and Realities ...)
In-Reply-To: <20091123172740.11291pr4oo2owizo@webmail.pardus.de>
References: <s7w8we5rwne.fsf@intevation.de> <200911172247.05037.ml@radoeka.nl>
	<20091123172740.11291pr4oo2owizo@webmail.pardus.de>
Message-ID: <960738410911231431g111e16cp279a08aa7b2823c1@mail.gmail.com>

Hi,

On Mon, Nov 23, 2009 at 5:27 PM, Gunnar Wrobel <wrobel at pardus.de> wrote:
(mega-snip)

> So I think the core issue to discuss would be testing. <snip>
Agree.

I will move the pkg-kolab (Debian) testsuite to Kolab CVS. We can use
it as a base.

Currently the script:
- bootstrap a virtual domain (Xen or Virtualbox)
- install kolab
- run kolab_bootstrap and automatically answer questions
- run Kolab_Filter and Kolab_freebusy testsuites

TODO rapidely:
- support for OpenPKG's kolab version
- support for other distributions (mainly those with native packages)
- support for other virtualizations (I don't have HVM myself)
- extend the testsuite

See: http://svn.debian.org/wsvn/pkg-kolab/pkg-kolab_testsuite/testsuite

(mega-snip)

Mathieu Parent


From wrobel at pardus.de  Tue Nov 24 00:01:29 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 24 Nov 2009 00:01:29 +0100
Subject: [Kolab-devel] How to test the Kolab server (was: Re: Brain	Dump
	of the Week: Ideas, Plans and Realities ...)
In-Reply-To: <960738410911231431g111e16cp279a08aa7b2823c1@mail.gmail.com>
References: <s7w8we5rwne.fsf@intevation.de> <200911172247.05037.ml@radoeka.nl>
	<20091123172740.11291pr4oo2owizo@webmail.pardus.de>
	<960738410911231431g111e16cp279a08aa7b2823c1@mail.gmail.com>
Message-ID: <20091124000129.119945cjqgdmxrok@webmail.pardus.de>

Hi Mathieu,

Quoting Mathieu Parent <math.parent at gmail.com>:

> Hi,
>
> On Mon, Nov 23, 2009 at 5:27 PM, Gunnar Wrobel <wrobel at pardus.de> wrote:
> (mega-snip)
>
>> So I think the core issue to discuss would be testing. <snip>
> Agree.
>
> I will move the pkg-kolab (Debian) testsuite to Kolab CVS. We can use
> it as a base.
>
> Currently the script:
> - bootstrap a virtual domain (Xen or Virtualbox)
> - install kolab
> - run kolab_bootstrap and automatically answer questions
> - run Kolab_Filter and Kolab_freebusy testsuites
>
> TODO rapidely:
> - support for OpenPKG's kolab version
> - support for other distributions (mainly those with native packages)
> - support for other virtualizations (I don't have HVM myself)
> - extend the testsuite
>
> See: http://svn.debian.org/wsvn/pkg-kolab/pkg-kolab_testsuite/testsuite

Wow, cool. Thanks! I couldn't take a closer look now but I guess it  
should be possible to merge that with the cvs-kolab.sh script from our  
cvs so that we can setup an OpenPKG based Kolab installation and test  
run it.

@Thomas: I know you had your own ideas in that direction. Can you join  
the discussion and maybe give some hints on whether this would be a  
move into the right direction? Thanks!

Cheers,

Gunnar

>
> (mega-snip)
>
> Mathieu Parent
>
> _______________________________________________
> 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 <<
--------------------------------------------------------------------

-------------- 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/20091124/6b80dd93/attachment.bin

From wrobel at pardus.de  Tue Nov 24 00:06:46 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 24 Nov 2009 00:06:46 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <20091116232903.184470z9qm8t1cg8@webmail.pardus.de>
References: <20091020172924.577027525.thomas@intevation.de>
	<20091116232903.184470z9qm8t1cg8@webmail.pardus.de>
Message-ID: <20091124000646.133563d7ga1eg680@webmail.pardus.de>

Hi!

Last week and today I had a kolab-webadmin bugfixing day and the list for
Kolab_Server-2.2.3 has shortened again. Here is what is left for my side:

Quoting Thomas Arendsen Hein <thomas at intevation.de>:

> Hi!
>
> Here is a preliminary list of issues we want to address in Kolab
> Server 2.2.3, we aim to make the release in December:

[snip]

>
> Gunnar:
>
>  SyncML issues
>
> maybe:
>
>  kolab/issue2991 (The Kolab web client is always in the privileged networks)
>  kolab/issue3567 (Migrate Horde prefs 2.2.0 -> 2.2.1, 2.2.2)
>    (requested by many people, though not customers)

SyncML will be next now.

Cheers,

Gunnar


-- 
______ 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 <<
--------------------------------------------------------------------

-------------- 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/20091124/04f5c80d/attachment-0001.bin

From thomas at intevation.de  Tue Nov 24 11:25:58 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Tue, 24 Nov 2009 11:25:58 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <20091124000646.133563d7ga1eg680@webmail.pardus.de>
References: <20091020172924.577027525.thomas@intevation.de>
	<20091116232903.184470z9qm8t1cg8@webmail.pardus.de>
	<20091124000646.133563d7ga1eg680@webmail.pardus.de>
Message-ID: <20091124112336.627744926.thomas@intevation.de>

* Gunnar Wrobel <wrobel at pardus.de> [20091124 00:06]:
> Last week and today I had a kolab-webadmin bugfixing day and the list for
> Kolab_Server-2.2.3 has shortened again. Here is what is left for my side:
>
>> Gunnar:
>>
>>  SyncML issues
>>
>> maybe:
>>
>>  kolab/issue2991 (The Kolab web client is always in the privileged networks)
>>  kolab/issue3567 (Migrate Horde prefs 2.2.0 -> 2.2.1, 2.2.2)
>>    (requested by many people, though not customers)

Thanks for the update, here is the current TODO list for 2.2.3:

Thomas (thomas):
  small effort:
    switch imapd databases back from berkeley to skiplist
      (skiplist has proven to cause less performance and stability issues)
    kolab/issue3951 (kolabconf -n (noreload) restarts services if RUNONCHANGE is used)
      (rbos provided a patch)
    kolab/issue3513 (Clamav - new upstream version 0.95.3)
      (needs cleanup: release-notes, Makefile)
    kolab/issue3594 (Mail containing NUL byte not delivered, Kolab Filter does not report lmtp error)
      (Use "message_reject_characters = \0")
    kolab/issue3838 (no logging for pop3)
      (small change in imapd package required)
    kolab/issue1448 (Users might add an account on the nonHome Server and write emails in there.)
      (probably just adjust ACLs)
    kolab/issue3895 (Openldap: loglevel should be set to none in slapd.conf)
      (small change, big benefit)
    kolab/issue3938 (compiling procmail fails on Fedora 11 and Ubuntu karmic)
      (updated OpenPKG package available)
    kolab/issue3940 (Deleting users does not work if master Kolab server is not master LDAP)
      (workaround exists, needs real fix)
  larger effort:
    (no public issue) Option to restrict MDNs to local server
      (new feature, but requested by customer)
    kolab/issue3751 (Empty page in Firefox instead of login screen)
      (caused by a broken event or contact, needs further investigation)
    kolab/issue3138 (problems with server upgrade from sarge to etch)
      (we have done this a couple of times from sarge or etch to lenny now)
    kolab/issue1340 (RFC: restrict users to sending mail only to internal recipients)
      (new feature, but requested by customers)

Gunnar (wrobel):
  kolab/issue3856 (IMP/DIMP folder navigator does not allow creating/deleting/... mail folders)
    (partly fixed: new folders are not shown until next login)
  kolab/issue3594 (Mail containing NUL byte not delivered, Kolab Filter does not report lmtp error)
    (better handling of lmtp errors by kolab filter)
  kolab/issue3952 (Version in kolabconf is not replaced in the build process)
  Verify/apply patches from Univention (e.g. SyncML issues)

Sascha (wilde):
  kolab/issue973 (Rewritten from shown inconveniently in kontact)
    (patch for server-side available)

maybe:
  kolab/issue2991 (The Kolab web client is always in the privileged networks)
  kolab/issue2919 (domain maintainer can't edit quota of his users)
  kolab/issue3445 (web client does not work with Konqueror)
  kolab/issue3567 (Migrate Horde prefs 2.2.0 -> 2.2.1, 2.2.2)
    (requested by many people, though not customers)
  improve build process:
  - Makefile target for 2.2.2 -> 2.2.3
  - SHA1 checksums for things downloaded during build process

And as usual, many of the issues which were fixed recently need testing.
Link for all server and web client issues on testing:
https://issues.kolab.org/issue?:columns=title,id,keyword&:group=priority&:filter=keyword,status&status=6&keyword=1,19

Some of the issues that need testing are:
  kolab/issue919  (kolab server has problems with some characters in passwords)
  kolab/issue3499 (creating/modifying users with special characters in name confuses web admin)
  kolab/issue3654 (Special character issue in Kolab web interface (e.g. vacation message))
  kolab/issue3610 (Mail to unknown at something.example.com gets accepted and yields kolabmailboxfilter exit 38)
  kolab/issue3768 (Kolab server 2.2.2 resmgr doesn't copy attendee status (rt#5801))
  kolab/issue2499 (Notification messages by the resource manager should be localized)
  kolab/issue3846 (fix recurring events that are counted per week and not per incident)

-- 
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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091124/08c37fa3/attachment.bin

From issues at kolab.org  Tue Nov 24 11:34:38 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 24 Nov 2009 10:34:38 +0000
Subject: [Kolab-devel] [issue3956] A way to save many attachments with one
	command.
In-Reply-To: <1259058878.22.0.493421805518.issue3956@kolab.org>
Message-ID: <1259058878.22.0.493421805518.issue3956@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

A wish from a customer.

He has a mail with many attachments and wants to save them with just one
command/operation. He doesn't want to click on every attachment and select "save
as" and save it.

Perhaps a "save all attachments to folder" menu action could help in this case.

Can you please estimate a solution. 
Wait on an ok before start to implement.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22471
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: wish
status: unread
title: A way to save many attachments with one command.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3956>
______________________________________


From issues at kolab.org  Tue Nov 24 12:02:15 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 24 Nov 2009 11:02:15 +0000
Subject: [Kolab-devel] [issue3957] Improvement of German text in
	conditionally accepted	events(rt#5905)
In-Reply-To: <1259060535.89.0.11089748151.issue3957@kolab.org>
Message-ID: <1259060535.89.0.11089748151.issue3957@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

observed with Kontact e35 20091113.1048602-kk1

Test:
1. A sends an invitation to B.
2. B accepts conditionally.
3. B starts to edit the event.

The German "Sie haben auf diese Einladung noch nicht definitiv geantwortet."
should be improved to "Sie haben auf diese Einladung noch nicht endg?ltig
geantwortet."

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22474
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Improvement of German text in conditionally accepted events(rt#5905)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3957>
______________________________________


From issues at kolab.org  Tue Nov 24 14:27:33 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 24 Nov 2009 13:27:33 +0000
Subject: [Kolab-devel] [issue3958] Copy action on the address of an open
	mail doesn't	work(rt#5911)
In-Reply-To: <1259069253.52.0.523365561368.issue3958@kolab.org>
Message-ID: <1259069253.52.0.523365561368.issue3958@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

observed with Kontact e35 20091113.1048602-kk1

Test:
1. Switch to mail plugin.
2. Double click on a mail to open it.
=> The mail is display in a window.
3. RMB on the From or To address of the mail and choose "Copy"
=> The text of the mail is not copied to the clipboard.
   So it is not possible to paste it again.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22477
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Copy action on the address of an open mail doesn't work(rt#5911)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3958>
______________________________________


From issues at kolab.org  Tue Nov 24 15:16:00 2009
From: issues at kolab.org (Gunnar Wrobel)
Date: Tue, 24 Nov 2009 14:16:00 +0000
Subject: [Kolab-devel] [issue3960] Left frame in Horde is not updated when
	creating/deleting	IMAP folders
In-Reply-To: <1259072160.6.0.262073683014.issue3960@kolab.org>
Message-ID: <1259072160.6.0.262073683014.issue3960@kolab.org>


New submission from Gunnar Wrobel <p at rdus.de>:

>From kolab/issue3856:

After creating new folders these are not shown in the left
navigation bar until an hard reload is triggered in the Browser.

----------
assignedto: wrobel
keyword: web client
messages: 22482
nosy: martin, thomas, wilde, wrobel
priority: minor bug
status: unread
title: Left frame in Horde is not updated when creating/deleting IMAP folders

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3960>
______________________________________


From wilde at intevation.de  Tue Nov 24 19:24:00 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Tue, 24 Nov 2009 19:24:00 +0100
Subject: [Kolab-devel] Brain Dump of the Week: Ideas,
	Plans and Realities ...
In-Reply-To: <200911232154.28310.ml@radoeka.nl> (Richard Bos's message of
	"Mon, 23 Nov 2009 21:54:27 +0100")
References: <s7w8we5rwne.fsf@intevation.de> <200911172247.05037.ml@radoeka.nl>
	<s7wpr7gyxah.fsf@intevation.de> <200911232154.28310.ml@radoeka.nl>
Message-ID: <s7w3a43lr27.fsf@intevation.de>

Richard Bos <ml at radoeka.nl> writes:
> Op woensdag 18 november 2009 10:52:54 schreef Sascha Wilde:
>> > What do you mean with a polished and shiny UI?
>>
>> I mean a UI that can compete with other groupware web clients, in terms
>> of the user experience.  That means: interactivity, speed and a modern
>> look and feel.  Good web applications these days do nearly match native
>> clients in these respects.  Users (and customers for that matter) know
>> this, they have seen and often used web applications like those of
>> google, zarafa or open-exchange for example and they expect us to
>> provide something comparable.
>
> Something like this? :
> http://www.siriusit.co.uk/labs/2009/roundcube-the-worlds-coolest-open-source-webmail-project/

From a quick glance over the screen shots (I haven't found an online
demo), yes.  Only that we would need a nice calendar (and address book,
and ...), too.  But I think, you got the idea!  :)

cheers
sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091124/cf487c79/attachment.bin

From wilde at intevation.de  Tue Nov 24 19:26:59 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Tue, 24 Nov 2009 19:26:59 +0100
Subject: [Kolab-devel] Brain Dump of the Week: Ideas,
	Plans and	Realities ...
In-Reply-To: <20091123172749.956249c6qz27xbms@webmail.pardus.de> (Gunnar
	Wrobel's message of "Mon, 23 Nov 2009 17:27:49 +0100")
References: <s7w8we5rwne.fsf@intevation.de> <200911172247.05037.ml@radoeka.nl>
	<200911191553.09590.bernhard@intevation.de>
	<200911192232.16069.benoit.mortier@opensides.be>
	<20091123172749.956249c6qz27xbms@webmail.pardus.de>
Message-ID: <s7wy6lvkccs.fsf@intevation.de>

Gunnar Wrobel <wrobel at pardus.de> writes:
[quoting deleted]

That's what I call a concise comment! ;-)  SCNR.

sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091124/63084f55/attachment.bin

From wilde at intevation.de  Tue Nov 24 19:40:47 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Tue, 24 Nov 2009 19:40:47 +0100
Subject: [Kolab-devel] How to test the Kolab server
In-Reply-To: <20091124000129.119945cjqgdmxrok@webmail.pardus.de> (Gunnar
	Wrobel's message of "Tue, 24 Nov 2009 00:01:29 +0100")
References: <s7w8we5rwne.fsf@intevation.de> <200911172247.05037.ml@radoeka.nl>
	<20091123172740.11291pr4oo2owizo@webmail.pardus.de>
	<960738410911231431g111e16cp279a08aa7b2823c1@mail.gmail.com>
	<20091124000129.119945cjqgdmxrok@webmail.pardus.de>
Message-ID: <s7wtywjkbps.fsf@intevation.de>

Gunnar Wrobel <wrobel at pardus.de> writes:
>> See: http://svn.debian.org/wsvn/pkg-kolab/pkg-kolab_testsuite/testsuite

> Wow, cool. Thanks!

I agree, its very cool to see useful stuff like this to emerge from the
community.  Thanks for sharing!

> @Thomas: I know you had your own ideas in that direction. Can you join
> the discussion and maybe give some hints on whether this would be a
> move into the right direction? Thanks!

Yes, we are working on an automated build server and we will definitely
evaluate this code.  But as we are currently heading for the 2.2.3
release and I myself will be on holidays next week it will take some
time before we can do so, sorry...  :-(  I hope we can revive this topic
by mid December.

cheers
sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091124/bf95740e/attachment.bin

From ml at radoeka.nl  Tue Nov 24 19:59:26 2009
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 24 Nov 2009 19:59:26 +0100
Subject: [Kolab-devel] Brain Dump of the Week: Ideas,
	Plans and Realities ...
In-Reply-To: <s7w3a43lr27.fsf@intevation.de>
References: <s7w8we5rwne.fsf@intevation.de> <200911232154.28310.ml@radoeka.nl>
	<s7w3a43lr27.fsf@intevation.de>
Message-ID: <200911241959.26777.ml@radoeka.nl>

Op dinsdag 24 november 2009 19:24:00 schreef Sascha Wilde:
> > Something like this? :
> > http://www.siriusit.co.uk/labs/2009/roundcube-the-worlds-coolest-open-sou
> >rce-webmail-project/
>
> From a quick glance over the screen shots (I haven't found an online
> demo), yes.  Only that we would need a nice calendar (and address book,
> and ...), too.  But I think, you got the idea!  :)

I just saw that my ISP was listed among the listed installation.  Hence I had 
the possibility to try it out (it's not the default webmailer for this 
provider) :)  Conclusion, it works as expected for the short that I used it.  
I missed however the possibility to group emails.

From the before mentioned webpage:
6) Do you have ambitions to extend Roundcube to offer a groupware 
functionality like calendaring in the core application?

A: No, we personally don?t have such ambitions but the plugin API should make 
it possible to extend a Roundcube installation with such features.
There are already other sophisticated open source solutions for groupware and 
we don?t want to compete with them. We?d rather see a couple integrations.
----------

Looks like some work is needed...

-- 
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kolab.org/pipermail/kolab-devel/attachments/20091124/d05c2391/attachment.html

From wrobel at pardus.de  Tue Nov 24 21:06:23 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 24 Nov 2009 21:06:23 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <20091124112336.627744926.thomas@intevation.de>
References: <20091020172924.577027525.thomas@intevation.de>
	<20091116232903.184470z9qm8t1cg8@webmail.pardus.de>
	<20091124000646.133563d7ga1eg680@webmail.pardus.de>
	<20091124112336.627744926.thomas@intevation.de>
Message-ID: <20091124210623.10962hqtw9tktscg@webmail.pardus.de>

Hi Thomas,

thanks for the update.

Quoting Thomas Arendsen Hein <thomas at intevation.de>:

[snip]

> Gunnar (wrobel):
>   kolab/issue3856 (IMP/DIMP folder navigator does not allow  
> creating/deleting/... mail folders)
>     (partly fixed: new folders are not shown until next login)
>   kolab/issue3594 (Mail containing NUL byte not delivered, Kolab  
> Filter does not report lmtp error)
>     (better handling of lmtp errors by kolab filter)
>   kolab/issue3952 (Version in kolabconf is not replaced in the build process)
>   Verify/apply patches from Univention (e.g. SyncML issues)

I think I'm done with those. Of course some things might come back  
from testing. Hopefully not.

I'm tempted to move to Kolab-Server-2.3 now. Though I'm certain you  
still find a few things that are urgent for 2.2.3 :)

In any case I believe there won't be many targets left by the end of  
next week. When do you think we might start building/packaging 2.2.3?

Cheers,

Gunnar


-- 
______ 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 <<
--------------------------------------------------------------------

-------------- 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/20091124/fa61e32b/attachment-0001.bin

From thomas at intevation.de  Wed Nov 25 09:22:23 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Wed, 25 Nov 2009 09:22:23 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <20091124210623.10962hqtw9tktscg@webmail.pardus.de>
References: <20091020172924.577027525.thomas@intevation.de>
	<20091116232903.184470z9qm8t1cg8@webmail.pardus.de>
	<20091124000646.133563d7ga1eg680@webmail.pardus.de>
	<20091124112336.627744926.thomas@intevation.de>
	<20091124210623.10962hqtw9tktscg@webmail.pardus.de>
Message-ID: <20091125091114.022422160.thomas@intevation.de>

* Gunnar Wrobel <wrobel at pardus.de> [20091124 21:06]:
> Quoting Thomas Arendsen Hein <thomas at intevation.de>:
>> Gunnar (wrobel):
>>   kolab/issue3856 (IMP/DIMP folder navigator does not allow  
>> creating/deleting/... mail folders)
>>     (partly fixed: new folders are not shown until next login)
>>   kolab/issue3594 (Mail containing NUL byte not delivered, Kolab  
>> Filter does not report lmtp error)
>>     (better handling of lmtp errors by kolab filter)
>>   kolab/issue3952 (Version in kolabconf is not replaced in the build process)
>>   Verify/apply patches from Univention (e.g. SyncML issues)
>
> I think I'm done with those. Of course some things might come back from 
> testing. Hopefully not.

One thing already is: kolab/issue3499

I'll add the current TODO at the end.

> I'm tempted to move to Kolab-Server-2.3 now. Though I'm certain you  
> still find a few things that are urgent for 2.2.3 :)

I probably will. For HEAD I think bringing everything that is in
kolab_2_2_branch into HEAD is the most important thing now.

I got some comments regarding minor problems (more usability issues
than a defect) in the web client, but I did not create public issues
for those yet.

> In any case I believe there won't be many targets left by the end of  
> next week. When do you think we might start building/packaging 2.2.3?

With much help from Kalle (khruskowski in the tracker) a bunch of
issues on testing could be set to resolved and so far it looks good.

But there are still many 2.2.3-targets on my list to do. Maybe I can
pass some of those (e.g. issue1340) over to you?

One of those things is finding the bogus event or contact from
kolab/issue3751 so you can make the web client (and probably
resource manager) understand or ignore it.

Regards,
Thomas

Here's the current TODO list:

Thomas (thomas):
  small effort:
    switch imapd databases back from berkeley to skiplist
      (skiplist has proven to cause less performance and stability issues)
    kolab/issue3951 (kolabconf -n (noreload) restarts services if RUNONCHANGE is used)
      (rbos provided a patch)
    kolab/issue3513 (Clamav - new upstream version 0.95.3)
      (needs cleanup: release-notes, Makefile)
    kolab/issue3594 (Mail containing NUL byte not delivered, Kolab Filter does not report lmtp error)
      (Use "message_reject_characters = \0")
    kolab/issue3838 (no logging for pop3)
      (small change in imapd package required)
    kolab/issue1448 (Users might add an account on the nonHome Server and write emails in there.)
      (probably just adjust ACLs)
    kolab/issue3895 (Openldap: loglevel should be set to none in slapd.conf)
      (small change, big benefit)
    kolab/issue3938 (compiling procmail fails on Fedora 11 and Ubuntu karmic)
      (updated OpenPKG package available)
    kolab/issue3940 (Deleting users does not work if master Kolab server is not master LDAP)
      (workaround exists, needs real fix)
  larger effort:
    (no public issue) Option to restrict MDNs to local server
      (new feature, but requested by customer)
    kolab/issue3751 (Empty page in Firefox instead of login screen)
      (caused by a broken event or contact, needs further investigation)
    kolab/issue3138 (problems with server upgrade from sarge to etch)
      (we have done this a couple of times from sarge or etch to lenny now)
    kolab/issue1340 (RFC: restrict users to sending mail only to internal recipients)
      (new feature, but requested by customers)

Gunnar (wrobel):
  kolab/issue3499 (creating/modifying users with special characters in name confuses web admin)
    (was already "testing", but the problem still persists)

Sascha (wilde):
  kolab/issue973 (Rewritten from shown inconveniently in kontact)
    (patch for server-side available)

maybe:
  kolab/issue2991 (The Kolab web client is always in the privileged networks)
  kolab/issue2919 (domain maintainer can't edit quota of his users)
  kolab/issue3445 (web client does not work with Konqueror)
  kolab/issue3567 (Migrate Horde prefs 2.2.0 -> 2.2.1, 2.2.2)
    (requested by many people, though not customers)
  improve build process:
  - Makefile target for 2.2.2 -> 2.2.3
  - SHA1 checksums for things downloaded during build process

And as usual, many of the issues which were fixed recently need testing.
Link for all server and web client issues on testing:
https://issues.kolab.org/issue?:columns=title,id,keyword&:group=priority&:filter=keyword,status&status=6&keyword=1,19

Some of the issues that need testing are:
  kolab/issue919  (kolab server has problems with some characters in passwords)
  kolab/issue2499 (Notification messages by the resource manager should be localized)
  kolab/issue3846 (fix recurring events that are counted per week and not per incident)
  kolab/issue3952 (Version in kolabconf is not replaced in the build process)

  kolab/issue3594 (Mail containing NUL byte not delivered, Kolab Filter does not report lmtp error)
    (testing for: better handling of lmtp errors by kolab filter)

-- 
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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091125/2d1303c3/attachment.bin

From issues at kolab.org  Wed Nov 25 11:22:15 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 25 Nov 2009 10:22:15 +0000
Subject: [Kolab-devel] [issue3961] Mail attachment of a task should be
	persistent(rt#5915)
In-Reply-To: <1259144535.99.0.109971571069.issue3961@kolab.org>
Message-ID: <1259144535.99.0.109971571069.issue3961@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

observed with Kontact e35 20091113.1048602-kk1

Test:
1. Open "New Task" dialog.
2. Enter a name.
3. Switch to mail part and D'n'D a mail to the attachment field of the task.
4. Press ok.
=> A new task is created.
5. Open this task. 
6. Double click on the mail.
=> the mail is opened
7. Restart Kontact.
8. Open this task.
9. Double click on the mail.
=> an empty mail is displayed.
I expect that after a restart the task still contains the mail.
The mails should be copied to the task(as the action says)

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22530
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Mail attachment of a task should be persistent(rt#5915)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3961>
______________________________________


From issues at kolab.org  Wed Nov 25 14:51:05 2009
From: issues at kolab.org (Sascha Wilde)
Date: Wed, 25 Nov 2009 13:51:05 +0000
Subject: [Kolab-devel] [issue3962] Names of config variables for "untrusted"
	text missleading
In-Reply-To: <1259157065.96.0.467826883277.issue3962@kolab.org>
Message-ID: <1259157065.96.0.467826883277.issue3962@kolab.org>


New submission from Sascha Wilde <wilde at intevation.de>:

The two variables to configure the text inserted during rewrite of
untrusted from headers are:

$conf['kolab']['filter']['untrusted_subject_insert']
$conf['kolab']['filter']['unauthenticated_subject_insert']

both contain the phrase "subject_insert" but the text is not inserted
into the subject but into the from header.

The quick fix would be to rename them.  But thinking of it I start to
wonder whether the subject might be actually a better place to put
this quite verbose information...

----------
assignedto: wrobel
keyword: filter, server
messages: 22539
nosy: martin, thomas, wilde, wrobel
priority: minor bug
status: unread
title: Names of config variables for "untrusted" text missleading

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3962>
______________________________________


From issues at kolab.org  Wed Nov 25 15:22:11 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 25 Nov 2009 14:22:11 +0000
Subject: [Kolab-devel] [issue3963] Alarm of an recurring task doesn't pop up
	(rt#5891)
In-Reply-To: <1259158931.53.0.302883788933.issue3963@kolab.org>
Message-ID: <1259158931.53.0.302883788933.issue3963@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

tested with Kontact e35 20091113.1048602-kk1

Test of recurring tasks alarm:
1. Create a new task with time, alarm and recurring daily.
   (e.g. 20091125 11:00-12:00, alarm 1 minute before, daily)
2. Close kontact and set the date/time to 20091125 10:57
3. Restart kontact and wait for the alarm.
=> The alarm appears.
4. Close kontact and set the date/time to 20091126 10:57.
5. Restart kontact and wait for the alarm.
=> The alarm doesn't appear.
I expect the alarm to appear in this case and the alarm should appear the
following days.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 22540
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: chatting
title: Alarm of an recurring task doesn't pop up (rt#5891)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3963>
______________________________________


From issues at kolab.org  Wed Nov 25 15:53:19 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 25 Nov 2009 14:53:19 +0000
Subject: [Kolab-devel] [issue3964] An attendee of an event is not informed
	about his role in	the event(rt#5893)
In-Reply-To: <1259160799.18.0.229120938328.issue3964@kolab.org>
Message-ID: <1259160799.18.0.229120938328.issue3964@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

observed with Kontact e35 20091113.1048602-kk1

Test:
1. A sends an invitation to B. B should have the role of a director or observer.
2. B syncs
3. B looks at the invitation.
=> B isn't informed about his role in the event.
I expect that B is informed about his role (and status) of the event.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 22541
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: An attendee of an event is not informed about his role in the event(rt#5893)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3964>
______________________________________


From issues at kolab.org  Wed Nov 25 15:55:38 2009
From: issues at kolab.org (Karl-Heinz Ruskowski)
Date: Wed, 25 Nov 2009 14:55:38 +0000
Subject: [Kolab-devel] [issue3965] Always accept: Invitationmails get lost
	when	Calendarfolder ist not writable for the calendar user
In-Reply-To: <1259160938.29.0.53085173273.issue3965@kolab.org>
Message-ID: <1259160938.29.0.53085173273.issue3965@kolab.org>


New submission from Karl-Heinz Ruskowski <khruskowski at intevation.de>:

Users with 'always accept'-Invitations status will not get any Invitations when
the calendar folder is not writable for the calendar user.

----------
keyword: server
messages: 22542
nosy: khruskowski, thomas, wilde, wrobel
priority: critical
status: unread
title: Always accept: Invitationmails get lost when Calendarfolder ist not writable for the calendar user

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3965>
______________________________________


From issues at kolab.org  Wed Nov 25 16:02:57 2009
From: issues at kolab.org (Saim Kim)
Date: Wed, 25 Nov 2009 15:02:57 +0000
Subject: [Kolab-devel] [issue3966] All day event with "not booked" not
	correctly processed
In-Reply-To: <1259161377.73.0.8278004529.issue3966@kolab.org>
Message-ID: <1259161377.73.0.8278004529.issue3966@kolab.org>


New submission from Saim Kim <s.kim at hia.rwth-aachen.de>:

Hello,

we have recently switched over to kolab 2.2.2 (openpkg) on a 64bit Xeon Quad
core machine. We are experiencing problems with all day events where the user is
not booked aka free, e.g. for birthday events. We have tested both
Outlook/Toltec (2.3.1) and the Horde interface (Dynamic and Traditional) and the
issus is reproducible. 

An allday event with attribute "free/unbooked" is created and an invitation is
send to a ressource (automatic handling is activated). The kolab-filter.log
shows the following error:

Nov 25 14:52:34 Kolab Filter [debug] [horde] Arguments: Horde_Argv_Values Object
(
    [sender] => testuser at test.domain
    [recipient] => Array
        (
            [0] => kalender_medit_wma at test.domain
        )

    [host] => kolab.test.domain
    [client] => 127.0.0.1
    [user] => testuser at test.domain
    [config] => /kolab/etc/kolab/kolabfilter.conf
)
 [on line 244 of "/kolab/lib/php/Horde/Kolab/Filter/Base.php"]
Nov 25 14:52:34 Kolab Filter [info] [horde] Horde_Kolab_Filter_Content
successfully completed (sender=testuser at test.domain,
recipients=kalender_medit_wma at test.domain, client_address=127.0.0.1,
id=<20091125145234.12765lg14rzq2t9e at kolab.test.domain>) [on line 141 of
"/kolab/lib/php/Horde/Kolab/Filter/Base.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Arguments: Horde_Argv_Values Object
(
    [sender] => testuser at test.domain
    [recipient] => Array
        (
            [0] => kalender_medit_wma at test.domain
        )

    [host] => kolab.test.domain
    [client] => 127.0.0.1
    [user] =>
    [config] => /kolab/etc/kolab/kolabfilter.conf
)
 [on line 244 of "/kolab/lib/php/Horde/Kolab/Filter/Base.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Calling
resmgr_filter(kolab.test.domain, testuser at test.domain,
kalender_medit_wma at test.domain, /tmp/IN.Horde_Kolab_Filter_Incoming.OFYHSG) [on
line 144 of "/kolab/lib/php/Horde/Kolab/Filter/Incoming.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Action for testuser at test.domain is
ACT_ALWAYS_ACCEPT [on line 355 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Processing REQUEST method for
kalender_medit_wma at test.domain [on line 387 of
"/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Event has UID
95e59a3d3bfac0d7b686f59865622ecc [on line 392 of
"/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Request made by
testuser at test.domain [on line 397 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converting to epoch Array
(
    [year] => 2009
    [month] => 11
    [mday] => 27
)
 [on line 1074 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converted <1259280000> [on line
1085 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converting to epoch Array
(
    [year] => 2009
    [month] => 11
    [mday] => 28
)
 [on line 1074 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converted <1259366400> [on line
1085 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converting to kolab format
1259280000 [on line 1034 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] To <2009-11-27T00:00:00Z> [on line
1059 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converting to kolab format
1259366400 [on line 1034 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] To <2009-11-28T00:00:00Z> [on line
1059 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Event starts on <1259280000>
2009-11-27T00:00:00Z and ends on <1259366400> 2009-11-28T00:00:00Z. [on line 407
of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converting to epoch Array
(
    [year] => 2009
    [month] => 11
    [mday] => 27
)
 [on line 1074 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converted <1259280000> [on line
1085 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converting to epoch Array
(
    [year] => 2009
    [month] => 11
    [mday] => 28
)
 [on line 1074 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converted <1259366400> [on line
1085 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Assembled event object: Array
(
    [uid] => 95e59a3d3bfac0d7b686f59865622ecc
    [organizer] => Array
        (
            [display-name] => Saim Kim
            [smtp-address] => testuser at test.domain
        )

    [summary] => Test ganztagstermin
    [location] =>
    [body] =>
    [_is_all_day] => 1
    [start-date] => 1259280000
    [end-date] => 1259366400
    [show-time-as] => Array
        (
            [year] => 2009
            [month] => 11
            [mday] => 28
        )

    [attendee] => Array
        (
            [0] => Array
                (
                    [display-name] => Kalender Medit Wma
                    [smtp-address] => kalender_medit_wma at test.domain
                    [request-response] => 1
                    [role] => REQ-PARTICIPANT
                )

        )

)
 [on line 325 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [info] [horde] Adding event
95e59a3d3bfac0d7b686f59865622ecc [on line 568 of
"/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [error] [horde] PHP Error:
DOMDocument::createTextNode() expects parameter 1 to be string, array given;
Code: 0 [on line 146 of "/kolab/lib/php/Horde/Kolab/Filter/Response.php"]
Nov 25 14:52:35 Kolab Filter [error] [horde] PHP Error: Argument 1 passed to
DOMNode::appendChild() must be an instance of DOMNode, null given, called in
/kolab/lib/php/Horde/Kolab/Format/XML.php on line 798 and defined; Code: 0 [on
line 146 of "/kolab/lib/php/Horde/Kolab/Filter/Response.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Arguments: Horde_Argv_Values Object
(
    [sender] =>
    [recipient] => Array  
       (
            [0] => testuser at test.domain
        )

    [host] => kolab.test.domain
    [client] =>
    [user] =>
    [config] => /kolab/etc/kolab/kolabfilter.conf
)
 [on line 244 of "/kolab/lib/php/Horde/Kolab/Filter/Base.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Calling
resmgr_filter(kolab.test.domain, , testuser at test.domain,
/tmp/IN.Horde_Kolab_Filter_Incoming.0CIeD9) [on line 144 of
"/kolab/lib/php/Horde/Kolab/Filter/Incoming.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Action for  is ACT_MANUAL [on line
355 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [info] [horde] Passing through message to
testuser at test.domain [on line 360 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Filter_Incoming successfully
completed. [on line 174 of "/kolab/lib/php/Horde/Kolab/Filter/Incoming.php"]
Nov 25 14:52:35 Kolab Filter [info] [horde] Horde_Kolab_Filter_Incoming
successfully completed (sender=, recipients=testuser at test.domain,
client_address=, id=<20091125135235.78CF4F69C1 at kolab.test.domain>) [on line 141
of "/kolab/lib/php/Horde/Kolab/Filter/Base.php"]



Also an error email is send to the user:

Reporting-MTA: dns; kolab.test.domain
X-Postfix-Queue-ID: A23B0F69B5
X-Postfix-Sender: rfc822; testuser at test.domain
Arrival-Date: Wed, 25 Nov 2009 15:44:40 +0100 (CET)

Final-Recipient: rfc822; kalender_medit_wma at test.domain
Original-Recipient: rfc822;kalender_medit_wma at test.domain
Action: failed
Status: 5.3.0
Diagnostic-Code: x-unix; unknown mail system error 255



The php error seems to react on the line:
[show-time-as] => Array

Nov 25 14:52:35 Kolab Filter [error] [horde] PHP Error:
DOMDocument::createTextNode() expects parameter 1 to be string, array given;
Code: 0 [on line 146 of "/kolab/lib/php/Horde/Kolab/Filter/Response.php"]
Nov 25 14:52:35 Kolab Filter [error] [horde] PHP Error: Argument 1 passed to
DOMNode::appendChild() must be an instance of DOMNode, null given, called in
/kolab/lib/php/Horde/Kolab/Format/XML.php on line 798 and defined; Code: 0 [on
line 146 of "/kolab/lib/php/Horde/Kolab/Filter/Response.php"]

Is that a known bug?

----------
files: Kolab_whole_day_event_free_bug.txt
messages: 22544
nosy: sojakim
priority: bug
status: unread
title: All day event with "not booked" not correctly processed

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3966>
______________________________________
-------------- next part --------------
Nov 25 14:52:34 Kolab Filter [debug] [horde] Arguments: Horde_Argv_Values Object
(
    [sender] => s.kim at medit.intern
    [recipient] => Array
        (
            [0] => kalender_medit_wma at medit.intern
        )

    [host] => kolab.medit.intern
    [client] => 127.0.0.1
    [user] => s.kim at medit.intern
    [config] => /kolab/etc/kolab/kolabfilter.conf
)
 [on line 244 of "/kolab/lib/php/Horde/Kolab/Filter/Base.php"]
Nov 25 14:52:34 Kolab Filter [info] [horde] Horde_Kolab_Filter_Content successfully completed (sender=s.kim at medit.intern, recipients=kalender_medit_wma at medit.intern, client_address=127.0.0.1, id=<20091125145234.12765lg14rzq2t9e at kolab.medit.intern>) [on line 141 of "/kolab/lib/php/Horde/Kolab/Filter/Base.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Arguments: Horde_Argv_Values Object
(
    [sender] => s.kim at medit.intern
    [recipient] => Array
        (
            [0] => kalender_medit_wma at medit.intern
        )

    [host] => kolab.medit.intern
    [client] => 127.0.0.1
    [user] =>
    [config] => /kolab/etc/kolab/kolabfilter.conf
)
 [on line 244 of "/kolab/lib/php/Horde/Kolab/Filter/Base.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Calling resmgr_filter(kolab.medit.intern, s.kim at medit.intern, kalender_medit_wma at medit.intern, /tmp/IN.Horde_Kolab_Filter_Incoming.OFYHSG) [on line 144 of "/kolab/lib/php/Horde/Kolab/Filter/Incoming.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Action for s.kim at medit.intern is ACT_ALWAYS_ACCEPT [on line 355 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Processing REQUEST method for kalender_medit_wma at medit.intern [on line 387 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Event has UID 95e59a3d3bfac0d7b686f59865622ecc [on line 392 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Request made by s.kim at medit.intern [on line 397 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converting to epoch Array
(
    [year] => 2009
    [month] => 11
    [mday] => 27
)
 [on line 1074 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converted <1259280000> [on line 1085 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converting to epoch Array
(
    [year] => 2009
    [month] => 11
    [mday] => 28
)
 [on line 1074 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converted <1259366400> [on line 1085 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converting to kolab format 1259280000 [on line 1034 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] To <2009-11-27T00:00:00Z> [on line 1059 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converting to kolab format 1259366400 [on line 1034 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] To <2009-11-28T00:00:00Z> [on line 1059 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Event starts on <1259280000> 2009-11-27T00:00:00Z and ends on <1259366400> 2009-11-28T00:00:00Z. [on line 407 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converting to epoch Array
(
    [year] => 2009
    [month] => 11
    [mday] => 27
)
 [on line 1074 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converted <1259280000> [on line 1085 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converting to epoch Array
(
    [year] => 2009
    [month] => 11
    [mday] => 28
)
 [on line 1074 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Converted <1259366400> [on line 1085 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Assembled event object: Array
(
    [uid] => 95e59a3d3bfac0d7b686f59865622ecc
    [organizer] => Array
        (
            [display-name] => Saim Kim
            [smtp-address] => s.kim at medit.intern
        )

    [summary] => Test ganztagstermin
    [location] =>
    [body] =>
    [_is_all_day] => 1
    [start-date] => 1259280000
    [end-date] => 1259366400
    [show-time-as] => Array
        (
            [year] => 2009
            [month] => 11
            [mday] => 28
        )

    [attendee] => Array
        (
            [0] => Array
                (
                    [display-name] => Kalender Medit Wma
                    [smtp-address] => kalender_medit_wma at medit.intern
                    [request-response] => 1
                    [role] => REQ-PARTICIPANT
                )

        )

)
 [on line 325 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [info] [horde] Adding event 95e59a3d3bfac0d7b686f59865622ecc [on line 568 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [error] [horde] PHP Error: DOMDocument::createTextNode() expects parameter 1 to be string, array given; Code: 0 [on line 146 of "/kolab/lib/php/Horde/Kolab/Filter/Response.php"]
Nov 25 14:52:35 Kolab Filter [error] [horde] PHP Error: Argument 1 passed to DOMNode::appendChild() must be an instance of DOMNode, null given, called in /kolab/lib/php/Horde/Kolab/Format/XML.php on line 798 and defined; Code: 0 [on line 146 of "/kolab/lib/php/Horde/Kolab/Filter/Response.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Arguments: Horde_Argv_Values Object
(
    [sender] =>
    [recipient] => Array  
       (
            [0] => s.kim at medit.intern
        )

    [host] => kolab.medit.intern
    [client] =>
    [user] =>
    [config] => /kolab/etc/kolab/kolabfilter.conf
)
 [on line 244 of "/kolab/lib/php/Horde/Kolab/Filter/Base.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Calling resmgr_filter(kolab.medit.intern, , s.kim at medit.intern, /tmp/IN.Horde_Kolab_Filter_Incoming.0CIeD9) [on line 144 of "/kolab/lib/php/Horde/Kolab/Filter/Incoming.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Action for  is ACT_MANUAL [on line 355 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [info] [horde] Passing through message to s.kim at medit.intern [on line 360 of "/kolab/lib/php/Horde/Kolab/Resource.php"]
Nov 25 14:52:35 Kolab Filter [debug] [horde] Filter_Incoming successfully completed. [on line 174 of "/kolab/lib/php/Horde/Kolab/Filter/Incoming.php"]
Nov 25 14:52:35 Kolab Filter [info] [horde] Horde_Kolab_Filter_Incoming successfully completed (sender=, recipients=s.kim at medit.intern, client_address=, id=<20091125135235.78CF4F69C1 at kolab.medit.intern>) [on line 141 of "/kolab/lib/php/Horde/Kolab/Filter/Base.php"]

From issues at kolab.org  Wed Nov 25 16:04:58 2009
From: issues at kolab.org (Sascha Wilde)
Date: Wed, 25 Nov 2009 15:04:58 +0000
Subject: [Kolab-devel] [issue3967] UNTRUSTED vs. UNAUTHENTICATED,
	distinction considered harmful
In-Reply-To: <1259161498.12.0.791239496294.issue3967@kolab.org>
Message-ID: <1259161498.12.0.791239496294.issue3967@kolab.org>


New submission from Sascha Wilde <wilde at intevation.de>:

Currently there are two variables to configure the rewrite of From
headers when Mail Filter sender checking is enabled:

$conf['kolab']['filter']['untrusted_subject_insert']
$conf['kolab']['filter']['unauthenticated_subject_insert']

The difference is made by the distinction between untrusted
vs. unauthenticated senders.

While my latest extensive testing for issue973 I was not able to
create a mail, which was rewritten using the untrusted_subject_insert
variant.

The thing is, I don't even know, in what specific case which of the
messages should be used.  I talked to Thomas and even he is not really
sure, we looked a long time hard at the pseudo code in issue954 and at
the diagram based on it in the Kolab Server 2.2 "operating manual" on
http://kolab.org/documentation.html and while there are really exactly
two cases in which the from header is marked untrusted, BUT in both
cases the user is unauthenticated and using two different messages is
more confusing than helpful.

We did some more research in old issues and at least I came to the
conclusion that the existence of two different texts is merely an
accident (or result of considerations which are now obsolete).

So my strong suggestion is we should reduce this to exactly one text
for all cases in which the rewrite takes place.

This is for 2.3 or what ever HEAD will become.

----------
assignedto: thomas
keyword: filter, server
messages: 22546
nosy: martin, thomas, wilde, wrobel
priority: bug
status: unread
title: UNTRUSTED vs. UNAUTHENTICATED, distinction considered harmful

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3967>
______________________________________


From issues at kolab.org  Wed Nov 25 16:18:00 2009
From: issues at kolab.org (Sascha Wilde)
Date: Wed, 25 Nov 2009 15:18:00 +0000
Subject: [Kolab-devel] [issue3968] Text in Mail Filter Settings misleading
In-Reply-To: <1259162280.8.0.361289302706.issue3968@kolab.org>
Message-ID: <1259162280.8.0.361289302706.issue3968@kolab.org>


New submission from Sascha Wilde <wilde at intevation.de>:

The Mail Filter settings contain the (main) switch
"Check messages for mismatching From header and envelope from."
this description is to generic and by that misleading.  

Following the text every mail with mismatching From header and
envelope sender should be concerned, but this is not the case!

The whole mail filter processing is only relevant if either the From
header or the envelope sender is a local address (my domains).

So the text should be reworked to match the actual functionality.
Kolab/issue954 contains valuable information on the intended behavior
of kolab filter.

This is for 2.3 or what ever HEAD will become...

----------
assignedto: thomas
keyword: server, web admin
messages: 22548
nosy: martin, thomas, wilde, wrobel
priority: bug
status: unread
title: Text in Mail Filter Settings misleading

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3968>
______________________________________


From wilde at intevation.de  Wed Nov 25 18:48:25 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Wed, 25 Nov 2009 18:48:25 +0100
Subject: [Kolab-devel] Brain Dump of the Week: One Filter to Rule Them All!
Message-ID: <s7weinmebrq.fsf@intevation.de>

Hello List!

it seems the last BDotW was a big success, I got positive feedback and
it spawned some interesting discussions, which is great!  So I decided
to found a new tradition by sending the second one.

After the exiting glance into the future of Kolab Server I reported on
last week, I headed back to (not so) boring ordinary business.  ;-)
This meant primarily looking at various open issues making some small
but worthwhile progress...

The last four days I was unavailable to Kolab, as I was busy with some
other urgent projects (including some real fun hacking, but
unfortunately totally unrelated to Kolab) and next week I will be on
holidays.  So today I reentered the race for the 2.2.3 release and took
full power on the one release critical issue Thomas assigned to me:
Issue973.

The issue is about customization of the Mail Filter's "untrusted from"
messages and it's customer requested stuff[0] so I'm especially happy to
announce that I committed what I think is the final solution to the
server_2_2_branch!  (Please do me a favor and don't look at the date of
the initial message in the issue ... D'oh!)

Well, as you see the issue I worked on is related to my good old friend
Kolab Filter, and it wouldn't be the Kolab Filter if working on one
issue wouldn't raise a bunch of questions, resulting most time a few new
issues.  This time was no difference, so say hello to issue3962,
issue3967 and issue3968, accompanied by a new comment in issue954.

The most interesting issues to work on (though both are reserved for the
next major release, i.e. the CVS HEAD) are 
issue3967: "UNTRUSTED vs. UNAUTHENTICATED, distinction considered harmful"
and issue3968: "Text in Mail Filter Settings misleading".

In 3967 I suggest a basic simplification, which I'd like to see
commented on by those interested in the matter (read: go there and write
a short "Yeah, lets do this!").

3968 is a challenge for the ambitious tech writer: the web admin
interface still fails to give a reasonable description what the Kolab
Filter stuff really does.  Unfortunately the flow diagram showing the
functionality in question consists of no less than 14 boxes, showing
about 19 possible code paths, which is not that easy to put in one or
two short and easily understandable sentences.

Finally, for the code divers who like to get their hands dirty I have a
small treat which I didn't even put into an issue yet:  in the file
Content.php of Kolab Filer
(/kolab/lib/php/Horde/Kolab/Filter/Content.php in OpenPKG based Server)
look out for the line: `if (strpos( $fromhdr, $untrusted )===false) {'
(its line number 449 in the latest version from 2.2-branch).  I have a
very bad feeling about that line as I suspect that MIME encoded data is
compared to a plain string there.  Feel free to send patches or proof me
wrong!  :)

That's all folks!

Today I feel like adding the following DISCLAIMER: 

This report is by no means an objective summary of ongoing affords and
status of the kolab server development, it is just a highly subjective
dump of one developers mind on one arbitrary point of time and subject
to change even in the moment of writing.

cheers
and thanks for contributing to everyone,

sascha

[0] For those of you who always wondered what the `kkc' keyword in the
    issue tracker might mean: it marks issues which are related to
    contracted work for customers.  So solving them helps the successful
    future of Kolab in a special way...
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091125/9637c27f/attachment.bin

From wilde at intevation.de  Wed Nov 25 18:50:49 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Wed, 25 Nov 2009 18:50:49 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <20091125091114.022422160.thomas@intevation.de> (Thomas Arendsen
	Hein's message of "Wed, 25 Nov 2009 09:22:23 +0100")
References: <20091020172924.577027525.thomas@intevation.de>
	<20091116232903.184470z9qm8t1cg8@webmail.pardus.de>
	<20091124000646.133563d7ga1eg680@webmail.pardus.de>
	<20091124112336.627744926.thomas@intevation.de>
	<20091124210623.10962hqtw9tktscg@webmail.pardus.de>
	<20091125091114.022422160.thomas@intevation.de>
Message-ID: <s7waayaebnq.fsf@intevation.de>

Thomas Arendsen Hein <thomas at intevation.de> writes:
> Sascha (wilde):
>   kolab/issue973 (Rewritten from shown inconveniently in kontact)
>     (patch for server-side available)

[x] done, waiting for Kalle to do a independent test -- but I'm
    unusually confident that we got it right this time.

sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091125/40423f48/attachment.bin

From wilde at intevation.de  Wed Nov 25 18:54:23 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Wed, 25 Nov 2009 18:54:23 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <20091125091114.022422160.thomas@intevation.de> (Thomas Arendsen
	Hein's message of "Wed, 25 Nov 2009 09:22:23 +0100")
References: <20091020172924.577027525.thomas@intevation.de>
	<20091116232903.184470z9qm8t1cg8@webmail.pardus.de>
	<20091124000646.133563d7ga1eg680@webmail.pardus.de>
	<20091124112336.627744926.thomas@intevation.de>
	<20091124210623.10962hqtw9tktscg@webmail.pardus.de>
	<20091125091114.022422160.thomas@intevation.de>
Message-ID: <s7w638yebhs.fsf@intevation.de>

Thomas Arendsen Hein <thomas at intevation.de> writes:
> Thomas (thomas):
>   small effort:
[...]
>     kolab/issue3594 (Mail containing NUL byte not delivered, Kolab Filter does not report lmtp error)
>       (Use "message_reject_characters = \0")

I'll look into this next.

sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091125/72c0491a/attachment.bin

From issues at kolab.org  Wed Nov 25 21:23:26 2009
From: issues at kolab.org (Bernhard Reiter)
Date: Wed, 25 Nov 2009 20:23:26 +0000
Subject: [Kolab-devel] [issue3969] two offline warning windows - that might
	overlap and lock
In-Reply-To: <1259180606.7.0.417728838737.issue3969@kolab.org>
Message-ID: <1259180606.7.0.417728838737.issue3969@kolab.org>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Got a report that with e35 20091030,
warning coming when in offline mode can be a problem.
Two of them come up and might overlap so the machine looks broken.
 
The options in the dimap account are:
* Check mail on startup
* Enable intevall mail checking
  15 minutes

When starting up in offline mode without network connection,
the issue shall appear (sorry I cannot test currently, as obviously I cannot 
test this via a remote connection, but because the case is critical, I am 
still writing the issue.)

----------
assignedto: allen
keyword: enterprise35
messages: 22556
nosy: allen, bernhard, ludwig, till
priority: critical
status: unread
title: two offline warning windows - that might overlap and lock

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3969>
______________________________________


From issues at kolab.org  Thu Nov 26 10:44:45 2009
From: issues at kolab.org (Bernhard Reiter)
Date: Thu, 26 Nov 2009 09:44:45 +0000
Subject: [Kolab-devel] [issue3970] Automatic backtrace should be
	configureable (rt#5871)
In-Reply-To: <1259228685.84.0.276488708588.issue3970@kolab.org>
Message-ID: <1259228685.84.0.276488708588.issue3970@kolab.org>


New submission from Bernhard Reiter <bernhard at intevation.de>:

Some users are not using the backtrace facility often, as they might
not find the button or might not know about it.
For some systemadministrators it would be helpful if they could 
configure the following behaviour:

* If a kcrash dialog comes up, directly and automatically start the backtrace.
  (The user is able to interrupt it of course, if they do not want to wait
   for whatever reason.)
* A directory where the backtrace is placed by default and automatically.
* Some text pieces

So if a crash occurs and the user is not in front of the machine,
if he or she comes back there will be just a screen saying something
along the lines: Kontact had crashed ... a backtrace X-20091126-1 was saved
to dir Y. Z (Default: Notify your system administration.)

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, enterprise5, kde client, kkc
messages: 22576
nosy: allen, bernhard, emanuel, ludwig, till, tmcguire
priority: bug
status: unread
title: Automatic backtrace should be configureable (rt#5871)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3970>
______________________________________


From issues at kolab.org  Thu Nov 26 13:01:54 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 26 Nov 2009 12:01:54 +0000
Subject: [Kolab-devel] [issue3971] Users dislike the "Cannot edit
	attachment" error	message(rt#5908)
In-Reply-To: <1259236914.19.0.0950081424516.issue3971@kolab.org>
Message-ID: <1259236914.19.0.0950081424516.issue3971@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

observed with Kontact e35 20091113.1048602-kk1

Test:
1. Open an composer.
2. Add an png attachment.
3. Double click on the attachment 
4. Select a fitting view program.
=> An error message: "Cannot edit attachment" appears.
Users dislike this error message. Remove it or make it configurable that it
doesn't appear in this case. (Checkbox with: Don't show this message again).

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22579
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Users dislike the "Cannot edit attachment" error message(rt#5908)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3971>
______________________________________


From issues at kolab.org  Thu Nov 26 14:18:57 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 26 Nov 2009 13:18:57 +0000
Subject: [Kolab-devel] [issue3973] Improvement of the German calendar import
	menu	texts(rt#5812)
In-Reply-To: <1259241537.5.0.262750073536.issue3973@kolab.org>
Message-ID: <1259241537.5.0.262750073536.issue3973@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

observed with kontact e35 20091113.1048602-kk1

Replace in the pull-down menu of the calendar part(German):
Datei->Importieren->Kalender importieren...
with
Datei->Importieren->Kalender/Termin (ICS-/VCS-Datei) importieren...

Replace in the import dialog every
Kalender
with 
Kalender/Termin 

Replace in the pull down menu:
Datei->Importieren->Aus UNIX-Ical Werkzeug importieren
with
Datei->Importieren->Aus UNIX-Ical (.calendar-Datei) importieren...

If no .calendar file exists after selecting Unix ical tool, the error message
should be:
Keine .calendar-Datei im Heimatverzeichnis gefunden.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22581
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Improvement of the German calendar import menu texts(rt#5812)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3973>
______________________________________


From issues at kolab.org  Thu Nov 26 14:31:32 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 26 Nov 2009 13:31:32 +0000
Subject: [Kolab-devel] [issue3974] Clicking on an ics/vcs-attachment doesn't
	import or	display the events of the attachment(rt#5812)
In-Reply-To: <1259242292.01.0.656171454477.issue3974@kolab.org>
Message-ID: <1259242292.01.0.656171454477.issue3974@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

observed with Kontact e35 20091113.1048602-kk1

Test:
1. Export an ics or vcs calendar file.
2. Create a mail with this file as attachment.
3. Look at this mail
4. Double click or RMB->open this ics/vcs attachment.
=> Kontact switches to korganizer, but doesn't display or import the events of
this file.
I think in this case it should be asked, if this file should be imported.
And then imported, if answered with yes.

Please estimate and wait on okay before implementing it.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22582
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Clicking on an ics/vcs-attachment doesn't import or display the events of the attachment(rt#5812)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3974>
______________________________________


From issues at kolab.org  Thu Nov 26 15:27:15 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 26 Nov 2009 14:27:15 +0000
Subject: [Kolab-devel] [issue3975] Automatic spellchecking checks
	Mailaddress/ Manual	checking doesn't(rt#5874)
In-Reply-To: <1259245635.2.0.912838722049.issue3975@kolab.org>
Message-ID: <1259245635.2.0.912838722049.issue3975@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

observed with Kontact 20091113.1048602-kk1

Automatic spellchecking works different then the manual spellchecking. (e. g. at
email addresses). So the auto spellchecking is marking some text red, but the
manual spellchecking is not showing a mistake.

Test:
1. Open a composer.
2. Using Auto spellchecking with Standard German.
3. Enter: "E-Mail: test at test.com"
=> Both test are displayed in red.
4. Activate the manual spellchecking (Tools->Spellchecking...)
=> An information is displayed: No error found.
This is confusing for the users.

Is there a way how to solve this?

Please estimate and wait on okay before implementing it.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22586
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Automatic spellchecking checks Mailaddress/ Manual checking doesn't(rt#5874)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3975>
______________________________________


From issues at kolab.org  Thu Nov 26 15:37:11 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 26 Nov 2009 14:37:11 +0000
Subject: [Kolab-devel] [issue3976] Entering words into the dictonary while
	manual	spellchecking are recognised from the Automatic
	spellchecking	after a restart.(rt#5874)
In-Reply-To: <1259246231.64.0.841536248263.issue3976@kolab.org>
Message-ID: <1259246231.64.0.841536248263.issue3976@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

observed with Kontact e35 20091113.1048602-kk1

Test:
1. Open a composer.
2. Enter a text with an word which is not in the dictionary.
3. Manual spellchecking->Add word into dictionary.
=> The word is still red. Users expect that the word is now black, because they
entered into the dict.
4. Restart kontact.
5. Open a composer.
3. Enter the text with this word again.
=> Now the word is black.

It seems like the dictionary of the automatic spellchecking is not updated.

Please estimate and wait on an okay before implementing it.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22588
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Entering words into the dictonary while manual spellchecking are recognised from the Automatic spellchecking after a restart.(rt#5874)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3976>
______________________________________


From issues at kolab.org  Thu Nov 26 15:37:12 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 26 Nov 2009 14:37:12 +0000
Subject: [Kolab-devel] [issue3977] Entering words into the dictonary while
	manual	spellchecking are recognised from the Automatic
	spellchecking	after a restart.(rt#5874)
In-Reply-To: <1259246232.85.0.490584780096.issue3977@kolab.org>
Message-ID: <1259246232.85.0.490584780096.issue3977@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

observed with Kontact e35 20091113.1048602-kk1

Test:
1. Open a composer.
2. Enter a text with an word which is not in the dictionary.
3. Manual spellchecking->Add word into dictionary.
=> The word is still red. Users expect that the word is now black, because they entered into the dict.
4. Restart kontact.
5. Open a composer.
3. Enter the text with this word again.
=> Now the word is black.

It seems like the dictionary of the automatic spellchecking is not updated.

Please estimate and wait on an okay before implementing it.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22589
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Entering words into the dictonary while manual spellchecking are recognised from the Automatic spellchecking after a restart.(rt#5874)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3977>
______________________________________


From issues at kolab.org  Thu Nov 26 18:08:18 2009
From: issues at kolab.org (Bernhard Reiter)
Date: Thu, 26 Nov 2009 17:08:18 +0000
Subject: [Kolab-devel] [issue3978] Forwarding some emails with an embedded
	email as text	loses some of the text
In-Reply-To: <1259255298.77.0.293704795154.issue3978@kolab.org>
Message-ID: <1259255298.77.0.293704795154.issue3978@kolab.org>


New submission from Bernhard Reiter <bernhard at intevation.de>:

I have an email here. It has an embedded emails.
If forwarded, the text of the embedded email is lost.

Expectation: The text should be there in the new (forwarded) email.
Reproduced with Version: 4:3.5.10.enterprise.0.20091103.1044299-kk1
reported also for 20091030. I have a non-public example case which I will email 
to Allen and Till.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22599
nosy: allen, bernhard, ludwig, till, tmcguire
priority: critical
status: chatting
title: Forwarding some emails with an embedded email as text loses some of the text

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3978>
______________________________________


From issues at kolab.org  Fri Nov 27 08:42:31 2009
From: issues at kolab.org (Richard Bos)
Date: Fri, 27 Nov 2009 07:42:31 +0000
Subject: [Kolab-devel] [issue3979] Confusing /root in the output of
	kolab_bootstrap
In-Reply-To: <1259307751.95.0.606559215911.issue3979@kolab.org>
Message-ID: <1259307751.95.0.606559215911.issue3979@kolab.org>


New submission from Richard Bos <ml at radoeka.nl>:

During the execution of kolab_bootstrap -b including the creation of keys the
following output is seen:
-----
writing new private key to '/etc/kolab/ca/private/cakey.pem'
Request is in /etc/kolab/newreq.pem and private key is in /etc/kolab/key.pem

Data Base Updated
Signed certificate is in /etc/kolab/cert.pem
/root
chgrp pki /etc/kolab/key.pem /etc/kolab/cert.pem
chmod 0640 /etc/kolab/key.pem /etc/kolab/cert.pem
cp /etc/kolab/ca/cacert.pem /etc/kolab/kolabserver-ca.crt && chmod 0644
/etc/kolab/kolabserver-ca.crt
CA and certificate creation complete.

################################################################################
# Please import /etc/kolab/kolabserver-ca.crt on your clients
# to allow them to verify the validity of your server certificates.
################################################################################
-----

Please note the /root half way the output.

Left me wondering, what is it doing there?  Is something wrong??  Some
investigation reveals that the kolab_ca.sh script ends with:
  cd -
which reports where it lands (goes to).

The attached simple patch fixes this.  Is it okay to commit?

----------
files: kolab_ca.sh.patch
keyword: server
messages: 22607
nosy: mathieu.parent, rbos, thomas, wilde, wrobel
priority: bug
status: unread
title: Confusing /root in the output of kolab_bootstrap

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3979>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kolab_ca.sh.patch
Type: text/x-patch
Size: 502 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091127/a1d81ba7/kolab_ca.sh.bin

From wrobel at pardus.de  Fri Nov 27 10:11:34 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 27 Nov 2009 10:11:34 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <20091125091114.022422160.thomas@intevation.de>
References: <20091020172924.577027525.thomas@intevation.de>
	<20091116232903.184470z9qm8t1cg8@webmail.pardus.de>
	<20091124000646.133563d7ga1eg680@webmail.pardus.de>
	<20091124112336.627744926.thomas@intevation.de>
	<20091124210623.10962hqtw9tktscg@webmail.pardus.de>
	<20091125091114.022422160.thomas@intevation.de>
Message-ID: <20091127101134.10086a15ji39ov0g@webmail.pardus.de>

Quoting Thomas Arendsen Hein <thomas at intevation.de>:

[snip]

> But there are still many 2.2.3-targets on my list to do. Maybe I can
> pass some of those (e.g. issue1340) over to you?

Sure.

>
> One of those things is finding the bogus event or contact from
> kolab/issue3751 so you can make the web client (and probably
> resource manager) understand or ignore it.
>
> Regards,
> Thomas
>

[snip]

>     kolab/issue3138 (problems with server upgrade from sarge to etch)
>       (we have done this a couple of times from sarge or etch to lenny now)
>       (new feature, but requested by customers)
>

And here is my updated list.

Gunnar (wrobel):

     kolab/issue919 (kolab server has problems with some characters in  
passwords
                    (rt#5558))
     (was already "testing", but seems to have been fixed only partially)
     kolab/issue1340 (RFC: restrict users to sending mail only to
                      internal recipients)
     kolab/issue3751 (Empty page in Firefox instead of login screen)
     (caused by a broken event or contact, needs further investigation)
     kolab/issue3499 (creating/modifying users with special characters
                      in name confuses web admin)
     (was already "testing", but the problem still persists)
     kolab/issue3965 (Always accept: invitations get lost when Calendar folder
                      ist not writable for the calendar user)
     (new critical issue)

As long as there is nothing additional coming in I'd say this will be  
finished until 9.12.09.

Cheers,

Gunnar

-- 
______ 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 <<
--------------------------------------------------------------------

-------------- 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/20091127/d2058d79/attachment-0001.bin

From issues at kolab.org  Fri Nov 27 11:06:54 2009
From: issues at kolab.org (Bernhard Reiter)
Date: Fri, 27 Nov 2009 10:06:54 +0000
Subject: [Kolab-devel] [issue3980] Copying a groupware folder needs a
	restart before its	type is detected.
In-Reply-To: <1259316414.33.0.0521387208583.issue3980@kolab.org>
Message-ID: <1259316414.33.0.0521387208583.issue3980@kolab.org>


New submission from Bernhard Reiter <bernhard at intevation.de>:

When copying a folder structure that includes a groupware folders,
the type of the groupware folder in the target will not get recognised
immedeately. After a restart it is.

Reproduced with 
Version: 4:3.5.10.enterprise.0.20091113.1048602-kk2~patched

Found while testing for kolab/issue3747 (Better archiving function for a branch 
(subtree) of folders (rt#5817))

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 22622
nosy: allen, bernhard, ludwig, tmcguire
priority: minor bug
status: unread
title: Copying a groupware folder needs a restart before its type is detected.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3980>
______________________________________


From wilde at intevation.de  Fri Nov 27 18:44:17 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Fri, 27 Nov 2009 18:44:17 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <20091125091114.022422160.thomas@intevation.de> (Thomas Arendsen
	Hein's message of "Wed, 25 Nov 2009 09:22:23 +0100")
References: <20091020172924.577027525.thomas@intevation.de>
	<20091116232903.184470z9qm8t1cg8@webmail.pardus.de>
	<20091124000646.133563d7ga1eg680@webmail.pardus.de>
	<20091124112336.627744926.thomas@intevation.de>
	<20091124210623.10962hqtw9tktscg@webmail.pardus.de>
	<20091125091114.022422160.thomas@intevation.de>
Message-ID: <s7w3a3zlv66.fsf@intevation.de>

Thomas Arendsen Hein <thomas at intevation.de> writes:
>     kolab/issue3895 (Openldap: loglevel should be set to none in slapd.conf)
>       (small change, big benefit)

Did this as a little farewell before my holidays... ;-)

sascha 
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 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: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091127/22afd8f7/attachment.bin

From math.parent at gmail.com  Sat Nov 28 12:14:36 2009
From: math.parent at gmail.com (Mathieu Parent)
Date: Sat, 28 Nov 2009 12:14:36 +0100
Subject: [Kolab-devel] Brain Dump of the Week: Ideas,
	Plans and Realities 	...
In-Reply-To: <s7w8we5rwne.fsf@intevation.de>
References: <s7w8we5rwne.fsf@intevation.de>
Message-ID: <960738410911280314n900cca5j33d5b91d809c0dee@mail.gmail.com>

Hello,


On Tue, Nov 17, 2009 at 4:36 PM, Sascha Wilde <wilde at intevation.de> wrote:
> Hi *,

> 2. Packaging and Distribution Future
>
> (snip)

Benoit pointed me to project-Builder: http://trac.project-builder.org/.

<quote>
Project-Builder.org aims to provide support to the "Continuous
Packaging" approach. The mantra is "Package early, package often".

Project-Builder.org is a tool that helps you build packages for your
application (provided as tar file, or through a configuration
management system such as CVS, Subversion, Mercurial, or Git). It is
able to generate build package skeleton for your project, and with
simple configuration files to generate for up to 50 different tuples
of distributions (name, version, architecture), including Fedora,
Mandriva, OpenSuSE, Debian, Ubuntu, Gentoo, Slackware.

It provides a macro system to help you keep common what needs to stay
common between distributions, and helps you build Virtual Machines
(VMs) (QEMU, KVM) or Virtual environments (VEs) (chroot, rinse) easily
to create native packages for the distributions you want to support.
</quote>

I have not tested it yet. The reference implementation can then be
Gentoo (if source-based distribution is wanted) or another one (Debian
;) ?).


Mathieu Parent


From issues at kolab.org  Mon Nov 30 15:21:22 2009
From: issues at kolab.org (Thomas Ribbrock)
Date: Mon, 30 Nov 2009 14:21:22 +0000
Subject: [Kolab-devel] [issue3981] Better folder selection dialogue for
	"Sent-Mail folder"	message composer
In-Reply-To: <1259590882.63.0.934351081274.issue3981@kolab.org>
Message-ID: <1259590882.63.0.934351081274.issue3981@kolab.org>


New submission from Thomas Ribbrock <itsef-admin at brightsight.com>:

A while back (was it in proko2->enterprise35? Don't remember), the folder
selection dialogues for copying and moving mails were improved quite a lot (e.g.
one can now type a few letters of the name of the folder and the dialogue only
shows matching folders). Unfortunately, the "Sent-Mail folder" selection in the
message composer still uses the old, unwieldy pull-down menu. This menu is very
difficult to use if one as a large number of folders and/or more than one account.

My feature suggestion therefore is: Use the same folder selection here as for
copy/move. In my eyes, this would improve usability quite a bit.

----------
messages: 22651
nosy: itsef_admin
priority: feature
status: unread
title: Better folder selection dialogue for "Sent-Mail folder"  message composer

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3981>
______________________________________


From issues at kolab.org  Mon Nov 30 15:29:36 2009
From: issues at kolab.org (Thomas Ribbrock)
Date: Mon, 30 Nov 2009 14:29:36 +0000
Subject: [Kolab-devel] [issue3982] Automatic,
	recipient-dependent "Sent-Mail" folder selection
In-Reply-To: <1259591376.54.0.340708417145.issue3982@kolab.org>
Message-ID: <1259591376.54.0.340708417145.issue3982@kolab.org>


New submission from Thomas Ribbrock <itsef-admin at brightsight.com>:

Other than Kontact/KMail, I'm using "mutt" quite intensively as my mail client.
mutt has one feature I am missing quite a lot in KMail: Recipient-dependent
"Sent-Mail" folders. KMail per default just drops everything in the same "Sent"
folder and if I do not like that, I have to change it manually for each and
every mail I write. Contrary to this, mutt has two mechanisms: Firstly, it
defaults to storing sent mail to RECIPIENT at DOM.AIN in a folder called
"RECIPIENT". Secondly, I can set "send-hooks" allowing me to fix certain
"Sent-Mail" folders for certain recipients. For KMail, I'd already be extremely
happy if the first part could be implemented, preferably with the improved
"Sent-Mail" folder selection dialogue as proposed in issue3981 . While that
won't cover all cases, it will cover the majority and will also allow "manual
override".

----------
keyword: enterprise35, kde client
messages: 22652
nosy: itsef_admin
priority: feature
status: unread
title: Automatic, recipient-dependent "Sent-Mail" folder selection

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3982>
______________________________________


From issues at kolab.org  Tue Nov 24 14:44:15 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 24 Nov 2009 13:44:15 -0000
Subject: [Kolab-devel] [issue3959] Side-by-Side view without Marcus Bains
	line seperator	displaced(rt#5912)
In-Reply-To: <1259070253.5.0.987783621717.issue3959@kolab.org>
Message-ID: <1259070253.5.0.987783621717.issue3959@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

observed with Kontact e35 20091113.1048602-kk1

Test:
1. Switch to Calendar part.
2. Open configuration dialog
3. Deactivate the Marcus Bains line.
4. Switch to side-by-side view.
5. Deactivate and Activate some resources.
=> the separator of the first folder is displaced against the seperator of the
different folders.

See screenshot.

----------
assignedto: allen
files: view-displaced-20091124.png
keyword: enterprise35, kde client, kkc
messages: 22479
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Side-by-Side view without Marcus Bains line seperator displaced(rt#5912)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3959>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: view-displaced-20091124.png
Type: image/png
Size: 104203 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091124/c8f0827f/view-displaced-20091124-0001.png

From issues at kolab.org  Thu Nov 26 13:53:54 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 26 Nov 2009 12:53:54 -0000
Subject: [Kolab-devel] [issue3972] Event print order will be wrong,
	if recurring and single events are mixed. (rt#5914)
In-Reply-To: <1259240033.71.0.472423625332.issue3972@kolab.org>
Message-ID: <1259240033.71.0.472423625332.issue3972@kolab.org>


New submission from Ludwig Reiter <ludwig at intevation.de>:

observed with Kontact e35 20091113.1048602-kk1

Test:
1. Switch to calendar. 
2. Create a recurring event at 2009-11-25 at 15:00-16:00. Daily Recurrency.
3. Create an event at 2009-11-26 at 10:00-11:00.
4. Print the whole month to a ps file.
At the 26th the 15:00 event is displayed before the 10:00 event.
Expected is: The time order is not broken.

See print2.ps at the 26th.

----------
assignedto: allen
files: print2.ps
keyword: enterprise35, kde client, kkc
messages: 22580
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Event print order will be wrong, if recurring and single events are mixed. (rt#5914)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3972>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: print2.ps
Type: application/postscript
Size: 84907 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091126/e72d8e89/print2-0001.ps