From kolab-issues at intevation.de  Wed Oct  1 11:58:30 2008
From: kolab-issues at intevation.de (T. Ribbrock)
Date: Wed, 01 Oct 2008 09:58:30 +0000
Subject: [Kolab-devel] [issue3098] Mail body no longer shown -> Crash
Message-ID: <1222855110.33.0.815453333278.issue3098@intevation.de>


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

I have two of our users reporting the problem below. I cannot reproduce it on my
own account(s), but for them it seems to happen frequently. As this causes mail
to be not accessible as well as crashes, I set this to critical.

The following is the original description as given by one of our users:

A regular problem that occurs several times a week (sometimes several times a day):

- email (old or new) in inbox clicked to open/see
- preview pane does not show content (empty) (also opening the email in a
different window does not help - content stays invisible)

Workaround:
- trying to move/copy the respective email to another folder
- then Kontact _always_ crashes
- after restarting Kontact, the email is usually visible.

The second user has reported that Kontact also crashes if the mail in question
is deleted. He has provided a backtrace - see attachment.

So far, we have not been able to detect a pattern (i.e. certain types of mail
that always produce this problems). In at least one case, this problem has lead
to the mail in question getting lost completely, i.e. the body was emptied *on
the server*.

Versions:

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

This has already been reported on earlier versions, namely 827950, 830933 and
837785, all on the same Kubuntu systems.

----------
files: Crash_on_delete_stuck_mail_issue4949-858460.txt
messages: 16882
nosy: itsef_admin
priority: critical
status: unread
title: Mail body no longer shown -> Crash
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3098>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Crash_on_delete_stuck_mail_issue4949-858460.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20081001/d78318b6/Crash_on_delete_stuck_mail_issue4949-858460.txt

From kolab-issues at intevation.de  Wed Oct  1 18:47:52 2008
From: kolab-issues at intevation.de (T. Ribbrock)
Date: Wed, 01 Oct 2008 16:47:52 +0000
Subject: [Kolab-devel] [issue3099] Replying to stored mail crashes Kontact
Message-ID: <1222879672.52.0.112290707785.issue3099@intevation.de>


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

In an online IMAP account, select a message, then store it to an MBOX file using
"File -> Save". Once the mail has been saved, reply to the mail that has just
been stored (e.g. by hitting "r") => Crash.

This has been reported by one of our users and I have been able to reproduce it
without problems. Backtrace included.

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

The user in question was using version 858460.

----------
files: Crash_on_replying_stored_mail-862683.txt
messages: 16906
nosy: itsef_admin
priority: urgent
status: unread
title: Replying to stored mail crashes Kontact
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3099>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Crash_on_replying_stored_mail-862683.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20081001/a8bbcadc/Crash_on_replying_stored_mail-862683.txt

From ml at radoeka.nl  Wed Oct  1 22:30:58 2008
From: ml at radoeka.nl (Richard Bos)
Date: Wed, 1 Oct 2008 22:30:58 +0200
Subject: [Kolab-devel] CeBIT Open Source: Linux Magazine and Linux
	Foundation Announce Call for Projects - Linux Magazine Online
Message-ID: <200810012230.58439.ml@radoeka.nl>

Is this something for the kolab project (including some of
the surrounding projects):
http://www.linux-magazine.com/online/news/cebit_open_source_linux_magazine_and_linux_foundation_announce_call_for_projects

-- 
Richard Bos
Without a home the journey is endless


From kolab-issues at intevation.de  Thu Oct  2 11:23:07 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 09:23:07 +0000
Subject: [Kolab-devel] [issue3100] update resources from Kolab
Message-ID: <1222939387.03.0.367821241193.issue3100@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

The kolabwizard has been started and configured before.

The calendar view don't show at the first start of Kontact the Ressources. 
First we have to check E-Mail and after this restart Kontact to see and use the
Ressource like calendar in the Calendar view.

This Bug occurs under Windows version 20080916 and Linux Version 20080911.

----------
messages: 16920
nosy: basyskom, till
priority: bug
status: unread
title: update resources from Kolab
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3100>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 11:27:29 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 09:27:29 +0000
Subject: [Kolab-devel] [issue3101] use of broken keys
Message-ID: <1222939649.81.0.759377340749.issue3101@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

The Kontact account has keys that are out of date. I want to sent a email that
is not signed and not encrypted.

It is not possible to sent the email, because Kontact will use the keys anyway. 

If the keys are deleted in Kontact under Identity I can send the email.

----------
messages: 16921
nosy: basyskom, till
priority: bug
status: unread
title: use of broken keys
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3101>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 11:31:38 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 09:31:38 +0000
Subject: [Kolab-devel] [issue3102] wait time till accepted meetings are sent
Message-ID: <1222939898.39.0.895185485109.issue3102@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

If I accept/reject an invitation it needs one or two minutes till the state
change has been sent over the outbox.

seen under windows version 20080916 and linux version 20080911

----------
messages: 16923
nosy: basyskom
priority: bug
status: unread
title: wait time till accepted meetings are sent
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3102>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 11:36:50 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 09:36:50 +0000
Subject: [Kolab-devel] [issue3103] wrong time mark shown at meeting time
Message-ID: <1222940210.56.0.404796348967.issue3103@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

If I create a new Meeting over the menu in calendar view and set the time e.g.
to 14:00 o'clock till 16:00 o'clock and switch to tab Attendees the time mark in
the graphic is wrong. 

Its a small line and not a rectangle from 14:00 to 16:00.

This error is at the windows version 20080916.

----------
messages: 16924
nosy: basyskom
status: unread
title: wrong time mark shown at meeting time
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3103>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 11:39:35 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 09:39:35 +0000
Subject: [Kolab-devel] [issue3104] type error in kmail settings
Message-ID: <1222940375.11.0.700276946879.issue3104@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

If the window "Identity" under KMail settings is open in german the caption of
the window is wrong. It should be "Identit?t" and not "Identit" . . .

Found at linux version 20080911.

----------
messages: 16925
nosy: basyskom
priority: minor bug
status: unread
title: type error in kmail settings
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3104>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 11:50:36 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 09:50:36 +0000
Subject: [Kolab-devel] [issue3105] the windows version is not complete in
	german language
Message-ID: <1222941036.6.0.801816551428.issue3105@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

some of the dialogs and tabs e.g. "Attendees" at "New Event" in Calendar are not
in german language. 
The reminder dialog is fully english if I set a remind time on a meeting.

At the linux version 20080911 are more entries in german language.

----------
messages: 16926
nosy: basyskom, till
priority: bug
status: unread
title: the windows version is not complete in german language
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3105>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 11:53:27 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 02 Oct 2008 09:53:27 +0000
Subject: [Kolab-devel] [issue3106] If kontact is started via knotes and a
	new note is created with the systemtray, the note mail is trippled.
Message-ID: <1222941207.58.0.787247424347.issue3106@intevation.de>


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

enterprise35 20081001.865016

Test:
In a KDE environment.
1. Start kontact with knotes.
2. Create a new note with the knotes icon (RMB)
3. Edit the new note.

Notice: There are 3 new mails in the notes folder.

----------
assignedto: till
messages: 16927
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: bug
status: unread
title: If kontact is started via knotes and a new note is created with the systemtray, the note mail is trippled.
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3106>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 12:01:35 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 10:01:35 +0000
Subject: [Kolab-devel] [issue3107] crash of kontact under windows
Message-ID: <1222941695.33.0.889803166413.issue3107@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

The kontact program don't run stable. Often it crashes without a traceable reason.

Happens at windows version 20080916

----------
messages: 16930
nosy: basyskom
priority: bug
status: unread
title: crash of kontact under windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3107>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 12:25:51 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 10:25:51 +0000
Subject: [Kolab-devel] [issue3108] forward invitation outside of window
	failed
Message-ID: <1222943151.3.0.136848406236.issue3108@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

A forwarded invitation to another user without using the "Forward to" window is
handled normal at the forwared user. 

If the forwarded user accepts the invitation the answer is send to the sender
that generates the invitation.

If the sender itself opens the answer of the forwarded user, Kontact crashes.

Kontact should realize the diffrence of the mail sender and the invited person.

Found error at version 20080916 under windows.

----------
messages: 16931
nosy: basyskom
priority: bug
status: unread
title: forward invitation outside of window failed
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3108>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 12:30:17 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 10:30:17 +0000
Subject: [Kolab-devel] [issue3109] wrong meeting entry of forwareded
	invitation
Message-ID: <1222943417.76.0.576287828765.issue3109@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

Tester A invites Tester B to a meeting. Tester B forwared the meeting to Tester C.
Tester C accepts the meeting.
Tester A check the accepted persons. 
Why is there still Tester B at the meeting?

Found at Linux version 20080911 and windows version 20080916

----------
messages: 16932
nosy: basyskom
status: unread
title: wrong meeting entry of forwareded invitation
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3109>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 12:34:58 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 10:34:58 +0000
Subject: [Kolab-devel] [issue3110] declined meeting still in calendar
Message-ID: <1222943698.53.0.443957518684.issue3110@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

An invitation to a meeting is declined. 
The answer mail is send. 
The meeting is still in the calendar.

Found at linux version 20080911 and windows version 20080916

----------
messages: 16933
nosy: basyskom, till
status: unread
title: declined meeting still in calendar
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3110>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 13:30:39 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 11:30:39 +0000
Subject: [Kolab-devel] [issue3111] problems with keys
Message-ID: <1222947039.0.0.134410063511.issue3111@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

linux version from 20080911

changed old keys with new keys under "KMail settings"-> "Identity" -> Kryptography".

After Sign, the email occured a warning that no keys are inserted.
After restart of kontact are the set keys away.

I set the new keys again. Now it is possible to sign and encrypt the emails.
Have to wait 2 minutes. 
After this step error, "Signierung Fehlgeschlagen:General Error...Kein
Pr?fprotokoll vorhanden"
in english:
Signing failed, General error, no protocol created.

----------
messages: 16934
nosy: basyskom, till
status: unread
title: problems with keys
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3111>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 13:33:40 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 11:33:40 +0000
Subject: [Kolab-devel] [issue3112] crash after moving meeting
Message-ID: <1222947220.46.0.737309737953.issue3112@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

version: windows 20080916

Creation of a meeting in calendar. Reopen meeting and changing the time of the
meeting. 
Kontact crashed.

----------
messages: 16936
nosy: basyskom
priority: bug
status: unread
title: crash after moving meeting
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3112>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 13:37:24 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 11:37:24 +0000
Subject: [Kolab-devel] [issue3113] copy error of inbox to diffrent folder
Message-ID: <1222947444.48.0.254627002285.issue3113@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

version windows 20080916

In the german version the INBOX is called "Posteingang". If I copy this Folder
to a new generated folder the content is copied.

But the name of the subfolder is not as expected "Posteingang", its "inbox".

----------
messages: 16937
nosy: basyskom, till
priority: bug
status: unread
title: copy error of inbox to diffrent folder
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3113>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 13:41:40 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 11:41:40 +0000
Subject: [Kolab-devel] [issue3114] problem with drag and drop under win
	version
Message-ID: <1222947700.01.0.142492440251.issue3114@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

I moved and copy some Folder in the E-Mail view e.g. "Posteingang", "Notizen"
and so on to a generated folder. After some copy/move operations it is not
possible to "drag" a folder or email again. Only selection is possible. 
It seems that the mouse events work not as normal.

After restart of contact the mouse events work normal.

----------
messages: 16938
nosy: basyskom, till
priority: bug
status: unread
title: problem with drag and drop under win version
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3114>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 13:49:15 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 11:49:15 +0000
Subject: [Kolab-devel] [issue3115] problem with coporate calender
Message-ID: <1222948155.03.0.496798742968.issue3115@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

version windows 20080916

Tester C has access to calendar of Tester B and create a meeting for both.
Tester B declined the meeting. But in Tester C is still the meeting from Tester
B shown.

----------
messages: 16940
nosy: basyskom
status: unread
title: problem with coporate calender
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3115>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 13:52:46 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 11:52:46 +0000
Subject: [Kolab-devel] [issue3116] no cooperate calendar under win
Message-ID: <1222948366.18.0.86429294086.issue3116@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

version windows 20080916

Tester C has access to the calendar from Tester B. The Access is visible in the
Kolab Resource but in the calendar view is the standard calendar visible.

Expect here as in Linux tab of Tester C's calendar and tab of Tester B's calendar.

----------
messages: 16941
nosy: basyskom, till
status: unread
title: no cooperate calendar under win
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3116>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 13:57:44 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 11:57:44 +0000
Subject: [Kolab-devel] [issue3117] problem at identity change of diffrent
	usr in one account (win)
Message-ID: <1222948664.77.0.624240729856.issue3117@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

version windows 20080916

Tester A has more Identities in Kontact.
As example here Tester B, Tester C, Tester D.

Tester A create a new Mail and change the identity to Tester B before sending
the email. The problem is that the password entry is shown for Tester A. 

If I insert the password the email can't be send. If I change the account name
to Tester B with his password than the email can be send.

Why doesn't recognize contact the identity change and give me the right user to
set the password. . .

----------
messages: 16942
nosy: basyskom, till
priority: bug
status: unread
title: problem at identity change of diffrent usr in one account (win)
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3117>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 14:01:39 2008
From: kolab-issues at intevation.de (basysKom GmbH)
Date: Thu, 02 Oct 2008 12:01:39 +0000
Subject: [Kolab-devel] [issue3118] encrypted mail can't load from kolab (win)
Message-ID: <1222948899.7.0.316927565708.issue3118@intevation.de>


New submission from basysKom GmbH <kontactbugs at basyskom.de>:

version windows 20080916

Tester A encrypt an email and send it to Tester B. The email is sent.
The email is in the inbox of Tester B at the Kolab server.
Tester B can't get the email. After retry of actualize emails, the email is not
transmitted to the kontact inbox folder.

----------
messages: 16943
nosy: basyskom, till
priority: bug
status: unread
title: encrypted mail can't load from kolab (win)
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3118>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 14:34:44 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 02 Oct 2008 12:34:44 +0000
Subject: [Kolab-devel] [issue3119] Black notes are displayed after a new
	system start
Message-ID: <1222950884.81.0.214555530048.issue3119@intevation.de>


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

enterprise35 20081001.865016

This bug is related to kolab/issue3106

Test:
In a KDE environment
1.Start knotes from the KDE menu.
=> kontact starts and the knotes icon is in the system tray.
2. Create 8 notes using the knotes from the system tray.
=> A lot of notes are on the desktop.
3. Hard kill kontact (kill -9)
4. Restart kontact

Notice : some of the notes on the desktop are just black.

----------
assignedto: till
messages: 16944
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: bug
status: unread
title: Black notes are displayed after a new system start
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3119>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct  2 15:14:43 2008
From: kolab-issues at intevation.de (T. Ribbrock)
Date: Thu, 02 Oct 2008 13:14:43 +0000
Subject: [Kolab-devel] [issue3120] DOS format mbox file crashes Kontact
Message-ID: <1222953283.78.0.210355857917.issue3120@intevation.de>


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

I ran into the following problem: Sometimes, we have to fetch mail from backup
and send them to someone. Our backups are taken from the Cyrus spool on our
Kolab server and are therefore in the same format as Cyrus stores its mail. As
the single mails stored in this format are not in straight-forward MBOX format,
I usually pipe them through formail to make them MBOX. The resulting file is
accepted by mutt as MBOX and I can also open it in KMail with "File->Open"
without problems.

