From kolab-issues at intevation.de  Sun Nov  2 22:42:12 2008
From: kolab-issues at intevation.de (Ernestine Fountain)
Date: Sun, 02 Nov 2008 21:42:12 +0000
Subject: [Kolab-devel] [issue3198] Back to School? No
Message-ID: <baea301c93d33$dc29c080$16b2a8c0@MICHA>


New submission from Ernestine Fountain <DiannasapsuckerBetts at ewtn.com>:

No Exams/Books/Tests/Interview/classes     
100% No Pre-School qualif?cation required!

----------
messages: 17414
nosy: "<intevation", "<jonathan", "<news-owner", "<thuban-list-bounces", DiannasapsuckerBetts
status: unread
title: Back to School? No
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3198>
___________________________________________________


From wrobel at pardus.de  Mon Nov  3 05:39:46 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 03 Nov 2008 05:39:46 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab/data quotawarning.txt,
	NONE, 1.1
In-Reply-To: <200810291241.07346.karl-heinz.ruskowski@intevation.de>
References: <20081010142206.C1D15600BAF@lists.intevation.de>
	<200810191132.17486.ml@radoeka.nl>
	<20081029083359.16146wrhnngl5yao@webmail.pardus.de>
	<200810291241.07346.karl-heinz.ruskowski@intevation.de>
Message-ID: <20081103053946.27947behimrrnr80@webmail.pardus.de>

Quoting Karl-Heinz Ruskowski <karl-heinz.ruskowski at intevation.de>:

> I had to remove one line in kolabd.spec.in too:
>
> Index: kolabd.spec.in
> ===================================================================
> RCS
> file:  
> /home/kroupware/jail/kolabrepository/server/kolabd/kolabd/kolabd.spec.in,v
> retrieving revision 1.33
> diff -u -r1.33 kolabd.spec.in
> --- kolabd.spec.in      18 Sep 2008 19:53:09 -0000      1.33
> +++ kolabd.spec.in      29 Oct 2008 11:38:44 -0000
> @@ -116,7 +116,6 @@
>
>      #   generate file list
>      %{l_rpmtool} files -v -ofiles -r$RPM_BUILD_ROOT %{l_files_std} \
> -       '%config %{l_prefix}/etc/kolab/quotawarning.txt' \
>         '%config %{l_prefix}/etc/kolab/templates/*.template' \
>         %dir '%defattr(-,%{l_nusr},
> %{l_ngrp})' %{l_prefix}/var/kolab/httpd_sessions \
>         %dir '%defattr(-,%{l_nusr},%{l_ngrp})' %{l_prefix}/var/kolab/tmp \

Thanks! Fixed in CVS.

Cheers,

Gunnar

>
> --
> Karl-Heinz Ruskowski |  ++49-541-335 08 30  |  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
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081103/ed7323f6/attachment.bin

From kolab-issues at intevation.de  Mon Nov  3 12:30:50 2008
From: kolab-issues at intevation.de (T. Ribbrock)
Date: Mon, 03 Nov 2008 11:30:50 +0000
Subject: [Kolab-devel] [issue3199] Rebuild of the cache crashes kontact
	(enterprise35)
Message-ID: <1225711850.63.0.562581084881.issue3199@intevation.de>


New submission from T. Ribbrock <itsef-admin at brightsight.com>:

(Split off issue2697, as enterprise35 uses different technology)

After another crash (see issue3106), only a few Tasks were shown in
the task list. I have three accounts (all split IMAP/DIMAP) and checked the
respective folders on the server to find two of them well filled. The local
folders for those accounts showed a bunch of "No Subject" mails plus a few real
tasks - so I decided to rebuild the cache for those two Task folders. In both
cases Kontact crashed - I'll attach the backtraces.

Versions:
kontact --version
Qt: 3.3.8b
KDE: 3.5.9
Kontact: 1.2.9 (enterprise35 20080919.862683)
(Kubuntu 8.04)

For the second crash, I noticed a bunch of messages on the command line, I'll
attach those as well.

----------
files: Crash_on_rebuild_DIMAP_cache-862683.txt
messages: 17415
nosy: itsef_admin
priority: urgent
status: unread
title: Rebuild of the cache crashes kontact (enterprise35)
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3199>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Crash_on_rebuild_DIMAP_cache-862683.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20081103/3b876246/Crash_on_rebuild_DIMAP_cache-862683-0001.txt

From kolab-issues at intevation.de  Mon Nov  3 13:47:58 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 03 Nov 2008 12:47:58 +0000
Subject: [Kolab-devel] [issue3200] New todo ,
	recurrence tab isn't translated into German
Message-ID: <1225716478.75.0.762647656802.issue3200@intevation.de>


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

Kontact-Installer_20081030.exe
Kontact Version 1.3 (enterprise4 0.20081027.876316) Windows
kdelibs-branch 877796
kdepimlibs-branch 877803
kdepim-branch (akgregator and knode older) 877803
i10n-kde4 (no branch) 874638

Test:
1. Switch to the todos plugin
2. Start to create a new todo.
3. Change to the recurrence tab.
It is all in English, not in German as excepted.

----------
assignedto: till
messages: 17419
nosy: bh, ludwig, till
priority: minor bug
status: unread
title: New todo , recurrence tab isn't translated into German
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3200>
___________________________________________________


From kolab-issues at intevation.de  Mon Nov  3 13:52:21 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 03 Nov 2008 12:52:21 +0000
Subject: [Kolab-devel] [issue3201] A todo with enabled recurrence is
	completed after first click on the checkbox
Message-ID: <1225716741.67.0.969032217005.issue3201@intevation.de>


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

Kontact-Installer_20081030.exe
Kontact Version 1.3 (enterprise4 0.20081027.876316) Windows
kdelibs-branch 877796
kdepimlibs-branch 877803
kdepim-branch (akgregator and knode older) 877803
i10n-kde4 (no branch) 874638

Test:
1. Switch to todos plugin.
2. Create a new todo with recurrence enabled.
3. Click on the checkbox of the todo.
Notice: the todo is completed. But this shouldn't happen because of the recurrence.

----------
assignedto: till
messages: 17420
nosy: bh, ludwig, till
priority: bug
status: unread
title: A todo with enabled recurrence is completed after first click on the checkbox
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3201>
___________________________________________________


From kolab-issues at intevation.de  Mon Nov  3 13:56:54 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 03 Nov 2008 12:56:54 +0000
Subject: [Kolab-devel] [issue3202] A todo which is over due is not displayed
	in red.
Message-ID: <1225717014.14.0.0434148014017.issue3202@intevation.de>


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

Kontact-Installer_20081030.exe
Kontact Version 1.3 (enterprise4 0.20081027.876316) Windows
kdelibs-branch 877796
kdepimlibs-branch 877803
kdepim-branch (akgregator and knode older) 877803
i10n-kde4 (no branch) 874638

Test:
1. Switch to todos plugin
2. Create a new todo, with a due date 2 days before the current date.
3. Look at the todos.
Notice the todo is not red, even the todo is overdue.

----------
assignedto: till
messages: 17421
nosy: bh, ludwig, till
priority: bug
status: unread
title: A todo which is over due is not displayed in red.
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3202>
___________________________________________________


From kolab-issues at intevation.de  Mon Nov  3 14:03:29 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 03 Nov 2008 13:03:29 +0000
Subject: [Kolab-devel] [issue3203] The size of an todo created with a mail
	is larger than a normal todo
Message-ID: <1225717409.86.0.617567001023.issue3203@intevation.de>


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

Kontact-Installer_20081030.exe
Kontact Version 1.3 (enterprise4 0.20081027.876316) Windows
kdelibs-branch 877796
kdepimlibs-branch 877803
kdepim-branch (akgregator and knode older) 877803
i10n-kde4 (no branch) 874638

Test:
1. Switch to the Mail plugin.
2. D'n'D a mail on the todo icon and create this todo.
3. Switch to the Todo Plugin.
Notice: The mail todo i larger than the normal todos
(Look at the screenshot large-todo-20081103.png as example)

----------
assignedto: till
files: large-todo-20081103.png
messages: 17422
nosy: bh, ludwig, till
priority: minor bug
status: unread
title: The size of an todo created with a mail is larger than a normal todo
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3203>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: large-todo-20081103.png
Type: image/png
Size: 3076 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081103/8fb19585/large-todo-20081103.png

From kolab-issues at intevation.de  Mon Nov  3 16:55:53 2008
From: kolab-issues at intevation.de (Karl-Heinz Ruskowski)
Date: Mon, 03 Nov 2008 15:55:53 +0000
Subject: [Kolab-devel] [issue3204] kolab_boostrap script has non-perl
	variables in it
Message-ID: <1225727753.03.0.678094653791.issue3204@intevation.de>


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

After building kolab from cvs the kolab_bootstrap still has some buildprocess
variables in it and line 38 has too many quotes: 

#$ bin/kolab_bootstrap -b
Global symbol "@CONFIG_DIR" requires explicit package name at
bin/kolab_bootstrap line 612, <DATA> line 278.
Global symbol "@CONFIG_DIR" requires explicit package name at
bin/kolab_bootstrap line 613, <DATA> line 278.
Global symbol "@CONFIG_DIR" requires explicit package name at
bin/kolab_bootstrap line 802, <DATA> line 278.
Global symbol "@CONFIG_DIR" requires explicit package name at
bin/kolab_bootstrap line 804, <DATA> line 278.
Global symbol "@CONFIG_DIR" requires explicit package name at
bin/kolab_bootstrap line 805, <DATA> line 278.
Global symbol "@CONFIG_DIR" requires explicit package name at
bin/kolab_bootstrap line 806, <DATA> line 278.
Global symbol "@CONFIG_DIR" requires explicit package name at
bin/kolab_bootstrap line 807, <DATA> line 278.
Global symbol "@CONFIG_DIR" requires explicit package name at
bin/kolab_bootstrap line 808, <DATA> line 278.
Global symbol "@ldapserver_rgrp" requires explicit package name at
bin/kolab_bootstrap line 809, <DATA> line 278.
Global symbol "@ldapserver_rgrp" requires explicit package name at
bin/kolab_bootstrap line 811, <DATA> line 278.
Execution of bin/kolab_bootstrap aborted due to compilation errors.

----------
assignedto: wrobel
messages: 17425
nosy: bernhard, khruskowski, martin, thomas, till, wilde, wrobel
priority: critical
status: unread
title: kolab_boostrap script has non-perl variables in it
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3204>
___________________________________________________


From kolab-issues at intevation.de  Mon Nov  3 17:49:19 2008
From: kolab-issues at intevation.de (Sascha Wilde)
Date: Mon, 03 Nov 2008 16:49:19 +0000
Subject: [Kolab-devel] [issue3205] FB in horde while creating events
Message-ID: <1225730959.72.0.568564413373.issue3205@intevation.de>


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

When selecting attendees during creation of new events horde wasn't able to
retrieve fb information.  The attached patch (by Gunnar) helped.

Please investigate if this still needs fixing for 2.2.1.

----------
assignedto: wrobel
files: turba-config.patch
messages: 17426
nosy: bernhard, thomas, wilde, wrobel
priority: bug
status: unread
title: FB in horde while creating events
topic: server, web client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3205>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: turba-config.patch
Type: application/octet-stream
Size: 1341 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081103/f2cd74dd/turba-config.exe

From kolab-issues at intevation.de  Mon Nov  3 17:53:56 2008
From: kolab-issues at intevation.de (Sascha Wilde)
Date: Mon, 03 Nov 2008 16:53:56 +0000
Subject: [Kolab-devel] [issue3206] Horde shouldn't look at folders which are
	(\Noselect \HasNoChildren)
Message-ID: <1225731236.36.0.692358988586.issue3206@intevation.de>


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

During experiments with a new IMAP back end we stmbled across the fact that
horde tries to get annotations (and acls) for folders which are (\Noselect
\HasNoChildren) -- as the client cant do anything meaningful with them anyway
they should be ignored rather than further inspected.

----------
assignedto: wrobel
messages: 17427
nosy: bernhard, thomas, wilde, wrobel
priority: bug
status: unread
title: Horde shouldn't look at folders which are (\Noselect \HasNoChildren)
topic: server, web client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3206>
___________________________________________________


From g.adamczyk at netkult.eu  Tue Nov  4 07:23:14 2008
From: g.adamczyk at netkult.eu (Gregor Adamczyk)
Date: Tue, 04 Nov 2008 07:23:14 +0100
Subject: [Kolab-devel] =?iso-8859-15?q?Danke_f=FCr_Kolab!!!_Thank_you_for_?=
 =?iso-8859-15?q?Kolab!!!?=
Message-ID: <490FEA52.1090808@netkult.eu>

Hallo, habe Kolab nun im t?glichen Einsatz.

Vielen Dank an alle daf?r!!!

Bitte weitermachen...


Mit freundlichen Gr??en
Gregor Adamczyk


From ml at radoeka.nl  Tue Nov  4 14:58:59 2008
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 4 Nov 2008 14:58:59 +0100
Subject: [Kolab-devel] bounced on alias name [Solved]
In-Reply-To: <71fe4e760811040547j73318616x24339aaf4022ef0f@mail.gmail.com>
References: <200811031759.44964.thorsten.schnebeck@gmx.net>
	<200811041430.44370.ml@radoeka.nl>
	<71fe4e760811040547j73318616x24339aaf4022ef0f@mail.gmail.com>
Message-ID: <200811041458.59417.ml@radoeka.nl>

Op Tuesday 04 November 2008 14:47:43 schreef Alain Spineux:
> >> > in /kolab/etc/kolab/templates/amavisd.conf.template, you can modify
> >> > the line
> >> >
> >> > $notify_method = $forward_method; ? ? ? ? ?# where to submit
> >> > notifications
> >> >
> >> > by someting like
> >> >
> >> > $notify_method = 'smtp:@@@local_addr@@@:25'; ? ? # where to submit
> >> > notifications
> >>
> >> Thanks Alain :-)
> >>
> >> works fine.
> >>
> >> Bye
> >>
> >> ? Thorsten
> >
> > Is this a general solution? ?If so, shouldn't an issue be opened in the
> > kolab tracker?
>
> Yes, this is an universal solution !
> I thing I already opened an issue for that, with the solution above

This one:
https://www.intevation.de/roundup/kolab/issue1863 ?

It is still there:
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolabd/kolabd/templates/amavisd.conf.template.in?rev=1.13&content-type=text/vnd.viewcvs-markup

It's easily changed, should it be done???

-- 
Richard Bos
Without a home the journey is endless


From kolab-issues at intevation.de  Tue Nov  4 15:37:05 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Tue, 04 Nov 2008 14:37:05 +0000
Subject: [Kolab-devel] [issue3207] exclusion of a recurrence event is not
	handled correctly
Message-ID: <1225809425.13.0.130890555804.issue3207@intevation.de>


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

enterprise35 kdepim 20081027.876310

Test:
1. Switch to the calendar plugin
2. Create an event with recurrence.
3. Sync.
4. Move one of the recurrence events to a different time as exclusion.
5. Sync.
6. Restart kontact.
Notice: The event is at the old time and hasn't changed.
On the server this event is an exclusion from the recurrence event.
If it is changed a second time, the change is permanent.

----------
assignedto: till
messages: 17430
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: bug
status: unread
title: exclusion of a recurrence event is not handled correctly
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3207>
___________________________________________________


From kolab-issues at intevation.de  Tue Nov  4 22:06:03 2008
From: kolab-issues at intevation.de (=?utf-8?q?Albrecht_Dre=C3=9F?=)
Date: Tue, 04 Nov 2008 21:06:03 +0000
Subject: [Kolab-devel] [issue3208] Free/Busy list is always empty
Message-ID: <1225832763.59.0.729314211418.issue3208@intevation.de>


New submission from Albrecht Dre? <albrecht.dress at lios-tech.com>:

The Kolab 2.2 server is configured to allow unauthenticated download of
free/busy lists.  As I had problems in the past with http 404 errors for the
calendar user, I also applied the patch from issue #3074.

Running the trigger as calendar user works fine (i.e. call
"https://kolab.my-server.de/freebusy/trigger/the.user%40my-company.com/Kalender.pfb"),
and the result looks like:

<snip>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//proko2//freebusy 1.0//EN
METHOD:PUBLISH BEGIN:VFREEBUSY
ORGANIZER;cn=The User:MAILTO:the.user at my-company.com
DTSTAMP:20081030T090125Z
DTSTART:20081029T230000Z
DTEND:20081228T230000Z
FREEBUSY:20081030T140000Z/20081030T143000Z
FREEBUSY:20081030T180000Z/20081030T190000Z
FREEBUSY:20081031T090000Z/20081031T103000Z
FREEBUSY:20081101T230000Z/20081105T230000Z
FREEBUSY:20081111T090000Z/20081111T100000Z
FREEBUSY:20081113T090000Z/20081113T163000Z
FREEBUSY:20081205T180000Z/20081205T220000Z
FREEBUSY:20081219T180000Z/20081219T230000Z
END:VFREEBUSY
END:VCALENDAR
</snip>

However, when I try to read the fb list using
"https://kolab.my-server.de/freebusy/the.user at my-company.com.ifb", the result is
always an empty dummy list:

<snip>
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//proko2//freebusy 1.0//EN
METHOD:PUBLISH
BEGIN:VFREEBUSY
ORGANIZER;cn=The User:MAILTO:the.user at my-company.com
DTSTAMP:20081030T074609Z
URL:http://kolab.my-server.de/freebusy/the.user at my-company.com.ifb
COMMENT:This is a dummy vfreebusy that indicates an empty calendar
FREEBUSY:19700101T000000Z/19700101T000000Z
END:VFREEBUSY
END:VCALENDAR
</snip>

I added more debug information to the file
/kolab/lib/php/Kolab/Freebusy/Cache.php, and apparently in the method
FreeBusyCache::load the statements

        /* Which files will we access? */
        $aclcache = &FreeBusyCacheDB_acl::singleton('acl', $this->_cache_dir);
        $files = $aclcache->get($access->owner);

/always/ result an empty files list unless "anyone" has at least read access to
the respective Calendar/Kalender folder which is obviously not what I want (i.e.
FB lists should be accessible for everyone).

----------
messages: 17432
nosy: albrecht.dress
priority: urgent
status: unread
title: Free/Busy list is always empty
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3208>
___________________________________________________


From aspineux at gmail.com  Tue Nov  4 22:16:45 2008
From: aspineux at gmail.com (Alain Spineux)
Date: Tue, 4 Nov 2008 22:16:45 +0100
Subject: [Kolab-devel] bounced on alias name [Solved]
In-Reply-To: <200811041458.59417.ml@radoeka.nl>
References: <200811031759.44964.thorsten.schnebeck@gmx.net>
	<200811041430.44370.ml@radoeka.nl>
	<71fe4e760811040547j73318616x24339aaf4022ef0f@mail.gmail.com>
	<200811041458.59417.ml@radoeka.nl>
Message-ID: <71fe4e760811041316l603f10b1x7e6583fe59fed6@mail.gmail.com>

On Tue, Nov 4, 2008 at 2:58 PM, Richard Bos <ml at radoeka.nl> wrote:
> Op Tuesday 04 November 2008 14:47:43 schreef Alain Spineux:
>> >> > in /kolab/etc/kolab/templates/amavisd.conf.template, you can modify
>> >> > the line
>> >> >
>> >> > $notify_method = $forward_method;          # where to submit
>> >> > notifications
>> >> >
>> >> > by someting like
>> >> >
>> >> > $notify_method = 'smtp:@@@local_addr@@@:25';     # where to submit
>> >> > notifications
>> >>
>> >> Thanks Alain :-)
>> >>
>> >> works fine.
>> >>
>> >> Bye
>> >>
>> >>   Thorsten
>> >
>> > Is this a general solution?  If so, shouldn't an issue be opened in the
>> > kolab tracker?
>>
>> Yes, this is an universal solution !
>> I thing I already opened an issue for that, with the solution above
>
> This one:
> https://www.intevation.de/roundup/kolab/issue1863 ?

Yes it is

>
> It is still there:
> http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolabd/kolabd/templates/amavisd.conf.template.in?rev=1.13&content-type=text/vnd.viewcvs-markup

Sorry whot do do yo mean

>
> It's easily changed, should it be done???


If a user can send email using one of his alias as sender, or a
distribution list can send email then YES
it should be considered to allow them to receive NDR

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



-- 
Alain Spineux
aspineux gmail com
May the sources be with you


From ml at radoeka.nl  Tue Nov  4 23:35:17 2008
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 4 Nov 2008 23:35:17 +0100
Subject: [Kolab-devel] bounced on alias name [Solved]
In-Reply-To: <71fe4e760811041316l603f10b1x7e6583fe59fed6@mail.gmail.com>
References: <200811031759.44964.thorsten.schnebeck@gmx.net>
	<200811041458.59417.ml@radoeka.nl>
	<71fe4e760811041316l603f10b1x7e6583fe59fed6@mail.gmail.com>
