valentin_nils | 1 Jun 2005 02:27

Re: Server 2.0-rc2 released/ advisory for rc1 and rc2

Hi Bernhard,

just a quick question (NOT MEANT to be INTRIGUING in anyway)

Wasnt 2.0 originally planned  to be released in October 2004 in the
schedules  or did I mistake that ?

Best regards

Nils Valentin
Tokyo / Japan
http://www.be-known-online.com

> Kolab-Server-2.0-rc2 is ready on the mirrors,
> but rc3 will follow shortly
> as we found a critical bug after releasing rc2.
> Still rc2 is interesting for some people.
> Carefully check the attached release-notes.
>
> Best,
> Bernhard
>
> _______________________________________________
> Kolab-users mailing list
> Kolab-users <at> kolab.org
> https://kolab.org/mailman/listinfo/kolab-users
>
Bernhard Reiter | 1 Jun 2005 09:43
Picon
Favicon

Re: Server 2.0-rc2 released/ advisory for rc1 and rc2

Hi Nils,

On Wednesday 01 June 2005 02:27, valentin_nils <at> be-known-online.com wrote:
> just a quick question (NOT MEANT to be INTRIGUING in anyway)
>
> Wasnt 2.0 originally planned  to be released in October 2004 in the
> schedules  or did I mistake that ?

the schedule for the Proko2 contract was end of 2004 and we kept it.
Kolab is running fine for our Proko2 customer(s). We have of course
fixed a couple of bugs and added some features for them since that.

The Proko2 contract was the main driving force behind Kolab2, but 
Kolab is a community project where the companies of Proko2 are a participating
among others. The rules to release software are different, 
because the product shall appeal to a wider public 
and thus according to good Free Software practice: 
It will be ready when it is ready. 
Kolab runs stable and for production in quite a few places now, 
but there are setups, where it leaves some things to be desired.
This is mainly what we try to address with the 
last server release candidates.

The speed on the project depends on how much people from the community 
are contributing.  This is healthy for a Free Software project.

	Bernhard

Attachment (smime.p7s): application/pkcs7-signature, 2145 bytes
(Continue reading)

Bernhard Reiter | 1 Jun 2005 09:47
Picon
Favicon

Re: Toltec connector and exceptions to recurring events

Hi Helge,

On Tuesday 31 May 2005 00:15, Helge Hess wrote:

> IMHO the uid/recurrence-id is quite important in the real world
> (and btw explicitly mentioned/supported in CalDAV). Maybe you can
> somehow workaround using the CalDAV approach (storing multiple
> vevents in memory under a single uid)?

my design approach would be to solve the problem in the client,
but that again needs a careful approach. In my view many recurrence
rules are quite complicated, so there will be a simpler solution.

[Probably topic for kolab-devel or kolab-format, depending on the focus
of implementation or design.]

Best,
  Bernhard
Attachment (smime.p7s): application/pkcs7-signature, 2145 bytes
_______________________________________________
Kolab-users mailing list
Kolab-users <at> kolab.org
https://kolab.org/mailman/listinfo/kolab-users
Bernhard Reiter | 1 Jun 2005 09:58
Picon
Favicon

Client-Support for SUSE 9.2 (was: Kontact in KDE 3.3 vs in 3.4)

On Tuesday 31 May 2005 17:32, Hans Moser wrote:
> Andreas Gungl schrieb das Folgende am 31.05.2005 17:09:
> > Given the background you've described, you might want to give
> > http://www.kolab-konsortium.de/ a try. They can certainly provide the
> > service you're looking for.
>
> In Osnabrück and same phonenumber than Intevation. Suprise, suprise! ;-)
>
> Ok, it _is_ Intevation GmbH - plus Klarälvdalens Datakonsult AB.
> -> http://www.kolab-konsortium.de/impressum.html

We are still ironing out organisational details...
Of course we are acting together with Erfrakon
and have prefered partners like 
Radley Network Communication for the Toltec connector 
and Codefusion for support in Africa and customising.

As for your question regarding SUSE 9.2:
We would build on top of Suse's KDE base and libs packages
that we can support. Technically this is mostly KDE PIM 
from the Proko2 branch. This is important for production systems
as we have a more stable behaviour then going with 3.4.x currently.

Best,
Bernhard
Attachment (smime.p7s): application/pkcs7-signature, 2145 bytes
_______________________________________________
Kolab-users mailing list
(Continue reading)

Stephan Buys | 1 Jun 2005 10:16
Picon

Re: Which user to set in checkout_proko2.sh

I modified the script to use anonsvn, try this one (or apply the same changes 
to the latest script if this one is outdated...)

http://intevation.de/pipermail/kolab-users/attachments/20050517/ca808f97/checkout_proko2_anon.bin