However, if I attach such a file to another mail (Composer -> Attach File Button
-> select this file) I can cause a reproducible crash by double-clicking on the
attachment in Composer. I spent some time investigating this and as far as I can
see this problem is caused by the extra line-feeds that Cyrus adds to the mails
("vim" says they're in "DOS" format). If I remove them before attaching the
mail, the crash does not happen.

I'll attach the backtrace and a testmail.mbox file which reproduces this crash
100% in my set-up.

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

I have seen the same problem in 858460 already.

----------
files: Crash_on_clicking_mbox_attachment_in_composer-862683.txt
messages: 16946
nosy: itsef_admin
priority: urgent
status: unread
title: DOS format mbox file crashes Kontact
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3120>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Crash_on_clicking_mbox_attachment_in_composer-862683.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20081002/8606be67/Crash_on_clicking_mbox_attachment_in_composer-862683.txt

From bernhard at intevation.de  Thu Oct  2 16:24:08 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 2 Oct 2008 16:24:08 +0200
Subject: [Kolab-devel] kdepim enterprise35 for debian lenny
In-Reply-To: <200809142248.20940.michael@mailwurm.org>
References: <200809142248.20940.michael@mailwurm.org>
Message-ID: <200810021624.09647.bernhard@intevation.de>

On Sunday 14 September 2008 22:48, Michael wrote:
>  (repackage) debian etch kdepim-enterprise35 packages for debian
> lenny. ?
>
> To install please put this lines in your sources.list:
>
> deb http://mailwurm.org lenny kdepim-enterprise35
> deb-src http://mailwurm.org lenny kdepim-enterprise35

BTW: I could successfully rebuild from the source-packages 
kdepim_3.5.9.enterprise.0.20080908.858460-mm1 
a version for powerpc for Debian unstable (sid) 20080922.
(Haven't tested the binaries yet.)

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Neuer Graben 17, Osnabr?ck, DE; AG 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: 189 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081002/37af0e76/attachment.bin

From kolab-issues at intevation.de  Thu Oct  2 17:21:13 2008
From: kolab-issues at intevation.de (T. Ribbrock)
Date: Thu, 02 Oct 2008 15:21:13 +0000
Subject: [Kolab-devel] [issue3121] IMAP folder size unreliable in Kontact
Message-ID: <1222960873.52.0.939173140189.issue3121@intevation.de>


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

After having had some trouble with quotas on our Kolab server, it became evident
that the folder sizes that Kontact are very unreliable. This has lead to several
users complaining along the lines "how am I supposed to clean up my mailbox if I
cannot see which folder is the biggest?".

I looked into the issue and found huge discrepancies. Example: For the inbox of
my own (online IMAP) account, Kontact reports "1.1MB" in the "Size" column of
the folder view. A "du" on the server itself shows 156MB(!) and mutt reports
148MB - what Kontact reports is therefore nowhere near reality.

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

----------
messages: 16949
nosy: itsef_admin
priority: bug
status: unread
title: IMAP folder size unreliable in Kontact
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3121>
___________________________________________________


From kolab-issues at intevation.de  Fri Oct  3 10:05:41 2008
From: kolab-issues at intevation.de (BOURIAUD)
Date: Fri, 03 Oct 2008 08:05:41 +0000
Subject: [Kolab-devel] [issue3122] gmp-4.2.2 fails to compile on rhel 5.2
Message-ID: <1223021141.44.0.116541095721.issue3122@intevation.de>


New submission from BOURIAUD <david.bouriaud at ac-rouen.fr>:

I'm trying to install kolab2 server on a DELL PE1920 with 2 intel Xeon E5420
@2.50 Ghz and 8Go ram.
The install process fails with the same error as the one figured out in issu
2928. I've tried out what's proposed here, and even patched gmp.spec file as
proposed, but nothing allows me to get further.
I can test various things if it can help have it compiled, but I don't know
where to begin with. As far as I know, the kernel is smp and compiled for a 64
bits architecture, but to be sure I give you the uname -a result :
Linux localhost.localdomain 2.6.18-92.1.10.el5 #1 SMP Wed Jul 23 03:56:11 EDT
2008 x86_64 x86_64 x86_64 GNU/Linux
And the local gcc is this one :
gcc (GCC) 4.1.2 20071124 (Red Hat 4.1.2-42)

Thanks for any help provided.

P.S. forgive-me for this double post, but I didn't expect the first one to go in
issue 2928, and since it is not the same archi, I guess a new issue is more adapted.

----------
messages: 16954
nosy: bouriaud
priority: critical
status: unread
title: gmp-4.2.2 fails to compile on rhel 5.2
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3122>
___________________________________________________


From kolab-issues at intevation.de  Fri Oct  3 10:11:26 2008
From: kolab-issues at intevation.de (courage by)
Date: Fri, 03 Oct 2008 08:11:26 +0000
Subject: [Kolab-devel] [issue3123] An it mankind
Message-ID: <001301c92540$641d0d50$0069a6e4@usera1b6accba6>


New submission from courage by <dcucustom at pwadc.com>:

with telnet and then into Media Moo. From inside Media Moo we user from excess radiation.  Other physical problems that occur
medium tool would be an added skill to other artists like myself.

----------
messages: 16955
nosy: dcucustom
status: unread
title: An it mankind
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3123>
___________________________________________________


From kolab-issues at intevation.de  Sat Oct  4 10:31:31 2008
From: kolab-issues at intevation.de (Michael)
Date: Sat, 04 Oct 2008 08:31:31 +0000
Subject: [Kolab-devel] [issue3124] Some attributes not shown in Kolab
	Webadmin external addresses
Message-ID: <1223109091.22.0.439454046374.issue3124@intevation.de>


New submission from Michael <kolab at micology.org>:

I was just playing around with Kolab 2.2 on Ubuntu 8.04.
After creating an external address with all attributes, everything worked ok and
was saved in ldap.
Modifying the same address entry in Kolab Webadmin shows empty entries for:
Room Number, Post Box, Postal Code, Telephone Number and Fax Number.



amavisd: 2.5.3-20080101
apache: 2.2.8-20080118
clamav: 0.93.3-20080708
imapd: 2.3.11-20080101_kolab4
kolab-filter: 2.2.0-20080709
kolab-freebusy: 2.2.0-20080709
kolab-webadmin: 2.2.0-20080709
kolabconf: 2.2.0-20080709
kolabd: 2.2.0-20080709
openldap: 2.3.41-20080424
perl-kolab: 2.2.0-20080709
php-kolab: 2.2.0-20080711
postfix: 2.4.6-20080101_kolab
spamassassin: 3.2.4-20080107

----------
messages: 16958
nosy: Mic
priority: minor bug
status: unread
title: Some attributes not shown in Kolab Webadmin external addresses
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3124>
___________________________________________________


From kolab-issues at intevation.de  Sun Oct  5 18:23:36 2008
From: kolab-issues at intevation.de (Mrs. Caroline Bryan.)
Date: Sun, 05 Oct 2008 16:23:36 +0000
Subject: [Kolab-devel] [issue3125] Your Email Address Was Selected
Message-ID: <20081005112253.lus4fsvz9mosk48s@mail.asocajas.org.co>


New submission from Mrs. Caroline Bryan. <online at lotto.co.uk>:

Atten: Lucky winner

We are pleased to inform you that your e-mail address has won the UK
Sweepstakes International Programme.Therefore you have been approve for a lump
sum payout (1,000,000.00 GBP) One Million Pounds in the Uk Sweepstakes
International Program held on 9th September 2008, and release 10th September
2008. Your e-mail ID emerged as one of the winners in the
1st category.

Please fill the form below and send it to our payment department with the
contact given below.

Name: Martin James
Email: james_mas at live.com
Phone: +44 70457 41170

PAYMENT PROCESSING FORM

1.Full Name:
2.Full Address:
3.Status:
4.Occupation:
5.Phone Number
6.Country:

Yours faithfully,
Mrs. Caroline Bryan.

------------------------------------

----------
messages: 16963
nosy: online
status: unread
title: Your Email Address Was Selected
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3125>
___________________________________________________


From kolab-issues at intevation.de  Mon Oct  6 14:38:47 2008
From: kolab-issues at intevation.de (T. Ribbrock)
Date: Mon, 06 Oct 2008 12:38:47 +0000
Subject: [Kolab-devel] [issue3126] Crash on moving IMAP folders with
	subfolders
Message-ID: <1223296727.14.0.158890241221.issue3126@intevation.de>


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

I've seen the following problem twice so far:

Two online IMAP accounts. Try to move a folder with a bunch of subfolders from
one account to the other account. Sometimes, KMail will crash after a while
during the move.

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

I've also seen this in 837785 and will attach backtraces for both.

----------
files: Crash_on_moving_IMAP_folder_with_subfolders_to_other_IMAP_folder-862683.txt
messages: 16971
nosy: itsef_admin
priority: urgent
status: unread
title: Crash on moving IMAP folders with subfolders
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3126>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Crash_on_moving_IMAP_folder_with_subfolders_to_other_IMAP_folder-862683.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20081006/c1b6e8e3/Crash_on_moving_IMAP_folder_with_subfolders_to_other_IMAP_folder-862683.txt

From kolab-issues at intevation.de  Mon Oct  6 16:13:08 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 06 Oct 2008 14:13:08 +0000
Subject: [Kolab-devel] [issue3127] Cannot open a mail d'n'ded to the desktop
	and then cannot restart kontact
Message-ID: <1223302388.07.0.344632469074.issue3127@intevation.de>


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

enterprise35 20081001.865016

Test:
1. Switch to kmail.
2. D'n'D a mail to the desktop. Name: "test".
3. Close kontact.
4. Double click on the mail on the desktop.
Neither Kontact nor Kmail opens, the mail is not displayed.
Now it is not possible to start kontact again.

----------
assignedto: till
messages: 16982
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: urgent
status: unread
title: Cannot open a mail d'n'ded to the desktop and then cannot restart kontact
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3127>
___________________________________________________


From wrobel at pardus.de  Tue Oct  7 10:04:35 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 07 Oct 2008 10:04:35 +0200
Subject: [Kolab-devel] CeBIT Open Source: Linux Magazine and
	Linux	Foundation Announce Call for Projects - Linux Magazine Online
In-Reply-To: <200810012230.58439.ml@radoeka.nl>
References: <200810012230.58439.ml@radoeka.nl>
Message-ID: <20081007100435.16941spyl170bqq8@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Is this something for the kolab project (including some of
> the surrounding projects):
> http://www.linux-magazine.com/online/news/cebit_open_source_linux_magazine_and_linux_foundation_announce_call_for_projects
>

The Kolab Konsortium has traditionally been present at Cebit and  
expect this to be the case for the next one as well. I don't know if  
the Konsortium will apply for a free booth but I expect them to be  
there in any case.

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/20081007/6d511058/attachment.bin

From kolab-issues at intevation.de  Tue Oct  7 15:10:18 2008
From: kolab-issues at intevation.de (Karl-Heinz Ruskowski)
Date: Tue, 07 Oct 2008 13:10:18 +0000
Subject: [Kolab-devel] [issue3128] PEAR-Horde-Channel is needed by Horde_Argv
Message-ID: <1223385018.54.0.723042722898.issue3128@intevation.de>


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

I was trying to build Kolabserver from cvs and make stumbled upon this 

...
cp Horde_Argv.spec /kolab/RPM/SRC/Horde_Argv
cd /kolab/RPM/SRC/Horde_Argv && /kolab/bin/openpkg rpm -ba Horde_Argv.spec
error: Failed build dependencies:
        PEAR-Horde-Channel is needed by Horde_Argv-0.1.0-20080924
make[1]: *** [Horde_Argv-0.1.0-20080924.src.rpm] Error 1
make[1]: Leaving directory `/kolab-cvs/server/pear/Horde_Argv'
make: *** [pear] Error 2

----------
assignedto: thomas
messages: 17001
nosy: bernhard, khruskowski, martin, thomas, till, wilde, wrobel
priority: bug
status: unread
title: PEAR-Horde-Channel is needed by Horde_Argv
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3128>
___________________________________________________


From kolab-issues at intevation.de  Wed Oct  8 14:10:27 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 08 Oct 2008 12:10:27 +0000
Subject: [Kolab-devel] [issue3129] freebusy hour scale is broken
Message-ID: <1223467827.41.0.43140539949.issue3129@intevation.de>


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

enterprise4 Kontact-Installer_20080923.exe (kdepimlibs: 863546, kdepim: 863546)

The hour scale seems to display wrong info.

Test:
1. Create a test event.
2. Start to edit this event.
3. Switch to attendee tab.
4. Change the scale to "Hour".
It seems like a month view is displayed, anyway the displayed calendar is wrong.

----------
assignedto: till
messages: 17004
nosy: bh, jstaniek, ludwig, till
priority: minor bug
status: unread
title: freebusy hour scale is broken
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3129>
___________________________________________________


From liste at gelpi.it  Thu Oct  9 09:47:34 2008
From: liste at gelpi.it (Gelpi Andrea)
Date: Thu, 09 Oct 2008 09:47:34 +0200
Subject: [Kolab-devel] Kolab server 2.2.0 ldap error
Message-ID: <48EDB716.10608@gelpi.it>

If a user Last Name contains symbols LDAP give error when you try to access it.

To reproduce:

1) Create via webadmin a user with  Last Name D'Name. The user is created.
2) Try to modify or delete that user. LDAP reply CN does't exist.

It works in kolab server 2.1.0 instead.

-- 
ing. Andrea Gelpi
***************************************************
La Terra non la abbiamo ereditata dai nostri avi,
ma la abbiamo presa in prestito dai nostri bambini.
***************************************************
We do not inherit the Earth from our parents,
but borrow it from our children.
***************************************************


From wrobel at pardus.de  Thu Oct  9 09:57:04 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 09 Oct 2008 09:57:04 +0200
Subject: [Kolab-devel] Kolab server 2.2.0 ldap error
In-Reply-To: <48EDB716.10608@gelpi.it>
References: <48EDB716.10608@gelpi.it>
Message-ID: <20081009095704.71996xxnrw0zzxwc@webmail.pardus.de>

Quoting Gelpi Andrea <liste at gelpi.it>:

> If a user Last Name contains symbols LDAP give error when you try to  
> access it.
>
> To reproduce:
>
> 1) Create via webadmin a user with  Last Name D'Name. The user is created.
> 2) Try to modify or delete that user. LDAP reply CN does't exist.
>
> It works in kolab server 2.1.0 instead.
https://www.intevation.de/roundup/kolab/issue1880


>
> --
> ing. Andrea Gelpi
> ***************************************************
> La Terra non la abbiamo ereditata dai nostri avi,
> ma la abbiamo presa in prestito dai nostri bambini.
> ***************************************************
> We do not inherit the Earth from our parents,
> but borrow it from our children.
> ***************************************************
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

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


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


From kolab-issues at intevation.de  Thu Oct  9 14:48:17 2008
From: kolab-issues at intevation.de (Jeff Walls)
Date: Thu, 09 Oct 2008 12:48:17 +0000
Subject: [Kolab-devel] [issue3130] Perl Error on Upgrade
Message-ID: <1223556497.13.0.993351284642.issue3130@intevation.de>


New submission from Jeff Walls <jwalls at browntransmission.com>:

Trying again to upgrade to Kolab 2.2 on Fedora 5, from Kolab 2.1.

The problem now is in perl-mail:

:::: /tmp/install-kolab.6968.5087.1078.1447/gzip-1.3.12-20080101.src.rpm = 0
:::
:
::::
/tmp/install-kolab.6968.5087.1078.1447/perl-mail-5.10.0-20080117.src.rpm ::
::
Installing
/tmp/install-kolab.6968.5087.1078.1447/perl-mail-5.10.0-20080117.src.
rpm
Executing(%prep): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix
-e /
kolab/RPM/TMP/rpm-tmp.54697
+ cd /kolab/RPM/TMP
+ cd /kolab/RPM/TMP
+ rm -rf perl-mail-5.10.0
+ /kolab/lib/openpkg/shtool mkdir -f -p -m 755 -p perl-mail-5.10.0
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc /kolab/RPM/SRC/perl-mail/MailTools-2.02.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/MIME-tools-5.425.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/MIME-Lite-3.021.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/MIME-Base64-3.07.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/MIME-Explode-0.38.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/MIME-Types-1.23.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/User-Identity-0.92.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/Mail-IMAPClient-3.03.tar.
gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc /kolab/RPM/SRC/perl-mail/Mail-Box-2.080.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/Mail-MboxParser-0.55.tar.
gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/Mail-Mbox-MessageParser-1
.5000.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/Mail-Sendmail-0.79.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/Mail-Sender-0.8.13.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/Email-Address-1.889.tar.g
z
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/Email-Valid-0.179.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/Email-Simple-2.003.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/Email-MessageID-1.351.tar
.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/Email-MIME-ContentType-1.
014.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/Email-MIME-Encodings-1.31
1.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/Email-MIME-1.861.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/Email-MIME-Modifier-1.442
.tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ /kolab/lib/openpkg/gzip -dc
/kolab/RPM/SRC/perl-mail/Email-MIME-Creator-1.454.
tar.gz
+ /kolab/lib/openpkg/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ /kolab/lib/openpkg/shtool subst -e
's;/usr/lib/sendmail;/kolab/sbin/sendmail;'
+ /kolab/lib/openpkg/shtool subst -e
's;/usr/lib/sendmail;/kolab/sbin/sendmail;' MIME-Lite-3.021/lib/MIME/Lite.pm
+ exit 0
Executing(%build): env -i /kolab/lib/openpkg/bash --norc --noprofile --posix
-e /kolab/RPM/TMP/rpm-tmp.9511
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ exit 0
Executing(%install): env -i /kolab/lib/openpkg/bash --norc --noprofile
--posix -e /kolab/RPM/TMP/rpm-tmp.9511
+ cd /kolab/RPM/TMP
+ cd perl-mail-5.10.0
+ rm -rf /kolab/RPM/TMP/perl-mail-5.10.0-root
+ /kolab/bin/perl-openpkg prepare
IO object version 1.23_01 does not match bootstrap parameter 1.23 at
/kolab/lib/perl/5.10.0/i686-linux/DynaLoader.pm line 226.
Compilation failed in require at /kolab/bin/perl-openpkg line 29.
BEGIN failed--compilation aborted at /kolab/bin/perl-openpkg line 29.
error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.9511 (%install)


RPM build errors:
    Bad exit status from /kolab/RPM/TMP/rpm-tmp.9511 (%install)

----------
messages: 17011
nosy: jswalls110
priority: urgent
status: unread
title: Perl Error on Upgrade
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3130>
___________________________________________________


From kolab-issues at intevation.de  Sun Oct 12 03:49:48 2008
From: kolab-issues at intevation.de (wenzhuo)
Date: Sun, 12 Oct 2008 01:49:48 +0000
Subject: [Kolab-devel] [issue3131] horde po/translation.php not working
Message-ID: <1223776188.86.0.320091222117.issue3131@intevation.de>


New submission from wenzhuo <wenzhuo at zhmail.com>:

/kolab/var/kolab/www/horde/po/translation.php does not work due to missing pear
modules: Console_Table and File_Find.




# ./translation.php 
---------------------------
Horde translation generator
---------------------------
Loading libraries...
Console_Getopt... OK
Console_Table... PHP Warning:  include(Console/Table.php): failed to open
stream: No such file or directory in
/kolab/var/kolab/www/horde/po/translation.php on line 1425
PHP Warning:  include(): Failed opening 'Console/Table.php' for inclusion
(include_path='/kolab/var/kolab/www/horde/lib:.:/kolab/lib/php') in
/kolab/var/kolab/www/horde/po/translation.php on line 1425
Console_Table not found.
File_Find... PHP Warning:  include(File/Find.php): failed to open stream: No
such file or directory in /kolab/var/kolab/www/horde/po/translation.php on line 1425
PHP Warning:  include(): Failed opening 'File/Find.php' for inclusion
(include_path='/kolab/var/kolab/www/horde/lib:.:/kolab/lib/php') in
/kolab/var/kolab/www/horde/po/translation.php on line 1425
File_Find not found.

Make sure that you have PEAR installed and in your include path.
include_path: /kolab/var/kolab/www/horde/lib:.:/kolab/lib/php

Please report any bugs to i18n at lists.horde.org.

----------
messages: 17017
nosy: wenzhuo
priority: bug
status: unread
title: horde po/translation.php not working
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3131>
___________________________________________________


From kolab-issues at intevation.de  Sun Oct 12 03:54:31 2008
From: kolab-issues at intevation.de (wenzhuo)
Date: Sun, 12 Oct 2008 01:54:31 +0000
Subject: [Kolab-devel] [issue3132] horde po/translation.php: wrong php
	commandline path
Message-ID: <1223776471.84.0.227802419445.issue3132@intevation.de>


New submission from wenzhuo <wenzhuo at zhmail.com>:

The first line of /kolab/var/kolab/www/horde/po/translation.php is currently
"#!/usr/bin/php -q', which should really be "#!/kolab/bin/php -q".

----------
messages: 17018
nosy: wenzhuo
status: unread
title: horde po/translation.php: wrong php commandline path
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3132>
___________________________________________________


From kolab-issues at intevation.de  Sun Oct 12 09:27:06 2008
From: kolab-issues at intevation.de (wenzhuo)
Date: Sun, 12 Oct 2008 07:27:06 +0000
Subject: [Kolab-devel] [issue3133] domain maintainer unable to set quota
Message-ID: <1223796426.64.0.616727885005.issue3133@intevation.de>


New submission from wenzhuo <wenzhuo at zhmail.com>:

Version: kolab-server-2.2.0

Domain maintainers are unable to modify cyrus-userquota. Here is the quick fix.

# diff  /kolab/var/kolab/www/admin/user/user.php.maintainer
/kolab/var/kolab/www/admin/user/user.php
557c557
<        if ($auth->group() == "maintainer" || $auth->group() == "admin") {
---
>        if ($auth->group() == "maintainer" || $auth->group() ==
"domain-maintainer" || $auth->group() == "admin") {

----------
messages: 17020
nosy: wenzhuo
priority: bug
status: unread
title: domain maintainer unable to set quota
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3133>
___________________________________________________


From kolab-issues at intevation.de  Sun Oct 12 09:46:02 2008
From: kolab-issues at intevation.de (wenzhuo)
Date: Sun, 12 Oct 2008 07:46:02 +0000
Subject: [Kolab-devel] [issue3134] Folder name Contacts not translated
Message-ID: <1223797562.01.0.641175027429.issue3134@intevation.de>


New submission from wenzhuo <wenzhuo at zhmail.com>:

Unlike other special IMAP folder names (Calendar, Notes and Tasks), Contacts is
not translated according to user's locale.

----------
messages: 17021
nosy: wenzhuo
priority: bug
status: unread
title: Folder name Contacts not translated
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3134>
___________________________________________________


From kolab-issues at intevation.de  Mon Oct 13 11:49:26 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Mon, 13 Oct 2008 09:49:26 +0000
Subject: [Kolab-devel] [issue3135] Crash in KMSender::doSendMsg
	DwRfc822Tokenizer DwTokenizer DwString
Message-ID: <1223891365.71.0.350755531786.issue3135@intevation.de>


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

Kontact: 1.2.9 (enterprise35 20080919.862683)

While sending an email over a slow line (mobile gprs),
the progress bar was at 99% for a while. I was viewing emails
in a different folder meanwhile.
Nothing interesting in the console output.

----------
assignedto: till
files: kontact-crash-20081008-1.txt
messages: 17046
nosy: bernhard, ludwig, till, vkrause
priority: bug
status: unread
title: Crash in KMSender::doSendMsg DwRfc822Tokenizer  DwTokenizer DwString
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3135>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kontact-crash-20081008-1.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20081013/75057ba1/kontact-crash-20081008-1.txt

From kolab-issues at intevation.de  Mon Oct 13 14:28:36 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 13 Oct 2008 12:28:36 +0000
Subject: [Kolab-devel] [issue3137] While creating a event with attendee,
	kwallet is not asked, to get the password
Message-ID: <1223900916.05.0.969275824597.issue3137@intevation.de>


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

enterprise4 
Kontact-Installer_20081013.exe (kdepimlibs: 869818, kdepim: 869818)

Test:
1. Create a new kolab account with saved password and configure kwallet.
2. Start kontact.
3. Create a new event with attendee and send mail.
Notice: kontact doesn't start kwallet, but asks for the server password. 

This is important, because saving passwords in kwallet is needed to use kmail well.

----------
assignedto: till
messages: 17052
nosy: bh, ludwig, till
priority: urgent
status: unread
title: While creating a event with attendee, kwallet is not asked, to get the password
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3137>
___________________________________________________


From kolab-issues at intevation.de  Tue Oct 14 07:44:36 2008
From: kolab-issues at intevation.de (Gunnar Wrobel)
Date: Tue, 14 Oct 2008 05:44:36 +0000
Subject: [Kolab-devel] [issue3138] Upgrade from Kolab-2.1 to Kolab-2.2 failed
Message-ID: <1223963076.08.0.913389714424.issue3138@intevation.de>


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

We recently had two upgrade failure reports with a similar issue.

http://kolab.org/pipermail/kolab-users/2008-September/008752.html
http://lists.wald.intevation.org/pipermail/kolab-users-de/2008-September/000129.html


In both cases the installation fails right at the beginning.

A close look at the beginning of the command line the installer tries to run

    /kolab/bin/openpkg build -kKBuZ -r "/tmp/install-kolab.545.9588.7063.16159" ...

shows a temporary install location which is not correct.

I believe that happens because the installer creates a temporary directory and
does not return to the source directory.

In cases where the user does not provide any arguments to the installer the
script will set INSTALL=`pwd` in line 216. This will be the temp dir which would
be incorrect.

I tried to fix this now with
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/install-kolab.sh.diff?r1=1.44&r2=1.45

@thomas, wilde: Can you check if I correctly identified the error, fixed it in a
sane way and maybe update the install script on the mirrors if you consider it
necessary?

----------
assignedto: thomas
messages: 17060
nosy: bernhard, thomas, wilde, wrobel
priority: urgent
status: testing
title: Upgrade from Kolab-2.1 to Kolab-2.2 failed
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3138>
___________________________________________________


From wrobel at pardus.de  Tue Oct 14 08:13:47 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 14 Oct 2008 08:13:47 +0200
Subject: [Kolab-devel] Kolab in the clouds
Message-ID: <20081014081347.27441bu8f5a6cfq8@webmail.pardus.de>

I marked a Xen based image of a Kolab2/OpenPKG-2.1 server "public" on  
Amazon/EC2 today. This allows you to quickly fire up a pre-built Kolab  
server and play with it.

Currently this is just a Kolab-2.1 server but the newer ones will  
follow (maybe even including a CVS based image).

This is *NOT* meant to be used for production servers. The EC2 system  
provided by Amazon has some very nice features but running mail  
servers there does not work - or is at least not recommended.

I personally use this for development work as I frequently need access  
to older versions of the Kolab server. By using the images I can  
quickly fire up an old version of the server for a few cents and test  
stuff or respond to a user request.

So if anybody has similar needs: Feel free to play around with the images.

The current one is AMI "ami-6e2eca07" and I update the thread once I  
publish others.

Cheers,

Gunnar

-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

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


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


From kolab-issues at intevation.de  Tue Oct 14 12:01:52 2008
From: kolab-issues at intevation.de (T. Ribbrock)
Date: Tue, 14 Oct 2008 10:01:52 +0000
Subject: [Kolab-devel] [issue3139] "Mark...as Read" does not work for
	multiple folders
Message-ID: <1223978512.09.0.983237011527.issue3139@intevation.de>


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

In the enterprise35 Kontact, I can select multiple folders  in the folder list
with Shift+click and Ctrl+click. While things like moving and copying work as
expected, the "Mark All Messages as Read" entry in either the context menu or
the "Folder" menu does not. If I use this function while having several folders
selected, only the messages in the folder that was selected last are marked as
read. What I would expect in this situation is that all messages in all selected
folders get marked as read.

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

----------
messages: 17083
nosy: itsef_admin
priority: minor bug
status: unread
title: "Mark...as Read" does not work for multiple folders
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3139>
___________________________________________________


From kolab-issues at intevation.de  Tue Oct 14 12:52:01 2008
From: kolab-issues at intevation.de (MR David Mark)
Date: Tue, 14 Oct 2008 10:52:01 +0000
Subject: [Kolab-devel] [issue3140] ATMCARD822
Message-ID: <e1eed852f95e364cf958a96bfa8db2df.squirrel@sol.ccsa.ufrn.br>


New submission from MR David Mark <info at atm.org>:

This is to officially inform you that(ATM Card Number;
4278763100030014) has been accredited with your favor.Your Personal
Identification Number is 822. The ATM Card Value is $6.8MILLION USD.
You are advice to contact Mrs Linda Hills via
Email:(mrslindahillpayout822 at yahoo.com.hk)with the following 
information's;
FULL NAME:
DELIVERY ADDRESS:
PHONE NUMBER
COUNTRY:
OCCUPATION:
SEX:
AGE:
Best Regards,
Senator David Mark.

----------
messages: 17086
nosy: info4
status: unread
title: ATMCARD822
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3140>
___________________________________________________


From kolab-issues at intevation.de  Tue Oct 14 12:56:26 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Tue, 14 Oct 2008 10:56:26 +0000
Subject: [Kolab-devel] [issue3141] Whole day events are displayed as line in
	the freebusy list after a sync.
Message-ID: <1223981786.12.0.547132011461.issue3141@intevation.de>


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

enterprise4 Kontact-Installer_20081013.exe (kdepimlibs: 869818, kdepim: 869818)

Test:
1. Switch to the calendar.
2. Create a new whole day event.
3. Sync.
4. Edit the whole day event and look at the freebusy list.
Notice: the whole day event is displayed as a small line and not the whole day.

----------
assignedto: till
messages: 17087
nosy: bh, ludwig, till
priority: bug
status: unread
title: Whole day events are displayed as line in the freebusy list after a sync.
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3141>
___________________________________________________


From kolab-issues at intevation.de  Tue Oct 14 15:02:28 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Tue, 14 Oct 2008 13:02:28 +0000
Subject: [Kolab-devel] [issue3142] Triggering pfb creation for all changes.
Message-ID: <1223989347.97.0.467674985508.issue3142@intevation.de>


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

We should do a test to see if KDE Kontact issues a pdf trigger
for all the operations that freebusy.txt Rev1.25 or later lists.

http://kolab.org/cgi-bin/viewcvs-kolab.cgi/doc/architecture/freebusy.txt?rev=1.25&content-type=text/vnd.viewcvs-markup
| Creation, deletion of a folder, 
| change of ACLs, annotations or non-local flags 
| also constitute a "write operation" making a trigger recessary.

Should be checked for enterprise35 and enterprise4.
Ludwig, maybe we put one test in the list of tests.

----------
assignedto: ludwig
messages: 17093
nosy: bernhard, bh, ludwig
priority: bug
status: unread
title: Triggering pfb creation for all changes.
topic: kde client, kowi, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3142>
___________________________________________________


From ml at radoeka.nl  Tue Oct 14 15:09:41 2008
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 14 Oct 2008 15:09:41 +0200
Subject: [Kolab-devel] bernhard: doc/architecture freebusy.txt, 1.24,
	1.25
In-Reply-To: <20081014125917.17C9D60016C@lists.intevation.de>
References: <20081014125917.17C9D60016C@lists.intevation.de>
Message-ID: <20081014130941.GA77882@xs4all.nl>

On Tue, Oct 14, 2008 at 02:59:17PM +0200, cvs at kolab.org wrote:
> +also constitute a "write operation" making a trigger recessary.

Small typo "recessary" -> necessary...

-- 
RB


From kolab-issues at intevation.de  Tue Oct 14 16:26:11 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Tue, 14 Oct 2008 14:26:11 +0000
Subject: [Kolab-devel] [issue3143] invalid keys are accepted by KMail
	(certmanager/lib/ui/keyselectiondialog.cpp)
Message-ID: <1223994371.08.0.440955016631.issue3143@intevation.de>


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

There is code in 
@svn.kde.org/home/kde/branches/kdepim/enterprise/kdepim/certmanager/lib/ui/keyselectiondialog.cpp

static bool checkKeyUsage( const GpgME::Key & key, unsigned int keyUsage ) {

  if ( keyUsage & Kleo::KeySelectionDialog::ValidKeys ) {
    if ( key.isInvalid() )
      kdDebug() << "key is invalid - ignoring" << endl;
    if ( key.isExpired() ) {
      kdDebug() << "key is expired" << endl;
      return false;
    } else if ( key.isRevoked() ) {
      kdDebug() << "key is revoked" << endl;
      return false;
    } else if ( key.isDisabled() ) {
      kdDebug() << "key is disabled" << endl;
      return false;
    }
  }

Where does this "ignoring" come from?
Invalid keys should not be used I guess.
This code section has not been changed in a long while,
I do have the problem that with Kontact Version 1.2.9 (enterprise35 
20081003.867492) a key that does not work in
LANG=C gpgsm -vv -e -r bernhard at intevation.de x >x.enc
gpgsm: can't encrypt to `bernhard at intevation.de': Not trusted

because it is invalid
LANG=C gpgsm --with-colons --with-validation --list-keys bernhard at intevation.de
gpgsm: DBG: connection to dirmngr established
BUG: trying to release an already released cert
/home/etch3/.gnupg/pubring.kbx
------------------------------
crt:i:2048:1:3B85F74F46C65E78:20080619T084325:20100619T084325:06::CN=ZS 
8,O=Intevation GmbH,C=DE::escESC:
fpr:::::::::9CF8E2A00B1EE4BF02662A693B85F74F46C65E78:::0CBB157CBE5ACD8F343DBA0AEAE22FA0BD659BB2:
uid:i::::::::CN=Bernhard Reiter,O=Intevation GmbH,C=DE::
uid:i::::::::<bernhard at intevation.de>::

does not produce any warning anymore.
This must have been a recent change, so it probably is not
related to this code section. Still this section and its debugging
output smells so I would want a explanation.

Compare to kolab/issue2976 (Irritating trust warning when selecting keys for 
encryption)

----------
assignedto: till
messages: 17099
nosy: bernhard, bh, marc, till
priority: critical
status: unread
title: invalid keys are accepted by KMail (certmanager/lib/ui/keyselectiondialog.cpp)
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3143>
___________________________________________________


From aspineux at gmail.com  Tue Oct 14 20:50:19 2008
From: aspineux at gmail.com (Alain Spineux)
Date: Tue, 14 Oct 2008 20:50:19 +0200
Subject: [Kolab-devel] make kolabd more robust
Message-ID: <71fe4e760810141150g1a008e9di1db1ee03d91b8440@mail.gmail.com>

The "kolabDeleteflag" avoid kolabd to forget to delete a user.
But for the user creation, we have no guaranty no users will not be
forgotten by kolabd !
The current system is based only on a _transation less_ ldap
replication mechanism !
This means user could be forgotten !

We could have a kolabNewflag that will help kolabd to create mailbox
of these "fogotten" users !
When a user is created in IMAP, kolabd could simply remove the
kolabNewflag key. The key was created
a user creation by the kolabgui.

When kolabd start or is waked up by slurp (or LDAP sync mechanism),
then kolabd could query for
kolabDeleteflag or kolabNewflag and update the users accordingly.


Maybe the inverse idea could be used too, kolabd search for user not
having the kolabCreatedflag, create the mailbox
and then add the kolabCreatedflag key to the ldp record !
That way the webgui dont need to be chnaged and only kolabd has to
manage the kolabCreatedflag.


Regards


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


From ml at radoeka.nl  Tue Oct 14 21:03:08 2008
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 14 Oct 2008 21:03:08 +0200
Subject: [Kolab-devel] make kolabd more robust
In-Reply-To: <71fe4e760810141150g1a008e9di1db1ee03d91b8440@mail.gmail.com>
References: <71fe4e760810141150g1a008e9di1db1ee03d91b8440@mail.gmail.com>
Message-ID: <200810142103.09193.ml@radoeka.nl>

Op Tuesday 14 October 2008 20:50:19 schreef Alain Spineux:
> The "kolabDeleteflag" avoid kolabd to forget to delete a user.
> But for the user creation, we have no guaranty no users will not be
> forgotten by kolabd !
> The current system is based only on a _transation less_ ldap
> replication mechanism !
> This means user could be forgotten !
>
> We could have a kolabNewflag that will help kolabd to create mailbox
> of these "fogotten" users !
> When a user is created in IMAP, kolabd could simply remove the
> kolabNewflag key. The key was created
> a user creation by the kolabgui.
>
> When kolabd start or is waked up by slurp (or LDAP sync mechanism),
> then kolabd could query for
> kolabDeleteflag or kolabNewflag and update the users accordingly.
>
>
> Maybe the inverse idea could be used too, kolabd search for user not
> having the kolabCreatedflag, create the mailbox
> and then add the kolabCreatedflag key to the ldp record !
> That way the webgui dont need to be chnaged and only kolabd has to
> manage the kolabCreatedflag.

Would it help to use a different replication mechanism?  See issue 1755 (
https://www.intevation.de/roundup/kolab/issue1755

The only thing for openpkg based kolab is to provide openldap-2.4.  After that 
you can switch to syncrepl mode, by changing in parameter in kolab.conf

-- 
Richard Bos
Without a home the journey is endless


From wrobel at pardus.de  Wed Oct 15 06:08:47 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Wed, 15 Oct 2008 06:08:47 +0200
Subject: [Kolab-devel] make kolabd more robust
In-Reply-To: <71fe4e760810141150g1a008e9di1db1ee03d91b8440@mail.gmail.com>
References: <71fe4e760810141150g1a008e9di1db1ee03d91b8440@mail.gmail.com>
Message-ID: <20081015060847.14804owrta6cm9es@webmail.pardus.de>

Hi Alain,

Quoting Alain Spineux <aspineux at gmail.com>:

> The "kolabDeleteflag" avoid kolabd to forget to delete a user.
> But for the user creation, we have no guaranty no users will not be
> forgotten by kolabd !
> The current system is based only on a _transation less_ ldap
> replication mechanism !
> This means user could be forgotten !

Do you have a specific scenario for this? This would of course be a  
bug and should get fixed.

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". It does not store  
the information in LDAP though - that is correct. The question would  
be if that would really be necessary.

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.

But I admit the code is not 100% clean and I could imagine there are  
situations where user creation could fail.

It would be good to clarify such a scenario though and put it in an  
issue in the tracker.

Cheers,

Gunnar

>
> We could have a kolabNewflag that will help kolabd to create mailbox
> of these "fogotten" users !
> When a user is created in IMAP, kolabd could simply remove the
> kolabNewflag key. The key was created
> a user creation by the kolabgui.
>
> When kolabd start or is waked up by slurp (or LDAP sync mechanism),
> then kolabd could query for
> kolabDeleteflag or kolabNewflag and update the users accordingly.
>
>
> Maybe the inverse idea could be used too, kolabd search for user not
> having the kolabCreatedflag, create the mailbox
> and then add the kolabCreatedflag key to the ldp record !
> That way the webgui dont need to be chnaged and only kolabd has to
> manage the kolabCreatedflag.
>
>
> Regards
>
>
> --
> Alain Spineux
> aspineux gmail com
> May the sources be with you
>
> _______________________________________________
> 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/20081015/9434c52b/attachment-0001.bin

From wrobel at pardus.de  Wed Oct 15 06:10:26 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Wed, 15 Oct 2008 06:10:26 +0200
Subject: [Kolab-devel] make kolabd more robust
In-Reply-To: <200810142103.09193.ml@radoeka.nl>
References: <71fe4e760810141150g1a008e9di1db1ee03d91b8440@mail.gmail.com>
	<200810142103.09193.ml@radoeka.nl>
Message-ID: <20081015061026.209475gj97k55b8k@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Op Tuesday 14 October 2008 20:50:19 schreef Alain Spineux:
>> The "kolabDeleteflag" avoid kolabd to forget to delete a user.
>> But for the user creation, we have no guaranty no users will not be
>> forgotten by kolabd !
>> The current system is based only on a _transation less_ ldap
>> replication mechanism !
>> This means user could be forgotten !
>>
>> We could have a kolabNewflag that will help kolabd to create mailbox
>> of these "fogotten" users !
>> When a user is created in IMAP, kolabd could simply remove the
>> kolabNewflag key. The key was created
>> a user creation by the kolabgui.
>>
>> When kolabd start or is waked up by slurp (or LDAP sync mechanism),
>> then kolabd could query for
>> kolabDeleteflag or kolabNewflag and update the users accordingly.
>>
>>
>> Maybe the inverse idea could be used too, kolabd search for user not
>> having the kolabCreatedflag, create the mailbox
>> and then add the kolabCreatedflag key to the ldp record !
>> That way the webgui dont need to be chnaged and only kolabd has to
>> manage the kolabCreatedflag.
>
> Would it help to use a different replication mechanism?  See issue 1755 (
> https://www.intevation.de/roundup/kolab/issue1755

I think it might help to remove the current kolabDeleteflag. But I  
admit I didn't think this through yet and I also only started playing  
with the code in issue1755 last week.

Good work by the way ;)

Cheers,

Gunnar

>
> The only thing for openpkg based kolab is to provide openldap-2.4.   
> After that
> you can switch to syncrepl mode, by changing in parameter in kolab.conf
>
> --
> 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/20081015/01df1db9/attachment.bin

From aspineux at gmail.com  Wed Oct 15 08:16:50 2008
From: aspineux at gmail.com (Alain Spineux)
Date: Wed, 15 Oct 2008 08:16:50 +0200
Subject: [Kolab-devel] make kolabd more robust
In-Reply-To: <20081015060847.14804owrta6cm9es@webmail.pardus.de>
References: <71fe4e760810141150g1a008e9di1db1ee03d91b8440@mail.gmail.com>
	<20081015060847.14804owrta6cm9es@webmail.pardus.de>
Message-ID: <71fe4e760810142316v7ce5a194o5fb5aed993b94006@mail.gmail.com>

On Wed, Oct 15, 2008 at 6:08 AM, Gunnar Wrobel <wrobel at pardus.de> wrote:
> Hi Alain,
>
> Quoting Alain Spineux <aspineux at gmail.com>:
>
>> The "kolabDeleteflag" avoid kolabd to forget to delete a user.
>> But for the user creation, we have no guaranty no users will not be
>> forgotten by kolabd !
>> The current system is based only on a _transation less_ ldap
>> replication mechanism !
>> This means user could be forgotten !
>
> Do you have a specific scenario for this? This would of course be a bug and
> should get fixed.

I read the user mailing list and see sometime user creating themself
the mailbox using cyradmin !
And yes I remember than when changing abruptly the server clock, the
synchronisation was lost.

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

> It does not store the information in
> LDAP though - that is correct.

Storring the info in LDAP could speed up the check.

>The question would be if that would really be
> necessary.

This why we are chatting :-)

>
> 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 ! Kolabd could compare imap
mailbox and ldap entries
and delete missing items. But this become slow and then "transaction less"

>
> But I admit the code is not 100% clean and I could imagine there are
> situations where user creation could fail.
>
> It would be good to clarify such a scenario though and put it in an issue in
> the tracker.

Sorry I have no time for this !
I saw a problem (that I didn't investate myself) and proposed a solution.

>
> Cheers,
>
> Gunnar
>
>>
>> We could have a kolabNewflag that will help kolabd to create mailbox
>> of these "fogotten" users !
>> When a user is created in IMAP, kolabd could simply remove the
>> kolabNewflag key. The key was created
>> a user creation by the kolabgui.
>>
>> When kolabd start or is waked up by slurp (or LDAP sync mechanism),
>> then kolabd could query for
>> kolabDeleteflag or kolabNewflag and update the users accordingly.
>>
>>
>> Maybe the inverse idea could be used too, kolabd search for user not
>> having the kolabCreatedflag, create the mailbox
>> and then add the kolabCreatedflag key to the ldp record !
>> That way the webgui dont need to be chnaged and only kolabd has to
>> manage the kolabCreatedflag.
>>
>>
>> Regards
>>
>>
>> --
>> Alain Spineux
>> aspineux gmail com
>> May the sources be with you
>>
>> _______________________________________________
>> 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 kolab-issues at intevation.de  Wed Oct 15 11:22:35 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 15 Oct 2008 09:22:35 +0000
Subject: [Kolab-devel] [issue3144] Crash KMail::ImapJob::slotGetNextMessage
Message-ID: <1224062555.58.0.266624051439.issue3144@intevation.de>


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

enterprise35 20080602.814375

A customer reported a unreproducable crash.
He has an online-IMAP account and a lot of unreadmessages. While looking at the
messages with fast pressing "n", kontact crashs.

For the bugtrace: See the attachment.

last output on the console was:
kmail: KMReaderWin  -  finished parsing and displaying of message.
kmail: [virtual void KMFolderImap::setStatus(QValueList<int>&, KMMsgStatus,
bool)] Migrating all flags to the server
kmail: setImapStatus path=/INBOX/Package-Changes/;UID=4261:6893,6895:6905 to: \SEEN
kmail: setImapStatus path=/INBOX/Package-Changes/;UID=6906:6916 to: 
kmail: Set status during folder listing, restarting listing.
kmail: KMFolderImap::slotCheckValidityResult of: Package-Changes
kmail: connections to server slugis.knut.univention.de now 0
kmail: processNextCheck, remaining 0
kmail: account Kolab-Server f<FC>r E-Mail finished check
kmail: 19 new message(s) in .995933303.directory/.INBOX.directory/Package-Changes
*** KMail got signal 11 (Crashing)
KCrash: Application 'kontact' crashing...

----------
assignedto: till
files: Kontact-Crash-081010-OnlineIMAP-SprungVonMailZuMail.kcrash
messages: 17116
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: urgent
status: unread
title: Crash KMail::ImapJob::slotGetNextMessage
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3144>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Kontact-Crash-081010-OnlineIMAP-SprungVonMailZuMail.kcrash
Type: application/octet-stream
Size: 5349 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081015/74f47ffc/Kontact-Crash-081010-OnlineIMAP-SprungVonMailZuMail.exe

From kolab-issues at intevation.de  Wed Oct 15 12:24:46 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 15 Oct 2008 10:24:46 +0000
Subject: [Kolab-devel] [issue3145] kleopatra --external option does not work
	as expected
Message-ID: <1224066286.88.0.729178535002.issue3145@intevation.de>


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

Version: 4:3.5.10.enterprise.0.20081003.867492-kk1
kleopatra --external 
without further arguments might bring up the setting "local search".

To reproduce:
a) start kleopatra and make sure that search is set to "local"
   close kleopatra
b) on the command line use "kleopatra --external"
Observation: is still switched to "local":
Expectation: should be switched to "external".

Might be the cause for /"externalSearch/" not working in  
   kolab/issue2875 (Better guide the use to find S/MIME certificate manager 
when trying to encrypt email)

----------
assignedto: till
messages: 17122
nosy: bernhard, ludwig, marc, till, vkrause
priority: minor bug
status: unread
title: kleopatra --external option does not work as expected
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3145>
___________________________________________________


From kolab-issues at intevation.de  Wed Oct 15 13:07:10 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 15 Oct 2008 11:07:10 +0000
Subject: [Kolab-devel] [issue3146] Add action buttons for the invited person
	to the event dialog (Z68)
Message-ID: <1224068830.57.0.36289827196.issue3146@intevation.de>


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

Rechecking the use cases for Z68
(triggered by kolab/issue2274 (After a sync a saved invitation changed.) )

I find that it is still too hard to change your mind on an invitation
as an invited person or participant. We must add action buttons
to the event dialog so I can do the same actions again as from the invitation.

Kontact: 1.2.9 (enterprise35 20081003.867492)

----------
assignedto: till
messages: 17126
nosy: bernhard, ludwig, till, vkrause
priority: bug
status: unread
title: Add action buttons for the invited person to the event dialog (Z68)
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3146>
___________________________________________________


From kolab-issues at intevation.de  Wed Oct 15 15:35:25 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Wed, 15 Oct 2008 13:35:25 +0000
Subject: [Kolab-devel] [issue3147] side-by-side tab in the calendar tabview
	is not displayed correctly
Message-ID: <1224077725.74.0.832553217634.issue3147@intevation.de>


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

enterprise 4 Windows
Kontact-Installer_20081013.exe (kdepimlibs: 869818, kdepim: 869818)

Test
1. Switch to calendar
2. Activate tab view
3. Restart kontact
4. Look at the side-by-side tab.
Notice the side-by-side tab is not displayed correctly.

----------
assignedto: till
messages: 17135
nosy: bh, ludwig, till
priority: bug
status: unread
title: side-by-side tab in the calendar tabview is not displayed correctly
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3147>
___________________________________________________


From kolab-issues at intevation.de  Wed Oct 15 18:01:40 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 15 Oct 2008 16:01:40 +0000
Subject: [Kolab-devel] [issue3148] Selection (configuration) of fields to
	display for contacts hard to find as context menu only
Message-ID: <1224086500.68.0.278566895819.issue3148@intevation.de>


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

Kontact Version 1.2.9 (enterprise35 20081003.867492)
and Kowi 20080913:

The postal address and the email address can both be shown,    
but the default is to show them.   
You can dis/enable this by the right clicking context menu    
in the area that displays the details of one contact.   
    
b) There should be another way to reach those settings, not  
   only by the context menu as some users will never get the idea.  

