From bh at intevation.de  Mon Aug  1 12:56:05 2005
From: bh at intevation.de (Bernhard Herzog)
Date: Mon, 01 Aug 2005 12:56:05 +0200
Subject: [Kolab-devel] Upgrading to db 4.3
Message-ID: <s9zvf2qq62i.fsf@thetis.intevation.de>


Hi,

we're currently preparing the 2.0.1 release of the kolab server.  The
most important change there will be the move to OpenPKG 2.4.  Among
other things this means an upgrade of the Berkeley DB to version 4.3.
So far it seems that this part of the upgrade has the most potential for
Problems.

There have been suggestions that 4.3 may not be a good choice for
openldap in a mail by Dieter Kluenter:
http://kolab.org/pipermail/kolab-users/2005-May/002582.html 
It's not quite clear to me, though, whether
"LDBM is definitly NO choice, nor will be BerkeleyDB-4.3.27."
means that bdb 4.3 should not be used or merely that it wouldn't solve
the stability problem (the comment was about a message in issue707 which
is about openldap stability).

Does anybody know more about this?

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/



From andreas at conectiva.com.br  Mon Aug  1 13:52:03 2005
From: andreas at conectiva.com.br (Andreas Hasenack)
Date: Mon, 1 Aug 2005 08:52:03 -0300
Subject: [Kolab-devel] Upgrading to db 4.3
In-Reply-To: <s9zvf2qq62i.fsf@thetis.intevation.de>
References: <s9zvf2qq62i.fsf@thetis.intevation.de>
Message-ID: <20050801115203.GA12873@conectiva.com.br>

On Mon, Aug 01, 2005 at 12:56:05PM +0200, Bernhard Herzog wrote:
> 
> Hi,
> 
> we're currently preparing the 2.0.1 release of the kolab server.  The
> most important change there will be the move to OpenPKG 2.4.  Among
> other things this means an upgrade of the Berkeley DB to version 4.3.
> So far it seems that this part of the upgrade has the most potential for
> Problems.
> 
> There have been suggestions that 4.3 may not be a good choice for
> openldap in a mail by Dieter Kluenter:
> http://kolab.org/pipermail/kolab-users/2005-May/002582.html 
> It's not quite clear to me, though, whether
> "LDBM is definitly NO choice, nor will be BerkeleyDB-4.3.27."
> means that bdb 4.3 should not be used or merely that it wouldn't solve
> the stability problem (the comment was about a message in issue707 which
> is about openldap stability).

That's also what I heard. So far, 4.2.52 + their two official patches
is the best choice, specially for openldap-2.3.x.



From jan at intevation.de  Mon Aug  1 14:32:44 2005
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Mon, 1 Aug 2005 14:32:44 +0200
Subject: [Kolab-devel] tiny patch for web admin interface
Message-ID: <20050801123244.GA25184@intevation.de>

Hi,

I did a little patch for the web admin interface to help
the beginners (attached).

I did not test it. How to handle such fixes (I could write
some further string improvements occasionally when I see
them during administration Kolab)?
Just commit (to HEAD?) or post here?

Best

	Jan

-- 
Jan-Oliver Wagner               http://intevation.de/~jan/
Intevation GmbH                      http://intevation.de/
Kolab Konsortium               http://kolab-konsortium.de/
FreeGIS                                http://freegis.org/
-------------- next part --------------
? .systemaliasnagscreen.tpl.swp
Index: systemaliasnagscreen.tpl
===================================================================
RCS file: /kolabrepository/server/kolab-webadmin/kolab-webadmin/php/admin/templates/systemaliasnagscreen.tpl,v
retrieving revision 1.1
diff -u -3 -p -r1.1 systemaliasnagscreen.tpl
--- systemaliasnagscreen.tpl	11 Mar 2005 09:59:05 -0000	1.1
+++ systemaliasnagscreen.tpl	1 Aug 2005 12:26:50 -0000
@@ -9,6 +9,18 @@
 </div>
 <div id="errorcontent">
 <div id="errorheader">{tr msg="NOTE:"}</div>
-{tr msg="No account is configured to receive mail for administrative addresses. If you have not yet created an account for this, please do so and then go"}
-<a href="{$topdir}/service/#systemaliasconf">{tr msg="here"}</a> {tr msg="to set up forwarding of mail to administrative email addresses."}
+{tr msg="The distribution lists for administrative issues have not yet been created.
+You need to have a user account on this Kolab server in order create the
+distribution list. Once created, you may withdraw the user from the distribution lists."}
+
+<p>
+<a href="{$topdir}/user/user.php?action=create">
+{tr msg="You may now create a new regular user account"}</a>
+{tr msg="and use him/her to create the administration
+distribution lists or you may whish to have a special user account (e.g. kolab-admin at yourdomain.tld
+as 'internal user') that forwards any emails to an external email address."}
+
+<p>
+<a href="{$topdir}/service/#systemaliasconf">{tr msg="Then go here"}</a>
+{tr msg="to set up the administrative distribution lists."}
 </div>

From list at codefusion.co.za  Mon Aug  1 15:12:42 2005
From: list at codefusion.co.za (Stephan Buys)
Date: Mon, 1 Aug 2005 15:12:42 +0200
Subject: [Kolab-devel] Re: steffen: server/kolabd/kolabd/templates
	DB_CONFIG.slapd.template, 1.2, 1.3 amavisd.conf.template, 1.6,
	1.7 clamd.conf.template, 1.2, 1.3 cyrus.conf.template, 1.1.1.1,
	1.2 fbview.conf.template, 1.1.1.1, 1.2 freebusy.conf.template,
	1.1.1.1, 1.2 freshclam.conf.template, 1.2,
	1.3 httpd.conf.template, 1.6, 1.7 httpd.local.template, 1.1,
	1.2 imapd.conf.template, 1.5, 1.6 imapd.group.template, 1.1.1.1,
	1.2 ldap.conf.template, 1.1.1.1, 1.2 ldapdistlist.cf.template,
	1.1, 1.2 ldaptransport.cf.template, 1.1,
	1.2 ldapvirtual.cf.template, 1.1, 1.2 main.cf.template, 1.18,
	1.19 master.cf.template, 1.12, 1.13 php.ini.template, 1.4,
	1.5 proftpd.conf.template, 1.1.1.1, 1.2 rc.conf.template, 1.2,
	1.3 resmgr.conf.template, 1.7, 1.8 saslauthd.conf.template,
	1.1.1.1, 1.2 session_vars.php.template, 1.4,
	1.5 slapd.access.template, 1.1, 1.2 slapd.conf.template, 1.14,
	1.15 slapd.replicas.template, 1.1.1.1, 1.2 smtpd.conf.template,
	1.1.1.1, 1.2 transport.template, 1.1.1.1
	, 1.2 virtual.temp late, 1.1.1.1, 1.2
In-Reply-To: <200507300227.12056.steffen@klaralvdalens-datakonsult.se>
References: <20050729021555.3884C101FAC@lists.intevation.de>
	<200507291553.32797.list@codefusion.co.za>
	<200507300227.12056.steffen@klaralvdalens-datakonsult.se>
Message-ID: <200508011512.42713.list@codefusion.co.za>

Hi,

Humble apologies if the mail had a sarcastic tone. It was true excitement and 
not meant as criticism. I have the greatest respect for your work on the
server.

On Saturday 30 July 2005 02:27, Steffen Hansen wrote:
> We're happy for your contribution of course, but given the slight 
> sarcasm in your mail, I have to say it didn't really work until now.
> 
Makes sense, it was never really tested much. It was a feature we implemented
and then put on hold while Kolab2 stabilized.

> The few lines of code to parse the meta-data part of the templates are 
> fine of course, but getting things to work with the templates that we 
> handle in special ways (like imapd.group) did require more than that.
> 
I don't think we ever even considered all the special-case files like imapd.group.

> Anyway, I'd like to push the "update command" out to the templates also 
> if possible. I haven't experimented with it yet, but I fear that just 
> having
> 
> COMMAND=/kolab/bin/openpkg rc foobar restart
> 
> in the templates is not good enough because we can't control the order 
> of things. Also it'll be difficult to prevent multiple restarts of the 
> same service unless the COMMAND given in the templates are byte-by-byte 
> equal. Any good ideas?
> 
Pushing the "update command" out to the templates was also a wish-list item
for me. What about having a couple of variations?

ON_UPDATE_EXEC=/command/to/be/executed
  This will run a command whenever the templates differ.

UPDATE_TEST=/command/to/be/executed
  Implement the "test for change" as a script. Depending on the return-code
  of the script this will trigger "COMMAND"

ON_UPDATE_RESTART=imapd
  This will restart imapd using /kolab/etc/rc imapd restart
  We can do a lowercase comparison of the commands. This way spaces or byte-level
  differences wont make the system fail.


Kind regards,
Stephan




> regards



From henning at loca.net  Mon Aug  1 16:47:49 2005
From: henning at loca.net (Henning Holtschneider)
Date: Mon, 1 Aug 2005 16:47:49 +0200
Subject: [Kolab-devel] KOrganizer reminds me at GMT
Message-ID: <200508011647.50355.henning@loca.net>

Hi,

I'm using Proko2 kdepim checked out last week from SVN on top of KDE 3.4.1. 
Since I compiled it last week, I have been wondering why I get no reminders 
from KOrganizer ...

I just created a new appointment at 18:00 o'clock with the reminder set to 15 
minutes. The reminder window pops up at 15:45 telling me that the meeting 
starts at 16:00. Since I'm in central Europe (GMT+2), I suppose this is a 
timezome problem. The timezone in the Kontact preferences is set to 
"Europe/Berlin". What's going wrong there? 

Regards,
Henning Holtschneider
--
LocaNet oHG - http://www.loca.net
Lindemannstrasse 81, D-44137 Dortmund
tel +49 231 91596-25, fax +49 231 91596-55
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050801/39fb8162/attachment.sig>

From bgmilne at obsidian.co.za  Mon Aug  1 18:28:00 2005
From: bgmilne at obsidian.co.za (Buchan Milne)
Date: Mon, 01 Aug 2005 18:28:00 +0200
Subject: [Kolab-devel] Upgrading to db 4.3
In-Reply-To: <s9zvf2qq62i.fsf@thetis.intevation.de>
References: <s9zvf2qq62i.fsf@thetis.intevation.de>
Message-ID: <42EE4D90.5030602@obsidian.co.za>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bernhard Herzog wrote:
> Hi,
> 
> we're currently preparing the 2.0.1 release of the kolab server.  The
> most important change there will be the move to OpenPKG 2.4.  Among
> other things this means an upgrade of the Berkeley DB to version 4.3.
> So far it seems that this part of the upgrade has the most potential for
> Problems.
> 
> There have been suggestions that 4.3 may not be a good choice for
> openldap in a mail by Dieter Kluenter:
> http://kolab.org/pipermail/kolab-users/2005-May/002582.html 
> It's not quite clear to me, though, whether
> "LDBM is definitly NO choice, nor will be BerkeleyDB-4.3.27."
> means that bdb 4.3 should not be used or merely that it wouldn't solve
> the stability problem (the comment was about a message in issue707 which
> is about openldap stability).
> 
> Does anybody know more about this?

Anyone using db4.3 by default at present has migrated prematurely IMHO
... Mandriva uses 4.2.52.4 (with patch for OpenLDAP 2.3, see below) by
default at present, although 4.3.27 is available (but nothing is built
against it).

AFAIK, most OpenLDAP developers haven't been happy with 4.3.27, 4.3.28
may be better, but none of the developers have yet noted that it is any
better. I haven't yet tried myself ...

BTW, what OpenLDAP version would be included? For 2.3.x, an additional
DB4.2 patch is recommended (available in build/ in current CVS).

Regards,
Buchan

- --
Buchan Milne                              Systems Architect
Obsidian Systems                  http://www.obsidian.co.za
B.Eng          RHCE (803004789010797),LPIC-1 (LPI000074592)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC7k2PrJK6UGDSBKcRAnrUAJ9RL11ozqgTgqvqpD1HSTPZO9NkEwCgojKN
7cuIWaCYm0HqJq5l21TtpWs=
=LnN3
-----END PGP SIGNATURE-----



From radoeka at xs4all.nl  Mon Aug  1 23:37:47 2005
From: radoeka at xs4all.nl (Richard Bos)
Date: Mon, 1 Aug 2005 23:37:47 +0200
Subject: [Kolab-devel] email folder questions
Message-ID: <200508012337.47843.radoeka@xs4all.nl>

I have 2 copies of the kolab resource folders.  They have been created by 
korganizer.  I run kde in Dutch and I think it is due to this, that the 
duplicate resource folders are there, I'll list them here:

Agenda
Calendar
Contactpersonen
Contacts
Notities
Notities
Taken
Tasks
Journaal
Logboek

Why is there Notities and Notities, while the others are translated?
Why are Journaal and Logboek at the end of list, I would expect them to be in 
the middle.

In the cyrus directory, the list is similar but still different:
# /kolab/var/imapd/spool/domain/..../user/richard
Agenda
Calendar
Contactpersonen
Contacts
Journal
Logboek
Notes
Notities
Taken
Tasks

Here the names are okay, but they are duplicated....

I think it happened while using different systems (but all with korganizer) to 
read email and such.  Is this a bug, a known one?  Should it be reported as a 
bug?


Another thing is, that in "normal" kmail operation (pop email) one can define 
an email folder as emaillist folder.  As such one can assign the folder the 
emaillist url.  This is a handy feature, but it does not seem to be available 
in case kmail is used in combination with kolab.  Do I miss something?

-- 
Richard Bos
Without a home the journey is endless



From kolab-issues at intevation.de  Tue Aug  2 11:43:56 2005
From: kolab-issues at intevation.de (Bernhard Herzog)
Date: Tue, 02 Aug 2005 09:43:56 +0000
Subject: [Kolab-devel] [issue861] kolab-resource-handlers installs with
	warning about uids
Message-ID: <1122975836.24.0.41260847369.issue861@intevation.de>


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

When installing kolab-resource-handlers-0.3.9-20050727 (part of the upcoming
2.0.1rc1) I get numerous warnings like this:

WARNING: running in safe mode requires that all files created be the same uid as
the current script.  PHP reports this script is uid: 19414, and current user is:
kolab

I wonder why it complains about that, since 19414 is the numerical uid of the
user kolab.  

This bug seems pretty harmless, so it won't stop a 2.0.1rc1 release.

----------
assignedto: steffen
messages: 5206
nosy: bh, steffen
priority: minor bug
status: unread
title: kolab-resource-handlers installs with warning about uids
topic: server
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue861>
________________________________________________



From bh at intevation.de  Tue Aug  2 16:29:56 2005
From: bh at intevation.de (Bernhard Herzog)
Date: Tue, 02 Aug 2005 16:29:56 +0200
Subject: [Kolab-devel] Upgrading to db 4.3
In-Reply-To: <42EE4D90.5030602@obsidian.co.za> (Buchan Milne's message of
	"Mon, 01 Aug 2005 18:28:00 +0200")
References: <s9zvf2qq62i.fsf@thetis.intevation.de>
	<42EE4D90.5030602@obsidian.co.za>
Message-ID: <s9zll3k8l97.fsf@thetis.intevation.de>

Buchan Milne <bgmilne at obsidian.co.za> writes:

> AFAIK, most OpenLDAP developers haven't been happy with 4.3.27, 4.3.28
> may be better, but none of the developers have yet noted that it is any
> better. I haven't yet tried myself ...

Thanks for the info.  I've googled a bit on this now.  Some of the
results are the following mails (one even from this very list :) ):

http://www.kolab.org/pipermail/kolab-devel/2005-May/003598.html

   Upgrading to BerkeleyDb-4.3.27 is not advised yet as there are some
   locking issues with transactional logs, patches have been provided to
   Sleepycat.

I don't know whether that may have changed in 4.3.28 which we would be
using in 2.0.1.


http://lists.debian.org/debian-devel/2005/03/msg01787.html


   You cannot use BDB 4.3 to load databases past a few million entries
   into OpenLDAP.  The way BDB handles logs changed enormously between
   BDB 4.2 and BDB 4.3, and its log management is not stable, often
   running out of space.  In addition, numerous users have written the
   OpenLDAP list complaining of issues they've hit using BDB 4.3 with
   OpenLDAP 2.2.  The solution was for them to move back to BDB
   4.2.52+patches.


One the whole there seems to no reason to upgrade bdb to 4.3 and some
reasons to stick with 4.2.  OTOH, 4.3 is the version used in both
OpenPKG 2.3 and 2.4 and we need to upgrade to 2.4 to benefit from
security updates from OpenPKG.

> BTW, what OpenLDAP version would be included? 

OpenLDAP 2.2.27

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/



From bgmilne at obsidian.co.za  Tue Aug  2 17:04:44 2005
From: bgmilne at obsidian.co.za (Buchan Milne)
Date: Tue, 02 Aug 2005 17:04:44 +0200
Subject: [Kolab-devel] Upgrading to db 4.3
In-Reply-To: <s9zll3k8l97.fsf@thetis.intevation.de>
References: <s9zvf2qq62i.fsf@thetis.intevation.de>	<42EE4D90.5030602@obsidian.co.za>
	<s9zll3k8l97.fsf@thetis.intevation.de>
Message-ID: <42EF8B8C.4000800@obsidian.co.za>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bernhard Herzog wrote:
> Buchan Milne <bgmilne at obsidian.co.za> writes:
> 
> 
>>AFAIK, most OpenLDAP developers haven't been happy with 4.3.27, 4.3.28
>>may be better, but none of the developers have yet noted that it is any
>>better. I haven't yet tried myself ...
> 
> 
> Thanks for the info.  I've googled a bit on this now.  Some of the
> results are the following mails (one even from this very list :) ):
> 
> http://www.kolab.org/pipermail/kolab-devel/2005-May/003598.html
> 
>    Upgrading to BerkeleyDb-4.3.27 is not advised yet as there are some
>    locking issues with transactional logs, patches have been provided to
>    Sleepycat.
> 
> I don't know whether that may have changed in 4.3.28 which we would be
> using in 2.0.1.
> 
> 
> http://lists.debian.org/debian-devel/2005/03/msg01787.html
> 
> 
>    You cannot use BDB 4.3 to load databases past a few million entries
>    into OpenLDAP.  The way BDB handles logs changed enormously between
>    BDB 4.2 and BDB 4.3, and its log management is not stable, often
>    running out of space.  In addition, numerous users have written the
>    OpenLDAP list complaining of issues they've hit using BDB 4.3 with
>    OpenLDAP 2.2.  The solution was for them to move back to BDB
>    4.2.52+patches.

The database loading issue should be addressed by using the quickload
option in slapadd, available in 2.3.x and as a patch for 2.2.x, but
requiring db-4.3 (or with a patch for db-4.2).

However, unless someone is going to do significant testing of OpenLDAP,
IMHO using 4.2.52.4 would be best.

> One the whole there seems to no reason to upgrade bdb to 4.3 and some
> reasons to stick with 4.2.  OTOH, 4.3 is the version used in both
> OpenPKG 2.3 and 2.4 and we need to upgrade to 2.4 to benefit from
> security updates from OpenPKG.

Well, I still wonder about anyone providing *only* 4.3 (and not 4.2).

But, it is possible to build OpenLDAP against an internal copy of
BerkeleyDB (in fact, it's so commonly required that the Mandriva spec
file allows for this by a macro, and will default to this on most older
releases of the distribution). There are some issues to take note of ...
but it's not difficult to implement.

>>BTW, what OpenLDAP version would be included? 
> 
> 
> OpenLDAP 2.2.27

2.3.x of course does have some nice features, but taking advantage of
them would be a lot of work (although taking advantage of them would
reduce the complexity of Kolab quite a bit I think ..).

But, we're sticking with 2.2.27 for now as well (though 2.3 is available
in contrib).

Regards,
Buchan

- --
Buchan Milne                              Systems Architect
Obsidian Systems                  http://www.obsidian.co.za
B.Eng          RHCE (803004789010797),LPIC-1 (LPI000074592)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC74uMrJK6UGDSBKcRAsabAJ9+NbhJDi/BflpVwPJGJ6PhjKverwCgqmvB
ufp7Cp0shEaXU23Ipr5WQdQ=
=jtc8
-----END PGP SIGNATURE-----



From radoeka at xs4all.nl  Tue Aug  2 19:18:38 2005
From: radoeka at xs4all.nl (Richard Bos)
Date: Tue, 2 Aug 2005 19:18:38 +0200
Subject: [Kolab-devel] Upgrading to db 4.3
In-Reply-To: <42EF8B8C.4000800@obsidian.co.za>
References: <s9zvf2qq62i.fsf@thetis.intevation.de>
	<s9zll3k8l97.fsf@thetis.intevation.de>
	<42EF8B8C.4000800@obsidian.co.za>
Message-ID: <200508021918.39013.radoeka@xs4all.nl>

Op dinsdag 2 augustus 2005 17:04, schreef Buchan Milne:
> 2.3.x of course does have some nice features, but taking advantage of
> them would be a lot of work (although taking advantage of them would
> reduce the complexity of Kolab quite a bit I think ..).

What advantages and how would it reduce kolab's complexity?

-- 
Richard Bos
Without a home the journey is endless



From dieter at dkluenter.de  Tue Aug  2 20:51:39 2005
From: dieter at dkluenter.de (Dieter Kluenter)
Date: Tue, 02 Aug 2005 20:51:39 +0200
Subject: [Kolab-devel] Upgrading to db 4.3
In-Reply-To: <s9zvf2qq62i.fsf@thetis.intevation.de> (Bernhard Herzog's
	message of "Mon, 01 Aug 2005 12:56:05 +0200")
References: <s9zvf2qq62i.fsf@thetis.intevation.de>
Message-ID: <87psswi344.fsf@rubin.l4b.de>

Hi,

Bernhard Herzog <bh at intevation.de> writes:
>
> we're currently preparing the 2.0.1 release of the kolab server.  The
> most important change there will be the move to OpenPKG 2.4.  Among
> other things this means an upgrade of the Berkeley DB to version 4.3.
> So far it seems that this part of the upgrade has the most potential for
> Problems.
>
> There have been suggestions that 4.3 may not be a good choice for
> openldap in a mail by Dieter Kluenter:
> http://kolab.org/pipermail/kolab-users/2005-May/002582.html 
> It's not quite clear to me, though, whether
> "LDBM is definitly NO choice, nor will be BerkeleyDB-4.3.27."
> means that bdb 4.3 should not be used or merely that it wouldn't solve
> the stability problem (the comment was about a message in issue707 which
> is about openldap stability).

I have done some moderate testing with OpenLDAP-2.3.4 and
BerkeleyDB-4.3.28. (some 20K entries, 3 subtrees, 1 search
operation per second and 1 write operation per minute, 6 hours). These
tests succeeded with no errors. I have not tested 2.2.27 though.
With regard to Kolab, OpenLDAP-2.2.27 and BerkelyDb-4.3.28, there
might still be some locking problems, as Quanah reported some issues
on openldap-software mailinglist.
I will set up a 2.2.27 test environment with 4.3.28 and rerun my test.
The environment will be x86_64, 1GB RAM, SuSE-9.3.
  
-Dieter

-- 
Dieter Kl?nter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6



From aseigo at kde.org  Tue Aug  2 22:33:36 2005
From: aseigo at kde.org (Aaron J. Seigo)
Date: Tue, 02 Aug 2005 14:33:36 -0600
Subject: [Kolab-devel] Re: Kolab / Horde LDAP missmatch?
In-Reply-To: <200508022142.38192.matt@fruitsalad.org>
References: <00dd01c596b2$cb217600$e900a8c0@ewuhome>
	<200508011108.49920.aseigo@kde.org>
	<200508022142.38192.matt@fruitsalad.org>
Message-ID: <200508021433.37190.aseigo@kde.org>

On Tuesday 02 August 2005 01:42, you wrote:
> On Monday 01 August 2005 19.08, Aaron J. Seigo wrote:
> > yes, i have a local fix for this...
> > in /kolab/var/kolab/www/admin/user/user.php on or around line 453 you'll
> > see this:
> >
> >        $ldap_object['objectClass'] = array('top',
> > 'inetOrgPerson','kolabInetOrgPerson');
> >
> > change it to:
> >
> >        $ldap_object['objectClass'] = array('top', 'inetOrgPerson',
> > 'kolabInetOrgPerson', 'hordePerson');
> >
> > and voila, things are good, even for accounts that have never been used
> > with horde. AFAIK this is not currently a generic fix since kolab doesn't
> > ship with the horde LDAP schema (which contains hordePerson) so would
> > likely create errors for those w/out horde.
>
> It should not be to hard to check if horde.schema is included in the ldap
> config files and based on that conditionally use the correct one.

might that not be a bit slow?

would it make more sense to have another checkbox on the services page that 
says "Enabled Horde webmail integration" and have the admin turn that on?

either way, i don't particularly care. i'll leave it up to the kolab web admin 
maintainer. choose a way and i'll implement it immediately and present the  
patch on the list here.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050802/17b90ff9/attachment.sig>

From kolab-issues at intevation.de  Tue Aug  2 23:08:20 2005
From: kolab-issues at intevation.de (Richard Bos)
Date: Tue, 02 Aug 2005 21:08:20 +0000
Subject: [Kolab-devel] [issue862] Mark folder as emaillist holder
Message-ID: <1123016900.88.0.454266188177.issue862@intevation.de>


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

In regular kmail it is possible to mark a email folder as emaillist holder. 
In combination with kolab this does not seem possible.  The nice feature 
of sending emails to an emaillist (ctrl-shift-N) does now not work.     
 
Is that because the folders are children of the inbox?

----------
messages: 5211
nosy: rbos
priority: wish
status: unread
title: Mark folder as emaillist holder
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue862>
________________________________________________



From piegope at hotmail.com  Wed Aug  3 00:28:52 2005
From: piegope at hotmail.com (pier jose gotta perez)
Date: Tue, 02 Aug 2005 22:28:52 +0000
Subject: [Kolab-devel] Spanish translation
Message-ID: <BAY18-F103882D5D2DB693635A0FAAEC20@phx.gbl>

Hi:

Is there already an spanish translation in progress?
How can I help in the translation project?

Thanks a lot for your help.

Pier Gotta
Refrinorte Ltda.
Barranquilla, Colombia

_________________________________________________________________
Charla con tus amigos en l?nea mediante MSN Messenger: 
http://messenger.latam.msn.com/



From markus at relix.de  Wed Aug  3 00:31:03 2005
From: markus at relix.de (Markus Heller)
Date: Wed, 3 Aug 2005 00:31:03 +0200
Subject: [Kolab-devel] Problem installing Kolab2
Message-ID: <200508030031.03298.markus@relix.de>

In Reference to the error reported in 
http://www.intevation.de/pipermail/kolab-devel/2005-July/004022.html

I am sorry to say that I also hit this error:
--------------------------------------------------------------
+ /kolab/RPM/TMP/openpkg-2.2.3/make-3.80/make
/kolab/RPM/TMP/openpkg-2.2.3/make-3.80/make  all-recursive
make[1]: Entering directory `/kolab/RPM/TMP/openpkg-2.2.3/rpm-4.2.1'
Making all in intl
make[2]: Entering directory `/kolab/RPM/TMP/openpkg-2.2.3/rpm-4.2.1/intl'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/kolab/RPM/TMP/openpkg-2.2.3/rpm-4.2.1/intl'
Making all in file
make[2]: Entering directory `/kolab/RPM/TMP/openpkg-2.2.3/rpm-4.2.1/file'
cd . && true
cat ./Header ./Localstuff > magic
for frag in Magdir/acorn Magdir/adi Magdir/adventure Magdir/allegro 
Magdir/alliant Magdir/alpha Magdir/amanda Magdir/amigaos Magdir/animation 
Magdir/apl Magdir/apple Magdir/applix Magdir/archive Magdir/asterix 
Magdir/att3b Magdir/audio Magdir/blender Magdir/blit Magdir/bsdi 
Magdir/c-lang Magdir/cddb Magdir/chi Magdir/cisco Magdir/citrus Magdir/claris 
Magdir/clipper Magdir/commands Magdir/compress Magdir/console Magdir/convex 
Magdir/ctags Magdir/cvs Magdir/database Magdir/diamond Magdir/diff 
Magdir/digital Magdir/dolby Magdir/dump Magdir/dyadic Magdir/editors 
Magdir/elf Magdir/encore Magdir/epoc Magdir/filesystems Magdir/flash 
Magdir/fonts Magdir/frame Magdir/freebsd Magdir/fsav Magdir/gimp Magdir/gnu 
Magdir/grace Magdir/gringotts Magdir/hitachi-sh Magdir/hp Magdir/ibm370 
Magdir/ibm6000 Magdir/iff Magdir/images Magdir/impulse Magdir/intel 
Magdir/interleaf Magdir/island Magdir/ispell Magdir/java Magdir/jpeg 
Magdir/karma Magdir/lecter Magdir/lex Magdir/lif Magdir/linux Magdir/lisp 
Magdir/mach Magdir/macintosh Magdir/magic Magdir/mail.news Magdir/maple 
Magdir/mathematica Magdir/mcrypt Magdir/mime Magdir/mips Magdir/mirage 
Magdir/mkid Magdir/mmdf Magdir/mlssa Magdir/modem Magdir/motorola 
Magdir/msdos Magdir/msvc Magdir/natinst Magdir/ncr Magdir/netbsd 
Magdir/netscape Magdir/news Magdir/nitpicker Magdir/octave Magdir/olf 
Magdir/os2 Magdir/os9 Magdir/osf1 Magdir/palm Magdir/parix Magdir/pbm 
Magdir/pdf Magdir/pdp Magdir/perl Magdir/pgp Magdir/pkgadd Magdir/plus5 
Magdir/printer Magdir/project Magdir/psdbms Magdir/pulsar Magdir/pyramid 
Magdir/python Magdir/riff Magdir/rpm Magdir/rtf Magdir/sc Magdir/sccs 
Magdir/sendmail Magdir/sequent Magdir/sgml Magdir/sharc Magdir/sketch 
Magdir/smalltalk Magdir/sniffer Magdir/softquad Magdir/spectrum Magdir/sun 
Magdir/sysex Magdir/teapot Magdir/terminfo Magdir/tex Magdir/tgif 
Magdir/ti-8x Magdir/timezone Magdir/troff Magdir/tuxedo Magdir/typeset 
Magdir/unknown Magdir/uuencode Magdir/varied.out Magdir/vax Magdir/vicar 
Magdir/visx Magdir/vms Magdir/vmware Magdir/vorbis Magdir/vxl 
Magdir/wordperfect Magdir/xdelta Magdir/xenix Magdir/zilog Magdir/zyxel; do \
  if test -f ./$frag; then \
    f=./$frag; \
  else \
    f=$frag; \
  fi; \
          cat $f; \
done >> magic
if /usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.   
-DMAGIC='"/kolab/lib/openpkg/magic"'  -DOPENPKG -DOPENPKG_LINUX 
-I/kolab/RPM/TMP/openpkg-2.2.3/zlib-1.2.1 
-I/kolab/RPM/TMP/openpkg-2.2.3/bzip2-1.0.2 
-I/kolab/RPM/TMP/openpkg-2.2.3/beecrypt-4.0.0 -D_GNU_SOURCE -D_REENTRANT 
-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes 
-Wno-char-subscripts -MT file.o -MD -MP -MF ".deps/file.Tpo" \
  -c -o file.o `test -f 'file.c' || echo './'`file.c; \
then mv -f ".deps/file.Tpo" ".deps/file.Po"; \
else rm -f ".deps/file.Tpo"; exit 1; \
fi
In file included from /usr/include/inttypes.h:28,
                 from system.h:17,
                 from file.c:28:
/usr/include/stdint.h:49: error: duplicate 'unsigned'
/usr/include/stdint.h:49: error: two or more data types in declaration 
specifiers
/usr/include/stdint.h:50: error: duplicate 'unsigned'
/usr/include/stdint.h:50: error: duplicate 'short'
/usr/include/stdint.h:52: error: duplicate 'unsigned'
/usr/include/stdint.h:52: error: two or more data types in declaration 
specifiers
make[2]: *** [file.o] Error 1
make[2]: Leaving directory `/kolab/RPM/TMP/openpkg-2.2.3/rpm-4.2.1/file'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/kolab/RPM/TMP/openpkg-2.2.3/rpm-4.2.1'
make: *** [all] Error 2
+ exit 2
./openpkg.boot:ERROR: script returned non-null value
/tmp/obmtool.3322.tmp: line 449: /kolab/RPM/PKG/openpkg-2.2.3-2.2.3.*-*-*.sh: 
No such file or directory
obmtool:ERROR: bootstrapping failed

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