Message-ID: <200811042335.17319.ml@radoeka.nl>

Op Tuesday 04 November 2008 22:16:45 schreef Alain Spineux:
> > This one:
> > https://www.intevation.de/roundup/kolab/issue1863 ?
>
> Yes it is

okay, but according to Thomas this is not the right solution:
"Using port 25 isn't an option, because the mails sent by amavis shouldn't go
through amavis again."
Perhaps you can convince Thomas to implement the patch anyhow, as it is better 
that what there is now.

-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From aspineux at gmail.com  Wed Nov  5 07:47:08 2008
From: aspineux at gmail.com (Alain Spineux)
Date: Wed, 5 Nov 2008 07:47:08 +0100
Subject: [Kolab-devel] bounced on alias name [Solved]
In-Reply-To: <200811042335.17319.ml@radoeka.nl>
References: <200811031759.44964.thorsten.schnebeck@gmx.net>
	<200811041458.59417.ml@radoeka.nl>
	<71fe4e760811041316l603f10b1x7e6583fe59fed6@mail.gmail.com>
	<200811042335.17319.ml@radoeka.nl>
Message-ID: <71fe4e760811042247h51019771r54939e5823c67ca3@mail.gmail.com>

On Tue, Nov 4, 2008 at 11:35 PM, Richard Bos <ml at radoeka.nl> wrote:
> Op Tuesday 04 November 2008 22:16:45 schreef Alain Spineux:
>> > This one:
>> > https://www.intevation.de/roundup/kolab/issue1863 ?
>>
>> Yes it is
>
> okay, but according to Thomas this is not the right solution:
> "Using port 25 isn't an option, because the mails sent by amavis shouldn't go
> through amavis again."
> Perhaps you can convince Thomas to implement the patch anyhow, as it is better
> that what there is now.
>

It should not go through amavis, but It MUST resolve the aliases !
The good solution is to enable alias resolution after amavis,
this can be done by removing the "post-cleanup" in main.cf


@@@local_addr@@@:10026 inet n   -       n       -       -  smtpd
    -o content_filter=
> just remove this line    -o cleanup_service_name=post-cleanup
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_restriction_classes=
    -o smtpd_client_restrictions=
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o mynetworks=127.0.0.0/8
    -o strict_rfc821_envelopes=yes
    -o smtpd_error_sleep_time=0
    -o smtpd_soft_error_limit=1001
    -o smtpd_hard_error_limit=1000



> --
> Richard Bos
> We are borrowing the world of our children,
> It is not inherited from our parents.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
Alain Spineux
aspineux gmail com
May the sources be with you


From kolab-issues at intevation.de  Wed Nov  5 15:48:45 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Wed, 05 Nov 2008 14:48:45 +0000
Subject: [Kolab-devel] [issue3209] Kontact/Mac: no icon in Dock if Kontact
	closed
Message-ID: <1225896525.04.0.620861334025.issue3209@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

If Kontact/Mac is not running and a link to /opt/kde4/bin/kontact.app is placed
in the Dock only a Mac default icon is shown. 

If Kontact is running the correct Kontact icon is shown.

Tested with Kontact/Mac installer 20081105.

----------
assignedto: till
messages: 17438
nosy: emanuel, till
priority: bug
status: unread
title: Kontact/Mac: no icon in Dock if Kontact closed
topic: enterprise4, kde client, macos
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3209>
___________________________________________________


From kolab-issues at intevation.de  Wed Nov  5 16:07:25 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Wed, 05 Nov 2008 15:07:25 +0000
Subject: [Kolab-devel] [issue3210] Kontact/Mac: side bar border to wide
Message-ID: <1225897645.6.0.402386343538.issue3210@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

Start Kontact.
Until you resize the Kontact window the border of the side bar navigation is to
big -> side bar gets scroll bars.
After resizing window border becomes normal width.

Cosmetic bug -> minor priority.

----------
assignedto: till
messages: 17440
nosy: emanuel, till
priority: minor bug
status: unread
title: Kontact/Mac: side bar border to wide
topic: enterprise4, macos
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3210>
___________________________________________________


From kolab-issues at intevation.de  Wed Nov  5 16:13:38 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Wed, 05 Nov 2008 15:13:38 +0000
Subject: [Kolab-devel] [issue3211] Kontact/Mac: KMail settings missing if
	Kontact starts with Mail view
Message-ID: <1225898018.86.0.50206739716.issue3211@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

* Close running Kontact in Mail view(!)
* Restart Kontact (starts in Mail view)
-> Menu "Settings"->"KMail settings" is missing

Change to "Summary" and back to "Mail"
-> Now menu "KMail settings" is shown in menu

----------
assignedto: till
messages: 17441
nosy: emanuel, till
priority: urgent
status: unread
title: Kontact/Mac: KMail settings missing if Kontact starts with Mail view
topic: enterprise4, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3211>
___________________________________________________


From kolab-issues at intevation.de  Wed Nov  5 16:17:23 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Wed, 05 Nov 2008 15:17:23 +0000
Subject: [Kolab-devel] [issue3212] Kontact/Mac: tabs in KMail
	settings->Composer to small
Message-ID: <1225898243.67.0.739278174646.issue3212@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

Open Kmail settings -> Composer:

Tabs to small to show complete titles.
(solution: e.g. 2nd tab row)

----------
assignedto: till
messages: 17442
nosy: emanuel, till
priority: bug
status: unread
title: Kontact/Mac: tabs in KMail settings->Composer to small
topic: enterprise4, macos
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3212>
___________________________________________________


From kolab-issues at intevation.de  Wed Nov  5 16:28:58 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Wed, 05 Nov 2008 15:28:58 +0000
Subject: [Kolab-devel] [issue3213] Kontact/Mac: Kontact name and icon
	missing in "kill application list"
Message-ID: <1225898938.67.0.706635829033.issue3213@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

Run Kontact.
Open "kill application list dialog" with [cmd]+[alt]+[esc].
-> Kontact name and icon is missing in this list.

Tested with Kontact/Mac installer 20081105.

----------
assignedto: till
messages: 17443
nosy: emanuel, till
priority: bug
status: unread
title: Kontact/Mac: Kontact name and icon missing in "kill application list"
topic: enterprise4, macos
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3213>
___________________________________________________


From kolab-issues at intevation.de  Thu Nov  6 10:08:41 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Thu, 06 Nov 2008 09:08:41 +0000
Subject: [Kolab-devel] [issue3214] Kontact/Mac: no pinentry
Message-ID: <1225962521.21.0.174378002059.issue3214@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

Sign or decrypt a mail failed. Pinentry missing.

Test with /opt/kde4-deps/bin/gpg2 (from Kontact/Mac installer 20081105) on
command line:

$ ./gpg2 -s test.txt 

Sie ben?tigen eine Passphrase, um den geheimen Schl?ssel zu entsperren.
Benutzer: "Emanuel Sch?tze <emanuel.schuetze at intevation.de>"
1024-Bit DSA Schl?ssel, ID 69A911FC, erzeugt 2006-11-15

gpg-agent[6700]: can't connect server: `ERR 67109133 can't exec
`/opt/kde4-deps/bin/pinentry': No such file or directory'
gpg-agent[6700]: can't connect to the PIN entry module: IPC "connect" Aufruf
fehlgeschlagen
gpg-agent[6700]: command get_passphrase failed: Kein Pinentry
gpg: Problem mit dem Agenten: Kein Pinentry
gpg: no default secret key: Allgemeiner Fehler
gpg: signing failed: Allgemeiner Fehler

----------
assignedto: till
messages: 17456
nosy: emanuel, till
priority: critical
status: unread
title: Kontact/Mac: no pinentry
topic: enterprise4, macos
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3214>
___________________________________________________


From kolab-issues at intevation.de  Thu Nov  6 10:29:52 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Thu, 06 Nov 2008 09:29:52 +0000
Subject: [Kolab-devel] [issue3215] Kontact/Mac: run gpg-agent failed
Message-ID: <1225963792.67.0.0327840201516.issue3215@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

Try to start /opt/kde4-deps/bin/gpg-agent:

$ ./gpg-agent 
gpg-agent[6863]: can't connect to `/Users/emanuel/.gnupg/S.gpg-agent': No such
file or directory
gpg-agent: Der gpg-agent l?uft nicht f?r diese Session

(Tested with Kontact/Mac installer 20081105)

----------
assignedto: till
messages: 17457
nosy: emanuel, till
priority: critical
status: unread
title: Kontact/Mac: run gpg-agent failed
topic: enterprise4, macos
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3215>
___________________________________________________


From kolab-issues at intevation.de  Thu Nov  6 10:44:40 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Thu, 06 Nov 2008 09:44:40 +0000
Subject: [Kolab-devel] [issue3216] Kontact/Mac: drag a mail - no folder
	highlighting
Message-ID: <1225964680.07.0.223915423483.issue3216@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

Drag a mail and move it over an other folder. The new folder doesn't change its
appearance (border or background color of folder should change until mail is drop).
Same for favorite folders.

----------
assignedto: till
messages: 17458
nosy: emanuel, till
priority: bug
status: unread
title: Kontact/Mac: drag a mail - no folder highlighting
topic: enterprise4, macos
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3216>
___________________________________________________


From kolab-issues at intevation.de  Thu Nov  6 16:43:45 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 06 Nov 2008 15:43:45 +0000
Subject: [Kolab-devel] [issue3217] Contacts: paste after a cut is greyed out.
Message-ID: <1225986225.02.0.855201416815.issue3217@intevation.de>


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

enterprise4 windows
Kontact-Installer_20081106.exe
Kontact Version 1.3 (enterprise4 0.20081027.876316) Windows
kdelibs-branch 877796 
kdepimlibs-branch 877803 
kdepim-branch 880441
i10n-kde4 (no branch) 874638

Test:
1. Switch to the contacts plugin.
2. Select a contact.
3. RMB-> Cut.
Try to use RMB->Paste but it is greyed out.

----------
assignedto: till
messages: 17464
nosy: bh, ludwig, till
priority: urgent
status: unread
title: Contacts: paste after a cut is greyed out.
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3217>
___________________________________________________


From kolab-issues at intevation.de  Fri Nov  7 13:00:16 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Fri, 07 Nov 2008 12:00:16 +0000
Subject: [Kolab-devel] [issue3218] "signature above text" setting not
	honored when switching identity
Message-ID: <1226059216.39.0.0412156223781.issue3218@intevation.de>


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

When switching to a different identity   
when using the "signature above text" setting,   
the signature of the switched-to identity get added additionally   
to the _bottom_ of the text.   
   
Kontact Version 1.2.9 (enterprise35 20081027.876310)    
   
   
How to reproduce:   
* Have two identities A,B with different signatures configured.   
* Have "signatures above text" configued and view identities 
* forward an email, let say signature A is shown, switch to B 
Observation: B's signature is there on the bottom. 
Expectation: B's signature should replace the signature on the top, 
   if it was not modified. 
 
Variant: Try this is both forwarding as attachment and as text. 
It is much worse with forwarding as text.

----------
assignedto: till
messages: 17470
nosy: bernhard, ludwig, till, vkrause
priority: urgent
status: unread
title: "signature above text" setting not honored when switching identity
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3218>
___________________________________________________


From kolab-issues at intevation.de  Fri Nov  7 13:31:23 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Fri, 07 Nov 2008 12:31:23 +0000
Subject: [Kolab-devel] [issue3219] user templates do not work,
	if the email has an attachment
Message-ID: <1226061083.7.0.590462403691.issue3219@intevation.de>


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

A global "user" template does not work,   
if the email as an attachment.   
   
Tested with   
Kontact Version 1.2.9 (enterprise35 20081027.876310)   
  
How to reproduce:  
* Have at least two emails ready, one with and one without attachment  
* Create your own template in Configure Kontact -> Email -> Composing  
  Tab "eigene Vorlagen" (personsl templates?)  
* Select one of the emails, use the menu to forward with personal template ->  
your template name  
Observation: Email with attachment does not have the template text. Email  
without attachment has. 
Expectation: Should work with both.

----------
assignedto: till
messages: 17471
nosy: bernhard, ludwig, till, vkrause
priority: urgent
status: unread
title: user templates do not work, if the email has an attachment
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3219>
___________________________________________________


From kolab-issues at intevation.de  Fri Nov  7 14:08:58 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Fri, 07 Nov 2008 13:08:58 +0000
Subject: [Kolab-devel] [issue3220] Other disconnected Imap folders good as
	sources for client filters broke
Message-ID: <1226063338.87.0.606701388009.issue3220@intevation.de>


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

It seems the feature kolab/issue1715 (Other disconnected Imap folders good as  
sources for client filters.) broke again.  
   
With Kontact Version 1.2.9 (enterprise35 20081027.876310)   
I have tried to move an email to a different folder,  
which comes in via sieve. It does not work.

----------
assignedto: till
messages: 17472
nosy: bernhard, ludwig, till, vkrause
priority: urgent
status: unread
title: Other disconnected Imap folders good as sources for client filters broke
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3220>
___________________________________________________


From kolab-issues at intevation.de  Fri Nov  7 17:54:02 2008
From: kolab-issues at intevation.de (Gunnar Wrobel)
Date: Fri, 07 Nov 2008 16:54:02 +0000
Subject: [Kolab-devel] [issue3221] Accessing foreign folders elicits PHP
	Notice: Unknown: Permission denied
Message-ID: <1226076842.04.0.0511254657846.issue3221@intevation.de>


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


From ml at radoeka.nl  Fri Nov  7 20:11:20 2008
From: ml at radoeka.nl (Richard Bos)
Date: Fri, 7 Nov 2008 20:11:20 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab Makefile.PL, 1.8,
	1.9 perl-kolab.spec, 1.104, 1.105
In-Reply-To: <20081107185810.AA542600926@lists.intevation.de>
References: <20081107185810.AA542600926@lists.intevation.de>
Message-ID: <200811072011.25000.ml@radoeka.nl>

Hi,

Op Friday 07 November 2008 19:58:10 schreef cvs at kolab.org:
> + ? ?for SBIN in kolabd kolabcheckperm kolabconf kolab_bootstrap; do ? ? ?
> ? ? ? ? ? ? ?\ + ? ? ?mv $RPM_BUILD_ROOT/%{l_prefix}/bin/$SBIN
> $RPM_BUILD_ROOT/%{l_prefix}/sbin/$SBIN; \ + ? ? ?chmod 744
> $RPM_BUILD_ROOT/%{l_prefix}/sbin/$SBIN; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\ +
> ? ? ?sed -i -e "s#/bin/$SBIN#/sbin/$SBIN#" perl-openpkg-files; ? ? ? ? ? ?
> ? ? ? ? ? ?\ + ? ?done

can't this be done in the Makefile?  Now every packager has to take care of 
this, while it is better if 'make install' would store the files in sbin.  
What's the limation of perl's packaging system to prevent files to be stored 
in /sbin?


-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From kolab-issues at intevation.de  Fri Nov  7 20:13:23 2008
From: kolab-issues at intevation.de (Daniel Vergien)
Date: Fri, 07 Nov 2008 19:13:23 +0000
Subject: [Kolab-devel] [issue3222] php-channel-horde-1.0-1 fails to compile
	on Solaris 10
Message-ID: <1226085203.4.0.711410383173.issue3222@intevation.de>


New submission from Daniel Vergien <daniel.vergien at web.de>:

The package fails to compile on Solaris 10 x86 because it calls
/usr/sbin/install with the option -p which the solaris install does not have.
As a workaround I replaced it with the one from gentoo and compiling works.
It seems that php-channel-horde is the only package which uses -p is it realy
necessary?

----------
messages: 17481
nosy: daniel.vergien
status: unread
title: php-channel-horde-1.0-1 fails to compile on Solaris 10
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3222>
___________________________________________________


From kolab-issues at intevation.de  Fri Nov  7 20:18:27 2008
From: kolab-issues at intevation.de (Daniel Vergien)
Date: Fri, 07 Nov 2008 19:18:27 +0000
Subject: [Kolab-devel] [issue3223] horde-framework-kolab-3.2_rc3-20080405
	fails to compile on solaris 10
Message-ID: <1226085507.34.0.0980895595684.issue3223@intevation.de>


New submission from Daniel Vergien <daniel.vergien at web.de>:

Compiling horde-framework-kolab fails on solaris 10 because
/kolab/RPM/TMP/pear/download is not existing.

As a workaround I just created the dir by hand and started the build again.

----------
messages: 17482
nosy: daniel.vergien
status: unread
title: horde-framework-kolab-3.2_rc3-20080405 fails to compile on solaris 10
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3223>
___________________________________________________


From wrobel at pardus.de  Sat Nov  8 08:59:14 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Sat, 08 Nov 2008 08:59:14 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab Makefile.PL, 1.8,
	1.9	perl-kolab.spec, 1.104, 1.105
In-Reply-To: <200811072011.25000.ml@radoeka.nl>
References: <20081107185810.AA542600926@lists.intevation.de>
	<200811072011.25000.ml@radoeka.nl>
Message-ID: <20081108085914.18033vg0preg1800@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Hi,
>
> Op Friday 07 November 2008 19:58:10 schreef cvs at kolab.org:
>> +    for SBIN in kolabd kolabcheckperm kolabconf kolab_bootstrap;  
>> do                    +      mv $RPM_BUILD_ROOT/%{l_prefix}/bin/$SBIN
>> $RPM_BUILD_ROOT/%{l_prefix}/sbin/$SBIN;  +      chmod 744
>> $RPM_BUILD_ROOT/%{l_prefix}/sbin/$SBIN;                                 +
>>      sed -i -e "s#/bin/$SBIN#/sbin/$SBIN#" perl-openpkg-files;       
>>                   +    done
>
> can't this be done in the Makefile?

It can, but I admit I didn't think long enough about this in the first  
round. Thanks for the comment.

> Now every packager has to take care of
> this, while it is better if 'make install' would store the files in sbin.

Indeed, I violated my ideas of clean packages here.

> What's the limation of perl's packaging system to prevent files to be stored
> in /sbin?

It is not so much a limitation of perls packaging system as the way  
OpenPKG uses this. The perl-wrapper within OpenPKG calls "make  
pure_install" rather than "make install". I don't know why exactly but  
there is probably a reason for that. This makes it more difficult to  
extend the Makefile with additional install targets - something that  
is support by the perl packaging system.

But I can work around that and added a few special lines for OpenPKG  
which are probably not needed on other distros if "make install" is  
called - Gentoo's perl-wrapper does this.

Cheers,

Gunnar

>
>
> --
> Richard Bos
> We are borrowing the world of our children,
> It is not inherited from our parents.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081108/f6f84768/attachment-0001.bin

From ml at radoeka.nl  Sat Nov  8 10:07:59 2008
From: ml at radoeka.nl (Richard Bos)
Date: Sat, 8 Nov 2008 10:07:59 +0100
Subject: [Kolab-devel]
	=?iso-8859-6?q?gunnar=3A_server/perl-kolab_Makefile?=
	=?iso-8859-6?b?LlBMLCAxLjgsIDEuOQlwZXJsLWtvbGFiLnNwZWMgLCAxLjEw?=
	=?iso-8859-6?q?4=2C_1=2E105?=
In-Reply-To: <20081108085914.18033vg0preg1800@webmail.pardus.de>
References: <20081107185810.AA542600926@lists.intevation.de>
	<200811072011.25000.ml@radoeka.nl>
	<20081108085914.18033vg0preg1800@webmail.pardus.de>
Message-ID: <200811081007.59677.ml@radoeka.nl>

Op Saturday 08 November 2008 08:59:14 schreef Gunnar Wrobel:
> But I can work around that and added a few special lines for OpenPKG ?
> which are probably not needed on other distros if "make install" is ?
> called - Gentoo's perl-wrapper does this.

Great and well done!

-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From richard at radoeka.nl  Sat Nov  8 11:11:31 2008
From: richard at radoeka.nl (Richard Bos)
Date: Sat, 8 Nov 2008 11:11:31 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab MANIFEST,1.6,1.7
In-Reply-To: <20081108094211.D444F60094A@lists.intevation.de>
References: <20081108094211.D444F60094A@lists.intevation.de>
Message-ID: <200811081111.32079.richard@radoeka.nl>

Op Saturday 08 November 2008 10:42:11 schreef cvs at kolab.org:
> +sbin/kolab_upgrade.in

should this script still be part of the packages?  It is for upgrading from 
2.0 to 2.1:
print "Kolab Upgrade script from 2.0 to 2.1\n";
print "------------------------------------\n\n";
print "This will upgrade your Kolab LDAP database from version 2.0 to 2.1.\n";
print "Please back up everything before continuing\n\n";
print "Continue? [N/y]: ";

As such it does not seem necessary to distribute it anylonger.

-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From ml at radoeka.nl  Sat Nov  8 11:11:46 2008
From: ml at radoeka.nl (Richard Bos)
Date: Sat, 8 Nov 2008 11:11:46 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab MANIFEST,1.6,1.7
In-Reply-To: <20081108094211.D444F60094A@lists.intevation.de>
References: <20081108094211.D444F60094A@lists.intevation.de>
Message-ID: <200811081111.46941.ml@radoeka.nl>