Split out from kolab/issue2605 (Contact display usability problems leading to 
not showing postal and email addresses)

----------
assignedto: till
messages: 17144
nosy: bernhard, ludwig, till, vkrause
priority: minor bug
status: unread
title: Selection (configuration) of fields to display for contacts hard to find as context menu only
topic: enterprise35, enterprise4, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3148>
___________________________________________________


From liste at gelpi.it  Wed Oct 15 20:03:41 2008
From: liste at gelpi.it (Gelpi Andrea)
Date: Wed, 15 Oct 2008 20:03:41 +0200
Subject: [Kolab-devel] Horde/mimp
Message-ID: <48F6307D.4040204@gelpi.it>

Hi,
	I have a kolab server 2.2.0 and I noticed that accessing horde via mobile phone, after a 
successful login I get 404 error for mimp pages not found.
So I suppose mimp is active in horde configuration.

I tried to add mimp to my installation.

I downloaded mimp-h3-1.1.tar.gz, untar it and copied it under /kolab/var/kolab/www/horde

I copied *.dist file into *.php in mimp/config

I set kolab as owner and group to all files in horde/mimp

AThen I login to horde as administrator an I generated the conf.php file for mimp.

Now I can login in mimp, send messages, change folder and see the list of messages.

But if I open a message to read it I get a blank page.

In /kolab/var/apache/log/php/php-errors.log I found these lines:

[15-ott-2008 19:45:41] PHP Warning: 
require_once(/kolab/var/kolab/www/horde/config/../imp/lib/IMAP/MessageCache.php) [<a 
href='function.require-once'>function.require-once</a>]: failed to open stream: No such file or 
directory in /kolab/var/kolab/www/horde/mimp/message.php on line 80
[15-ott-2008 19:45:41] PHP Fatal error:  require_once() [<a 
href='function.require'>function.require</a>]: Failed opening required 
'/kolab/var/kolab/www/horde/config/../imp/lib/IMAP/MessageCache.php' 
(include_path='/kolab/var/kolab/www/horde/lib:.:/kolab/lib/php:/kolab/var/kolab/php:/kolab/var/kolab/php/pear') 
in /kolab/var/kolab/www/horde/mimp/message.php on line 80

Any hints?

-- 
ing. Andrea Gelpi
***************************************************
La Terra non la abbiamo ereditata dai nostri avi,
ma la abbiamo presa in prestito dai nostri bambini.
***************************************************
We do not inherit the Earth from our parents,
but borrow it from our children.
***************************************************


From kolab-issues at intevation.de  Thu Oct 16 12:07:14 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 16 Oct 2008 10:07:14 +0000
Subject: [Kolab-devel] [issue3149] "Remove contact" button is missing in the
	toolbar of kaddressbook
Message-ID: <1224151634.26.0.732557437862.issue3149@intevation.de>


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

enterprise4 Windows
Kontact-Installer_20081013.exe (kdepimlibs: 869818, kdepim: 869818)

There is no button for deleting a contact in the toolbar of kaddressbook.

----------
assignedto: till
messages: 17156
nosy: bh, ludwig, till
priority: bug
status: unread
title: "Remove contact" button is missing in the toolbar of kaddressbook
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3149>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct 16 14:55:19 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 16 Oct 2008 12:55:19 +0000
Subject: [Kolab-devel] [issue3150] Calendar: Local distribution list should
	not add itself to itself
Message-ID: <1224161719.49.0.922872260973.issue3150@intevation.de>


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

enterprise4 windows
Kontact-Installer_20081013.exe (kdepimlibs: 869818, kdepim: 869818)

Test:
1. Switch to contacts
2. Create a test local distribution list.
3. Start to edit this list.
4. Search for the name of the test local dist list.

Notice: The edited dist list can be added to itself.

----------
assignedto: till
messages: 17159
nosy: bh, ludwig, till
priority: bug
status: unread
title: Calendar: Local distribution list should not add itself to itself
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3150>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct 16 17:22:13 2008
From: kolab-issues at intevation.de (Rickie Webb)
Date: Thu, 16 Oct 2008 15:22:13 +0000
Subject: [Kolab-devel] [issue3151] rfee
Message-ID: <605627814.01353748769961@inbursa.com.mx>


New submission from Rickie Webb <hpopma at inbursa.com.mx>:

bizdl uip dcxhjh db wxiw.
http://www.swfpages.com/files/40628cgfoozu.swf

----------
messages: 17160
nosy: hpopma
status: unread
title: rfee
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3151>
___________________________________________________


From ml at radoeka.nl  Thu Oct 16 21:38:18 2008
From: ml at radoeka.nl (Richard Bos)
Date: Thu, 16 Oct 2008 21:38:18 +0200
Subject: [Kolab-devel] RFC next kolab server version 2.3 and 2.2.1?
Message-ID: <200810162138.19076.ml@radoeka.nl>

Hi,

I would like to discuss the version of the soon(?) to be released kolab 
server.  At the moment one find on the roadmap page the following 
information:

"Release 2.2.1 is envisioned for Q4 2008 or earlier. It will have at least one 
release candidate before that. Planned improvements include adding the SyncML 
improvements to Horde."