Regards,

Markus



From markus at relix.de  Wed Aug  3 00:58:57 2005
From: markus at relix.de (Markus Heller)
Date: Wed, 3 Aug 2005 00:58:57 +0200
Subject: [Kolab-devel] Problem installing Kolab2
In-Reply-To: <200508030031.03298.markus@relix.de>
References: <200508030031.03298.markus@relix.de>
Message-ID: <200508030058.58294.markus@relix.de>

Dear Specialists :-)

I figure out, some more information should be useful: 
- Debian 3.1 , fresh install
- Sources downloaded as given in the wiki howto

Maybe this is about gcc? My gcc version is 4.0.2 20050725 (prerelease) (Debian 
4.0.1-3)

Best wishes,
Markus

Am Mittwoch, 3. August 2005 00:31 schrieb Markus Heller:
> In Reference to the error reported in
> http://www.intevation.de/pipermail/kolab-devel/2005-July/004022.html
>
> I am sorry to say that I also hit this error:
> --------------------------------------------------------------
> + /kolab/RPM/TMP/openpkg-2.2.3/make-3.80/make
> /kolab/RPM/TMP/openpkg-2.2.3/make-3.80/make  all-recursive
> make[1]: Entering directory `/kolab/RPM/TMP/openpkg-2.2.3/rpm-4.2.1'
> Making all in intl
> make[2]: Entering directory `/kolab/RPM/TMP/openpkg-2.2.3/rpm-4.2.1/intl'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory `/kolab/RPM/TMP/openpkg-2.2.3/rpm-4.2.1/intl'
> Making all in file
> make[2]: Entering directory `/kolab/RPM/TMP/openpkg-2.2.3/rpm-4.2.1/file'
> cd . && true
> cat ./Header ./Localstuff > magic
> for frag in Magdir/acorn Magdir/adi Magdir/adventure Magdir/allegro
> Magdir/alliant Magdir/alpha Magdir/amanda Magdir/amigaos Magdir/animation
> Magdir/apl Magdir/apple Magdir/applix Magdir/archive Magdir/asterix
> Magdir/att3b Magdir/audio Magdir/blender Magdir/blit Magdir/bsdi
> Magdir/c-lang Magdir/cddb Magdir/chi Magdir/cisco Magdir/citrus
> Magdir/claris Magdir/clipper Magdir/commands Magdir/compress Magdir/console
> Magdir/convex Magdir/ctags Magdir/cvs Magdir/database Magdir/diamond
> Magdir/diff Magdir/digital Magdir/dolby Magdir/dump Magdir/dyadic
> Magdir/editors Magdir/elf Magdir/encore Magdir/epoc Magdir/filesystems
> Magdir/flash Magdir/fonts Magdir/frame Magdir/freebsd Magdir/fsav
> Magdir/gimp Magdir/gnu Magdir/grace Magdir/gringotts Magdir/hitachi-sh
> Magdir/hp Magdir/ibm370 Magdir/ibm6000 Magdir/iff Magdir/images
> Magdir/impulse Magdir/intel Magdir/interleaf Magdir/island Magdir/ispell
> Magdir/java Magdir/jpeg Magdir/karma Magdir/lecter Magdir/lex Magdir/lif
> Magdir/linux Magdir/lisp Magdir/mach Magdir/macintosh Magdir/magic
> Magdir/mail.news Magdir/maple Magdir/mathematica Magdir/mcrypt Magdir/mime
> Magdir/mips Magdir/mirage Magdir/mkid Magdir/mmdf Magdir/mlssa Magdir/modem
> Magdir/motorola
> Magdir/msdos Magdir/msvc Magdir/natinst Magdir/ncr Magdir/netbsd
> Magdir/netscape Magdir/news Magdir/nitpicker Magdir/octave Magdir/olf
> Magdir/os2 Magdir/os9 Magdir/osf1 Magdir/palm Magdir/parix Magdir/pbm
> Magdir/pdf Magdir/pdp Magdir/perl Magdir/pgp Magdir/pkgadd Magdir/plus5
> Magdir/printer Magdir/project Magdir/psdbms Magdir/pulsar Magdir/pyramid
> Magdir/python Magdir/riff Magdir/rpm Magdir/rtf Magdir/sc Magdir/sccs
> Magdir/sendmail Magdir/sequent Magdir/sgml Magdir/sharc Magdir/sketch
> Magdir/smalltalk Magdir/sniffer Magdir/softquad Magdir/spectrum Magdir/sun
> Magdir/sysex Magdir/teapot Magdir/terminfo Magdir/tex Magdir/tgif
> Magdir/ti-8x Magdir/timezone Magdir/troff Magdir/tuxedo Magdir/typeset
> Magdir/unknown Magdir/uuencode Magdir/varied.out Magdir/vax Magdir/vicar
> Magdir/visx Magdir/vms Magdir/vmware Magdir/vorbis Magdir/vxl
> Magdir/wordperfect Magdir/xdelta Magdir/xenix Magdir/zilog Magdir/zyxel; do
> \ if test -f ./$frag; then \
>     f=./$frag; \
>   else \
>     f=$frag; \
>   fi; \
>           cat $f; \
> done >> magic
> if /usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.
> -DMAGIC='"/kolab/lib/openpkg/magic"'  -DOPENPKG -DOPENPKG_LINUX
> -I/kolab/RPM/TMP/openpkg-2.2.3/zlib-1.2.1
> -I/kolab/RPM/TMP/openpkg-2.2.3/bzip2-1.0.2
> -I/kolab/RPM/TMP/openpkg-2.2.3/beecrypt-4.0.0 -D_GNU_SOURCE -D_REENTRANT
> -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
> -Wno-char-subscripts -MT file.o -MD -MP -MF ".deps/file.Tpo" \
>   -c -o file.o `test -f 'file.c' || echo './'`file.c; \
> then mv -f ".deps/file.Tpo" ".deps/file.Po"; \
> else rm -f ".deps/file.Tpo"; exit 1; \
> fi
> In file included from /usr/include/inttypes.h:28,
>                  from system.h:17,
>                  from file.c:28:
> /usr/include/stdint.h:49: error: duplicate 'unsigned'
> /usr/include/stdint.h:49: error: two or more data types in declaration
> specifiers
> /usr/include/stdint.h:50: error: duplicate 'unsigned'
> /usr/include/stdint.h:50: error: duplicate 'short'
> /usr/include/stdint.h:52: error: duplicate 'unsigned'
> /usr/include/stdint.h:52: error: two or more data types in declaration
> specifiers
> make[2]: *** [file.o] Error 1
> make[2]: Leaving directory `/kolab/RPM/TMP/openpkg-2.2.3/rpm-4.2.1/file'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/kolab/RPM/TMP/openpkg-2.2.3/rpm-4.2.1'
> make: *** [all] Error 2
> + exit 2
> ./openpkg.boot:ERROR: script returned non-null value
> /tmp/obmtool.3322.tmp: line 449:
> /kolab/RPM/PKG/openpkg-2.2.3-2.2.3.*-*-*.sh: No such file or directory
> obmtool:ERROR: bootstrapping failed
>
> -----------------------------------------
>
> Regards,
>
> Markus
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel



From lists at pietrosanti.it  Wed Aug  3 08:36:14 2005
From: lists at pietrosanti.it (Fabio Pietrosanti)
Date: Wed, 03 Aug 2005 08:36:14 +0200
Subject: [Kolab-devel] Re: Kolab / Horde LDAP missmatch?
In-Reply-To: <20050802203617.EE4F61D8F81@supertolla.itapac.net>
References: <00dd01c596b2$cb217600$e900a8c0@ewuhome>	<200508011108.49920.aseigo@kde.org>	<200508022142.38192.matt@fruitsalad.org>
	<20050802203617.EE4F61D8F81@supertolla.itapac.net>
Message-ID: <20050803063635.5219B1D8F34@supertolla.itapac.net>

Aaron J. Seigo ha scritto:

>On Tuesday 02 August 2005 01:42, you wrote:
>  
>
>>On Monday 01 August 2005 19.08, Aaron J. Seigo wrote:
>>    
>>
>>>yes, i have a local fix for this...
>>>in /kolab/var/kolab/www/admin/user/user.php on or around line 453 you'll
>>>see this:
>>>
>>>       $ldap_object['objectClass'] = array('top',
>>>'inetOrgPerson','kolabInetOrgPerson');
>>>
>>>change it to:
>>>
>>>       $ldap_object['objectClass'] = array('top', 'inetOrgPerson',
>>>'kolabInetOrgPerson', 'hordePerson');
>>>
>>>and voila, things are good, even for accounts that have never been used
>>>with horde. AFAIK this is not currently a generic fix since kolab doesn't
>>>ship with the horde LDAP schema (which contains hordePerson) so would
>>>likely create errors for those w/out horde.
>>>      
>>>
>>It should not be to hard to check if horde.schema is included in the ldap
>>config files and based on that conditionally use the correct one.
>>    
>>
>
>might that not be a bit slow?
>
>would it make more sense to have another checkbox on the services page that 
>says "Enabled Horde webmail integration" and have the admin turn that on?
>
>either way, i don't particularly care. i'll leave it up to the kolab web admin 
>maintainer. choose a way and i'll implement it immediately and present the  
>patch on the list here.
>  
>
Imho your porposed approach is good.
Integrate the horde ldap schema permanently, then an if statement in
user.php that look at a specified ldap field which could be
horde-integration: 1 .

I would really appreciate that patch.

Fabio



From jan at intevation.de  Wed Aug  3 11:02:02 2005
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Wed, 3 Aug 2005 11:02:02 +0200
Subject: [Kolab-devel] Problem installing Kolab2
In-Reply-To: <200508030058.58294.markus@relix.de>
References: <200508030031.03298.markus@relix.de>
	<200508030058.58294.markus@relix.de>
Message-ID: <20050803090202.GA29851@intevation.de>

On Wed, Aug 03, 2005 at 12:58:57AM +0200, Markus Heller wrote:
> I figure out, some more information should be useful: 
> - Debian 3.1 , fresh install
> - Sources downloaded as given in the wiki howto
> 
> Maybe this is about gcc? My gcc version is 4.0.2 20050725 (prerelease) (Debian 
> 4.0.1-3)

I recently build Kolab 2.0.0 on Debian 3.1 and it worked out of the
box. The resulting binaries are even uploaded to the ftp servers
of Kolab.

However, the gcc version of Debian 3.1 is:
gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)

Have you followed the installation instructions as described in
1st.README ?

Best

	Jan

-- 
Jan-Oliver Wagner               http://intevation.de/~jan/
Intevation GmbH                      http://intevation.de/
Kolab Konsortium               http://kolab-konsortium.de/
FreeGIS                                http://freegis.org/



From jan at intevation.de  Wed Aug  3 11:14:11 2005
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Wed, 3 Aug 2005 11:14:11 +0200
Subject: [Kolab-devel] Spanish translation
In-Reply-To: <BAY18-F103882D5D2DB693635A0FAAEC20@phx.gbl>
References: <BAY18-F103882D5D2DB693635A0FAAEC20@phx.gbl>
Message-ID: <20050803091411.GB29851@intevation.de>

On Tue, Aug 02, 2005 at 10:28:52PM +0000, pier jose gotta perez wrote:
> Is there already an spanish translation in progress?

none that I am aware of.

> How can I help in the translation project?

Any help is appreciated.

Are you familiar with the gettext technologies (po files)?

The locale stuff in CVS is located here:
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/kolab-webadmin/kolab-webadmin/php/admin/locale/

Best

	Jan
-- 
Jan-Oliver Wagner               http://intevation.de/~jan/
Intevation GmbH                      http://intevation.de/
Kolab Konsortium               http://kolab-konsortium.de/
FreeGIS                                http://freegis.org/



From kolab-issues at intevation.de  Wed Aug  3 11:47:48 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 03 Aug 2005 09:47:48 +0000
Subject: [Kolab-devel] [issue863] Crash when selectiong regular imap account
	for groupware folders
Message-ID: <1123062468.04.0.553778997082.issue863@intevation.de>


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

Report with 2.0rc3 client packages:   
   
If you selected the groupware folder to be in a regular imap account  
(In this special case it was on an exchange), 
Kontact crashes. 
 
Till wanted to test how we can prevent this effectively that  
this selection is made.

----------
assignedto: till
messages: 5214
nosy: bernhard, till
priority: bug
status: unread
title: Crash when selectiong regular imap account for groupware folders
topic: kde client
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue863>
________________________________________________



From kolab-issues at intevation.de  Wed Aug  3 11:57:24 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 03 Aug 2005 09:57:24 +0000
Subject: [Kolab-devel] [issue864] freebusy display takes internal or does
	not honor "nobody" annotation
Message-ID: <1123063044.74.0.387131896515.issue864@intevation.de>


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

KDE client 2.0rc3: 
 
A user has two calendars. 
He switches the freebusy relevancy to "nobody" for the second one. 
This works fine as other people do not have those appointments 
in the fb list anymore. 
 
On the other hand, if those user goes to its own freebusy view 
in the attendee dialog of Kontact, the appointments from this folder 
still can be seen. 
 
Question a): Does KOrganizer use the internal information here 
or does it fetch the own list? If it uses internal information, 
we need to honor the "nobody" attribute of the second folder. 
 
b) If we get this from the server always, is this the xfb? 
Might there be a problem with xfb creation and the annotation flags?

----------
assignedto: till
messages: 5216
nosy: bernhard, bh, david, till
priority: minor bug
status: unread
title: freebusy display takes internal or does not honor "nobody" annotation
topic: kde client
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue864>
________________________________________________



From kolab-issues at intevation.de  Wed Aug  3 12:03:08 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 03 Aug 2005 10:03:08 +0000
Subject: [Kolab-devel] [issue865] Eating all memory when moving email.
Message-ID: <1123063388.02.0.108397969404.issue865@intevation.de>


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

KDE client 2.0 on Suse:    
    
There are two accounts: a) imap on the exchange, b) dimap on Kolab.    
   
Take an email on a) and use the menu to move it to a folder   
on b). Now Kontacts shows the clock and starts eating memory   
until the machine swaps and then cannot move.   
   
The process that hogs the memory is kontact.   
I am attaching a ps output  
and I will try to get the console debug output for more information.

----------
assignedto: till
files: ps
messages: 5217
nosy: bernhard, bh, david, till
priority: urgent
status: need-eg
title: Eating all memory when moving email.
topic: kde client
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue865>
________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ps
Type: application/octet-stream
Size: 1191 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050803/2fa857b6/attachment.obj>

From kolab-issues at intevation.de  Wed Aug  3 12:09:04 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 03 Aug 2005 10:09:04 +0000
Subject: [Kolab-devel] [issue866] email: default charset when email has none
	given
Message-ID: <1123063744.47.0.621163026064.issue866@intevation.de>


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

KDE client 2.0:    
This is a wish I have heard from two sides now:  
  
I an emails comes in and has no charset given, 
it would be nice to have a default charset kmail would fall back 
in this case. AFAIK kmail can only configure the charset that 
will overrule all given charsets and not the default charset if non is givben. 
 
Question: Is there a place to configure the default charset? 
If not: How much effort would it be to do it?

----------
assignedto: till
messages: 5218
nosy: bernhard, bh, david, till
priority: wish
status: unread
title: email: default charset when email has none given
topic: kde client
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue866>
________________________________________________



From kolab-issues at intevation.de  Wed Aug  3 12:13:18 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 03 Aug 2005 10:13:18 +0000
Subject: [Kolab-devel] [issue867] Attendee dialog shortcut for new does not
	work in German
Message-ID: <1123063998.08.0.740599033342.issue867@intevation.de>


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

KDE Proko2.0 on Suse 9.1, German:  
  
Open an appointment, try to add attendees.  
N is underlined, but still Alt-N does not work.  
  
What can we do about this?

----------
assignedto: till
messages: 5219
nosy: bernhard, bh, till
priority: minor bug
status: unread
title: Attendee dialog shortcut for new does not work in German
topic: kde client
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue867>
________________________________________________



From kolab-issues at intevation.de  Wed Aug  3 14:34:24 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 03 Aug 2005 12:34:24 +0000
Subject: [Kolab-devel] [issue868] Directly move appointment in fb diagram.
Message-ID: <1123072464.22.0.989037631139.issue868@intevation.de>


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

KDE client 2.0: 
 
This is a wish to move an appointment around by dragging 
the start and the beginning of the appointment in the freebusy chart. 
What effort would it be?

----------
assignedto: david
messages: 5222
nosy: bernhard, david, till
priority: wish
status: unread
title: Directly move appointment in fb diagram.
topic: kde client
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue868>
________________________________________________



From bgmilne at obsidian.co.za  Wed Aug  3 17:55:56 2005
From: bgmilne at obsidian.co.za (Buchan Milne)
Date: Wed, 03 Aug 2005 17:55:56 +0200
Subject: [Kolab-devel] Upgrading to db 4.3
In-Reply-To: <200508021918.39013.radoeka@xs4all.nl>
References: <s9zvf2qq62i.fsf@thetis.intevation.de>	<s9zll3k8l97.fsf@thetis.intevation.de>	<42EF8B8C.4000800@obsidian.co.za>
	<200508021918.39013.radoeka@xs4all.nl>
Message-ID: <42F0E90C.2050503@obsidian.co.za>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Bos wrote:
> Op dinsdag 2 augustus 2005 17:04, schreef Buchan Milne:
> 
>>2.3.x of course does have some nice features, but taking advantage of
>>them would be a lot of work (although taking advantage of them would
>>reduce the complexity of Kolab quite a bit I think ..).
> 
> 
> What advantages and how would it reduce kolab's complexity?

No need to manage the slapd.conf files (since OL 2.3 can be configured
via LDAP using the config backend), replication to the Kolab daemon can
be dropped in favour of using sync replication ...

Some of these issues aren't as prevalent in the "package all the
software we need seperately, even if the distribution we're on provides
the software we need" setup, but it is for distributions who do many
things with OpenLDAP, postfix, Cyrus-imap (and Kolab is only one
combination).

Regards,
Buchan

- --
Buchan Milne                              Systems Architect
Obsidian Systems                  http://www.obsidian.co.za
B.Eng          RHCE (803004789010797),LPIC-1 (LPI000074592)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC8OkMrJK6UGDSBKcRAk6CAJ949MvpEOm37xkrf3fglu3ZCQh1QACglC/s
zAx6kBWjae5k6Dg4VtHxnbQ=
=R+da
-----END PGP SIGNATURE-----



From markus at relix.de  Wed Aug  3 18:52:26 2005
From: markus at relix.de (Markus Heller)
Date: Wed, 3 Aug 2005 18:52:26 +0200
Subject: [Kolab-devel] Problem installing Kolab2
In-Reply-To: <20050803090202.GA29851@intevation.de>
References: <200508030031.03298.markus@relix.de>
	<200508030058.58294.markus@relix.de>
	<20050803090202.GA29851@intevation.de>
Message-ID: <200508031852.27092.markus@relix.de>

Hi Jan,

that's true: "/usr/bin/gcc" is only a symlink to a specific version of gcc, 
and mine pointed to gcc 4. I installed gcc-3.3 and recreated the symlink 
accordingly, pointing to gcc3.3 and then I restarted the compilation 
procedure - successfully. 

As a matter of fact I can state that Kolab2.0.0 does not compile with gcc 
version 4. Maybe this is of some interest to the developers who should keep a 
notice somewhere, preferably in the 1st.readme file. 

Best wishes,
Markus


Am Mittwoch, 3. August 2005 11:02 schrieb Jan-Oliver Wagner:
> On Wed, Aug 03, 2005 at 12:58:57AM +0200, Markus Heller wrote:
> > I figure out, some more information should be useful:
> > - Debian 3.1 , fresh install
> > - Sources downloaded as given in the wiki howto
> >
> > Maybe this is about gcc? My gcc version is 4.0.2 20050725 (prerelease)
> > (Debian 4.0.1-3)
>
> I recently build Kolab 2.0.0 on Debian 3.1 and it worked out of the
> box. The resulting binaries are even uploaded to the ftp servers
> of Kolab.
>
> However, the gcc version of Debian 3.1 is:
> gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)
>
> Have you followed the installation instructions as described in
> 1st.README ?
>
> Best
>
> 	Jan



From radoeka at xs4all.nl  Wed Aug  3 19:02:59 2005
From: radoeka at xs4all.nl (Richard Bos)
Date: Wed, 3 Aug 2005 19:02:59 +0200
Subject: [Kolab-devel] Problem installing Kolab2
In-Reply-To: <200508031852.27092.markus@relix.de>
References: <200508030031.03298.markus@relix.de>
	<20050803090202.GA29851@intevation.de>
	<200508031852.27092.markus@relix.de>
Message-ID: <200508031903.00419.radoeka@xs4all.nl>

Op woensdag 3 augustus 2005 18:52, schreef Markus Heller:
> that's true: "/usr/bin/gcc" is only a symlink to a specific version of gcc,
> and mine pointed to gcc 4. I installed gcc-3.3 and recreated the symlink
> accordingly, pointing to gcc3.3 and then I restarted the compilation
> procedure - successfully.
>
> As a matter of fact I can state that Kolab2.0.0 does not compile with gcc
> version 4. 

That would impy that kolab would not work on the next suse, as that will be 
compiled with gcc-4...

-- 
Richard Bos
Without a home the journey is endless



From andreas at conectiva.com.br  Wed Aug  3 20:22:31 2005
From: andreas at conectiva.com.br (Andreas Hasenack)
Date: Wed, 3 Aug 2005 15:22:31 -0300
Subject: [Kolab-devel] Problem installing Kolab2
In-Reply-To: <200508031903.00419.radoeka@xs4all.nl>
References: <200508030031.03298.markus@relix.de>
	<20050803090202.GA29851@intevation.de>
	<200508031852.27092.markus@relix.de>
	<200508031903.00419.radoeka@xs4all.nl>
Message-ID: <20050803182230.GB6914@conectiva.com.br>

On Wed, Aug 03, 2005 at 07:02:59PM +0200, Richard Bos wrote:
> Op woensdag 3 augustus 2005 18:52, schreef Markus Heller:
> > that's true: "/usr/bin/gcc" is only a symlink to a specific version of gcc,
> > and mine pointed to gcc 4. I installed gcc-3.3 and recreated the symlink
> > accordingly, pointing to gcc3.3 and then I restarted the compilation
> > procedure - successfully.
> >
> > As a matter of fact I can state that Kolab2.0.0 does not compile with gcc
> > version 4. 
> 
> That would impy that kolab would not work on the next suse, as that will be 
> compiled with gcc-4...

Many next versions of distributions will be using gcc-4. But new openpkg
builds fine, and kolab is upgrading openpkg, so things will work out
find I think.



From aseigo at kde.org  Wed Aug  3 20:54:58 2005
From: aseigo at kde.org (Aaron J. Seigo)
Date: Wed, 03 Aug 2005 12:54:58 -0600
Subject: [Kolab-devel] Re: Kolab / Horde LDAP missmatch?
In-Reply-To: <20050803063635.5219B1D8F34@supertolla.itapac.net>
References: <00dd01c596b2$cb217600$e900a8c0@ewuhome>
	<20050802203617.EE4F61D8F81@supertolla.itapac.net>
	<20050803063635.5219B1D8F34@supertolla.itapac.net>
Message-ID: <200508031254.58665.aseigo@kde.org>

On Wednesday 03 August 2005 12:36, Fabio Pietrosanti wrote:
> Imho your porposed approach is good.
> Integrate the horde ldap schema permanently, then an if statement in
> user.php that look at a specified ldap field which could be
> horde-integration: 1 .
>
> I would really appreciate that patch.

see attached.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kolab_hordeintegration.tar.gz
Type: application/x-gzip
Size: 1171 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050803/98056580/attachment.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050803/98056580/attachment.sig>

From kolab-issues at intevation.de  Wed Aug  3 22:25:29 2005
From: kolab-issues at intevation.de (Gavin Hamill)
Date: Wed, 03 Aug 2005 20:25:29 +0000
Subject: [Kolab-devel] [issue869] Recurring event from Outlook causes insane
	freebusy
Message-ID: <1123100729.35.0.557460524038.issue869@intevation.de>


New submission from Gavin Hamill <gdh at laterooms.com>:

I originally mailed this to Joon directly, but it may be a more general thing.   
   
I'm using Outlook 2000 with the gold release of Kolab 2.0 and Toltec Connector 
RC4 - I'm having extreme bother with recurring appointments.  
  
e.g. I create a new item in my calendar, add   
'meeting.room at groupware.laterooms.com' as a participant (their freebusy   
appears in outlook OK), set it to recur every Wednesday from 10th Aug onwards   
at 1300-1330, and press Send.  
  
I see the normal activity in kolab's postfix.log, and I get an email reply   
from kolab saying that Meeting Room has accepted my invitation.  
  
(Meeting Room is a 'resource' account Kolab user which auto accepts if there   
is no conflict)  
  
If I look at the source of the email in Meeting Room's 'Calendar' IMAP folder   
I see this:  
  
<?xml version="1.0"?>  
<event version="1.0">  
  <uid>040000008200E00074C5B7101A82E00800000000703F24604998C501000000000000000010000000A8D98009122ACA4D82E690FB3061AE32</uid>  
  <organizer>  
    <display-name></display-name>  
    <smtp-address>gdh at laterooms.com</smtp-address>  
  </organizer>  
  <summary>Wednesday lunchtime</summary>  
  <location></location>  
  <body>When: Occurs every Wednesday effective 10/08/2005 from 13:00 to 13:30   
(GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London.&#xD;  
&#xD;  
*~*~*~*~*~*~*~*~*~*&#xD;  
&#xD;  
&#xD;  
</body>  
  <start-date>1970-01-01T00:00:00Z</start-date>  
  <end-date>1970-01-01T00:00:00Z</end-date>  
  <attendee>  
    <display-name>"Meeting Room"</display-name>  
    <smtp-address>meeting.room at groupware.laterooms.com</smtp-address>  
    <status></status>  
    <request-response>true</request-response>  
    <role>req-participant</role>  
  </attendee>  
  <alarm>15</alarm>  
  <recurrence cycle="weekly">  
    <day>wednesday</day>  
    <interval>1</interval>  
    <range type="none"/>  
  </recurrence>  
</event>  
  
Note the start-date and end-date - they are complete nonsense :(((  
  
Now when I look at the source for   
http://freebusy:freebusy at groupware/freebusy/meeting.room at groupware.laterooms.com.ifb   
it takes 15 seconds to think.. and then I see this:  
  
BEGIN:VCALENDAR PRODID:-//proko2//freebusy 1.0//EN METHOD:PUBLISH VERSION:2.0   
BEGIN:VFREEBUSY ORGANIZER:MAILTO:meeting.room at groupware.laterooms.com   
DTSTAMP:20050803T154129Z   
URL:http://groupware/freebusy/meeting.room at groupware.laterooms.com.ifb   
DTSTART:20050802T230000Z DTEND:20051001T230000Z   
FREEBUSY:19700103T235959Z/19700103T235959Z   
FREEBUSY:19700110T235959Z/19700110T235959Z   
FREEBUSY:19700117T235959Z/19700117T235959Z   
FREEBUSY:19700124T235959Z/19700124T235959Z  
  
and so on, for every week until September 2005!  
  
Help! :)

----------
messages: 5225
nosy: gdhgdh
priority: bug
status: unread
title: Recurring event from Outlook causes insane freebusy
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue869>
________________________________________________



From hansjuergen.riess at t-online.de  Wed Aug  3 20:29:20 2005
From: hansjuergen.riess at t-online.de (hansjuergen.riess at t-online.de)
Date: Wed, 03 Aug 2005 20:29:20 +0200 (CEST)
Subject: [Kolab-devel] Compile error apache kolab 2
Message-ID: <1123093510.42f10c0670ee3@modem.webmail.t-online.de>

Hello Andreas,

thank you for the hint. I solved the problem. It was the

http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/imap/imap.annotate.patch

Yours sincerly

Hansjuergen



From elliot at otchet.net  Wed Aug  3 21:34:01 2005
From: elliot at otchet.net (Elliot Otchet)
Date: Wed, 3 Aug 2005 15:34:01 -0400
Subject: [Kolab-devel] LDAP DN reorganization.
Message-ID: <20050803193409.3162A4068@mail.otchet.net>

Hi,

 

I'm relatively new to the Kolab development world, and I'm really impressed
with the amount of work completed in this project.

 

As I've been looking through the code base and reviewing my Kolab 2
installation, I've come across an issue with LDAP.  It seems that Kolab 2
uses the First Name and Last Name attributes to compose the base cn
attribute of an entry's distinguished name (DN).  In my experience, this
presents a challenge (and a kolab UI error) when you have two people with
the same names.  Here in the States, that can be a common problem.  Is their
a commonly known drawback in other areas of Kolab2 to use the unique ID
attribute for the DN?  Since UIDs must be unique, we could avoid name
collisions in the cn=internal branch of the tree.

 

Thanks,

 

Elliot

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050803/2b04f716/attachment.html>

From kbaker at missionvi.com  Wed Aug  3 22:50:40 2005
From: kbaker at missionvi.com (Kevin Baker)
Date: Wed, 3 Aug 2005 13:50:40 -0700 (PDT)
Subject: [Kolab-devel] Kolab imap migration - ACL for imapsync
Message-ID: <54612.208.240.243.170.1123102240.squirrel@mail.missionvi.com>

I am looking to use imapsync to migrate about 300 accounts.

I was hoping to use mailsync or imapsync.

I was noticing that both require a password. Could I
possibly setup ACL perms for one account to migrate all of
them?

Is there a best practices way to do this?




From kolab-issues at intevation.de  Thu Aug  4 12:19:44 2005
From: kolab-issues at intevation.de (Hamish)
Date: Thu, 04 Aug 2005 10:19:44 +0000
Subject: [Kolab-devel] [issue870] Web gui action log
Message-ID: <1123150784.24.0.392608633517.issue870@intevation.de>


New submission from Hamish <lists at subvs.co.uk>:

I am in the unfortunate position that there are other (unskilled) people who log
in to the web gui as maintainer/manager and make changes. While most of the
changes are harmless, occasionally, due to either lack of knowledge, or just
gross incompetence, a change is made that actually causes harm. What I propose
is a log of all changes made using the web gui. This will allow the unfortunate
admins who need to give gui access to others to retrace the steps of the monkey,
and thus fix things more quickly.

----------
messages: 5228
nosy: captainmish
priority: wish
status: unread
title: Web gui action log
topic: proko2, server, web admin
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue870>
________________________________________________



From jan at intevation.de  Fri Aug  5 11:42:38 2005
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Fri, 5 Aug 2005 11:42:38 +0200
Subject: [Kolab-devel] btw, an intro to why i'm suddenly here =P
In-Reply-To: <200507260024.01700.martin.konold@erfrakon.de>
References: <200506231956.25038.aseigo@kde.org>
	<200507231007.19437.martin.konold@erfrakon.de>
	<200507251907.43132.bernhard@intevation.de>
	<200507260024.01700.martin.konold@erfrakon.de>
Message-ID: <20050805094238.GA3041@intevation.de>

On Tue, Jul 26, 2005 at 12:24:00AM +0200, Martin Konold wrote:
> Am Montag 25 Juli 2005 19:07 schrieb Bernhard Reiter:
> > Can you be more specific?
> 
> E.g. there is a useless link to the German client install doc. (URLs point at 
> sxw with broken mime-type are useless.)
> Better use html or pdf.

added a pdf.

-- 
Jan-Oliver Wagner               http://intevation.de/~jan/
Intevation GmbH                      http://intevation.de/
Kolab Konsortium               http://kolab-konsortium.de/
FreeGIS                                http://freegis.org/



From jan at intevation.de  Fri Aug  5 11:44:42 2005
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Fri, 5 Aug 2005 11:44:42 +0200
Subject: [Kolab-devel] Roadmap web page
Message-ID: <20050805094442.GB3041@intevation.de>

Hi,

I assembled a Roadmap web page from the information
I gathered on the mailing list.
See http://www.kolab.org/roadmap.html

Best

	Jan
-- 
Jan-Oliver Wagner               http://intevation.de/~jan/
Intevation GmbH                      http://intevation.de/
Kolab Konsortium               http://kolab-konsortium.de/
FreeGIS                                http://freegis.org/



From radoeka at xs4all.nl  Fri Aug  5 11:48:47 2005
From: radoeka at xs4all.nl (radoeka)
Date: Fri, 5 Aug 2005 11:48:47 +0200
Subject: [Kolab-devel] Roadmap web page
In-Reply-To: <20050805094442.GB3041@intevation.de>
References: <20050805094442.GB3041@intevation.de>
Message-ID: <20050805094847.GC86533@xs4all.nl>

On Fri, Aug 05, 2005 at 11:44:42AM +0200, Jan-Oliver Wagner wrote:
> Hi,
> 
> I assembled a Roadmap web page from the information
> I gathered on the mailing list.
> See http://www.kolab.org/roadmap.html

Why not in the wiki?

--
Richard



From jan at intevation.de  Fri Aug  5 12:19:42 2005
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Fri, 5 Aug 2005 12:19:42 +0200
Subject: [Kolab-devel] Roadmap web page
In-Reply-To: <20050805094847.GC86533@xs4all.nl>
References: <20050805094442.GB3041@intevation.de>
	<20050805094847.GC86533@xs4all.nl>
Message-ID: <20050805101942.GA3117@intevation.de>

On Fri, Aug 05, 2005 at 11:48:47AM +0200, radoeka wrote:
> On Fri, Aug 05, 2005 at 11:44:42AM +0200, Jan-Oliver Wagner wrote:
> > I assembled a Roadmap web page from the information
> > I gathered on the mailing list.
> > See http://www.kolab.org/roadmap.html
> 
> Why not in the wiki?

the roadmap is not a wishlist. It is something some people
might take very serious and would not be happy
to see items pop up and vanish from the Roadmap again.

Thus I thought it is best to reduce the access to those
who have CVS write access anyway.

We could link an additional wiki page where anyone may
add ideas (if anyone likes to setup such a page).

Best

	Jan
-- 
Jan-Oliver Wagner               http://intevation.de/~jan/
Intevation GmbH                      http://intevation.de/
Kolab Konsortium               http://kolab-konsortium.de/
FreeGIS                                http://freegis.org/



From mose at mose.fr  Fri Aug  5 15:51:52 2005
From: mose at mose.fr (mose)
Date: Fri, 5 Aug 2005 15:51:52 +0200
Subject: [Kolab-devel] Roadmap web page
In-Reply-To: <20050805101942.GA3117@intevation.de>
References: <20050805094442.GB3041@intevation.de>
	<20050805094847.GC86533@xs4all.nl>
	<20050805101942.GA3117@intevation.de>
Message-ID: <20050805135151.GU13948@mose.fr>

le Fri, Aug 05, 2005 at 12:19:42PM +0200 par Jan-Oliver Wagner :
> On Fri, Aug 05, 2005 at 11:48:47AM +0200, radoeka wrote:
> > On Fri, Aug 05, 2005 at 11:44:42AM +0200, Jan-Oliver Wagner wrote:
> > > I assembled a Roadmap web page from the information
> > > I gathered on the mailing list.
> > > See http://www.kolab.org/roadmap.html
> > 
> > Why not in the wiki?
> 
> the roadmap is not a wishlist. It is something some people
> might take very serious and would not be happy
> to see items pop up and vanish from the Roadmap again.
> 
> Thus I thought it is best to reduce the access to those
> who have CVS write access anyway.
> 
> We could link an additional wiki page where anyone may
> add ideas (if anyone likes to setup such a page).

- I didn't find any wishlist on the wiki, so I created that page.
http://wiki.kolab.org/index.php/Kolab2_Whislist


cheers,
mose



From martin.konold at erfrakon.de  Fri Aug  5 19:00:21 2005
From: martin.konold at erfrakon.de (Martin Konold)
Date: Fri, 5 Aug 2005 19:00:21 +0200
Subject: [Kolab-devel] tiny patch for web admin interface
In-Reply-To: <20050801123244.GA25184@intevation.de>
References: <20050801123244.GA25184@intevation.de>
Message-ID: <200508051900.22454.martin.konold@erfrakon.de>

Am Montag 01 August 2005 14:32 schrieb Jan-Oliver Wagner:

Hi Jan,

> I did a little patch for the web admin interface to help
> the beginners (attached).

> them during administration Kolab)?
> Just commit (to HEAD?) or post here?

Only commit it to HEAD as otherwise you would break all translations.

Regards,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From martin.konold at erfrakon.de  Sat Aug  6 09:14:05 2005
From: martin.konold at erfrakon.de (Martin Konold)
Date: Sat, 6 Aug 2005 09:14:05 +0200
Subject: [Kolab-devel] Re: Kolab / Horde LDAP missmatch?
In-Reply-To: <200508031254.58665.aseigo@kde.org>
References: <00dd01c596b2$cb217600$e900a8c0@ewuhome>
	<20050803063635.5219B1D8F34@supertolla.itapac.net>
	<200508031254.58665.aseigo@kde.org>
Message-ID: <200508060914.06558.martin.konold@erfrakon.de>

Am Mittwoch 03 August 2005 20:54 schrieb Aaron J. Seigo:

Hi Aaron,

> On Wednesday 03 August 2005 12:36, Fabio Pietrosanti wrote:

> > I would really appreciate that patch.
>
> see attached.

before any Horde support can be integrated into an official Kolab release the 
severe Horde security issues (e.g. connecting as manager to LDAP) need to be 
solved.

Regards,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From aseigo at kde.org  Sun Aug  7 00:43:41 2005
From: aseigo at kde.org (Aaron J. Seigo)
Date: Sat, 06 Aug 2005 16:43:41 -0600
Subject: [Kolab-devel] Re: Kolab / Horde LDAP missmatch?
In-Reply-To: <200508060914.06558.martin.konold@erfrakon.de>
References: <00dd01c596b2$cb217600$e900a8c0@ewuhome>
	<200508031254.58665.aseigo@kde.org>
	<200508060914.06558.martin.konold@erfrakon.de>
Message-ID: <200508061643.41507.aseigo@kde.org>

On Saturday 06 August 2005 01:14, Martin Konold wrote:
> Am Mittwoch 03 August 2005 20:54 schrieb Aaron J. Seigo:
>
> Hi Aaron,
>
> > On Wednesday 03 August 2005 12:36, Fabio Pietrosanti wrote:
> > > I would really appreciate that patch.
> >
> > see attached.
>
> before any Horde support can be integrated into an official Kolab release
> the severe Horde security issues (e.g. connecting as manager to LDAP) need
> to be solved.

agreed. but right now Horde is the only web mail solution (AFAIK?), there's 
documentation for it on the kolab website and people are using it. this patch 
simply allows people to do so without getting the impression that kolab is 
broken.

there's no need to ship horde due to this patch. this patch simply makes kolab 
admin still work when using horde.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050806/59791225/attachment.sig>

From martin.konold at erfrakon.de  Sun Aug  7 09:56:20 2005
From: martin.konold at erfrakon.de (Martin Konold)
Date: Sun, 7 Aug 2005 09:56:20 +0200
Subject: [Kolab-devel] Re: Kolab / Horde LDAP missmatch?
In-Reply-To: <200508061643.41507.aseigo@kde.org>
References: <00dd01c596b2$cb217600$e900a8c0@ewuhome>
	<200508060914.06558.martin.konold@erfrakon.de>
	<200508061643.41507.aseigo@kde.org>
Message-ID: <200508070956.21828.martin.konold@erfrakon.de>

Am Sonntag 07 August 2005 00:43 schrieb Aaron J. Seigo:

Hi Aaron.

> > before any Horde support can be integrated into an official Kolab release
> > the severe Horde security issues (e.g. connecting as manager to LDAP)
> > need to be solved.
>
> agreed. but right now Horde is the only web mail solution (AFAIK?)

No, Kolab works with any IMAP web mail solution for plain email but has 
incomplete and insecure/unstable support for groupware functionality from 
horde.

> there's no need to ship horde due to this patch. this patch simply makes
> kolab admin still work when using horde.

I prefer to document how to use horde with kolab in our wiki. I addition we 
can offer your valuable patches on a kolab.org server for people who have 
read the wiki.

In general I currently don't feel confident about horde as the future web 
based kolab client. There are serious issues (e.g. security/design) not 
beeing solved for a very long time. I have the impression that maybe a new 
start with a new design is required.

Regards,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From aseigo at kde.org  Sun Aug  7 10:16:33 2005
From: aseigo at kde.org (Aaron J. Seigo)
Date: Sun, 07 Aug 2005 02:16:33 -0600
Subject: [Kolab-devel] Re: Kolab / Horde LDAP missmatch?
In-Reply-To: <200508070956.21828.martin.konold@erfrakon.de>
References: <00dd01c596b2$cb217600$e900a8c0@ewuhome>
	<200508061643.41507.aseigo@kde.org>
	<200508070956.21828.martin.konold@erfrakon.de>
Message-ID: <200508070216.39608.aseigo@kde.org>

On Sunday 07 August 2005 01:56, Martin Konold wrote:
> Am Sonntag 07 August 2005 00:43 schrieb Aaron J. Seigo:
> > > before any Horde support can be integrated into an official Kolab
> > > release the severe Horde security issues (e.g. connecting as manager to
> > > LDAP) need to be solved.
> >
> > agreed. but right now Horde is the only web mail solution (AFAIK?)
>
> No, Kolab works with any IMAP web mail solution for plain email but has
> incomplete and insecure/unstable support for groupware functionality from
> horde.

yes, only groupware solution available. without calendaring, webmail is vastly 
less interesting / useful.

> > there's no need to ship horde due to this patch. this patch simply makes
> > kolab admin still work when using horde.
>
> I prefer to document how to use horde with kolab in our wiki. I addition we
> can offer your valuable patches on a kolab.org server for people who have
> read the wiki.

fair 'nuff

> In general I currently don't feel confident about horde as the future web
> based kolab client. There are serious issues (e.g. security/design) not
> beeing solved for a very long time. I have the impression that maybe a new
> start with a new design is required.

i would totally support this as horde has been the biggest liability and 
headache with kolab2 for me, and the interface is overly complex for many 
users.

do you have any ideas / premonitions as to what direction might be realistic / 
feasible / to be expected?

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050807/b93f330a/attachment.sig>

From martin.konold at erfrakon.de  Mon Aug  8 08:35:57 2005
From: martin.konold at erfrakon.de (Martin Konold)
Date: Mon, 8 Aug 2005 08:35:57 +0200
Subject: [Kolab-devel] Re: Kolab / Horde LDAP missmatch?
In-Reply-To: <200508070216.39608.aseigo@kde.org>
References: <00dd01c596b2$cb217600$e900a8c0@ewuhome>
	<200508070956.21828.martin.konold@erfrakon.de>
	<200508070216.39608.aseigo@kde.org>
Message-ID: <200508080835.58653.martin.konold@erfrakon.de>

Am Sonntag 07 August 2005 10:16 schrieb Aaron J. Seigo:

Hi Aaron,

> do you have any ideas / premonitions as to what direction might be
> realistic / feasible / to be expected?

Yes, I have ideas but ideas are not worth much as long as noone is doing the 
actual work. This is the reason why I won't dismiss Horde before I cannot 
offer something better at the same time.

Maybe something like proko3 will help here.

Yours,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From kolab-issues at intevation.de  Tue Aug  9 10:39:16 2005
From: kolab-issues at intevation.de (Tomasz Chmielewski)
Date: Tue, 09 Aug 2005 08:39:16 +0000
Subject: [Kolab-devel] [issue871] Live CD with a Horde web client
Message-ID: <1123576756.2.0.439492291137.issue871@intevation.de>


New submission from Tomasz Chmielewski <mangoo at interia.pl>:

It would be nice if we had a Kolab Live CD with a Horde web client integrated.

Now the only Kolab Live CD we have is made by Konsec, but it doesn't include a
Horde web client.

It shouldn't be hard to create if someone has an already running Kolab + Horde.

----------
messages: 5239
nosy: mangoo
priority: wish
status: unread
title: Live CD with a Horde web client
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue871>
________________________________________________



From bh at intevation.de  Tue Aug  9 12:43:00 2005
From: bh at intevation.de (Bernhard Herzog)
Date: Tue, 09 Aug 2005 12:43:00 +0200
Subject: [Kolab-devel] Kolab Server 2.0.1 RC 1 released
Message-ID: <s9zoe87e6h7.fsf@thetis.intevation.de>


Hi all,

we've been preparing the 2.0.1 release of the Kolab server for a while
now.  The big change is the move to OpenPKG as the base platform.  This
means a lot of changes since 2.0.0.  Almost all rpms in the release are
new!  Given this, we need to get it tested more thoroughly before
declaring it stable.  Therefore we make a release candidate available
now.  For a list of changes, see below.

I've just uploaded the files, so it may take a while still before it
shows up on the mirrors.  You'll find the relase in the
beta/kolab-server-2.0.1-rc-1 directory.

Please test this release and report your experiences with it, so that we
know how well it works for you.


   Bernhard



Release notes Kolab2 Server
(Version 20050808, Kolab server 2.0.1 RC 1)


For upgrading and installation instructions, please refer to the
1st.README file in the source directory.

Note that this is a release candidate for 2.0.1.  The many new packages
mean an increased risk of problems, so we'd like to see this update
tested as widely as possible before the real 2.0.1 release.


Changes since 2.0 final:

    - Switch to OpenPKG 2.4.  As a result of this, practically all
      packages have been updated.

      Up to now the Kolab server used OpenPKG 2.2.  The current release
      of OpenPKG is 2.4, though, and the OpenPKG project only provides
      security advisories and updates for the most recent release and
      its immediate predecessor.  Therefore moving to OpenPKG 2.4 is
      necessary to benefit from the OpenPKG updates.

      The db package has not been updated to the version from OpenPKG
      2.4 yet to avoid potential stability problems with OpenLDAP.

    - A new clamav package fixing a buffer overflow. 
      This is the package mentioned in the kolab security advisory 02
      http://kolab.org/security/kolab-vendor-notice-02.txt

    - better deletion handling.  Now more objects are deleted using
      kolabDeleteFlag (issues 845 and 855)

    - perl-kolab 5.8.5-20050530 -> 5.8.7-2.0_20050719

      * Fixing:
      	  Issue845 (groupOfNames cleanup handling)
	  Issue855 (make shared folder and external deletion same as users)

    - kolab-webadmin 20050616 -> 20050620

      * Fixing:
      	  Issue845 (groupOfNames cleanup handling)
	  Issue855 (make shared folder and external deletion same as users)

    - kolabd 20050615 -> 20050722

      * Fixing:
      	  Issue791 (automatic invitation handling uses http instead of https)
      	  Issue845 (groupOfNames cleanup handling)
      	  Issue851 (kolabquotawarn uses system sendmail)
	  Issue855 (make shared folder and external deletion same as users)

    - kolab-resource-handlers 20050615 -> 20050727

      * Fixing:
      	  Issue825 (Bad error handling of kolabmailboxfilter)






From radoeka at xs4all.nl  Tue Aug  9 13:04:23 2005
From: radoeka at xs4all.nl (radoeka)
Date: Tue, 9 Aug 2005 13:04:23 +0200
Subject: [Kolab-devel] Kolab Server 2.0.1 RC 1 released
In-Reply-To: <s9zoe87e6h7.fsf@thetis.intevation.de>
References: <s9zoe87e6h7.fsf@thetis.intevation.de>
Message-ID: <20050809110423.GC46063@xs4all.nl>

On Tue, Aug 09, 2005 at 12:43:00PM +0200, Bernhard Herzog wrote:
> 
> Hi all,
> 
> we've been preparing the 2.0.1 release of the Kolab server for a while
> now.  The big change is the move to OpenPKG as the base platform.  This
> means a lot of changes since 2.0.0.  Almost all rpms in the release are
> new!  Given this, we need to get it tested more thoroughly before
> declaring it stable.  Therefore we make a release candidate available
> now.  For a list of changes, see below.

Given this, I would not call this just a bug fix release, but a "major"
upgrade.  Hence the version should state this and I think 2.0.1 does
not signal this big increase.  Wouldn't 2.1 be a better version number?

--
Richard



From martin.konold at erfrakon.de  Tue Aug  9 13:58:44 2005
From: martin.konold at erfrakon.de (Martin Konold)
Date: Tue, 9 Aug 2005 13:58:44 +0200
Subject: [Kolab-devel] Kolab Server 2.0.1 RC 1 released
In-Reply-To: <20050809110423.GC46063@xs4all.nl>
References: <s9zoe87e6h7.fsf@thetis.intevation.de>
	<20050809110423.GC46063@xs4all.nl>
Message-ID: <200508091358.45478.martin.konold@erfrakon.de>

Am Dienstag 09 August 2005 13:04 schrieb radoeka:

> Given this, I would not call this just a bug fix release, but a "major"
> upgrade.  Hence the version should state this and I think 2.0.1 does
> not signal this big increase.  Wouldn't 2.1 be a better version number?

We think that 2.0.1 is fine because we added no significant new features.

You may consult http://www.kolab.org/roadmap.html

Regards,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker



From lists at pietrosanti.it  Tue Aug  9 14:31:37 2005
From: lists at pietrosanti.it (Fabio Pietrosanti)
Date: Tue, 09 Aug 2005 14:31:37 +0200
Subject: [Kolab-devel] Kolab Server 2.0.1 RC 1 released
In-Reply-To: <20050809110435.DD2491D8F70@supertolla.itapac.net>
References: <s9zoe87e6h7.fsf@thetis.intevation.de>
	<20050809110435.DD2491D8F70@supertolla.itapac.net>
Message-ID: <20050809123201.D6C251D8FB1@supertolla.itapac.net>

radoeka ha scritto:

>Given this, I would not call this just a bug fix release, but a "major"
>upgrade.  Hence the version should state this and I think 2.0.1 does
>not signal this big increase.  Wouldn't 2.1 be a better version number?
>  
>

The 2.1 version has not yet passed the quality assurance testing but if
you want to download it you can use
ftp://ftp.kdab.net/pub/kolab/server/current/ .

The biggest feature of 2.1, even if not already official, is multidomain
support.

Fabio



From radoeka at xs4all.nl  Tue Aug  9 14:45:43 2005
From: radoeka at xs4all.nl (radoeka)
Date: Tue, 9 Aug 2005 14:45:43 +0200
Subject: [Kolab-devel] Kolab Server 2.0.1 RC 1 released
In-Reply-To: <20050809123201.D6C251D8FB1@supertolla.itapac.net>
References: <s9zoe87e6h7.fsf@thetis.intevation.de>
	<20050809110435.DD2491D8F70@supertolla.itapac.net>
	<20050809123201.D6C251D8FB1@supertolla.itapac.net>
Message-ID: <20050809124543.GE46063@xs4all.nl>

On Tue, Aug 09, 2005 at 02:31:37PM +0200, Fabio Pietrosanti wrote:
> radoeka ha scritto:
> 
> >Given this, I would not call this just a bug fix release, but a "major"
> >upgrade.  Hence the version should state this and I think 2.0.1 does
> >not signal this big increase.  Wouldn't 2.1 be a better version number?
> >  
> >
> 
> The 2.1 version has not yet passed the quality assurance testing but if
> you want to download it you can use
> ftp://ftp.kdab.net/pub/kolab/server/current/ .
> 
> The biggest feature of 2.1, even if not already official, is multidomain
> support.

I'm aware of that; with my proposal 2.1 should be renamed to 2.2. 

--
Richard



From bart at verwilst.be  Tue Aug  9 13:38:10 2005
From: bart at verwilst.be (Bart Verwilst)
Date: Tue, 9 Aug 2005 13:38:10 +0200
Subject: [Kolab-devel] Kolab Server 2.0.1 RC 1 released
In-Reply-To: <20050809110423.GC46063@xs4all.nl>
References: <s9zoe87e6h7.fsf@thetis.intevation.de>
	<20050809110423.GC46063@xs4all.nl>
Message-ID: <200508091338.10416.bart@verwilst.be>

Hello!

My thoughts exactly..
And 2.2 for the multi-domain release or something..

Bye!

Op dinsdag 09 augustus 2005 13:04, schreef radoeka:
> On Tue, Aug 09, 2005 at 12:43:00PM +0200, Bernhard Herzog wrote:
> > Hi all,
> >
> > we've been preparing the 2.0.1 release of the Kolab server for a while
> > now.  The big change is the move to OpenPKG as the base platform.  This
> > means a lot of changes since 2.0.0.  Almost all rpms in the release are
> > new!  Given this, we need to get it tested more thoroughly before
> > declaring it stable.  Therefore we make a release candidate available
> > now.  For a list of changes, see below.
>
> Given this, I would not call this just a bug fix release, but a "major"
> upgrade.  Hence the version should state this and I think 2.0.1 does
> not signal this big increase.  Wouldn't 2.1 be a better version number?
>
> --
> Richard
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel



From alessandro.fiorino at gmail.com  Tue Aug  9 15:28:36 2005
From: alessandro.fiorino at gmail.com (Alessandro Fiorino)
Date: Tue, 9 Aug 2005 15:28:36 +0200
Subject: [Kolab-devel] Still problems compiling Kolab 2.0.1-rc on Fedora 4
Message-ID: <d790496105080906284f17ba5e@mail.gmail.com>

Although  the openpkg upgrade to version 2.4 the new release candidate
still doesn't compile on Fedora 4: the error is always the same

if /usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.   -DMAGIC='"/kolab/lib/openpkg/magic
"'  -DOPENPKG -DOPENPKG_LINUX -I/kolab/RPM/TMP/openpkg-2.4.2/zlib-1.2.3 -I/kolab
/RPM/TMP/openpkg-2.4.2/bzip2-1.0.3 -I/kolab/RPM/TMP/openpkg-2.4.2/beecrypt-4.1.2
 -D_GNU_SOURCE -D_REENTRANT -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-
prototypes -Wno-char-subscripts -MT file.o -MD -MP -MF ".deps/file.Tpo" \
  -c -o file.o `test -f 'file.c' || echo './'`file.c; \
then mv -f ".deps/file.Tpo" ".deps/file.Po"; \
else rm -f ".deps/file.Tpo"; exit 1; \
fi
In file included from /usr/include/inttypes.h:28,
                 from system.h:17,
                 from file.c:28:
/usr/include/stdint.h:49: error: duplicate 'unsigned'
/usr/include/stdint.h:49: error: two or more data types in declaration specifier
s
/usr/include/stdint.h:50: error: duplicate 'unsigned'
/usr/include/stdint.h:50: error: duplicate 'short'
/usr/include/stdint.h:52: error: duplicate 'unsigned'
/usr/include/stdint.h:52: error: two or more data types in declaration specifier
s
make[2]: *** [file.o] Error 1
make[2]: Leaving directory `/kolab/RPM/TMP/openpkg-2.4.2/rpm-4.2.1/file'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/kolab/RPM/TMP/openpkg-2.4.2/rpm-4.2.1'
make: *** [all] Error 2
+ exit 2
./openpkg.boot:ERROR: script returned non-null value
/tmp/obmtool.362.tmp: line 449: /kolab/RPM/PKG/openpkg-2.4.2-2.4.2.*-*-*.sh: No
such file or directory
obmtool:ERROR: bootstrapping failed



From bh at intevation.de  Tue Aug  9 15:38:11 2005
From: bh at intevation.de (Bernhard Herzog)
Date: Tue, 09 Aug 2005 15:38:11 +0200
Subject: [Kolab-devel] Still problems compiling Kolab 2.0.1-rc on Fedora 4
In-Reply-To: <d790496105080906284f17ba5e@mail.gmail.com> (Alessandro
	Fiorino's message of "Tue, 9 Aug 2005 15:28:36 +0200")
References: <d790496105080906284f17ba5e@mail.gmail.com>
Message-ID: <s9zk6ivdyd8.fsf@thetis.intevation.de>

Alessandro Fiorino <alessandro.fiorino at gmail.com> writes:

> Although  the openpkg upgrade to version 2.4 the new release candidate
> still doesn't compile on Fedora 4: the error is always the same
[...]
> In file included from /usr/include/inttypes.h:28,
>                  from system.h:17,
>                  from file.c:28:
> /usr/include/stdint.h:49: error: duplicate 'unsigned'

This problem doesn't seem to be limited to OpenPKG/Kolab:
http://sourceforge.net/mailarchive/forum.php?thread_id=7707316&forum_id=7186

Maybe the quick hack proposed there helps.


   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/



From radoeka at xs4all.nl  Tue Aug  9 19:31:46 2005
From: radoeka at xs4all.nl (Richard Bos)
Date: Tue, 9 Aug 2005 19:31:46 +0200
Subject: [Kolab-devel] Kolab Server 2.0.1 RC 1 released
In-Reply-To: <s9zoe87e6h7.fsf@thetis.intevation.de>
References: <s9zoe87e6h7.fsf@thetis.intevation.de>
Message-ID: <200508091931.47687.radoeka@xs4all.nl>

Op dinsdag 9 augustus 2005 12:43, schreef Bernhard Herzog:
> Please test this release and report your experiences with it, so that we
> know how well it works for you.

Bad experience:
Excellent all required Ports are available!
LDAP repository is empty - assuming fresh install
............
prepare LDAP database...
temporarily starting slapd
Waiting for OpenLDAP to start
could not connect ldap server ldap://127.0.0.1:389/ 
at /kolab/etc/kolab/kolab_bootstrap line 415.

   414     my $ldapuri = URI->new($ldap_uri) || die "error: could not parse 
given uri";
   415     my $ldap = Net::LDAP->new($ldap_uri, verify => 'none' ) || die 
"could not connect ldap server $ldap_uri";
  
I have:
install perl-kolab-5.8.7-2.0_20050727
install kolabd-1.9.4-20050801
install kolab-webadmin-0.4.0-20050728
install kolab-resource-handlers-0.3.9-20050727
INSTALL: openpkg-2.4.2-2.4.2 ........  perl-kolab-5.8.7-2.0_20050727
 kolabd-1.9.4-20050801 kolab-webadmin-0.4.0-20050728
 kolab-resource-handlers-0.3.9-20050727
MISSSRC: none
MISSPKG: none
MISSING: none
SURPLUS: none
SUMMARY: NODE=atlas; CMD=kolab; DATE=2005-08-09/19:08:29; HASX11=; DONE

Kolab-2.0 used to run before on the same machine.  Don't worry nothing 
operation fortunately.

Running openldap with debugging on results in:
@(#) $OpenLDAP: slapd 2.2.27 (Aug  9 2005 17:25:42) $
        kolab at atlas:/opt/kolab/RPM/TMP/openldap-2.2.27/servers/slapd
daemon_init: ldap://127.0.0.1:389/
bdb_db_init: Initializing BDB database
bdb_db_open: dc=school,dc=nl
bdb(dc=school,dc=nl): Ignoring log 
file: /kolab/var/openldap/openldap-data/log.0000000001: magic number 0, not 
40988
bdb(dc=school,dc=nl): Invalid log file: log.0000000001: Invalid argument
bdb(dc=school,dc=nl): PANIC: Invalid argument
bdb(dc=school,dc=nl): PANIC: DB_RUNRECOVERY: Fatal error, run database 
recovery
bdb_db_open: dbenv_open failed: DB_RUNRECOVERY: Fatal error, run database 
recovery (-30978)
backend_startup: bi_db_open failed! (-30978)
bdb(dc=school,dc=nl): DB_ENV->lock_id_free interface requires an environment 
configured for the locking subsystem
bdb(dc=school,dc=nl): txn_checkpoint interface requires an environment 
configured for the transaction subsystem
bdb_db_destroy: txn_checkpoint failed: Invalid argument (22)
slapd stopped.
connections_destroy: nothing to destroy.


What can to do now?


-- 
Richard Bos
Without a home the journey is endless

-- 
Richard Bos
Without a home the journey is endless



From radoeka at xs4all.nl  Tue Aug  9 21:21:40 2005
From: radoeka at xs4all.nl (Richard Bos)
Date: Tue, 9 Aug 2005 21:21:40 +0200
Subject: [Kolab-devel] [SOLVED] Kolab Server 2.0.1 RC 1 released
In-Reply-To: <200508091931.47687.radoeka@xs4all.nl>
References: <s9zoe87e6h7.fsf@thetis.intevation.de>
	<200508091931.47687.radoeka@xs4all.nl>
Message-ID: <200508092121.40876.radoeka@xs4all.nl>

Op dinsdag 9 augustus 2005 19:31, schreef Richard Bos:
> Op dinsdag 9 augustus 2005 12:43, schreef Bernhard Herzog:
> > Please test this release and report your experiences with it, so that we
> > know how well it works for you.
>
> Bad experience:
> Excellent all required Ports are available!
> LDAP repository is empty - assuming fresh install
> ............
> prepare LDAP database...
> temporarily starting slapd
> Waiting for OpenLDAP to start
> could not connect ldap server ldap://127.0.0.1:389/
> at /kolab/etc/kolab/kolab_bootstrap line 415.

Solved by reinstall from package (rpm) bdb onwards.

-- 
Richard Bos
Without a home the journey is endless



From radoeka at xs4all.nl  Tue Aug  9 22:40:47 2005
From: radoeka at xs4all.nl (Richard Bos)
Date: Tue, 9 Aug 2005 22:40:47 +0200
Subject: [Kolab-devel] Kolab Server 2.0.1 RC 1 released
In-Reply-To: <s9zoe87e6h7.fsf@thetis.intevation.de>
References: <s9zoe87e6h7.fsf@thetis.intevation.de>
Message-ID: <200508092240.48573.radoeka@xs4all.nl>

Op dinsdag 9 augustus 2005 12:43, schreef Bernhard Herzog:
> Please test this release and report your experiences with it, so that we
> know how well it works for you.

I get the an authorisation error, when sending email using kontact from a 
suse92 system, the error is:
Autorisation failed, an error occured during authentication:
  SASL(-4): no mechanism available:
  No worthy mechs found-authenticatie not supported


kolab is installed on a suse93 system.  Kontact can send email from the suse93 
system.  But when I use kontact (kde-3.4.2) on the suse92 system it just does 
not work :(

Any idea what can be the rootcause of this problem?  The settings are correct 
to my opinion, kontact showed the certified when smtp'ing the first time, 
e.g.

-- 
Richard Bos
Without a home the journey is endless



From till at klaralvdalens-datakonsult.se  Tue Aug  9 22:30:11 2005
From: till at klaralvdalens-datakonsult.se (Till Adam)
Date: Tue, 9 Aug 2005 22:30:11 +0200
Subject: [Kolab-devel] Kolab Server 2.0.1 RC 1 released
In-Reply-To: <200508092240.48573.radoeka@xs4all.nl>
References: <s9zoe87e6h7.fsf@thetis.intevation.de>
	<200508092240.48573.radoeka@xs4all.nl>
Message-ID: <200508092230.11929.till@klaralvdalens-datakonsult.se>

On Tuesday 09 August 2005 22:40, Richard Bos wrote:
> Op dinsdag 9 augustus 2005 12:43, schreef Bernhard Herzog:
> > Please test this release and report your experiences with it, so that we
> > know how well it works for you.
>
> I get the an authorisation error, when sending email using kontact from a
> suse92 system, the error is:
> Autorisation failed, an error occured during authentication:
>   SASL(-4): no mechanism available:
>   No worthy mechs found-authenticatie not supported
>
>
> kolab is installed on a suse93 system.  Kontact can send email from the
> suse93 system.  But when I use kontact (kde-3.4.2) on the suse92 system it
> just does not work :(
>
> Any idea what can be the rootcause of this problem?  The settings are
> correct to my opinion, kontact showed the certified when smtp'ing the first
> time, e.g.

You are very likely missing the cyrus-sasl plugins on the client installation, 
which KDE 3.4 uses to implement various authentication mechanisms. Note that 
while they are called cyrus-sasl-foo, they are to be installed on the client, 
not on the server, they have nothing in common with the IMAP server but the 
origin of the implementation.

-- 
Till Adam -- till at klaralvdalens-datakonsult.se, adam at kde.org
Klar?lvdalens Datakonsult AB, Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050809/16975c79/attachment.sig>

From radoeka at xs4all.nl  Tue Aug  9 23:31:03 2005
From: radoeka at xs4all.nl (Richard Bos)
Date: Tue, 9 Aug 2005 23:31:03 +0200
Subject: [Kolab-devel] Kolab Server 2.0.1 RC 1 released
In-Reply-To: <200508092230.11929.till@klaralvdalens-datakonsult.se>
References: <s9zoe87e6h7.fsf@thetis.intevation.de>
	<200508092240.48573.radoeka@xs4all.nl>
	<200508092230.11929.till@klaralvdalens-datakonsult.se>
Message-ID: <200508092331.03891.radoeka@xs4all.nl>

Op dinsdag 9 augustus 2005 22:30, schreef Till Adam:
> You are very likely missing the cyrus-sasl plugins on the client
> installation, which KDE 3.4 uses to implement various authentication
> mechanisms. Note that while they are called cyrus-sasl-foo, they are to be
> installed on the client, not on the server, they have nothing in common
> with the IMAP server but the origin of the implementation.

Till that's the reason indeed.  I have installed these and now after some 
tweaking it's up and running :))

-- 
Richard Bos
Without a home the journey is endless



From richard at radoeka.nl  Tue Aug  9 19:22:58 2005
From: richard at radoeka.nl (Richard Bos)
Date: Tue, 9 Aug 2005 19:22:58 +0200
Subject: [Kolab-devel] Kolab Server 2.0.1 RC 1 released
In-Reply-To: <s9zoe87e6h7.fsf@thetis.intevation.de>
References: <s9zoe87e6h7.fsf@thetis.intevation.de>
Message-ID: <200508091923.00139.richard@radoeka.nl>

Op dinsdag 9 augustus 2005 12:43, schreef Bernhard Herzog:
> Please test this release and report your experiences with it, so that we
> know how well it works for you.

Bad experience:
Excellent all required Ports are available!
LDAP repository is empty - assuming fresh install
............
prepare LDAP database...
temporarily starting slapd
Waiting for OpenLDAP to start
could not connect ldap server ldap://127.0.0.1:389/ at /kolab/etc/kolab/kolab_bootstrap line 415.

   414     my $ldapuri = URI->new($ldap_uri) || die "error: could not parse given uri";
   415     my $ldap = Net::LDAP->new($ldap_uri, verify => 'none' ) || die "could not connect ldap server $ldap_uri";
  
I have:
install perl-kolab-5.8.7-2.0_20050727
install kolabd-1.9.4-20050801
install kolab-webadmin-0.4.0-20050728
install kolab-resource-handlers-0.3.9-20050727
INSTALL: openpkg-2.4.2-2.4.2 ........  perl-kolab-5.8.7-2.0_20050727
 kolabd-1.9.4-20050801 kolab-webadmin-0.4.0-20050728
 kolab-resource-handlers-0.3.9-20050727
MISSSRC: none
MISSPKG: none
MISSING: none
SURPLUS: none
SUMMARY: NODE=atlas; CMD=kolab; DATE=2005-08-09/19:08:29; HASX11=; DONE

Kolab-2.0 used to run before on the same machine.  Don't worry nothing operation fortunately.

Running openldap with debugging on results in:
@(#) $OpenLDAP: slapd 2.2.27 (Aug  9 2005 17:25:42) $
        kolab at atlas:/opt/kolab/RPM/TMP/openldap-2.2.27/servers/slapd
daemon_init: ldap://127.0.0.1:389/
bdb_db_init: Initializing BDB database
bdb_db_open: dc=school,dc=nl
bdb(dc=school,dc=nl): Ignoring log file: /kolab/var/openldap/openldap-data/log.0000000001: magic number 0, not 40988
bdb(dc=school,dc=nl): Invalid log file: log.0000000001: Invalid argument
bdb(dc=school,dc=nl): PANIC: Invalid argument
bdb(dc=school,dc=nl): PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
bdb_db_open: dbenv_open failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30978)
backend_startup: bi_db_open failed! (-30978)
bdb(dc=school,dc=nl): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem
bdb(dc=school,dc=nl): txn_checkpoint interface requires an environment configured for the transaction subsystem
bdb_db_destroy: txn_checkpoint failed: Invalid argument (22)
slapd stopped.
connections_destroy: nothing to destroy.


What can to do now?


-- 
Richard Bos
Without a home the journey is endless



From jan at intevation.de  Wed Aug 10 09:42:55 2005
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Wed, 10 Aug 2005 09:42:55 +0200
Subject: [Kolab-devel] Re: Italian translation
In-Reply-To: <200507310200.35889.martin.konold@erfrakon.de>
References: <d7904961050729175846453bd2@mail.gmail.com>
	<200507301217.10888.martin.konold@erfrakon.de>
	<200507310200.35889.martin.konold@erfrakon.de>
Message-ID: <20050810074255.GA13882@intevation.de>

On Sun, Jul 31, 2005 at 02:00:34AM +0200, Martin Konold wrote:
> Am Samstag 30 Juli 2005 12:17 schrieb Martin Konold:
> > Send it till Sunday night MEST to me and I will add it. If it is later send
> > the translation to Steffen.
> 
> I added the italian translation to HEAD. After some feedback I propose to also 
> add it to the 2.0 branch.

I propose to add the italian translation to 2.0 branch right away.
I don't expect it to be tested else and the strings changed anyway with
HEAD, so there is no point to test a version in HEAD.

	Jan

-- 
Jan-Oliver Wagner               http://intevation.de/~jan/
Intevation GmbH                      http://intevation.de/
Kolab Konsortium               http://kolab-konsortium.de/
FreeGIS                                http://freegis.org/



From kolab-issues at intevation.de  Wed Aug 10 10:18:15 2005
From: kolab-issues at intevation.de (Martin Konold)
Date: Wed, 10 Aug 2005 08:18:15 +0000
Subject: [Kolab-devel] [issue872] Tasks get falsely assigned a time after
	sync
Message-ID: <1123661895.54.0.830369432033.issue872@intevation.de>


New submission from Martin Konold <martin.konold at erfrakon.de>:

When creating a task without a time associated syncing with Kolab     
and restarting Kontact the task gets unintentionally a time associated    
with.   
   
I attached a screenshot showing how the checkbox got activated after the   
restart.    
 
This is the xml on the server after the restart. 
 
<?xml version="1.0" encoding="UTF-8"?>  
<task version="1.0" >  
 <product-id>KOrganizer 3.4.2, Kolab resource</product-id>  
 <uid>libkcal-190579406.334</uid>  
 <creation-date>2005-08-10T07:47:38Z</creation-date>  
 <last-modification-date>2005-08-10T07:47:38Z</last-modification-date>  
 <sensitivity>public</sensitivity>  
 <summary>test todo time</summary>  
 <organizer>  
  <display-name>Martin Konold</display-name>  
  <smtp-address>martin.konold at erfrakon.de</smtp-address>  
 </organizer>  
 <revision>0</revision>  
 <priority>5</priority>  
 <completed>0</completed>  
 <status>not-started</status>  
</task>

----------
assignedto: till
files: task.png
messages: 5240
nosy: martin, till
priority: minor bug
status: unread
title: Tasks get falsely assigned a time after sync
topic: format, kde client
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue872>
________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: task.png
Type: image/png
Size: 47253 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050810/12816e1a/attachment.png>

From andreas at conectiva.com.br  Wed Aug 10 19:52:36 2005
From: andreas at conectiva.com.br (Andreas Hasenack)
Date: Wed, 10 Aug 2005 14:52:36 -0300
Subject: [Kolab-devel] Still problems compiling Kolab 2.0.1-rc on Fedora 4
In-Reply-To: <s9zk6ivdyd8.fsf@thetis.intevation.de>
References: <d790496105080906284f17ba5e@mail.gmail.com>
	<s9zk6ivdyd8.fsf@thetis.intevation.de>
Message-ID: <20050810175236.GA8875@conectiva.com.br>

On Tue, Aug 09, 2005 at 03:38:11PM +0200, Bernhard Herzog wrote:
> Alessandro Fiorino <alessandro.fiorino at gmail.com> writes:
> 
> > Although  the openpkg upgrade to version 2.4 the new release candidate
> > still doesn't compile on Fedora 4: the error is always the same
> [...]
> > In file included from /usr/include/inttypes.h:28,
> >                  from system.h:17,
> >                  from file.c:28:
> > /usr/include/stdint.h:49: error: duplicate 'unsigned'
> 
> This problem doesn't seem to be limited to OpenPKG/Kolab:
> http://sourceforge.net/mailarchive/forum.php?thread_id=7707316&forum_id=7186

And not limited to fedora. Mandriva cooker (soon to be 2006) build also fails.



From kolab-issues at intevation.de  Thu Aug 11 15:01:33 2005
From: kolab-issues at intevation.de (Bernhard Herzog)
Date: Thu, 11 Aug 2005 13:01:33 +0000
Subject: [Kolab-devel] [issue873] .../maintainer.php was not found on this
	server
Message-ID: <1123765293.49.0.227154683252.issue873@intevation.de>


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

In Kolab 2.1 (kolab-webadmin-0.4.0-20050724), after you've created a domain
maintainer, display the list of the domain maintainers and click on the modify
link of one of them.  An error message appears:

Not Found
The requested URL /admin/domainmaintainer/maintainer.php was not found on this
server.

It seems that the URL in the link is wrong.  It should be domainmaintainer.php
instead of maintainer.php.

----------
assignedto: steffen
messages: 5242
nosy: bh, steffen
priority: bug
status: unread
title: .../maintainer.php was not found on this server
topic: kolab-2.1, web admin
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue873>
________________________________________________



From kolab-issues at intevation.de  Thu Aug 11 15:54:54 2005
From: kolab-issues at intevation.de (Bernhard Herzog)
Date: Thu, 11 Aug 2005 13:54:54 +0000
Subject: [Kolab-devel] [issue874] automatic resource handling doesn't work
	in 2.1
Message-ID: <1123768494.39.0.325028229979.issue874@intevation.de>


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

In the current kolab 2.1 packages (2005-08-11) automatic resource handling
doesn't work.  resmgr.log contains an error message:

August 11 15:44:07 kolabmailboxfilter.php[27615]: Error: IMAP Errors from
createMailBox: NO, Permission denied

----------
assignedto: steffen
messages: 5243
nosy: bh, steffen
status: unread
title: automatic resource handling doesn't work in 2.1
topic: kolab-2.1, server
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue874>
________________________________________________



From jan at intevation.de  Thu Aug 11 17:31:05 2005
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Thu, 11 Aug 2005 17:31:05 +0200
Subject: [Kolab-devel] Re: Italian translation
In-Reply-To: <20050810074255.GA13882@intevation.de>
References: <d7904961050729175846453bd2@mail.gmail.com>
	<200507301217.10888.martin.konold@erfrakon.de>
	<200507310200.35889.martin.konold@erfrakon.de>
	<20050810074255.GA13882@intevation.de>
Message-ID: <20050811153105.GA16899@intevation.de>

On Wed, Aug 10, 2005 at 09:42:55AM +0200, Jan-Oliver Wagner wrote:
> On Sun, Jul 31, 2005 at 02:00:34AM +0200, Martin Konold wrote:
> > Am Samstag 30 Juli 2005 12:17 schrieb Martin Konold:
> > > Send it till Sunday night MEST to me and I will add it. If it is later send
> > > the translation to Steffen.
> > 
> > I added the italian translation to HEAD. After some feedback I propose to also 
> > add it to the 2.0 branch.
> 
> I propose to add the italian translation to 2.0 branch right away.
> I don't expect it to be tested else and the strings changed anyway with
> HEAD, so there is no point to test a version in HEAD.

Since noone objects, I added Italian support to the 2.0 branch.

Best

	Jan

-- 
Jan-Oliver Wagner               http://intevation.de/~jan/
Intevation GmbH                      http://intevation.de/
Kolab Konsortium               http://kolab-konsortium.de/
FreeGIS                                http://freegis.org/



From bernhard at intevation.de  Thu Aug 11 17:53:37 2005
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 11 Aug 2005 17:53:37 +0200
Subject: [Kolab-devel] Is getpackages.sh still useful?
Message-ID: <20050811155337.GI29291@intevation.de>

Hi Stephan,

I did some minor cleanup in the CVS.
Is your
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/doc/getpackages.sh
still useful?

So yes, you probably should move it to a different place.
If not, you could just cvs remove it.

Best,
	Bernhard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050811/af8af738/attachment.sig>

From bh at intevation.de  Thu Aug 11 17:54:37 2005
From: bh at intevation.de (Bernhard Herzog)
Date: Thu, 11 Aug 2005 17:54:37 +0200
Subject: [Kolab-devel] Re: bernhard: server README.1st,1.25,1.26
In-Reply-To: <20050811155115.64448101EF7@lists.intevation.de>
	(cvs@intevation.de's
	message of "Thu, 11 Aug 2005 17:51:15 +0200 (CEST)")
References: <20050811155115.64448101EF7@lists.intevation.de>
Message-ID: <s9zacjo8o5e.fsf@thetis.intevation.de>

cvs at intevation.de writes:

> -# ./obmtool kolab
> +# ./obmtool kolab 2>&1 | tee kolab-build.log

Will that catch anything that is not already logged into the various
obmtool* files in /tmp ?

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/



From kolab-issues at intevation.de  Thu Aug 11 19:53:09 2005
From: kolab-issues at intevation.de (Bernhard Herzog)
Date: Thu, 11 Aug 2005 17:53:09 +0000
Subject: [Kolab-devel] [issue875] domain is "$mydomain" after upgrade to 2.1
Message-ID: <1123782789.0.0.130793042243.issue875@intevation.de>


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

I've tested the upgrade from a 2.0 installation to 2.1.  After the upgrade the
kolab server knows about one domain called $mydomain.  That is literally what
appears in the web-admin interface.

----------
assignedto: steffen
messages: 5248
nosy: bh, steffen
priority: bug
status: unread
title: domain is "$mydomain" after upgrade to 2.1
topic: kolab-2.1, server
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue875>
________________________________________________



From bh at intevation.de  Thu Aug 11 21:39:34 2005
From: bh at intevation.de (Bernhard Herzog)
Date: Thu, 11 Aug 2005 21:39:34 +0200
Subject: [Kolab-devel] Kolab Server 2.1 snapshot release
Message-ID: <s9zwtms6z61.fsf@thetis.intevation.de>


Hi all,

I've just uploaded the first snapshot release of Kolab Server 2.1.
You'll find it in the new server/development-2.1 directory.

There are some rough edges still, so this is not a beta release yet.  An
upgrade from 2.0 is not recommended at this stage.  However, starting
with a new installation works and we would like get some feedback.

As usual the release notes are below.


   Bernhard


Release notes Kolab2 Server
(Version 20050811, Kolab Server pre 2.1)

This is a development snapshot of the kolab server leading up to a 2.1
release.  At this point an upgrade from 2.0 is not recommended (one of
the problems is Issue875)

For upgrading and installation instructions, please refer to the
1st.README file in the source directory.


Known Bugs:

      Issue875 (domain is "$mydomain" after upgrade to 2.1)
      Issue873 (.../maintainer.php was not found on this server)


Changes since 2.0 final:

    - Simple multi-domain support

      The Kolab server can now accept mail for multiple email domains.
      There is also a new class of maintainers which are only allowed to
      manage settings for a subset of the mail domains of the kolab
      server.

    - Switch to OpenPKG 2.4.  As a result of this, practically all
      packages have been updated.

      Up to now the Kolab server used OpenPKG 2.2.  The current release
      of OpenPKG is 2.4, though, and the OpenPKG project only provides
      security advisories and updates for the most recent release and
      its immediate predecessor.  Therefore moving to OpenPKG 2.4 is
      necessary to benefit from the OpenPKG updates.

      The db package has not been updated to the version from OpenPKG
      2.4 yet to avoid potential stability problems with OpenLDAP.

    - A new clamav package fixing a buffer overflow. 
      This is the package mentioned in the kolab security advisory 02
      http://kolab.org/security/kolab-vendor-notice-02.txt

    - better deletion handling.  Now more objects are deleted using
      kolabDeleteFlag (issues 845 and 855)

    - perl-kolab 5.8.5-20050530 -> 5.8.7-20050728

      Uses autoperl now

      * Fixing:
          Issue855 (make shared folder and external deletion same as users)

    - kolab-resource-handlers 20050615 -> 20050719

      * Fixing:
          Issue825 (Errorhandling for multiple recipients)


    - kolabd 1.9.4-20050615 -> 2.0.0-20050729

      * Fixing:
          Issue824 (Enable delivery to multiple recipients)
          Issue851 (kolabquotawarn uses system sendmail)
          Issue791 (automatic invitation handling uses http instead of https)
          Issue845 (groupOfNames cleanup handling)
          Issue855 (make shared folder and external deletion same as users)


    - kolab-webadmin 20050620 -> 20050724

      * Fixing:
          Issue820 (dist list lookup error)
          Issue845 (groupOfNames cleanup handling)
          Issue855 (make shared folder and external deletion same as users)



$Id: release-notes.txt,v 1.18 2005/08/11 19:04:10 bh Exp $



From radoeka at xs4all.nl  Thu Aug 11 22:27:17 2005
From: radoeka at xs4all.nl (Richard Bos)
Date: Thu, 11 Aug 2005 22:27:17 +0200
Subject: [Kolab-devel] Kolab Server 2.1 snapshot release
In-Reply-To: <s9zwtms6z61.fsf@thetis.intevation.de>
References: <s9zwtms6z61.fsf@thetis.intevation.de>
Message-ID: <200508112227.18560.radoeka@xs4all.nl>

Op donderdag 11 augustus 2005 21:39, schreef Bernhard Herzog:
> I've just uploaded the first snapshot release of Kolab Server 2.1.
> You'll find it in the new server/development-2.1 directory.
>
> There are some rough edges still, so this is not a beta release yet. ?An
> upgrade from 2.0 is not recommended at this stage. ?However, starting
> with a new installation works and we would like get some feedback.

Is there information available how to upgrade from e.g. 2.0 to 2.0.1 or from 
the latter to 2.1?

In the wiki there is a howto about migrating from kolab1 to kolab2.

In case of a 2.0 to 2.0.1/2.1 it is different I think?

Is it e.g. necessary to stop all the services, before the the packages are 
being build?  Is it possible to build the packages and have them not 
installed, until the build has finished (sounds not possible)....
I mean if all services need to be stopped for a update, and the binaries still 
have to be build the downtime can be very long....
Is there a way to keep the downtime short?

-- 
Richard Bos
Without a home the journey is endless

-- 
Richard Bos
Without a home the journey is endless



From radoeka at xs4all.nl  Fri Aug 12 09:28:56 2005
From: radoeka at xs4all.nl (Richard Bos)
Date: Fri, 12 Aug 2005 09:28:56 +0200
Subject: [Kolab-devel] Kolab Server 2.1 snapshot release
In-Reply-To: <s9zwtms6z61.fsf@thetis.intevation.de>
References: <s9zwtms6z61.fsf@thetis.intevation.de>
Message-ID: <200508120928.57327.radoeka@xs4all.nl>

Op donderdag 11 augustus 2005 21:39, schreef Bernhard Herzog:
> I've just uploaded the first snapshot release of Kolab Server 2.1.
> You'll find it in the new server/development-2.1 directory.
>
> There are some rough edges still, so this is not a beta release yet. ?An
> upgrade from 2.0 is not recommended at this stage. ?However, starting
> with a new installation works and we would like get some feedback.

Is there information available how to upgrade from e.g. 2.0 to 2.0.1 or from 
the latter to 2.1?

In the wiki there is a howto about migrating from kolab1 to kolab2.

In case of a 2.0 to 2.0.1/2.1 it is different I think?

Is it e.g. necessary to stop all the services, before the the packages are 
being build?  Is it possible to build the packages and have them not 
installed, until the build has finished (sounds not possible)....
I mean if all services need to be stopped for a update, and the binaries still 
have to be build the downtime can be very long....
Is there a way to keep the downtime short?

-- 
Richard Bos
Without a home the journey is endless

-- 
Richard Bos
Without a home the journey is endless



From jan at intevation.de  Fri Aug 12 10:00:57 2005
From: jan at intevation.de (Jan-Oliver Wagner)
Date: Fri, 12 Aug 2005 10:00:57 +0200
Subject: [Kolab-devel] Kolab Server 2.1 snapshot release
In-Reply-To: <200508120928.57327.radoeka@xs4all.nl>
References: <s9zwtms6z61.fsf@thetis.intevation.de>
	<200508120928.57327.radoeka@xs4all.nl>
Message-ID: <20050812080057.GA18025@intevation.de>

On Fri, Aug 12, 2005 at 09:28:56AM +0200, Richard Bos wrote:
> Op donderdag 11 augustus 2005 21:39, schreef Bernhard Herzog:
> > I've just uploaded the first snapshot release of Kolab Server 2.1.
> > You'll find it in the new server/development-2.1 directory.
> >
> > There are some rough edges still, so this is not a beta release yet. ?An
> > upgrade from 2.0 is not recommended at this stage. ?However, starting
> > with a new installation works and we would like get some feedback.
> 
> Is there information available how to upgrade from e.g. 2.0 to 2.0.1 or from 
> the latter to 2.1?

well, you always find upgrade infos in the 1st.README file.

> In the wiki there is a howto about migrating from kolab1 to kolab2.

I'd rather call it some notes ;-)

> In case of a 2.0 to 2.0.1/2.1 it is different I think?

Definitely!

	Jan
-- 
Jan-Oliver Wagner               http://intevation.de/~jan/
Intevation GmbH                      http://intevation.de/
Kolab Konsortium               http://kolab-konsortium.de/
FreeGIS                                http://freegis.org/



From radoeka at xs4all.nl  Fri Aug 12 10:28:19 2005
From: radoeka at xs4all.nl (Richard Bos)
Date: Fri, 12 Aug 2005 10:28:19 +0200
Subject: [Kolab-devel] why is /kolab/etc/rc called with exec in
	/etc/init.d/kolab?
Message-ID: <200508121028.20604.radoeka@xs4all.nl>

Hello,

I wonder why 'exec' is being used to launch /kolab/etc/rc in the
/etc/init.d/kolab script?  The problem with it at the moment is,
that programs being programmed to start after the line wth exec
are not started...

I encounter this problem with a kolab/fetchmail combination....
Where fetchmail is to be started after /kolab/etc/rc has finished.

Would it be a problem to leave out the exec line and just launch
it without exec?  After all when the same command is given on the
command line, as proposed by kolab_bootstrap, it is executed without
exec too...


The problem can be emulated with:
----8<----8<----8<----8<----8<----8<
exec echo test
echo this line is not echoed
----8<----8<----8<----8<----8<----8<
put the above in file and execute it, the result is just 'test' ....

Please, find attached a updated /etc/init.d/kolab script.  The change is
that it looks for its filename and from that deduct whether kolab should
be started or stopped.  It is not for general use yet, as the fetchmail is
being started from it as well.  Perhaps fetchmail should be switch on
and off with a variable?

-- 
Richard Bos
Without a home the journey is endless
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kolab
Type: application/x-shellscript
Size: 635 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050812/aa195fa9/attachment.bin>

From radoeka at xs4all.nl  Fri Aug 12 10:52:47 2005
From: radoeka at xs4all.nl (Richard Bos)
Date: Fri, 12 Aug 2005 10:52:47 +0200
Subject: [Kolab-devel] Kolab Server 2.1 snapshot release
In-Reply-To: <20050812080057.GA18025@intevation.de>
References: <s9zwtms6z61.fsf@thetis.intevation.de>
	<200508120928.57327.radoeka@xs4all.nl>
	<20050812080057.GA18025@intevation.de>
Message-ID: <200508121052.48118.radoeka@xs4all.nl>

On Friday 12 August 2005 10:00, Jan-Oliver Wagner wrote:
> On Fri, Aug 12, 2005 at 09:28:56AM +0200, Richard Bos wrote:
> > Op donderdag 11 augustus 2005 21:39, schreef Bernhard Herzog:
> > > I've just uploaded the first snapshot release of Kolab Server 2.1.
> > > You'll find it in the new server/development-2.1 directory.
> > >
> > > There are some rough edges still, so this is not a beta release yet.
> > > ?An upgrade from 2.0 is not recommended at this stage. ?However,
> > > starting with a new installation works and we would like get some
> > > feedback.
> >
> > Is there information available how to upgrade from e.g. 2.0 to 2.0.1 or
> > from the latter to 2.1?
>
> well, you always find upgrade infos in the 1st.README file.

I read that one (of course) before I sent out my question => the 1st.README
did not answer my question.

Should all services be stopped before the packages are being build and
installed or should they be stopped?

To obtain the shortes possible downtime the packages have to build on
other system I assume.  If that is not possible, the downtime is just
the time that is needed to build and install the packages??

--
Richard



From kolab-issues at intevation.de  Fri Aug 12 11:19:22 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Fri, 12 Aug 2005 09:19:22 +0000
Subject: [Kolab-devel] [issue876] FB Setup documentation not clear enough
	for KDE in doc2.
Message-ID: <1123838362.49.0.569367829669.issue876@intevation.de>


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

The FB setup documentation and the screenshots are inconsistant  
about what to use as fb retrieval URL and setup.  
  
We shall improve it.  
Michel: Usually this would be your task, but I have more information  
about what is confusing some users in German, so I might just do the changes.  
IMHO the default url for retrieval in KDE should be:  
  
https://your.kolabhomeserver/freebusy/%EMAIL%.ifb  
 
We would need to test if this also works on windows.

----------
assignedto: bernhard
messages: 5250
nosy: bernhard, bh, michel
priority: bug
status: unread
title: FB Setup documentation not clear enough for KDE in doc2.
topic: docs, kkc
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue876>
________________________________________________



From bh at intevation.de  Fri Aug 12 16:48:15 2005
From: bh at intevation.de (Bernhard Herzog)
Date: Fri, 12 Aug 2005 16:48:15 +0200
Subject: [Kolab-devel] Kolab Server 2.1 snapshot release
In-Reply-To: <200508121052.48118.radoeka@xs4all.nl> (Richard Bos's message
	of "Fri, 12 Aug 2005 10:52:47 +0200")
References: <s9zwtms6z61.fsf@thetis.intevation.de>
	<200508120928.57327.radoeka@xs4all.nl>
	<20050812080057.GA18025@intevation.de>
	<200508121052.48118.radoeka@xs4all.nl>
Message-ID: <s9zmznnyzww.fsf@thetis.intevation.de>

Richard Bos <radoeka at xs4all.nl> writes:

> Should all services be stopped before the packages are being build and
> installed or should they be stopped?

Normally it's not necessary to stop the server in my experience.  The
servers I done this with don't have much load though.

> To obtain the shortes possible downtime the packages have to build on
> other system I assume.  If that is not possible, the downtime is just
> the time that is needed to build and install the packages??

You could build the new packages on a separate machine and then upgrade
the production server from binary packages.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/



From andreas at conectiva.com.br  Fri Aug 12 19:34:26 2005
From: andreas at conectiva.com.br (Andreas Hasenack)
Date: Fri, 12 Aug 2005 14:34:26 -0300
Subject: [Kolab-devel] freebusy in http://srv/kolab/freebusy instead of
	/freebusy
Message-ID: <20050812173426.GC6311@conectiva.com.br>

Hello,

I'm trying to make kolab (and its components) work in http://server/kolab instead of
http://server/. I already changed many places and templates to the new
url scheme, but something is still missing. Kontact is also configured with the
correct URL.

When using kontact from KDE 3.4.2, I see accesses for
http://server/freebusy instead of http://server/kolab/freebusy:

10.0.2.177 - - [12/Aug/2005:14:28:53 -0300] "GET /freebusy/trigger/sisko%40kolab.conectiva/Calendar.pfb HTTP/1.1" 404 1012

I grepped everything and couldn't find where this is misconfigured. So I
took a look at the source for kontact and found this in kmail/kmailicalifaceimpl.cpp
around line 1295 in function/method KMailICalIfaceImpl::triggerKolabFreeBusy:

  httpURL.setPath( "/freebusy/trigger/" + path + ".pfb" ); <---------------
  httpURL.setQuery( QString::null );
  // Ensure that we encode everything with UTF8
  httpURL = KURL( httpURL.url(0,106), 106 );
  kdDebug() << "Triggering PFB update for " << folderURL << " : getting " << httpURL << endl;

So, can't Kontact work with freebusy installed somewhere else other than the webserver's
DocumentRoot?



From matt at fruitsalad.org  Fri Aug 12 22:10:50 2005
From: matt at fruitsalad.org (Matt Douhan)
Date: Fri, 12 Aug 2005 22:10:50 +0200
Subject: [Kolab-devel] Kolab Server 2.1 snapshot release
In-Reply-To: <s9zmznnyzww.fsf@thetis.intevation.de>
References: <s9zwtms6z61.fsf@thetis.intevation.de>
	<200508121052.48118.radoeka@xs4all.nl>
	<s9zmznnyzww.fsf@thetis.intevation.de>
Message-ID: <200508122210.50531.matt@fruitsalad.org>

On Friday 12 August 2005 16.48, Bernhard Herzog wrote:
> Richard Bos <radoeka at xs4all.nl> writes:
> > Should all services be stopped before the packages are being build and
> > installed or should they be stopped?
>
> Normally it's not necessary to stop the server in my experience.  The
> servers I done this with don't have much load though.

I totally agree with thisc comment, for low load servers stopping the services 
is not necessary in my experience, but on high load servers it is required or 
you may end up with corruped imap db's or squatters, and that is really not 
fun, so I tend to be safe on higher load servers.



-- 
Matt Douhan
www.fruitsalad.org



From matt at fruitsalad.org  Fri Aug 12 22:11:57 2005
From: matt at fruitsalad.org (Matt Douhan)
Date: Fri, 12 Aug 2005 22:11:57 +0200
Subject: [Kolab-devel] [issue876] FB Setup documentation not clear enough
	for KDE in doc2.
In-Reply-To: <1123838362.49.0.569367829669.issue876@intevation.de>
References: <1123838362.49.0.569367829669.issue876@intevation.de>
Message-ID: <200508122211.57454.matt@fruitsalad.org>

On Friday 12 August 2005 11.19, Bernhard Reiter wrote:
>
> https://your.kolabhomeserver/freebusy/%EMAIL%.ifb
>


I thought webdav was the recommended method for KDE/korg

rgds

Matt

-- 
Matt Douhan
www.fruitsalad.org



From radoeka at xs4all.nl  Fri Aug 12 22:18:02 2005
From: radoeka at xs4all.nl (Richard Bos)
Date: Fri, 12 Aug 2005 22:18:02 +0200
Subject: [Kolab-devel] Kolab Server 2.1 snapshot release
In-Reply-To: <200508122210.50531.matt@fruitsalad.org>
References: <s9zwtms6z61.fsf@thetis.intevation.de>
	<s9zmznnyzww.fsf@thetis.intevation.de>
	<200508122210.50531.matt@fruitsalad.org>
Message-ID: <200508122218.04116.radoeka@xs4all.nl>

Op vrijdag 12 augustus 2005 22:10, schreef Matt Douhan:
> > Normally it's not necessary to stop the server in my experience. ?The
> > servers I done this with don't have much load though.
>
> I totally agree with thisc comment, for low load servers stopping the
> services is not necessary in my experience, but on high load servers it is
> required or you may end up with corruped imap db's or squatters, and that
> is really not fun, so I tend to be safe on higher load servers.

High load servers you don't want to stop... => in that case it will be 
required to offline build the packages.  That shouldn't be a problem.


-- 
Richard Bos
Without a home the journey is endless



From kolab-issues at intevation.de  Fri Aug 12 22:35:33 2005
From: kolab-issues at intevation.de (Richard Bos)
Date: Fri, 12 Aug 2005 20:35:33 +0000
Subject: [Kolab-devel] [issue877] /etc/init.d/kolab does not work correctly
Message-ID: <1123878933.69.0.194165131712.issue877@intevation.de>


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

I wonder why 'exec' is being used to launch /kolab/etc/rc in the 
/etc/init.d/kolab script?  The problem with it at the moment is, 
that programs being programmed to start after the line with exec 
are not started... 
 
I encounter this problem with a kolab/fetchmail combination.... 
Where fetchmail is started after /kolab/etc/rc has finished. 
 
Would it be a problem to leave out the exec line and just launch 
it without exec?  After all when the same command is given on the 
command line, as proposed by kolab_bootstrap, it is executed without 
exec too... 
 
 
The problem can be emulated with: 
----8<----8<----8<----8<----8<----8< 
exec echo test 
echo this line is not echoed 
----8<----8<----8<----8<----8<----8< 
put the above in file and execute it, the result is just 'test' .... 
 
Please, find attached a updated /etc/init.d/kolab script.  The change is 
that it looks for its filename and from that deduct whether kolab should 
be started or stopped.  It is not for general use yet, as the fetchmail is 
being started from it as well.  Perhaps fetchmail should be switch on 
and off with a variable?

----------
files: kolab
messages: 5252
nosy: rbos
status: unread
title: /etc/init.d/kolab does not work correctly
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue877>
________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kolab
Type: application/octet-stream
Size: 635 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050812/40fe6020/attachment.obj>

From radoeka at xs4all.nl  Mon Aug 15 10:23:49 2005
From: radoeka at xs4all.nl (Richard Bos)
Date: Mon, 15 Aug 2005 10:23:49 +0200
Subject: [Kolab-devel] Suspicious looking paths
Message-ID: <200508151023.50557.radoeka@xs4all.nl>

Dear kolabbers ;)

during our porting effort, we came accross the following suspicious looking 
paths:

FILE: amavisd.conf.template
@@ -1242,7 +1247,7 @@
 #   qr/(?i)<name>(.+)<\/name>/ ],

   ['KasperskyLab AVP - aveclient',
-    ['/usr/local/kav/bin/aveclient','/usr/local/share/kav/bin/aveclient',
+    ['/kolab/local/kav/bin/aveclient','/kolab/local/share/kav/bin/aveclient',


@@ -1442,7 +1447,7 @@
     qr/Infection: (.+)/ ],

   ### http://www.trendmicro.com/
-  ['Trend Micro FileScanner', ['/etc/iscan/vscan','vscan'],
+  ['Trend Micro FileScanner', ['/kolab/etc/iscan/vscan','vscan'],


Are these paths correct I would not expect them to be in /usr or /etc.  Your 
comments on those paths are highly appreciated.  What do you think should 
they be located in /kolab as shown in the diff above?


-- 
Richard Bos
Without a home the journey is endless



From oeriksson at mandriva.com  Mon Aug 15 11:00:51 2005
From: oeriksson at mandriva.com (Oden Eriksson)
Date: Mon, 15 Aug 2005 11:00:51 +0200
Subject: [Kolab-devel] Suspicious looking paths
In-Reply-To: <200508151023.50557.radoeka@xs4all.nl>
References: <200508151023.50557.radoeka@xs4all.nl>
Message-ID: <200508151100.51647.oeriksson@mandriva.com>

m?ndag 15 augusti 2005 10.23 skrev Richard Bos:
> Dear kolabbers ;)
>
> during our porting effort, we came accross the following suspicious looking
> paths:
>
> FILE: amavisd.conf.template
> @@ -1242,7 +1247,7 @@
>  #   qr/(?i)<name>(.+)<\/name>/ ],
>
>    ['KasperskyLab AVP - aveclient',
> -    ['/usr/local/kav/bin/aveclient','/usr/local/share/kav/bin/aveclient',
> +   
> ['/kolab/local/kav/bin/aveclient','/kolab/local/share/kav/bin/aveclient',
>
>
> @@ -1442,7 +1447,7 @@
>      qr/Infection: (.+)/ ],
>
>    ### http://www.trendmicro.com/
> -  ['Trend Micro FileScanner', ['/etc/iscan/vscan','vscan'],
> +  ['Trend Micro FileScanner', ['/kolab/etc/iscan/vscan','vscan'],
>
>
> Are these paths correct I would not expect them to be in /usr or /etc. 
> Your comments on those paths are highly appreciated.  What do you think
> should they be located in /kolab as shown in the diff above?

When I installed KAV long time ago (don't use it anymore) it ended up 
in /opt/kaspersky (or something like that). The path is hardcoded into the 
KAV config files and also some softlinks made by the "installer". So I'd say, 
leave as is. I'd rather see we get rid of the hardcoded /kolab thing ;)

Some reflections about KAV. I bought it (v4.0.x) for personal usage with one 
year of subscription, but when I wanted to renew the subscription they 
refused me to do that, instead they wanted me to buy an upgrade that had 
nearly the same price as buying it once again. So, when they put out a new 
version of their software, their previous version has reached EOL. This was 
their policy then, maybe it has changed now. I never upgraded and will never 
again use their software.


Cheers.

-- 
Regards // Oden Eriksson



From henning at loca.net  Mon Aug 15 11:35:48 2005
From: henning at loca.net (Henning Holtschneider)
Date: Mon, 15 Aug 2005 11:35:48 +0200
Subject: [Kolab-devel] Suspicious looking paths
In-Reply-To: <200508151100.51647.oeriksson@mandriva.com>
References: <200508151023.50557.radoeka@xs4all.nl>
	<200508151100.51647.oeriksson@mandriva.com>
Message-ID: <200508151135.53175.henning@loca.net>

On Monday 15 August 2005 11:00, Oden Eriksson wrote:

> When I installed KAV long time ago (don't use it anymore) it ended up
> in /opt/kaspersky (or something like that). The path is hardcoded into the
> KAV config files and also some softlinks made by the "installer". So I'd
> say, leave as is. I'd rather see we get rid of the hardcoded /kolab thing
> ;)

It's possible to choose the installation path of the anti-virus software but 
that's not recommended. You should always install the anti-virus software 
into the path they suggest because some paths are hardcoded into the 
software. That applies to both Trend Micro and Kaspersky.

> Some reflections about KAV. I bought it (v4.0.x) for personal usage with
> one year of subscription, but when I wanted to renew the subscription they
> refused me to do that, 

You shouldn't buy from Kaspersky directly. It's a Russian company and they 
still have some way to go in terms of customer satisfaction. If you buy KAV 
Personal from one of the big retailers like Amazon, it's cheaper and 
hassle-free.

> instead they wanted me to buy an upgrade that had
> nearly the same price as buying it once again. So, when they put out a new

This is common among most - if not all - of the anti-virus software 
manufacturers. The days when anti-virus software could be "bought" once and 
updated ever after are over. See it as an annual subscription service ...

Regards,
Henning Holtschneider
--
LocaNet oHG - http://www.loca.net
Lindemannstrasse 81, D-44137 Dortmund
tel +49 231 91596-25, fax +49 231 91596-55
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050815/d564756c/attachment.sig>

From kolab-issues at intevation.de  Mon Aug 15 12:48:24 2005
From: kolab-issues at intevation.de (Bernhard Herzog)
Date: Mon, 15 Aug 2005 10:48:24 +0000
Subject: [Kolab-devel] [issue878] fb retrieval only works with lowercase
	email addresses
Message-ID: <1124102904.44.0.703878556782.issue878@intevation.de>


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

When fetching a free/busy list with the url
https:/<kolabserver>/freebusy/<email-address>.ifb the email address has to be
written entirely with lower case letters.  Otherwise an empty fb/list will be
returned.

It's likely that the email address actually has to be spelled in exactly the
same way as it occurs in the pfb cache's acl files.  So it could be that it
doesn't have to be all lower-case actually.  For addresses created with kolab,
the default spelling is all lower-case, though.

The freebusy retrieval should not be case-sensitive, of course.

----------
assignedto: steffen
messages: 5254
nosy: bh, steffen
priority: bug
status: unread
title: fb retrieval only works with lowercase email addresses
topic: server
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue878>
________________________________________________



From bernhard.reiter at intevation.de  Mon Aug 15 12:50:44 2005
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Mon, 15 Aug 2005 12:50:44 +0200
Subject: [Kolab-devel] freebusy in http://srv/kolab/freebusy instead of
	/freebusy
In-Reply-To: <20050812173426.GC6311@conectiva.com.br>
References: <20050812173426.GC6311@conectiva.com.br>
Message-ID: <200508151250.45157.bernhard.reiter@intevation.de>

Am Freitag, 12. August 2005 19:34 schrieb Andreas Hasenack:

> I grepped everything and couldn't find where this is misconfigured. So I
> took a look at the source for kontact and found this in
> kmail/kmailicalifaceimpl.cpp around line 1295 in function/method
> KMailICalIfaceImpl::triggerKolabFreeBusy:
>
>   httpURL.setPath( "/freebusy/trigger/" + path + ".pfb" ); <---------------
>   httpURL.setQuery( QString::null );
>   // Ensure that we encode everything with UTF8
>   httpURL = KURL( httpURL.url(0,106), 106 );
>   kdDebug() << "Triggering PFB update for " << folderURL << " : getting "
> << httpURL << endl;
>
> So, can't Kontact work with freebusy installed somewhere else other than
> the webserver's DocumentRoot?

So far this does not seem to be configurable.
On the other hand, this could well become a convention with external servers,
so I do not consider this a huge problem. You can alias this internally on 
your webserver. 

Bernhard



From bernhard.reiter at intevation.de  Mon Aug 15 12:54:47 2005
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Mon, 15 Aug 2005 12:54:47 +0200
Subject: [Kolab-devel] Suspicious looking paths
In-Reply-To: <200508151023.50557.radoeka@xs4all.nl>
References: <200508151023.50557.radoeka@xs4all.nl>
Message-ID: <200508151254.48083.bernhard.reiter@intevation.de>

Am Montag, 15. August 2005 10:23 schrieb Richard Bos:
> during our porting effort, we came accross the following suspicious looking
> paths:
>
> FILE: amavisd.conf.template

> ['/kolab/local/kav/bin/aveclient','/kolab/local/share/kav/bin/aveclient',

> ['Trend Micro FileScanner', ['/kolab/etc/iscan/vscan','vscan'],

> Are these paths correct I would not expect them to be in /usr or /etc. 
> Your comments on those paths are highly appreciated.  

They probably depend on the proprietary scanner software and would 
leave to be configured when somebody has one of those.

> What do you think 
> should they be located in /kolab as shown in the diff above?

Both could make sense.
Because you need to adapt this file anyway when you really start
running a lot of scanning service, I think this is harmless.

Bernhard



From radoeka at xs4all.nl  Mon Aug 15 13:30:34 2005
From: radoeka at xs4all.nl (Richard Bos)
Date: Mon, 15 Aug 2005 13:30:34 +0200
Subject: [Kolab-devel] Suspicious looking paths
In-Reply-To: <200508151100.51647.oeriksson@mandriva.com>
References: <200508151023.50557.radoeka@xs4all.nl>
	<200508151100.51647.oeriksson@mandriva.com>
Message-ID: <200508151330.35567.radoeka@xs4all.nl>

Op maandag 15 augustus 2005 11:00, schreef Oden Eriksson:
> I'd rather see we get rid of the hardcoded /kolab thing

We are getting close.  At the moment one more question.  We encounter the 
following diff in httpd.conf

@@ -138,7 +143,7 @@
     Deny from all
 </Files>
 
-TypesConfig etc/apache/mime.types
+TypesConfig /kolab/etc/apache/mime.types



Is it okay to have the TypesConfig variable be absolute instead of relative 
(btw relative to what)?

-- 
Richard Bos
Without a home the journey is endless



From markus at relix.de  Mon Aug 15 14:17:04 2005
From: markus at relix.de (Markus Heller)
Date: Mon, 15 Aug 2005 14:17:04 +0200
Subject: [Kolab-devel] Open ports?
Message-ID: <200508151417.04760.markus@relix.de>

Dear experts,

I'm interested to hear your opinion about which open ports should better be 
hidden behind an iptables entry...

I see that the following ports are open:

mykolab:~# netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       
User       Inode      PID/Program name
tcp        0      0 0.0.0.0:993             0.0.0.0:*               LISTEN     
0          543953     16120/cyrmaster
tcp        0      0 0.0.0.0:995             0.0.0.0:*               LISTEN     
0          543956     16120/cyrmaster
tcp        0      0 0.0.0.0:389             0.0.0.0:*               LISTEN     
0          385452     2132/slapd
tcp        0      0 127.0.0.1:10024         0.0.0.0:*               LISTEN     
19415      385856     2658/amavisd (maste
tcp        0      0 127.0.0.1:10025         0.0.0.0:*               LISTEN     
0          386455     3262/master
tcp        0      0 127.0.0.1:10026         0.0.0.0:*               LISTEN     
0          386458     3262/master
tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN     
0          543950     16120/cyrmaster
tcp        0      0 127.0.0.1:9999          0.0.0.0:*               LISTEN     
0          386571     3393/perl
tcp        0      0 127.0.0.1:783           0.0.0.0:*               LISTEN     
0          385756     2553/spamassassin.p
tcp        0      0 0.0.0.0:2000            0.0.0.0:*               LISTEN     
0          543959     16120/cyrmaster
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN     
0          491528     24939/apache2
tcp        0      0 0.0.0.0:465             0.0.0.0:*               LISTEN     
0          386444     3262/master
tcp        0      0 127.0.0.1:2003          0.0.0.0:*               LISTEN     
0          543964     16120/cyrmaster
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
0          1219       1176/sshd
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN     
0          386391     3262/master
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN     
0          392110     7230/apache
tcp        0      0 0.0.0.0:636             0.0.0.0:*               LISTEN     
0          385454     2132/slapd

well, I banned kolab-apache from using port 80 and told apache2 to live there. 

and nmap says 

PORT     STATE    SERVICE
22/tcp   open     ssh
25/tcp   open     smtp
80/tcp   open     http
143/tcp  open     imap
389/tcp  open     ldap
443/tcp  open     https
445/tcp  filtered microsoft-ds
465/tcp  open     smtps
636/tcp  open     ldapssl
993/tcp  open     imaps
995/tcp  open     pop3s
2000/tcp open     callbook
6667/tcp filtered irc

Thanks for your advice!

Markus



From oeriksson at mandriva.com  Mon Aug 15 14:46:21 2005
From: oeriksson at mandriva.com (Oden Eriksson)
Date: Mon, 15 Aug 2005 14:46:21 +0200
Subject: [Kolab-devel] Suspicious looking paths
In-Reply-To: <200508151330.35567.radoeka@xs4all.nl>
References: <200508151023.50557.radoeka@xs4all.nl>
	<200508151100.51647.oeriksson@mandriva.com>
	<200508151330.35567.radoeka@xs4all.nl>
Message-ID: <200508151446.21671.oeriksson@mandriva.com>

m?ndag 15 augusti 2005 13.30 skrev Richard Bos:
> Op maandag 15 augustus 2005 11:00, schreef Oden Eriksson:
> > I'd rather see we get rid of the hardcoded /kolab thing
>
> We are getting close.  At the moment one more question.  We encounter the
> following diff in httpd.conf
>
> @@ -138,7 +143,7 @@
>      Deny from all
>  </Files>
>
> -TypesConfig etc/apache/mime.types
> +TypesConfig /kolab/etc/apache/mime.types
>
>
>
> Is it okay to have the TypesConfig variable be absolute instead of relative
> (btw relative to what)?

Relative to ServerRoot:

httpd -V | grep HTTPD_ROOT

-- 
Regards // Oden Eriksson



From andreas at conectiva.com.br  Mon Aug 15 16:04:05 2005
From: andreas at conectiva.com.br (Andreas Hasenack)
Date: Mon, 15 Aug 2005 11:04:05 -0300
Subject: [Kolab-devel] freebusy in http://srv/kolab/freebusy instead of
	/freebusy
In-Reply-To: <200508151250.45157.bernhard.reiter@intevation.de>
References: <20050812173426.GC6311@conectiva.com.br>
	<200508151250.45157.bernhard.reiter@intevation.de>
Message-ID: <20050815140404.GC5450@conectiva.com.br>

On Mon, Aug 15, 2005 at 12:50:44PM +0200, Bernhard Reiter wrote:
> Am Freitag, 12. August 2005 19:34 schrieb Andreas Hasenack:
> 
> > I grepped everything and couldn't find where this is misconfigured. So I
> > took a look at the source for kontact and found this in
> > kmail/kmailicalifaceimpl.cpp around line 1295 in function/method
> > KMailICalIfaceImpl::triggerKolabFreeBusy:
> >
> >   httpURL.setPath( "/freebusy/trigger/" + path + ".pfb" ); <---------------
> >   httpURL.setQuery( QString::null );
> >   // Ensure that we encode everything with UTF8
> >   httpURL = KURL( httpURL.url(0,106), 106 );
> >   kdDebug() << "Triggering PFB update for " << folderURL << " : getting "
> > << httpURL << endl;
> >
> > So, can't Kontact work with freebusy installed somewhere else other than
> > the webserver's DocumentRoot?
> 
> So far this does not seem to be configurable.

I opened a ticket upstream:
http://bugs.kde.org/show_bug.cgi?id=110649

> On the other hand, this could well become a convention with external servers,
> so I do not consider this a huge problem. You can alias this internally on 
> your webserver. 

I know. Hardcoded things in kolab/kontact are very common ;)



From kolab-issues at intevation.de  Mon Aug 15 16:41:55 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Mon, 15 Aug 2005 14:41:55 +0000
Subject: [Kolab-devel] [issue879] Quota action: refusing outgoing email!
Message-ID: <1124116915.1.0.558369420731.issue879@intevation.de>


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

Kolab Server 2.0.1rc1: 
 
When a user is overquota, it would be an interesting escalation 
to actually forbit this user to send email, 
instead of just blocking incoming emails. 
Users might care more about the ability to send 
then to receive. 
 
Steffen: I need an effort estimate for this.

----------
assignedto: steffen
messages: 5258
nosy: bernhard, steffen
priority: wish
status: unread
title: Quota action: refusing outgoing email!
topic: kksa, server
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue879>
________________________________________________



From kolab-issues at intevation.de  Mon Aug 15 19:54:34 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Mon, 15 Aug 2005 17:54:34 +0000
Subject: [Kolab-devel] [issue880] Client: freebusy view showing empty,
	for no-information
Message-ID: <1124128474.64.0.873264740486.issue880@intevation.de>


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

KDE client proko2 branch:   
   
Add an attendee which does not have a freebusy list yet.  
(You can verify with a webbrowser getting the .ifb, it should contain 
text that this is a dummy fblist.)  
  
Now the gantt chart for the time after a while removes  
the stipes to become white. White indicates that there are   
information about this section, and the user has not appointment.  
In case of the dummy fblist we do not have information about this time, 
thus this should not become white.

----------
messages: 5263
nosy: bernhard, bh, david, till
status: unread
title: Client: freebusy view showing empty, for no-information
topic: kde client, kkc
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue880>
________________________________________________



From bernhard.reiter at intevation.de  Mon Aug 15 21:48:07 2005
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Mon, 15 Aug 2005 21:48:07 +0200
Subject: [Kolab-devel] freebusy in http://srv/kolab/freebusy instead of
	/freebusy
In-Reply-To: <20050815140404.GC5450@conectiva.com.br>
References: <20050812173426.GC6311@conectiva.com.br>
	<200508151250.45157.bernhard.reiter@intevation.de>
	<20050815140404.GC5450@conectiva.com.br>
Message-ID: <200508152148.07493.bernhard.reiter@intevation.de>

Am Montag, 15. August 2005 16:04 schrieb Andreas Hasenack:
> On Mon, Aug 15, 2005 at 12:50:44PM +0200, Bernhard Reiter wrote:
> > Am Freitag, 12. August 2005 19:34 schrieb Andreas Hasenack:

> > > So, can't Kontact work with freebusy installed somewhere else other
> > > than the webserver's DocumentRoot?
> >
> > So far this does not seem to be configurable.
>
> I opened a ticket upstream:
> http://bugs.kde.org/show_bug.cgi?id=110649
>
> > On the other hand, this could well become a convention with external
> > servers, so I do not consider this a huge problem. You can alias this
> > internally on your webserver.
>
> I know. Hardcoded things in kolab/kontact are very common ;)

Actually I think it was fine to hardcode it, if this is a standard with Kolab 
Servers. Otherwise someone from external which only has your email address
cannot determine where to get the freebusy list for.

At least it should not be a configuration option offered to the user,
it makes the interface more complex and it is complex enough already. ;)



From bernhard.reiter at intevation.de  Mon Aug 15 21:52:44 2005
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Mon, 15 Aug 2005 21:52:44 +0200
Subject: [Kolab-devel] Open ports?
In-Reply-To: <200508151417.04760.markus@relix.de>
References: <200508151417.04760.markus@relix.de>
Message-ID: <200508152152.44733.bernhard.reiter@intevation.de>

Am Montag, 15. August 2005 14:17 schrieb Markus Heller:
> I'm interested to hear your opinion about which open ports should better be
> hidden behind an iptables entry...

Hide those, they are for internal use:
> tcp        0      0 127.0.0.1:10024         0.0.0.0:*               LISTEN
> 19415      385856     2658/amavisd (maste
> tcp        0      0 127.0.0.1:10025         0.0.0.0:*               LISTEN
> 0          386455     3262/master
> tcp        0      0 127.0.0.1:10026         0.0.0.0:*               LISTEN
> 0          386458     3262/master

> tcp        0      0 127.0.0.1:9999          0.0.0.0:*               LISTEN
> 0          386571     3393/perl
> tcp        0      0 127.0.0.1:783           0.0.0.0:*               LISTEN
> 0          385756     2553/spamassassin.p

This one can be used over a vpn or if all people use TLS over IMAP,
otherwise you can block it, as people can use the SSL IMAP port:
> tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN
> 0          543950     16120/cyrmaster


The following is sieve, because it is unencrypted, you shall
block it outside of your trusted network:
> tcp        0      0 0.0.0.0:2000            0.0.0.0:*               LISTEN
> 0          543959     16120/cyrmaster

Bernhard



From andreas at conectiva.com.br  Mon Aug 15 22:11:11 2005
From: andreas at conectiva.com.br (Andreas Hasenack)
Date: Mon, 15 Aug 2005 17:11:11 -0300
Subject: [Kolab-devel] freebusy in http://srv/kolab/freebusy instead of
	/freebusy
In-Reply-To: <200508152148.07493.bernhard.reiter@intevation.de>
References: <20050812173426.GC6311@conectiva.com.br>
	<200508151250.45157.bernhard.reiter@intevation.de>
	<20050815140404.GC5450@conectiva.com.br>
	<200508152148.07493.bernhard.reiter@intevation.de>
Message-ID: <20050815201111.GG5450@conectiva.com.br>

On Mon, Aug 15, 2005 at 09:48:07PM +0200, Bernhard Reiter wrote:
> Am Montag, 15. August 2005 16:04 schrieb Andreas Hasenack:
> > On Mon, Aug 15, 2005 at 12:50:44PM +0200, Bernhard Reiter wrote:
> > > Am Freitag, 12. August 2005 19:34 schrieb Andreas Hasenack:
> 
> > > > So, can't Kontact work with freebusy installed somewhere else other
> > > > than the webserver's DocumentRoot?
> > >
> > > So far this does not seem to be configurable.
> >
> > I opened a ticket upstream:
> > http://bugs.kde.org/show_bug.cgi?id=110649
> >
> > > On the other hand, this could well become a convention with external
> > > servers, so I do not consider this a huge problem. You can alias this
> > > internally on your webserver.
> >
> > I know. Hardcoded things in kolab/kontact are very common ;)
> 
> Actually I think it was fine to hardcode it, if this is a standard with Kolab 
> Servers. Otherwise someone from external which only has your email address
> cannot determine where to get the freebusy list for.
> 
> At least it should not be a configuration option offered to the user,
> it makes the interface more complex and it is complex enough already. ;)

Note that the interface already asks for the freebusy url. And twice (once for
your URL, and another time for other people's url where we use %EMAIL%).




From andreas at conectiva.com.br  Mon Aug 15 22:14:21 2005
From: andreas at conectiva.com.br (Andreas Hasenack)
Date: Mon, 15 Aug 2005 17:14:21 -0300
Subject: [Kolab-devel] PHP5 with kolab2...?
Message-ID: <20050815201420.GH5450@conectiva.com.br>

While trying to run kolab2 with current php (which is PHP5), I came
across this error:

PHP Fatal error:  Call to undefined function domxml_open_mem() in
/var/www/html/kolab/freebusy/freebusy.class.php on line 338

That function only exists for PHP4. There could be other errors related
to PHP5, but this is the first obvious one I found.

Any movement regarding supporting PHP5? Or only when openpkg upgrades to
it?

Any specific hint/patch for the error? Another way to do the same thing?

Googling brought me to this hack:
http://alexandre.alapetite.net/doc-alex/domxml-php4-php5/index.en.html

This is scary and big. I hope only because it's a generic wrapper.



From kolab-issues at intevation.de  Tue Aug 16 12:14:58 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Tue, 16 Aug 2005 10:14:58 +0000
Subject: [Kolab-devel] [issue881] Issue a warning if a locale cannot be set.
Message-ID: <1124187298.3.0.238257285881.issue881@intevation.de>


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

Kolab Server 2.0.1rc1:   
This is only minor minor bug, it would be nice to issue a warning   
when a locale cannot be set by the php, because it is missing on the system.   
Then it would explain why the language switching does not work.

----------
assignedto: steffen
messages: 5267
nosy: bernhard, bh, steffen
priority: wish
status: unread
title: Issue a warning if a locale cannot be set.
topic: server
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue881>
________________________________________________



From smp at openix-services.com  Tue Aug 16 12:21:35 2005
From: smp at openix-services.com (Sidoine Mosiah PIERREL)
Date: Tue, 16 Aug 2005 12:21:35 +0200
Subject: [Kolab-devel] [Kolab 2.1rc1] - Installation and state of the art
	(for me...)
Message-ID: <4301BE2F.4070203@openix-services.com>

Hello,

I tried the 2.1rc1 to test it. The installation came without trouble on 
a Athlon 700 system and it was, like the stable version, very smooth. 
But, I got trouble to make it work with Kontact. I created several users 
with several way to identificate (e-mail login or plain text login) but 
only the plain text login (ie: spierrel) accepted to identificate. And I 
got trouble with the ca authority. I will try it again and send you as 
many information as I can.

Regards,

Sidoine
---



From kolab-issues at intevation.de  Tue Aug 16 12:32:41 2005
From: kolab-issues at intevation.de (Bernhard Herzog)
Date: Tue, 16 Aug 2005 10:32:41 +0000
Subject: [Kolab-devel] [issue882] Kolabd creates imap accounts for external
	users
Message-ID: <1124188361.25.0.619782057304.issue882@intevation.de>


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

In Kolab server 2.0.1rc1, kolabd creates imap accounts for any external users
that have an email address.

We had this bug before but it was fixed in one of the 2.0 betas (issue482).

The following patch fixes it for me.  The patch reverts one of the changes made
between 2.0.0 and 2.0.1rc1:

--- /kolab/lib/perl/vendor_perl/5.8.7/Kolab/LDAP.pm~	Thu Jul 28 03:28:51 2005
+++ /kolab/lib/perl/vendor_perl/5.8.7/Kolab/LDAP.pm	Tue Aug 16 12:26:38 2005
@@ -481,7 +481,7 @@
     }
     %newuid_db = ();
 
-    syncBasic($cyrus, 'user', '', 0);
+    syncBasic($cyrus, 'user', '(uid=*)', 0);
     syncBasic($cyrus, 'sf', '', 1);
     syncBasic($cyrus, 'group', '', 0);

----------
assignedto: steffen
messages: 5270
nosy: bh, steffen
priority: bug
status: unread
title: Kolabd creates imap accounts for external users
topic: server
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue882>
________________________________________________



From alessandro.fiorino at gmail.com  Tue Aug 16 12:39:02 2005
From: alessandro.fiorino at gmail.com (Alessandro Fiorino)
Date: Tue, 16 Aug 2005 12:39:02 +0200
Subject: [Kolab-devel] main.cf permissions
Message-ID: <d790496105081603396134367e@mail.gmail.com>

I've noticed that the /kolab/etc/postfix/main.cf is owned by
kolab:kolab-r with read allowed only for user and group. The problem
is that the /kolab/sbin/sendmail program needs read access for this
file, so if I want a script to send mail starting under another user
(e.g. with a cron job) I get a permission read error.
Why this file doesn't have read access by everyone? I think it's the
default behaviour when using postfix standalone.



From andreas at conectiva.com.br  Tue Aug 16 14:37:41 2005
From: andreas at conectiva.com.br (Andreas Hasenack)
Date: Tue, 16 Aug 2005 09:37:41 -0300
Subject: [Kolab-devel] main.cf permissions
In-Reply-To: <d790496105081603396134367e@mail.gmail.com>
References: <d790496105081603396134367e@mail.gmail.com>
Message-ID: <20050816123740.GG3961@conectiva.com.br>

On Tue, Aug 16, 2005 at 12:39:02PM +0200, Alessandro Fiorino wrote:
> I've noticed that the /kolab/etc/postfix/main.cf is owned by
> kolab:kolab-r with read allowed only for user and group. The problem
> is that the /kolab/sbin/sendmail program needs read access for this
> file, so if I want a script to send mail starting under another user
> (e.g. with a cron job) I get a permission read error.
> Why this file doesn't have read access by everyone? I think it's the
> default behaviour when using postfix standalone.

Earlier it had a ldap bind password there. Now the ldap maps definitions
are in external files, so main.cf can get back to 0644. However, I'm not
sure if the sendmail program will need to read the ldap map definitions
as well (g-rwx), but I think not.



From alessandro.fiorino at gmail.com  Tue Aug 16 14:54:05 2005
From: alessandro.fiorino at gmail.com (Alessandro Fiorino)
Date: Tue, 16 Aug 2005 14:54:05 +0200
Subject: [Kolab-devel] main.cf permissions
In-Reply-To: <20050816123740.GG3961@conectiva.com.br>
References: <d790496105081603396134367e@mail.gmail.com>
	<20050816123740.GG3961@conectiva.com.br>
Message-ID: <d790496105081605547f508292@mail.gmail.com>

I've tried but the kolabconf script resets the permissions to 640 when executed.
Time for a patch ? Have I to fill a bug report ?

2005/8/16, Andreas Hasenack <andreas at conectiva.com.br>:
> 
> Earlier it had a ldap bind password there. Now the ldap maps definitions
> are in external files, so main.cf can get back to 0644. However, I'm not
> sure if the sendmail program will need to read the ldap map definitions
> as well (g-rwx), but I think not.
>



From kolab-issues at intevation.de  Tue Aug 16 14:54:06 2005
From: kolab-issues at intevation.de (Michael Leupold)
Date: Tue, 16 Aug 2005 12:54:06 +0000
Subject: [Kolab-devel] [issue883] Linking kolab items
Message-ID: <1124196846.7.0.075880195795.issue883@intevation.de>


New submission from Michael Leupold <leupold at leunet.de>:

Administrating a mixed Kolab2/Toltec/Kontact environment I see one major    
advantage in using Outlook: Interweaving of different kinds of information.   
By attaching a link to some contact to a calendar item (eg. a birthday), I can   
efficiently "browse" to that contact. It's also nice being able to link   
contacts together (eg. some kind of relationship).   
Browsing the kolab format specification I can't find any reference on how that   
kind of information may be stored. Has this already been discussed?   
   
Maybe the uid could be used to reference other kolab items, dn for referencing  
ldap items?

----------
messages: 5279
nosy: lemma
priority: wish
status: unread
title: Linking kolab items
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue883>
________________________________________________



From andreas at conectiva.com.br  Tue Aug 16 14:58:05 2005
From: andreas at conectiva.com.br (Andreas Hasenack)
Date: Tue, 16 Aug 2005 09:58:05 -0300
Subject: [Kolab-devel] main.cf permissions
In-Reply-To: <d790496105081605547f508292@mail.gmail.com>
References: <d790496105081603396134367e@mail.gmail.com>
	<20050816123740.GG3961@conectiva.com.br>
	<d790496105081605547f508292@mail.gmail.com>
Message-ID: <20050816125805.GH3961@conectiva.com.br>

On Tue, Aug 16, 2005 at 02:54:05PM +0200, Alessandro Fiorino wrote:
> I've tried but the kolabconf script resets the permissions to 640 when executed.
> Time for a patch ? Have I to fill a bug report ?

The version from CVS (and 2.0.1rc1 IIRC) uses a special header in those
template files where you can adjust the permission and ownership to 
whatever you want.



From suse-tux at gmx.de  Tue Aug 16 16:01:30 2005
From: suse-tux at gmx.de (Marcus aka }-Tux-{)
Date: Tue, 16 Aug 2005 16:01:30 +0200
Subject: [Kolab-devel] kolabd new build mechanism
Message-ID: <20050816160130.678ba409@linux.linux-network>

Hi,

Richard and I finished the with porting the kolabd module. It's free
configuralbe now and should work without any problems :)

Howto apply the whole stuff:

1.) change to the kolabd/kolabd directory and run the movefiles script
(which i attached)
2.) copy the bootstrap, configure.ac and Makefile.am to the
kolabd/kolabd directory
3.) copy the dist_conf/ (which i attached, too) into the kolabd/kolabd
dir
4.) apply the kolabd-auto.patch

if you just wanna do a quick test use the kolabd-1.9.4.tar.bz2 :)


Now you can install the kolabd-modules:
1.) ./bootstrap (generates the configure script)
2.) if you want to install it in a normal kolab environment just run
'./configure --prefix=/kolab'
    2.1) for more configure options see './configure --help'
3.) now it's time to install it. Just type 'make install' to start the
installation.
4.) enjoy :)


If you've any question please send it to the kolab-devel list or
directly to me (suse-tux at gmx.de)

Could someone with enough karma commit this to cvs, either to HEAD or
starting with a branch?


Cheers Marcus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kolabd-auto.patch
Type: text/x-patch
Size: 101786 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050816/cef0bd01/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: movefiles
Type: application/octet-stream
Size: 554 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050816/cef0bd01/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bootstrap
Type: application/octet-stream
Size: 90 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050816/cef0bd01/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure.ac
Type: application/octet-stream
Size: 1186 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050816/cef0bd01/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile.am
Type: application/octet-stream
Size: 15779 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050816/cef0bd01/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kolabd-1.9.4.tar.bz2
Type: application/x-bzip
Size: 144072 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050816/cef0bd01/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dist_conf.tar.bz2
Type: application/x-bzip
Size: 2488 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050816/cef0bd01/attachment-0002.bin>

From henning at loca.net  Tue Aug 16 16:19:22 2005
From: henning at loca.net (Henning Holtschneider)
Date: Tue, 16 Aug 2005 16:19:22 +0200
Subject: [Kolab-devel] main.cf permissions
In-Reply-To: <d790496105081605547f508292@mail.gmail.com>
References: <d790496105081603396134367e@mail.gmail.com>
	<20050816123740.GG3961@conectiva.com.br>
	<d790496105081605547f508292@mail.gmail.com>
Message-ID: <200508161619.26625.henning@loca.net>

On Tuesday 16 August 2005 14:54, Alessandro Fiorino wrote:
> I've tried but the kolabconf script resets the permissions to 640 when

You have to modify the permissions 
in /kolab/lib/perl/vendor_perl/5.8.5/Kolab/Conf.pm to be preserved when 
running kolabconf.

> executed. Time for a patch ? Have I to fill a bug report ?

I think this has already been taken care of in CVS.

Regards,
Henning Holtschneider
--
LocaNet oHG - http://www.loca.net
Lindemannstrasse 81, D-44137 Dortmund
tel +49 231 91596-25, fax +49 231 91596-55
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050816/f29b5ad2/attachment.sig>

From kolab-issues at intevation.de  Tue Aug 16 16:21:44 2005
From: kolab-issues at intevation.de (Bernhard Herzog)
Date: Tue, 16 Aug 2005 14:21:44 +0000
Subject: [Kolab-devel] [issue884] external events stay "marked for deletion"
Message-ID: <1124202104.52.0.677497995592.issue884@intevation.de>


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

With kolab server 2.0.1rc1, deletion of external addresses doesn't work anymore.
 The entry is marked for deletion, but it's never actually deleted.
When I look at the corresponding ldap entry, I can see that the kolabdeleteflag
contains all the servers (master and slaves), none of them seem to remove
themselves from that list.

----------
assignedto: steffen
messages: 5280
nosy: bh, steffen
priority: bug
status: unread
title: external events stay "marked for deletion"
topic: web admin
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue884>
________________________________________________



From lists at pietrosanti.it  Tue Aug 16 16:35:30 2005
From: lists at pietrosanti.it (Fabio Pietrosanti)
Date: Tue, 16 Aug 2005 16:35:30 +0200
Subject: [Kolab-devel] Kolab 2.1 compilation error on debian testing
Message-ID: <20050816143555.237661D8F32@supertolla.itapac.net>

Debian Testing of 16/08/2005

xerv06:/kolab/RPM/PKG# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gettext --enable-threads=posix --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.1 (Debian 4.0.1-2)

Receive the following error during compilation after issuing a ./obmtool
kolab:

make[2]: Leaving directory `/kolab/RPM/TMP/openpkg-2.4.2/rpm-4.2.1/intl'
Making all in file
make[2]: Entering directory `/kolab/RPM/TMP/openpkg-2.4.2/rpm-4.2.1/file'
cd . && true
cat ./Header ./Localstuff > magic
for frag in Magdir/acorn Magdir/adi Magdir/adventure Magdir/allegro
Magdir/alliant Magdir/alpha Magdir/amanda Magdir/amigaos
Magdir/animation Magdir/apl Magdir/apple Magdir/applix Magdir/archive
Magdir/asterix Magdir/att3b Magdir/audio Magdir/blender Magdir/blit
Magdir/bsdi Magdir/c-lang Magdir/cddb Magdir/chi Magdir/cisco
Magdir/citrus Magdir/claris Magdir/clipper Magdir/commands
Magdir/compress Magdir/console Magdir/convex Magdir/ctags Magdir/cvs
Magdir/database Magdir/diamond Magdir/diff Magdir/digital Magdir/dolby
Magdir/dump Magdir/dyadic Magdir/editors Magdir/elf Magdir/encore
Magdir/epoc Magdir/filesystems Magdir/flash Magdir/fonts Magdir/frame
Magdir/freebsd Magdir/fsav Magdir/gimp Magdir/gnu Magdir/grace
Magdir/gringotts Magdir/hitachi-sh Magdir/hp Magdir/ibm370
Magdir/ibm6000 Magdir/iff Magdir/images Magdir/impulse Magdir/intel
Magdir/interleaf Magdir/island Magdir/ispell Magdir/java Magdir/jpeg
Magdir/karma Magdir/lecter Magdir/lex Magdir/lif Magdir/linux
Magdir/lisp Magdir/mach Magdir/macintosh Magdir/magic Magdir/mail.news
Magdir/maple Magdir/mathematica Magdir/mcrypt Magdir/mime Magdir/mips
Magdir/mirage Magdir/mkid Magdir/mmdf Magdir/mlssa Magdir/modem
Magdir/motorola Magdir/msdos Magdir/msvc Magdir/natinst Magdir/ncr
Magdir/netbsd Magdir/netscape Magdir/news Magdir/nitpicker Magdir/octave
Magdir/olf Magdir/os2 Magdir/os9 Magdir/osf1 Magdir/palm Magdir/parix
Magdir/pbm Magdir/pdf Magdir/pdp Magdir/perl Magdir/pgp Magdir/pkgadd
Magdir/plus5 Magdir/printer Magdir/project Magdir/psdbms Magdir/pulsar
Magdir/pyramid Magdir/python Magdir/riff Magdir/rpm Magdir/rtf Magdir/sc
Magdir/sccs Magdir/sendmail Magdir/sequent Magdir/sgml Magdir/sharc
Magdir/sketch Magdir/smalltalk Magdir/sniffer Magdir/softquad
Magdir/spectrum Magdir/sun Magdir/sysex Magdir/teapot Magdir/terminfo
Magdir/tex Magdir/tgif Magdir/ti-8x Magdir/timezone Magdir/troff
Magdir/tuxedo Magdir/typeset Magdir/unknown Magdir/uuencode
Magdir/varied.out Magdir/vax Magdir/vicar Magdir/visx Magdir/vms
Magdir/vmware Magdir/vorbis Magdir/vxl Magdir/wordperfect Magdir/xdelta
Magdir/xenix Magdir/zilog Magdir/zyxel; do \
  if test -f ./$frag; then \
    f=./$frag; \
  else \
    f=$frag; \
  fi; \
          cat $f; \
done >> magic
if /usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.  
-DMAGIC='"/kolab/lib/openpkg/magic"'  -DOPENPKG -DOPENPKG_LINUX
-I/kolab/RPM/TMP/openpkg-2.4.2/zlib-1.2.3
-I/kolab/RPM/TMP/openpkg-2.4.2/bzip2-1.0.3
-I/kolab/RPM/TMP/openpkg-2.4.2/beecrypt-4.1.2 -D_GNU_SOURCE -D_REENTRANT
-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes
-Wno-char-subscripts -MT file.o -MD -MP -MF ".deps/file.Tpo" \
  -c -o file.o `test -f 'file.c' || echo './'`file.c; \
then mv -f ".deps/file.Tpo" ".deps/file.Po"; \
else rm -f ".deps/file.Tpo"; exit 1; \
fi
In file included from /usr/include/inttypes.h:28,
                 from system.h:17,
                 from file.c:28:
/usr/include/stdint.h:49: error: duplicate 'unsigned'
/usr/include/stdint.h:49: error: two or more data types in declaration
specifiers
                                                                               
/usr/include/stdint.h:50: error: duplicate 'unsigned'
/usr/include/stdint.h:50: error: duplicate 'short'
/usr/include/stdint.h:52: error: duplicate 'unsigned'
/usr/include/stdint.h:52: error: two or more data types in declaration
specifiers
                                                                               
make[2]: *** [file.o] Error 1
make[2]: Leaving directory `/kolab/RPM/TMP/openpkg-2.4.2/rpm-4.2.1/file'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/kolab/RPM/TMP/openpkg-2.4.2/rpm-4.2.1'
make: *** [all] Error 2
+ exit 2
./openpkg.boot:ERROR: script returned non-null value
/tmp/obmtool.1947.tmp: line 2:
/kolab/RPM/PKG/openpkg-2.4.2-2.4.2.*-*-*.sh: No such file or directory
obmtool:ERROR: bootstrapping failed
xerv06:/kolab/RPM/PKG#




From lists at pietrosanti.it  Tue Aug 16 17:23:24 2005
From: lists at pietrosanti.it (Fabio Pietrosanti)
Date: Tue, 16 Aug 2005 17:23:24 +0200
Subject: [Kolab-devel] Kolab 2.1 compilation error on debian testing
In-Reply-To: <20050816143610.EF9791D8F32@supertolla.itapac.net>
References: <20050816143610.EF9791D8F32@supertolla.itapac.net>
Message-ID: <20050816152349.288331D8F7A@supertolla.itapac.net>

Ok, resolved changing the gcc to 3.3 version.

It seems that file components of openpkg still doesn't work with gcc 4.

Fabio Pietrosanti ha scritto:

>Debian Testing of 16/08/2005
>
>xerv06:/kolab/RPM/PKG# gcc -v
>Using built-in specs.
>Target: i486-linux-gnu
>Configured with: ../src/configure -v
>--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
>--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls
>--without-included-gettext --enable-threads=posix --program-suffix=-4.0
>--enable-__cxa_atexit --enable-libstdcxx-allocator=mt
>--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
>--enable-java-awt=gtk
>--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
>--enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu
>Thread model: posix
>gcc version 4.0.1 (Debian 4.0.1-2)
>  
>



From mangoo at mch.one.pl  Tue Aug 16 17:26:55 2005
From: mangoo at mch.one.pl (Tomasz Chmielewski)
Date: Tue, 16 Aug 2005 17:26:55 +0200
Subject: [Kolab-devel] LDAP DN reorganization.
Message-ID: <430205BF.8060707@mch.one.pl>

> I'm relatively new to the Kolab development world, and I'm really impressed
> with the amount of work completed in this project.
> 
>  
> 
> As I've been looking through the code base and reviewing my Kolab 2
> installation, I've come across an issue with LDAP.  It seems that Kolab 2
> uses the First Name and Last Name attributes to compose the base cn
> attribute of an entry's distinguished name (DN).  In my experience, this
> presents a challenge (and a kolab UI error) when you have two people with
> the same names.  Here in the States, that can be a common problem.  Is their
> a commonly known drawback in other areas of Kolab2 to use the unique ID
> attribute for the DN?  Since UIDs must be unique, we could avoid name
> collisions in the cn=internal branch of the tree.

Hi,

You might want to use LAM - LDAP Account Manager - http://lam.sf.net - 
for managing Kolab accounts (but then don't use Kolab web-GUI for 
editing such created users).

It creates users in a "right" format:

uid=bbaggins,ou=Users,dc=my,dc=server

and Kolab can read it.


-- 
Tomek
http://wpkg.org



From kolab-issues at intevation.de  Tue Aug 16 17:32:49 2005
From: kolab-issues at intevation.de (Bernhard Herzog)
Date: Tue, 16 Aug 2005 15:32:49 +0000
Subject: [Kolab-devel] [issue885] kolabd creates shared folders in wrong
	directory
Message-ID: <1124206369.33.0.73777653233.issue885@intevation.de>


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

Kolab server 2.0.1rc1 (probably also in older versions)

Normally shared folders are ultimately represented as directories under
/kolab/var/imapd/spool/domain/<kolab domain name>.  If, however, the base dn
used by the kolab server does not end in the dc-elements that make up the
domain, the directories will be directly in /kolab/var/imapd/spool/domain/
because the imapd doesn't get the information to which domain the shared folder
belongs.  Such a base dn can easily occur when the ldap server used with kolab
is not the one distributed and managed by kolab itself.

More precisely, the bug is most likely the following code in createObject in
LDAP.pm:

   if( $p eq 'sf' ) {
     # We have to create shared folders
     # with names user.<fldrname>@<domain>
     my @dcs = split(/,/,$object->dn());
     my @dn;
     while( pop( @dcs ) =~ /dc=(.*)/ ) {
       push(@dn, $1);
     }
     if( $#dn > 0 ) { $uid .= '@'.join('.',reverse(@dn)); }
   }

Note how the domain component of the uid is constructed of the dc elements at
the end of the dn of the ldap entry of the shared folder.

----------
assignedto: steffen
messages: 5282
nosy: bh, steffen
priority: bug
status: unread
title: kolabd creates shared folders in wrong directory
topic: server
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue885>
________________________________________________



From kolab-issues at intevation.de  Tue Aug 16 18:06:30 2005
From: kolab-issues at intevation.de (Bernhard Herzog)
Date: Tue, 16 Aug 2005 16:06:30 +0000
Subject: [Kolab-devel] [issue886] german translation of webadmin interface
	is not up to date
Message-ID: <1124208390.0.0.10694080583.issue886@intevation.de>


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

Kolab server 2.0.1rc1.  The german translation of the web admin interface is not
up to date.  One untranslated string is in addr.php:
"Address book entry with DN $dn  was deleted"

----------
assignedto: steffen
messages: 5284
nosy: bh, steffen
priority: minor bug
status: unread
title: german translation of webadmin interface is not up to date
topic: web admin
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue886>
________________________________________________



From mangoo at mch.one.pl  Tue Aug 16 18:14:55 2005
From: mangoo at mch.one.pl (Tomasz Chmielewski)
Date: Tue, 16 Aug 2005 18:14:55 +0200
Subject: [Kolab-devel] IMAP - Sent, Draft, Template folders not created?
Message-ID: <430210FF.90700@mch.one.pl>

When I setup a new User in Kolab an imap Folder INBOX is created.
But it does not contain the folders Sent, Drafts, Templates ...
What do I have to do to get these Folders created on user creation,
What are the nameconventions of these Folders?

Horde/Imp as well as Mozilla Mail/Thunderbird expect these Folders for 
their proper function.

I use Kolab2.

There was a topic about that in the forum, but till now there is no answer.
http://eforum.de/viewtopic.php?t=11

Does anyone have a solution for that?



From kolab-issues at intevation.de  Tue Aug 16 18:38:18 2005
From: kolab-issues at intevation.de (Adam Tworkowski)
Date: Tue, 16 Aug 2005 16:38:18 +0000
Subject: [Kolab-devel] [issue887] Access to user's sieve
	(forwarding/vacation) settings from manager/administrative account
Message-ID: <1124210298.09.0.550645160761.issue887@intevation.de>


New submission from Adam Tworkowski <atworkowski at masterfile.com>:

I would like to suggest adding a feature to the web interface so that the
administrative account can act on a user's sieve settings (forwarding, vacation)
w/o having to log out and log in as the specific user.

----------
messages: 5285
nosy: atworkowski
priority: wish
status: unread
title: Access to user's sieve (forwarding/vacation) settings from manager/administrative account
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue887>
________________________________________________



From kolab-issues at intevation.de  Tue Aug 16 18:42:00 2005
From: kolab-issues at intevation.de (Adam Tworkowski)
Date: Tue, 16 Aug 2005 16:42:00 +0000
Subject: [Kolab-devel] [issue888] Mail account suspension/deactivation
Message-ID: <1124210520.27.0.0279957642362.issue888@intevation.de>


New submission from Adam Tworkowski <atworkowski at masterfile.com>:

I would like to suggest adding an option to suspend or disable an account w/o
deleting it.  A present work around is changing the user's password.  It would
be nice to have the ability to a) lock a user out and reject mail and b) lock a
user out but still accept mail.

----------
messages: 5286
nosy: atworkowski
priority: wish
status: unread
title: Mail account suspension/deactivation
topic: web admin
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue888>
________________________________________________



From kolab-issues at intevation.de  Tue Aug 16 18:45:55 2005
From: kolab-issues at intevation.de (Adam Tworkowski)
Date: Tue, 16 Aug 2005 16:45:55 +0000
Subject: [Kolab-devel] [issue889] Query tool for showing what Distribution
	Lists a user is subscribed to.
Message-ID: <1124210755.53.0.973818942841.issue889@intevation.de>


New submission from Adam Tworkowski <atworkowski at masterfile.com>:

I would like to suggest the addition of a query tool to show what Distribution
Lists a user is subscribed to.

----------
messages: 5287
nosy: atworkowski
status: unread
title: Query tool for showing what Distribution Lists a user is subscribed to.
topic: web admin
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue889>
________________________________________________



From kolab-issues at intevation.de  Tue Aug 16 18:52:48 2005
From: kolab-issues at intevation.de (Adam Tworkowski)
Date: Tue, 16 Aug 2005 16:52:48 +0000
Subject: [Kolab-devel] [issue890] Assigning multiple Distribution Lists to
	user during creation and modification
Message-ID: <1124211168.45.0.554296384923.issue890@intevation.de>


New submission from Adam Tworkowski <atworkowski at masterfile.com>:

I would like to suggest adding a feature so that a user can be added to multiple
Distribution Lists during account creation or modification.  This could be in
the form of a lists of distribution lists with check boxes or large text box
where distribution lists are added line by line.

----------
messages: 5288
nosy: atworkowski
priority: wish
status: unread
title: Assigning multiple Distribution Lists to user during creation and modification
topic: web admin
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue890>
________________________________________________



From kolab-issues at intevation.de  Tue Aug 16 18:56:24 2005
From: kolab-issues at intevation.de (Adam Tworkowski)
Date: Tue, 16 Aug 2005 16:56:24 +0000
Subject: [Kolab-devel] [issue891] Ability to use vacationing and forwarding
	at the same time.
Message-ID: <1124211384.08.0.949753343667.issue891@intevation.de>


New submission from Adam Tworkowski <atworkowski at masterfile.com>:

I would like to suggest adding the ability to have vacationing and fowarding on
at the same time (and preferably multiple forwards).  This is common request in
my organization which is currently met via the sieve shell.  Thanks.

----------
messages: 5289
nosy: atworkowski
priority: wish
status: unread
title: Ability to use vacationing and forwarding at the same time.
topic: web admin
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue891>
________________________________________________



From andreas at conectiva.com.br  Tue Aug 16 20:30:15 2005
From: andreas at conectiva.com.br (Andreas Hasenack)
Date: Tue, 16 Aug 2005 15:30:15 -0300
Subject: [Kolab-devel] PHP5 with kolab2...?
In-Reply-To: <20050815201420.GH5450@conectiva.com.br>
References: <20050815201420.GH5450@conectiva.com.br>
Message-ID: <20050816183015.GL3961@conectiva.com.br>

On Mon, Aug 15, 2005 at 05:14:21PM -0300, Andreas Hasenack wrote:
> PHP Fatal error:  Call to undefined function domxml_open_mem() in
> /var/www/html/kolab/freebusy/freebusy.class.php on line 338
> 
> That function only exists for PHP4. There could be other errors related
> to PHP5, but this is the first obvious one I found.

Attached my first attempt at a patch to make freebusy in kolab2 use
php-dom (instead of php-domxml which is no longer available for PHP5).

I really don't know much php nor xml, so...

Things that come to mind:
- no error catching
- I couldn't find equivalents for all flags used in domxml_open_mem()
- during testing, a recurring event was different for one of the
  participants: the creator had monday->saturday, while the lonely
  participant had the whole week scheduled. I don't know if this patch
  caused it and/or if it some other bad php5 interaction.
-------------- next part --------------
--- kolab-resource-handlers/kolab-resource-handlers/freebusy/freebusy.class.php.orig	2005-08-16 15:20:58.000000000 -0300
+++ kolab-resource-handlers/kolab-resource-handlers/freebusy/freebusy.class.php	2005-08-16 15:21:02.000000000 -0300
@@ -325,44 +325,52 @@
   }
 
   function getEventHash($xml_text) {
-    $xmldoc = @domxml_open_mem($xml_text, DOMXML_LOAD_PARSING +
+/*    $xmldoc = @domxml_open_mem($xml_text, DOMXML_LOAD_PARSING +
 			       DOMXML_LOAD_COMPLETE_ATTRS + DOMXML_LOAD_SUBSTITUTE_ENTITIES +
 			       DOMXML_LOAD_DONT_KEEP_BLANKS, $error);
-    
+*/
+
+    $xmldoc = new DOMDocument;
+    $xmldoc->validateOnParse = true;
+    $xmldoc->preserveWhiteSpace = false;
+    $xmldoc->loadXML($xml_text);
+
+    /* XXX - how to catch errors in loadXML()?
     if (!empty($error)) {
       // There were errors parsing the XML data - abort
       myLog( "Error parsing \"$xml_txt\": $error", RM_LOG_ERROR);
       return false;
     }
-    
-    $noderoot = $xmldoc->document_element();
-    $childnodes = $noderoot->child_nodes();
+    */
+
+    $noderoot = $xmldoc->documentElement;
+    $childnodes = $noderoot->childNodes;
     
     $event_hash = array();
     
     // Build the event hash
     foreach ($childnodes as $value) {
-      //myLog("Looking at tag ".($value->tagname), RM_LOG_DEBUG);
-      if( $value->tagname == 'recurrence' ) {
+      //myLog("Looking at tag ".($value->tagName), RM_LOG_DEBUG);
+      if( $value->tagName == 'recurrence' ) {
 	$rhash = array();
-	$attrs = $value->attributes();
+	$attrs = $value->attributes;
 	foreach( $attrs as $attr ) {
 	  //myLog("getEventHash setting rhash[".$attr->name."] = ".$attr->value, RM_LOG_DEBUG);
 	  $rhash[$attr->name] = $attr->value;
 	}
-	foreach( $value->child_nodes() as $v ) {
-	  if( $v->tagname == 'day' || $v->tagname == 'exclusion' ) {
-	    $rhash[$v->tagname][] = $v->get_content();
+	foreach( $value->childNodes as $v ) {
+	  if( $v->tagName == 'day' || $v->tagName == 'exclusion' ) {
+	    $rhash[$v->tagName][] = $v->nodeValue();
 	  } else {
-	    $rhash[$v->tagname] = $v->get_content();
-	    if( $v->tagname == 'range' && $v->has_attribute('type') ) {
-	      $rhash['rangetype'] = $v->get_attribute('type');
+	    $rhash[$v->tagName] = $v->nodeValue;
+	    if( $v->tagName == 'range' && $v->hasAttribute('type') ) {
+	      $rhash['rangetype'] = $v->getAttribute('type');
 	    }
 	  }
 	}	
-	$event_hash[$value->tagname] = $rhash;
+	$event_hash[$value->tagName] = $rhash;
       } else {
-	$event_hash[$value->tagname] = $value->get_content();
+	$event_hash[$value->tagName] = $value->nodeValue;
       }
     }
     
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050816/fd1f86f9/attachment.sig>

From miguel at rozsas.xx.nom.br  Tue Aug 16 20:33:40 2005
From: miguel at rozsas.xx.nom.br (Miguel Angelo Rozsas)
Date: Tue, 16 Aug 2005 15:33:40 -0300
Subject: [Kolab-devel] development questions
Message-ID: <200508161533.40744.miguel@rozsas.xx.nom.br>

Hi there,

I am considering to use Kolab as a framework to develop new modules that have 
a high degree of integration with the data stored from calendars, address 
book, etc.

I am exploring the idea to use kolab + additional modules to act as a 
customized backoffice application.

Could you provide me with introductory information to handle with this task ? 
What is, in your opinion, the major difficulty I will face on ?
What is the best developer's profile to work on kolab ? C/C++ or LAMP (Linux, 
Apache, MySQL, P-language)
Which is the main development language for kolab ? There is support for 
arbitrary languages other the main one ?
Do you know if there is a support for plugable module or whatever ?
Do you know if there is a template system to render HTML pages, like Smarty 
PHP template engine ?
Do you know if there is a abstraction layer for data access like PEARDB ?
There is support for internationalization (foreign languages other than 
English in the GUI) ?
Is the API fully documented ?
There is a starter kit for lazy developers ;-) ? Serious, I mean a kind of 
tutorial for development in kolab ?

I appreciate any ideas and comments.

best regards,



From andreas at conectiva.com.br  Tue Aug 16 23:46:52 2005
From: andreas at conectiva.com.br (Andreas Hasenack)
Date: Tue, 16 Aug 2005 18:46:52 -0300
Subject: [Kolab-devel] idletimeout in slapd.conf
Message-ID: <20050816214652.GO3961@conectiva.com.br>

I'm having a problem related to the low idletimeout set in slapd.conf
(openldap).

Actually, the problem lies at the client (apache's mod_auth_ldap
module), but I discovered it due to the idletimeout.

By default, the apache module is using persistent connections. It
doesn't, however, deal gracefully when the connection is dropped by the
server, either when idletimeout is hit or the ldap server is just
restarted.

Increasing the idletimeout makes this better, but is no fix. Adding
"LDAP_Persistent_G off" to the apache conf fixes it at the expense of an
increased load on the ldap server.

So, I was just wondering if somebody else saw this ;)
I guess I'll try to patch the apache module to behave better.



From lists at pietrosanti.it  Wed Aug 17 16:10:53 2005
From: lists at pietrosanti.it (Fabio Pietrosanti)
Date: Wed, 17 Aug 2005 16:10:53 +0200
Subject: [Kolab-devel] Kolab imapd openpkg options
Message-ID: <20050817141119.2206A1D8F88@supertolla.itapac.net>

Hi all,

i'm in progress of setting up a customized kolab environment.

I noticed that's not possible to compile kolab openpkg package with
"--with libwrap" and "--with snmp" because in imapd.spec are manually
cabled --without-libwrap and --without-snmp .

If possible to add those from command line i would add tcpwrapper to
kolab environment (which could be usefull for host blacklisting) and
snmp for internal cyrus imap monitoring trough snmpdx.

Fabio



From kolab-issues at intevation.de  Wed Aug 17 17:30:11 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 17 Aug 2005 15:30:11 +0000
Subject: [Kolab-devel] [issue892] Button to send email to the selected
	addresses in LDAP search
Message-ID: <1124292611.15.0.587375157749.issue892@intevation.de>


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

KDE client: 
 
In the LDAP search dialog. 
(reachable by Contact view -> magnifying glass with animal feed) 
 
There should be a button to directly mail to the selected addresses. 
Some people like to use it this was: Search for all addresses, 
select the few you want to mail to and hit that button. 
It was there in the KDE Kolab1 client. 
 
The dialog that you reach when you press "..." does not have the ldap 
search capabilities, so this really seems to be missing in the Proko2 branch. 
 
Till: Can you give me an estimation to one of the solution which is 
easier to do?

----------
assignedto: till
messages: 5298
nosy: bernhard, bh, david, till
priority: wish
status: unread
title: Button to send email to the selected addresses in LDAP search
topic: kde client, kksa
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue892>
________________________________________________



From kolab-issues at intevation.de  Wed Aug 17 17:47:05 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 17 Aug 2005 15:47:05 +0000
Subject: [Kolab-devel] [issue893] Toltec always using a windows attachment
	-> doubling the size
Message-ID: <1124293624.89.0.202962664175.issue893@intevation.de>


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

Toltec 2.0.5: 
 
Users report that Toltec doubles the size of all email messages 
that are synced up via the .pst. 
RC3 did not have that behaviour. 
 
Joon told me that this is to prevent the loss of information, 
as any plugin could set unkown flags. 
 
Still the doubling the size seems to be a problem for quotated 
users. What could we do about it. 
I remember a discussion about such flags. 
One idea was to only use the attachments when there are flags. 
Maybe this cannot be reliably detected.  
 
Could a configuration option help? Even when some flags are then disregarded? I 
believe this would be preferable in some situations. 
 
The best solution would be to only put this information in 
X-Toltec-flag--xxxxxx: YYYY 
headers and try to decode as many YYYY situations as we can over time 
so that compatibility with other clients could be made possible in the future.

----------
assignedto: joonradley
messages: 5300
nosy: bernhard, bh, joonradley
priority: bug
status: unread
title: Toltec always using a windows attachment -> doubling the size
topic: toltec
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue893>
________________________________________________



From andreas at conectiva.com.br  Wed Aug 17 22:13:36 2005
From: andreas at conectiva.com.br (Andreas Hasenack)
Date: Wed, 17 Aug 2005 17:13:36 -0300
Subject: [Kolab-devel] $mydestination in an ldap map
Message-ID: <20050817201335.GA16285@conectiva.com.br>

I don't think postfix variables such as $mydestination are expanded in
a ldap map file definition. For example,
ldap:/etc/postfix/ldapdistlist.cf:
(...)
server_host = ldap://127.0.0.1:389
search_base = dc=kolab,dc=conectiva
domain = $mydestination <-------------------
query_filter = (&(objectClass=kolabGroupOfNames)(!(kolabDeleteFlag=*))(mail=%s))
(...)

When running "postmap -q -v postmaster at kolab.conectiva ldap:/etc/postfix/ldapdistlist.cf"
I get:

(...)
postmap: cfg_get_int: /etc/postfix/ldapdistlist.cf: debuglevel = 0
postmap: dict_open: ldap:/etc/postfix/ldapdistlist.cf
postmap: dict_ldap_lookup: In dict_ldap_lookup
postmap: match_string: kolab.conectiva ~? $mydestination <===========
postmap: match_list_match: kolab.conectiva: no match <===============
postmap: dict_ldap_lookup: Skipping lookup of
'postmaster at kolab.conectiva'

So that should probably be "domain = @@@postfix-mydestination@@@" in the
template file instead, no?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050817/06f4c524/attachment.sig>

From kolab-issues at intevation.de  Thu Aug 18 01:48:10 2005
From: kolab-issues at intevation.de (Tricia Shipman)
Date: Wed, 17 Aug 2005 23:48:10 +0000
Subject: [Kolab-devel] [issue894] Why does your boyfriend pay so much
Message-ID: <U53z20W7dWJW7d0WJ4at@bsysgwy.fob.ford.com>


New submission from Tricia Shipman <gnxakkp at bsysgwy.fob.ford.com>:

Hello, Hi amigo, it's Chasity Hess

here's a question:

Looking for a bargain price on the Blue Pill?

Buddy,stop the vicious Impotence problems cycle now

More info here http://easyrx-4u.com/index.php?ref_id=766

best regards,

gnxakkp

----------
messages: 5301
nosy: gnxakkp, thomas.koester
status: unread
title: Why does your boyfriend pay so much
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue894>
________________________________________________



From andreas at conectiva.com.br  Thu Aug 18 16:26:43 2005
From: andreas at conectiva.com.br (Andreas Hasenack)
Date: Thu, 18 Aug 2005 11:26:43 -0300
Subject: [Kolab-devel] undefined indexes in several arrays
Message-ID: <20050818142643.GF5403@conectiva.com.br>

kolab seems to make several assumptions about array indexes always
existing. For example (referer ommited for brevity):

Undefined index:  kolabfilter-verify-from-header in /var/www/html/kolab/admin/service/index.php on line 87, ...
Undefined index:  kolabfilter-allow-sender-header in /var/www/html/kolab/admin/service/index.php on line 88, ...
Undefined index:  kolabfilter-reject-forged-from-header in /var/www/html/kolab/admin/service/index.php on line 89, ...

and many more.

The code there reads:
$kolabfilterverifyfrom = $attrs['kolabfilter-verify-from-header'][0];
$kolabfilterallowsender = $attrs['kolabfilter-allow-sender-header'][0];
$kolabfilterrejectforgedfrom = $attrs['kolabfilter-reject-forged-from-header'][0];

Some of these attributes only get inserted into LDAP when the user changes the
value to either TRUE or FALSE via the admin interface. After that, they are
always there.

So, is this an LDAP database initialization problem? Or should the code
be more careful and check if the index exists before attempting to use
it? Has anybody else seen this?



From kolab-issues at intevation.de  Thu Aug 18 18:27:08 2005
From: kolab-issues at intevation.de (Bernhard Herzog)
Date: Thu, 18 Aug 2005 16:27:08 +0000
Subject: [Kolab-devel] [issue895] order of kontact's components
Message-ID: <1124382428.27.0.997327090159.issue895@intevation.de>


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

In Kontact there's a list of all the components (summary, email, contacts, ...)
on  the left.  The order of the items on there is different from the order of
the items in the config dialog and on the summary config page.

The order also depends on the language, e.g. it's different in English (Calendar
is last) than in German (notes are last).

It would be best if the order of these components is the same everywhere as much
as possible.   Not sure what should happen with the different parts of
korganizer which are grouped under korganizer for konfiguration but appear as
separate component in the list on the left.

----------
assignedto: david
messages: 5303
nosy: bh, david
priority: minor bug
status: unread
title: order of kontact's components
topic: kde client, kkc
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue895>
________________________________________________



From kolab-issues at intevation.de  Thu Aug 18 18:42:09 2005
From: kolab-issues at intevation.de (Bernhard Herzog)
Date: Thu, 18 Aug 2005 16:42:09 +0000
Subject: [Kolab-devel] [issue896] Summary plugins naming inconsistency
Message-ID: <1124383329.62.0.617213340359.issue896@intevation.de>


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

The names used for the summary page plugins in the config dialog are different
from the titles they actually have on the summary page.  E.g. "New Messages" vs.
"Mail" or "Birthdays and Anniversaries" vs. "Contacts".  This is confusing. 
Using the titles from the summary page also for the config dialog would be much
better.

----------
assignedto: david
messages: 5304
nosy: bh, david
priority: minor bug
status: unread
title: Summary plugins naming inconsistency
topic: kde client
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue896>
________________________________________________



From kolab-issues at intevation.de  Thu Aug 18 18:50:02 2005
From: kolab-issues at intevation.de (Bernhard Herzog)
Date: Thu, 18 Aug 2005 16:50:02 +0000
Subject: [Kolab-devel] [issue897] Kpilot component doesn't show up in main
	window
Message-ID: <1124383802.44.0.973791992519.issue897@intevation.de>


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

Kontact lets the user choose which components they want to use with the
Settings->Select Components dialog.  The selected components appear in the list
of components on the left side of kontact's main window with an icon.  However,
the kpilot component doesn't show up ther when it's selected.

----------
assignedto: david
messages: 5305
nosy: bh, david
priority: minor bug
status: unread
title: Kpilot component doesn't show up in main window
topic: kde client
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue897>
________________________________________________



From andreas at conectiva.com.br  Thu Aug 18 19:39:23 2005
From: andreas at conectiva.com.br (Andreas Hasenack)
Date: Thu, 18 Aug 2005 14:39:23 -0300
Subject: [Kolab-devel] [PATCH] $PHP_SELF -> $_SERVER['PHP_SELF']
Message-ID: <20050818173923.GI5403@conectiva.com.br>


-------------- next part --------------
--- kolab-webadmin-0.4.9-20050812/www/admin/user/index.php.orig	2005-08-18 14:19:38.000000000 -0300
+++ kolab-webadmin-0.4.9-20050812/www/admin/user/index.php	2005-08-18 14:19:59.000000000 -0300
@@ -164,7 +164,7 @@
 $smarty->assign( 'uid', $auth->uid() );
 $smarty->assign( 'group', $auth->group() );
 $smarty->assign( 'page_title', $menuitems[$sidx]['title'] );
-$smarty->assign( 'self_url', $PHP_SELF );
+$smarty->assign( 'self_url', $_SERVER['PHP_SELF'] );
 
 $smarty->assign( 'filterattrs', array( 'cn'   => _('Name'),
 									   'mail' => _('Email'),
--- kolab-webadmin-0.4.9-20050812/www/admin/addressbook/index.php.orig	2005-08-18 14:19:46.000000000 -0300
+++ kolab-webadmin-0.4.9-20050812/www/admin/addressbook/index.php	2005-08-18 14:20:13.000000000 -0300
@@ -116,7 +116,7 @@
 $smarty->assign( 'uid', $auth->uid() );
 $smarty->assign( 'group', $auth->group() );
 $smarty->assign( 'page_title', $menuitems[$sidx]['title'] );
-$smarty->assign( 'self_url', $PHP_SELF );
+$smarty->assign( 'self_url', $_SERVER['PHP_SELF'] );
 
 $smarty->assign( 'filterattrs', array( 'cn'   => _('Name'),
 									   'mail' => _('Email') ) );
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050818/20748a76/attachment.sig>

From kolab-issues at intevation.de  Thu Aug 18 20:36:29 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Thu, 18 Aug 2005 18:36:29 +0000
Subject: [Kolab-devel] [issue898] pfbs from several folders, document it
Message-ID: <1124390189.76.0.557840653701.issue898@intevation.de>


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

Kolab Server 2.0.1rc1:     
     
userA's homeserver is X     
userB's homeserver is Y     
     
userA shares a folder with userB that is fb-relevant.     
     
Any .ifb request for userB.ifb will be answered by Y, which is fine.     
How does a triggered creation of pfb of the folder on X will    
reach Y?   
  
BH: Can you try if this works?

----------
assignedto: bh
messages: 5306
nosy: bernhard, bh, steffen
priority: bug
status: need-eg
title: pfbs from several folders, document it
topic: server
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue898>
________________________________________________



From bernhard.reiter at intevation.de  Thu Aug 18 20:42:31 2005
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Thu, 18 Aug 2005 20:42:31 +0200
Subject: [Kolab-devel] freebusy in http://srv/kolab/freebusy instead of
	/freebusy
In-Reply-To: <20050815201111.GG5450@conectiva.com.br>
References: <20050812173426.GC6311@conectiva.com.br>
	<200508152148.07493.bernhard.reiter@intevation.de>
	<20050815201111.GG5450@conectiva.com.br>
Message-ID: <200508182042.31805.bernhard.reiter@intevation.de>

Am Montag, 15. August 2005 22:11 schrieb Andreas Hasenack:
> On Mon, Aug 15, 2005 at 09:48:07PM +0200, Bernhard Reiter wrote:
> > Am Montag, 15. August 2005 16:04 schrieb Andreas Hasenack:

> > > I know. Hardcoded things in kolab/kontact are very common ;)
> >
> > Actually I think it was fine to hardcode it, if this is a standard with
> > Kolab Servers. Otherwise someone from external which only has your email
> > address cannot determine where to get the freebusy list for.
> >
> > At least it should not be a configuration option offered to the user,
> > it makes the interface more complex and it is complex enough already. ;)
>
> Note that the interface already asks for the freebusy url. And twice (once
> for your URL, and another time for other people's url where we use
> %EMAIL%).

This is for retrieval and would not be necessary if the Kolab Servers would be
the only ones offering fb-lists. So far Kolab2 Servers are the only ones that 
require a trigger, though.



From bernhard.reiter at intevation.de  Thu Aug 18 20:44:46 2005
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Thu, 18 Aug 2005 20:44:46 +0200
Subject: [Kolab-devel] [Kolab 2.1rc1] - Installation and state of the art
	(for me...)
In-Reply-To: <4301BE2F.4070203@openix-services.com>
References: <4301BE2F.4070203@openix-services.com>
Message-ID: <200508182044.46582.bernhard.reiter@intevation.de>

Hello Sidoine,

Am Dienstag, 16. August 2005 12:21 schrieb Sidoine Mosiah PIERREL:
> I tried the 2.1rc1 to test it. 

thanks for giving us a hand.

> The installation came without trouble on 
> a Athlon 700 system and it was, like the stable version, very smooth.
> But, I got trouble to make it work with Kontact. I created several users
> with several way to identificate (e-mail login or plain text login) but
> only the plain text login (ie: spierrel) accepted to identificate. And I
> got trouble with the ca authority. I will try it again and send you as
> many information as I can.

This is helpful, especially if you describe your difficulties in more detail.
Steffen will be back soon and then we will get a go at 2.1xx problems.



From bernhard.reiter at intevation.de  Thu Aug 18 20:49:49 2005
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Thu, 18 Aug 2005 20:49:49 +0200
Subject: [Kolab-devel] kolabd new build mechanism
In-Reply-To: <20050816160130.678ba409@linux.linux-network>
References: <20050816160130.678ba409@linux.linux-network>
Message-ID: <200508182049.49701.bernhard.reiter@intevation.de>

Am Dienstag, 16. August 2005 16:01 schrieb Marcus aka }-Tux-{:

> Richard and I finished the with porting the kolabd module. It's free
> configuralbe now and should work without any problems :)

Sounds good.

> Could someone with enough karma commit this to cvs, either to HEAD or
> starting with a branch?

We need to wait for Steffen as Server maintainer on this one I guess.
He will be back next week, but stuff might have piled up a bit.



From bernhard.reiter at intevation.de  Thu Aug 18 20:51:22 2005
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Thu, 18 Aug 2005 20:51:22 +0200
Subject: [Kolab-devel] Kolab 2.1 compilation error on debian testing
In-Reply-To: <20050816152349.288331D8F7A@supertolla.itapac.net>
References: <20050816143610.EF9791D8F32@supertolla.itapac.net>
	<20050816152349.288331D8F7A@supertolla.itapac.net>
Message-ID: <200508182051.22654.bernhard.reiter@intevation.de>

Am Dienstag, 16. August 2005 17:23 schrieb Fabio Pietrosanti:
> Ok, resolved changing the gcc to 3.3 version.
>
> It seems that file components of openpkg still doesn't work with gcc 4.

Maybe, you could try CURRENT
and also try to report that difficulty to the openpkg people.



From bernhard.reiter at intevation.de  Thu Aug 18 20:54:38 2005
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Thu, 18 Aug 2005 20:54:38 +0200
Subject: [Kolab-devel] IMAP - Sent, Draft, Template folders not created?
In-Reply-To: <430210FF.90700@mch.one.pl>
References: <430210FF.90700@mch.one.pl>
Message-ID: <200508182054.38290.bernhard.reiter@intevation.de>

Am Dienstag, 16. August 2005 18:14 schrieb Tomasz Chmielewski:
> When I setup a new User in Kolab an imap Folder INBOX is created.
> But it does not contain the folders Sent, Drafts, Templates ...
> What do I have to do to get these Folders created on user creation,

The folders are not created at the same time as the user,
they should be created by the client.

> What are the nameconventions of these Folders?

The client is free to create them, but uses IMAP annotations
to mark the function of the folders.
There should be one event.default for instance.

> Horde/Imp as well as Mozilla Mail/Thunderbird expect these Folders for
> their proper function.

If Horde/IMP cannot create them properly, this is still a but.
Any Kolab client should be able to create those folders.

> I use Kolab2.
>
> There was a topic about that in the forum, but till now there is no answer.
> http://eforum.de/viewtopic.php?t=11



From bernhard.reiter at intevation.de  Thu Aug 18 21:05:45 2005
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Thu, 18 Aug 2005 21:05:45 +0200
Subject: [Kolab-devel] development questions
In-Reply-To: <200508161533.40744.miguel@rozsas.xx.nom.br>
References: <200508161533.40744.miguel@rozsas.xx.nom.br>
Message-ID: <200508182105.45474.bernhard.reiter@intevation.de>

Hi Miguel,

Am Dienstag, 16. August 2005 20:33 schrieb Miguel Angelo Rozsas:
> I am considering to use Kolab as a framework to develop new modules that
> have a high degree of integration with the data stored from calendars,
> address book, etc.
>
> I am exploring the idea to use kolab + additional modules to act as a
> customized backoffice application.
>
> Could you provide me with introductory information to handle with this task
> ? What is, in your opinion, the major difficulty I will face on ?

To think within the Kolab design idea: 
No database, but smart clients.

> What is the best developer's profile to work on kolab ? C/C++ or LAMP
> (Linux, Apache, MySQL, P-language)

It depends on which part of Kolab you want to work on.
The KDE client or the server and then which part of the server.

> Which is the main development language for kolab ? 

The KDE Kolab client is written mainly in C++.
The Server glue code is in perl and the web administration interface in php.

> There is support for 
> arbitrary languages other the main one ?

Any language that can implement an imap client is well suited
in the Kolab world. We have done quite a few test scripts in python
to give you an example. 

> Do you know if there is a support for plugable module or whatever ?

Both the KDE client and the server are extensible.
For the server this usually means to run a daemon Kolab client.

> Do you know if there is a template system to render HTML pages, like Smarty
> PHP template engine ?

The web admin uses Smarty and pear in particular, but mostly
only implements an ldap client. There are other parts in php,
like the kolabfilter. It depends on what you want to do, if this is the right 
place for your funcationality.

> Do you know if there is a abstraction layer for data access like PEARDB ?

Yes, like disconnected IMAP, LDAP and the Kolab XML Storage format.

> There is support for internationalization (foreign languages other than
> English in the GUI) ?

Yes, currently we have Dutch, German, English and French in the web admin gui.
The KDE client is available in about 30 languages, with another 30 partly 
supported.

> Is the API fully documented ?

Yes, but see the first answer. This might not be the API to a database
solution you might expect.

> There is a starter kit for lazy developers ;-) ? Serious, I mean a kind of
> tutorial for development in kolab ?