Op Saturday 08 November 2008 10:42:11 schreef cvs at kolab.org:
> +sbin/kolab_upgrade.in

should this script still be part of the packages?  It is for upgrading from 
2.0 to 2.1:
print "Kolab Upgrade script from 2.0 to 2.1\n";
print "------------------------------------\n\n";
print "This will upgrade your Kolab LDAP database from version 2.0 to 2.1.\n";
print "Please back up everything before continuing\n\n";
print "Continue? [N/y]: ";

As such it does not seem necessary to distribute it anylonger.

-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From wrobel at pardus.de  Sat Nov  8 11:25:22 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Sat, 08 Nov 2008 11:25:22 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab MANIFEST,1.6,1.7
In-Reply-To: <200811081111.46941.ml@radoeka.nl>
References: <20081108094211.D444F60094A@lists.intevation.de>
	<200811081111.46941.ml@radoeka.nl>
Message-ID: <20081108112522.104139xogbckb38k@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Op Saturday 08 November 2008 10:42:11 schreef cvs at kolab.org:
>> +sbin/kolab_upgrade.in
>
> should this script still be part of the packages?  It is for upgrading from
> 2.0 to 2.1:
> print "Kolab Upgrade script from 2.0 to 2.1\n";
> print "------------------------------------\n\n";
> print "This will upgrade your Kolab LDAP database from version 2.0  
> to 2.1.\n";
> print "Please back up everything before continuing\n\n";
> print "Continue? [N/y]: ";
>
> As such it does not seem necessary to distribute it anylonger.

This is for Thomas to decide. I'm not 100% certain if we support  
upgrading a Kolab-2.0 server directly to 2.2. In that case you'd still  
need the script.

I could also imagine that we rewrite the script and place other  
upgrade tasks there.

Cheers,

Gunnar

>
> --
> Richard Bos
> We are borrowing the world of our children,
> It is not inherited from our parents.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081108/9127bc73/attachment.bin

From ml at radoeka.nl  Sat Nov  8 11:35:48 2008
From: ml at radoeka.nl (Richard Bos)
Date: Sat, 8 Nov 2008 11:35:48 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab MANIFEST,1.6,1.7
In-Reply-To: <20081108112522.104139xogbckb38k@webmail.pardus.de>
References: <20081108094211.D444F60094A@lists.intevation.de>
	<200811081111.46941.ml@radoeka.nl>
	<20081108112522.104139xogbckb38k@webmail.pardus.de>
Message-ID: <200811081135.49244.ml@radoeka.nl>

Op Saturday 08 November 2008 11:25:22 schreef Gunnar Wrobel:
> Quoting Richard Bos <ml at radoeka.nl>:
> > Op Saturday 08 November 2008 10:42:11 schreef cvs at kolab.org:
> >> +sbin/kolab_upgrade.in
> >
> > should this script still be part of the packages?  It is for upgrading
> > from 2.0 to 2.1:
> > print "Kolab Upgrade script from 2.0 to 2.1\n";
> > print "------------------------------------\n\n";
> > print "This will upgrade your Kolab LDAP database from version 2.0
> > to 2.1.\n";
> > print "Please back up everything before continuing\n\n";
> > print "Continue? [N/y]: ";
> >
> > As such it does not seem necessary to distribute it anylonger.
>
> This is for Thomas to decide. I'm not 100% certain if we support
> upgrading a Kolab-2.0 server directly to 2.2. In that case you'd still
> need the script.
>
> I could also imagine that we rewrite the script and place other
> upgrade tasks there.

shall I open an issue for it, or is this email sufficient?

-- 
Richard Bos
Without a home the journey is endless


From kolab-issues at intevation.de  Sat Nov  8 11:45:37 2008
From: kolab-issues at intevation.de (Gunnar Wrobel)
Date: Sat, 08 Nov 2008 10:45:37 +0000
Subject: [Kolab-devel] [issue3224] perl-kolab has been restructured and
	needs to be tested
Message-ID: <1226141136.95.0.181288347925.issue3224@intevation.de>


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

I restructured perl-kolab and it needs some testing before the next release.

Rationale for restructuring:

 - Perl scripts should be installed using ExtUtils::MakeMaker which is the 
   packaging system provided by perl
 - We had many perl based scripts in kolabd and this is by no means a 
   perl-package
 - The perl scripts were still using the dist_conf approach for access to
   system variables. The scripts should retrieve such information from a
   configuration file rather than having them hardcoded during build time.

All perl scripts have now been moved into perl-kolab and fixed for the new
install location. I tested the functionality of each on a CVS based server and
they seem to work. Nevertheless I suggest testing them again before the next
release.

In the long term we might consider splitting the perl-scripts out of perl-kolab
into a separate package. Thomas and Richard both disliked having the scripts in
perl-kolab. On the other hand I don't really see why this hurts because the
library part in perl-kolab is really only used by these scripts and I don't
think there is a reason to install perl-kolab on anything else than a Kolab-Server.

----------
assignedto: thomas
messages: 17485
nosy: bernhard, khruskowski, rbos, thomas, wilde, wrobel
priority: urgent
status: unread
title: perl-kolab has been restructured and needs to be tested
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3224>
___________________________________________________


From wrobel at pardus.de  Sat Nov  8 11:47:06 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Sat, 08 Nov 2008 11:47:06 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab MANIFEST,1.6,1.7
In-Reply-To: <200811081135.49244.ml@radoeka.nl>
References: <20081108094211.D444F60094A@lists.intevation.de>
	<200811081111.46941.ml@radoeka.nl>
	<20081108112522.104139xogbckb38k@webmail.pardus.de>
	<200811081135.49244.ml@radoeka.nl>
Message-ID: <20081108114706.99782ejw5vmx4y1w@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Op Saturday 08 November 2008 11:25:22 schreef Gunnar Wrobel:
>> Quoting Richard Bos <ml at radoeka.nl>:
>> > Op Saturday 08 November 2008 10:42:11 schreef cvs at kolab.org:
>> >> +sbin/kolab_upgrade.in
>> >
>> > should this script still be part of the packages?  It is for upgrading
>> > from 2.0 to 2.1:
>> > print "Kolab Upgrade script from 2.0 to 2.1\n";
>> > print "------------------------------------\n\n";
>> > print "This will upgrade your Kolab LDAP database from version 2.0
>> > to 2.1.\n";
>> > print "Please back up everything before continuing\n\n";
>> > print "Continue? [N/y]: ";
>> >
>> > As such it does not seem necessary to distribute it anylonger.
>>
>> This is for Thomas to decide. I'm not 100% certain if we support
>> upgrading a Kolab-2.0 server directly to 2.2. In that case you'd still
>> need the script.
>>
>> I could also imagine that we rewrite the script and place other
>> upgrade tasks there.
>
> shall I open an issue for it, or is this email sufficient?

An issue is probably safer :) Thanks!

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



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081108/9875193d/attachment.bin

From kolab-issues at intevation.de  Sat Nov  8 16:37:36 2008
From: kolab-issues at intevation.de (Richard Bos)
Date: Sat, 08 Nov 2008 15:37:36 +0000
Subject: [Kolab-devel] [issue3225] Should the script kolab_upgrade be
	removed from the rpm package?
Message-ID: <1226158656.37.0.0606966414021.issue3225@intevation.de>


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

Should the script kolab_upgrade be removed from the rpm package perl-kolab?
It is for upgrading from 2.0 to 2.1, so it does not seem necessary anymore
for the current and subsequent releases.

See, email discussion on:
http://www.kolab.org/pipermail/kolab-devel/2008-November/009740.html

----------
messages: 17488
nosy: rbos, thomas, wrobel
priority: bug
status: unread
title: Should the script kolab_upgrade be removed from the rpm package?
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3225>
___________________________________________________


From kolab-issues at intevation.de  Mon Nov 10 13:05:39 2008
From: kolab-issues at intevation.de (=?utf-8?q?Albrecht_Dre=C3=9F?=)
Date: Mon, 10 Nov 2008 12:05:39 +0000
Subject: [Kolab-devel] [issue3226] Toltec cannot interpret VCALENDER parts
	w/ utf-8 chars
Message-ID: <1226318739.36.0.734223594662.issue3226@intevation.de>


New submission from Albrecht Dre? <albrecht.dress at lios-tech.com>:

When reading the freebusy list of a user whose CN entry contains utf-8 national
chars, Outlook 2002SP3 w/ the Toltec connector reproducibly displays an error
(see attached screenshot).  I sniffed the HTTP traffic with Wireshark, and the
content looks fine except that RFC 2616, Section 3.7.1 specifies that text/*
content without a charset parameter shall be interpreted as ISO-8859-1. 
However, even by adding the "charset=utf-8" parameter to the Apache config, the
error still occurs.

----------
files: OUTLOOK.png
messages: 17493
nosy: albrecht.dress
priority: urgent
status: unread
title: Toltec cannot interpret VCALENDER parts w/ utf-8 chars
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3226>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OUTLOOK.png
Type: image/png
Size: 3466 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081110/5ac32e57/OUTLOOK.png

From kolab-issues at intevation.de  Mon Nov 10 15:58:29 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 10 Nov 2008 14:58:29 +0000
Subject: [Kolab-devel] [issue3227] Shared seen flag problem
Message-ID: <1226329109.61.0.376938156384.issue3227@intevation.de>


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

enterprise4 lenny
kdepim 4.1.1.enterprise4.0.20081108.881490-kk1
kdepimlibs 4.1.1.enterprise4.0.20081108.881490-kk1
kde-l10n-de 4.1.1.enterprise4.0.20081028.876863-kk1
kdelibs5 4.1.1.enterprise4.0.20081104.879654-kk1
kdebase_runtime 4.1.1.enterprise4.0.20081015.871597-kk1

Sometimes at the first sync with the option "share unread state with all users",
the state is not saved.

Test:
1. A creates a new folder x.
2. A copies some mails into x and mark them read.
3. A syncs.
4. A shares the folder x with readrights only to B,
5. A activate "Share unread state with all users" for x.
6. A syncs.
7. B syncs.
=> the folder x appears in B's account, but all mails are marked "unread".
8. B syncs.
9. A syncs.
=> the folder x in A's account contains "unread" mails.

----------
assignedto: till
messages: 17495
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: urgent
status: unread
title: Shared seen flag problem
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3227>
___________________________________________________


From kolab-issues at intevation.de  Mon Nov 10 16:09:06 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Mon, 10 Nov 2008 15:09:06 +0000
Subject: [Kolab-devel] [issue3228] forwarding filter action does not
	directly send the email
Message-ID: <1226329746.04.0.333300008946.issue3228@intevation.de>


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

Kontact Version 1.2.9 (enterprise35 20081109.881860)
Debian Package Version: 4:3.5.10.enterprise.0.20081109.881860-kk1

Create a new manual filter, with the only filter action 
being a forward to a different email address.
Select an email somewhere and apply the filter.
Observation the forwarded email is not getting send, but is stuck
in the outgoing queue.
Expectation: The email should be send right away.

(Yes, the Kontact is in online mode. Yes, a fresh emails or a manually 
forwarded one goes out directly.)

----------
assignedto: till
messages: 17496
nosy: bernhard, ludwig, till, vkrause
priority: urgent
status: unread
title: forwarding filter action does not directly send the email
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3228>
___________________________________________________


From kolab-issues at intevation.de  Mon Nov 10 19:47:40 2008
From: kolab-issues at intevation.de (=?utf-8?q?Albrecht_Dre=C3=9F?=)
Date: Mon, 10 Nov 2008 18:47:40 +0000
Subject: [Kolab-devel] [issue3229] Toltec connector makes encrypted messages
	unusable for other MUA's
Message-ID: <1226342860.56.0.0402401818621.issue3229@intevation.de>


New submission from Albrecht Dre? <albrecht.dress at lios-tech.com>:

When the Toltec connector reads a RFC 3156 (multipart/encrypted OpenPGP)
message, it stores it back to the IMAP folders in a format which is not
parseable any more by RFC 3156-aware clients (tested with Balsa,
<http://balsa.gnome.org>, which is fully RFC 3156 compliant).

The original MIME message structure

multipart/encrypted; protocol="application/pgp-encrypted"
  +-- application/pgp-encrypted
  +-- application/octet-stream

is converted into

multipart/mixed
  +-- text/plain (containing Empty text body)
  +-- application/pgp-encrypted (with a crazy filename added)
  +-- application/octet-stream (also with a crazy filename, plus
  |   charset="iso-8859-1"???)
  +-- application/x-toltec-tnef-1

The last part seems to contain the parts of the original message
(checked/extracted with tnef).

I have no idea why Toltec re-arranges the message - if they would just leave it
"as is" when tey store it back, Outlook simply could co-exist with standard (and
standard-compliant!) MUA's accessing the IMAP store!

----------
messages: 17505
nosy: albrecht.dress
priority: bug
status: unread
title: Toltec connector makes encrypted messages unusable for other MUA's
topic: toltec
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3229>
___________________________________________________


From kolab-issues at intevation.de  Mon Nov 10 23:35:27 2008
From: kolab-issues at intevation.de (Mathieu Parent)
Date: Mon, 10 Nov 2008 22:35:27 +0000
Subject: [Kolab-devel] [issue3230] opportunity to delete freebusy value
Message-ID: <1226356527.39.0.247423531948.issue3230@intevation.de>


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

This patch has been in debian for some time now. It allows to delete freebusy
value by just entering empty value in freebusypast input.

Patch is attached

This issue, is to track feedback before commit.

----------
assignedto: mathieu.parent
files: 20-service_index.diff
messages: 17507
nosy: martin, mathieu.parent, rbos, thomas
priority: feature
status: unread
title: opportunity to delete freebusy value
topic: web admin
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3230>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 20-service_index.diff
Url: http://kolab.org/pipermail/kolab-devel/attachments/20081110/20430f91/20-service_index.txt

From kolab-issues at intevation.de  Wed Nov 12 10:03:34 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 12 Nov 2008 09:03:34 +0000
Subject: [Kolab-devel] [issue3231] Sometimes the body of a mail isn't
	display in the inbox.
Message-ID: <1226480614.5.0.767693488689.issue3231@intevation.de>


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

enterprise35 20080602.814375

A customer reported a bug with mixed mode accounts:
The bodies of mails from the inbox were sometimes not displayed, while the
headers were displayed.
This problem appears one time in a week at the customer.
Moving the mails solves the problem but sometimes triggers a crash.

----------
assignedto: till
messages: 17538
nosy: bernhard, bh, ludwig, osterfeld, pradeepto, till
priority: bug
status: need-eg
title: Sometimes the body of a mail isn't display in the inbox.
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3231>
___________________________________________________


From kolab-issues at intevation.de  Wed Nov 12 12:28:46 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Wed, 12 Nov 2008 11:28:46 +0000
Subject: [Kolab-devel] [issue3232] pinentry-qt4 doesn't run
Message-ID: <1226489326.54.0.563962093782.issue3232@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

1. Install Kontact/Mac installer (2008-11-10)
2. Copy pinentry-qt4 to /opt/kde4-deps/bin
3. run pinentry-qt4

-> Error:
dyld: Library not loaded: QtCore.framework/Versions/4/QtCore
  Referenced from: /opt/kde4-deps/bin/./pinentry-qt4
  Reason: image not found

----------
assignedto: till
messages: 17541
nosy: emanuel, till
priority: critical
status: unread
title: pinentry-qt4 doesn't run
topic: kde client, kowi, macos
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3232>
___________________________________________________


From kolab-issues at intevation.de  Thu Nov 13 10:03:52 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Thu, 13 Nov 2008 09:03:52 +0000
Subject: [Kolab-devel] [issue3233] Archiving and deletion of old calender
	entries does not work
Message-ID: <1226567032.3.0.785762673863.issue3233@intevation.de>


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

I have 99 emails in my "Kalender" folder.
Deleting and archiving old calender entries does not work on Windows.
a) deletion is confirmed, but events just stay there
b) trying to open a new file for achiving is not allowed 
   by the file dialog, as it want to "open" an existing file

(There are several accounts and event folders configured.)

Kontact Version 1.3 (enterprise4 0.20081027.876316) Windows
kdelibs-4.1-branch 877805
kdepimlibs-branch  877821
kdepim-branch      883540
l10n-kde4-branch   877770.

I am trying to delete the entries. So I use in the calender view
the File -> Archive Old Entries (or so) function.
Selecting a few days in the future, to get all appointments
and "delete only". I get a dialog that asks me if I really want to delete.
Yes! *rumble* *rumble* dialgo gone, appointments still there.
Trying again: No appointment found in the given time.
Closing and restarting Kontact, now I can do it again from the beginning.

----------
assignedto: till
messages: 17568
nosy: bernhard, ludwig, till, vkrause
priority: bug
status: unread
title: Archiving and deletion of old calender entries does not work
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3233>
___________________________________________________


From wrobel at pardus.de  Thu Nov 13 11:00:49 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 13 Nov 2008 11:00:49 +0100
Subject: [Kolab-devel] PHP debugging
Message-ID: <20081113110049.82611q3qrfc35r0k@webmail.pardus.de>

Hi!

There is a new page in the wiki that describes the setup of PHP  
debugging tools with the Kolab server.

https://wiki.kolab.org/index.php/PHP_debugging

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


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081113/2274186f/attachment.bin

From kolab-issues at intevation.de  Thu Nov 13 15:56:26 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Thu, 13 Nov 2008 14:56:26 +0000
Subject: [Kolab-devel] [issue3234] Optional participants (attendees) from
	Kontact's invitations are required in Outlook 2003
Message-ID: <1226588186.66.0.40786901646.issue3234@intevation.de>


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

When inviting people as "optinal" (Freiwilliger Teilnehmer)
with Kontact, testing with proko2 2.1.12 for comparision
and enterprise enterprise35 20080919.862683,
Outlook 2003 will list these participant as required.

A bit of testing reveals that it probably is that
Outlook wants optional participants to be in Cc: and not in To:
in the invitation to actually make them "optional". 
It seems that the realname is also taken from the email header
fullnames and not from the CN= parameter of the VEVENT.

I am attaching a few example invitations for reference.

----------
assignedto: bernhard
files: proko2-invitation-with-optional-participants.mbox
messages: 17573
nosy: bernhard, ludwig, till
priority: urgent
status: chatting
title: Optional participants (attendees) from Kontact's invitations are required in Outlook 2003
topic: kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3234>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proko2-invitation-with-optional-participants.mbox
Type: application/octet-stream
Size: 1309 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081113/15e2e31e/proko2-invitation-with-optional-participants.exe

From ml at radoeka.nl  Thu Nov 13 19:11:10 2008
From: ml at radoeka.nl (Richard Bos)
Date: Thu, 13 Nov 2008 19:11:10 +0100
Subject: [Kolab-devel] gunnar: server/kolabd/kolabd/templates
	freebusy.conf.template.in, 1.17, 1.18
In-Reply-To: <20081113054338.E61D060093F@lists.intevation.de>
References: <20081113054338.E61D060093F@lists.intevation.de>
Message-ID: <200811131911.11527.ml@radoeka.nl>

Op Thursday 13 November 2008 06:43:38 schreef cvs at kolab.org:
> RCS file:
> /kolabrepository/server/kolabd/kolabd/templates/freebusy.conf.template.in,v

//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
//
// If you modify this file, please do not forget to modify both the
// template in kolabd and the source file in kolab-freebusy
//
// In order to check if both are in sync:
//
// cd server
// diff -Nau kolab-freebusy/freebusy/config.php 
kolabd/kolabd/templates/freebusy.conf.template.in
//
//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Is this still valid?  Isn't kolab-filter and freebusy moved to php pear?
Should the above comment be removed from the file?

-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From ml at radoeka.nl  Thu Nov 13 19:11:13 2008
From: ml at radoeka.nl (Richard Bos)
Date: Thu, 13 Nov 2008 19:11:13 +0100
Subject: [Kolab-devel] gunnar: server/kolabd/kolabd/templates
	resmgr.conf.template.in, 1.30, 1.31
In-Reply-To: <20081113064411.31C2260093F@lists.intevation.de>
References: <20081113064411.31C2260093F@lists.intevation.de>
Message-ID: <200811131911.13310.ml@radoeka.nl>

Op Thursday 13 November 2008 07:44:11 schreef cvs at kolab.org:
> RCS file:
> /kolabrepository/server/kolabd/kolabd/templates/resmgr.conf.template.in,v

From the template:
//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
//
// If you modify this file, please do not forget to modify both the
// template in kolabd and the source file in kolab-freebusy
//
// In order to check if both are in sync:
//
// cd server
// diff -Nau kolab-filter/filter/config.php 
kolabd/kolabd/templates/resmgr.conf.template.in
//
//!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Is this still valid?  Isn't kolab-filter and freebusy moved to php pear?
Should the above comment be removed from the file?

-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From kolab-issues at intevation.de  Fri Nov 14 10:38:46 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Fri, 14 Nov 2008 09:38:46 +0000
Subject: [Kolab-devel] [issue3235] Kontact doesn't  start Kleopatra
Message-ID: <1226655526.3.0.910550946032.issue3235@intevation.de>


New submission from Emanuel Sch?tze <emanuel at intevation.de>:

Try to start Kleopatra from Kontact/Mac:
Tools->Certificate Manager

-> error: "Could not start certificate manager; please check your installation"

Run "open /opt/kde4/bin/kleopatra.app" works.

Tested with Kontact/Mac installer (20081112).

----------
assignedto: till
messages: 17577
nosy: emanuel, till
priority: urgent
status: unread
title: Kontact doesn't  start Kleopatra
topic: kde client, kowi, macos
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3235>
___________________________________________________


From kolab-issues at intevation.de  Fri Nov 14 18:43:59 2008
From: kolab-issues at intevation.de (Saim Kim)
Date: Fri, 14 Nov 2008 17:43:59 +0000
Subject: [Kolab-devel] [issue3236] Attendee status email not recognized
Message-ID: <1226684638.95.0.384884792709.issue3236@intevation.de>


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

Hello,


as previously dicussed on the mailing list:

I'm experiencing problems with the attendee status in Outlook with Toltec 2.3
and Kolab 2.2 release. Even though I'm receiving a notification that the event
has been accepted/deleted but still it is not updated in the attendee status of
the event. Also, the status notification is not recognized as such anymore. Both
manual and automatic answering were tested with varying results. Here is an
example notification:

Return-Path: <kalender_user_wma at mydomain.com>
Received: from localhost (localhost [127.0.0.1])
    by kolab.mydomain.com (Cyrus v2.3.11-kolab-nocaps) with LMTPA;
    Mon, 08 Sep 2008 10:45:37 +0200
X-Sieve: CMU Sieve 2.3
Received: from localhost (localhost [127.0.0.1])
   by kolab.mydomain.com (Postfix) with ESMTP id A91E2E8002
   for <user at mydomain.com>; Mon,  8 Sep 2008 10:45:37 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
   by kolab.mydomain.com (Postfix) with ESMTP id 9C2214962AF
   for <user at mydomain.com>; Mon,  8 Sep 2008 10:45:37 +0200 (CEST)
Received: from localhost ([localhost]) by mydomain.com (Horde Framework)
   with HTTP; Mon, 08 Sep 2008 10:45:37 +0200
Message-ID: <20080908104537.89424ns1q2072w4k at mydomain.com>
Date: Mon, 08 Sep 2008 10:45:37 +0200
From: Kalender user Wma <kalender_user_wma at mydomain.com>
To: user at mydomain.com
Subject: Accepted: Aktualisiert: Test Termin
MIME-Version: 1.0
Content-Type: text/calendar;
   charset=UTF-8;
   method="REPLY"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
X-Kolab-Scheduling-Message: TRUE

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//proko2//resmgr 1.0//EN
METHOD:REPLY
BEGIN:VEVENT
UID:040000008200E00074C5B7101A82E0080000000010C7EF0CA011C9010000000000000000=
1000000046BC72203B9CAF46B6712CBF388AB531
SUMMARY:Aktualisiert: Test Termin
DESCRIPTION:Zeit:
 Montag\, 8. September 2008 13:00-14:00 (GMT+01:00) Amsterdam\, Berlin\,
 Bern\, Rom\, Stockholm\, Wien.

*~*~*~*~*~*~*~*~*~*
DTSTART:20080908T110000Z
DTEND:20080908T120000Z
SEQUENCE:1
ORGANIZER:MAILTO:user at mydomain.com
ATTENDEE;CN=3DKalender user
 Wma;PARTSTAT=3DACCEPTED:MAILTO:kalender_user_wma at mydomain.com
DTSTAMP:20080908T084537Z
END:VEVENT
END:VCALENDAR


Best regards,
Saim

----------
messages: 17590
nosy: sojakim
priority: bug
status: unread
title: Attendee status email not recognized
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3236>
___________________________________________________


From kolab-issues at intevation.de  Fri Nov 14 19:46:54 2008
From: kolab-issues at intevation.de (Gunnar Wrobel)
Date: Fri, 14 Nov 2008 18:46:54 +0000
Subject: [Kolab-devel] [issue3237] Double Sync with SyncML when using
	external client
Message-ID: <1226688414.69.0.238237290784.issue3237@intevation.de>


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

Horde is currently agnostic of external clients to the storage backend used by
Horde/Kolab. For SyncML any storage changes need to get logged in order to be
exchanged with the mobile clients.

Currently the Kolab drivers within Horde will create the necessary changelog.
But this currently only happens after Synchronization started. Which means that
you need to sync twice in order to get changes from an external client if you
did not log in via Horde after changing something with an external client.

The attached patch has been provided by Univention but needs some cleanup to go
in upstream. We mainly need a clean library call in the Horde application
libraries that will be called for synchronization.

----------
assignedto: wrobel
files: 02_fixed_double_sync.patch
messages: 17591
nosy: bernhard, thomas, wilde, wrobel
priority: bug
status: chatting
title: Double Sync with SyncML when using external client
topic: web client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3237>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02_fixed_double_sync.patch
Type: application/octet-stream
Size: 8161 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081114/bcc820ab/02_fixed_double_sync.exe

From kolab-issues at intevation.de  Fri Nov 14 19:49:14 2008
From: kolab-issues at intevation.de (Gunnar Wrobel)
Date: Fri, 14 Nov 2008 18:49:14 +0000
Subject: [Kolab-devel] [issue3238] Double Entries with SyncML when the
	folder uid validity changes
Message-ID: <1226688554.14.0.537178505013.issue3238@intevation.de>


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

When the uid validity of an IMAP folder changes this confuses the Kolab storage
driver and leads to double entries. The attached patch has been proposed by
Univention and should be applied after some cleanup.

----------
assignedto: wrobel
files: 03_fixed_entry_doubling.patch
messages: 17592
nosy: bernhard, thomas, wilde, wrobel
priority: bug
status: chatting
title: Double Entries with SyncML when the folder uid validity changes
topic: web client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3238>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 03_fixed_entry_doubling.patch
Type: application/octet-stream
Size: 3070 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081114/e9073956/03_fixed_entry_doubling.exe

From kolab-issues at intevation.de  Sun Nov 16 08:59:07 2008
From: kolab-issues at intevation.de (Gunnar Wrobel)
Date: Sun, 16 Nov 2008 07:59:07 +0000
Subject: [Kolab-devel] [issue3239] Kolabd does not clear sieve scripts on
	deletion of a user
Message-ID: <1226822347.49.0.105876896563.issue3239@intevation.de>


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


From wrobel at pardus.de  Sun Nov 16 09:05:18 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Sun, 16 Nov 2008 09:05:18 +0100
Subject: [Kolab-devel] gunnar:
	server/kolabd/kolabd/templates	freebusy.conf.template.in, 1.17, 1.18
In-Reply-To: <200811131911.11527.ml@radoeka.nl>
References: <20081113054338.E61D060093F@lists.intevation.de>
	<200811131911.11527.ml@radoeka.nl>
Message-ID: <20081116090518.92512f2m0ezb6e68@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Op Thursday 13 November 2008 06:43:38 schreef cvs at kolab.org:
>> RCS file:
>> /kolabrepository/server/kolabd/kolabd/templates/freebusy.conf.template.in,v
>
> //!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> //
> // If you modify this file, please do not forget to modify both the
> // template in kolabd and the source file in kolab-freebusy
> //
> // In order to check if both are in sync:
> //
> // cd server
> // diff -Nau kolab-freebusy/freebusy/config.php
> kolabd/kolabd/templates/freebusy.conf.template.in
> //
> //!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>

Thanks for the note!

> Is this still valid?

No.

> Isn't kolab-filter and freebusy moved to php pear?

Yes.

> Should the above comment be removed from the file?

I modified it so that it points to the upstream config file. Though I  
still need to fix the upstream configuration file. It does not yet  
match the template. I'll do that for the next upstream release.

Cheers,

Gunnar

>
> --
> Richard Bos
> We are borrowing the world of our children,
> It is not inherited from our parents.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081116/dbf3f4ed/attachment.bin

From wrobel at pardus.de  Sun Nov 16 09:39:50 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Sun, 16 Nov 2008 09:39:50 +0100
Subject: [Kolab-devel] Kolab Server 2.2.1 moves ahead
Message-ID: <20081116093950.38465uhrq0yyweos@webmail.pardus.de>

Hi!

Just a short note about the Kolab Server 2.2.1 progress:

p at rdus finished the development activities for this Kolab Server  
version last week. Thus we move into testing and bug fixing now. There  
should be betas available soon.

What are notable changes in Kolab Server 2.2.1:

   - The Kolab web client upgrades to horde-webmail-1.2 (+ a big Kolab specfic
     patch).
   - Support for attachments as described by the Kolab format (leads to photo
     support in the address book as well as attachments to contacts).
   - SyncML support for contacts and events.
   - DIMP: AJAX based "dynamic" web client (horde)
   - MIMP: mobile mail client (horde)

In addition there are changes concerning the Kolab free/busy system as  
well as the Kolab mail filters:

   - Removal of kolab-filter, kolab-freebusy, as well as the code in php-kolab
     and replacement by upstream PEAR packages released via  
http://pear.horde.org

The main focus of this release is stabilization of the Kolab web  
client and associated with this a consolidation of the Horde libraries  
we use within the Kolab Server. While this does not bring much new  
functionality I believe it provides us with a sound basis for the next  
three years (as far as I can preview this period yet).

The fact that most of the Kolab code has been moved upstream now has  
several important side effects:

  1) A single implementation of the Kolab concepts and thus a significant
     reduction in code duplication.
  2) Improved code quality.
  3) phpUnit based unit testing for all Kolab specific modules.
  4) Clean package releases based on PEAR.

I realize that point 4) means a lot of new work for the native ports  
but I'm convinced that this approach will reduce the maintenance  
workload in the long run. It will also bring the different  
distributions closer together as we have a clear reference point now.

Cheers,

Gunnar

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


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081116/7d58ab50/attachment.bin

From wrobel at pardus.de  Mon Nov 17 08:32:26 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 17 Nov 2008 08:32:26 +0100
Subject: [Kolab-devel] Running Kolab2/OpenPKG-2.2 on Amazon EC2
	(was:	Kolab in the clouds)
In-Reply-To: <20081021111032.13843cl51kv1wayo@webmail.pardus.de>
References: <20081014081347.27441bu8f5a6cfq8@webmail.pardus.de>
	<200810171744.22064.bernhard@intevation.de>
	<20081021111032.13843cl51kv1wayo@webmail.pardus.de>
Message-ID: <20081117083226.17031qut78i2a7fo@webmail.pardus.de>

Quoting Gunnar Wrobel <wrobel at pardus.de>:

> Quoting Bernhard Reiter <bernhard at intevation.de>:
>
>> On Dienstag, 14. Oktober 2008, Gunnar Wrobel wrote:
>>> The current one is AMI "ami-6e2eca07" and I update the thread once
>>> I  publish others.
>>
>> This might warrent a new wiki page to keep the overview and the
>> instructions. :)
>
> Yes, will do that once I have a 2.2 image. I'll write down some
> instructions on how to use the images then.

I generated a Kolab2/OpenPKG-2.2 server image which is available with  
the ID "ami-c910f4a0".

In addition I created instructions on how to get a Kolab server up and  
running in 10 minutes. See

https://wiki.kolab.org/index.php/Kolab2_on_Amazons_EC2

Please note that this is really only meant for testing purposes. As  
far as I know most of Amazons EC2 network is black listed as spammers  
like the possibility to start up a virtual machine and send a few mails.

A question to the developer crowd: Is there significant interest in  
having a pre-release Kolab-Server-2.2.1 on EC2?

Cheers,

Gunnar

>
> Cheers,
>
> Gunnar
>
>>
>> --
>> Managing Director - Owner: www.intevation.net      (Free Software Company)
>> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
>> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
>> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>>
>
>
>
> --
> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
>
> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
> Tel.   : +49 700 6245 0000                         Bundesstrasse 29
> Fax    : +49 721 1513 52322                        D-20146 Hamburg
> --------------------------------------------------------------------
>     >> Mail at ease - Rent a kolab groupware server at p at rdus <<
> --------------------------------------------------------------------
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081117/0b18c43d/attachment.bin

From kolab-issues at intevation.de  Mon Nov 17 11:18:29 2008
From: kolab-issues at intevation.de (Pierluca)
Date: Mon, 17 Nov 2008 10:18:29 +0000
Subject: [Kolab-devel] [issue3240] DB ERROR in cyrus log file
Message-ID: <1226917109.06.0.693509346145.issue3240@intevation.de>


New submission from Pierluca <pizetalinux at gmail.com>:

Hi, 
I've Kolab 2.2.0 (last stable release) for more than 100K of email user.
I've this problem, every day in log file of cyrus compare this message:

<warning> master[1065]: service pop3 pid 29880 in READY state: terminated abnormally
<warning> imaps[29884]: DBERROR db4: Lock table is out of available locker entries
<error> imaps[29884]: DBERROR: opening /kolab/var/imapd/mailboxes.db: Cannot
allocate memory
<error> imaps[29884]: DBERROR: opening /kolab/var/imapd/mailboxes.db: cyrusdb error
<error> imaps[29884]: Fatal error: can't read mailboxes file
<warning> master[1065]: service imaps pid 29884 in READY state: terminated
abnormally
<warning> pop3[29885]: DBERROR db4: Lock table is out of available locker entries
<error> pop3[29885]: DBERROR: opening /kolab/var/imapd/mailboxes.db: Cannot
allocate memory
<error> pop3[29885]: DBERROR: opening /kolab/var/imapd/mailboxes.db: cyrusdb error
<error> pop3[29885]: Fatal error: can't read mailboxes file
<warning> imap[29883]: DBERROR db4: Lock table is out of available locker entries
<error> imap[29883]: DBERROR: opening /kolab/var/imapd/mailboxes.db: Cannot
allocate memory
<error> imap[29883]: DBERROR: opening /kolab/var/imapd/mailboxes.db: cyrusdb error
<error> imap[29883]: Fatal error: can't read mailboxes file

this problem is critical, later few minutes impad not work.

----------
messages: 17594
nosy: pizeta
priority: urgent
status: unread
title: DB ERROR in cyrus log file
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3240>
___________________________________________________


From lists at infosecurity.ch  Mon Nov 17 11:25:47 2008
From: lists at infosecurity.ch (Fabio Pietrosanti (naif))
Date: Mon, 17 Nov 2008 11:25:47 +0100
Subject: [Kolab-devel] Kolab Server 2.2.1 moves ahead
In-Reply-To: <20081116093950.38465uhrq0yyweos@webmail.pardus.de>
References: <20081116093950.38465uhrq0yyweos@webmail.pardus.de>
Message-ID: <492146AB.4020206@infosecurity.ch>

My compliments for the very good work done!

I am also seeing progress in Debian Package development that would allow 
a greater community to quickly install and use kolab on Debian systems.

One question: There's a delivery date for Kolab 2.2.1?

Fabio Pietrosanti

Gunnar Wrobel wrote:
> Hi!
>
> Just a short note about the Kolab Server 2.2.1 progress:
>
> p at rdus finished the development activities for this Kolab Server 
> version last week. Thus we move into testing and bug fixing now. There 
> should be betas available soon.
>
> What are notable changes in Kolab Server 2.2.1:
>
>   - The Kolab web client upgrades to horde-webmail-1.2 (+ a big Kolab 
> specfic
>     patch).
>   - Support for attachments as described by the Kolab format (leads to 
> photo
>     support in the address book as well as attachments to contacts).
>   - SyncML support for contacts and events.
>   - DIMP: AJAX based "dynamic" web client (horde)
>   - MIMP: mobile mail client (horde)
>
> In addition there are changes concerning the Kolab free/busy system as 
> well as the Kolab mail filters:
>
>   - Removal of kolab-filter, kolab-freebusy, as well as the code in 
> php-kolab
>     and replacement by upstream PEAR packages released via 
> http://pear.horde.org
>
> The main focus of this release is stabilization of the Kolab web 
> client and associated with this a consolidation of the Horde libraries 
> we use within the Kolab Server. While this does not bring much new 
> functionality I believe it provides us with a sound basis for the next 
> three years (as far as I can preview this period yet).
>
> The fact that most of the Kolab code has been moved upstream now has 
> several important side effects:
>
>  1) A single implementation of the Kolab concepts and thus a significant
>     reduction in code duplication.
>  2) Improved code quality.
>  3) phpUnit based unit testing for all Kolab specific modules.
>  4) Clean package releases based on PEAR.
>
> I realize that point 4) means a lot of new work for the native ports 
> but I'm convinced that this approach will reduce the maintenance 
> workload in the long run. It will also bring the different 
> distributions closer together as we have a clear reference point now.
>
> Cheers,
>
> Gunnar
>
> Cheers,
>
> Gunnar
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From kolab-issues at intevation.de  Mon Nov 17 12:39:29 2008
From: kolab-issues at intevation.de (Karl-Heinz Ruskowski)
Date: Mon, 17 Nov 2008 11:39:29 +0000
Subject: [Kolab-devel] [issue3241] Horde: Can't accept invitation
Message-ID: <1226921969.64.0.536152867445.issue3241@intevation.de>


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

When i try to accept an invitation in Horde i get the following error: 

Error sending reply: authentication failure [SMTP: Invalid response code
received from server (code: 535, response: 5.7.0 Error: authentication failed:
generic failure)].

and of course no message is send.

----------
assignedto: wrobel
messages: 17597
nosy: bernhard, khruskowski, martin, thomas, till, wilde, wrobel
priority: urgent
status: unread
title: Horde: Can't accept invitation
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3241>
___________________________________________________


From kolab-issues at intevation.de  Mon Nov 17 15:09:38 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 17 Nov 2008 14:09:38 +0000
Subject: [Kolab-devel] [issue3242] Crash KMHeaders::msgRemoved after
	pressing sync button.
Message-ID: <1226930978.75.0.698153089327.issue3242@intevation.de>


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

enterprise35 20080919.862683

A user reported a crash.
He opened kontact and synced. This had crashed kontact.
(See attachment.)

----------
assignedto: till
files: crash-20081117.txt
messages: 17600
nosy: bernhard, bh, ludwig, osterfeld, pradeepto, till
priority: urgent
status: unread
title: Crash KMHeaders::msgRemoved after pressing sync button.
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3242>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: crash-20081117.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20081117/bbad6f64/crash-20081117.txt

From kolab-issues at intevation.de  Mon Nov 17 15:30:52 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Mon, 17 Nov 2008 14:30:52 +0000
Subject: [Kolab-devel] [issue3243] Store web client user preferences in
	files, not in LDAP
Message-ID: <1226932252.87.0.724532020524.issue3243@intevation.de>


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

As discussed in person, main reasons against storing in LDAP are:
- LDAP entries should not be polluted with large amounts of Horde settings
  -> especially important for integrating in existing LDAP environments
- LDAP should only contain persistent data, not user data

Possible problems with file storage:
- in multi-server setups not all servers have the user's config.
  -> You could still switch back to LDAP, use some file synchronization
     mechanism or use a different backend, e.g. IMAP., or force users to always
     use a specific server (e.g. kolabHomeServer)
- existing user preferences when upgrading
  -> at least documentation on how to switch back to LDAP would be needed,
     even better a way to migrate existing user preferences.

Despite these possible problems the switch should be done now to prevent new
installations from having the additional LDAP entries.

----------
assignedto: wrobel
messages: 17602
nosy: bernhard, martin, thomas, till, wilde, wrobel
priority: urgent
status: unread
title: Store web client user preferences in files, not in LDAP
topic: web client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3243>
___________________________________________________


From aspineux at gmail.com  Mon Nov 17 21:05:38 2008
From: aspineux at gmail.com (Alain Spineux)
Date: Mon, 17 Nov 2008 21:05:38 +0100
Subject: [Kolab-devel] Running Kolab2/OpenPKG-2.2 on Amazon EC2 (was:
	Kolab in the clouds)
In-Reply-To: <20081117083226.17031qut78i2a7fo@webmail.pardus.de>
References: <20081014081347.27441bu8f5a6cfq8@webmail.pardus.de>
	<200810171744.22064.bernhard@intevation.de>
	<20081021111032.13843cl51kv1wayo@webmail.pardus.de>
	<20081117083226.17031qut78i2a7fo@webmail.pardus.de>
Message-ID: <71fe4e760811171205w16e25a16lde3ee684034cbd57@mail.gmail.com>

On Mon, Nov 17, 2008 at 8:32 AM, Gunnar Wrobel <wrobel at pardus.de> wrote:
> Quoting Gunnar Wrobel <wrobel at pardus.de>:
>
>> Quoting Bernhard Reiter <bernhard at intevation.de>:
>>
>>> On Dienstag, 14. Oktober 2008, Gunnar Wrobel wrote:
>>>>
>>>> The current one is AMI "ami-6e2eca07" and I update the thread once
>>>> I  publish others.
>>>
>>> This might warrent a new wiki page to keep the overview and the
>>> instructions. :)
>>
>> Yes, will do that once I have a 2.2 image. I'll write down some
>> instructions on how to use the images then.
>
> I generated a Kolab2/OpenPKG-2.2 server image which is available with the ID
> "ami-c910f4a0".

Hi Gunnar

Could you give us an idea of the cost of the use :
- for example for the installation of kolab2.2
- for its use, say create 2 users and send some emails in between.




>
> In addition I created instructions on how to get a Kolab server up and
> running in 10 minutes. See
>
> https://wiki.kolab.org/index.php/Kolab2_on_Amazons_EC2
>
> Please note that this is really only meant for testing purposes. As far as I
> know most of Amazons EC2 network is black listed as spammers like the
> possibility to start up a virtual machine and send a few mails.
>
> A question to the developer crowd: Is there significant interest in having a
> pre-release Kolab-Server-2.2.1 on EC2?
>
> Cheers,
>
> Gunnar
>
>>
>> Cheers,
>>
>> Gunnar
>>
>>>
>>> --
>>> Managing Director - Owner: www.intevation.net      (Free Software
>>> Company)
>>> Germany Coordinator: fsfeurope.org. Coordinator:
>>> www.Kolab-Konsortium.com.
>>> Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
>>> Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>>>
>>
>>
>>
>> --
>> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
>>
>> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
>> Tel.   : +49 700 6245 0000                         Bundesstrasse 29
>> Fax    : +49 721 1513 52322                        D-20146 Hamburg
>> --------------------------------------------------------------------
>>    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
>> --------------------------------------------------------------------
>>
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>> _______________________________________________
>> Kolab-devel mailing list
>> Kolab-devel at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-devel
>
>
>
> --
> ______ http://kdab.com _______________ http://kolab-konsortium.com _
>
> p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
>
> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
> E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
> Tel.   : +49 700 6245 0000                          Bundesstrasse 29
> Fax    : +49 721 1513 52322                          D-20146 Hamburg
> --------------------------------------------------------------------
>   >> Mail at ease - Rent a kolab groupware server at p at rdus <<
> --------------------------------------------------------------------
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
Alain Spineux
aspineux gmail com
May the sources be with you


From bernhard at intevation.de  Tue Nov 18 12:48:56 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 18 Nov 2008 12:48:56 +0100
Subject: [Kolab-devel] roundup: how to indicate issues that will be worked
	on quite later (was: [issue1382] resmgr accepts concurrent
	overlapping invitations)
In-Reply-To: <1226433876.09.0.0151697078024.issue1382@intevation.de>
References: <1226433876.09.0.0151697078024.issue1382@intevation.de>
Message-ID: <200811181248.56671.bernhard@intevation.de>

On Dienstag, 11. November 2008, Gunnar Wrobel wrote:
> I guess I'm just lacking a
> method in the tracker to indicate that this is a bug that I won't tackle
> unless somebody pushes me. Maybe I should use the "in-progress" marker more
> often to indicate bugs I'm going to work on rather soon.

"deferred" could be a possible value.
Otherwise, just say so in the issue itself.


-- 
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: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081118/6a76d775/attachment.bin

From kolab-issues at intevation.de  Tue Nov 18 14:16:01 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Tue, 18 Nov 2008 13:16:01 +0000
Subject: [Kolab-devel] [issue3244] Crash at KMFolder::addMsg after a second
	import of testmails.
Message-ID: <1227014161.51.0.872181333769.issue3244@intevation.de>


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

enterprise35 kdepim   20081109.881860
             kde-i18n 20081024.875434
Test
Requirements:
The user has a test.mbox file with three mails in his user account.

StepByStep:
1. Import the test.mbox file.
2. Delete the local folder "MBOX-test"
3. Import the test.mbox file again.
=> Crash

----------
assignedto: till
files: crash-import-msgs-20081118.txt
messages: 17620
nosy: bernhard, bh, ludwig, osterfeld, pradeepto, till
priority: bug
status: unread
title: Crash at KMFolder::addMsg after a second import of testmails.
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3244>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: crash-import-msgs-20081118.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20081118/8299c9b9/crash-import-msgs-20081118.txt

From kolab-issues at intevation.de  Tue Nov 18 17:26:03 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Tue, 18 Nov 2008 16:26:03 +0000
Subject: [Kolab-devel] [issue3245] Remove horde.schema from
	kolab-server/slapd.conf.template
Message-ID: <1227025563.41.0.609677912452.issue3245@intevation.de>


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

Split out from kolab/issue3243 (Store web client user preferences in files, not
in LDAP)

horde.schema is no longer needed if user preferences are stored in files, so it
can be removed from slapd.conf.template, but keeping it in the package for
backwards compatibility is important.

If the corresponding line is just disabled, the admin can easily reenable it.

----------
assignedto: wrobel
messages: 17629
nosy: bernhard, martin, thomas, till, wilde, wrobel
priority: bug
status: unread
title: Remove horde.schema from kolab-server/slapd.conf.template
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3245>
___________________________________________________


From bernhard at intevation.de  Tue Nov 18 17:44:25 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 18 Nov 2008 17:44:25 +0100
Subject: [Kolab-devel] Kolab Server 2.2.1 moves ahead
In-Reply-To: <492146AB.4020206@infosecurity.ch>
References: <20081116093950.38465uhrq0yyweos@webmail.pardus.de>
	<492146AB.4020206@infosecurity.ch>
Message-ID: <200811181744.25942.bernhard@intevation.de>

On Montag, 17. November 2008, Fabio Pietrosanti (naif) wrote:
> My compliments for the very good work done!
>
> I am also seeing progress in Debian Package development that would allow
> a greater community to quickly install and use kolab on Debian systems.

I maintain that anyone can install Kolab Server/OpenPKG very quickly 
on Debian Systems. 
(The .deb based approaches, aka Kolab Server/Debian have all been harder to 
install and this is likely to stay this way for a longer time, though this is 
not a drawback.)

> One question: There's a delivery date for Kolab 2.2.1?

Not really.
The plan is to have at least a beta this year.

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: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081118/52767d10/attachment.bin

From bernhard at intevation.de  Tue Nov 18 17:54:33 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 18 Nov 2008 17:54:33 +0100
Subject: [Kolab-devel] make kolabd more robust
In-Reply-To: <71fe4e760810142316v7ce5a194o5fb5aed993b94006@mail.gmail.com>
References: <71fe4e760810141150g1a008e9di1db1ee03d91b8440@mail.gmail.com>
	<20081015060847.14804owrta6cm9es@webmail.pardus.de>
	<71fe4e760810142316v7ce5a194o5fb5aed993b94006@mail.gmail.com>
Message-ID: <200811181754.35894.bernhard@intevation.de>

On Mittwoch, 15. Oktober 2008, Alain Spineux wrote:
> > The idea within kolabd is that new users are stored in a local user db
> > once they are created. If they are not in there the account will be
> > created. So I wouldn't say it is "transaction less".
>
> Yes this is transaction less because kolabd don't
> use this information even if ?it exists. This is too much work to
> check that all account has it existing mailbox created
> at each startup ! This was done in the past but was taking hours ! I
> dont know what is the empyrical system used now,
> but as shown in the user mailing list some mailbox look to be
> forgotten sometime.

From my memory kolabd has a faster local database that it will consulte
for user creating when triggered. So a lost transaction is _not_ a problem.
Kolabd will check on many changes if all users are there and create 
accordingly, even if the current replication part does not have all
the changes.

> > The deletion flag exists as all servers need to purge the entry. But for
> > creation only one server needs to create the account. So the local db
> > solution should be okay.
>
> The deletion flag is not mandatory at all ! 

I was from my perspective for a robust solution to delete stuff
in the right order from all Kolab Server (e.g. one master, two slaves).

> Kolabd could compare imap mailbox and ldap entries
> and delete missing items. But this become slow and then "transaction less"

Was probably considered too risky, think about the directory service
temorarily being in disorder and your precious email folders being deleted...

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: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081118/36df7e12/attachment.bin

From bernhard at intevation.de  Tue Nov 18 18:02:25 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 18 Nov 2008 18:02:25 +0100
Subject: [Kolab-devel]
 =?iso-8859-1?q?CeBIT_Open_Source=3A_Linux_Magazine_?=
 =?iso-8859-1?q?and_Linux=09Foundation_Announce_Call_for_Projects_-_Linux_?=
 =?iso-8859-1?q?Magazine_Online?=
In-Reply-To: <200810172344.04463.ml@radoeka.nl>
References: <200810012230.58439.ml@radoeka.nl>
	<200810171742.54562.bernhard@intevation.de>
	<200810172344.04463.ml@radoeka.nl>
Message-ID: <200811181802.25988.bernhard@intevation.de>

On Freitag, 17. Oktober 2008, Richard Bos wrote:
> > > I don't know if ?
> > > the Konsortium will apply for a free booth but I expect them to be ?
> > > there in any case.
> >
> > The Kolab community could, but the problem is that we need to staff the
> > booth for the time of the trade show, which means a significant effort.
> > CeBIT tends to be quite expensive.
>
> How many days is Cebit normally, I believe it is around 7 days (Wednesday
> till Wednesday), isn't it? 

They might have shortened it a bit to 6 days, 
www.cebit.de has 3rd to 8th of March in 2009.

> When the konsortium is there, is that not 
> enough for kolab? ?What could a community booth add to that (the
> konsortium)?

This is what I was trying to say: For the Kolab-Konsortium this is
a lot of work, so we are probably not doing it, unless we can staff
the booth.

Also we might not apply for a gratis booth, as we are a commercial entity
(doing Free Software - that is, even most "expert"-magazines do not understand 
this fine line).

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: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081118/0bbaeda0/attachment.bin

From liste at gelpi.it  Tue Nov 18 18:41:17 2008
From: liste at gelpi.it (Gelpi Andrea)
Date: Tue, 18 Nov 2008 18:41:17 +0100
Subject: [Kolab-devel] [issue3240] DB ERROR in cyrus log file
In-Reply-To: <1226917109.06.0.693509346145.issue3240@intevation.de>
References: <1226917109.06.0.693509346145.issue3240@intevation.de>
Message-ID: <4922FE3D.5030106@gelpi.it>

Pierluca ha scritto:
> New submission from Pierluca <pizetalinux at gmail.com>:
> 
> Hi, 
> I've Kolab 2.2.0 (last stable release) for more than 100K of email user.
> I've this problem, every day in log file of cyrus compare this message:
> 
> <warning> master[1065]: service pop3 pid 29880 in READY state: terminated abnormally
> <warning> imaps[29884]: DBERROR db4: Lock table is out of available locker entries
> <error> imaps[29884]: DBERROR: opening /kolab/var/imapd/mailboxes.db: Cannot
> allocate memory
> <error> imaps[29884]: DBERROR: opening /kolab/var/imapd/mailboxes.db: cyrusdb error
> <error> imaps[29884]: Fatal error: can't read mailboxes file
> <warning> master[1065]: service imaps pid 29884 in READY state: terminated
> abnormally
> <warning> pop3[29885]: DBERROR db4: Lock table is out of available locker entries
> <error> pop3[29885]: DBERROR: opening /kolab/var/imapd/mailboxes.db: Cannot
> allocate memory
> <error> pop3[29885]: DBERROR: opening /kolab/var/imapd/mailboxes.db: cyrusdb error
> <error> pop3[29885]: Fatal error: can't read mailboxes file
> <warning> imap[29883]: DBERROR db4: Lock table is out of available locker entries
> <error> imap[29883]: DBERROR: opening /kolab/var/imapd/mailboxes.db: Cannot
> allocate memory
> <error> imap[29883]: DBERROR: opening /kolab/var/imapd/mailboxes.db: cyrusdb error
> <error> imap[29883]: Fatal error: can't read mailboxes file
> 
> this problem is critical, later few minutes impad not work.

Do you have something in kernel.log?

I had something similar when my virtual server run out of memory.
I solved adding another swap partition.

-- 
ing. Andrea Gelpi
***************************************************
La Terra non la abbiamo ereditata dai nostri avi,
ma la abbiamo presa in prestito dai nostri bambini.
***************************************************


From aspineux at gmail.com  Wed Nov 19 07:46:39 2008
From: aspineux at gmail.com (Alain Spineux)
Date: Wed, 19 Nov 2008 07:46:39 +0100
Subject: [Kolab-devel] make kolabd more robust
In-Reply-To: <200811181754.35894.bernhard@intevation.de>
References: <71fe4e760810141150g1a008e9di1db1ee03d91b8440@mail.gmail.com>
	<20081015060847.14804owrta6cm9es@webmail.pardus.de>
	<71fe4e760810142316v7ce5a194o5fb5aed993b94006@mail.gmail.com>
	<200811181754.35894.bernhard@intevation.de>
Message-ID: <71fe4e760811182246q2da3e1fcqf60163937a1faf4c@mail.gmail.com>

On Tue, Nov 18, 2008 at 5:54 PM, Bernhard Reiter <bernhard at intevation.de> wrote:
> On Mittwoch, 15. Oktober 2008, Alain Spineux wrote:
>> > The idea within kolabd is that new users are stored in a local user db
>> > once they are created. If they are not in there the account will be
>> > created. So I wouldn't say it is "transaction less".
>>
>> Yes this is transaction less because kolabd don't
>> use this information even if  it exists. This is too much work to
>> check that all account has it existing mailbox created
>> at each startup ! This was done in the past but was taking hours ! I
>> dont know what is the empyrical system used now,
>> but as shown in the user mailing list some mailbox look to be
>> forgotten sometime.
>
> From my memory kolabd has a faster local database that it will consulte
> for user creating when triggered. So a lost transaction is _not_ a problem.
> Kolabd will check on many changes if all users are there and create
> accordingly, even if the current replication part does not have all
> the changes.
>
>> > The deletion flag exists as all servers need to purge the entry. But for
>> > creation only one server needs to create the account. So the local db
>> > solution should be okay.
>>
>> The deletion flag is not mandatory at all !

I said that to confirm the utility of a creationflag.
A creationflag is not more meaningless than a deletionflag !
None of them are mandatory, but both help in the creation and deletion process.

>
> I was from my perspective for a robust solution to delete stuff
> in the right order from all Kolab Server (e.g. one master, two slaves).
>
>> Kolabd could compare imap mailbox and ldap entries
>> and delete missing items. But this become slow and then "transaction less"
>
> Was probably considered too risky, think about the directory service
> temorarily being in disorder and your precious email folders being deleted...
>
> 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
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
Alain Spineux
aspineux gmail com
May the sources be with you


From kolab-issues at intevation.de  Wed Nov 19 08:02:24 2008
From: kolab-issues at intevation.de (Angeline Vogel)
Date: Wed, 19 Nov 2008 07:02:24 +0000
Subject: [Kolab-devel] [issue3246] Comprehensive Healthcare Contact List
Message-ID: <MAILanX39HmomgewZa700007123@mail.xla-tech.com>


New submission from Angeline Vogel <noreplyhere at mail.xla-tech.com>:

Currently in Practice:  Doctors in the United States 

Coverage for many different medical specialties

16 different sortable fields

This week only you pay only: $398

{}{}{} The above package also comes with these four lists: {}{}{}

++> Chiropractors

++> Physical Therapists

++> Massage Therapists

++> Acupuncturists

contact your rep:: White at mediprodat.com

from now until Friday ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   to adjust your subscription status email to release at mediprodat.com

----------
messages: 17635
nosy: kolab-gentoo-owner, noreplyhere
status: unread
title: Comprehensive Healthcare Contact List
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3246>
___________________________________________________


From bernhard at intevation.de  Wed Nov 19 09:05:04 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 19 Nov 2008 09:05:04 +0100
Subject: [Kolab-devel] make kolabd more robust
In-Reply-To: <71fe4e760811182246q2da3e1fcqf60163937a1faf4c@mail.gmail.com>
References: <71fe4e760810141150g1a008e9di1db1ee03d91b8440@mail.gmail.com>
	<200811181754.35894.bernhard@intevation.de>
	<71fe4e760811182246q2da3e1fcqf60163937a1faf4c@mail.gmail.com>
Message-ID: <200811190905.07865.bernhard@intevation.de>

On Mittwoch, 19. November 2008, Alain Spineux wrote:
> I said that to confirm the utility of a creationflag.
> A creationflag is not more meaningless than a deletionflag !
> None of them are mandatory, but both help in the creation and deletion
> process.

Potentially yes, but there is a difference between creation and deletion
which makes the deletionflag mandatory to cut risks.
(Which is why we did it for deletion and not creation as far as I remember.)

-- 
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: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081119/fb6071e6/attachment.bin

From kolab-issues at intevation.de  Wed Nov 19 09:59:15 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 19 Nov 2008 08:59:15 +0000
Subject: [Kolab-devel] [issue3247] Once in a while moving folder leads to
	losing mails
Message-ID: <1227085155.86.0.795698787896.issue3247@intevation.de>


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

enterprise35 kdepim   20081118.886071
             kde-i18n 20081024.875434

I did the operations sync/Moving the test folder with d'n'd/Moving mails into
the test folder. Once in a while after this operations, the moved folder is
suddently empty. Anyway I cannot reproduce this behaviour. It just happens once
in a while.
I also once encountered a crash this way.(See attachment).

----------
assignedto: till
files: crash-moving-mails-20081119.txt
messages: 17638
nosy: bernhard, bh, ludwig, osterfeld, pradeepto, till
priority: urgent
status: unread
title: Once in a while moving folder leads to losing mails
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3247>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: crash-moving-mails-20081119.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20081119/4f977b90/crash-moving-mails-20081119.txt

From kolab-issues at intevation.de  Wed Nov 19 11:29:24 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 19 Nov 2008 10:29:24 +0000
Subject: [Kolab-devel] [issue3248] A replay to a SMIME mail should be of
	SMIME type.
Message-ID: <1227090564.6.0.828755233648.issue3248@intevation.de>


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

enterprise35  kdepim   20081118.886071
              kde-i18n 20081024.875434

User A sends a SMIME encrypted and signed mail to user B.
User B has configured that he favors OpenPGP as encryption type.
B just have a SMIME key of A.
Now B replys to A's mail.
In this case the encrpytion type of the reply mail is Openpgp but should be SMIME.

----------
assignedto: till
messages: 17639
nosy: bernhard, bh, ludwig, osterfeld, pradeepto, till
priority: bug
status: unread
title: A replay to a SMIME mail should be of SMIME type.
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3248>
___________________________________________________


From kolab-issues at intevation.de  Wed Nov 19 11:34:47 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 19 Nov 2008 10:34:47 +0000
Subject: [Kolab-devel] [issue3249] Strange crash while replying to an SMIME
	mail.
Message-ID: <1227090887.36.0.486776382281.issue3249@intevation.de>


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

enterprise35  kdepim   20081118.886071
              kde-i18n 20081024.875434

User A sends a SMIME encrypted and signed mail to user B.
User B has configured that he favors OpenPGP as encryption type.
B just have a SMIME key of A.
Now B replys to A's mail.
B sends the reply. He is informed that the encryption setting is conflicting.
But he tries to send the mail and chooses the SMIME key of A as encryption key.
At the end kontact crashs with no backtrace but console output:
kontact: messagecomposer.cpp:2150: void MessageComposer::pgpSignedMsg(const
QByteArray&, Kleo::CryptoMessageFormat): Zusicherung ?!signingKeys.empty()?
nicht erf?llt.
*** KMail got signal 6 (Crashing)
kmail: [virtual void KMComposeWin::autoSaveMessage()]

----------
assignedto: till
messages: 17641
nosy: bernhard, bh, ludwig, osterfeld, pradeepto, till
priority: urgent
status: unread
title: Strange crash while replying to an SMIME mail.
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3249>
___________________________________________________


From kolab-issues at intevation.de  Wed Nov 19 12:47:41 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 19 Nov 2008 11:47:41 +0000
Subject: [Kolab-devel] [issue3250] Kontacts sends unencryptable mail.
Message-ID: <1227095260.96.0.374461003507.issue3250@intevation.de>


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

enterprise35 kdepim   20081118.886071
              kde-i18n 20081024.875434

User A sends a SMIME encrypted and signed mail to user B.
User B has configured that he favors OpenPGP as encryption type.
B just have a SMIME key of A.
Now B replys to A's mail.
In the composer is selected to encrypt with openPGP.
B sends the mail. He is informed about a conflict, but he continues to send the
mail. B chooses the SMIME key as encrpytion key.
Now a wrong encrypted mail is send. 
This should not happen.

----------
assignedto: till
messages: 17651
nosy: bernhard, bh, ludwig, osterfeld, pradeepto, till
priority: urgent
status: unread
title: Kontacts sends unencryptable mail.
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3250>
___________________________________________________


From kolab-issues at intevation.de  Wed Nov 19 14:24:05 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 19 Nov 2008 13:24:05 +0000
Subject: [Kolab-devel] [issue3251] The xml type of a home phone number of a
	contact is "home2".
Message-ID: <1227101045.12.0.296723699896.issue3251@intevation.de>


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

enterprise35 kdepim   20081118.886071
             kde-i18n 20081024.875434

Test:
1. Switch to contact plugin.
2. Create a new contact with home phone number and business phone number.
3. Look at the kolab.xml file of this new contact.

In the kolab.xml file is the home phone number stated with type "home2"
and the business phone number stated with type "business2".

This leads to conflict with horde and tolec as they expect home1 and business1
and cannot display it this way.

Please have a look at the example.xml (created by kontact)

----------
assignedto: till
files: example.xml
messages: 17655
nosy: bernhard, bh, ludwig, osterfeld, pradeepto, till
priority: bug
status: unread
title: The xml type of a home phone number of a contact is "home2".
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3251>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.xml
Type: text/xml
Size: 1257 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081119/437b70a5/example.xml

From kolab-issues at intevation.de  Wed Nov 19 15:34:29 2008
From: kolab-issues at intevation.de (Gracie Osborne)
Date: Wed, 19 Nov 2008 14:34:29 +0000
Subject: [Kolab-devel] [issue3252] D.entists Directory in the USA
Message-ID: <20081119143425.8CDD794A6AE@kolab.intevation.de>


New submission from Gracie Osborne <noreplyhere at 200-113-107-226.static.tie.cl>:

Enhance your marketing efforts with this:

-> 164,671 Dent ists 
-> 158,863 Addresses
-> 163,936 Telephone Numbers
-> 77,804 Office Fax Numbers 
-> 45,967 E-Mails

from now until Friday we have lowered the price to $294 - a $300 savings!

For details please send an email to Rosenberg at mediprodat.com

By emailing release at mediprodat.com you will have your email taken off

----------
messages: 17659
nosy: noreplyhere1
status: unread
title: D.entists Directory in the USA
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3252>
___________________________________________________


From kolab-issues at intevation.de  Wed Nov 19 17:05:51 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Wed, 19 Nov 2008 16:05:51 +0000
Subject: [Kolab-devel] [issue3253] syncrepl backend currently does not
	support slave servers
Message-ID: <1227110751.54.0.722333484633.issue3253@intevation.de>


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

In msg17307 of kolab/issue1755 (syncrepl support (for OpenLDAP >=2.4.6)) Mathieu
Parent writes:

Note that the current implementation doesn't allow slave servers. We have to
solve this.

Neil Price spotted this at
http://lists.alioth.debian.org/pipermail/pkg-kolab-devel/2008-October/001827.html.

----------
assignedto: rbos
messages: 17662
nosy: bernhard, martin, mathieu.parent, mhuewe, rbos, thomas, till, wilde, wrobel
priority: urgent
status: unread
title: syncrepl backend currently does not support slave servers
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3253>
___________________________________________________


From thomas at intevation.de  Wed Nov 19 18:40:44 2008
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Wed, 19 Nov 2008 18:40:44 +0100
Subject: [Kolab-devel] Freeze! (was: Re: Kolab Server 2.2.1 moves ahead)
In-Reply-To: <492146AB.4020206@infosecurity.ch>
References: <20081116093950.38465uhrq0yyweos@webmail.pardus.de>
	<492146AB.4020206@infosecurity.ch>
Message-ID: <20081119174044.GG651.thomas@intevation.de>

* Fabio Pietrosanti (naif) <lists at infosecurity.ch> [20081117 11:25]:
> One question: There's a delivery date for Kolab 2.2.1?

After a talk with Bernhard we think that the following should be done:

1. Freeze now, so I can concentrate on packaging, upgrading and
   other release preparations.

2. Get out 2.2.1-beta1 as soon as possible, depending on above work
   packages this will be end of next week or the first week of
   December.

3. If this beta works as good as we hope, we have a release in
   December, otherwise there will be a release candidate first.

As the web client (Horde) received the most feature enhancements,
this needs the most testing, e.g. if dimp's Kolab features work fine
and if SyncML is usable.

Many packages got shuffled around, but after beta1 the package list
is final to give native packagers (and us) a chance to catch up with
e.g. upgrading issues.

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: 206 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081119/73beffe7/attachment.bin

From bernhard at intevation.de  Thu Nov 20 08:47:16 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 20 Nov 2008 08:47:16 +0100
Subject: [Kolab-devel] Freeze! (was: Re: Kolab Server 2.2.1 moves ahead)
In-Reply-To: <20081119174044.GG651.thomas@intevation.de>
References: <20081116093950.38465uhrq0yyweos@webmail.pardus.de>
	<492146AB.4020206@infosecurity.ch>
	<20081119174044.GG651.thomas@intevation.de>
Message-ID: <200811200847.16309.bernhard@intevation.de>

On Mittwoch, 19. November 2008, Thomas Arendsen Hein wrote:
> 1. Freeze now, so I can concentrate on packaging, upgrading and
> ? ?other release preparations.

Note that the following two patches we still might consider:
kolab/issue3238 (Double Entries with SyncML when the folder uid validity 
changes)
kolab/issue3237 (Double Sync with SyncML when using external client)

Otherwise we want problem fixes only during the freeze
and only if the problems are significant and the changes are low risk.


-- 
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: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081120/a8a341e6/attachment.bin

From kolab-issues at intevation.de  Thu Nov 20 10:21:02 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 20 Nov 2008 09:21:02 +0000
Subject: [Kolab-devel] [issue3254] printed mail cut at the left side
Message-ID: <1227172862.08.0.367519575249.issue3254@intevation.de>


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

enterprise35 kdepim   20081118.886071
             kde-i18n 20081024.875434

Test:
1. Select a mail with attachment.
2. Press print
3. Print it into a file and open the file.

(See attachment. The left side is cut. This looks ugly.)

----------
assignedto: till
files: print.ps
messages: 17676
nosy: bernhard, bh, ludwig, osterfeld, pradeepto, till
priority: minor bug
status: unread
title: printed mail cut at the left side
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3254>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: print.ps
Type: application/postscript
Size: 42242 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081120/a838e9d6/print-0001.ps

From kolab-issues at intevation.de  Thu Nov 20 10:55:25 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 20 Nov 2008 09:55:25 +0000
Subject: [Kolab-devel] [issue3255] Deleting a whole day event doesn't
	trigger rebuild of the monthday view
Message-ID: <1227174925.08.0.42848517996.issue3255@intevation.de>


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

enterprise35 kdepim   20081118.886071
             kde-i18n 20081024.875434

Test:
1. Switch to the calendar plugin.
2. Create a whole day event at a day withot any other event.
3. Sync.
4. Delete the event.
Notice: in the left monthday view the font of the day is still bold, even as
ther is no longer a event at that day. This is a bit confusing.

----------
assignedto: till
messages: 17677
nosy: bernhard, bh, ludwig, osterfeld, pradeepto, till
priority: minor bug
status: unread
title: Deleting a whole day event doesn't trigger rebuild of the monthday view
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3255>
___________________________________________________


From kolab-issues at intevation.de  Thu Nov 20 17:11:12 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Thu, 20 Nov 2008 16:11:12 +0000
Subject: [Kolab-devel] [issue3256] resmgr responses should reflect server
	revision in PRODID
Message-ID: <1227197472.83.0.557410210875.issue3256@intevation.de>


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

I'm inviting an account that automatically answers, the resulting
iCalender response has an outdated version information.
Tested Kolab Server 2.2.0 gives me:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//proko2//resmgr 1.0//EN

Expectation: No "proko2" anymore, but something that reflects
on that it is Kolab Server its revision and possibly the revisions
of main packages involved.

----------
assignedto: thomas
messages: 17694
nosy: bernhard, thomas, wrobel
priority: minor bug
status: unread
title: resmgr responses should reflect server revision in PRODID
topic: release, server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3256>
___________________________________________________


From kolab-issues at intevation.de  Thu Nov 20 18:15:06 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Thu, 20 Nov 2008 17:15:06 +0000
Subject: [Kolab-devel] [issue3257] PEAR-Mail_Mime-1.3.1-1 conflicts with
	PEAR-Mail_mimeDecode-1.5.0-1
Message-ID: <1227201306.45.0.243219648606.issue3257@intevation.de>


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

file /kolab/lib/php/Mail/mimeDecode.php conflicts between attempted
installs of PEAR-Mail_Mime-1.3.1-1 and PEAR-Mail_mimeDecode-1.5.0-1

Do I assume correctly that PEAR-Mail_Mime is no longer needed?
At least rpm does not complain if I do not install it, so no package has it as
dependency. Horde_MIME requires PEAR-Mail_mimeDecode

----------
assignedto: wrobel
messages: 17698
nosy: bernhard, martin, thomas, till, wilde, wrobel
priority: urgent
status: unread
title: PEAR-Mail_Mime-1.3.1-1 conflicts with PEAR-Mail_mimeDecode-1.5.0-1
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3257>
___________________________________________________


From kolab-issues at intevation.de  Thu Nov 20 18:20:29 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Thu, 20 Nov 2008 17:20:29 +0000
Subject: [Kolab-devel] [issue3258] Building kolab-webclient from CVS fails
Message-ID: <1227201629.7.0.797401920981.issue3258@intevation.de>


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

When doing 'make kolab' in CVS it fails during build of kolab-webclient:

+ cd horde-webmail-1.2
+ echo 'Patch #0 (horde-webmail-1.2.0_kolab_openpkg.patch):'
Patch #0 (horde-webmail-1.2.0_kolab_openpkg.patch):
+ /kolab/lib/openpkg/patch -p1 -s -b
1 out of 2 hunks FAILED -- saving rejects to file lib/Horde/Share/kolab.php.rej
Reversed (or previously applied) patch detected!  Assume -R? [n]

----------
assignedto: wrobel
messages: 17699
nosy: bernhard, martin, thomas, till, wilde, wrobel
priority: critical
status: unread
title: Building kolab-webclient from CVS fails
topic: server, web client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3258>
___________________________________________________


From kolab-issues at intevation.de  Fri Nov 21 04:46:06 2008
From: kolab-issues at intevation.de (childish Wooten)
Date: Fri, 21 Nov 2008 03:46:06 +0000
Subject: [Kolab-devel] [issue3259] Listing of radiologists and many other
	popular specialties
Message-ID: <SINFACAB-MESSAGkhbG0000ef00@sinfacab-messag.sinfacables.ma>


New submission from childish Wooten <Denny at 41.248.247.222>:

Board Certified Doctors in the US 

Most medical specialties covered

you can sort by many different fields like zip or county

Reduced to only: $396

~~~~~ We will give you the lists below at no extra charge if you order this week ~~~~~

==> Dentists

==> Veterinarians

==> Physical Therapists

==> Visiting Nurses & RN's

contact by email - : Cantrell at mediprodat.com

for only this week ~~~~~~~~~~~~~~~~~~~~   By emailing release at mediprodat.com you will have your email taken off

----------
messages: 17705
nosy: Denny, droldham, info6, info7, info8, josh.piskina, keit.fomotskin, krishnakumarms, l-godsel, marc2
status: unread
title: Listing of radiologists  and many other popular specialties
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3259>
___________________________________________________


From kolab-issues at intevation.de  Fri Nov 21 15:14:53 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Fri, 21 Nov 2008 14:14:53 +0000
Subject: [Kolab-devel] [issue3260] kolabfilter does not allow empty sender
	(and therefore MAILER-DAEMON)
Message-ID: <1227276893.45.0.0622596334664.issue3260@intevation.de>


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

Current CVS HEAD and Kolab_Filter-0.1.0.20081114-20081114:

kolab-n$ /kolab/bin/php -c /kolab/etc/apache/php.ini -f /kolab/bin/kolabfilter
-- --host=example.com --sender= --recipient=user at example.com
--config=/kolab/etc/kolab/kolabfilter.conf
Please provide a value for the sender and the recipient.

Usage: kolabfilter [options]

An empty sender should be no problem and it worked in Kolab server 2.2.0

This breaks e.g. bounces and mails from kolabquotawarn.

----------
assignedto: wrobel
messages: 17716
nosy: bernhard, martin, thomas, till, wilde, wrobel
priority: critical
status: unread
title: kolabfilter does not allow empty sender (and therefore MAILER-DAEMON)
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3260>
___________________________________________________


From kolab-issues at intevation.de  Fri Nov 21 17:09:56 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Fri, 21 Nov 2008 16:09:56 +0000
Subject: [Kolab-devel] [issue3261] Kolab_Filter (and probably others) not
	required by any rpm
Message-ID: <1227283796.77.0.0485379621147.issue3261@intevation.de>


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

$ openpkg rpm -e Kolab_Filter
this just works without any other package complaining that this is needed for
something.

install-kolab.sh will not try to install it unless the package is manually
specified, and of course there are many other reasons to keep the dependencies
accurate.

----------
assignedto: wrobel
messages: 17718
nosy: bernhard, martin, thomas, till, wilde, wrobel
priority: urgent
status: unread
title: Kolab_Filter (and probably others) not required by any rpm
topic: release, server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3261>
___________________________________________________


From kolab-issues at intevation.de  Fri Nov 21 18:32:09 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Fri, 21 Nov 2008 17:32:09 +0000
Subject: [Kolab-devel] [issue3262] web admin: versions page needs to be
	updated for CVS HEAD
Message-ID: <1227288728.99.0.104102228033.issue3262@intevation.de>


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

Due to the renaming of many packages, the page is no longer complete.

Our patched sqlite should show there, too, maybe by adding a _kolab

And the current way is cumbersome to maintain, because there are too many small
autoconf variables:

  @RPM@ -q --qf "%{NAME}: %{VERSION}-%{RELEASE}\n" \
    @kolab_pkgs@ \
    @amavisd_pkg@ \
    @emailserver_pkg@ \
    @imap_pkg@ \
    @webserver_pkg@ \
    @kolab_pkg@ \
    @kolab_webadmin_pkg@ \
    @kolab_filter_pkg@ \
    @kolab_freebusy_pkg@ \
    @perl_kolabconf_pkg@ \
    @perl_kolab_pkg@ \
    @php_kolab_pkg@ \
    | sort

Maybe just fold more packages into @kolab_pkgs@

----------
assignedto: thomas
messages: 17722
nosy: bernhard, martin, thomas, till, wilde, wrobel
priority: urgent
status: unread
title: web admin: versions page needs to be updated for CVS HEAD
topic: release, server, web admin
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3262>
___________________________________________________


From kolab-issues at intevation.de  Fri Nov 21 21:06:56 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Fri, 21 Nov 2008 20:06:56 +0000
Subject: [Kolab-devel] [issue3263] Create a filter action for setting a cc:
	header for a possible automatic response
Message-ID: <1227298016.49.0.718270508627.issue3263@intevation.de>


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

It should be possible to solve the use case:
Forward an email to a fixed to: and cc: address using inline forward
and a template.

Having fixed
   kolab/issue3228 (forwarding filter action does not directly send the email)
we only need a filter action that can set a prospective cc:
(carbon-copy) header for a possible reply mail, e.g. when it is send
automatically by another filter action.

----------
assignedto: till
messages: 17727
nosy: bernhard, ludwig, till
priority: urgent
status: unread
title: Create a filter action for setting a cc: header for a possible automatic response
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3263>
___________________________________________________


From kolab-issues at intevation.de  Sun Nov 23 18:33:28 2008
From: kolab-issues at intevation.de (=?utf-8?q?Albrecht_Dre=C3=9F?=)
Date: Sun, 23 Nov 2008 17:33:28 +0000
Subject: [Kolab-devel] [issue3264] Some Kolabd log files are not rotated
Message-ID: <1227461608.87.0.889196167238.issue3264@intevation.de>


New submission from Albrecht Dre? <albrecht.dress at lios-tech.com>:

The following log files are apparently not being rotated:

- /kolab/var/kolab-freebusy/log/freebusy.log
- /kolab/var/kolab-freebusy/log/php-error.log
- /kolab/var/kolab-filter/log/fatal.log
- /kolab/var/kolab-filter/log/filter.log

This seems to be caused by the following statements in the file
/kolab/etc/rc.d/rc.kolabd:

    kolabd_log_resmgr_logfile="@resmgr_logfile@"
    kolabd_log_freebusy_logfile="@freebusy_logfile@"
    kolabd_log_fbview_logfile="/kolab/var/resmgr/fbview.log"

The first two lines might indicate that something went wrong during the
installation.  The "resmgr" file/folder does not exist.

----------
messages: 17728
nosy: albrecht.dress
priority: bug
status: unread
title: Some Kolabd log files are not rotated
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3264>
___________________________________________________


From kolab-issues at intevation.de  Mon Nov 24 14:21:52 2008
From: kolab-issues at intevation.de (Volker Krause)
Date: Mon, 24 Nov 2008 13:21:52 +0000
Subject: [Kolab-devel] [merge84] Retrieving of audit log error e35 -> e4
Message-ID: <1227532911.98.0.00884599381581.merge84@intevation.de>


New submission from Volker Krause <volker at kdab.net>:

877883 (feel free to assign back to me after this one, I should be able to 
merge the remaining ones myself)
886602
886603
886604
886606

----------
assignedto: marc
messages: 17731
nosy: marc, vkrause
priority: normal
status: unread
title: Retrieving of audit log error e35 -> e4
_________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/merge84>
_________________________________________________


From kolab-issues at intevation.de  Mon Nov 24 18:56:57 2008
From: kolab-issues at intevation.de (Marc Mutz)
Date: Mon, 24 Nov 2008 17:56:57 +0000
Subject: [Kolab-devel] [issue3265] OpenPGP key expiry warning not emitted
	for signing keys
Message-ID: <1227549417.76.0.321581304862.issue3265@intevation.de>


New submission from Marc Mutz <marc at kdab.net>:

To test, configure the end-user signing certificate expiry warning to trigger 
on very high numbers already (I used 140, since my work keys expire at the end 
of calendar years). Leave the encryption warning at a low level.

Expectation: one is warned about the signing cert.
Actual: no warning is issued.

----------
assignedto: marc
messages: 17736
nosy: bernhard, marc, till
priority: bug
status: unread
title: OpenPGP key expiry warning not emitted for signing keys
topic: enterprise35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3265>
___________________________________________________


From kolab-issues at intevation.de  Tue Nov 25 04:01:12 2008
From: kolab-issues at intevation.de (Dominique mandrel)
Date: Tue, 25 Nov 2008 03:01:12 +0000
Subject: [Kolab-devel] [issue3266] Healthcare Industry Contact List
Message-ID: <MARTEoHLwo6vLxZm4Rp0000089a@marte.berchinet.local>


New submission from Dominique mandrel <Anna at ns1.neonatus.net>:

Current Physicians in America 

Data for the many various medical specialties

many fields which can easily be sorted in excel

This week only you pay only: $399

***** Receive the items below as a Bon.US if  you order this week *****

>> Dentists

>> Veterinarians

>> Physical Therapists

>> Visiting Nurses & RN's

your rep is - : Hagan at statlists.com

for this week ~~~~~~~~~~~~~~~~~~~~   to get off please email gone at statlists.com

----------
messages: 17739
nosy: 21dtf, Anna, customercare, info10, info9, mpetraglia, mriedi, stacy
status: unread
title: Healthcare Industry Contact List
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3266>
___________________________________________________


From kolab-issues at intevation.de  Tue Nov 25 17:47:11 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Tue, 25 Nov 2008 16:47:11 +0000
Subject: [Kolab-devel] [merge85] php-kolab/Kolab_Filter/kolab-issue3260.patch
Message-ID: <1227631631.06.0.783576802078.merge85@intevation.de>


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


From ml at radoeka.nl  Wed Nov 26 08:26:38 2008
From: ml at radoeka.nl (Richard Bos)
Date: Wed, 26 Nov 2008 08:26:38 +0100
Subject: [Kolab-devel] why does the pkg Auth require Kolab_Server?
In-Reply-To: <200811242139.21996.richard@radoeka.nl>
References: <200811242135.39609.richard@radoeka.nl>
	<200811242139.21996.richard@radoeka.nl>
Message-ID: <200811260826.38514.ml@radoeka.nl>

Hi,

Op Monday 24 November 2008 21:39:21 schreef Richard Bos:
> Op Monday 24 November 2008 21:35:39 schreef Richard Bos:
> > why does Kolab_Server require Auth and Auth Kolab_Server? ?The latter
> > does not seem correct to me.
>
> a bit related to this, why is there a package called Auth and Horde_Auth. ?
> Should Auth not just be called Horde_Auth?

I checked the packages that are shown, when one uses these pages:
http://pear.horde.org/index.php?category=framework
http://pear.horde.org/index.php?category=framework&page=[1-5]
and captured all the listed packages, and looked for Group, Auth and Util.  
Non of those (last 3) are listed there as a pear.horde package....?  So, 
should the package Util indeed be read as Horde_Util and likewise the other 2 
as Horde_Auth and Horde_Group?

Sorry I have more questions, related to this.  I'm building horde package 16 
now and it looks I'm half way the dependency list.... How come that the 
package kolab_freebusy and filter that were moved from kolab cvs to horde.org 
result in so many horde packages?  It is almost insane.  Although you stated 
that this is better maintainable, it does not look that way.  Anyway, how 
come that so many horde packages are needed to replace kolab_freebusy and 
filter from kolab cvs (just curious nothing more), are those packages also 
used for the applications, like ingo, turba, imp, etc?

Last question for this email: the package Auth (or is it Horde_Auth?) has 
among its dependencies 2 PHP extensions; pam_auth and sasl:
http://pear.horde.org/index.php?package=Auth&downloads  As those extensions 
were not needed for the kolab_flter and freebusy packages from kolab cvs, I 
wonder if they are needed for Kolab_Filter and Kolab_Freebusy from 
pear.horde.  I ask because the extensions do not seem to be available via 
openSUSE rpms...  If they are not needed, I rather don't spend my time on 
getting those php extensions build.


-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From richard at radoeka.nl  Wed Nov 26 10:34:47 2008
From: richard at radoeka.nl (Richard Bos)
Date: Wed, 26 Nov 2008 10:34:47 +0100
Subject: [Kolab-devel] pear rpmbuild advice
In-Reply-To: <20081123214751.108877ntg9ampkg8@webmail.pardus.de>
References: <200811212347.39544.richard@radoeka.nl>
	<20081123214751.108877ntg9ampkg8@webmail.pardus.de>
Message-ID: <200811261034.48280.richard@radoeka.nl>

Hi,

Why is phpunit required as dependency for Kolab_Server?
 http://pear.horde.org/index.php?package=Kolab_Server&release=0.2.0&downloads

Is this a runtime dependency or a buildtime dependency.  In case it is a 
runtime dependency, why is a testing framework needed as runtime dependency 
for the kolab-server module (just curious, wanting to learn something).


-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.


From ml at radoeka.nl  Wed Nov 26 10:35:03 2008
From: ml at radoeka.nl (Richard Bos)
Date: Wed, 26 Nov 2008 10:35:03 +0100
Subject: [Kolab-devel] pear rpmbuild advice
In-Reply-To: <20081123214751.108877ntg9ampkg8@webmail.pardus.de>
References: <200811212347.39544.richard@radoeka.nl>
	<20081123214751.108877ntg9ampkg8@webmail.pardus.de>
Message-ID: <200811261035.03816.ml@radoeka.nl>

Hi,

Why is phpunit required as dependency for Kolab_Server?
 http://pear.horde.org/index.php?package=Kolab_Server&release=0.2.0&downloads

Is this a runtime dependency or a buildtime dependency.  In case it is a 
runtime dependency, why is a testing framework needed as runtime dependency 
for the kolab-server module (just curious, wanting to learn something).


-- 
Richard Bos
Without a home the journey is endless


From kolab-issues at intevation.de  Wed Nov 26 18:32:18 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Wed, 26 Nov 2008 17:32:18 +0000
Subject: [Kolab-devel] [issue3267] kontact: groupware invitation buttons not
	displayed with mail from web client
Message-ID: <1227720737.9.0.270425983541.issue3267@intevation.de>


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

I sent the attached invitation from the Kolab web client 1.2
(i.e. current Horde from Kolab CVS HEAD)
to Kontact Version 1.2.9 (enterprise35 20081118.886071)

The mail window displays:

  test 4 (on 11/26/08 at 09:00)

  Attendees: thomas at intevation.de

  Attached is an iCalendar file ...

and the invitation box inside the mail window shows:

  You have been invited to this meeting
  What:  test 4
    Where:  Location unspecified
    Start Time:  2008-11-26 09:00
    End Time:  2008-11-26 10:00
    Duration:  1 hour

BUT: The usual buttons [Accept] [Accept cond.] ... are not displayed!

----------
assignedto: till
files: horde-invitation.mbox
messages: 17792
nosy: bernhard, bh, ludwig, osterfeld, thomas, till, vkrause, wrobel
priority: urgent
status: unread
title: kontact: groupware invitation buttons not displayed with mail from web client
topic: enterprise35, kde client, web client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3267>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: horde-invitation.mbox
Type: application/octet-stream
Size: 2301 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081126/3b74eb28/horde-invitation.exe

From kolab-issues at intevation.de  Wed Nov 26 18:37:27 2008
From: kolab-issues at intevation.de (Marc Mutz)
Date: Wed, 26 Nov 2008 17:37:27 +0000
Subject: [Kolab-devel] [issue3268] kmail reply prefixes changes require
	restart of app to take effect
Message-ID: <1227721047.67.0.104359219165.issue3268@intevation.de>


New submission from Marc Mutz <marc at kdab.net>:

To test:
1. Clear the list of reply prefixes in Configure KMail -> Composer -> Subject
2. [x] Replace recognised reply prefixes with "Re"
3. Restart KMail/Kontact, have a mail ready with e.g. AW: Foo bar subject
4. reply to said mail
-> the reply prefix is not recognised (expected)
5. Add "AW:" to Configure KMail -> Composer -> Subject
6. reply to said mail again
-> the reply prefix is still not recognised (bug)

It seems kmmsgbase.cpp's static list of reply prefixes isn't reloaded properly.

----------
assignedto: marc
messages: 17793
nosy: bernhard, marc, till
priority: minor bug
status: unread
title: kmail reply prefixes changes require restart of app to take effect
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3268>
___________________________________________________


From kolab-issues at intevation.de  Wed Nov 26 18:51:19 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Wed, 26 Nov 2008 17:51:19 +0000
Subject: [Kolab-devel] [issue3269] option for web client to send invitations
	in the mail body
Message-ID: <1227721879.02.0.0209655844837.issue3269@intevation.de>


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

Kontact is configured to send invitations in the mail body by default, according
to the tooltip of the corresponding option to be compatible with Outlook (I
suspect this means Outlook before 2003).

Horde sends a large text with https links to accept/decline the invitations in
the mail text and attaches the ics file.
1. This might confuse kontact users as it shows both, the mail text and the
invitation box (yes, that's probably a kontact bug, but not discussed here)
2. This option might allow interoperability with e.g. Outlook 2000

----------
assignedto: wrobel
messages: 17795
nosy: bernhard, martin, thomas, till, wilde, wrobel
priority: feature
status: unread
title: option for web client to send invitations in the mail body
topic: web client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3269>
___________________________________________________


From kolab-issues at intevation.de  Wed Nov 26 19:01:43 2008
From: kolab-issues at intevation.de (Sascha Wilde)
Date: Wed, 26 Nov 2008 18:01:43 +0000
Subject: [Kolab-devel] [issue3270] Kontact displays MIME
	multipart/alternative as if it were multipart/mixed
Message-ID: <1227722503.17.0.496895953225.issue3270@intevation.de>


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

Thomas reported this already in Issue1166 (more than 2 years ago!):

Kontact/kmail displays all parts of multipart/alternative MIME-Parts
simultaneously, just as if it were multipart/mixed.[0]

Besides violating the semantics defined in RfC2046 this is quite
problematic for example with Invitations generated by the Horde web
client (see attached Example):

The relevant part (the rendered vCal Object) is way down the display,
while the URLs of the alternative plain text part are quite prominent
above -- this could lead users to use them, even though they are only
intended as last resort for recipients who don't have a Kolab enabled
client.

Having Horde integrated as web-client in the stable Kolab-Server
releases I consider this issue urgent. 

Tested with:
Kontact Version 1.2.9 (enterprise35 20081118.886071)

cheers
sascha

[0] The only exception I found during my tests is
    mutlipart/alternative with text/plain and text/html, where Kontact
    refuses to display the html part for security reasons (which is
    good!).  Once the user allows to display the html-part there is no
    way to get the original display (text/plain in mail context) back
    -- but this is just another minor issue...

----------
assignedto: till
files: horde-invitation.mbox
messages: 17796
nosy: bernhard, bh, ludwig, osterfeld, thomas, till, vkrause, wilde
priority: urgent
status: unread
title: Kontact displays MIME multipart/alternative as if it were multipart/mixed
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3270>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: horde-invitation.mbox
Type: application/octet-stream
Size: 2301 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081126/5aff066c/horde-invitation.exe

From kolab-issues at intevation.de  Wed Nov 26 19:13:50 2008
From: kolab-issues at intevation.de (Carlos N Love)
Date: Wed, 26 Nov 2008 18:13:50 +0000
Subject: [Kolab-devel] [issue3271] D e ntists Listing in the USA
Message-ID: <20081126181346.53C4D94A6A2@kolab.intevation.de>


New submission from Carlos N Love <Marylou at hazar.tel.net.ua>:

New for this Year: Listing of D e ntists  in America

++ 164,598 Den Tists 
++ 158,570 Postal Addresses
++ 163,157 Business Tel #
++ 77,534 Business Fax #
++ 45,308 E-Mail Addresses

Up to Nov 28 the price has been reduced to $294, you save $200!

To inquire please write to Cormier at statlists.com

to adjust your subscription status email to gone at statlists.com

----------
messages: 17799
nosy: Marylou, ddaley, heike.kruspe, info11, kent, meditek.pd, pantugruel, rwest, sally
status: unread
title: D e ntists Listing in the USA
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3271>
___________________________________________________


From kolab-issues at intevation.de  Thu Nov 27 10:17:15 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 27 Nov 2008 09:17:15 +0000
Subject: [Kolab-devel] [issue3272] Crash at KMail::HeaderItem::msgId while
	sending a mail
Message-ID: <1227777435.45.0.447832635609.issue3272@intevation.de>


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

enterprise35 20081118.886071

We encountered a crash while sending a mail. Kleopatra was open at the moment.
(See backtrace.) I couldn't reproduce the crash.

----------
assignedto: till
files: kontact-crash_log.txt
messages: 17803
nosy: bernhard, bh, ludwig, osterfeld, pradeepto, till
priority: urgent
status: unread
title: Crash at KMail::HeaderItem::msgId while sending a mail
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3272>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kontact-crash_log.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20081127/049edcf0/kontact-crash_log-0001.txt

From kolab-issues at intevation.de  Thu Nov 27 11:34:37 2008
From: kolab-issues at intevation.de (Marc Mutz)
Date: Thu, 27 Nov 2008 10:34:37 +0000
Subject: [Kolab-devel] [issue3273] kmail hangs connecting to itself
Message-ID: <1227782077.2.0.72121344785.issue3273@intevation.de>


New submission from Marc Mutz <marc at kdab.net>:

It's nearly 100% reproducible when starting kmail from the build dir. This is 
with the kolab resource provider set to kmail, not kontact.

To reproduce (composer):
1. start kmail
2. more of less immediately hit CTRL-N
3. start typing in the To field
-> hang

To reproduce (reader):
1. start kmail
2. more or less immediately go into a folder with mail
-> hang

Workaround I found:
1. start kmail on a folder that does not contain mail
2. change between a couple of folders without mail
3. do anything
-> no hang

Backtrace from addresseelineedit completion:

0x00002af1811271bf in __read_nocancel () from /lib/libpthread.so.0
(gdb) where
#0  0x00002af1811271bf in __read_nocancel () from /lib/libpthread.so.0
#1  0x00002af17ecb402f in _kde_IceTransSocketRead (
    ciptr=<value optimized out>, buf=0x52b510 "\002\003", size=8)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./dcop/KDE-ICE/Xtranssock.c:1710
#2  0x00002af17ecae17b in _kde_IceRead (iceConn=0x52b3d0,
    nbytes=<value optimized out>, ptr=0x52b510 "\002\003")
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./dcop/KDE-ICE/misc.c:249
#3  0x00002af17ecb24a0 in KDE_IceProcessMessages (iceConn=0x52b3d0,
    replyWait=0x7fff30129d10, replyReadyRet=0x7fff30129dbc)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./dcop/KDE-ICE/process.c:153
#4  0x00002af17eca021d in DCOPClient::callInternal (this=0x529490,
    remApp=<value optimized out>, remObjId=@0x7fff3012a010,
    remFun=@0x7fff3012a000, data=<value optimized out>,
    replyStruct=0x7fff30129e40, useEventLoop=false, timeout=-1, minor_opcode=2)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./dcop/dcopclient.cpp:1931
#5  0x00002af17eca0518 in DCOPClient::callInternal (this=0x529490,
    remApp=@0x26df350, remObjId=@0x7fff3012a010, remFun=@0x7fff3012a000,
    data=@0x7fff30129fe0, replyType=@0x7fff30129ff0,
    replyData=@0x7fff30129fd0, useEventLoop=false, timeout=-1, minor_opcode=2)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./dcop/dcopclient.cpp:1821
#6  0x00002af17eca4a58 in DCOPClient::call (this=0x529490, remApp=@0x26df350,
    remObjId=@0x7fff3012a010, remFun=@0x7fff3012a000, data=@0x7fff30129fe0,
    replyType=@0x7fff30129ff0, replyData=@0x7fff30129fd0, useEventLoop=false,
---Type <return> to continue, or q <return> to quit---
    timeout=-1) at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./dcop/dcopclient.cpp:1765
#7  0x00002af17eca4a83 in DCOPClient::call (this=0x5, remApp=@0x52b510,
    remObjId=@0x8, remFun=@0xffffffffffffffff, data=@0x80,
    replyType=@0x7fff30129e40, replyData=@0x7fff30129fd0, useEventLoop=false)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./dcop/dcopclient.cpp:1730
#8  0x00002af17eca62fb in DCOPClient::remoteObjects (this=0x529490,
    remApp=@0x26df350, ok=0x0)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./dcop/dcopclient.cpp:1251
#9  0x00002aaaac333519 in Kolab::KMailConnection::connectToKMail ()
   from /usr/lib/libkabckolab.so.0
#10 0x00002aaaac3340f6 in Kolab::KMailConnection::kmailSubresources ()
   from /usr/lib/libkabckolab.so.0
#11 0x00002aaaac33203d in Kolab::ResourceKolabBase::kmailSubresources ()
   from /usr/lib/libkabckolab.so.0
#12 0x00002aaaac322edd in KABC::ResourceKolab::doOpen ()
   from /usr/lib/libkabckolab.so.0
#13 0x00002af17dc11406 in KRES::Resource::open (this=0x2638510)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./kresources/resource.cpp:93
#14 0x00002af17d97ac1a in KABC::StdAddressBook::init (this=0x2621fd0,
    asynchronous=true)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./kabc/stdaddressbook.cpp:106
#15 0x00002af17d97af2d in StdAddressBook (this=0x2621fd0, asynchronous=true)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./kabc/stdaddressbook.cpp:90
---Type <return> to continue, or q <return> to quit---
#16 0x00002af17d97afa1 in KABC::StdAddressBook::self (asynchronous=true)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./kabc/stdaddressbook.cpp:72
#17 0x00002af17b6e8f9f in KPIM::AddresseeLineEdit::loadContacts (
    this=0x250c4e0) at ../../kdepim/libkdepim/addresseelineedit.cpp:515
#18 0x00002af17afe2fa9 in KMLineEdit::loadContacts (this=0x5)
    at ../../kdepim/kmail/kmlineeditspell.cpp:160
#19 0x00002af17b6e94c4 in KPIM::AddresseeLineEdit::doCompletion (
    this=0x250c4e0, ctrlT=false)
    at ../../kdepim/libkdepim/addresseelineedit.cpp:385
#20 0x00002af17b6eb02a in KPIM::AddresseeLineEdit::qt_invoke (this=0x250c4e0,
    _id=89, _o=0x7fff3012ac00) at ./addresseelineedit.moc:126
#21 0x00002af17afe32ad in KMLineEdit::qt_invoke (this=0x250c4e0, _id=89,
    _o=0x7fff3012ac00) at ./kmlineeditspell.moc:102
#22 0x00002af17b02f399 in RecipientLineEdit::qt_invoke (this=0x5, _id=5420304,
    _o=0x8) at ./recipientseditor.moc:191
#23 0x00002af17f75bc26 in QObject::activate_signal (this=0x250c4e0,
    clist=0x24d3730, o=0x7fff3012ac00) at kernel/qobject.cpp:2356
#24 0x00002af17f75c1bd in QObject::activate_signal (this=0x250c4e0, signal=8,
    param=@0x7fff3012ac50) at kernel/qobject.cpp:2451
#25 0x00002af17e43fd68 in KLineEdit::completion (this=0x250c4e0,
    t0=<value optimized out>) at ./klineedit.moc:207
#26 0x00002af17e4409c9 in KLineEdit::keyPressEvent (this=0x250c4e0,
    e=0x7fff3012b8c0)
---Type <return> to continue, or q <return> to quit---
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./kdeui/klineedit.cpp:700
#27 0x00002af17b6ea89b in KPIM::AddresseeLineEdit::keyPressEvent (
    this=0x250c4e0, e=0x7fff3012b8c0)
    at ../../kdepim/libkdepim/addresseelineedit.cpp:210
#28 0x00002af17b03172f in RecipientLineEdit::keyPressEvent (this=0x250c4e0,
    ev=0x7fff3012b8c0) at ../../kdepim/kmail/recipientseditor.cpp:144
#29 0x00002af17f790446 in QWidget::event (this=0x250c4e0, e=0x7fff3012b8c0)
    at kernel/qwidget.cpp:4748
#30 0x00002af17f835f03 in QLineEdit::event (this=0x250c4e0, e=0x7fff3012b8c0)
    at widgets/qlineedit.cpp:1424
#31 0x00002af17f6f7262 in QApplication::internalNotify (this=0x7fff3012bff0,
    receiver=0x250c4e0, e=0x7fff3012b8c0) at kernel/qapplication.cpp:2635
#32 0x00002af17f6f91fb in QApplication::notify (this=0x7fff3012bff0,
    receiver=0x250c4e0, e=0x7fff3012b8c0) at kernel/qapplication.cpp:2392
#33 0x00002af17eac38be in KApplication::notify (this=0x7fff3012bff0,
    receiver=0x250c4e0, event=0x7fff3012b8c0)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./kdecore/kapplication.cpp:550
#34 0x00002af17f68a874 in QApplication::sendSpontaneousEvent (
    receiver=0x250c4e0, event=0x7fff3012b8c0) at kernel/qapplication.h:523
#35 0x00002af17f67c16d in QETWidget::translateKeyEvent (this=0x250c4e0,
    event=0x7fff3012bcc0, grab=false) at kernel/qapplication_x11.cpp:5636
#36 0x00002af17f687971 in QApplication::x11ProcessEvent (this=0x7fff3012bff0,
    event=0x7fff3012bcc0) at kernel/qapplication_x11.cpp:3493
---Type <return> to continue, or q <return> to quit---
#37 0x00002af17f69d8ba in QEventLoop::processEvents (this=0x55f6e0, flags=4)
    at kernel/qeventloop_x11.cpp:192
#38 0x00002af17f7107ee in QEventLoop::enterLoop (this=0x55f6e0)
    at kernel/qeventloop.cpp:198
#39 0x00002af17f7105f7 in QEventLoop::exec (this=0x55f6e0)
    at kernel/qeventloop.cpp:145
#40 0x00002af17f6f8d40 in QApplication::exec (this=0x7fff3012bff0)
    at kernel/qapplication.cpp:2758
#41 0x0000000000403432 in main (argc=<value optimized out>,
    argv=<value optimized out>) at ../../kdepim/kmail/main.cpp:110


Backtrace from the reader:

0x00002b3111b2c1bf in __read_nocancel () from /lib/libpthread.so.0
(gdb) where
#0  0x00002b3111b2c1bf in __read_nocancel () from /lib/libpthread.so.0
#1  0x00002b310f6b902f in _kde_IceTransSocketRead (
    ciptr=<value optimized out>, buf=0x52b520 "\002\003", size=8)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./dcop/KDE-ICE/Xtranssock.c:1710
#2  0x00002b310f6b317b in _kde_IceRead (iceConn=0x52b3e0,
    nbytes=<value optimized out>, ptr=0x52b520 "\002\003")
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./dcop/KDE-ICE/misc.c:249
#3  0x00002b310f6b74a0 in KDE_IceProcessMessages (iceConn=0x52b3e0,
    replyWait=0x7fff9f71d0b0, replyReadyRet=0x7fff9f71d15c)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./dcop/KDE-ICE/process.c:153
#4  0x00002b310f6a521d in DCOPClient::callInternal (this=0x5295d0,
    remApp=<value optimized out>, remObjId=@0x7fff9f71d3b0,
    remFun=@0x7fff9f71d3a0, data=<value optimized out>,
    replyStruct=0x7fff9f71d1e0, useEventLoop=false, timeout=-1, minor_opcode=2)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./dcop/dcopclient.cpp:1931
#5  0x00002b310f6a5518 in DCOPClient::callInternal (this=0x5295d0,
    remApp=@0x2845f50, remObjId=@0x7fff9f71d3b0, remFun=@0x7fff9f71d3a0,
    data=@0x7fff9f71d380, replyType=@0x7fff9f71d390,
    replyData=@0x7fff9f71d370, useEventLoop=false, timeout=-1, minor_opcode=2)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./dcop/dcopclient.cpp:1821
#6  0x00002b310f6a9a58 in DCOPClient::call (this=0x5295d0, remApp=@0x2845f50,
    remObjId=@0x7fff9f71d3b0, remFun=@0x7fff9f71d3a0, data=@0x7fff9f71d380,
    replyType=@0x7fff9f71d390, replyData=@0x7fff9f71d370, useEventLoop=false,
---Type <return> to continue, or q <return> to quit---
    timeout=-1) at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./dcop/dcopclient.cpp:1765
#7  0x00002b310f6a9a83 in DCOPClient::call (this=0x5, remApp=@0x52b520,
    remObjId=@0x8, remFun=@0xffffffffffffffff, data=@0x80,
    replyType=@0x20000000, replyData=@0x7fff9f71d370, useEventLoop=false)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./dcop/dcopclient.cpp:1730
#8  0x00002b310f6ab2fb in DCOPClient::remoteObjects (this=0x5295d0,
    remApp=@0x2845f50, ok=0x0)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./dcop/dcopclient.cpp:1251
#9  0x00002aaaac0e8519 in Kolab::KMailConnection::connectToKMail ()
   from /usr/lib/libkabckolab.so.0
#10 0x00002aaaac0e90f6 in Kolab::KMailConnection::kmailSubresources ()
   from /usr/lib/libkabckolab.so.0
#11 0x00002aaaac0e703d in Kolab::ResourceKolabBase::kmailSubresources ()
   from /usr/lib/libkabckolab.so.0
#12 0x00002aaaac0d7edd in KABC::ResourceKolab::doOpen ()
   from /usr/lib/libkabckolab.so.0
#13 0x00002b310e616406 in KRES::Resource::open (this=0x280f760)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./kresources/resource.cpp:93
#14 0x00002b310e37fc1a in KABC::StdAddressBook::init (this=0x28286e0,
    asynchronous=true)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./kabc/stdaddressbook.cpp:106
#15 0x00002b310e37ff2d in StdAddressBook (this=0x28286e0, asynchronous=true)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./kabc/stdaddressbook.cpp:90
---Type <return> to continue, or q <return> to quit---
#16 0x00002b310e37ffa1 in KABC::StdAddressBook::self (asynchronous=true)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./kabc/stdaddressbook.cpp:72
#17 0x00002b310b9712e8 in KMail::FancyHeaderStyle::format (
    this=<value optimized out>, message=0x27fe8e0, strategy=0x5264a0,
    vCardName=@0x7fff9f7283c0, printing=<value optimized out>, topLevel=true)
    at ../../kdepim/kmail/headerstyle.cpp:477
#18 0x00002b310b893249 in KMReaderWin::writeMsgHeader (this=0x2029c60,
    aMsg=0x27fe8e0, hasVCard=<value optimized out>, topLevel=true)
    at ../../kdepim/kmail/kmreaderwin.cpp:1703
#19 0x00002b310b89b4e7 in KMReaderWin::parseMsg (this=0x2029c60,
    aMsg=0x27fe8e0) at ../../kdepim/kmail/kmreaderwin.cpp:1584
#20 0x00002b310b8958e9 in KMReaderWin::displayMessage (this=0x2029c60)
    at ../../kdepim/kmail/kmreaderwin.cpp:1514
#21 0x00002b310b895a28 in KMReaderWin::updateReaderWin (this=0x2029c60)
    at ../../kdepim/kmail/kmreaderwin.cpp:1449
#22 0x00002b310b897eb1 in KMReaderWin::qt_invoke (this=0x2029c60, _id=48,
    _o=0x7fff9f728d20) at ./kmreaderwin.moc:301
#23 0x00002b3110160c26 in QObject::activate_signal (this=0x2029d98,
    clist=0x2092910, o=0x7fff9f728d20) at kernel/qobject.cpp:2356
#24 0x00002b31101617b6 in QObject::activate_signal (this=0x2029d98, signal=2)
    at kernel/qobject.cpp:2325
#25 0x00002b31104cf9e2 in QTimer::timeout (this=0x2029d98)
    at .moc/debug-shared-mt/moc_qtimer.cpp:82
---Type <return> to continue, or q <return> to quit---
#26 0x00002b3110186fef in QTimer::event (this=0x2029d98, e=0x7fff9f7291f0)
    at kernel/qtimer.cpp:219
#27 0x00002b31100fc262 in QApplication::internalNotify (this=0x7fff9f7295b0,
    receiver=0x2029d98, e=0x7fff9f7291f0) at kernel/qapplication.cpp:2635
#28 0x00002b31100fe00c in QApplication::notify (this=0x7fff9f7295b0,
    receiver=0x2029d98, e=0x7fff9f7291f0) at kernel/qapplication.cpp:2358
#29 0x00002b310f4c88be in KApplication::notify (this=0x7fff9f7295b0,
    receiver=0x2029d98, event=0x7fff9f7291f0)
    at /tmp/buildd/kdelibs-3.5.5a.dfsg.1/./kdecore/kapplication.cpp:550
#30 0x00002b311008f802 in QApplication::sendEvent (receiver=0x2029d98,
    event=0x7fff9f7291f0) at ../include/qapplication.h:520
#31 0x00002b31100ef57c in QEventLoop::activateTimers (this=0x55f700)
    at kernel/qeventloop_unix.cpp:556
#32 0x00002b31100a3584 in QEventLoop::processEvents (this=0x55f700, flags=4)
    at kernel/qeventloop_x11.cpp:389
#33 0x00002b31101157ee in QEventLoop::enterLoop (this=0x55f700)
    at kernel/qeventloop.cpp:198
#34 0x00002b31101155f7 in QEventLoop::exec (this=0x55f700)
    at kernel/qeventloop.cpp:145
#35 0x00002b31100fdd40 in QApplication::exec (this=0x7fff9f7295b0)
    at kernel/qapplication.cpp:2758
#36 0x0000000000403432 in main (argc=<value optimized out>,
    argv=<value optimized out>) at ../../kdepim/kmail/main.cpp:110

----------
assignedto: vkrause
messages: 17806
nosy: bernhard, marc, till, vkrause
priority: bug
status: unread
title: kmail hangs connecting to itself
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3273>
___________________________________________________


From kolab-issues at intevation.de  Thu Nov 27 15:25:02 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 27 Nov 2008 14:25:02 +0000
Subject: [Kolab-devel] [issue3274] Changing a contact which is part of a
	local distribution list creates problems.
Message-ID: <1227795902.18.0.718892951052.issue3274@intevation.de>


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

enterprise35 kdepim 20081121.887372-kk2

Changing the mail address of contact which is part of a local distribution list
and sending a mail to the distribution list, sends it to the old not changed
mail address of the changed contact.

Changing the name of a contact which is part of a local distribution list and
sending a mail to the distribution list, doesn't send a mail to the changed
contact. The changed contact isn't in the distribution list anymore.

How should a local distribution list react on the change of its contacts?
I would suppose that the dist list changes if some of its contacts change, so
that is uses the new contacts. Is this possible?

----------
assignedto: till
messages: 17830
nosy: bernhard, bh, ludwig, osterfeld, pradeepto, till
priority: urgent
status: unread
title: Changing a contact which is part of a local distribution list creates problems.
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3274>
___________________________________________________


From kolab-issues at intevation.de  Thu Nov 27 17:54:47 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Thu, 27 Nov 2008 16:54:47 +0000
Subject: [Kolab-devel] [issue3275] translation of "calendar" to "Kalendar"
	is wrong, should be "Kalender"
Message-ID: <1227804886.96.0.498334347261.issue3275@intevation.de>


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

Customer notes that it should be "Kalender", not "Kalendar".

grep -ir kalenar in the current German translation for e35 
turns up quite a lot of hits. (Otherwise I would just have corrected it.)

Should also be fixed for e4.

----------
assignedto: till
messages: 17835
nosy: bernhard, ludwig, till
priority: bug
status: unread
title: translation of "calendar" to "Kalendar" is wrong, should be "Kalender"
topic: kde client, kowi, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3275>
___________________________________________________


From oszwald at web.de  Thu Nov 27 22:24:07 2008
From: oszwald at web.de (Florian Oszwald)
Date: Thu, 27 Nov 2008 22:24:07 +0100
Subject: [Kolab-devel] horde and kolab on opensuse 10.2
Message-ID: <200811272224.08174.oszwald@web.de>

Dear list,
I am running kolab together with horde on an opensuse 10.2 system
I have the following situation:

In horde:
- no calendars can be accessed in the user configuration dialog for standard 
calendar
- no tasks in the user configuration dialog for standard tasks
- no adressbook in the user configuration dialog for standard adressbook
- no memos in the user configuration dialog for standard memos

With email, there seems no problem so far.

When making a new entry in the calender I get the following error direct in 
the browser:
Beim Zugriff auf den Kalender ist ein Fehler aufgetreten: Share 
"user at example.com" existiert nicht.

Furthermore I have every time I log into horde: DB Error: not found

/var/log/horde/horde.conf says:
error] [kronolith] Besitzer des Ordners INBOX konnte nicht festgestellt 
werden. [pid 4933 on line 1330 of 
"/srv/www/htdocs/horde2/kronolith/lib/Kronolith.php"]

Can anybody help me herewith?

Regards,
Florian


From bernhard at intevation.de  Fri Nov 28 10:24:00 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 28 Nov 2008 10:24:00 +0100
Subject: [Kolab-devel] horde and kolab on opensuse 10.2
In-Reply-To: <200811272224.08174.oszwald@web.de>
References: <200811272224.08174.oszwald@web.de>
Message-ID: <200811281024.00991.bernhard@intevation.de>

Hi Florian,

On Donnerstag, 27. November 2008, Florian Oszwald wrote:
> I am running kolab together with horde on an opensuse 10.2 system
> I have the following situation:
>
> In horde:
> - no calendars can be accessed in the user configuration dialog for
> standard calendar

note that Gunnar the current maintainer of our Kolab Webclient
is currently on vacation until the 4th of December. 

Also note that Kolab Server/OpenPKG is usually known to be
a more stable choice. (This is said out of completeness, as you are writing to 
our devel list, I'm assuming that you want to help develop Kolab 
Server/Opensuse, which is great!)

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: 206 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081128/86b7d459/attachment.bin

From kolab-issues at intevation.de  Fri Nov 28 16:36:18 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Fri, 28 Nov 2008 15:36:18 +0000
Subject: [Kolab-devel] [issue3276] cannot encrypt to marginally trusted
	OpenPGP key
Message-ID: <1227886578.31.0.924748396607.issue3276@intevation.de>


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

I have a marginally trusted key here that I cannot encrypt to.
Further conditions are:
* The key does not contain the email address I am sending to
  (can be simulated by adding a "+xyz" with several email servers.)
* My addressbook has the sending email address and the OpenPGP key
  in the crypto settings

a)Create an email to the recipient.
  Try "sending later" is enough to reproduce the problem.
b) Observation:
   As the email is not in the key, I get asked for the key.
   The key is shown in green, 
Expectation: The key should not be green as it is only
marginally trusted. In Proko2 those keys were yellow.
(Might be related to kolab/issue3143 (s/mime invalid keys are accepted by KMail 
and shown green in kleo (certmanager/lib/ui/keyselectiondialog.cpp))

c) I select the key and then get the error message
that something is conflicting with the encryption settings
for this senders.
(Might be related to 
   kolab/issue3066 (Unnecessary encryption key check when sending signed.))
I get asked if I wanted to encrypt again.
(Obviosly I do not want to get this question, as the key was green.)

d) I say "encrypt", get the key dialog and select the key again.
and then I get asked for the key again.
Observation: Right after the okay, I get another key dialog, this time
with the longer text saying that not valid and trusted key for this
recipient could be found (and that I could use external search).

BTW, When selecting the external search, Kleo is started and I 
get an error message that the backend gave no results.
(Which is wrong, an empty search result is not an error. I feel
we already have an issue for this.)

e) After the third key selection, the email is not send. Nothing more
happens. :(
Expectation: If the operation could not be done, give me an error
message or something.

kontact Version: 4:3.5.10.enterprise.0.20081118.886071-kk1
gnupg2 Version: 2.0.9.svn4835-0kk3

----------
assignedto: till
messages: 17841
nosy: bernhard, ludwig, marc, till
priority: urgent
status: unread
title: cannot encrypt to marginally trusted OpenPGP key
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3276>
___________________________________________________


From wrobel at pardus.de  Sat Nov 29 22:42:04 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Sat, 29 Nov 2008 22:42:04 +0100
Subject: [Kolab-devel] horde and kolab on opensuse 10.2
In-Reply-To: <200811272224.08174.oszwald@web.de>
References: <200811272224.08174.oszwald@web.de>
Message-ID: <20081129224204.17051kivtc1xwugg@webmail.pardus.de>

Quoting Florian Oszwald <oszwald at web.de>:

> Dear list,
> I am running kolab together with horde on an opensuse 10.2 system
> I have the following situation:
>
> In horde:
> - no calendars can be accessed in the user configuration dialog for standard
> calendar
> - no tasks in the user configuration dialog for standard tasks
> - no adressbook in the user configuration dialog for standard adressbook
> - no memos in the user configuration dialog for standard memos
>
> With email, there seems no problem so far.
>
> When making a new entry in the calender I get the following error direct in
> the browser:
> Beim Zugriff auf den Kalender ist ein Fehler aufgetreten: Share
> "user at example.com" existiert nicht.
>
> Furthermore I have every time I log into horde: DB Error: not found
>
> /var/log/horde/horde.conf says:
> error] [kronolith] Besitzer des Ordners INBOX konnte nicht festgestellt
> werden. [pid 4933 on line 1330 of
> "/srv/www/htdocs/horde2/kronolith/lib/Kronolith.php"]
>
> Can anybody help me herewith?

Sounds like the package maintainers provide a broken Horde  
configuration. It is hard to tell you exactly what is wrong as the  
Horde configuration is quite complex (which is the reason why a decent  
default should be provided by the package maintainers).

I'd suggest to install a Kolab Server based on OpenPKG and compare the  
Horde configuration in that system to your Suse configuration. That  
might help.

Cheers,

Gunnar

>
> Regards,
> Florian
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081129/27c6199c/attachment.bin

From wrobel at pardus.de  Sat Nov 29 23:00:46 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Sat, 29 Nov 2008 23:00:46 +0100
Subject: [Kolab-devel] pear rpmbuild advice
In-Reply-To: <200811261035.03816.ml@radoeka.nl>
References: <200811212347.39544.richard@radoeka.nl>
	<20081123214751.108877ntg9ampkg8@webmail.pardus.de>
	<200811261035.03816.ml@radoeka.nl>
Message-ID: <20081129230046.140516oycmtladfk@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Hi,
>
> Why is phpunit required as dependency for Kolab_Server?
>  http://pear.horde.org/index.php?package=Kolab_Server&release=0.2.0&downloads

This is an optional dependency. It is not marked as "optional" on  
pear.horde.org because the PEAR software running the package provider  
on pear.php.net and pear.horde.org still has some limitations.

>
> Is this a runtime dependency or a buildtime dependency.  In case it is a
> runtime dependency, why is a testing framework needed as runtime dependency
> for the kolab-server module (just curious, wanting to learn something).

Neither runtime nor buildtime but "testtime" :)

It is absolutely not required in your system. I did nevertheless  
include it also in the Kolab/OpenPKG server version because I like  
having the phpUnit tests also on a productive system.

Often people tend to start patching the installed code. Then it may be  
useful to be able to run/extend unit tests on your system. It is not  
necessarily the best way of coding stuff but I want to enable people  
to contribute as much as possible.

Cheers,

Gunnar

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



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081129/658ac997/attachment.bin

From wrobel at pardus.de  Sat Nov 29 23:25:21 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Sat, 29 Nov 2008 23:25:21 +0100
Subject: [Kolab-devel] why does the pkg Auth require Kolab_Server?
In-Reply-To: <200811260826.38514.ml@radoeka.nl>
References: <200811242135.39609.richard@radoeka.nl>
	<200811242139.21996.richard@radoeka.nl>
	<200811260826.38514.ml@radoeka.nl>
Message-ID: <20081129232521.18536kbeoxsqcuww@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Hi,
>
> Op Monday 24 November 2008 21:39:21 schreef Richard Bos:
>> Op Monday 24 November 2008 21:35:39 schreef Richard Bos:
>> > why does Kolab_Server require Auth and Auth Kolab_Server?  The latter
>> > does not seem correct to me.
>>
>> a bit related to this, why is there a package called Auth and  
>> Horde_Auth.  Should Auth not just be called Horde_Auth?
>
> I checked the packages that are shown, when one uses these pages:
> http://pear.horde.org/index.php?category=framework
> http://pear.horde.org/index.php?category=framework&page=[1-5]
> and captured all the listed packages, and looked for Group, Auth and Util.
> Non of those (last 3) are listed there as a pear.horde package....?

Might be a problem of the PEAR server implementation that is running  
pear.horde.org.

In any case the newer package names will *not* have the "Horde_" prefix.

> So,
> should the package Util indeed be read as Horde_Util and likewise the other 2
> as Horde_Auth and Horde_Group?

No, the Horde_* packages are going to be deprecated. Some have already  
been replaced with the shortened counterpart but not all of them.

>
> Sorry I have more questions, related to this.  I'm building horde package 16
> now and it looks I'm half way the dependency list.... How come that the
> package kolab_freebusy and filter that were moved from kolab cvs to horde.org
> result in so many horde packages?  It is almost insane.  Although you stated
> that this is better maintainable, it does not look that way.

To me this touches the basics of any package management. Why do we  
have packages or a package management system at all? Why is there not  
only one big blob named "OpenSuse 10.2"? This is the same question.

Once I accept package management makes sense then it is obvious to me  
that I split packages of different functionality.

All those package you now see have traditionally been contained within  
horde-framework. This has always been a horrible approach which is  
also known within Horde and will be changed with Horde 4. PHP in  
general is one of the languages with the worst package management  
strategies I have ever seen.

If your approach is to reduce packages as much as possible then all  
you want to do is to build appliances. But if you think in terms of a  
distribution you need to split into logical modules.

> Anyway, how
> come that so many horde packages are needed to replace kolab_freebusy and
> filter from kolab cvs (just curious nothing more), are those packages also
> used for the applications, like ingo, turba, imp, etc?

They were always there but they were always incorrectly packaged.

>
> Last question for this email: the package Auth (or is it Horde_Auth?) has
> among its dependencies 2 PHP extensions; pam_auth and sasl:
> http://pear.horde.org/index.php?package=Auth&downloads  As those extensions
> were not needed for the kolab_flter and freebusy packages from kolab cvs, I
> wonder if they are needed for Kolab_Filter and Kolab_Freebusy from
> pear.horde.  I ask because the extensions do not seem to be available via
> openSUSE rpms...  If they are not needed, I rather don't spend my time on
> getting those php extensions build.

They are probably optional extensions. Check the package.xml in the package.

Cheers,

Gunnar

>
>
> --
> Richard Bos
> We are borrowing the world of our children,
> It is not inherited from our parents.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081129/33c74793/attachment.bin

From kolab-issues at intevation.de  Sun Nov 30 19:15:49 2008
From: kolab-issues at intevation.de (Frank Osterfeld)
Date: Sun, 30 Nov 2008 18:15:49 +0000
Subject: [Kolab-devel] [issue3277] OS X packages contain hardcoded phonon
	library path specific to Till's build enviroment
Message-ID: <1228068949.1.0.522012262812.issue3277@intevation.de>


New submission from Frank Osterfeld <frank at kdab.net>:

OS X installer from http://www.kdab.net/~till/KDEOnMac/20081119, also observed
with previous versions.

The file 

/opt/kde4/share/apps/cmake/modules/KDELibsDependenciesInternal.cmake

contains a wrong path to libphonon:

/Users/till/Code/mac.kde.org/kdemac-read-only/compile.build/kdelibs/lib/libphonon.dylib

This leads to errors when building e.g. a custom kdepim against the installed
kdelibs.

Only libphonon is affected, all other paths are fine. Replacing all occurrences of

/Users/till/Code/mac.kde.org/kdemac-read-only/compile.build/kdelibs/lib/libphonon.dylib

by 

/opt/kde4/lib/libphonon.dylib

in KDELibsDependenciesInternal.cmake fixes the problem.

----------
assignedto: till
messages: 17844
nosy: osterfeld, till
priority: bug
status: unread
title: OS X packages contain hardcoded phonon library path specific to Till's build enviroment
topic: enterprise4
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3277>
___________________________________________________


From ronald at kovoks.nl  Wed Nov 26 10:38:50 2008
From: ronald at kovoks.nl (Ronald van Eendenburg)
Date: Wed, 26 Nov 2008 09:38:50 -0000
Subject: [Kolab-devel] bug in seperator and freebusy ?
Message-ID: <492D1927.6080300@kovoks.nl>

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