AFAIK 2.2.1 is the only known version that is being worked on, but with the 
many changes that have been made to kolab I believe that a version like 2.2.1 
is misleading.  A minor version upgrades means in most cases (for the other 
OSS projects) that the upgrade contains only bug fixes.  But looking at 
kolab's current ChangeLog, much more has changed and some changes have a big 
impact.  With this mind I would like to mentioned the removal of the packages 
kolab-filter and kolab-freebusy from kolab cvs.  This means that packages 
will get totally different names (something horde-freebusy and filter, it 
will be I think).  Newpackage files have to be made by packagers for the next 
kolab version.  Further more files have been moved from kolabd to perl-kolab.
Big changes have been made to horde.  Horde will be delivered as I believe 1 
big application instead of many seperate applications.  These are only a few 
of the many more changes that were made, and that were not bugs.

Because of the reasons above I believe that it is justified to call the next 
kolab server release 2.3 and not 2.2.1.  What's your opinion about this?

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


From wrobel at pardus.de  Thu Oct 16 22:16:58 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 16 Oct 2008 22:16:58 +0200
Subject: [Kolab-devel] RFC next kolab server version 2.3 and 2.2.1?
In-Reply-To: <200810162138.19076.ml@radoeka.nl>
References: <200810162138.19076.ml@radoeka.nl>
Message-ID: <20081016221658.15863vqjzym4angg@webmail.pardus.de>

Hi Richard,

Quoting Richard Bos <ml at radoeka.nl>:

> Hi,
>
> I would like to discuss the version of the soon(?) to be released kolab
> server.  At the moment one find on the roadmap page the following
> information:
>
> "Release 2.2.1 is envisioned for Q4 2008 or earlier. It will have at  
> least one
> release candidate before that. Planned improvements include adding the SyncML
> improvements to Horde."
>
> AFAIK 2.2.1 is the only known version that is being worked on, but with the
> many changes that have been made to kolab I believe that a version like 2.2.1
> is misleading.  A minor version upgrades means in most cases (for the other
> OSS projects) that the upgrade contains only bug fixes.  But looking at
> kolab's current ChangeLog, much more has changed and some changes have a big
> impact.  With this mind I would like to mentioned the removal of the packages
> kolab-filter and kolab-freebusy from kolab cvs.  This means that packages
> will get totally different names (something horde-freebusy and filter, it
> will be I think).  Newpackage files have to be made by packagers for the next
> kolab version.  Further more files have been moved from kolabd to perl-kolab.
> Big changes have been made to horde.  Horde will be delivered as I believe 1
> big application instead of many seperate applications.  These are only a few
> of the many more changes that were made, and that were not bugs.
>
> Because of the reasons above I believe that it is justified to call the next
> kolab server release 2.3 and not 2.2.1.  What's your opinion about this?

There are indeed many packaging changes. And I understand that this  
affects all people porting Kolab to other distros as some packages  
need to be cleaned up.

But lets be honest: In terms of functionality there are not that many  
changes. Most of this is really just cleanup. The biggest part of  
converting the old code structures into something that is maintainable  
- at least in my eyes :) - is just structure and not content.

So even if I'm playing around wildly in both Kolab and Horde CVS there  
will be no big "wow" with Kolab-Server-2.2.1 and I think it makes  
sense calling it 2.2.1 :)

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/20081016/99ac9b7c/attachment.bin

From aspineux at gmail.com  Fri Oct 17 07:39:19 2008
From: aspineux at gmail.com (Alain Spineux)
Date: Fri, 17 Oct 2008 07:39:19 +0200
Subject: [Kolab-devel] RFC next kolab server version 2.3 and 2.2.1?
In-Reply-To: <20081016221658.15863vqjzym4angg@webmail.pardus.de>
References: <200810162138.19076.ml@radoeka.nl>
	<20081016221658.15863vqjzym4angg@webmail.pardus.de>
Message-ID: <71fe4e760810162239k1c328edbi8b43fbbc62dc0619@mail.gmail.com>

On Thu, Oct 16, 2008 at 10:16 PM, Gunnar Wrobel <wrobel at pardus.de> wrote:
> Hi Richard,
>
> Quoting Richard Bos <ml at radoeka.nl>:
>
>> Hi,
>>
>> I would like to discuss the version of the soon(?) to be released kolab
>> server.  At the moment one find on the roadmap page the following
>> information:
>>
>> "Release 2.2.1 is envisioned for Q4 2008 or earlier. It will have at least
>> one
>> release candidate before that. Planned improvements include adding the
>> SyncML
>> improvements to Horde."
>>
>> AFAIK 2.2.1 is the only known version that is being worked on, but with
>> the
>> many changes that have been made to kolab I believe that a version like
>> 2.2.1
>> is misleading.  A minor version upgrades means in most cases (for the
>> other
>> OSS projects) that the upgrade contains only bug fixes.  But looking at
>> kolab's current ChangeLog, much more has changed and some changes have a
>> big
>> impact.  With this mind I would like to mentioned the removal of the
>> packages
>> kolab-filter and kolab-freebusy from kolab cvs.  This means that packages
>> will get totally different names (something horde-freebusy and filter, it
>> will be I think).  Newpackage files have to be made by packagers for the
>> next
>> kolab version.  Further more files have been moved from kolabd to
>> perl-kolab.
>> Big changes have been made to horde.  Horde will be delivered as I believe
>> 1
>> big application instead of many seperate applications.  These are only a
>> few
>> of the many more changes that were made, and that were not bugs.
>>
>> Because of the reasons above I believe that it is justified to call the
>> next
>> kolab server release 2.3 and not 2.2.1.  What's your opinion about this?
>
> There are indeed many packaging changes. And I understand that this affects
> all people porting Kolab to other distros as some packages need to be
> cleaned up.
>
> But lets be honest: In terms of functionality there are not that many
> changes. Most of this is really just cleanup. The biggest part of converting
> the old code structures into something that is maintainable - at least in my
> eyes :) - is just structure and not content.
>
> So even if I'm playing around wildly in both Kolab and Horde CVS there will
> be no big "wow" with Kolab-Server-2.2.1 and I think it makes sense calling
> it 2.2.1 :)

Other questions to take care of :

- How the data format has changed ?
- How the interface/usage as changed ?

Regards

>
> 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.
>
> _______________________________________________
> 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 wrobel at pardus.de  Fri Oct 17 08:37:54 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 17 Oct 2008 08:37:54 +0200
Subject: [Kolab-devel] RFC next kolab server version 2.3 and 2.2.1?
In-Reply-To: <71fe4e760810162239k1c328edbi8b43fbbc62dc0619@mail.gmail.com>
References: <200810162138.19076.ml@radoeka.nl>
	<20081016221658.15863vqjzym4angg@webmail.pardus.de>
	<71fe4e760810162239k1c328edbi8b43fbbc62dc0619@mail.gmail.com>
Message-ID: <20081017083754.33715uhyt8ucyuko@webmail.pardus.de>

Quoting Alain Spineux <aspineux at gmail.com>:

> On Thu, Oct 16, 2008 at 10:16 PM, Gunnar Wrobel <wrobel at pardus.de> wrote:
>> Hi Richard,
>>
>> Quoting Richard Bos <ml at radoeka.nl>:
>>
>>> Hi,
>>>
>>> I would like to discuss the version of the soon(?) to be released kolab
>>> server.  At the moment one find on the roadmap page the following
>>> information:
>>>
>>> "Release 2.2.1 is envisioned for Q4 2008 or earlier. It will have at least
>>> one
>>> release candidate before that. Planned improvements include adding the
>>> SyncML
>>> improvements to Horde."
>>>
>>> AFAIK 2.2.1 is the only known version that is being worked on, but with
>>> the
>>> many changes that have been made to kolab I believe that a version like
>>> 2.2.1
>>> is misleading.  A minor version upgrades means in most cases (for the
>>> other
>>> OSS projects) that the upgrade contains only bug fixes.  But looking at
>>> kolab's current ChangeLog, much more has changed and some changes have a
>>> big
>>> impact.  With this mind I would like to mentioned the removal of the
>>> packages
>>> kolab-filter and kolab-freebusy from kolab cvs.  This means that packages
>>> will get totally different names (something horde-freebusy and filter, it
>>> will be I think).  Newpackage files have to be made by packagers for the
>>> next
>>> kolab version.  Further more files have been moved from kolabd to
>>> perl-kolab.
>>> Big changes have been made to horde.  Horde will be delivered as I believe
>>> 1
>>> big application instead of many seperate applications.  These are only a
>>> few
>>> of the many more changes that were made, and that were not bugs.
>>>
>>> Because of the reasons above I believe that it is justified to call the
>>> next
>>> kolab server release 2.3 and not 2.2.1.  What's your opinion about this?
>>
>> There are indeed many packaging changes. And I understand that this affects
>> all people porting Kolab to other distros as some packages need to be
>> cleaned up.
>>
>> But lets be honest: In terms of functionality there are not that many
>> changes. Most of this is really just cleanup. The biggest part of converting
>> the old code structures into something that is maintainable - at least in my
>> eyes :) - is just structure and not content.
>>
>> So even if I'm playing around wildly in both Kolab and Horde CVS there will
>> be no big "wow" with Kolab-Server-2.2.1 and I think it makes sense calling
>> it 2.2.1 :)
>
> Other questions to take care of :
>
> - How the data format has changed ?

No changes.

> - How the interface/usage as changed ?

No changes, with the exception of the Kolab web client (based on  
Horde). But in a way the web client is just another Kolab client and I  
don't see a strong relation to the Kolab-Server version number.

Cheers,

Gunnar

>
> Regards
>
>>
>> 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.
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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/20081017/0245d22c/attachment-0001.bin

From kolab-issues at intevation.de  Fri Oct 17 10:17:07 2008
From: kolab-issues at intevation.de (Mathieu Parent)
Date: Fri, 17 Oct 2008 08:17:07 +0000
Subject: [Kolab-devel] [issue3152] keep syncrepl cookie on disk between
	sessions
Message-ID: <1224231427.12.0.0221655736703.issue3152@intevation.de>


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

Current implementation of syncrepl LDAP backend make a full check on every start
of kolabd.

The cookie should be stored in a file to prevent this.

----------
assignedto: mathieu.parent
messages: 17162
nosy: mathieu.parent
priority: feature
status: unread
title: keep syncrepl cookie on disk between sessions
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3152>
___________________________________________________


From kolab-issues at intevation.de  Fri Oct 17 10:17:16 2008
From: kolab-issues at intevation.de (Mathieu Parent)
Date: Fri, 17 Oct 2008 08:17:16 +0000
Subject: [Kolab-devel] [issue3153] keep syncrepl cookie on disk between
	sessions
Message-ID: <1224231436.48.0.203703669798.issue3153@intevation.de>


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

Current implementation of syncrepl LDAP backend make a full check on every start
of kolabd.

The cookie should be stored in a file to prevent this.

----------
assignedto: mathieu.parent
messages: 17163
nosy: mathieu.parent
priority: feature
status: unread
title: keep syncrepl cookie on disk between sessions
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3153>
___________________________________________________


From kolab-issues at intevation.de  Fri Oct 17 10:20:11 2008
From: kolab-issues at intevation.de (Mathieu Parent)
Date: Fri, 17 Oct 2008 08:20:11 +0000
Subject: [Kolab-devel] [issue3154] Make syncrepl backend works in
	refreshAndPersist mode
Message-ID: <1224231611.33.0.508097723325.issue3154@intevation.de>


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

Current implementation of syncrepl LDAP backend doesn't work in
refreshAndPersistMode.


This will reduce a bit of bandwidth.

----------
assignedto: mathieu.parent
messages: 17164
nosy: mathieu.parent
priority: wish
status: unread
title: Make syncrepl backend works in refreshAndPersist mode
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3154>
___________________________________________________


From kolab-issues at intevation.de  Fri Oct 17 10:23:51 2008
From: kolab-issues at intevation.de (Mathieu Parent)
Date: Fri, 17 Oct 2008 08:23:51 +0000
Subject: [Kolab-devel] [issue3155] Reduce syncrepl overload
Message-ID: <1224231831.49.0.00327183046756.issue3155@intevation.de>


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

Current implementation of syncrepl rebuild everything if any change happen to
the directory .


This can be reduced by :
- watching only necessary objects (users, groups, kolab)
- triggering only necessary cyrus and kolabconf commands


Benefit :
- reduced bandwidth
- reduced cyrus load
- reduced kolabconf load

----------
assignedto: mathieu.parent
messages: 17165
nosy: mathieu.parent
priority: wish
status: unread
title: Reduce syncrepl overload
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3155>
___________________________________________________


From kolab-issues at intevation.de  Fri Oct 17 16:59:47 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Fri, 17 Oct 2008 14:59:47 +0000
Subject: [Kolab-devel] [issue3156] Kleopatra: error in dialog of kleopatra
	settings->s/mime validation (kcm_kleopatra.dll)
Message-ID: <1224255587.53.0.973617545633.issue3156@intevation.de>


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

Install Kowi 2008-10-17 (kdepimlibs: 872241, kdepim: 872258)
Install Gpg4win-1.9.8-beta

Start Kleopatra from Start menu (not from Kowi extras menu).
Open Kleopatra settings -> section smime checks.
-> Error:
"QLibrary::resolve_sys: Symbol "init_libkcm_kleopatra" ist nicht in
C:/Programme/Kontact/lib/kde4/kcm_kleopatra.dll definiert ..."

Maybe a problem of using "/" instead of "\"? kcm_kleopatra.dll exists.

----------
assignedto: till
messages: 17174
nosy: emanuel, till
priority: urgent
status: unread
title: Kleopatra: error in dialog of kleopatra settings->s/mime validation (kcm_kleopatra.dll)
topic: kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3156>
___________________________________________________


From kolab-issues at intevation.de  Fri Oct 17 17:26:29 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Fri, 17 Oct 2008 15:26:29 +0000
Subject: [Kolab-devel] [issue3157] [i18n] Kleopatra: English/German mix
Message-ID: <1224257189.48.0.306627623461.issue3157@intevation.de>


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

Install Kowi 2008-10-17 (kdepimlibs: 872241, kdepim: 872258)
Install Gpg4win-1.9.8-beta

Start Kleopatra.
Open certificate details of a selected certificate.
-> English/German mix

Seems to be a problem with Kowi. If installing gpg4win without kowi translations
are correct.

----------
assignedto: till
messages: 17175
nosy: emanuel, till
priority: bug
status: unread
title: [i18n] Kleopatra: English/German mix
topic: kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3157>
___________________________________________________


From bernhard at intevation.de  Fri Oct 17 17:32:04 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 17 Oct 2008 17:32:04 +0200
Subject: [Kolab-devel]
	=?utf-8?q?Samba_KEP_=28Re=3A_Enhancing_Kolab_decisi?=
	=?utf-8?q?on=09making_=28re=3A_Is_it_okay_to_commit_the_samba_patc?=
	=?utf-8?b?aCB0byBjdnM/KSk=?=
In-Reply-To: <20080919140517.11356dcw98cjnmo0@webmail.pardus.de>
References: <200809111755.13871.ml@radoeka.nl>
	<200809171054.55089.bernhard@intevation.de>
	<20080919140517.11356dcw98cjnmo0@webmail.pardus.de>
Message-ID: <200810171732.04772.bernhard@intevation.de>

On Freitag, 19. September 2008, Gunnar Wrobel wrote:
> Complete applications ?
> have completely different needs concerning the testing. You already ?
> mentioned that this has (or is) a problem with the Kolab Server web ?
> client which did not get the testing to make it rock solid in the ?
> current server version.
>
> Would a decision on such a KEP also be a community process? The ?
> testing would still be done by KK.

I consider a community process to be good. The Kolab Konsortium is one
part of the community, maybe a very important part and often driving
development and progress. Still we value the full community.

We can define criteria as a community to take up things,
one would be having a maintainer and a good perspective on the component in 
question.

> I believe we should just try to be more open to such extensions and ?
> provide some upload place or some other structures instead of going ?
> all KEPpy on extensions that provide new applications.

Well, we can do extensions out of the core as much as we want to.
Anybody can do this right away even without asking the Kolab development 
community. Again then comes the question: Shall we (as in the community) pick 
it up for the core?


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

From kolab-issues at intevation.de  Fri Oct 17 17:34:31 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Fri, 17 Oct 2008 15:34:31 +0000
Subject: [Kolab-devel] [issue3158] Error if try to add an attachment
Message-ID: <1224257671.12.0.253272112246.issue3158@intevation.de>


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

Installed: Kowi 2008-10-17 (kdepimlibs: 872241, kdepim: 872258)

Create a new mail.
Click attachment button.
-> Error "Windows Kein Datentr?ger" (see screenshot)

----------
assignedto: till
files: kowi-error-20081017-1.png
messages: 17176
nosy: emanuel, till
priority: urgent
status: unread
title: Error if try to add an attachment
topic: enterprise4, kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3158>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kowi-error-20081017-1.png
Type: image/png
Size: 22032 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081017/c2d6197a/kowi-error-20081017-1-0001.png

From kolab-issues at intevation.de  Fri Oct 17 17:39:10 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Fri, 17 Oct 2008 15:39:10 +0000
Subject: [Kolab-devel] [issue3159] Bad attachment default directory
Message-ID: <1224257949.87.0.733944872377.issue3159@intevation.de>


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

Installed: Kowi 2008-10-17 (kdepimlibs: 872241, kdepim: 872258)

Create a new mail.
Click attachment button.
-> bad default directory: C:\Programme\Kontact\translations

Maybe a follow-up error of kolab/issue3158.

----------
assignedto: till
messages: 17177
nosy: emanuel, till
priority: urgent
status: unread
title: Bad attachment default directory
topic: enterprise4, kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3159>
___________________________________________________


From ml at radoeka.nl  Fri Oct 17 17:42:14 2008
From: ml at radoeka.nl (Richard Bos)
Date: Fri, 17 Oct 2008 17:42:14 +0200
Subject: [Kolab-devel] RFC next kolab server version 2.3 and 2.2.1?
In-Reply-To: <20081016221658.15863vqjzym4angg@webmail.pardus.de>
References: <200810162138.19076.ml@radoeka.nl>
	<20081016221658.15863vqjzym4angg@webmail.pardus.de>
Message-ID: <200810171742.14935.ml@radoeka.nl>

Op Thursday 16 October 2008 22:16:58 schreef Gunnar Wrobel:
> But lets be honest: In terms of functionality there are not that many ?
> changes. Most of this is really just cleanup. The biggest part of ?
> converting the old code structures into something that is maintainable ?
> - at least in my eyes :) - is just structure and not content.
>
> So even if I'm playing around wildly in both Kolab and Horde CVS there ?
> will be no big "wow" with Kolab-Server-2.2.1 and I think it makes ?
> sense calling it 2.2.1 :)

Functionality wise, you're indeed correct that there are not major changes.  
But still a lot has changed.  It's not that one can do a cvs diff and find 
only a couple of lines changed, that can be directly pinpointed to an issue.  
From _that_ point of view it is just more than a minor release (+0.0.1).
It's also good to let people know that the new version has more than only bug 
fixes.  If one would rewrite a piece of software, there is probably less 
functionality but still it is a major upgrade (see e.g. kde-3.5.x vs kde-4.x.  
The latter has less functionality than the former).

With a version of 2.2.1 people may blindly upgrade, assuming hardly any 
changes were made.  With a 2.3 version number people will be more carefull.  
Looking it from a cvs point of view: 2.2.1 should be a branch from 2.2.0.  
2.3 is further on, on the trunk.   The latter is what is happening with 
kolab.

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


From bernhard at intevation.de  Fri Oct 17 17:42:51 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 17 Oct 2008 17:42:51 +0200
Subject: [Kolab-devel]
 =?iso-8859-15?q?CeBIT_Open_Source=3A_Linux_Magazine?=
 =?iso-8859-15?q?_and_Linux=09Foundation_Announce_Call_for_Projects_-_Linu?=
 =?iso-8859-15?q?x_Magazine_Online?=
In-Reply-To: <20081007100435.16941spyl170bqq8@webmail.pardus.de>
References: <200810012230.58439.ml@radoeka.nl>
	<20081007100435.16941spyl170bqq8@webmail.pardus.de>
Message-ID: <200810171742.54562.bernhard@intevation.de>

On Dienstag, 7. Oktober 2008, Gunnar Wrobel wrote:
> Quoting Richard Bos <ml at radoeka.nl>:
> > Is this something for the kolab project (including some of
> > the surrounding projects):
> > http://www.linux-magazine.com/online/news/cebit_open_source_linux_magazin
> >e_and_linux_foundation_announce_call_for_projects
>
> The Kolab Konsortium has traditionally been present at Cebit and ?
> expect this to be the case for the next one as well. 

We have not been there each time for CeBit 
(Probably a mixup with the Linuxtag).

> 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. 
Would there be lot of volunteers to represent Kolab?

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

From bernhard at intevation.de  Fri Oct 17 17:44:21 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 17 Oct 2008 17:44:21 +0200
Subject: [Kolab-devel] Kolab in the clouds
In-Reply-To: <20081014081347.27441bu8f5a6cfq8@webmail.pardus.de>
References: <20081014081347.27441bu8f5a6cfq8@webmail.pardus.de>
Message-ID: <200810171744.22064.bernhard@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. :)

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

From bernhard at intevation.de  Fri Oct 17 17:46:27 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 17 Oct 2008 17:46:27 +0200
Subject: [Kolab-devel] bernhard: doc/architecture freebusy.txt, 1.24,
	1.25
In-Reply-To: <20081014130941.GA77882@xs4all.nl>
References: <20081014125917.17C9D60016C@lists.intevation.de>
	<20081014130941.GA77882@xs4all.nl>
Message-ID: <200810171746.27788.bernhard@intevation.de>

On Dienstag, 14. Oktober 2008, Richard Bos wrote:
> On Tue, Oct 14, 2008 at 02:59:17PM +0200, cvs at kolab.org wrote:
> > +also constitute a "write operation" making a trigger recessary.
>
> Small typo "recessary" -> necessary...

Fixed with rev 1.26.
Thanks. 

ps.: You can directly commit fixes for things like this.


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

From bernhard at intevation.de  Fri Oct 17 17:49:53 2008
From: bernhard at intevation.de (Bernhard Reiter)
Date: Fri, 17 Oct 2008 17:49:53 +0200
Subject: [Kolab-devel] Intevation moved; working on communication pile
Message-ID: <200810171749.54195.bernhard@intevation.de>

Just as a heads-up:

The Intevation office (home of the official KK postal address) 
has succesfully moved a few weeks ago and I am now working to get 
out of the communication pile, which also comes out of the fact
that we are working very intensively on Kontact enterprise4 (for Windows, 
GNU/Linux and MacOSX). Beta pending this year, our internal packages
are all just too big to really get published.

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

From kolab-issues at intevation.de  Fri Oct 17 17:52:34 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Fri, 17 Oct 2008 15:52:34 +0000
Subject: [Kolab-devel] [issue3160] Encrypt mail: strange key check dialogs
Message-ID: <1224258754.21.0.357682471054.issue3160@intevation.de>


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

Installed Kowi 2008-10-17 (kdepimlibs: 872241, kdepim: 872258)
Installed Gpg4win-1.9.8-beta

Import an openpgp and a smime certificate for the same email address (A).

Send an encrypt mail to (A). Encryption format to "all".
Certificate choice dialog comes up, because more then one key matches to (A).
-> 4 strange dialogs with running progress bar come up (see screenshot). User
has to cancel all manually. After that: Certificate can selected. Encryption works.

----------
assignedto: till
files: kowi-encrypt-2008-10-17.png
messages: 17178
nosy: emanuel, till
priority: urgent
status: unread
title: Encrypt mail: strange key check dialogs
topic: enterprise4, kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3160>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kowi-encrypt-2008-10-17.png
Type: image/png
Size: 28575 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081017/d640ac4a/kowi-encrypt-2008-10-17-0001.png