No, not yet.
The best idea is to get a Kolab Server and a Kolab Client and 
start exploring the thing.

Bernhard



From bernhard.reiter at intevation.de  Thu Aug 18 21:07:05 2005
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Thu, 18 Aug 2005 21:07:05 +0200
Subject: [Kolab-devel] idletimeout in slapd.conf
In-Reply-To: <20050816214652.GO3961@conectiva.com.br>
References: <20050816214652.GO3961@conectiva.com.br>
Message-ID: <200508182107.05853.bernhard.reiter@intevation.de>

Am Dienstag, 16. August 2005 23:46 schrieb Andreas Hasenack:
> I'm having a problem related to the low idletimeout set in slapd.conf
> (openldap).
>
> Actually, the problem lies at the client (apache's mod_auth_ldap
> module), but I discovered it due to the idletimeout.
>
> By default, the apache module is using persistent connections. It
> doesn't, however, deal gracefully when the connection is dropped by the
> server, either when idletimeout is hit or the ldap server is just
> restarted.
>
> Increasing the idletimeout makes this better, but is no fix. Adding
> "LDAP_Persistent_G off" to the apache conf fixes it at the expense of an
> increased load on the ldap server.
>
> So, I was just wondering if somebody else saw this ;)
> I guess I'll try to patch the apache module to behave better.