On Tuesday 31 May 2005 17:34, Stefan wrote:
> Hello List!
> 
> Okay, I'm not that type of svn-guru.
> I get the latest version of the script, but I need to know, which user I 
> should use! Is it something like "anoymous"? :-)
> 
> Perhaps it's possible to write a "Mini-Micro-Howto" (only a few lines) 
> regarding the checkout procedure of proko2!
> 
> TIA
> Stefan
> 
> _______________________________________________
> Kolab-users mailing list
> Kolab-users <at> kolab.org
> https://kolab.org/mailman/listinfo/kolab-users
> 
> 
> 
> 

--

-- 
Stephan  Buys
Code Fusion cc.
(Continue reading)

Stefan | 1 Jun 2005 10:43

Re: Which user to set in checkout_proko2.sh

Am Mittwoch 01 Juni 2005 10:16 schrieb Stephan Buys:
> I modified the script to use anonsvn, try this one (or apply the same
> changes to the latest script if this one is outdated...)
>
> http://intevation.de/pipermail/kolab-users/attachments/20050517/ca808f97/ch
>eckout_proko2_anon.bin
 Ahhhhh! Looking gooooooood!! :-)
It works!
Thank you very much!!
Stefan
Bernhard Reiter | 1 Jun 2005 12:24
Picon
Favicon

Re: Which user to set in checkout_proko2.sh

On Wednesday 01 June 2005 10:16, Stephan Buys wrote:
> I modified the script to use anonsvn, try this one (or apply the same
> changes to the latest script if this one is outdated...)

I think David just makes the changes in CVS.

> http://intevation.de/pipermail/kolab-users/attachments/20050517/ca808f97/ch
>eckout_proko2_anon.bin
>
Attachment (smime.p7s): application/pkcs7-signature, 2145 bytes
_______________________________________________
Kolab-users mailing list
Kolab-users <at> kolab.org
https://kolab.org/mailman/listinfo/kolab-users
Bernhard Reiter | 1 Jun 2005 12:50
Picon
Favicon

Re: Which user to set in checkout_proko2.sh

On Wednesday 01 June 2005 12:24, Bernhard Reiter wrote:
> On Wednesday 01 June 2005 10:16, Stephan Buys wrote:
> > I modified the script to use anonsvn, try this one (or apply the same
> > changes to the latest script if this one is outdated...)
>
> I think David just makes the changes in CVS.

Done.

after updating checkout_proko2.sh, you now can

export SVNSERVER=anonsvn.kde.org
cd /wanted/directory/for/checkout
ln -s /path/to/checkout_proko2.sh .
sh checkout_proko2.sh
Attachment (smime.p7s): application/pkcs7-signature, 2145 bytes
_______________________________________________
Kolab-users mailing list
Kolab-users <at> kolab.org
https://kolab.org/mailman/listinfo/kolab-users
Oliver Wiemer | 1 Jun 2005 16:20
Picon

Re: Kolab install Problems

Hello ZigZAg,

do this

su -
enter passwd

mv /kolab /kolabtemp
cd /kolabtemp
sh obmtool kolab
#only RH based systems
chkconfig sendmail off
/etc/init.d/sendmail stop

# now start bootstrap
/kolab/etc/kolab/kolab_bootstrap -b

Please enter Hostname [oliver.wiemer.lan]: -> do this

Do you want to set up (1) a master Kolab server or (2) a slave [1] (1/2): 
press return

Please enter your Maildomain [wiemer.lan]: -> do this

Please choose a manager password [aMiRicGO0zF8IHz/]: -> do this

Enter fully qualified hostname of slave kolab server e.g. thishost.domain.tld 
[empty when done]: -> press return

Do you want to create CA and certificates [y] (y/n): press y
(Continue reading)

Helge Hess | 1 Jun 2005 16:33
Favicon

Re: Toltec connector and exceptions to recurring events

On Jun 1, 2005, at 9:47, Bernhard Reiter wrote:
> On Tuesday 31 May 2005 00:15, Helge Hess wrote:
>> IMHO the uid/recurrence-id is quite important in the real world
>> (and btw explicitly mentioned/supported in CalDAV). Maybe you can
>> somehow workaround using the CalDAV approach (storing multiple
>> vevents in memory under a single uid)?
> my design approach would be to solve the problem in the client,
> but that again needs a careful approach. In my view many recurrence
> rules are quite complicated, so there will be a simpler solution.

Honestly I can't follow what you are trying to say (my comment was 
about Kontact [to my knowledge a client ;-)], not about servers).

Did you mean by "solve the problem in the client" that the client 
should flatten recurrences and store them individually in the server 
(in other words: remove rrule support in the Kolab format)?

Greets,
   Helge
--

-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Gmane