From kolab-issues at intevation.de  Fri Oct 17 17:58:58 2008
From: kolab-issues at intevation.de (=?utf-8?q?Emanuel_Sch=C3=BCtze?=)
Date: Fri, 17 Oct 2008 15:58:58 +0000
Subject: [Kolab-devel] [issue3161] "Accept encryption key" window to small
Message-ID: <1224259138.53.0.582172308726.issue3161@intevation.de>


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

Installed: Kowi 2008-10-17 (kdepimlibs: 872241, kdepim: 872258)
Installed: Gpg4win-1.9.8-beta

Send an encrypted mail.
Accept encryption key dialog comes up. Window to small. Scroll bars
insufficient. Window not resizeable (see screenshot).

----------
assignedto: till
files: kowi-key-dialog-2009-10-17.png
messages: 17179
nosy: emanuel, till
priority: bug
status: unread
title: "Accept encryption key" window to small
topic: enterprise4, kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3161>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kowi-key-dialog-2009-10-17.png
Type: image/png
Size: 9857 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081017/6359466f/kowi-key-dialog-2009-10-17.png

From ml at radoeka.nl  Fri Oct 17 23:44:04 2008
From: ml at radoeka.nl (Richard Bos)
Date: Fri, 17 Oct 2008 23:44:04 +0200
Subject: [Kolab-devel]
 =?iso-8859-6?q?CeBIT_Open_Source=3A_Linux_Magazine_?=
 =?iso-8859-6?q?and_Linux=09Foundation_Announce_Call_for_Projects_-_Linux_?=
 =?iso-8859-6?q?Magazine_Online?=
In-Reply-To: <200810171742.54562.bernhard@intevation.de>
References: <200810012230.58439.ml@radoeka.nl>
	<20081007100435.16941spyl170bqq8@webmail.pardus.de>
	<200810171742.54562.bernhard@intevation.de>
Message-ID: <200810172344.04463.ml@radoeka.nl>

Hi Bernard,

Op Friday 17 October 2008 17:42:51 schreef Bernhard Reiter:
> > The Kolab Konsortium has traditionally been present at Cebit and ?
> > expect this to be the case for the next one as well.
>
> We have not been there each time for CeBit
> (Probably a mixup with the Linuxtag).

I remember :)

> > 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?  When the konsortium is there, is that not enough for 
kolab?  What could a community booth add to that (the konsortium)?


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


From kolab-issues at intevation.de  Sat Oct 18 07:48:16 2008
From: kolab-issues at intevation.de (Gunnar Wrobel)
Date: Sat, 18 Oct 2008 05:48:16 +0000
Subject: [Kolab-devel] [issue3162] Kolab Server 2.2 "operating manual" still
	lists "./install-kolab.sh -H -F" as installation method.
Message-ID: <1224308896.53.0.617573428629.issue3162@intevation.de>


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

Page 22 of
(http://kolab.org/doc/Allgemeine-Betriebsdokumentation-KolabServer22_20080103_1.0.pdf)
still lists the old version of the installation command and confuses users.

----------
assignedto: thomas
messages: 17189
nosy: bernhard, thomas, wilde, wrobel
priority: bug
status: unread
title: Kolab Server 2.2 "operating manual" still lists "./install-kolab.sh -H -F" as installation method.
topic: docs
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3162>
___________________________________________________


From martin.konold at erfrakon.de  Sat Oct 18 20:06:40 2008
From: martin.konold at erfrakon.de (Martin Konold)
Date: Sat, 18 Oct 2008 20:06:40 +0200
Subject: [Kolab-devel] RFC next kolab server version 2.3 and 2.2.1?
In-Reply-To: <200810171742.14935.ml@radoeka.nl>
References: <200810162138.19076.ml@radoeka.nl>
	<20081016221658.15863vqjzym4angg@webmail.pardus.de>
	<200810171742.14935.ml@radoeka.nl>
Message-ID: <200810182006.40672.martin.konold@erfrakon.de>

On Friday 17 October 2008 17:42:14 Richard Bos wrote:

Hi,

> With a version of 2.2.1 people may blindly upgrade, assuming hardly any
> changes were made. ?With a 2.3 version number people will be more carefull.
> ? Looking it from a cvs point of view: 2.2.1 should be a branch from 2.2.0.
> 2.3 is further on, on the trunk. ? The latter is what is happening with
> kolab.

I second Richards reasoning.

Yours,
-- martin

-- 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Sitz: Adolfstra?e 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126
http://www.erfrakon.com/


From ml at radoeka.nl  Sun Oct 19 11:09:30 2008
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 19 Oct 2008 11:09:30 +0200
Subject: [Kolab-devel] gunnar: server/perl-kolab/data quotawarning.txt,
	NONE, 1.1
In-Reply-To: <20081010142206.C1D15600BAF@lists.intevation.de>
References: <20081010142206.C1D15600BAF@lists.intevation.de>
Message-ID: <200810191109.30542.ml@radoeka.nl>

Op Friday 10 October 2008 16:22:06 schreef cvs at kolab.org:
> Author: gunnar
>
> Update of /kolabrepository/server/perl-kolab/data
> In directory doto:/tmp/cvs-serv20319/data
>
> Added Files:
> ????????quotawarning.txt
> Log Message:
> Merge all perl tools into the perl-kolab package.

I get this during the build:

make: *** No rule to make target `quotawarning.txt', needed by `all-am'.  
Stop.
error: Bad exit status from /var/tmp/rpm-tmp.28741 (%build)


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


From ml at radoeka.nl  Sun Oct 19 11:09:35 2008
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 19 Oct 2008 11:09:35 +0200
Subject: [Kolab-devel] gunnar: server/perl-kolab/bin kolab_bootstrap.in,
	NONE, 1.1 kolabcheckperm.in, NONE, 1.1 kolabconf.in, NONE,
	1.1 kolabdcachetool.in, NONE, 1.1 kolabd.in, NONE,
	1.1 kolabpasswd.in, NONE, 1.1 kolabquotareport.in, NONE,
	1.1 kolabquotawarn.in, NONE, 1.1 kolab_smtpdpolicy.in, NONE,
	1.1 kolab_upgrade.in, NONE, 1.1
In-Reply-To: <20081010142207.323F0600BAF@lists.intevation.de>
References: <20081010142207.323F0600BAF@lists.intevation.de>
Message-ID: <200810191109.36206.ml@radoeka.nl>

Hi,

Op Friday 10 October 2008 16:22:07 schreef cvs at kolab.org:
> Update of /kolabrepository/server/perl-kolab/bin
> In directory doto:/tmp/cvs-serv20319/bin
>
> Added Files:
> ????????kolab_bootstrap.in kolabcheckperm.in kolabconf.in
> ????????kolabdcachetool.in kolabd.in kolabpasswd.in
> ????????kolabquotareport.in kolabquotawarn.in kolab_smtpdpolicy.in
> ????????kolab_upgrade.in
> Log Message:
> Merge all perl tools into the perl-kolab package.

why did this happen?  Don't belong those tools/scripts whatever to the kolab 
server?  Why should e.g. kolab_bootstrap.in be part of perl-kolab and not of 
the kolab server package?  If kolab_bootstrap.in is going to be rewritten in 
bash, ruby, python, should it than be moved to respectively bash-kolab, 
ruby-kolab or python-kolab?

With all scripts removed from the kolab package, the latter is now almost an 
empty package...

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


From ml at radoeka.nl  Sun Oct 19 11:32:17 2008
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 19 Oct 2008 11:32:17 +0200
Subject: [Kolab-devel] gunnar: server/perl-kolab/data quotawarning.txt,
	NONE, 1.1
In-Reply-To: <200810191109.30542.ml@radoeka.nl>
References: <20081010142206.C1D15600BAF@lists.intevation.de>
	<200810191109.30542.ml@radoeka.nl>
Message-ID: <200810191132.17486.ml@radoeka.nl>

Op Sunday 19 October 2008 11:09:30 schreef Richard Bos:
> > Added Files:
> > ????????quotawarning.txt
> > Log Message:
> > Merge all perl tools into the perl-kolab package.
>
> I get this during the build:
>
> make: *** No rule to make target `quotawarning.txt', needed by `all-am'. ?
> Stop.
> error: Bad exit status from /var/tmp/rpm-tmp.28741 (%build)

The solution is simple:
kolabd> cvs diff Makefile.am
Index: Makefile.am
===================================================================
RCS file: /kolabrepository/server/kolabd/kolabd/Makefile.am,v
retrieving revision 1.46
diff -u -r1.46 Makefile.am
--- Makefile.am 10 Oct 2008 14:30:44 -0000      1.46
+++ Makefile.am 19 Oct 2008 09:30:31 -0000
@@ -24,8 +24,7 @@
 kolabspecialdir = $(kolabconfdir)
 kolabspecial_DATA = kolab.globals

-kolabconfig_FILES = rootDSE.ldif \
-       quotawarning.txt
+kolabconfig_FILES = rootDSE.ldif

But as I don't agree with the move of the kolabd files/tools/scripts to 
perl-kolab I leave it to someone else to commit the change.

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


From kolab-issues at intevation.de  Sun Oct 19 12:26:59 2008
From: kolab-issues at intevation.de (PEPSI BOTTLING =?iso-8859-1?b?Q09NUEFOWak=?=)
Date: Sun, 19 Oct 2008 10:26:59 +0000
Subject: [Kolab-devel] [issue3163] WINNING NOTIFICATION..
Message-ID: <1224412002.48fb0b62b0ff7@pegasus.cc.ucf.edu>


New submission from PEPSI BOTTLING =?iso-8859-1?b?Q09NUEFOWak=?= <info at pepsipromo.com>:

FROM: THE PROMOTIONS DIRECTOR
INTERNATIONAL PROMOTIONS DEPT

PEPSI BOTTLING COMPANY?
2 Bedford Row London,
DX LDE 17 WC1R 4BU
United Kingdom.

Congratulations winner.

This is to inform you that your email has won a prize money of
One Million Great Britain Pound Sterlings(?1,000,000.00)
for the month October 2008 Online promotion which is organized by
PEPSI BOTTLING COMPANY

To claim your winning prize you are to send the following information
about your self to the claims manager for verification & direction.

1.FULL NAMES :_______________
2.CONTACT ADDRESS_____________
3.AGE:_____
4.TELEPHONE NUMBER:__________
5.SEX:__________
6.OCCUPATION:_____________
7.NATIONALITY:_______________
8.COUNTRY:________________________
9.I____________________________ hereby declare that the
aboveinformation is true and binding on me. If at any time it is
discoveredthat I have given false information, I will forfeit my rights
to my
winnings.

Contac US now for your Claims
E-mail:claimsurprize-pepsicola at hotmail.com
Dean Winchester(MR).
(PROCESSING MANAGER).
congratulations once again!.

Pepsi Online Co-ordinator
Miss Lisa Spark.
?2008 pepsibottlingcompany.com All rights reserved.

----------
messages: 17197
nosy: info5
status: unread
title: WINNING NOTIFICATION..
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3163>
___________________________________________________


From kolab-issues at intevation.de  Mon Oct 20 17:15:41 2008
From: kolab-issues at intevation.de (Saim Kim)
Date: Mon, 20 Oct 2008 15:15:41 +0000
Subject: [Kolab-devel] [issue3166] ClamAV clutters up space in
	/kolab/share/clamav
Message-ID: <1224515741.53.0.805087044535.issue3166@intevation.de>


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

Hello,

today my kolab 2.2 system stopped working: Every time a new appointment was
created a user would receive an IMAP error stating that the server is out of
memory. A quick check showed, that the harddisk was at the limit. The reason was
the /kolab/share/clamav folder. It was filled with almost 40 GB of data named
"clamav-alphanumericnumbers" of a size between 4 kB and 4 MB. It seems that
everytime freshclam updates the virus db, it forgets to clean up -slowly filling
the harddisk.

A quick answer from the clamav mailinglist was to just delete those files since
freshclam would download the files it needs during the automatic update check.
This helped me to solve the problem. Nevertheless, this seems to be a bug to me.

Best regards,
Saim

----------
messages: 17209
nosy: sojakim
priority: bug
status: unread
title: ClamAV clutters up space in /kolab/share/clamav
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3166>
___________________________________________________


From akopciuch at bddf.ca  Mon Oct 20 17:38:53 2008
From: akopciuch at bddf.ca (Andrew J. Kopciuch)
Date: Mon, 20 Oct 2008 09:38:53 -0600
Subject: [Kolab-devel] [issue3166] ClamAV clutters up space in
	/kolab/share/clamav
In-Reply-To: <1224515741.53.0.805087044535.issue3166@intevation.de>
References: <1224515741.53.0.805087044535.issue3166@intevation.de>
Message-ID: <200810200938.56743.akopciuch@bddf.ca>

On October 20, 2008, Saim Kim wrote:
> New submission from Saim Kim <s.kim at hia.rwth-aachen.de>:
>
> Hello,
>
> today my kolab 2.2 system stopped working: Every time a new appointment was
> created a user would receive an IMAP error stating that the server is out
> of memory. A quick check showed, that the harddisk was at the limit. The
> reason was the /kolab/share/clamav folder. It was filled with almost 40 GB
> of data named "clamav-alphanumericnumbers" of a size between 4 kB and 4 MB.
> It seems that everytime freshclam updates the virus db, it forgets to clean
> up -slowly filling the harddisk.
>
> A quick answer from the clamav mailinglist was to just delete those files
> since freshclam would download the files it needs during the automatic
> update check. This helped me to solve the problem. Nevertheless, this seems
> to be a bug to me.
>
> Best regards,
> Saim

This is not happening on openPKG installations I checked.  What kind of 
installation did you do?  OpenSUSE?  Debian?



Andy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081020/1da75021/attachment.bin

From ml at radoeka.nl  Mon Oct 20 19:11:14 2008
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 20 Oct 2008 19:11:14 +0200
Subject: [Kolab-devel] [issue3166] ClamAV clutters up space in
	/kolab/share/clamav
In-Reply-To: <200810200938.56743.akopciuch@bddf.ca>
References: <1224515741.53.0.805087044535.issue3166@intevation.de>
	<200810200938.56743.akopciuch@bddf.ca>
Message-ID: <200810201911.14887.ml@radoeka.nl>

Op Monday 20 October 2008 17:38:53 schreef Andrew J. Kopciuch:
> On October 20, 2008, Saim Kim wrote:
> > New submission from Saim Kim <s.kim at hia.rwth-aachen.de>:
> >
> > Hello,
> >
> > today my kolab 2.2 system stopped working: Every time a new appointment
> > was created a user would receive an IMAP error stating that the server is
> > out of memory. A quick check showed, that the harddisk was at the limit.
> > The reason was the /kolab/share/clamav folder. It was filled with almost
> > 40 GB of data named "clamav-alphanumericnumbers" of a size between 4 kB
> > and 4 MB. It seems that everytime freshclam updates the virus db, it
> > forgets to clean up -slowly filling the harddisk.
> >
> > A quick answer from the clamav mailinglist was to just delete those files
> > since freshclam would download the files it needs during the automatic
> > update check. This helped me to solve the problem. Nevertheless, this
> > seems to be a bug to me.
> >
> > Best regards,
> > Saim
>
> This is not happening on openPKG installations I checked.  What kind of
> installation did you do?  OpenSUSE?  Debian?

Looks like openpkg to me as his clamav files are stored at: 
 /kolab/share/clamav


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


From kolab-issues at intevation.de  Tue Oct 21 10:05:24 2008
From: kolab-issues at intevation.de (angelavanpoort)
Date: Tue, 21 Oct 2008 08:05:24 +0000
Subject: [Kolab-devel] [issue3168] CONFIRMATION Ticket No:BLN/AB1985
Message-ID: <K92WNV$BCCA0D21E48B02257A355483A707EB84@libero.it>


New submission from angelavanpoort <angelavanpoort at libero.it>:

CONFIRMATION Ticket No:BLN/AB1985

You have won ?1,000,000.00  (One Million Euros Only) in the Krasloten Lottery E-mail electronic On-line Sweepstakes Program Corporation, held on the 20th of October 2008. We write to officially notify you of this award and to advise you to contact the processing office immediately for the claim,

Winning Information's

Mr. Peter Van Moore
Claims Processing Manager)
Tel: +31-623-248-379
Reply Emails: petervanmoore at aim.com

(1) Batch No: BLN/1611/899 (2) Ticket No:BLN/AB1985
(3) Lucky No:  QBL/13977 (4) Serial No: SWNL/65201
(5) Ref No: SWBDZ/1171

Congratulations!!!

Mrs. Angela Van Poort

----------
messages: 17233
nosy: angelavanpoort
status: unread
title: CONFIRMATION Ticket No:BLN/AB1985
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3168>
___________________________________________________


From wrobel at pardus.de  Tue Oct 21 11:10:32 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 21 Oct 2008 11:10:32 +0200
Subject: [Kolab-devel] Kolab in the clouds
In-Reply-To: <200810171744.22064.bernhard@intevation.de>
References: <20081014081347.27441bu8f5a6cfq8@webmail.pardus.de>
	<200810171744.22064.bernhard@intevation.de>
Message-ID: <20081021111032.13843cl51kv1wayo@webmail.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.

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.


From wrobel at pardus.de  Tue Oct 21 11:17:24 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 21 Oct 2008 11:17:24 +0200
Subject: [Kolab-devel] Horde/mimp
In-Reply-To: <48F6307D.4040204@gelpi.it>
References: <48F6307D.4040204@gelpi.it>
Message-ID: <20081021111724.15433rbmhpkwssao@webmail.pardus.de>

Quoting Gelpi Andrea <liste at gelpi.it>:

> Hi,
> 	I have a kolab server 2.2.0 and I noticed that accessing horde via  
> mobile phone, after a
> successful login I get 404 error for mimp pages not found.
> So I suppose mimp is active in horde configuration.
>
> I tried to add mimp to my installation.
>
> I downloaded mimp-h3-1.1.tar.gz, untar it and copied it under  
> /kolab/var/kolab/www/horde
>
> I copied *.dist file into *.php in mimp/config
>
> I set kolab as owner and group to all files in horde/mimp
>
> AThen I login to horde as administrator an I generated the conf.php  
> file for mimp.
>
> Now I can login in mimp, send messages, change folder and see the  
> list of messages.
>
> But if I open a message to read it I get a blank page.
>
> In /kolab/var/apache/log/php/php-errors.log I found these lines:
>
> [15-ott-2008 19:45:41] PHP Warning:
> require_once(/kolab/var/kolab/www/horde/config/../imp/lib/IMAP/MessageCache.php)  
> [<a
> href='function.require-once'>function.require-once</a>]: failed to  
> open stream: No such file or
> directory in /kolab/var/kolab/www/horde/mimp/message.php on line 80
> [15-ott-2008 19:45:41] PHP Fatal error:  require_once() [<a
> href='function.require'>function.require</a>]: Failed opening required
> '/kolab/var/kolab/www/horde/config/../imp/lib/IMAP/MessageCache.php'
> (include_path='/kolab/var/kolab/www/horde/lib:.:/kolab/lib/php:/kolab/var/kolab/php:/kolab/var/kolab/php/pear')
> in /kolab/var/kolab/www/horde/mimp/message.php on line 80
>
> Any hints?

I guess you'd need to update IMP to the newest version as well. But I  
did not do an in-depth analysis. You could check Horde CVS to see when  
the missing file was added and which imp version should contain it.

Cheers,

Gunnar

>
> --
> ing. Andrea Gelpi
> ***************************************************
> La Terra non la abbiamo ereditata dai nostri avi,
> ma la abbiamo presa in prestito dai nostri bambini.
> ***************************************************
> We do not inherit the Earth from our parents,
> but borrow it from our children.
> ***************************************************
>
> _______________________________________________
> 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/20081021/237dd725/attachment.bin

From wrobel at pardus.de  Tue Oct 21 11:21:56 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 21 Oct 2008 11:21:56 +0200
Subject: [Kolab-devel] RFC next kolab server version 2.3 and 2.2.1?
In-Reply-To: <200810171742.14935.ml@radoeka.nl>
References: <200810162138.19076.ml@radoeka.nl>
	<20081016221658.15863vqjzym4angg@webmail.pardus.de>
	<200810171742.14935.ml@radoeka.nl>
Message-ID: <20081021112156.21125krngpa1x1k4@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Op Thursday 16 October 2008 22:16:58 schreef Gunnar Wrobel:
>> But lets be honest: In terms of functionality there are not that  
>> many  changes. Most of this is really just cleanup. The biggest  
>> part of  converting the old code structures into something that is  
>> maintainable  - at least in my eyes :) - is just structure and not  
>> content.
>>
>> So even if I'm playing around wildly in both Kolab and Horde CVS  
>> there  will be no big "wow" with Kolab-Server-2.2.1 and I think it  
>> makes  sense calling it 2.2.1 :)
>
> Functionality wise, you're indeed correct that there are not major changes.
> But still a lot has changed.  It's not that one can do a cvs diff and find
> only a couple of lines changed, that can be directly pinpointed to an issue.
> From _that_ point of view it is just more than a minor release (+0.0.1).
> It's also good to let people know that the new version has more than only bug
> fixes.  If one would rewrite a piece of software, there is probably less
> functionality but still it is a major upgrade (see e.g. kde-3.5.x vs kde-4.x.
> The latter has less functionality than the former).
>
> With a version of 2.2.1 people may blindly upgrade, assuming hardly any
> changes were made.  With a 2.3 version number people will be more carefull.
> Looking it from a cvs point of view: 2.2.1 should be a branch from 2.2.0.
> 2.3 is further on, on the trunk.   The latter is what is happening with
> kolab.

Yes, you convinced me, too.

2.3 would be better. Bernhard, Thomas?

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/20081021/30bb0644/attachment-0001.bin

From wrobel at pardus.de  Tue Oct 21 11:48:05 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 21 Oct 2008 11:48:05 +0200
Subject: [Kolab-devel] gunnar: server/perl-kolab/bin	kolab_bootstrap.in,
	NONE, 1.1 kolabcheckperm.in, NONE, 1.1 kolabconf.in, NONE,
	1.1 kolabdcachetool.in, NONE, 1.1 kolabd.in, NONE,
	1.1	kolabpasswd.in, NONE, 1.1 kolabquotareport.in, NONE,
	1.1 kolabquotawarn.in, NONE, 1.1 kolab_smtpdpolicy.in, NONE,
	1.1 kolab_upgrade.in, NONE, 1.1
In-Reply-To: <200810191109.36206.ml@radoeka.nl>
References: <20081010142207.323F0600BAF@lists.intevation.de>
	<200810191109.36206.ml@radoeka.nl>
Message-ID: <20081021114805.12311a3l6as00n6g@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Hi,
>
> Op Friday 10 October 2008 16:22:07 schreef cvs at kolab.org:
>> Update of /kolabrepository/server/perl-kolab/bin
>> In directory doto:/tmp/cvs-serv20319/bin
>>
>> Added Files:
>>         kolab_bootstrap.in kolabcheckperm.in kolabconf.in
>>         kolabdcachetool.in kolabd.in kolabpasswd.in
>>         kolabquotareport.in kolabquotawarn.in kolab_smtpdpolicy.in
>>         kolab_upgrade.in
>> Log Message:
>> Merge all perl tools into the perl-kolab package.
>
> why did this happen?  Don't belong those tools/scripts whatever to the kolab
> server?