I haven't seen it so far.
What are the symtoms I would see, if I hit that issue?
If you believe this is going to be a general issue, 
you could file a bug report.



From bernhard.reiter at intevation.de  Thu Aug 18 21:08:38 2005
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Thu, 18 Aug 2005 21:08:38 +0200
Subject: [Kolab-devel] Kolab imapd openpkg options
In-Reply-To: <20050817141119.2206A1D8F88@supertolla.itapac.net>
References: <20050817141119.2206A1D8F88@supertolla.itapac.net>
Message-ID: <200508182108.39087.bernhard.reiter@intevation.de>

Am Mittwoch, 17. August 2005 16:10 schrieb Fabio Pietrosanti:

> i'm in progress of setting up a customized kolab environment.
>
> I noticed that's not possible to compile kolab openpkg package with
> "--with libwrap" and "--with snmp" because in imapd.spec are manually
> cabled --without-libwrap and --without-snmp .

I do not know the reasons for them being diabled.
If this is an original openpkg version, I would ask there.

> If possible to add those from command line i would add tcpwrapper to
> kolab environment (which could be usefull for host blacklisting) and
> snmp for internal cyrus imap monitoring trough snmpdx.

You could at least try and see if this works.



From andreas at conectiva.com.br  Thu Aug 18 21:15:20 2005
From: andreas at conectiva.com.br (Andreas Hasenack)
Date: Thu, 18 Aug 2005 16:15:20 -0300
Subject: [Kolab-devel] idletimeout in slapd.conf
In-Reply-To: <200508182107.05853.bernhard.reiter@intevation.de>
References: <20050816214652.GO3961@conectiva.com.br>
	<200508182107.05853.bernhard.reiter@intevation.de>