The Kolab Server is a set of many different packages. It requires  
postfix, cyrus but also perl-kolab, kolabfilter and kolabfreebusy.

You are referring to the kolabd package. What did and does the package  
deliver?

  - bash scripts
  - perl scripts
  - configuration templates
  - amavisd templates

Especially the scripts are a wild assortment of different  
functionality that "do something for the server".

I consider it essential in packaging to use the language specific  
packaging tools. This would be PEAR for php, MakeMaker for Perl,  
distutils for python and gem for Ruby.

So the change was not at all about perl-kolab but in fact about  
cleaning up the kolabd package. We need to get rid of the distconf  
approach in the long run and this has been just another commit on the  
road to that goal.

I wouldn't mind if we place these perl scripts into a seperate perl  
package (maybe "perl-kolab-scripts") if you consider that more  
appropriate. I only moved all that stuff into perl-kolab and also  
collapsed kolabconf into perl-kolab for convenience.

The very critical part about the change was the use of MakeMaker (or  
Makefile.PL) which I consider essential. The scripts don't use the  
dist_conf approach any longer but use the Kolab configuration files  
which is how they should work.

> Why should e.g. kolab_bootstrap.in be part of perl-kolab and not of
> the kolab server package?  If kolab_bootstrap.in is going to be rewritten in
> bash, ruby, python, should it than be moved to respectively bash-kolab,
> ruby-kolab or python-kolab?

Not at all. From a packaging perspective I wouldn't mind if we get  
packages such as kolabconf (which I collapsed into perl-kolab now),  
kolabbootstrap, kolabd-daemon and so on. But this is usually not the  
way things are handled on OpenPKG. In most cases packages bundle  
different type of funtionality.

Cheers,

Gunnar

>
> With all scripts removed from the kolab package, the latter is now almost an
> empty package...
>
> --
> 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/20081021/e8d6d37f/attachment.bin

From bernhard.reiter at intevation.de  Tue Oct 21 11:49:05 2008
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Tue, 21 Oct 2008 11:49:05 +0200
Subject: [Kolab-devel] RFC next kolab server version 2.3 and 2.2.1?
In-Reply-To: <20081021112156.21125krngpa1x1k4@webmail.pardus.de>
References: <200810162138.19076.ml@radoeka.nl>
	<200810171742.14935.ml@radoeka.nl>
	<20081021112156.21125krngpa1x1k4@webmail.pardus.de>
Message-ID: <200810211149.08945.bernhard.reiter@intevation.de>

On Dienstag, 21. Oktober 2008, Gunnar Wrobel wrote:
> > With a version of 2.2.1 people may blindly upgrade, assuming hardly any
> > changes were made. 

On the roadmap are only minor changes from the users 
(aka Kolab Server Admin) perspective.

> > With a 2.3 version number people will be more 
> > carefull. Looking it from a cvs point of view: 2.2.1 should be a branch
> > from 2.2.0. 2.3 is further on, on the trunk. ? The latter is what is
> > happening with kolab.
>
> Yes, you convinced me, too.
>
> 2.3 would be better. Bernhard, Thomas?

Ideally 2.2.1 would just go in very smoothly on an update
and this is the version I hope we get which would also warrent that
particular version number.

Regards,
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: 197 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081021/aa28805a/attachment.bin

From wrobel at pardus.de  Tue Oct 21 11:49:36 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 21 Oct 2008 11:49:36 +0200
Subject: [Kolab-devel] gunnar: server/perl-kolab/bin	kolab_bootstrap.in,
	NONE, 1.1 kolabcheckperm.in, NONE, 1.1 kolabconf.in, NONE,
	1.1 kolabdcachetool.in, NONE, 1.1 kolabd.in, NONE,
	1.1	kolabpasswd.in, NONE, 1.1 kolabquotareport.in, NONE,
	1.1 kolabquotawarn.in, NONE, 1.1 kolab_smtpdpolicy.in, NONE,
	1.1 kolab_upgrade.in, NONE, 1.1
In-Reply-To: <200810191109.36206.ml@radoeka.nl>
References: <20081010142207.323F0600BAF@lists.intevation.de>
	<200810191109.36206.ml@radoeka.nl>
Message-ID: <20081021114936.20782r8o1nfhwj40@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Hi,
>
> Op Friday 10 October 2008 16:22:07 schreef cvs at kolab.org:
>> Update of /kolabrepository/server/perl-kolab/bin
>> In directory doto:/tmp/cvs-serv20319/bin
>>
>> Added Files:
>>         kolab_bootstrap.in kolabcheckperm.in kolabconf.in
>>         kolabdcachetool.in kolabd.in kolabpasswd.in
>>         kolabquotareport.in kolabquotawarn.in kolab_smtpdpolicy.in
>>         kolab_upgrade.in
>> Log Message:
>> Merge all perl tools into the perl-kolab package.
>
> why did this happen?  Don't belong those tools/scripts whatever to the kolab
> server?  Why should e.g. kolab_bootstrap.in be part of perl-kolab and not of
> the kolab server package?  If kolab_bootstrap.in is going to be rewritten in
> bash, ruby, python, should it than be moved to respectively bash-kolab,
> ruby-kolab or python-kolab?
>
> With all scripts removed from the kolab package, the latter is now almost an
> empty package...

Forget to comment this on the other mail:

This is indeed the goal. The package should only retain the templates.

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/20081021/e4fcc01b/attachment.bin

From kolab-issues at intevation.de  Tue Oct 21 12:29:53 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Tue, 21 Oct 2008 10:29:53 +0000
Subject: [Kolab-devel] [issue3169] No writable resource found if kontact is
	started the first time after a kolabwizard configuration
Message-ID: <1224584993.51.0.669804962126.issue3169@intevation.de>


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

enterprise4 windows
Kontact-Installer_20081017.exe (kdepimlibs: 872241, kdepim: 872258)
Test:
Needed a fresh .kde dir.
1.Use kolabwizard to configure an account.
2.Start kontact
3.switch to kmail and sync twice,
4.switch to the calendar and try to create an new event.

Notice: Now a 
"No writable Resource found" error is shown and it is not possible to save the
event.

----------
assignedto: till
messages: 17241
nosy: bh, ludwig, till
priority: bug
status: unread
title: No writable resource found if kontact is started the first time after a kolabwizard configuration
topic: enterprise4, kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3169>
___________________________________________________


From kolab-issues at intevation.de  Tue Oct 21 14:00:36 2008
From: kolab-issues at intevation.de (T. Ribbrock)
Date: Tue, 21 Oct 2008 12:00:36 +0000
Subject: [Kolab-devel] [issue3170] Invitation via server side distribution
	list leads to confusing mails
Message-ID: <1224590436.53.0.376709646783.issue3170@intevation.de>


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

Situation:

- An organizer O invites a server side distribution list SDL with two members A
and B.
- A accepts and selects his correct identity.
- O gets a mail confirming A's acceptance. Upon entering this into his calendar,
het gets another dialog box stating that an attendee (A) has requested to
particiate in the event despite not being invited. Technically, this is true, as
SDL was invited and not A or B.
- O accepts the "extra" attendee
- As a result, both A and B (in fact, the whole SDL) receive mails stating that
the event has been updated. This mail is extremely confusing as:

1) To start with, the mail does state "This meeting has been updated", however,
the mail *looks* like an ordinary invitation, i.e. with all the controls like
"Accept", "Accept cond." etc. There is also a control "Enter this into my
calendar" (which is not part of a standard invitation), but a casual observer
will most likely not notice the difference. For example A will wonder why he is
getting another invitation - he just accepted one for the same meeting, after all...

2) It does not state what has been updated, so neither A nor B have the
slightest idea why they are getting this mail (time/place/etc. have not changed,
after all)

3) Even if the mail would contain a statement like "User A has been added to the
event", it would still be confusing, as A was already part of SDL in the first
place.

Especially (1) frequently spooks users at our company, despite having explained
this effect - I've been asked several times "Why am I getting X invitations for
the same event???"

I can imagine that (3) is difficult to fix, but I thing as the minimum, the
mails generated by this chain of events should a) very clearly state what has
been updated and b) not have the same controls as an ordinary invitation (i.e.
only "Enter this into my calendar").

To add to the confusion, if A accepts the "second invitation", O gets a second
confirmation mail...

This was observed with Kolab 2.1 and several enterprise35 Kontact clients,
hence, I'm not entirely certain about the correct "Topic" in this case.

----------
messages: 17245
nosy: itsef_admin
priority: bug
status: unread
title: Invitation via server side distribution list leads to confusing mails
topic: enterprise35, kde client, kolab-2.1
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3170>
___________________________________________________


From kolab-issues at intevation.de  Tue Oct 21 15:03:30 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Tue, 21 Oct 2008 13:03:30 +0000
Subject: [Kolab-devel] [issue3171] KWallet appears only in the background
Message-ID: <1224594209.94.0.568308098606.issue3171@intevation.de>


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

tested with enterprise4 windows
Kontact-Installer_20081017.exe (kdepimlibs: 872241, kdepim: 872258)

Test:
1. Start kontact, switch to kmail
2. Create a new mail
=> a server password dialog pops up.
3. Enter password and check "Save password" checkbox.
Notice: A kwallet appears in the background.

Excepted: The kwallet dialog should appear in the foreground,

----------
assignedto: till
messages: 17249
nosy: bh, ludwig, till
priority: minor bug
status: unread
title: KWallet appears only in the background
topic: enterprise4, kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3171>
___________________________________________________


From kolab-issues at intevation.de  Tue Oct 21 15:03:53 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Tue, 21 Oct 2008 13:03:53 +0000
Subject: [Kolab-devel] [issue3172] Shortcut for folder sync (default F5)
	does not work.
Message-ID: <1224594233.8.0.68265560608.issue3172@intevation.de>


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

Kontact Version 1.3 (enterprise4 0.20081017.872576) Windows.
kdepim-branch Revision 873857.
kdepimlibs-branch Revision 873968.
kdelibs last Changed Rev 871812.
Qt 4.4.3

Pressing F5 on a folder does not work.
It should sync just this folder.

DebugView says something like: 
Warning:QAction::eventFilter: Ambigous shortcut overload: F5

----------
assignedto: till
messages: 17250
nosy: bernhard, ludwig, till
priority: minor bug
status: unread
title: Shortcut for folder sync (default F5) does not work.
topic: kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3172>
___________________________________________________


From kolab-issues at intevation.de  Tue Oct 21 18:08:17 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Tue, 21 Oct 2008 16:08:17 +0000
Subject: [Kolab-devel] [issue3173] Broken task objects written
Message-ID: <1224605297.78.0.290787520688.issue3173@intevation.de>


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

Kontact Version 1.3 (enterprise4 0.20081017.872576)
Qt 4.4.3 on Windows

Prerequisite for this analysis: disable "hide groupware folders"
in the configuration.

Start with an empty task folder (e.g. called "Aufgaben"), switch
to task view and create a new task. Now switch to the email view
and look up the raw format of the email. You can already
see missleading entries in <creation-time>, e.g. "ZZ" at the end
of the datetime string.

Now go back to the task view and add start time (go one day back) and due time 
(go one day forward), press okay. Check again the raw format, now
much more fields are broken, here is an excerpt how it looks to me:


<?xml version="1.0" encoding="UTF-8"?>
<task version="1.0" >
 <product-id>KOrganizer 4.1 (enterprise4 0.20081017.872576), Kolab 
resource</product-id>
 <uid>libkcal-19272.583</uid>
 <body>&lt;!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 
4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
&lt;html>&lt;head>&lt;meta name="qrichtext" content="1" />&lt;style 
type="text/css">
p, li { white-space: pre-wrap; }
&lt;/style>&lt;/head>&lt;body style=" font-family:'Sans Serif'; font-
size:10pt; font-weight:400; font-style:normal;">
&lt;p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; 
margin-left:0px; margin-right:0px; -qt-block-indent:0; text-
indent:0px;">&lt;/p>&lt;/body>&lt;/html></body>
 <creation-date>2008-10-21T15:58:40.468ZZ</creation-date>
 <last-modification-date>2008-10-21T15:59:28+00:00Z</last-modification-date>
 <sensitivity>public</sensitivity>
 <start-date>2008-10-20T17:59:00ZZ</start-date>
 <summary>task001</summary>
 <organizer>
  <display-name>Bernhard Test2 Reiter</display-name>
  <smtp-address>bernhardtest2.reiter at demo.example.org</smtp-address>
 </organizer>
 <revision>0</revision>
 <priority>0</priority>
 <completed>0</completed>
 <status>not-started</status>
 <due-date>2008-10-22T17:59:00ZZ</due-date>
</task>

----------
assignedto: till
messages: 17257
nosy: bernhard, ludwig, till, vkrause
priority: critical
status: unread
title: Broken task objects written
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3173>
___________________________________________________


From kolab-issues at intevation.de  Tue Oct 21 18:48:40 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Tue, 21 Oct 2008 16:48:40 +0000
Subject: [Kolab-devel] [issue3174] Invalid Address specified to RtlFreeHeap
Message-ID: <1224607720.19.0.787286602989.issue3174@intevation.de>


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

When running in gdb under windows, I sometimes get a few traps
like the following. Till said I should put it in an issue to Marc.
After three continues it really continues.

Version is Kontact
Version 1.3 (enterprise4 0.20081017.872576) on Windows.

GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".

warning: HEAP[kontact.exe]:
warning: Invalid Address specified to RtlFreeHeap( 0FB10000, 1BB491CC )


Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c91120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0  0x7c91120f in ntdll!DbgUiConnectToDbg ()
   from C:\WINDOWS\system32\ntdll.dll
#1  0x7c97c201 in ntdll!RtlpNtMakeTemporaryKey ()
   from C:\WINDOWS\system32\ntdll.dll
#2  0x7c97c63e in ntdll!RtlpNtMakeTemporaryKey ()
   from C:\WINDOWS\system32\ntdll.dll
#3  0x7c97d826 in ntdll!RtlpNtMakeTemporaryKey ()
   from C:\WINDOWS\system32\ntdll.dll
#4  0x7c959e1c in ntdll!LdrFindEntryForAddress ()
   from C:\WINDOWS\system32\ntdll.dll
#5  0x0fb10000 in ?? ()
#6  0x50000061 in ?? ()
#7  0x1bb491cc in guard variable for std::money_put<char, 
std::ostreambuf_iterat
or<char, std::char_traits<char> > >::id ()
   from c:\kowi-devel\kderoot-6\bin\libgpgme++.dll
#8  0x0fb10000 in ?? ()
#9  0x1bb491cc in guard variable for std::money_put<char, 
std::ostreambuf_iterat
or<char, std::char_traits<char> > >::id ()
   from c:\kowi-devel\kderoot-6\bin\libgpgme++.dll
#10 0x40000060 in ?? ()
#11 0x1a943678 in check_exception_spec ()
    at C:/kowi-devel/kderoot-6/include/Qt3Support/q3ptrcollection.h:57
#12 0x7c937553 in ntdll!RtlPcToFileHeader ()
   from C:\WINDOWS\system32\ntdll.dll
#13 0x77bfc2de in msvcrt!free () from C:\WINDOWS\system32\msvcrt.dll
#14 0x0fb10000 in ?? ()
#15 0x00000000 in ?? ()
(gdb) c
Continuing.
warning: HEAP[kontact.exe]:
warning: Invalid Address specified to RtlFreeHeap( 0FB10000, 1BB491CC )


Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c91120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
(gdb) c
Continuing.
warning: HEAP[kontact.exe]:
warning: Invalid Address specified to RtlFreeHeap( 0FB10000, 1BB491CC )


Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c91120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
(gdb) c
Continuing.
warning: HEAP[kontact.exe]:
warning: Invalid Address specified to RtlFreeHeap( 0FB10000, 1BB491CC )


Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c91120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
(gdb) c
Continuing.

----------
assignedto: marc
messages: 17260
nosy: bernhard, marc, till
priority: minor bug
status: unread
title: Invalid Address specified to RtlFreeHeap
topic: kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3174>
___________________________________________________


From ml at radoeka.nl  Tue Oct 21 20:46:55 2008
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 21 Oct 2008 20:46:55 +0200
Subject: [Kolab-devel] RFC next kolab server version 2.3 and 2.2.1?
In-Reply-To: <200810211149.08945.bernhard.reiter@intevation.de>
References: <200810162138.19076.ml@radoeka.nl>
	<20081021112156.21125krngpa1x1k4@webmail.pardus.de>
	<200810211149.08945.bernhard.reiter@intevation.de>
Message-ID: <200810212046.56305.ml@radoeka.nl>

Bernard,

Op Tuesday 21 October 2008 11:49:05 schreef Bernhard Reiter:
> On Dienstag, 21. Oktober 2008, Gunnar Wrobel wrote:
> > > With a version of 2.2.1 people may blindly upgrade, assuming hardly any
> > > changes were made.
>
> On the roadmap are only minor changes from the users
> (aka Kolab Server Admin) perspective.
>
> > > With a 2.3 version number people will be more
> > > carefull. Looking it from a cvs point of view: 2.2.1 should be a branch
> > > from 2.2.0. 2.3 is further on, on the trunk. ? The latter is what is
> > > happening with kolab.
> >
> > Yes, you convinced me, too.
> >
> > 2.3 would be better. Bernhard, Thomas?
>
> Ideally 2.2.1 would just go in very smoothly on an update
> and this is the version I hope we get which would also warrent that
> particular version number.

Forget the Ideally word in your sentence above.  The current situation is 
quite messy.  At the moment I can't do a testbuild for openSUSE at all 
because I have no idea what I need to package, as I have no idea what has 
been moved and to which module it has been moved.  That very much 
contradicts "go in very smoothly on an update" above.
I understood that with the current situation the kolabconf package has been 
integrated in the perl-kolab package.  This means that on package level a 
whole package is gone, and special rules have to be added the perl-kolab 
package to obsoletes the kolabconf package.  That is only one example, 
besides the many others I have given before.

Hence I believe that with the current state of affairs the roadmap has to be 
updated with a 2.3 version.  The 2.2.1 version can still be released (just 
check the 2.2.0 sources and apply the fixes for 2.2.1 and release), but the 
current code is not a minor upgrade.


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


From ml at radoeka.nl  Tue Oct 21 21:02:50 2008
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 21 Oct 2008 21:02:50 +0200
Subject: [Kolab-devel]
	=?iso-8859-6?q?gunnar=3A_server/perl-kolab/bin=09ko?=
	=?iso-8859-6?q?lab=5Fbootstrap=2Ein_=2C_NONE=2C_1=2E1_kolabcheckpe?=
	=?iso-8859-6?q?rm=2Ein=2C_NONE=2C_1=2E1_kolabconf=2Ein=2C_NONE=2C_?=
	=?iso-8859-6?q?1=2E1_kolabdcachetool=2Ein=2C_NONE=2C_1=2E1_kolabd?=
	=?iso-8859-6?b?LmluLCBOT05FLCAxLjEJa29sYWJwYXNzd2QuaW4gLCBOT05F?=
	=?iso-8859-6?q?=2C_1=2E1_kolabquotareport=2Ein=2C_NONE=2C_1=2E1_ko?=
	=?iso-8859-6?q?labquotawarn=2Ein=2C_NONE=2C_1=2E1_kolab=5Fsmtpdpol?=
	=?iso-8859-6?q?icy=2Ein=2C_NONE=2C_1=2E1_kolab=5Fupgrade=2Ein=2C_N?=
	=?iso-8859-6?q?ONE=2C_1=2E1?=
In-Reply-To: <20081021114805.12311a3l6as00n6g@webmail.pardus.de>
References: <20081010142207.323F0600BAF@lists.intevation.de>
	<200810191109.36206.ml@radoeka.nl>
	<20081021114805.12311a3l6as00n6g@webmail.pardus.de>
Message-ID: <200810212102.50430.ml@radoeka.nl>

Op Tuesday 21 October 2008 11:48:05 schreef Gunnar Wrobel:
> Quoting Richard Bos <ml at radoeka.nl>:
> > Hi,
> >
> > Op Friday 10 October 2008 16:22:07 schreef cvs at kolab.org:
> >> Update of /kolabrepository/server/perl-kolab/bin
> >> In directory doto:/tmp/cvs-serv20319/bin
> >>
> >> Added Files:
> >>         kolab_bootstrap.in kolabcheckperm.in kolabconf.in
> >>         kolabdcachetool.in kolabd.in kolabpasswd.in
> >>         kolabquotareport.in kolabquotawarn.in kolab_smtpdpolicy.in
> >>         kolab_upgrade.in
> >> Log Message:
> >> Merge all perl tools into the perl-kolab package.
> >
> > why did this happen?  Don't belong those tools/scripts whatever to the
> > kolab server?
>
> The Kolab Server is a set of many different packages. It requires
> postfix, cyrus but also perl-kolab, kolabfilter and kolabfreebusy.

Yep.

> You are referring to the kolabd package. What did and does the package
> deliver?
>
>   - bash scripts
>   - perl scripts
>   - configuration templates
>   - amavisd templates
>
> Especially the scripts are a wild assortment of different
> functionality that "do something for the server".
>
> I consider it essential in packaging to use the language specific
> packaging tools. This would be PEAR for php, MakeMaker for Perl,
> distutils for python and gem for Ruby.
>
> So the change was not at all about perl-kolab but in fact about
> cleaning up the kolabd package. We need to get rid of the distconf
> approach in the long run and this has been just another commit on the
> road to that goal.

I see.  Good goal.

> I wouldn't mind if we place these perl scripts into a seperate perl
> package (maybe "perl-kolab-scripts") if you consider that more
> appropriate. I only moved all that stuff into perl-kolab and also
> collapsed kolabconf into perl-kolab for convenience.

I always thought that it should some how be possible that others (outside 
kolab) should be able to install perl-kolab module.  If that is true, all the 
scripts that you added to the perl-kolab module are strangers to the module 
and it would indeed better to have them moved to another package.  Don't know 
whether the scripts should be stored in perl-kolab-scripts, might be good 
indeed, but it also results in package fragmentation.

> The very critical part about the change was the use of MakeMaker (or
> Makefile.PL) which I consider essential. The scripts don't use the
> dist_conf approach any longer but use the Kolab configuration files
> which is how they should work.

:)

> > Why should e.g. kolab_bootstrap.in be part of perl-kolab and not of
> > the kolab server package?  If kolab_bootstrap.in is going to be rewritten
> > in bash, ruby, python, should it than be moved to respectively
> > bash-kolab, ruby-kolab or python-kolab?
>
> Not at all. From a packaging perspective I wouldn't mind if we get
> packages such as kolabconf (which I collapsed into perl-kolab now),
> kolabbootstrap, kolabd-daemon and so on. 

That looks to fragmented to me.  Those scripts are all essential to the kolab 
server, as such I would put them all in the "kolab" package.  I will see  how 
it goes.  I hope I can follow what is going on.


> But this is usually not the 
> way things are handled on OpenPKG. In most cases packages bundle
> different type of funtionality.
>
> Cheers,
>
> Gunnar
>
> > With all scripts removed from the kolab package, the latter is now almost
> > an empty package...
> >
> > --
> > 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



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


From kolab-issues at intevation.de  Wed Oct 22 11:40:18 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Wed, 22 Oct 2008 09:40:18 +0000
Subject: [Kolab-devel] [issue3175] Cyrus IMAPd 2.3.13 Released
Message-ID: <1224668418.89.0.168392773952.issue3175@intevation.de>


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

Two changes in this release might be useful for us:

* Added support for ManageSieve auto-capability response after
  STARTTLS and after AUTH with a SASL security layer.

see kolab/issue2443 (kontact aborts sieve when imapd sends capabilities after
starttls)

* Several skiplist transaction bugfixes.

see kolab/issue840 (Annotations needs to be more robust (skiplist problems))

----------
assignedto: thomas
messages: 17269
nosy: bernhard, martin, thomas, till, wilde, wrobel
priority: feature
status: unread
title: Cyrus IMAPd 2.3.13 Released
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3175>
___________________________________________________


From kolab-issues at intevation.de  Wed Oct 22 12:09:23 2008
From: kolab-issues at intevation.de (T. Ribbrock)
Date: Wed, 22 Oct 2008 10:09:23 +0000
Subject: [Kolab-devel] [issue3176] "Request Response" OFF only partially
	honoured by Kontact
Message-ID: <1224670162.92.0.868632917032.issue3176@intevation.de>


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

When creating an event with attendees, I can choose to switch "request response"
off for an attendee. Unfortunately, this setting is only partially honoured by
Kontact: The recipient still gets the standard invitation mail with "Accept",
"Accept Cond." etc., however, if "Accept" is clicked, no mail is sent back to
the organiser (which is as expeected).

This is quite confusing for the recipient, as he has no way of seeing from the
mail that the invitation is "informational" only and that no action of his is
required. I would expect that the invitation mail in this case only contains
something like "Enter this into my calendar" - but not all the standard options.

The situation is even worse when inviting a server side mailing list: In this
case, the recipient *will* get the dialog where he needs to confirm his identity
*and* a mail *is* sent to the organiser - despite having not requested one. This
is most likely related to issue3170.


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

P.S.: I seem to remember that a similar bug report was filed at some time in the
past, but I cannot find it - apologies if this is a duplicate.

----------
messages: 17271
nosy: itsef_admin
priority: bug
status: unread
title: "Request Response" OFF only partially honoured by Kontact
topic: enterprise35, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3176>
___________________________________________________


From kolab-issues at intevation.de  Wed Oct 22 16:23:32 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 22 Oct 2008 14:23:32 +0000
Subject: [Kolab-devel] [issue3177] klauncher crash (related with kioslave
	sieve)
Message-ID: <1224685412.11.0.191292694886.issue3177@intevation.de>


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

Sometimes klauncher.exe crashes. In this case kontact stops working
correctly as it cannot contact klauncher via dbus anymore.
(You can see this in the DebugView for instance.)

Workaround to restart: Kill all kde processes (e.g.e with killkde.bat)
to get a new klauncher.
Disable sieve in the settings.

Kontact Version 1.3 (enterprise4 0.20081017.872576) Windows.
kdepim-branch Revision 873857.
kdepimlibs-branch Revision 873968.
kdelibs last Changed Rev 871812.
Qt 4.4.3

Also Kontact_Installer_200812222.

The working hypothesis is that this is a race conditition
with kioslave sieve and appears only under some circumstances.
Tests have shown that without sieve those crashes do not appear.

----------
assignedto: bernhard
messages: 17274
nosy: bernhard, till
priority: urgent
status: unread
title: klauncher crash (related with kioslave sieve)
topic: kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3177>
___________________________________________________


From kolab-issues at intevation.de  Wed Oct 22 18:32:47 2008
From: kolab-issues at intevation.de (Thomas Arendsen Hein)
Date: Wed, 22 Oct 2008 16:32:47 +0000
Subject: [Kolab-devel] [issue3178] Kolab server CVS HEAD not compilable due
	to sqlite problems
Message-ID: <1224693167.65.0.382335184735.issue3178@intevation.de>


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

apache-php and php need sqlite (version 3), but they also need
/kolab/lib/libsqlite.* to compile.

If compiling the sqlite (version 2) package from CVS and reusing its libsqlite.*
files apache-php at least compiles, but php not.

----------
assignedto: wrobel
messages: 17276
nosy: bernhard, martin, thomas, till, wilde, wrobel
priority: critical
status: unread
title: Kolab server CVS HEAD not compilable due to sqlite problems
topic: server
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3178>
___________________________________________________


From thomas at intevation.de  Wed Oct 22 18:47:58 2008
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Wed, 22 Oct 2008 18:47:58 +0200
Subject: [Kolab-devel] New CVS committer, working on the next server beta
Message-ID: <20081022164758.GC24314.thomas@intevation.de>

Hi!

I just wanted to announce that Mathieu Parent now has write access
to the Kolab server CVS.

His work on the syncrepl code was very good and accurate, and he
delivered many good patches before that, so I talked to some people
who agreed on this.

Welcome, Mathieu!


We aim to produce a development snapshot of Kolab server CVS soon,
so developers and testers can take a look at the refactored
packages, e.g. kolab-webclient and friends. If first testing shows
that in general everything works, we can release this as a new beta
version which should be followed by a release candidate a month
after that.

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: 197 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081022/a0a1139c/attachment.bin

From kolab-issues at intevation.de  Thu Oct 23 09:47:13 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Thu, 23 Oct 2008 07:47:13 +0000
Subject: [Kolab-devel] [issue3179] Attached email not directly opened with
	Kontact
Message-ID: <1224748033.17.0.388963063382.issue3179@intevation.de>


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

Kontact Version 1.3 (enterprise4 0.20081017.872576) Windows
Kontact_Installer_20081022 with gpg4win-1.9.8-beta.

Forward yourself an email.
Now look at the received email which has an attachment email.

Clicking on the attachment brings up an "save" or "open with" (or "cancel")
dialog, which is different to behaviour in e35.
Using the right click menu, "open" does nothing.

I would expect a single click to do "open" and I expect "open"
to open the email in a new kontact email window, just like when pressing
on the "embeeded message" link which is shown in the pane below.

----------
assignedto: till
messages: 17279
nosy: bernhard, ludwig, till
priority: bug
status: unread
title: Attached email not directly opened with Kontact
topic: kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3179>
___________________________________________________


From kolab-issues at intevation.de  Thu Oct 23 15:56:28 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Thu, 23 Oct 2008 13:56:28 +0000
Subject: [Kolab-devel] [issue3181] composer LDAP lookup doesn't show every
	address.
Message-ID: <1224770188.75.0.895095463812.issue3181@intevation.de>


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

enterprise4 windows
Kontact-Installer_20081022.exe (kdepimlibs: 874622, kdepim: 874624)

If a ldap lookup is used by the composer to find addresses, it doenot display 
every address.

----------
assignedto: till
messages: 17306
nosy: bh, ludwig, till
priority: bug
status: unread
title: composer LDAP lookup doesn't show every address.
topic: kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3181>
___________________________________________________


From kolab-issues at intevation.de  Fri Oct 24 12:24:24 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Fri, 24 Oct 2008 10:24:24 +0000
Subject: [Kolab-devel] [issue3182] Not possible to accept an event sended to
	a second account
Message-ID: <1224843864.15.0.408650417009.issue3182@intevation.de>


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

enterprise4 windows
Kontact-Installer_20081022.exe (kdepimlibs: 874622, kdepim: 874624)

A user configures his user account as dimap and a group account as dimap.
He wants to accept an invitation sent to the group account.
So he presses Accept in the invitation mail, but the mail is not accepted by the
server.
The user has own identity for the group account and an own Server set as special
transport, but the mail is send with a wrong sending server.

----------
assignedto: till
messages: 17310
nosy: bh, ludwig, till
priority: bug
status: unread
title: Not possible to accept an event sended to a second account
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3182>
___________________________________________________


From kolab-issues at intevation.de  Sat Oct 25 18:49:44 2008
From: kolab-issues at intevation.de (Amy Choi)
Date: Sat, 25 Oct 2008 16:49:44 +0000
Subject: [Kolab-devel] [issue3183] here it is
Message-ID: <49034E2B.1028204@aol.com>


New submission from Amy Choi <Amy86 at aol.com>:

What's Up?
Fun People are meeting right now,
Check them out here
http://tinyurl.com/6exqp6

----------
messages: 17313
nosy: Amy86
status: unread
title: here it is
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3183>
___________________________________________________


From kolab-issues at intevation.de  Mon Oct 27 10:29:25 2008
From: kolab-issues at intevation.de (Pierluca)
Date: Mon, 27 Oct 2008 09:29:25 +0000
Subject: [Kolab-devel] [issue3184] Kolab 2.2 problem high cpu
Message-ID: <1225099765.8.0.487672850633.issue3184@intevation.de>


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

Hi,
i've one server kolab 2.2 with 10GB of RAM and 4 cpu core.
The level of cpu increases when the users login into horde. 
POP3 and IMAP work ok, with another web mail the problem not persist.
Any idea?

Pier

----------
messages: 17315
nosy: pizeta
priority: urgent
status: unread
title: Kolab 2.2 problem high cpu
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3184>
___________________________________________________


From kolab-issues at intevation.de  Mon Oct 27 11:17:43 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 27 Oct 2008 10:17:43 +0000
Subject: [Kolab-devel] [issue3185] After restart of kontact a whole day
	event was not displayed.
Message-ID: <1225102663.47.0.437251248518.issue3185@intevation.de>


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

enterprise4 windows
Kontact-Installer_20081022.exe (kdepimlibs: 874622, kdepim: 874624)

After some testing of the calendar, I notice that a whole day event was not
displayed after a restart.
This should not happen.

I rebuild the cache and this worked again.

----------
assignedto: till
messages: 17316
nosy: bh, ludwig, till
priority: bug
status: unread
title: After restart of kontact a whole day event was not displayed.
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3185>
___________________________________________________


From kolab-issues at intevation.de  Mon Oct 27 11:21:31 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 27 Oct 2008 10:21:31 +0000
Subject: [Kolab-devel] [issue3186] Start date isn't direct editable.
Message-ID: <1225102891.64.0.115403653079.issue3186@intevation.de>


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

enterprise4 windows
Kontact-Installer_20081022.exe (kdepimlibs: 874622, kdepim: 874624)

Test:
1. Start to create a new event.
2. Try to edit the "Start Date" field.

Notice: Opening the calendar field is needed to enter a new date.

----------
assignedto: till
messages: 17317
nosy: bh, ludwig, till
priority: minor bug
status: unread
title: Start date isn't direct editable.
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3186>
___________________________________________________


From kolab-issues at intevation.de  Mon Oct 27 11:25:38 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 27 Oct 2008 10:25:38 +0000
Subject: [Kolab-devel] [issue3187] Accept,
	accept cond. etc not translated into German.
Message-ID: <1225103138.56.0.556584478534.issue3187@intevation.de>


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

enterprise4 windows 
Kontact-Installer_20081022.exe (kdepimlibs: 874622, kdepim: 874624)

The invitation answer buttons are not translated into German.

Test:
1. UserA invites UserB to an event.
2. UserB snycs and looks at the invitation.

----------
assignedto: till
messages: 17318
nosy: bh, ludwig, till
priority: minor bug
status: unread
title: Accept, accept cond. etc not translated into German.
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3187>
___________________________________________________


From kolab-issues at intevation.de  Mon Oct 27 11:33:16 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 27 Oct 2008 10:33:16 +0000
Subject: [Kolab-devel] [issue3188] klauncher crash (missing resource)
Message-ID: <1225103596.53.0.464830591295.issue3188@intevation.de>


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

enterprise4 windows
Kontact-Installer_20081022.exe (kdepimlibs: 874622, kdepim: 874624)

I noticed a klauncher crash, after I have restarted kontact.
Before the restart, I failed to create an event, because the resource was missing.

----------
assignedto: till
messages: 17320
nosy: bh, ludwig, till
priority: bug
status: unread
title: klauncher crash (missing resource)
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3188>
___________________________________________________


From kolab-issues at intevation.de  Mon Oct 27 11:37:20 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 27 Oct 2008 10:37:20 +0000
Subject: [Kolab-devel] [issue3189] Accept an attendee dialog is not
	translated to German.
Message-ID: <1225103840.87.0.87246419756.issue3189@intevation.de>


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

enterprise4 windows
Kontact-Installer_20081022.exe (kdepimlibs: 874622, kdepim: 874624)

Test:
1. UserA invites UserB to an event
2. UserB fowards the event to UserC.
3. UserC accepts the event.
4. UserA enters UserC's update mail into his calendar
=> Accept UserC for the event dialog pops up
Notice : This dialog is not translated into German.

----------
assignedto: till
messages: 17321
nosy: bh, ludwig, till
priority: minor bug
status: unread
title: Accept an attendee dialog is not translated to German.
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3189>
___________________________________________________


From kolab-issues at intevation.de  Mon Oct 27 11:42:57 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Mon, 27 Oct 2008 10:42:57 +0000
Subject: [Kolab-devel] [issue3190] Mails of an event with local distribution
	list as atendee are not sent.
Message-ID: <1225104177.09.0.861311540223.issue3190@intevation.de>


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

enterprise4 windows
Kontact-Installer_20081022.exe (kdepimlibs: 874622, kdepim: 874624)

A user tries to invite a local distribution list, but after pressing okay, the
mails to the local dist list contacts are not sent and reopening of the event
shows, that the dist list attendees are missing.

----------
assignedto: till
messages: 17322
nosy: bh, ludwig, till
priority: bug
status: unread
title: Mails of an event with local distribution list as atendee are not sent.
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3190>
___________________________________________________


From wrobel at pardus.de  Mon Oct 27 15:28:07 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 27 Oct 2008 15:28:07 +0100
Subject: [Kolab-devel] RFC next kolab server version 2.3 and 2.2.1?
In-Reply-To: <200810212046.56305.ml@radoeka.nl>
References: <200810162138.19076.ml@radoeka.nl>
	<20081021112156.21125krngpa1x1k4@webmail.pardus.de>
	<200810211149.08945.bernhard.reiter@intevation.de>
	<200810212046.56305.ml@radoeka.nl>
Message-ID: <20081027152807.13014s5i25zq87wg@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Bernard,
>
> Op Tuesday 21 October 2008 11:49:05 schreef Bernhard Reiter:
>> On Dienstag, 21. Oktober 2008, Gunnar Wrobel wrote:
>> > > With a version of 2.2.1 people may blindly upgrade, assuming hardly any
>> > > changes were made.
>>
>> On the roadmap are only minor changes from the users
>> (aka Kolab Server Admin) perspective.
>>
>> > > With a 2.3 version number people will be more
>> > > carefull. Looking it from a cvs point of view: 2.2.1 should be a branch
>> > > from 2.2.0. 2.3 is further on, on the trunk.   The latter is what is
>> > > happening with kolab.
>> >
>> > Yes, you convinced me, too.
>> >
>> > 2.3 would be better. Bernhard, Thomas?
>>
>> Ideally 2.2.1 would just go in very smoothly on an update
>> and this is the version I hope we get which would also warrent that
>> particular version number.
>
> Forget the Ideally word in your sentence above.  The current situation is
> quite messy.  At the moment I can't do a testbuild for openSUSE at all
> because I have no idea what I need to package, as I have no idea what has
> been moved and to which module it has been moved.  That very much
> contradicts "go in very smoothly on an update" above.

I believe Bernhard has been referring to the functional aspects of the  
Kolab Server and we do indeed hope that this will be very smooth  
transition on the OpenPKG version.

> I understood that with the current situation the kolabconf package has been
> integrated in the perl-kolab package.  This means that on package level a
> whole package is gone, and special rules have to be added the perl-kolab
> package to obsoletes the kolabconf package.  That is only one example,
> besides the many others I have given before.

If you had a clean perl rpm spec for perl-kolab all you need to do is  
to remove the kolabconf package.

I am using the language specific packaging methods where ever I can.  
This means packaging for you platform should actually get easier not  
more complex.

Cheers,

Gunnar

>
> Hence I believe that with the current state of affairs the roadmap has to be
> updated with a 2.3 version.  The 2.2.1 version can still be released (just
> check the 2.2.0 sources and apply the fixes for 2.2.1 and release), but the
> current code is not a minor upgrade.
>
>
> --
> 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/20081027/7e3b053a/attachment.bin

From wrobel at pardus.de  Mon Oct 27 15:34:14 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 27 Oct 2008 15:34:14 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab/bin	kolab_bootstrap.in	,
	NONE, 1.1 kolabcheckperm.in, NONE, 1.1 kolabconf.in, NONE,
	1.1	kolabdcachetool.in, NONE, 1.1 kolabd.in, NONE,
	1.1	kolabpasswd.in , NONE, 1.1 kolabquotareport.in, NONE,
	1.1 kolabquotawarn.in, NONE, 1.1	kolab_smtpdpolicy.in, NONE,
	1.1 kolab_upgrade.in, NONE, 1.1
In-Reply-To: <200810212102.50430.ml@radoeka.nl>
References: <20081010142207.323F0600BAF@lists.intevation.de>
	<200810191109.36206.ml@radoeka.nl>
	<20081021114805.12311a3l6as00n6g@webmail.pardus.de>
	<200810212102.50430.ml@radoeka.nl>
Message-ID: <20081027153414.17724120ocaltsao@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Op Tuesday 21 October 2008 11:48:05 schreef Gunnar Wrobel:
>> Quoting Richard Bos <ml at radoeka.nl>:
>> > Hi,
>> >
>> > Op Friday 10 October 2008 16:22:07 schreef cvs at kolab.org:
>> >> Update of /kolabrepository/server/perl-kolab/bin
>> >> In directory doto:/tmp/cvs-serv20319/bin
>> >>
>> >> Added Files:
>> >>         kolab_bootstrap.in kolabcheckperm.in kolabconf.in
>> >>         kolabdcachetool.in kolabd.in kolabpasswd.in
>> >>         kolabquotareport.in kolabquotawarn.in kolab_smtpdpolicy.in
>> >>         kolab_upgrade.in
>> >> Log Message:
>> >> Merge all perl tools into the perl-kolab package.
>> >
>> > why did this happen?  Don't belong those tools/scripts whatever to the
>> > kolab server?
>>
>> The Kolab Server is a set of many different packages. It requires
>> postfix, cyrus but also perl-kolab, kolabfilter and kolabfreebusy.
>
> Yep.
>
>> You are referring to the kolabd package. What did and does the package
>> deliver?
>>
>>   - bash scripts
>>   - perl scripts
>>   - configuration templates
>>   - amavisd templates
>>
>> Especially the scripts are a wild assortment of different
>> functionality that "do something for the server".
>>
>> I consider it essential in packaging to use the language specific
>> packaging tools. This would be PEAR for php, MakeMaker for Perl,
>> distutils for python and gem for Ruby.
>>
>> So the change was not at all about perl-kolab but in fact about
>> cleaning up the kolabd package. We need to get rid of the distconf
>> approach in the long run and this has been just another commit on the
>> road to that goal.
>
> I see.  Good goal.
>
>> I wouldn't mind if we place these perl scripts into a seperate perl
>> package (maybe "perl-kolab-scripts") if you consider that more
>> appropriate. I only moved all that stuff into perl-kolab and also
>> collapsed kolabconf into perl-kolab for convenience.
>
> I always thought that it should some how be possible that others (outside
> kolab) should be able to install perl-kolab module.

Absolutely. This is the intention. The easiest way to achieve that is  
to build a clean perl package that uses Make::Maker (the Makefile.PL  
in server/perl-kolab/).

> If that is true, all the
> scripts that you added to the perl-kolab module are strangers to the module
> and it would indeed better to have them moved to another package.

Each and every one of the perl-based scripts actually requires  
perl-kolab as a basis. So I don't consider them strangers to the  
package at all. But as Thomas did also complain I'll probably move  
them some where else later. I actually don't care much about the  
actual structure. It is just important that we use packing tools that  
work across the distributions. And in case of Perl Make::Maker is the  
standard.

Cheers,

Gunnar

> Don't know
> whether the scripts should be stored in perl-kolab-scripts, might be good
> indeed, but it also results in package fragmentation.
>
>> The very critical part about the change was the use of MakeMaker (or
>> Makefile.PL) which I consider essential. The scripts don't use the
>> dist_conf approach any longer but use the Kolab configuration files
>> which is how they should work.
>
> :)
>
>> > Why should e.g. kolab_bootstrap.in be part of perl-kolab and not of
>> > the kolab server package?  If kolab_bootstrap.in is going to be rewritten
>> > in bash, ruby, python, should it than be moved to respectively
>> > bash-kolab, ruby-kolab or python-kolab?
>>
>> Not at all. From a packaging perspective I wouldn't mind if we get
>> packages such as kolabconf (which I collapsed into perl-kolab now),
>> kolabbootstrap, kolabd-daemon and so on.
>
> That looks to fragmented to me.  Those scripts are all essential to the kolab
> server, as such I would put them all in the "kolab" package.  I will see  how
> it goes.  I hope I can follow what is going on.
>
>
>> But this is usually not the
>> way things are handled on OpenPKG. In most cases packages bundle
>> different type of funtionality.
>>
>> Cheers,
>>
>> Gunnar
>>
>> > With all scripts removed from the kolab package, the latter is now almost
>> > an empty package...
>> >
>> > --
>> > 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
>
>
>
> --
> 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/20081027/70d7ba63/attachment.bin

From ml at radoeka.nl  Mon Oct 27 22:42:49 2008
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 27 Oct 2008 22:42:49 +0100
Subject: [Kolab-devel]
	=?iso-8859-6?q?gunnar=3A_server/perl-kolab/bin=09ko?=
	=?iso-8859-6?q?lab=5Fbootstrap=2Ein_=2C_NONE=2C_1=2E1_kolabcheckpe?=
	=?iso-8859-6?q?rm=2Ein=2C_NONE=2C_1=2E1_kolabconf=2Ein=2C_NONE=2C_?=
	=?iso-8859-6?q?1=2E1=09kolabdcachetool=2Ein_=2C_NONE=2C_1=2E1_kola?=
	=?iso-8859-6?q?bd=2Ein=2C_NONE=2C_1=2E1=09kolabpasswd=2Ein_=2C_NON?=
	=?iso-8859-6?q?E=2C_1=2E1_kolabquotareport=2Ein=2C_NONE=2C_1=2E1_k?=
	=?iso-8859-6?q?olabquotawarn=2Ein=2C_NONE=2C_1=2E1=09kolab=5Fsmtpd?=
	=?iso-8859-6?q?policy=2Ein_=2C_NONE=2C_1=2E1_kolab=5Fupgrade=2Ein?=
	=?iso-8859-6?b?LCBOT05FLCAxLjE=?=
In-Reply-To: <20081027153414.17724120ocaltsao@webmail.pardus.de>
References: <20081010142207.323F0600BAF@lists.intevation.de>
	<200810212102.50430.ml@radoeka.nl>
	<20081027153414.17724120ocaltsao@webmail.pardus.de>
Message-ID: <200810272242.49190.ml@radoeka.nl>

Op Monday 27 October 2008 15:34:14 schreef Gunnar Wrobel:
> > If that is true, all the
> > scripts that you added to the perl-kolab module are strangers to the
> > module and it would indeed better to have them moved to another package.
>
> Each and every one of the perl-based scripts actually requires ?
> perl-kolab as a basis. So I don't consider them strangers to the ?
> package at all. But as Thomas did also complain I'll probably move ?
> them some where else later. I actually don't care much about the ?
> actual structure. It is just important that we use packing tools that ?
> work across the distributions. And in case of Perl Make::Maker is the ?
> standard.

Why not leave them in (or bring them back to) to the kolab package.  In there 
the templates and the like (the current leftovers) can be build with the 
dist_conf variables and the perl scripts will be build with Perl Make::Maker?  
Just an idea.  I'll see how it develops.

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


From ml at radoeka.nl  Mon Oct 27 22:51:10 2008
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 27 Oct 2008 22:51:10 +0100
Subject: [Kolab-devel] RFC next kolab server version 2.3 and 2.2.1?
In-Reply-To: <20081027152807.13014s5i25zq87wg@webmail.pardus.de>
References: <200810162138.19076.ml@radoeka.nl>
	<200810212046.56305.ml@radoeka.nl>
	<20081027152807.13014s5i25zq87wg@webmail.pardus.de>
Message-ID: <200810272251.10712.ml@radoeka.nl>

Op Monday 27 October 2008 15:28:07 schreef Gunnar Wrobel:
> > I understood that with the current situation the kolabconf package has
> > been integrated in the perl-kolab package. ?This means that on package
> > level a whole package is gone, and special rules have to be added the
> > perl-kolab package to obsoletes the kolabconf package. ?That is only one
> > example, besides the many others I have given before.
>
> If you had a clean perl rpm spec for perl-kolab all you need to do is ?
> to remove the kolabconf package.

Kolabconf comes in its own package.  As kolabconf is now intergrated into 
perl-kolab, the package kolabconf is not needed anymore.  If we do not take 
appropriate action, rpm will complain that new perl-kolab rpm is about to 
install files over the files of the old kolabconf rpm.  Which is correct.  So 
either the sysadmin removes kolabconf manually, but as we're talking about a 
bugfix release (2.2.0 -> 2.2.1) according to many, the sysadmin does not 
expect that it is needed to remove the kolabconf rpm.
Or more advanced, and the one that we'll use (of course ;) ) is to tell the 
system that perl-kolab obsoletes kolabconf.  Now the kolabconf rpm will 
automatically be removed from system.  But as stated before, I don't expect 
that such package tricks are needed for a bug fix release.

> I am using the language specific packaging methods where ever I can. ?
> This means packaging for you platform should actually get easier not ?
> more complex.

Don't worry, as I appreciate all the effort that you put in kolab.  I worry 
that we're are talking about bug fix release while much more work is done.  
It would be good to tell the outside world that much has be done to kolab to 
make it much better....


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


From kolab-issues at intevation.de  Tue Oct 28 14:28:48 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Tue, 28 Oct 2008 13:28:48 +0000
Subject: [Kolab-devel] [issue3191] groupware resources not found
Message-ID: <1225200527.92.0.474289185763.issue3191@intevation.de>


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

enterprise4 windows
Kontact-Installer_20081027.exe (kdepimlibs 876316, kdepim 876316,
kdelibs-4.1-branch 874615 kdebase-runtime 874622)

After configuration of kontact with the kolabwizard and starting kontact,
kontact does't find the groupware resources. (calendar, contacts, etc...)
After restart the resources are still not found.
I checked with two different accounts.
If I close kontact, after I have tried to create an event, I encounter an error 
message(See screenshot resource-error-20081028.png)

----------
assignedto: till
files: resource-error-20081028.png
messages: 17341
nosy: bh, ludwig, till
priority: critical
status: unread
title: groupware resources not found
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3191>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resource-error-20081028.png
Type: image/png
Size: 8971 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081028/0a5460ce/resource-error-20081028.png

From kolab-issues at intevation.de  Tue Oct 28 15:52:35 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Tue, 28 Oct 2008 14:52:35 +0000
Subject: [Kolab-devel] [issue3192] Forwarding an invitation with toltec
	failed
Message-ID: <1225205555.46.0.596198353218.issue3192@intevation.de>


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

toltec 2.3.1 
kolab server 2.2.0

Test:
1. Someone sends an invitation to a toltec user.
2. The toltec user forwars the intvition.
=> The kolab server sends an error message to the toltec user.

(See screenshot.)

----------
assignedto: thomas
files: server-error-msg-20081028.png
messages: 17342
nosy: bh, joonradley, ludwig, thomas
priority: urgent
status: unread
title: Forwarding an invitation with toltec failed
topic: server, toltec
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3192>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server-error-msg-20081028.png
Type: image/png
Size: 11968 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081028/39b86189/server-error-msg-20081028-0001.png

From kolab-issues at intevation.de  Wed Oct 29 01:17:43 2008
From: kolab-issues at intevation.de (YOUR EMAIL ID WON 1, 000, 000 IN FREE EMAIL LOTTO (REF.007,
	BATCH.14))
Date: Wed, 29 Oct 2008 00:17:43 +0000
Subject: [Kolab-devel] [issue3193] Claim it
Message-ID: <48D08D7100007184@mail-6-uk.mail.tiscali.sys>


New submission from YOUR EMAIL ID WON 1,000,000 IN FREE EMAIL LOTTO (REF.007,BATCH.14) <micro_info at handbag.com>:

Attn, Lucky winner of one million euros.

Consult Dr.Jan Krugar
Email: micro.alliance at i12.com Tel:+31-64-7269-378

Include your private phone number as you file claim to>micro.alliance at i12.com

Sincerely yours,
Mrs. Bianca Peter.
Microsoft Email Award NL.

___________________________________________________________

Tiscali Broadband from 14.99 with free setup!
http://www.tiscali.co.uk/products/broadband/

----------
messages: 17344
nosy: micro_info
status: unread
title: Claim it
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3193>
___________________________________________________


From wrobel at pardus.de  Wed Oct 29 08:33:59 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Wed, 29 Oct 2008 08:33:59 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab/data quotawarning.txt,
	NONE, 1.1
In-Reply-To: <200810191132.17486.ml@radoeka.nl>
References: <20081010142206.C1D15600BAF@lists.intevation.de>
	<200810191109.30542.ml@radoeka.nl> <200810191132.17486.ml@radoeka.nl>
Message-ID: <20081029083359.16146wrhnngl5yao@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Op Sunday 19 October 2008 11:09:30 schreef Richard Bos:
>> > Added Files:
>> >         quotawarning.txt
>> > Log Message:
>> > Merge all perl tools into the perl-kolab package.
>>
>> I get this during the build:
>>
>> make: *** No rule to make target `quotawarning.txt', needed by  
>> `all-am'.  Stop.
>> error: Bad exit status from /var/tmp/rpm-tmp.28741 (%build)
>
> The solution is simple:
> kolabd> cvs diff Makefile.am
> Index: Makefile.am
> ===================================================================
> RCS file: /kolabrepository/server/kolabd/kolabd/Makefile.am,v
> retrieving revision 1.46
> diff -u -r1.46 Makefile.am
> --- Makefile.am 10 Oct 2008 14:30:44 -0000      1.46
> +++ Makefile.am 19 Oct 2008 09:30:31 -0000
> @@ -24,8 +24,7 @@
>  kolabspecialdir = $(kolabconfdir)
>  kolabspecial_DATA = kolab.globals
>
> -kolabconfig_FILES = rootDSE.ldif \
> -       quotawarning.txt
> +kolabconfig_FILES = rootDSE.ldif
>
> But as I don't agree with the move of the kolabd files/tools/scripts to
> perl-kolab I leave it to someone else to commit the change.

Thanks! In CVS.

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/20081029/4e9917bf/attachment.bin

From benoit.mortier at opensides.be  Wed Oct 29 09:41:59 2008
From: benoit.mortier at opensides.be (Benoit Mortier)
Date: Wed, 29 Oct 2008 09:41:59 +0100
Subject: [Kolab-devel] list of sucessfull implementation
Message-ID: <200810290941.59770.benoit.mortier@opensides.be>

Hello Everybody,

It's very hard to find reference of Kolab installation around the world, 
and i got asked fairly often about those.

I wanted to start a page reference in the wiki but got very few entries.

Could everybody send his reference here so we can publish them on the wiki

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


From kolab-issues at intevation.de  Wed Oct 29 21:04:17 2008
From: kolab-issues at intevation.de (Jeannine Masters)
Date: Wed, 29 Oct 2008 20:04:17 +0000
Subject: [Kolab-devel] [issue3194] craps tables
Message-ID: <07f401c93a01$8cb10700$0401a8c0@BEDROOM>


New submission from Jeannine Masters <WinniegibletGomes at helicoptergame.net>:

Come here for the Hottest Actiion and Games On|ine.

Join today and get 1800 USD in a free cash bonus.

http://yqzc5f483gv93.spaces.live.com/

All countries welcome!

----------
messages: 17370
nosy: WinniegibletGomes
status: unread
title: craps tables
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3194>
___________________________________________________


From wrobel at pardus.de  Thu Oct 30 08:49:47 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 30 Oct 2008 08:49:47 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab/bin	kolab_bootstrap.in	,
	NONE, 1.1 kolabcheckperm.in, NONE, 1.1 kolabconf.in, NONE,
	1.1	kolabdcachetool.in , NONE, 1.1 kolabd.in, NONE,
	1.1	kolabpasswd.in , NONE, 1.1 kolabquotareport.in, NONE,
	1.1 kolabquotawarn.in, NONE, 1.1	kolab_smtpdpolicy.in , NONE,
	1.1 kolab_upgrade.in, NONE, 1.1
In-Reply-To: <200810272242.49190.ml@radoeka.nl>
References: <20081010142207.323F0600BAF@lists.intevation.de>
	<200810212102.50430.ml@radoeka.nl>
	<20081027153414.17724120ocaltsao@webmail.pardus.de>
	<200810272242.49190.ml@radoeka.nl>
Message-ID: <20081030084947.64773wrl79eb0wf4@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Op Monday 27 October 2008 15:34:14 schreef Gunnar Wrobel:
>> > If that is true, all the
>> > scripts that you added to the perl-kolab module are strangers to the
>> > module and it would indeed better to have them moved to another package.
>>
>> Each and every one of the perl-based scripts actually requires   
>> perl-kolab as a basis. So I don't consider them strangers to the   
>> package at all. But as Thomas did also complain I'll probably move   
>> them some where else later. I actually don't care much about the   
>> actual structure. It is just important that we use packing tools  
>> that  work across the distributions. And in case of Perl  
>> Make::Maker is the  standard.
>
> Why not leave them in (or bring them back to) to the kolab package.  In there
> the templates and the like (the current leftovers) can be build with the
> dist_conf variables and the perl scripts will be build with Perl Make::Maker?
> Just an idea.  I'll see how it develops.

A clean package uses a single build mechanism. Not two.

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/20081030/97bf798c/attachment.bin

From wrobel at pardus.de  Thu Oct 30 08:59:30 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 30 Oct 2008 08:59:30 +0100
Subject: [Kolab-devel] RFC next kolab server version 2.3 and 2.2.1?
In-Reply-To: <200810272251.10712.ml@radoeka.nl>
References: <200810162138.19076.ml@radoeka.nl>
	<200810212046.56305.ml@radoeka.nl>
	<20081027152807.13014s5i25zq87wg@webmail.pardus.de>
	<200810272251.10712.ml@radoeka.nl>
Message-ID: <20081030085930.17022waaluugr82s@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Op Monday 27 October 2008 15:28:07 schreef Gunnar Wrobel:
>> > I understood that with the current situation the kolabconf package has
>> > been integrated in the perl-kolab package.  This means that on package
>> > level a whole package is gone, and special rules have to be added the
>> > perl-kolab package to obsoletes the kolabconf package.  That is only one
>> > example, besides the many others I have given before.
>>
>> If you had a clean perl rpm spec for perl-kolab all you need to do  
>> is  to remove the kolabconf package.
>
> Kolabconf comes in its own package.  As kolabconf is now intergrated into
> perl-kolab, the package kolabconf is not needed anymore.  If we do not take
> appropriate action, rpm will complain that new perl-kolab rpm is about to
> install files over the files of the old kolabconf rpm.  Which is correct.  So
> either the sysadmin removes kolabconf manually, but as we're talking about a
> bugfix release (2.2.0 -> 2.2.1) according to many, the sysadmin does not
> expect that it is needed to remove the kolabconf rpm.
> Or more advanced, and the one that we'll use (of course ;) ) is to tell the
> system that perl-kolab obsoletes kolabconf.  Now the kolabconf rpm will
> automatically be removed from system.  But as stated before, I don't expect
> that such package tricks are needed for a bug fix release.
>
>> I am using the language specific packaging methods where ever I  
>> can.  This means packaging for you platform should actually get  
>> easier not  more complex.
>
> Don't worry, as I appreciate all the effort that you put in kolab.  I worry
> that we're are talking about bug fix release while much more work is done.
> It would be good to tell the outside world that much has be done to kolab to
> make it much better....

Packaging should not interfere with the functionality the packages are  
providing. In my eyes we really don't change anything here. We just do  
some cleanup but the functionality should be the same.

I do understand that such packaging changes are a burden to the  
packagers. But I believe it is essential that the Kolab Server moves  
to a clean packaging scheme that works across all distributions  
including OpenPKG.

We had a short internal discussion on the topic this week and it looks  
like we will stick to Kolab-Server-2.2.1 for the OpenPKG version. For  
OpenPKG we see the transition between 2.2.0 and 2.2.1 as a smooth one  
with a simple upgrade path.

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://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/20081030/fdfec5a2/attachment.bin

From wrobel at pardus.de  Thu Oct 30 10:13:33 2008
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 30 Oct 2008 10:13:33 +0100
Subject: [Kolab-devel] Another release of the Kolab PHP development packages
Message-ID: <20081030101333.13547bjkg7hd1t44@webmail.pardus.de>

Hi!

In preparations of the Kolab-Server-2.2.1 release I released new  
versions of the Kolab PHP modules. They can be used as a powerful  
Kolab specific library to create "Kolab-aware" PHP applications.

The links to the packages:

http://pear.horde.org/index.php?package=Kolab_Format&release=1.0.0RC1&downloads
http://pear.horde.org/index.php?package=Kolab_Server&release=0.2.0&downloads
http://pear.horde.org/index.php?package=Kolab_Storage&release=0.2.0&downloads

Kolab_Format can be used to read/write the Kolab XML format. It did  
only see minor changes and is considered nearly stable. You'll find  
documentation here: http://wiki.kolab.org/index.php/Kolab_Format

Kolab_Server did gain a lot of functionality and has write  
capabilities now. This means it can be used to manage the Kolab users  
in LDAP. It will at some point be the basis for a rewritten Kolab web  
admin. You'll find some documentation here:  
http://wiki.kolab.org/index.php/Kolab_Server (this only documents read  
access at the moment).

Kolab_Storage did see some bug fixes and minor changes. It is the  
central package if you want to access Kolab data stored in IMAP. I did  
not yet find the time to describe how this package can be used. There  
is only basic information available at:  
https://wiki.kolab.org/index.php/Kolab_Storage

I'll try to extend the package documentation soon so that it becomes  
clearer how to authenticate against the Kolab server and how to  
manipulate the IMAP data.

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/20081030/aaf43b40/attachment.bin

From kolab-issues at intevation.de  Fri Oct 31 14:13:59 2008
From: kolab-issues at intevation.de (Ludwig Reiter)
Date: Fri, 31 Oct 2008 13:13:59 +0000
Subject: [Kolab-devel] [issue3195] Sending a mail encrypted and signed with
	an expired Openpgp key shows confusiong dialog
Message-ID: <1225458839.61.0.0895682038804.issue3195@intevation.de>


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

enterprise35  kdepim   20081027.876310
gnupg2 2.0.9.svn4835-0kk3

Test:
1.Create an OpenPGP key which expires in one day.
2.Start kontact and configure a new identity with the OpenPGP key.
3. Close kontact
4. Set the system time to a date in the future ( 20 days or so).
5. Start kontact and try to send a OpenPGP encrypted and signed mail to another
account.
=> First a "Unusable key" dialog(unusable-encryption-keys-20081031.png) pops up.
6. Press on "Continue"
=> A "key expires soon" warning (key-expires-soon-dialog-20081031.png) pops up.
The warning is wrong, because the key is already expired.

It is is urgent, because a customer asked about it.

----------
assignedto: till
files: screenshots-key-expire-20081031.zip
messages: 17406
nosy: bh, ludwig, osterfeld, pradeepto, till, vkrause
priority: urgent
status: unread
title: Sending a mail encrypted and signed with an expired Openpgp key shows confusiong dialog
topic: kde client, prokde35
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3195>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshots-key-expire-20081031.zip
Type: application/zip
Size: 40203 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081031/33dc3407/screenshots-key-expire-20081031-0001.zip

From kolab-issues at intevation.de  Mon Oct 20 15:58:28 2008
From: kolab-issues at intevation.de (Bernhard Herzog)
Date: Mon, 20 Oct 2008 13:58:28 +0000
Subject: [Kolab-devel] [issue3165] lenny enterprise4 packages have problems
	recognizing new resource folders
Message-ID: <1224511108.33.0.469253224971.issue3165@intevation.de>


New submission from Bernhard Herzog <bh at intevation.de>:

The KDEPIM Enterprise 4 packages for Debian Lenny have Problems recognizing new
resource folders when they are created with the Mail component.  E.g. create a
new calendar folder "foo" in the email part and change to the calender part. 
The folder should show up there, but it doesn't.  The new folders do show up
when Kontact is restarted.

This also happens for the default resource folders that are created
automatically when Disconnected IMAP is synced for the first time.

Kontact has been configured with the Kolab wizard.

Sometime the folder does show up immediately, though.  The attached
lenny-enterprise4-debug.txt contains the debug log for several test folders. 
All folders were created with the mail component.  Some did show up.  The
folders and the observed behavior was:

  Name        Type        Behavior
  zyzygy      Calendar    Showed up in calendar, but without color icon
  foobie      Contacts    Did not show up in Contact part

----------
assignedto: till
files: lenny-enterprise4-debug.txt
messages: 17205
nosy: bh, till
priority: bug
status: unread
title: lenny enterprise4 packages have problems recognizing new resource folders
topic: enterprise4, kde client
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3165>
___________________________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lenny-enterprise4-debug.txt
Url: http://kolab.org/pipermail/kolab-devel/attachments/20081020/afef4cc2/lenny-enterprise4-debug-0001.txt

From kolab-issues at intevation.de  Mon Oct 20 18:12:03 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Mon, 20 Oct 2008 16:12:03 +0000
Subject: [Kolab-devel] [issue3167] Configuration dialog has some doubled
	icons.
Message-ID: <1224519123.03.0.843190285961.issue3167@intevation.de>


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

Kontact Version 1.3 (enterprise4 0.20081017.872576) Windows.
kdepim-branch Revision 873857.
kdepimlibs-branch Revision 873968.
kdelibs last Changed Rev 871812.
Qt 4.4.3

See screenshot.

----------
assignedto: till
files: kontact-preferences-20081020-1.png
messages: 17215
nosy: bernhard, ludwig, till
priority: bug
status: unread
title: Configuration dialog has some doubled icons.
topic: kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3167>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kontact-preferences-20081020-1.png
Type: image/png
Size: 73180 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081020/0244dfc1/kontact-preferences-20081020-1-0001.png

From kolab-issues at intevation.de  Thu Oct 23 14:37:47 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Thu, 23 Oct 2008 12:37:47 +0000
Subject: [Kolab-devel] [issue3180] timezone selection/display not necessary
	for everyday event editing
Message-ID: <1224765467.89.0.0849498583132.issue3180@intevation.de>


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

Kontact Version 1.3 (enterprise4 0.20081013.870829) Lenny.
Also on Windows Installer 20080222.

The display and selection of the timezone takes up too much 
screenspace in the edit dialog. Most users will not need this feature,
so we should make it configurable to show or an "extended" button somehow
so it does not get in the way for the common case.

For a change I am attaching a screenshot from the Lenny version. :)

----------
assignedto: till
files: kontact-e4-lenny-event-edit-20081023-1.png
messages: 17305
nosy: bernhard, ludwig, till
priority: bug
status: unread
title: timezone selection/display not necessary for everyday event editing
topic: kde client, kowi
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3180>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kontact-e4-lenny-event-edit-20081023-1.png
Type: image/png
Size: 62947 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081023/2e778f91/kontact-e4-lenny-event-edit-20081023-1-0001.png

From karl-heinz.ruskowski at intevation.de  Wed Oct 29 12:40:49 2008
From: karl-heinz.ruskowski at intevation.de (Karl-Heinz Ruskowski)
Date: Wed, 29 Oct 2008 12:40:49 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab/data quotawarning.txt,
	NONE, 1.1
In-Reply-To: <20081029083359.16146wrhnngl5yao@webmail.pardus.de>
References: <20081010142206.C1D15600BAF@lists.intevation.de>
	<200810191132.17486.ml@radoeka.nl>
	<20081029083359.16146wrhnngl5yao@webmail.pardus.de>
Message-ID: <200810291241.07346.karl-heinz.ruskowski@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 \

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081029/3f5deb51/attachment.bin

From kolab-issues at intevation.de  Fri Oct 31 17:27:35 2008
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Fri, 31 Oct 2008 16:27:35 +0000
Subject: [Kolab-devel] [issue3196] large number of appointments can lead to
	corrupt index and loss of events
Message-ID: <1225470455.34.0.51498287335.issue3196@intevation.de>


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

It is possible to lose calender entries.
This probably is a result of some index corruption, thus there is 
a relation to kolab/issue3185 (Index problems (it is somehow possible to 
corrupt the index, needs cache rebuild))

How I reproduced it (before with 1800 and 3600 events as well):
1. switch to calender view. Make sure only one calendar is selected.
2. import 20081110-1200events.ics to merge into the current calendar
   and wait for loading and server sync (~ 7 minutes)
(optional) 3. checking the server with date ;ls *. | wc : 1200
Observation: Upload rate is 1/second in the beginning (up to 100). 
Gets faster later. Note that we are in the 4 digit numbers for the folder
on the server.
4. Try calender sync. ok. Go to email view and try full sync: ok.
   The  calender folder shows 1200 emails.
5. Switch to calender view. Select the full week from 10 to 16th of November 
2008, with the mouse. 
6. switch to email, sync. ok.
7. switch to calender, ok. select tab for side by side view. scroll around. ok.
8. switch to email. close Kontact. Give password for kwallet. ok.
9. Start kontact agian.

10. Doing combinations of: sync, index rebuilds, switching to calender view,
    switching tabs, email view, sync, enabling the other calender, disabling
    and enabling the large calender. At the end in the email view at a sync,
    when the large calender was enabled, 
Observation: the sync suddenly takes longer, on the server
suddenly all but 99 items are gone. (Interesting enough, this was when the 
upload was felt faster after 99, but I cannot say precisely.)
Now the email folder shows 99 in Kontact and on the folder.
Switching back to calender, interesting enough all 1200 items can still
be seen.
    
Using the output of day_appointment-20081110-1200events.py
a5dbf4ef2206e5a88330590ea9f0ada9e73e871b  20081110-1200events.ics
and
Kontact Version 1.3 (enterprise4 0.20081027.876316) Windows
kdelibs-4.1-branch 877805
kdepimlibs-branch  877821
kdepim-branch      878049
l10n-kde4-branch   877770.

Configured to switch between tab view. Two accounts configured.
Immediate sync enabled. Groupware folder blended in.

----------
assignedto: till
files: day_appointment-20081110-1200events.py
messages: 17410
nosy: bernhard, ludwig, till
priority: critical
status: unread
title: large number of appointments can lead to corrupt index and loss of events
topic: kde client, kowi, windows
___________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://www.intevation.de/roundup/kolab/issue3196>
___________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: day_appointment-20081110-1200events.py
Type: text/x-python
Size: 1690 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20081031/c479935e/day_appointment-20081110-1200events.py