Message-ID: <20050818191520.GK5403@conectiva.com.br>

On Thu, Aug 18, 2005 at 09:07:05PM +0200, Bernhard Reiter wrote:
> > Increasing the idletimeout makes this better, but is no fix. Adding
> > "LDAP_Persistent_G off" to the apache conf fixes it at the expense of an
> > increased load on the ldap server.
> >
> > So, I was just wondering if somebody else saw this ;)
> > I guess I'll try to patch the apache module to behave better.
> 
> I haven't seen it so far.
> What are the symtoms I would see, if I hit that issue?

The module falls back to anonymous login, so suddenly some things don't
work as expected anymore. I experienced many intermitent freebusy
failures until I figured this out.



From kolab-issues at intevation.de  Fri Aug 19 01:20:37 2005
From: kolab-issues at intevation.de (Michael Leupold)
Date: Thu, 18 Aug 2005 23:20:37 +0000
Subject: [Kolab-devel] [issue899] Kontact inline-attachment
Message-ID: <1124407237.35.0.939880113244.issue899@intevation.de>


New submission from Michael Leupold <leupold at leunet.de>:

The Kolab format specification mentions common fields named inline-attachment   
and link-attachment which don't seem to be implemented into the kde client yet.  
Toltec/Outlook doesn't support this correctly either, but they are going to  
implement it in 2.1 (Nov 2005).  
  
Is this a feature that's already being worked on for the KDE client?

----------
messages: 5313
nosy: lemma
priority: feature
status: unread
title: Kontact inline-attachment
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue899>
________________________________________________



From davlist2 at nextgentech.net  Fri Aug 19 09:09:24 2005
From: davlist2 at nextgentech.net (Davison Long)
Date: Fri, 19 Aug 2005 03:09:24 -0400
Subject: [Kolab-devel] Horde webclient folders
Message-ID: <20050819070919.D13B336EA6@mail.intevation.de>

Has anyone successfully got Horde IMP running with the ability to have IMP
auto-create the sent-mail and Draft folders?

I can't seem to get that working and it seems to be a namespace/folder
hierarchy issue in a nasty relationship between IMP and Cyrus.  Please tell
me that this is a problem that can be solved.  As it is right now no drafts
or sent items can be saved.

And of course this is with Kolab2 and the the CVS version of Horde checkout
out today.

I've messed around with the servers.php configuration file but to no avail
so far.

Any help would be greatly appreciated!

-Davison



From jan at horde.org  Fri Aug 19 09:35:09 2005
From: jan at horde.org (Jan Schneider)
Date: Fri, 19 Aug 2005 09:35:09 +0200
Subject: [Kolab-devel] Horde webclient folders
In-Reply-To: <20050819070919.D13B336EA6@mail.intevation.de>
References: <20050819070919.D13B336EA6@mail.intevation.de>
Message-ID: <20050819093509.7jpek1bq8go8w8gw@jan.dip.ammma.net>

Zitat von Davison Long <davlist2 at nextgentech.net>:

> Has anyone successfully got Horde IMP running with the ability to have IMP
> auto-create the sent-mail and Draft folders?
>
> I can't seem to get that working and it seems to be a namespace/folder
> hierarchy issue in a nasty relationship between IMP and Cyrus.  Please tell
> me that this is a problem that can be solved.  As it is right now no drafts
> or sent items can be saved.

Namespace support in IMP is currently being rewritten and unstable.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/



From mirroradmin at etf.bg.ac.yu  Fri Aug 19 14:12:57 2005
From: mirroradmin at etf.bg.ac.yu (Marko Uskokovic)
Date: Fri, 19 Aug 2005 14:12:57 +0200
Subject: [Kolab-devel] mirroring kolab
Message-ID: <4305CCC9.1090100@etf.bg.ac.yu>

Hello,
We would like to mirror kolab on mirror.etf.bg.ac.yu and 
mirror2.etf.bg.ac.yu
Please send us needed info and rsync parameters.



Marko Uskokovic
System Administrator
email: uskokovic at etf.bg.ac.yu

University of Belgrade
School of Electrical Engineering's Computer Centre
Bulevar Kralja Aleksandra 73, 11020 Belgrade, Serbia
tel: +381 11 3370110



From davlist2 at nextgentech.net  Fri Aug 19 19:06:38 2005
From: davlist2 at nextgentech.net (Davison Long)
Date: Fri, 19 Aug 2005 13:06:38 -0400
Subject: [Kolab-devel] Horde webclient folders
In-Reply-To: <20050819135850.4A2611D8F40@supertolla.itapac.net>
Message-ID: <20050819170653.05DFD36CDC@mail.intevation.de>

The problem is that when I log in to Horde with a Kolab user I don't have
the sent-mail or Drafts folder.

If I try to send mail then it gives the following error:
The folder "sent-mail" was not created. This is what the server said:
Permission denied
Message sent successfully, but not saved to sent-mail

If I try to save a draft I get the same error:
The folder "drafts" was not created. This is what the server said:
Permission denied
There was an error saving this message as a draft.

I even tried going in and creating the folders myself, and it would let me
create subfolders of the INBOX, but IMP would not recognize the folders I
created when it tried to save sent mail or drafts.  The same errors as above
would show up.

Thanks,
Davison

-----Original Message-----
From: Fabio Pietrosanti [mailto:lists at pietrosanti.it] 
Sent: Friday, August 19, 2005 9:58 AM
To: davlist2 at nextgentech.net
Subject: Re: [Kolab-devel] Horde webclient folders

Dear Davison,

exactly what's the problem you found?

Davison Long ha scritto:

>Has anyone successfully got Horde IMP running with the ability to have 
>IMP auto-create the sent-mail and Draft folders?
>
>I can't seem to get that working and it seems to be a namespace/folder 
>hierarchy issue in a nasty relationship between IMP and Cyrus.  Please 
>tell me that this is a problem that can be solved.  As it is right now 
>no drafts or sent items can be saved.
>
>And of course this is with Kolab2 and the the CVS version of Horde 
>checkout out today.
>
>I've messed around with the servers.php configuration file but to no 
>avail so far.
>
>Any help would be greatly appreciated!
>
>-Davison
>
>_______________________________________________
>Kolab-devel mailing list
>Kolab-devel at kolab.org
>https://kolab.org/mailman/listinfo/kolab-devel
>  
>





From kolab-issues at intevation.de  Fri Aug 19 19:37:46 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Fri, 19 Aug 2005 17:37:46 +0000
Subject: [Kolab-devel] [issue900] appointment deletion/chancel not
	registered correctly
Message-ID: <1124473066.86.0.908871740914.issue900@intevation.de>


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

Testing with svn 444225: 
 
Invite user B via email. 
User B accepts and the appointment is registered in his calendar. 
 
Now delete the event and send the chancelation email. 
User hits: the button in the email to delete the email from his 
calendar. The email is gone, but the appointment stays!

----------
assignedto: till
messages: 5325
nosy: bernhard, bh, david, till
priority: urgent
status: unread
title: appointment deletion/chancel not registered correctly
topic: kde client, kksa
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue900>
________________________________________________



From lists at pietrosanti.it  Sat Aug 20 03:14:04 2005
From: lists at pietrosanti.it (Fabio Pietrosanti)
Date: Sat, 20 Aug 2005 03:14:04 +0200
Subject: [Kolab-devel] Kolab 2.1 - same common name bug
Message-ID: <20050820011433.9E83E1D8F43@supertolla.itapac.net>

I setup kolab 2.1 with 2 domains.

I was trying to create two users with the same userid,name,surname but
each one on a different domain.

The userid is: prova1 @ domain1
The name: prova1
The surname: prova1

When i attempt to create this user:
The userid is: prova1 @ domain2
The name: prova1
The surname: prova1

i get the following error from web interface and it doesn't create the user.
LDAP Error: could not add object cn=prova1
prova1,dc=my,dc=domain,dc=com: Already exists

Notice that if attempt to create this user (which have a different first
name)
The userid is: prova1 @ domain2
The name: thisisanewfirstname
The surname: prova1

this work!
So it seems that cannot coexist two name and surname even if on
different domains.

Fabio



From lists at pietrosanti.it  Sat Aug 20 03:38:54 2005
From: lists at pietrosanti.it (Fabio Pietrosanti)
Date: Sat, 20 Aug 2005 03:38:54 +0200
Subject: [Kolab-devel] Kolab 2.1 - minor problem with postfix permission and
	logging
Message-ID: <20050820013923.2849D1D8F66@supertolla.itapac.net>

After a few i started getting those error in the log:

==> postfix/log/postfix.log <==
Aug 20 03:36:23 dns-gw <warning> postfix/postfix-script[4914]: warning:
not owned by root: /kolab/etc/postfix/ldapdistlist.cf.old
Aug 20 03:36:23 dns-gw <warning> postfix/postfix-script[4915]: warning:
not owned by root: /kolab/etc/postfix/ldaptransport.cf.old
Aug 20 03:36:23 dns-gw <warning> postfix/postfix-script[4916]: warning:
not owned by root: /kolab/etc/postfix/ldapvirtual.cf.old
Aug 20 03:36:24 dns-gw <warning> postfix/postfix-script[4917]: warning:
not owned by root: /kolab/etc/postfix/main.cf.old
Aug 20 03:36:24 dns-gw <warning> postfix/postfix-script[4918]: warning:
not owned by root: /kolab/etc/postfix/master.cf.old
Aug 20 03:36:24 dns-gw <warning> postfix/postfix-script[4919]: warning:
not owned by root: /kolab/etc/postfix/transport.old
Aug 20 03:36:24 dns-gw <warning> postfix/postfix-script[4920]: warning:
not owned by root: /kolab/etc/postfix/virtual.old
Aug 20 03:36:24 dns-gw <info>

Notice that i never created .old by hand and that those are kolab owned
created by something in kolab:

dns-gw:/kolab/var# ls -la /kolab/etc/postfix/virtual.old
-rw-------  1 kolab kolab 409 2005-08-20 03:29
/kolab/etc/postfix/virtual.old



From kolab-issues at intevation.de  Mon Aug 22 10:38:29 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Mon, 22 Aug 2005 08:38:29 +0000
Subject: [Kolab-devel] [issue901] reconstruct in Admin.pm or imapd calls
	wrong binaries
Message-ID: <1124699909.01.0.703346231705.issue901@intevation.de>


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

Kolab Server 2.0.1rc1:       
       
Somehow imapd wants to call      
 /kolab/bin/reconstruct' and '/kolab/bin/quota'     
during a reconstruct and cannot find them,    
because they are called:  cyrquota and  cyrreconstruct  
in openpkg.  
 
The right solution would be to enhance the openpkg patch 
to make imapd call the right binaries. 
(A kludge is to make symlinks to the old names.) 
 
While we are at it, why is reconstruct in Admin.pm's POD not mentioned?=

----------
assignedto: steffen
messages: 5345
nosy: bernhard, bh, steffen
priority: bug
status: unread
title: reconstruct in Admin.pm or imapd calls wrong binaries
topic: kkc, server
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue901>
________________________________________________



From bernhard.reiter at intevation.de  Mon Aug 22 11:21:22 2005
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Mon, 22 Aug 2005 11:21:22 +0200
Subject: [Kolab-devel] mirroring kolab
In-Reply-To: <4305CCC9.1090100@etf.bg.ac.yu>
References: <4305CCC9.1090100@etf.bg.ac.yu>
Message-ID: <200508221121.23383.bernhard.reiter@intevation.de>

Am Freitag, 19. August 2005 14:12 schrieb Marko Uskokovic:
> We would like to mirror kolab on mirror.etf.bg.ac.yu and
> mirror2.etf.bg.ac.yu
> Please send us needed info and rsync parameters.

Hi Marko,

you have probably found http://www.kolab.org/mirrors.html
  You need to be able to use rsync with the options to preserve soft links. 
  
This means your webserver must honor the soft links, too.

In addition check out: http://ftp.belnet.be/packages/kolab/RSYNC.txt

Best,
Bernhard





From bernhard.reiter at intevation.de  Mon Aug 22 11:23:03 2005
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Mon, 22 Aug 2005 11:23:03 +0200
Subject: [Kolab-devel] Kolab 2.1 - same common name bug
In-Reply-To: <20050820011433.9E83E1D8F43@supertolla.itapac.net>
References: <20050820011433.9E83E1D8F43@supertolla.itapac.net>
Message-ID: <200508221123.04211.bernhard.reiter@intevation.de>

Hi Fabio,
can you file an issue for this one?
I guess this is related to our attempt to keep Kolab server 2.1's ldap 
structure compatible with 2.0.

Bernhard

Am Samstag, 20. August 2005 03:14 schrieb Fabio Pietrosanti:
> I setup kolab 2.1 with 2 domains.
>
> I was trying to create two users with the same userid,name,surname but
> each one on a different domain.
>
> The userid is: prova1 @ domain1
> The name: prova1
> The surname: prova1
>
> When i attempt to create this user:
> The userid is: prova1 @ domain2
> The name: prova1
> The surname: prova1
>
> i get the following error from web interface and it doesn't create the
> user. LDAP Error: could not add object cn=prova1
> prova1,dc=my,dc=domain,dc=com: Already exists
>
> Notice that if attempt to create this user (which have a different first
> name)
> The userid is: prova1 @ domain2
> The name: thisisanewfirstname
> The surname: prova1
>
> this work!
> So it seems that cannot coexist two name and surname even if on
> different domains.
>
> Fabio
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel



From bernhard.reiter at intevation.de  Mon Aug 22 11:23:54 2005
From: bernhard.reiter at intevation.de (Bernhard Reiter)
Date: Mon, 22 Aug 2005 11:23:54 +0200
Subject: [Kolab-devel] Kolab 2.1 - minor problem with postfix permission
	and logging
In-Reply-To: <20050820013923.2849D1D8F66@supertolla.itapac.net>
References: <20050820013923.2849D1D8F66@supertolla.itapac.net>
Message-ID: <200508221123.54524.bernhard.reiter@intevation.de>

Am Samstag, 20. August 2005 03:38 schrieb Fabio Pietrosanti:
> After a few i started getting those error in the log:
>
> ==> postfix/log/postfix.log <==
> Aug 20 03:36:23 dns-gw <warning> postfix/postfix-script[4914]: warning:
> not owned by root: /kolab/etc/postfix/ldapdistlist.cf.old

You can ignore those.

> Aug 20 03:36:23 dns-gw <warning> postfix/postfix-script[4915]: warning:
> not owned by root: /kolab/etc/postfix/ldaptransport.cf.old
> Aug 20 03:36:23 dns-gw <warning> postfix/postfix-script[4916]: warning:
> not owned by root: /kolab/etc/postfix/ldapvirtual.cf.old
> Aug 20 03:36:24 dns-gw <warning> postfix/postfix-script[4917]: warning:
> not owned by root: /kolab/etc/postfix/main.cf.old
> Aug 20 03:36:24 dns-gw <warning> postfix/postfix-script[4918]: warning:
> not owned by root: /kolab/etc/postfix/master.cf.old
> Aug 20 03:36:24 dns-gw <warning> postfix/postfix-script[4919]: warning:
> not owned by root: /kolab/etc/postfix/transport.old
> Aug 20 03:36:24 dns-gw <warning> postfix/postfix-script[4920]: warning:
> not owned by root: /kolab/etc/postfix/virtual.old
> Aug 20 03:36:24 dns-gw <info>
>
> Notice that i never created .old by hand and that those are kolab owned
> created by something in kolab:
>
> dns-gw:/kolab/var# ls -la /kolab/etc/postfix/virtual.old
> -rw-------  1 kolab kolab 409 2005-08-20 03:29
> /kolab/etc/postfix/virtual.old

Probably kolabconf created them as automaticall called by kolabd
when the ldap changed.



From kolab-issues at intevation.de  Mon Aug 22 12:20:01 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Mon, 22 Aug 2005 10:20:01 +0000
Subject: [Kolab-devel] [issue902] charset problems with on demand imap
	loading
Message-ID: <1124706001.43.0.208147491236.issue902@intevation.de>


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

Revision: 451934 
 
Till, 
can you change the default for a fresh online imap resource 
to have loading attachment on default disabled? 
This avoid some of the charset bugs when displaying such emails.

----------
assignedto: till
messages: 5355
nosy: bernhard, bh, till
priority: minor bug
status: unread
title: charset problems with on demand imap loading
topic: kde client, kksa
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue902>
________________________________________________



From kolab-issues at intevation.de  Mon Aug 22 13:13:35 2005
From: kolab-issues at intevation.de (Fabio Pietrosanti)
Date: Mon, 22 Aug 2005 11:13:35 +0000
Subject: [Kolab-devel] [issue903] Kolab 2.1 - same common name bug
Message-ID: <1124709215.65.0.0807365466548.issue903@intevation.de>


New submission from Fabio Pietrosanti <fabio at pietrosanti.it>:

> I setup kolab 2.1 with 2 domains.
>
> I was trying to create two users with the same userid,name,surname but
> each one on a different domain.
>
> The userid is: prova1 @ domain1
> The name: prova1
> The surname: prova1
>
> When i attempt to create this user:
> The userid is: prova1 @ domain2
> The name: prova1
> The surname: prova1
>
> i get the following error from web interface and it doesn't create the
> user. LDAP Error: could not add object cn=prova1
> prova1,dc=my,dc=domain,dc=com: Already exists
>
> Notice that if attempt to create this user (which have a different first
> name)
> The userid is: prova1 @ domain2
> The name: thisisanewfirstname
> The surname: prova1
>
> this work!
> So it seems that cannot coexist two name and surname even if on
> different domains.
>
> Fabio

----------
messages: 5356
nosy: fpietrosanti
priority: bug
status: unread
title: Kolab 2.1 - same common name bug
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue903>
________________________________________________



From kolab-issues at intevation.de  Mon Aug 22 17:04:19 2005
From: kolab-issues at intevation.de (Guillaume)
Date: Mon, 22 Aug 2005 15:04:19 +0000
Subject: [Kolab-devel] [issue904] PHP iconv support missing ?
Message-ID: <1124723059.72.0.508099081993.issue904@intevation.de>


New submission from Guillaume <guillaume at opensides.be>:

Iconv support missing?    
Because the install of gosa fails on verification of iconv with binary 
packages( 2.0)

----------
messages: 5357
nosy: guiguidoc
priority: minor bug
status: unread
title: PHP iconv support missing ?
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue904>
________________________________________________



From lists at pietrosanti.it  Mon Aug 22 17:31:39 2005
From: lists at pietrosanti.it (Fabio Pietrosanti)
Date: Mon, 22 Aug 2005 17:31:39 +0200
Subject: [Kolab-devel] Problem in Horde password changing on Kolab 2.1
	multidomain
Message-ID: <20050822153211.8AEBB1D8F81@supertolla.itapac.net>

Changing passwords trough Horde passwd module of multidomain of a kolab
installation (kolab 2.1) doesn't work.

Sometimes the passwd module say:
 Failure in changing password on Local Kolab Server: User not found.

Sometimes say:
 Failure in changing password on Local Kolab Server: Wrong Password

Have tried with several different configuration and found that on
"primary domain" (the one specified in kolab maildomain in conf.php of
horde) password changing works fine, but on additional domains it
doesn't work.

Fabio



From lists at pietrosanti.it  Mon Aug 22 18:09:05 2005
From: lists at pietrosanti.it (Fabio Pietrosanti)
Date: Mon, 22 Aug 2005 18:09:05 +0200
Subject: [Kolab-devel] Kolab 2.1: Error from imap server "SQUA failed to
	open index file"
Message-ID: <20050822160940.1B5131D8F83@supertolla.itapac.net>

When i create a new contacts with latest Turba modules of Horde i get
the following error from Cyrus IMAP in the log files:

Aug 22 17:45:09 test-srv  <debug> imap[17903]: open: user
user1 at my.domain.com opened INBOX/Contacts
Aug 22 17:45:09 test-srv  <debug> imap[17903]: SQUAT failed to open
index file
Aug 22 17:45:09 test-srv  <debug> imap[17903]: SQUAT failed

The contacts was created correctly, however i found this errors in the
log files of imapd.



From kolab-issues at intevation.de  Mon Aug 22 19:57:48 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Mon, 22 Aug 2005 17:57:48 +0000
Subject: [Kolab-devel] [issue905] Email read after filtering!
Message-ID: <1124733468.82.0.364718061597.issue905@intevation.de>


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

KDE client rev 451917:   
   
I am using filter to move emails from some mailinglists to  
a few subfolders.     
  
inbox -> a -> subfolder  
  
With the new revision, after a sync the email will be marked read. 
First I can see the new email, but then another part of the process 
markes it all read. :(

----------
assignedto: till
messages: 5358
nosy: bernhard, bh, david, till
priority: urgent
status: unread
title: Email read after filtering!
topic: kde client, kksa
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue905>
________________________________________________



From matt at fruitsalad.org  Tue Aug 23 08:37:28 2005
From: matt at fruitsalad.org (Matt Douhan)
Date: Tue, 23 Aug 2005 08:37:28 +0200
Subject: [Kolab-devel] Kolab 2.1: Error from imap server "SQUA failed to
	open index file"
In-Reply-To: <20050822160940.1B5131D8F83@supertolla.itapac.net>
References: <20050822160940.1B5131D8F83@supertolla.itapac.net>
Message-ID: <200508230837.28978.matt@fruitsalad.org>

On Monday 22 August 2005 18.09, Fabio Pietrosanti wrote:
> When i create a new contacts with latest Turba modules of Horde i get
> the following error from Cyrus IMAP in the log files:
>
> Aug 22 17:45:09 test-srv  <debug> imap[17903]: open: user
> user1 at my.domain.com opened INBOX/Contacts
> Aug 22 17:45:09 test-srv  <debug> imap[17903]: SQUAT failed to open
> index file
> Aug 22 17:45:09 test-srv  <debug> imap[17903]: SQUAT failed
>
> The contacts was created correctly, however i found this errors in the
> log files of imapd.


It simply means that the foler is not indexed, and the logging is turned on at 
debug level, I have long sicne changed the logging to be at info level it is 
just to much noice otherwise on really busy servers.

you may also want to run squatter -s every night to handle your indexing, nut 
note i do NOT recommend this, it may not be good for your environment so you 
need to test it on testsystems first.

-- 
Matt Douhan
www.fruitsalad.org



From kolab-issues at intevation.de  Tue Aug 23 19:28:43 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Tue, 23 Aug 2005 17:28:43 +0000
Subject: [Kolab-devel] [issue906] Have display names in imap annotations for
	international folders
Message-ID: <1124818123.08.0.999528704149.issue906@intevation.de>


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

This is a feature proposed by Martin  
to solve the problem of folder names in an international setting.  
 
In msg4783 he proposes to have another imap annotation  
to give display names for the folders in other languages. 
This issues is to document and discuss this feature proposal. 
 
Some minor drawbacks:  
(1) the one with rights to write  
must be able to create all folder translations. 
(2) for standard folder names, some space might be wasted.

----------
assignedto: martin
messages: 5377
nosy: bernhard, david, martin, steffen, till
priority: feature
status: unread
title: Have display names in imap annotations for international folders
topic: concept
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue906>
________________________________________________



From kolab-issues at intevation.de  Wed Aug 24 11:03:11 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 24 Aug 2005 09:03:11 +0000
Subject: [Kolab-devel] [issue907] event registered very late
Message-ID: <1124874191.18.0.534050315616.issue907@intevation.de>


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

The KDE client         
ix86-suse91p/kolab2.0-kdepim3.3-aegypten2.0-client-1.0.6/          
(which is KDE client 2.0.1).       
       
A user report that invitations are not registered directly.      
Setup up user I has given user R  read rights on his       
default calendar. Now he makes an appointment with I and R      
as attendees, sends to invitation to R and syncs.      
      
R syncs.   
Then R recieves the emails and presses: accept!   
R is not asked where to save the appointment,   
only after restart or after a few longer while,    
this happens.   
    
I  have a personal debugging log, showing the  
 Emitting DCOP signal incidenceAdded 
comming very late. 
So far I could not reproduce it here. 
 
I am sending the debugging output to Till and David personally.

----------
assignedto: till
messages: 5383
nosy: bernhard, david, till
priority: critical
status: unread
title: event registered very late
topic: kde client, kksa
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue907>
________________________________________________



From kolab-issues at intevation.de  Wed Aug 24 17:34:30 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 24 Aug 2005 15:34:30 +0000
Subject: [Kolab-devel] [issue908] fb trigger should be default for new
	kolab2 XML account
Message-ID: <1124897670.32.0.0715388345936.issue908@intevation.de>


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

Toltec 2.0.5:   
When setting up a new account for a Kolab2 XML storage,   
the fb creation button is disabled by default.  
 
It should be enabled by default to save to extra step for users.

----------
assignedto: joonradley
messages: 5388
nosy: bernhard, joonradley
priority: minor bug
status: unread
title: fb trigger should be default for new kolab2 XML account
topic: toltec
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue908>
________________________________________________



From kolab-issues at intevation.de  Wed Aug 24 18:19:27 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Wed, 24 Aug 2005 16:19:27 +0000
Subject: [Kolab-devel] [issue909] Decoding msg822 attachments uncorrectly.
Message-ID: <1124900367.28.0.831213990132.issue909@intevation.de>


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

Toltec 2.0.5-de:    
    
Emails with rfc822 attachments are not displayed correctly.   
  
How to reproduce with Outlook and a Kolab 2 Server:  
  
Write two simple emails to yourself.  
Activate Email delivery on another account so that  
emails will go to a folder and Toltec will sync them up,  
not pop3.  
  
Now select both emails and forward them to the other account  
and yourself.  
Sync the folder they are in and they you can see  
that the emails are not displayed correctly  
and cannot be directly opened as emails.  
  
I am attaching such an email from the server.

----------
assignedto: joonradley
files: 106.zip
messages: 5391
nosy: bernhard, joonradley
priority: bug
status: unread
title: Decoding msg822 attachments uncorrectly.
topic: toltec
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue909>
________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 106.zip
Type: application/zip
Size: 1493 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050824/c14ac767/attachment.zip>

From mirroradmin at etf.bg.ac.yu  Wed Aug 24 20:38:02 2005
From: mirroradmin at etf.bg.ac.yu (Marko Uskokovic)
Date: Wed, 24 Aug 2005 20:38:02 +0200
Subject: [Kolab-devel] mirroring kolab
In-Reply-To: <200508221121.23383.bernhard.reiter@intevation.de>
References: <4305CCC9.1090100@etf.bg.ac.yu>
	<200508221121.23383.bernhard.reiter@intevation.de>
Message-ID: <430CBE8A.1000303@etf.bg.ac.yu>

Mirrors are ready:
http://mirror.etf.bg.ac.yu/kolab/
ftp://mirror.etf.bg.ac.yu/kolab/

Daily update...
Please add us to the list on http://www.kolab.org/mirrors.html
Best regards,

Marko Uskokovic
System Administrator
email: uskokovic at etf.bg.ac.yu

University of Belgrade
School of Electrical Engineering's Computing Centre
Bulevar Kralja Aleksandra 73, 11020 Belgrade, Serbia
tel: +381 11 3370110
http://rc.etf.bg.ac.yu



Bernhard Reiter wrote:
>Am Freitag, 19. August 2005 14:12 schrieb Marko Uskokovic:
>  
>>We would like to mirror kolab on mirror.etf.bg.ac.yu and
>>mirror2.etf.bg.ac.yu
>>Please send us needed info and rsync parameters.
>>    
>
>Hi Marko,
>
>you have probably found http://www.kolab.org/mirrors.html
>  You need to be able to use rsync with the options to preserve soft links. 
>  
>This means your webserver must honor the soft links, too.
>
>In addition check out: http://ftp.belnet.be/packages/kolab/RSYNC.txt
>
>Best,
>Bernhard
>
>
>
>  



From lists at subvs.co.uk  Thu Aug 25 18:00:20 2005
From: lists at subvs.co.uk (Hamish)
Date: Thu, 25 Aug 2005 17:00:20 +0100
Subject: [Kolab-devel] Windows Clients
Message-ID: <200508251700.32765.lists@subvs.co.uk>

Hi all
A question that gets asked often I know, but does anyone know the state of any 
"native" windows clients? It seems aethera still only suppports kolab1 and I 
have seen nothing of the kontact windows port. Can anyone shed any light?
Thanks,
Hamish
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050825/60226657/attachment.sig>

From matt at fruitsalad.org  Fri Aug 26 09:57:32 2005
From: matt at fruitsalad.org (Matt Douhan)
Date: Fri, 26 Aug 2005 09:57:32 +0200
Subject: [Kolab-devel] Windows Clients
In-Reply-To: <200508251700.32765.lists@subvs.co.uk>
References: <200508251700.32765.lists@subvs.co.uk>
Message-ID: <200508260957.32954.matt@fruitsalad.org>

On Thursday 25 August 2005 18:00, Hamish wrote:
> Hi all
> A question that gets asked often I know, but does anyone know the state of
> any "native" windows clients? It seems aethera still only suppports kolab1
> and I have seen nothing of the kontact windows port. Can anyone shed any
> light? Thanks,
> Hamish

It does not get more native than OutLook does it?

rgds

Matt

-- 
Matt Douhan
www.fruitsalad.org



From kolab-issues at intevation.de  Fri Aug 26 12:04:47 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Fri, 26 Aug 2005 10:04:47 +0000
Subject: [Kolab-devel] [issue910] Improve pfb creation time
Message-ID: <1125050687.08.0.655228035833.issue910@intevation.de>


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

We shall further improve the creation time of pfbs,        
as a section calendar that several people actively work        
with and has 3000 calendars with Toltec can put a server under load       
because of many triggers links coming.       
        
In issue793 proposes an algorithm that promisses another improvement.       
       
Another possible improvement would be to wait a few minutes      
before creating the pfb and see if addition request come in      
and to ignore those, thus putting a limit on how many pfb creations      
are done per time interval.      
    
This might also be related to issue893 because Toltec 2.0.5  
always uses a  application/x-outlook-tnef attachment now. 
I cannot say how much that adds to the load.

----------
assignedto: steffen
messages: 5392
nosy: bernhard, bh, martin, steffen
priority: bug
status: unread
title: Improve pfb creation time
topic: server
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue910>
________________________________________________



From kolab-issues at intevation.de  Fri Aug 26 13:15:35 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Fri, 26 Aug 2005 11:15:35 +0000
Subject: [Kolab-devel] [issue911] overview configuration usuability problem
	with Kmail's email
Message-ID: <1125054935.9.0.61181617936.issue911@intevation.de>


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

If you go to        
Settings -> Configure Contact... -> Mail -> Mail Summary        
Headline: "Mail Summary Setup".        
      
there is a usability problem with it,      
as people think this will configure the email overview      
within the email (kmail) view.       
And then they are dissappointed that this does not work.      
      
If this setting is only for Kontact's overview page,      
it would be best if this would appear below the      
"overview" entry in the configuration tree.      
      
A step in the right direction would to rename      
the configuration entry under Mail to     
"for Kontact's overview page"    
  
I have created http://bugs.kde.org/show_bug.cgi?id=111551 
for it.

----------
assignedto: till
messages: 5395
nosy: bernhard, david, till
priority: minor bug
status: unread
title: overview configuration usuability problem with Kmail's email
topic: kde client, kkc
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue911>
________________________________________________



From lists at subvs.co.uk  Fri Aug 26 15:35:43 2005
From: lists at subvs.co.uk (Hamish)
Date: Fri, 26 Aug 2005 14:35:43 +0100
Subject: [Kolab-devel] Windows Clients
In-Reply-To: <200508260957.32954.matt@fruitsalad.org>
References: <200508251700.32765.lists@subvs.co.uk>
	<200508260957.32954.matt@fruitsalad.org>
Message-ID: <200508261435.53899.lists@subvs.co.uk>

On Friday 26 August 2005 08:57, Matt Douhan wrote:
> On Thursday 25 August 2005 18:00, Hamish wrote:
> > Hi all
> > A question that gets asked often I know, but does anyone know the state
> > of any "native" windows clients? It seems aethera still only suppports
> > kolab1 and I have seen nothing of the kontact windows port. Can anyone
> > shed any light? Thanks,
> > Hamish
>
> It does not get more native than OutLook does it?
>
> rgds
>
> Matt
Let me rephrase - a native windows client that does not need the a plugin to 
work. (And is not Outlook). Outlook + toltec plugin works out quite expensive 
for smaller companies. To be fair, the toltec plugin is cheap, Outlook price 
can be a show stopper though.
Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050826/cb3dbbc2/attachment.sig>

From lists at subvs.co.uk  Fri Aug 26 15:38:06 2005
From: lists at subvs.co.uk (Hamish)
Date: Fri, 26 Aug 2005 14:38:06 +0100
Subject: [Kolab-devel] Error when modifying user
In-Reply-To: <4241B069.1050304@frapr.ath.cx>
References: <4241AD19.1090302@frapr.ath.cx>
	<1111601132.1784.10.camel@localhost>
	<4241B069.1050304@frapr.ath.cx>
Message-ID: <200508261438.06846.lists@subvs.co.uk>

On Wednesday 23 March 2005 18:07, Philip Rigden wrote:
> Thanks, Z.
>
> Yes I am using Horde. That would explain it. I can add a new user,
> however, which is odd. Is there a workaround for this?
>
> Phil
>
> Zachariah Mully wrote:
> >On Wed, 2005-03-23 at 18:53 +0100, Philip Rigden wrote:
> >>Hello all,
> >>
> >>I just set up a Kolab 2 server (beta 3) and set up a user for myself
> >>without problems.  Then, after copying my mails from my old Kolab
> >>server, I tried to modify my user and got the following error message:
> >>
> >>LDAP Error: Could not modify object cn=First
> >>Last,dc=mydomain,dc=ath,dc=cx: Object class violation
> >>
> >>What can I do to fix this?
> >>
> >>Thanks,
> >>Phil
> >
> >Are you using the webclient (Horde) as well? The inclusion of
> >horde.schema breaks the management interface for reasons yet to be
> >determined.

Has anyone found a workaround for this yet?
Thanks,
Hamish
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050826/c3fcb92e/attachment.sig>

From kolab-issues at intevation.de  Fri Aug 26 15:37:07 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Fri, 26 Aug 2005 13:37:07 +0000
Subject: [Kolab-devel] [issue912] kmail lockfile not removed on SIGTERM,
	problem for moving workplaces
Message-ID: <1125063427.29.0.483256758446.issue912@intevation.de>


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

kmail and kontact do not remove   
 .kde/share/apps/kmail/lock 
when "kill"ed with regular SIGTERM. 
 
When a user now starts it from a different machine, 
this creates a problem because of the warning message 
which the user cannot resolve. 
 
There is a kde bug for this: 
http://bugs.kde.org/show_bug.cgi?id=109637   
I confirmed it.

----------
messages: 5396
nosy: bernhard
priority: minor bug
status: unread
title: kmail lockfile not removed on SIGTERM, problem for moving workplaces
topic: kde client
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue912>
________________________________________________



From matt at fruitsalad.org  Fri Aug 26 17:21:22 2005
From: matt at fruitsalad.org (Matt Douhan)
Date: Fri, 26 Aug 2005 17:21:22 +0200
Subject: [Kolab-devel] Error when modifying user
In-Reply-To: <200508261438.06846.lists@subvs.co.uk>
References: <4241AD19.1090302@frapr.ath.cx> <4241B069.1050304@frapr.ath.cx>
	<200508261438.06846.lists@subvs.co.uk>
Message-ID: <200508261721.22786.matt@fruitsalad.org>

On Friday 26 August 2005 15:38, Hamish wrote:
> > >Are you using the webclient (Horde) as well? The inclusion of
> > >horde.schema breaks the management interface for reasons yet to be
> > >determined.
>
> Has anyone found a workaround for this yet?

Yes Aaron Seigop posted a working patch on kolab-devel@ a while ago you shold 
be able to find it in the archives.

rgds

Matt

-- 
Matt Douhan
www.fruitsalad.org



From kolab-issues at intevation.de  Mon Aug 29 16:25:22 2005
From: kolab-issues at intevation.de (Marco Weber)
Date: Mon, 29 Aug 2005 14:25:22 +0000
Subject: [Kolab-devel] [issue914] calendar: recurrent event exception
	forgets it's start and end time
Message-ID: <1125325522.18.0.604197411238.issue914@intevation.de>


New submission from Marco Weber <mw at cabag.ch>:

I've catched this bug on a little flash video...

http://jukan.ch/kolab2/kolab2_recurrent_exception_bug.html

in words:
A recurrent event get's an exception. This exception event forgets about it's
start and end time (even about it's date) as soon as kontact is closed.
After restarting kontact, moving the exception event does work as expected in
the first place.

Thanks for getting rid of this lil'bugger!

----------
messages: 5405
nosy: mweber
priority: bug
status: unread
title: calendar: recurrent event exception forgets it's start and end time
topic: kde client, server
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue914>
________________________________________________



From kolab-issues at intevation.de  Mon Aug 29 16:47:35 2005
From: kolab-issues at intevation.de (Bernhard Herzog)
Date: Mon, 29 Aug 2005 14:47:35 +0000
Subject: [Kolab-devel] [issue915] non-ascii not handled correctly in
	webadmin interface
Message-ID: <1125326855.27.0.962461586067.issue915@intevation.de>


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

The web admin interface doesn't handle non-ascii characters correctly.  E.g. set
the city attribute of a user to "Osnabr?ck".  The web-admin interface shows this
as "Osnabr??ck", i.e. the utf8 encoding interpreted as latin1.

----------
assignedto: steffen
messages: 5406
nosy: bh, steffen
priority: bug
status: unread
title: non-ascii not handled correctly in webadmin interface
topic: web admin
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue915>
________________________________________________



From suse-tux at gmx.de  Mon Aug 29 18:43:03 2005
From: suse-tux at gmx.de (Marcus =?UTF-8?B?SMO8d2U=?=)
Date: Mon, 29 Aug 2005 18:43:03 +0200
Subject: [Kolab-devel] kolabd new build mechanism
In-Reply-To: <200508182049.49701.bernhard.reiter@intevation.de>
References: <20050816160130.678ba409@linux.linux-network>
	<200508182049.49701.bernhard.reiter@intevation.de>
Message-ID: <20050829184303.17f7902a@linux.linux-network>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 18 Aug 2005 20:49:49 +0200
Bernhard Reiter <bernhard.reiter at intevation.de> wrote:

> Am Dienstag, 16. August 2005 16:01 schrieb Marcus aka }-Tux-{:
> 
> > Richard and I finished the with porting the kolabd module. It's free
> > configuralbe now and should work without any problems :)
> 
> Sounds good.
> 
> > Could someone with enough karma commit this to cvs, either to HEAD
> > or starting with a branch?
> 
> We need to wait for Steffen as Server maintainer on this one I guess.
> He will be back next week, but stuff might have piled up a bit.
> 
hmmm... what's up with Steffen?
Or is he too busy at the moment? ;(


Greets Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDEzsXv7TjYvlViHIRAjcDAJ97bvr+d3kH/Fk6uny4vyvbLhe7pQCZAcgd
onJwx0rWlEjt3/M3hjkdkhc=
=EJcw
-----END PGP SIGNATURE-----

From kolab-issues at intevation.de  Sun Aug 28 17:56:46 2005
From: kolab-issues at intevation.de (Roy Hoobler)
Date: Sun, 28 Aug 2005 15:56:46 +0000
Subject: [Kolab-devel] [issue913] admin interface changes
Message-ID: <1125244606.88.0.157572587647.issue913@intevation.de>


New submission from Roy Hoobler <roy at connectcomputing.com>:

Added "mobile" and "state/prov" fields to admin/users and admin/addrbook.  Added
field to separate cn from mailing list (on update).

Attached is a tar file with my changes and a "diff" file for each.

They go into the following directories:
Added "state" and "mobile phone" fields
/admin/users/user.php
/admin/addressbook/addr.php

separated cn and dist name fields for LDAP.
/admin/distributionlist/list.php

I did a a "diff" (without any options).  I hope that is okay for now.

Thanks,

Roy

----------
files: adminchanges.tar
messages: 5398
nosy: rhoobler
status: unread
title: admin interface changes
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue913>
________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: adminchanges.tar
Type: application/x-tar
Size: 61440 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050828/950b3833/attachment.tar>

From kolab-issues at intevation.de  Tue Aug 30 14:51:00 2005
From: kolab-issues at intevation.de (Bernhard Reiter)
Date: Tue, 30 Aug 2005 12:51:00 +0000
Subject: [Kolab-devel] [issue916] cannot news from overview/summary
Message-ID: <1125406260.24.0.519614046397.issue916@intevation.de>


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

KDE client post 2.0.1 Rev 451917 and earlier:  
  
cannot remove all news from the summary / overview page of Kontact.  
 
If I remove all new sources, I get dot.kde.org. 
When I am trying to remove dot.kde.org, it keeps coming back. 
 
Trying to switch of news in the Configure Kontact -> overview 
leads to have the button be unchecked, but the news are still shown.

----------
messages: 5425
nosy: bernhard, bh, danimo, david, till
priority: minor bug
status: unread
title: cannot news from overview/summary
topic: kde client
________________________________________________
Kolab issue tracker <kolab-issues at intevation.de>
<https://intevation.de/roundup/kolab/issue916>
________________________________________________



From martin.konold at erfrakon.de  Wed Aug 31 13:32:19 2005
From: martin.konold at erfrakon.de (Martin Konold)
Date: Wed, 31 Aug 2005 13:32:19 +0200
Subject: [Kolab-devel] [Kolab 2.1rc1] - Installation and state of the art
	(for me...)
In-Reply-To: <200508182044.46582.bernhard.reiter@intevation.de>
References: <4301BE2F.4070203@openix-services.com>
	<200508182044.46582.bernhard.reiter@intevation.de>
Message-ID: <200508311332.20005.martin.konold@erfrakon.de>

Am Donnerstag 18 August 2005 20:44 schrieb Bernhard Reiter:

Hi Sidoine,

> > But, I got trouble to make it work with Kontact. I created several users
> > with several way to identificate (e-mail login or plain text login) but
> > only the plain text login (ie: spierrel) accepted to identificate. And I
> > got trouble with the ca authority. I will try it again and send you as
> > many information as I can.
>
> This is helpful, especially if you describe your difficulties in more
> detail. Steffen will be back soon and then we will get a go at 2.1xx
> problems.

Any update here?

Regards,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker