From issues at kolab.org  Tue Dec  1 20:02:16 2009
From: issues at kolab.org (Mathieu Parent)
Date: Tue, 01 Dec 2009 19:02:16 +0000
Subject: [Kolab-devel] [issue3983] Phpunit testsuite fails on OpenPKG Kolab
	2.2.2
In-Reply-To: <1259694136.93.0.321365574788.issue3983@kolab.org>
Message-ID: <1259694136.93.0.321365574788.issue3983@kolab.org>


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

On a Debian lenny VM, following
http://wiki.kolab.org/index.php/Kolab2_Installation_-_Source, I got following
coverage:

Kolab_Format: OK (14 tests, 58 assertions)
Kolab_Server: Tests: 121, Assertions: 177, Incomplete: 56.
Kolab_Storage: Tests: 33, Assertions: 197, Failures: 1.
Kolab_FreeBusy: Failed opening required 'Horde/Kolab/Test.php'
Kolab_Filter: Tests: 21, Assertions: 44, Failures: 3.

----------
assignedto: wrobel
keyword: filter, format, freebusy, server, web client
messages: 22676
nosy: mathieu.parent, rbos, thomas, wrobel
status: unread
title: Phpunit testsuite fails on OpenPKG Kolab 2.2.2

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


From issues at kolab.org  Wed Dec  2 10:47:00 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 02 Dec 2009 09:47:00 +0000
Subject: [Kolab-devel] [issue3984] New filter "*.*" for the save mail as
	dialog.(rt#5896)
In-Reply-To: <1259747220.5.0.76543144692.issue3984@kolab.org>
Message-ID: <1259747220.5.0.76543144692.issue3984@kolab.org>


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

enterprise35 Kontact 20091127.1055372-kk1

Test:
1. RMB on a mail in the maillist.
2. Choose "Save as..."
The file dialog which opens, has a *.mbox filter. So only mbox files are
displayed. An additional filter "*.*" which shows every file of the folder could
be useful.

Please estimate and wait on an okay, before implement.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22680
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: New filter "*.*" for the save mail as dialog.(rt#5896)

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


From issues at kolab.org  Wed Dec  2 11:11:38 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 02 Dec 2009 10:11:38 +0000
Subject: [Kolab-devel] =?utf-8?q?=5Bissue3985=5D_Typos_in_German_dialog_?=
 =?utf-8?q?=22Ung=C3=BCltige_E-Mail-Adresse=22?=
In-Reply-To: <1259748698.46.0.813224952518.issue3985@kolab.org>
Message-ID: <1259748698.46.0.813224952518.issue3985@kolab.org>


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

observed with Kontact e35 kdepim   20091127.1055372-kk1
                          kde-l10n 20091127.1055371-kk1

Test:
1. Start to create a new event.
2. Enter a name.
3. Switch to attendee tab.
4. Click into the names/addresses field.
=>A Name at example.com address appears.
5. Press on ok.
=> The unvalid email address dialog appears(German: Ung?ltige E-Mail-Adresse)
and the German dialog has two typos in it:
* "nichtnach" instead of "nicht nach" (space missing)
* "E-Mail-Addresse" instead of "E-Mail-Adresse"

Please fix.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22681
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Typos in German dialog "Ung?ltige E-Mail-Adresse"

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


From issues at kolab.org  Wed Dec  2 11:50:31 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 02 Dec 2009 10:50:31 +0000
Subject: [Kolab-devel] [issue3986] event/todo rrecurrence option should
	be	consistent(rt#5900)
In-Reply-To: <1259751031.42.0.415714677844.issue3986@kolab.org>
Message-ID: <1259751031.42.0.415714677844.issue3986@kolab.org>


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

observed with Kontact e35 kdepim   20091127.1055372-kk1

Test (event):
1. Start to create a new event.
2. Click on "Edit..."
=> Now it is possible to add a recurrence.

Test (to-do):
1. Start to create a new to-do.
2. Click on the "Recurrence" Tab.
=> Now it is possible to add a recurrence.

The two ways are different. The to-do way is better in this case.
So please estimate to have a recurrence tab in the event case, too.
Wait on an okay, before implement.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22682
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: event/todo rrecurrence option should be consistent(rt#5900)

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


From issues at kolab.org  Thu Dec  3 11:34:14 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 03 Dec 2009 10:34:14 +0000
Subject: [Kolab-devel] [issue3988] Calendar: update mail of a changed
	attendee asked to	reply (rt#5899)
In-Reply-To: <1259836454.44.0.357126854057.issue3988@kolab.org>
Message-ID: <1259836454.44.0.357126854057.issue3988@kolab.org>


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

observed with Kontact e35 20091127.1055372-kk1

Test:
1. A invites B to an event.
2. B forwards the event to C and accepts the event.
3. C accepts.
4. A accepts C to the event and sends an update mail.
=> B gets an update mail which says: Your reply is needed. (In German: "Ihre
Antwort wird angefordert")
But B has already answered to the event. If B has already answered to an event,
he should not need to answer to the same event again.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22697
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Calendar: update mail of a changed attendee asked to reply (rt#5899)

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


From issues at kolab.org  Thu Dec  3 11:59:41 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 03 Dec 2009 10:59:41 +0000
Subject: [Kolab-devel] [issue3989] Calendar: Attendee names with comma are
	handled wrongly	(rt#5899)
In-Reply-To: <1259837981.88.0.575424181895.issue3989@kolab.org>
Message-ID: <1259837981.88.0.575424181895.issue3989@kolab.org>


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

observed with Kontact e35 20091127.1055372-kk1

Test:
1. Start to create a new event.
2. Switch to the attendee tab.
3. Enter: Test1, Test2 <test at test.hq> 
   into the attendee textfield.
=>  The attendee name in the list is: Test2 <test at test.hq>
This is wrong. 

Test2:
1. Get an invitation and click on forward invitation.
2. Enter a name into the forward dialog: Test1, Test2 <test at test.hq>
3. Press Add and Okay
=> The mail is sent to: Test1 at test.hq, Test2 <test at test.hq>
This is wrong, too.

I think there exist other problems of emails/names with comma.

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22699
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Calendar: Attendee names with comma are handled wrongly (rt#5899)

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


From math.parent at gmail.com  Thu Dec  3 19:29:26 2009
From: math.parent at gmail.com (Mathieu Parent)
Date: Thu, 3 Dec 2009 19:29:26 +0100
Subject: [Kolab-devel] Call for testing and proposal for kolab-test-toolbox
Message-ID: <960738410912031029x63e4a937ocf38c6c6411f60f0@mail.gmail.com>

Hello,

I just have commited kolab-test-toolbox.pl to CVS.

This tools aims to easily test kolab:
- bootstrap a VM
- boot it
- install kolab on it
- test

Currently three "platforms" have been created (in kolab-test-toolbox.ini):
- OpenPKG on lenny
- native on lenny
- native on sid (fail to build, see [ftbfs])

Currently, only VirtualBox and Xen are supported.

Ideas/to be done:
- add other distributions (suse, gentoo, ubuntu, mandriva, ...)
- add other native methods (those in dist_conf, mainly gentoo and suse)
- add other VM types (kvm, ...)
- implement Installation from CVS
(http://wiki.kolab.org/index.php/Kolab2_Beta_testing)
- enhance the testsuite

The testsuite, very small as of now, already helped me to report:
https://issues.kolab.org/issue3983
https://issues.kolab.org/issue3949

Comments, improvements, ideas, .. welcome!

NB: kolab-test-toolbox requires:
- Sys::Virt  http://search.cpan.org/dist/Sys-Virt/
- Expect http://search.cpan.org/dist/Expect/
- libvirt
- xen-create-image from xen-tools (will probably drop this requirement
in the future)

Mathieu Parent

[ftbfs]: one cause is described here:
<http://wiki.kolab.org/index.php/Kolab2_Server_Troubleshooting_-_Compiling#Fail_to_build_from_source_with_error:_conflicting_types_for_.27getline.27>.
There is at least another problem caused by the use of newer gcc.
===============
Output of kolab-test-toolbox.pl --test:
---------------
Usage:
    kolab-test-toolbox [options] command [[options] command] ...

Arguments:
    *bootstrap*
            Step 1: Bootstrap the domain

    *preboot_install*
            Step 2: Install from chroot.

    *boot*  Step 3: Power on the domain

    *install*
            Step 4: Install

    *test*  Step 5: Test

    *chroot*
            Extra step: Chroot to the mounted root partition

    *login* Extra step: Log in via ssh

    *list-platforms*
            Extra step: List available platforms

Options:
    --help  Print a brief help message and exits.

    --man   Prints the manual page and exits.

    --platform=*NAME*
            Set platform. See also command *list-platforms*.


From ml at radoeka.nl  Thu Dec  3 19:45:49 2009
From: ml at radoeka.nl (Richard Bos)
Date: Thu, 3 Dec 2009 19:45:49 +0100
Subject: [Kolab-devel] Call for testing and proposal for
	kolab-test-toolbox
In-Reply-To: <960738410912031029x63e4a937ocf38c6c6411f60f0@mail.gmail.com>
References: <960738410912031029x63e4a937ocf38c6c6411f60f0@mail.gmail.com>
Message-ID: <200912031945.49330.ml@radoeka.nl>

Mathieu,

Op donderdag 03 december 2009 19:29:26 schreef Mathieu Parent:
> Ideas/to be done:
> - add other native methods (those in dist_conf, mainly gentoo and suse)

What's needed to achieve this?

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

From ml at radoeka.nl  Thu Dec  3 21:13:18 2009
From: ml at radoeka.nl (Richard Bos)
Date: Thu, 3 Dec 2009 21:13:18 +0100
Subject: [Kolab-devel] What's going with kolab on openSUSE (blog post)
Message-ID: <200912032113.18510.ml@radoeka.nl>

For those interested what's going with kolab on openSUSE,
the following blog post might be interesting:
http://lizards.opensuse.org/2009/12/03/kolab-cyrus-imapd-inherits-from-opensuse-base-cyrus-imapd/

-- 
Richard

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

From math.parent at gmail.com  Thu Dec  3 21:32:00 2009
From: math.parent at gmail.com (Mathieu Parent)
Date: Thu, 3 Dec 2009 21:32:00 +0100
Subject: [Kolab-devel] Call for testing and proposal for
	kolab-test-toolbox
In-Reply-To: <200912031945.49330.ml@radoeka.nl>
References: <960738410912031029x63e4a937ocf38c6c6411f60f0@mail.gmail.com>
	<200912031945.49330.ml@radoeka.nl>
Message-ID: <960738410912031232u244e6615sbda1788fe8ddaaea@mail.gmail.com>

hello Richard,


On Thu, Dec 3, 2009 at 7:45 PM, Richard Bos <ml at radoeka.nl> wrote:
> Mathieu,
>
> Op donderdag 03 december 2009 19:29:26 schreef Mathieu Parent:
>> Ideas/to be done:
>> - add other native methods (those in dist_conf, mainly gentoo and suse)
>
> What's needed to achieve this?

Basically three things:
- add a new vm_install_method (suse)
- add a new 'kolab_installation_method' native_suse
- adding a section in the inifile

The first part can be skipped as you can do this manually (using a CD
in the VM, or virtinst)

For the second part, you can improve "sub domain_install" with some
if(...) from "Preparing packages" to "Kolab bootstrap" (with some
minor changes after).

The third part is the easier, add something like this in the ini file:
[suse-11-native]
storage_pool_dir=/var/tmp/pkg-kolab_testsuite/suse-11-native

vm_install_method=virtinst
vm_dist=11

ip_offset=25

kolab_installation_method=native_suse

Don't hesitate to commit major changes (we can break the testsuite :).

Regards

> --
> Richard


From wrobel at pardus.de  Fri Dec  4 07:39:11 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 04 Dec 2009 07:39:11 +0100
Subject: [Kolab-devel] What's going with kolab on openSUSE (blog post)
In-Reply-To: <200912032113.18510.ml@radoeka.nl>
References: <200912032113.18510.ml@radoeka.nl>
Message-ID: <20091204073911.77701q0r03og20e8@webmail.pardus.de>


Quoting Richard Bos <ml at radoeka.nl>:

> For those interested what's going with kolab on openSUSE,
> the following blog post might be interesting:
>
http://lizards.opensuse.org/2009/12/03/kolab-cyrus-imapd-inherits-from-opensuse-base-cyrus-imapd/

Thanks for sharing the information! We seem to be getting more verbose  
these days. Which is a good thing :)

By the way: After several years of silence the core cyrus annotation  
patch has seen some comments in the associated Cyrus IMAP bug  
(https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2458) last week. Even  
Ken Murchison dropped a comment. Probably does not mean much but who  
knows.

Cheers,

Gunnar

>
> -- 
> Richard
>
>

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

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

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

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

From wrobel at pardus.de  Fri Dec  4 08:41:57 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 04 Dec 2009 08:41:57 +0100
Subject: [Kolab-devel] Call for testing and proposal
	for	kolab-test-toolbox
In-Reply-To: <960738410912031029x63e4a937ocf38c6c6411f60f0@mail.gmail.com>
References: <960738410912031029x63e4a937ocf38c6c6411f60f0@mail.gmail.com>
Message-ID: <20091204084157.16567iqooz02mz4s@webmail.pardus.de>

Hi Mathieu!

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

> Hello,
>
> I just have commited kolab-test-toolbox.pl to CVS.

Very nice! Thanks a lot.

I did move this from the "testing" directory to a new "ci" (for  
continuous integration) hierarchy. I also added my older "ec2"  
directory there (see below). I'm pretty certain Thomas also has a few  
ideas concerning CI but I hope it makes sense to keep the things that  
will be needed in that area within utils/ci.

>
> This tools aims to easily test kolab:
> - bootstrap a VM
> - boot it
> - install kolab on it
> - test
>
> Currently three "platforms" have been created (in kolab-test-toolbox.ini):
> - OpenPKG on lenny
> - native on lenny
> - native on sid (fail to build, see [ftbfs])
>
> Currently, only VirtualBox and Xen are supported.
>
> Ideas/to be done:
> - add other distributions (suse, gentoo, ubuntu, mandriva, ...)
> - add other native methods (those in dist_conf, mainly gentoo and suse)

Native Kolab2/Gentoo is a project I needed to drop between of time  
constraints. So it is unlikely I'll add something for gentoo soon :(

> - add other VM types (kvm, ...)

As I'm currently only using Amazon ec2 for such things I'd like to  
merge my older shell scripts into your perl script.

Cheers,

Gunnar

> - implement Installation from CVS
> (http://wiki.kolab.org/index.php/Kolab2_Beta_testing)
> - enhance the testsuite
>
> The testsuite, very small as of now, already helped me to report:
> https://issues.kolab.org/issue3983
> https://issues.kolab.org/issue3949
>
> Comments, improvements, ideas, .. welcome!
>
> NB: kolab-test-toolbox requires:
> - Sys::Virt  http://search.cpan.org/dist/Sys-Virt/
> - Expect http://search.cpan.org/dist/Expect/
> - libvirt
> - xen-create-image from xen-tools (will probably drop this requirement
> in the future)

Does it make sense to directly package this in a decent perl package?  
Similar to perl-kolab?

>
> Mathieu Parent
>
> [ftbfs]: one cause is described here:
> <http://wiki.kolab.org/index.php/Kolab2_Server_Troubleshooting_-_Compiling#Fail_to_build_from_source_with_error:_conflicting_types_for_.27getline.27>.
> There is at least another problem caused by the use of newer gcc.
> ===============
> Output of kolab-test-toolbox.pl --test:
> ---------------
> Usage:
>     kolab-test-toolbox [options] command [[options] command] ...
>
> Arguments:
>     *bootstrap*
>             Step 1: Bootstrap the domain
>
>     *preboot_install*
>             Step 2: Install from chroot.
>
>     *boot*  Step 3: Power on the domain
>
>     *install*
>             Step 4: Install
>
>     *test*  Step 5: Test
>
>     *chroot*
>             Extra step: Chroot to the mounted root partition
>
>     *login* Extra step: Log in via ssh
>
>     *list-platforms*
>             Extra step: List available platforms
>
> Options:
>     --help  Print a brief help message and exits.
>
>     --man   Prints the manual page and exits.
>
>     --platform=*NAME*
>             Set platform. See also command *list-platforms*.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



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

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

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

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

From wrobel at pardus.de  Fri Dec  4 09:35:10 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 04 Dec 2009 09:35:10 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <20091125091114.022422160.thomas@intevation.de>
References: <20091020172924.577027525.thomas@intevation.de>
	<20091116232903.184470z9qm8t1cg8@webmail.pardus.de>
	<20091124000646.133563d7ga1eg680@webmail.pardus.de>
	<20091124112336.627744926.thomas@intevation.de>
	<20091124210623.10962hqtw9tktscg@webmail.pardus.de>
	<20091125091114.022422160.thomas@intevation.de>
Message-ID: <20091204093510.98433309d2m3gesk@webmail.pardus.de>

Hi!

An udate on the current ToDo-List for Kolab Server 2.2.3 as I see it  
at the moment (Thomas got sick this week so I took over some of the  
issues from him):

Thomas (thomas):
   small effort:
     switch imapd databases back from berkeley to skiplist
       (skiplist has proven to cause less performance and stability issues)
     kolab/issue3513 (Clamav - new upstream version 0.95.3)
       (needs cleanup: release-notes, Makefile)
     kolab/issue3938 (compiling procmail fails on Fedora 11 and Ubuntu karmic)
       (updated OpenPKG package available)
     kolab/issue3940 (Deleting users does not work if master Kolab  
server is not master LDAP)
       (workaround exists, needs real fix)
   larger effort:
     (no public issue) Option to restrict MDNs to local server
       (new feature, but requested by customer)
     kolab/issue3138 (problems with server upgrade from sarge to etch)
       (we have done this a couple of times from sarge or etch to lenny now)

Gunnar (wrobel):
     kolab/issue919  (kolab server has problems with some characters  
in passwords)
     kolab/issue1340 (RFC: restrict users to sending mail only to  
internal recipients)
       (new feature, but requested by customers)
     kolab/issue1448 (Users might add an account on the nonHome Server  
and write emails in there.)
       (probably just adjust ACLs)
     kolab/issue3751 (Empty page in Firefox instead of login screen)
       (caused by a broken event or contact, needs further investigation)
     kolab/issue3838 (no logging for pop3)
       (small change in imapd package required)
     kolab/issue3895 (Openldap: loglevel should be set to none in slapd.conf)
       (small change, big benefit)
     kolab/issue3951 (kolabconf -n (noreload) restarts services if   
RUNONCHANGE is used)
       (rbos provided a patch)

Sascha (wilde):

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

And as usual, many of the issues which were fixed recently need testing.
Link for all server and web client issues on testing:

https://issues.kolab.org/issue?:columns=title,id,keyword&:group=priority&:filter=keyword,status&status=6&keyword=1,19

Some of the issues that need testing are:
   kolab/issue3594 (Mail containing NUL byte not delivered, Kolab  
Filter does not report lmtp error)
   kolab/issue3846 (fix recurring events that are counted per week and  
not per incident)
   kolab/issue3965 (Always accept: invitations get lost when Calendar  
folder ist not writable for the calendar user)


DONE (Issues that were completed):

   kolab/issue973 (Rewritten from shown inconveniently in kontact)
     (patch for server-side available)
   kolab/issue2499 (Notification messages by the resource manager  
should be localized)
   kolab/issue3952 (Version in kolabconf is not replaced in the build process)


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

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

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

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

From ml at radoeka.nl  Fri Dec  4 20:30:49 2009
From: ml at radoeka.nl (Richard Bos)
Date: Fri, 4 Dec 2009 20:30:49 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab MANIFEST, 1.9,
	1.10 Makefile.PL, 1.17, 1.18
In-Reply-To: <20091204112321.CE25D60057F@lists.intevation.de>
References: <20091204112321.CE25D60057F@lists.intevation.de>
Message-ID: <200912042030.50051.ml@radoeka.nl>

Hi Gunnar,

when packaging the updated perl-kolab I get this:
+ /usr/bin/perl Makefile.PL --config /etc/kolab --bin /usr/bin --sbin 
/usr/sbin --etc /etc/kolab
Checking if your kit is complete...
Warning: the following files are missing in your kit:
        Base.mk
Please inform the author.
Writing Makefile for perl-kolab
+ /usr/bin/make
Makefile:937: Base.mk: No such file or directory
make: *** No rule to make target `Base.mk'.  Stop.


Is the Makefile not complete yet?


Op vrijdag 04 december 2009 12:23:21 schreef cvs at kolab.org:
> Author: gunnar
>
> Update of /kolabrepository/server/perl-kolab
> In directory doto:/tmp/cvs-serv10694
>
> Modified Files:
> 	MANIFEST Makefile.PL
> Log Message:
> Complete  kolab/issue3952 (Version in kolabconf is not replaced in the
> build process)
>
> Index: MANIFEST
> ===================================================================
> RCS file: /kolabrepository/server/perl-kolab/MANIFEST,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -u -d -r1.9 -r1.10
> --- MANIFEST	16 Mar 2009 17:17:34 -0000	1.9
> +++ MANIFEST	4 Dec 2009 11:23:19 -0000	1.10
> @@ -1,4 +1,5 @@
>  AUTHORS
> +Base.mk
>  ChangeLog
>  INSTALL
>  bin/kolabdcachetool.in



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

From ml at radoeka.nl  Fri Dec  4 20:47:59 2009
From: ml at radoeka.nl (Richard Bos)
Date: Fri, 4 Dec 2009 20:47:59 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab MANIFEST, 1.9,
	1.10 Makefile.PL, 1.17, 1.18
In-Reply-To: <200912042030.50051.ml@radoeka.nl>
References: <20091204112321.CE25D60057F@lists.intevation.de>
	<200912042030.50051.ml@radoeka.nl>
Message-ID: <200912042048.00069.ml@radoeka.nl>

Op vrijdag 04 december 2009 20:30:49 schreef Richard Bos:
> Makefile:937: Base.mk: No such file or directory
> make: *** No rule to make target `Base.mk'.  Stop.
>
>
> Is the Makefile not complete yet?

It goes wrong file executing 'perl Makefile.PL'.  I added a check to it, 
being:
sub MY::postamble {
    if (-e "../Base.mk")
    {
        copy("../Base.mk", "./") or die "Could not copy ../Base.mk";
    } else {
        die "../Base.mk does not exist";  <<<<<<<<<<
    }
    my $add = "include Base.mk

Now when I run 'perl Makefile.PL', it fails with:
perl-kolab-2.2.2.90_cvs20091204> perl Makefile.PL
../Base.mk does not exist at Makefile.PL line 103.

Base.mk is located at:
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/Base.mk?rev=1.2&content-
type=text/vnd.viewcvs-markup

Does it need an issue to be opened for it?

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

From ml at radoeka.nl  Fri Dec  4 21:11:46 2009
From: ml at radoeka.nl (Richard Bos)
Date: Fri, 4 Dec 2009 21:11:46 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab MANIFEST, 1.9,
	1.10 Makefile.PL, 1.17, 1.18
In-Reply-To: <200912042048.00069.ml@radoeka.nl>
References: <20091204112321.CE25D60057F@lists.intevation.de>
	<200912042030.50051.ml@radoeka.nl>
	<200912042048.00069.ml@radoeka.nl>
Message-ID: <200912042111.46642.ml@radoeka.nl>

Op vrijdag 04 december 2009 20:47:59 schreef Richard Bos:
> It goes wrong file executing 'perl Makefile.PL'.  I added a check to it,
> being:
> sub MY::postamble {
>     if (-e "../Base.mk")
>     {
>         copy("../Base.mk", "./") or die "Could not copy ../Base.mk";
>     } else {
>         die "../Base.mk does not exist";  <<<<<<<<<<
>     }
>     my $add = "include Base.mk
>
> Now when I run 'perl Makefile.PL', it fails with:
> perl-kolab-2.2.2.90_cvs20091204> perl Makefile.PL
> ../Base.mk does not exist at Makefile.PL line 103.

When I use the original Makefile.PL and remove "include Base.mk", 'make 
install' complains:

chmod 755 /usr/src/packages/BUILD/perl-
kolab-2.2.2.90_cvs20091204/ME//kolab/sbin/*                                                                   
/bin/sh: -q: invalid option                                                                                                                          
I think it fails at:
ifeq \"x\$(PLATTAG)\" \"x\"
        PLATTAG = \$(shell /usr/bin/rpm -q --qf=\"%{ARCH}-%{OS}\" 
openpkg)-\$(HOME:/%=%)
endif

Ain't possible to use a perl function for it:
 perl -V
Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
  Platform:                                                            
    osname=linux, osvers=2.6.27, archname=i586-linux-thread-multi      
........

Perhaps something like:
perl-kolab> perl -V:vendorlib
vendorlib='/usr/lib/perl5/vendor_perl/5.10.0';

/perl-kolab> perl -V:sitelib
sitelib='/usr/lib/perl5/site_perl/5.10.0';

or
5.10.0> perl -V:myarchname
myarchname='i686-linux';

/usr/lib/perl5/5.10.0> perl -V:archname
archname='i586-linux-thread-multi';

Don't know what you're looking for.  More info in 'perldoc perltoc'



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

From wrobel at pardus.de  Mon Dec  7 14:27:39 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 07 Dec 2009 14:27:39 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab MANIFEST, 1.9,
	1.10	Makefile.PL, 1.17, 1.18
In-Reply-To: <200912042048.00069.ml@radoeka.nl>
References: <20091204112321.CE25D60057F@lists.intevation.de>
	<200912042030.50051.ml@radoeka.nl> <200912042048.00069.ml@radoeka.nl>
Message-ID: <20091207142739.36522qk3n49q3g84@webmail.pardus.de>


Quoting Richard Bos <ml at radoeka.nl>:

> Op vrijdag 04 december 2009 20:30:49 schreef Richard Bos:
> > Makefile:937: Base.mk: No such file or directory
> > make: *** No rule to make target `Base.mk'.  Stop.
> >
> >
> > Is the Makefile not complete yet?
>
> It goes wrong file executing 'perl Makefile.PL'.  I added a
> check to it, being:
> sub MY::postamble {
> if (-e "../Base.mk")
> {
> copy("../Base.mk", "./") or die "Could not copy ../Base.mk";
> } else {
> die "../Base.mk does not exist"; <<<<<<<<<<
> }
> my $add = "include Base.mk
>
> Now when I run 'perl Makefile.PL', it fails with:
> perl-kolab-2.2.2.90_cvs20091204> perl Makefile.PL
> ../Base.mk does not exist at Makefile.PL line 103.
>
> Base.mk is located at:
>
http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/Base.mk?rev=1.2&content-type=text/vnd.viewcvs-markup
>

Why is Base.mk missing in your case? Did you only check out the  
perl-kolab directory?

The correct fix would probably be to separate source from packaging  
here. Same thing we'd need to do for kolabd and kolab-webadmin. I hope  
we find the time for this for 2.3.

Cheers,

Gunnar

> Does it need an issue to be opened for it?
>
> -- 
> Richard

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

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

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

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

From tr at erdfunkstelle.de  Mon Dec  7 21:08:49 2009
From: tr at erdfunkstelle.de (Thomas Reitelbach)
Date: Mon, 7 Dec 2009 21:08:49 +0100
Subject: [Kolab-devel] Kontact for Windows - new Beta?
Message-ID: <200912072108.49200.tr@erdfunkstelle.de>

Hello developers list,

I regularly visit the beta-page for kontact for windows, hoping that there 
will be an updated beta package for download available.
The last beta (2009-06) I tested had a bug that was critical to me (timezone 
handling in the calendar) and since june I hope to get a new beta for testing.

Would it be possible to create a new beta for download?
Or are there instructions for building kontact for windows myself? I already 
managed to build regular KDE packages for windows, but didn't try kdepim yet.

Any help would be very appreciated :-)
I'm willing to debug and fill bug reports where I'm able to!

Cheers
Thomas


From issues at kolab.org  Mon Dec  7 21:43:47 2009
From: issues at kolab.org (Richard Bos)
Date: Mon, 07 Dec 2009 20:43:47 +0000
Subject: [Kolab-devel] [issue3990] packaging perl-kolab does not work
	anymore after cvs	update to Makefile.PL, 1.17, 1.18
In-Reply-To: <1260218627.32.0.255921809306.issue3990@kolab.org>
Message-ID: <1260218627.32.0.255921809306.issue3990@kolab.org>


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

when packaging the updated perl-kolab I get this:
+ /usr/bin/perl Makefile.PL --config /etc/kolab --bin /usr/bin --sbin 
/usr/sbin --etc /etc/kolab
Checking if your kit is complete...
Warning: the following files are missing in your kit:
        Base.mk
Please inform the author.
Writing Makefile for perl-kolab
+ /usr/bin/make
Makefile:937: Base.mk: No such file or directory
make: *** No rule to make target `Base.mk'.  Stop.


Is the Makefile not complete yet?


Op vrijdag 04 december 2009 12:23:21 schreef cvs at kolab.org:
> Author: gunnar
>
> Update of /kolabrepository/server/perl-kolab
> In directory doto:/tmp/cvs-serv10694
>
> Modified Files:
>       MANIFEST Makefile.PL
> Log Message:
> Complete  kolab/issue3952 (Version in kolabconf is not replaced in the
> build process)
>
> Index: MANIFEST
> ===================================================================
> RCS file: /kolabrepository/server/perl-kolab/MANIFEST,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -u -d -r1.9 -r1.10
> --- MANIFEST  16 Mar 2009 17:17:34 -0000      1.9
> +++ MANIFEST  4 Dec 2009 11:23:19 -0000       1.10
> @@ -1,4 +1,5 @@
>  AUTHORS
> +Base.mk
>  ChangeLog
>  INSTALL
>  bin/kolabdcachetool.in

Issue first reported on the kolab-devel, the thread starts on this url:
http://www.kolab.org/pipermail/kolab-devel/2009-December/011068.html
<more information, from kolab-devel to be added>

----------
keyword: server
messages: 22735
nosy: mathieu.parent, rbos, thomas, wilde, wrobel
priority: bug
status: unread
title: packaging perl-kolab does not work anymore after cvs update to Makefile.PL, 1.17, 1.18

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


From martin.konold at erfrakon.de  Tue Dec  8 08:08:10 2009
From: martin.konold at erfrakon.de (Martin Konold)
Date: Tue, 8 Dec 2009 08:08:10 +0100
Subject: [Kolab-devel] Fwd: Introducing OpenPKG 4.x
Message-ID: <200912080808.11106.martin.konold@erfrakon.de>



Hi,

somthing like this was expected for a while. 

I therefore propose to prepare a decision with regards to using OpenPKG within 
the Kolab Project.

What about an IRC discussion in the near future?

Yours,
-- martin

----------  Forwarded Message  ----------

Subject: Introducing OpenPKG 4.x
Date: Monday 07 December 2009
From: Thomas Lotterer <thl at openpkg.org>
To: openpkg-announce at openpkg.org

Dear fellows.

Time to keep you posted what's going on in the world of OpenPKG.

     **** OpenPKG 4.x concept ****

You might have noticed that the latest "openpkg" bootstrap package has
been released on openpkg.org just before the end of the year 2007.
Beginning 2008-01-01 OpenPKG has adopted the "Open Source Software
Refinement" (OSSR) architecture [1] which was first published on "Open
Source Meets Business" event in January 2007. The substantial change was
to split packages from the framework. The idea is to let users focus on
using Software Stacks (SS), maintainers focus on maintaining Software
Packages (SP) and developers focus on developing the Package Framework
(PF).

     SC + PS = SP

The OSSR architecture defines that Software Components (SC) are packaged
into Software Packages (SP) by adding Package Specifications (PS). This
is how OpenPKG worked all the time, so no change here. However, to
emphasize this concept to the community, the license ownership has been
transferred to the OpenPKG Foundation e.V. which is since then
responsible to supply SPs and continues to issue them under BSD style
Open Source license.

     SP + PF = SS

The OSSR architecture also defines that Software Stacks (SS) are built
from Software Packages (SP) by adding a Package Framework (PF). This is
once again the way OpenPKG worked all the time, so no change here as
well. However, what has been formerly known as the "bootstrap" has been
renamed to the "framework". The PF development is solely driven by the
OpenPKG GmbH which owns the copyright of some core PF components.

     **** OpenPKG 4.x licensing ****

The next generation of OpenPKG ships with full source code and the
framework is subject to a commercial license. There is a license for
free evaluation (EVAL), one license is free for creating examples,
documentation and trainings (EXAMPLE), one license is free for "bleeding
edge" "build from source" stacks (COMMUNITY). More licenses are possible
with one variant being a time-limited promotional offering (PROMO).
Finally, for static installations, a shareware license (VALUE) will be
available for a small fee.

The framework is licensed and anyone who wants to run it has to acquire
a license. The VALUE license works "per kernel". This approach was
chosen to encourage users to deploy many OpenPKG instances on one
system, while still allowing fully administrative disjunct installations
using chroots, jails, zones and vservers. In contrast, bare metal,
hardware virtualization, and multiple kernels require additional
licenses per se. The price is in the typical low cost shareware space
and licenses can be obtained from an online shop soon. The VALUE license
allows run-time usage of all OpenPKG 4.x frameworks released in the
past, the present one and all future frameworks within one year after
purchase -- as long as technically feasible. It has no run-time
limitations related to space, time, packages, users, network, domain,
processors, instances etc.

     **** OpenPKG 4.x technology ****

The OpenPKG GmbH has great impact on RPM5 development. In fact it hosts
the project infrastructure [3], and it is no surprise the infrastructure
is built from OpenPKG 4.x with RPM5. Almost every OpenPKG improvement
which was previously developed for RPM4 has not only been ported to, but
has become an integral part of, RPM5.

There is a smooth but short upgrade path where both the old bootstrap
and the new framework will continue to work with old and CURRENT
packages, providing full interoperability. Backwards compatibility in
all areas from package file format, package database, package
specifications and instance administration was the major goal for
OpenPKG 4.x. However, in order to unleash the power of the new framework
it is inevitable that packages leverage new features. This evolution
will break compatibility between the RPM4 based <=2007 and RPM5 based
  >=2010 generations. Please note there are no plans to enhance, bug- or
security fix, port or otherwise improve the 2007 bootstrap, nor are
there any plans of maintaining dual packages. Expect 2009-12-31 being
the end of the RPM4-based and 2010-01-01 being the start of RPM5-based
OpenPKG development. Needless to say, this does in no way affect
existing installations.

     **** OpenPKG 4.x infrastructure ****

In order to consolidate services and introduce the new concept to the
community we will disable RSYNC, FTP and CVS services on openpkg.org by
2009-12-31. The OpenPKG GmbH pushes the Package Framework (PF) to
openpkg.org and the OpenPKG Foundation e.V. pushes the Software Packages
(SP) to openpkg.org. The resulting stacks can be downloaded from
openkg.org through HTTP. There are no replacements for RSYNC and FTP.
The result is a HTTP based infrastructure where users work with packages
only.

     **** OpenPKG 4.x summary ****

- Software Stacks (SS) = Package Framework (PF) + Software Packages (SP)
- Full source code shipping
- Open Source Software Packages (SP)
- Shareware Package Framework (PF) with some licenses available for free
- OpenPKG 4.x Beta available now [4]
- Shutdown of FTP, RSYNC and public CVS by the end of year 2009
- HTTP access already available now
- 2009-12-31 end of RPM4-based OpenPKG package development
- 2010-01-01 start of RPM5-based OpenPKG package development

Now go ahead and build Software Stacks ...

[1]
http://www.openpkg.com/events/osmb2007/openpkg-osmb2007-poster-low-
resolution.pdf
[2] http://www.heise.de/events/2007/open_source_meets_business/
[3] http://rpm5.org/
[4] http://download.openpkg.org/framework/testing/source/

-- 
Ralf S. Engelschall and Thomas Lotterer
______________________________________________________________________
OpenPKG                                             http://openpkg.org
Announcement List                         openpkg-announce at openpkg.org

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


From paul at kdab.com  Tue Dec  8 08:57:42 2009
From: paul at kdab.com (Paul Adams)
Date: Tue, 8 Dec 2009 07:57:42 +0000
Subject: [Kolab-devel] Fwd: Introducing OpenPKG 4.x
In-Reply-To: <200912080808.11106.martin.konold@erfrakon.de>
References: <200912080808.11106.martin.konold@erfrakon.de>
Message-ID: <886E32F6-F502-4390-9096-50CCDF4EC985@kdab.com>

Hi Martin (et al),

On 8 Dec 2009, at 07:08, Martin Konold wrote:
> I therefore propose to prepare a decision with regards to using  
> OpenPKG within
> the Kolab Project.

Hasn't the decision been made for us?...

The new licensing model, at least just after the brief description in  
this email, sounds unfriendly towards Free Software.

Either way, setting aside some time to discuss the future of Kolab  
packaging is not a bad idea.


All the best,
Paul

-- 
Paul J. Adams | paul at kdab.com | Software Engineer
Klar?lvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions


From martin.konold at erfrakon.de  Tue Dec  8 14:51:06 2009
From: martin.konold at erfrakon.de (Martin Konold)
Date: Tue, 8 Dec 2009 14:51:06 +0100
Subject: [Kolab-devel] What's going with kolab on openSUSE (blog post)
In-Reply-To: <20091204073911.77701q0r03og20e8@webmail.pardus.de>
References: <200912032113.18510.ml@radoeka.nl>
	<20091204073911.77701q0r03og20e8@webmail.pardus.de>
Message-ID: <200912081451.06796.martin.konold@erfrakon.de>

On Friday 04 December 2009 07:39:11 Gunnar Wrobel wrote:

Hi,

> By the way: After several years of silence the core cyrus annotation
> patch has seen some comments in the associated Cyrus IMAP bug
> (https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2458) last week. Even
> Ken Murchison dropped a comment. Probably does not mean much but who
> knows.

I promised today to have a look into this before the holidays.

Yours,
-- martin


From martin.konold at erfrakon.de  Tue Dec  8 16:30:05 2009
From: martin.konold at erfrakon.de (Martin Konold)
Date: Tue, 8 Dec 2009 16:30:05 +0100
Subject: [Kolab-devel] What's going with kolab on openSUSE (blog post)
In-Reply-To: <200912081451.06796.martin.konold@erfrakon.de>
References: <200912032113.18510.ml@radoeka.nl>
	<20091204073911.77701q0r03og20e8@webmail.pardus.de>
	<200912081451.06796.martin.konold@erfrakon.de>
Message-ID: <200912081630.06459.martin.konold@erfrakon.de>

On Tuesday 08 December 2009 14:51:06 Martin Konold wrote:
> On Friday 04 December 2009 07:39:11 Gunnar Wrobel wrote:

Hi,

> > (https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2458) last week. Even
> > Ken Murchison dropped a comment. Probably does not mean much but who
> > knows.
> 
> I promised today to have a look into this before the holidays.

Sorry, I meant Ken has promised not me ;-)

Yours,
-- martin


From ml at radoeka.nl  Tue Dec  8 20:02:08 2009
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 8 Dec 2009 20:02:08 +0100
Subject: [Kolab-devel] support for Kolab in Thunderbird??
Message-ID: <200912082002.08978.ml@radoeka.nl>

Some articles in the Internet press are stating that Mozilla is going to spend 
more time on developing Thunderbird (see e.g. 
http://www.theregister.co.uk/2009/12/05/thunderbird_future/).  
Would they (Mozilla) be interested in adding support for Kolab to Thunderbird?

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

From wrobel at pardus.de  Tue Dec  8 23:15:29 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 08 Dec 2009 23:15:29 +0100
Subject: [Kolab-devel] Separating sources from OpenPKG packaging
Message-ID: <20091208231529.53047dgndzthsohs@webmail.pardus.de>

Hi!

A long standing issue of the Kolab server has been the fact that  
source code packaging (*.tar.gz) was kept together with the necessary  
build machinery for the final OpenPKG RPM. This has been a larger  
problem for building native RPMs but also led to some interesting  
hacks and a degradation of code quality.

This has been largely resolved in the past years and we are left with  
three packages where this kind of organization is still present:

  - perl-kolab
  - kolabd
  - kolab-webadmin

It would be good to separate source code packaging from RPM building  
for the Kolab Server 2.3 version.

All I need in order to do this soon (once we released 2.2.3) would be  
a decision how the structure should look like. I would propose to add  
a new directory "src" in our "server" CVS module. So we would have

  - server/src/perl-kolab
  - server/src/kolabd
  - server/src/kolab-webadmin

These would be used to provide *.tar.gz packages that can be uploaded  
to files.kolab.org.

We'd keep the old

  - server/perl-kolab
  - server/kolabd
  - server/kolab-webadmin

but they'd just contain the OpenPKG RPM build machinery.

In principle I don't consider this a big deal and would just do it  
this way but I thought I'd ask to make sure nobody disagrees.

Cheers,

Gunnar

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

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



From alain.abbas at libertech.fr  Wed Dec  9 00:03:08 2009
From: alain.abbas at libertech.fr (Alain abbas)
Date: Wed, 09 Dec 2009 00:03:08 +0100
Subject: [Kolab-devel] support for Kolab in Thunderbird??
In-Reply-To: <200912082002.08978.ml@radoeka.nl>
References: <200912082002.08978.ml@radoeka.nl>
Message-ID: <4B1EDB2C.3040903@libertech.fr>

hi richard
we are working on Thunderbird+ lighting (inverse version) and Sogo 
Connector to integrate it
For the moment we started with Davical project to have a good support of 
Caldav . All things
that have seen about Caldav/horde is not clear and i didn t find a lot 
of information about it

We started with Davical and we synchronize the database of Davical 
(Postgres) with Kolab Folder
we have 3 clients who work like that and there are no major problem 
except the installation (Php kolab is not compiled with PosgesSql support)
the main advantage is the speed because the database is used as cache or 
proxy.
If someone is interested i can publish the code

i believe that Thunderbird + ligthning + sogo connector is a best 
replacement for outlook

Alain

Richard Bos a ?crit :
> Some articles in the Internet press are stating that Mozilla is going 
> to spend more time on developing Thunderbird (see e.g. 
> http://www.theregister.co.uk/2009/12/05/thunderbird_future/).
> Would they (Mozilla) be interested in adding support for Kolab to 
> Thunderbird?
>
>
> -- 
> Richard
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel


From thomas at btspuhler.com  Wed Dec  9 05:16:55 2009
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Tue, 8 Dec 2009 21:16:55 -0700
Subject: [Kolab-devel] Separating sources from OpenPKG packaging
In-Reply-To: <20091208231529.53047dgndzthsohs@webmail.pardus.de>
References: <20091208231529.53047dgndzthsohs@webmail.pardus.de>
Message-ID: <200912082116.56312.thomas@btspuhler.com>

On Tuesday 08 December 2009 03:15:29 pm Gunnar Wrobel wrote:
> Hi!
>
> A long standing issue of the Kolab server has been the fact that
> source code packaging (*.tar.gz) was kept together with the necessary
> build machinery for the final OpenPKG RPM. This has been a larger
> problem for building native RPMs but also led to some interesting
> hacks and a degradation of code quality.
>
> This has been largely resolved in the past years and we are left with
> three packages where this kind of organization is still present:
>
>   - perl-kolab
>   - kolabd
>   - kolab-webadmin
>
> It would be good to separate source code packaging from RPM building
> for the Kolab Server 2.3 version.
>
> All I need in order to do this soon (once we released 2.2.3) would be
> a decision how the structure should look like. I would propose to add
> a new directory "src" in our "server" CVS module. So we would have
>
>   - server/src/perl-kolab
>   - server/src/kolabd
>   - server/src/kolab-webadmin
>
> These would be used to provide *.tar.gz packages that can be uploaded
> to files.kolab.org.
>
> We'd keep the old
>
>   - server/perl-kolab
>   - server/kolabd
>   - server/kolab-webadmin
>
> but they'd just contain the OpenPKG RPM build machinery.
>
> In principle I don't consider this a big deal and would just do it
> this way but I thought I'd ask to make sure nobody disagrees.
>
> Cheers,
>
> Gunnar

I like this idea. This would make building the Mandriva native packages 
easier.
-- 
Thomas


From ml at radoeka.nl  Wed Dec  9 08:51:33 2009
From: ml at radoeka.nl (Richard Bos)
Date: Wed, 9 Dec 2009 08:51:33 +0100
Subject: [Kolab-devel] Separating sources from OpenPKG packaging
In-Reply-To: <20091208231529.53047dgndzthsohs@webmail.pardus.de>
References: <20091208231529.53047dgndzthsohs@webmail.pardus.de>
Message-ID: <20091209075133.GA47405@xs4all.nl>

On Tue, Dec 08, 2009 at 11:15:29PM +0100, Gunnar Wrobel wrote:
> All I need in order to do this soon (once we released 2.2.3) would be  
> a decision how the structure should look like. I would propose to add  
> a new directory "src" in our "server" CVS module. So we would have
> 
>   - server/src/perl-kolab
>   - server/src/kolabd
>   - server/src/kolab-webadmin
> 
> These would be used to provide *.tar.gz packages that can be uploaded  
> to files.kolab.org.
> 
> We'd keep the old
> 
>   - server/perl-kolab
>   - server/kolabd
>   - server/kolab-webadmin
> 
> but they'd just contain the OpenPKG RPM build machinery.
> 
> In principle I don't consider this a big deal and would just do it  
> this way but I thought I'd ask to make sure nobody disagrees.


So, actually what you want to do is to move the directories
 server/kolabd/kolabd           to src/kolabd
 server/kolab-admin/kolab-admin to src/kolab-admin
 and
 server/perl-kolab              to src/perl-kolab

I assume that the openpkg packaging stuff is located in
server/kolabd and server/kolab-admin.  For perl-kolab it seems
to be mixed.

Thinking Out Loud:
Everything related to the server is located in the cvs root 'server',
why should the above 3 mentioned modules be removed from there?
Wouldn't it be possible to leave the current structure and store
the openpkg stuff in a cvs module called openpkg?  Like:
server/{kolabd, kolab-webadmin, perl-kolab}
openpkg/{kolabd, kolab-webadmin, perl-kolab}

server/openpkg/{kolabd, kolab-webadmin, perl-kolab}

If you stay with your proposal, how would you move modules?
I hope that you'll move them on the server, to leave the cvs
history untouched.

-- 
Richard



From benoit.mortier at opensides.be  Wed Dec  9 12:51:50 2009
From: benoit.mortier at opensides.be (Benoit Mortier)
Date: Wed, 9 Dec 2009 12:51:50 +0100
Subject: [Kolab-devel] support for Kolab in Thunderbird??
In-Reply-To: <4B1EDB2C.3040903@libertech.fr>
References: <200912082002.08978.ml@radoeka.nl> <4B1EDB2C.3040903@libertech.fr>
Message-ID: <200912091251.51137.benoit.mortier@opensides.be>

Le Wednesday 09 December 2009 00:03:08 Alain abbas, vous avez ?crit?:
> hi richard

Hello,

> we are working on Thunderbird+ lighting (inverse version) and Sogo
> Connector to integrate it
> For the moment we started with Davical project to have a good support
> of Caldav . All things
> that have seen about Caldav/horde is not clear and i didn t find a lot
> of information about it

sure, there is no much

> We started with Davical and we synchronize the database of Davical
> (Postgres) with Kolab Folder
> we have 3 clients who work like that and there are no major problem
> except the installation (Php kolab is not compiled with PosgesSql
> support) the main advantage is the speed because the database is used
> as cache or proxy.
> If someone is interested i can publish the code

Yes i would be interested in waht you have done for that. 
> i believe that Thunderbird + ligthning + sogo connector is a best
> replacement for outlook

Yes, we have some old thunderbird + lightning + synckolab running at some 
place ;-)

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


From benoit.mortier at opensides.be  Wed Dec  9 12:55:14 2009
From: benoit.mortier at opensides.be (Benoit Mortier)
Date: Wed, 9 Dec 2009 12:55:14 +0100
Subject: [Kolab-devel] Fwd: Introducing OpenPKG 4.x
In-Reply-To: <200912080808.11106.martin.konold@erfrakon.de>
References: <200912080808.11106.martin.konold@erfrakon.de>
Message-ID: <200912091255.14803.benoit.mortier@opensides.be>

Le Tuesday 08 December 2009 08:08:10 Martin Konold, vous avez ?crit?:
> Hi,
>
> somthing like this was expected for a while.
>
> I therefore propose to prepare a decision with regards to using OpenPKG
> within the Kolab Project.
>
> What about an IRC discussion in the near future?

Yes sure, as i recommended to mathieu one great tool for packaing issues 
is http://trac.project-builder.org/

i started using it for my GOsa packaging effort for multi-distro and it is 
great. 

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


From ml at radoeka.nl  Wed Dec  9 14:24:13 2009
From: ml at radoeka.nl (Richard Bos)
Date: Wed, 9 Dec 2009 14:24:13 +0100
Subject: [Kolab-devel] Fwd: Introducing OpenPKG 4.x
In-Reply-To: <200912091255.14803.benoit.mortier@opensides.be>
References: <200912080808.11106.martin.konold@erfrakon.de>
	<200912091255.14803.benoit.mortier@opensides.be>
Message-ID: <20091209132413.GA67956@xs4all.nl>

Benoit,

On Wed, Dec 09, 2009 at 12:55:14PM +0100, Benoit Mortier wrote:
> Le Tuesday 08 December 2009 08:08:10 Martin Konold, vous avez ?crit?:
> > Hi,
> >
> > somthing like this was expected for a while.
> >
> > I therefore propose to prepare a decision with regards to using OpenPKG
> > within the Kolab Project.
> >
> > What about an IRC discussion in the near future?
> 
> Yes sure, as i recommended to mathieu one great tool for packaing issues 
> is http://trac.project-builder.org/

Do you what the differences are with the Build Service that is provided
by openSUSE?  Do you know any site that list the commonalities or the
differences?  They (project-builder and OBS (openSUSE Build Service)
seem to have a lot in common.  If there is not such a page, perhaps we
can come with such a list?

-- 
Richard


From issues at kolab.org  Wed Dec  9 14:51:12 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 09 Dec 2009 13:51:12 +0000
Subject: [Kolab-devel] [issue3991] Crash after creation of a subfolder,
	copying some mails to the folder and looking at the mail.
In-Reply-To: <1260366672.3.0.454338997285.issue3991@kolab.org>
Message-ID: <1260366672.3.0.454338997285.issue3991@kolab.org>


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

observed with Kontact e4 lenny of tag 20091204.1058385

Test:
1. Create a new subfolder of the inbox.
2. Copy a mail to the test folder.
3. Move a mail to the test folder.
4. Click on the folder and look at the mails.
  => Crash with signal 11.

----------
assignedto: allen
keyword: enterprise4, kde client
messages: 22759
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: critical
status: unread
title: Crash after creation of a subfolder, copying some mails to the folder and looking at the mail.

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


From martin.konold at erfrakon.de  Thu Dec 10 07:57:43 2009
From: martin.konold at erfrakon.de (Martin Konold)
Date: Thu, 10 Dec 2009 07:57:43 +0100
Subject: [Kolab-devel] Separating sources from OpenPKG packaging
In-Reply-To: <20091209075133.GA47405@xs4all.nl>
References: <20091208231529.53047dgndzthsohs@webmail.pardus.de>
	<20091209075133.GA47405@xs4all.nl>
Message-ID: <200912100757.44058.martin.konold@erfrakon.de>


Hi,

On Wednesday 09 December 2009 08:51:33 Richard Bos wrote:
> If you stay with your proposal, how would you move modules?
> I hope that you'll move them on the server, to leave the cvs
> history untouched.

According to my experience there is no project which is as volatile with 
regards to moving files around like Kolab CVS.

So I propose to be really really careful with not breaking too many things 
(Moving the stuff on the cvs server does break older checkouts while keeping 
the history...) or moving to git in the near future.

Regards,
-- martin


From wrobel at pardus.de  Thu Dec 10 09:14:50 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 10 Dec 2009 09:14:50 +0100
Subject: [Kolab-devel] Separating sources from OpenPKG packaging
In-Reply-To: <200912100757.44058.martin.konold@erfrakon.de>
References: <20091208231529.53047dgndzthsohs@webmail.pardus.de>
	<20091209075133.GA47405@xs4all.nl>
	<200912100757.44058.martin.konold@erfrakon.de>
Message-ID: <20091210091450.24225lqizxmrj74s@webmail.pardus.de>

Quoting Martin Konold <martin.konold at erfrakon.de>:

>
> Hi,
>
> On Wednesday 09 December 2009 08:51:33 Richard Bos wrote:
>> If you stay with your proposal, how would you move modules?
>> I hope that you'll move them on the server, to leave the cvs
>> history untouched.
>
> According to my experience there is no project which is as volatile with
> regards to moving files around like Kolab CVS.

This is however only a problem as we are using CVS.

>
> So I propose to be really really careful with not breaking too many things
> (Moving the stuff on the cvs server does break older checkouts while keeping
> the history...) or moving to git in the near future.

As far as I know we'll be switching to mercurial soon.

Cheers,

Gunnar

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



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

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

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

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

From wrobel at pardus.de  Thu Dec 10 09:25:36 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Thu, 10 Dec 2009 09:25:36 +0100
Subject: [Kolab-devel] Separating sources from OpenPKG packaging
In-Reply-To: <20091209075133.GA47405@xs4all.nl>
References: <20091208231529.53047dgndzthsohs@webmail.pardus.de>
	<20091209075133.GA47405@xs4all.nl>
Message-ID: <20091210092536.608231e7elltz0ys@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> On Tue, Dec 08, 2009 at 11:15:29PM +0100, Gunnar Wrobel wrote:
>> All I need in order to do this soon (once we released 2.2.3) would be
>> a decision how the structure should look like. I would propose to add
>> a new directory "src" in our "server" CVS module. So we would have
>>
>>   - server/src/perl-kolab
>>   - server/src/kolabd
>>   - server/src/kolab-webadmin
>>
>> These would be used to provide *.tar.gz packages that can be uploaded
>> to files.kolab.org.
>>
>> We'd keep the old
>>
>>   - server/perl-kolab
>>   - server/kolabd
>>   - server/kolab-webadmin
>>
>> but they'd just contain the OpenPKG RPM build machinery.
>>
>> In principle I don't consider this a big deal and would just do it
>> this way but I thought I'd ask to make sure nobody disagrees.
>
>
> So, actually what you want to do is to move the directories
>  server/kolabd/kolabd           to src/kolabd
>  server/kolab-admin/kolab-admin to src/kolab-admin
>  and
>  server/perl-kolab              to src/perl-kolab

Correct.

>
> I assume that the openpkg packaging stuff is located in
> server/kolabd and server/kolab-admin.  For perl-kolab it seems
> to be mixed.

Correct.

>
> Thinking Out Loud:
> Everything related to the server is located in the cvs root 'server',
> why should the above 3 mentioned modules be removed from there?
> Wouldn't it be possible to leave the current structure and store
> the openpkg stuff in a cvs module called openpkg?  Like:
> server/{kolabd, kolab-webadmin, perl-kolab}
> openpkg/{kolabd, kolab-webadmin, perl-kolab}
>
> server/openpkg/{kolabd, kolab-webadmin, perl-kolab}

I don't quite follow. If you look at the current directories in CVS  
HEAD then nearly all of them only contain OpenPKG related stuff. The  
build Makefile, the spec file, additional patches etc. They are all  
used to build an RPM from these components.

The three packages I mentioned differ from that structure as they  
contain source code. For all other packages source code is being  
downloaded as *.tar.{gz,bz2} from an external server.

So the goal would be to move the sources to a separate directory where  
we do the *.tar.gz packaging and upload to files.kolab.org.

The remaining directories server/{kolabd, kolab-webadmin, perl-kolab}  
would then only contain the build machinery in the same way the other  
packages do.

>
> If you stay with your proposal, how would you move modules?
> I hope that you'll move them on the server, to leave the cvs
> history untouched.

Probably also depends on when we could switch to mercurial. That would  
make such things easier.

Cheers,

Gunnar

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



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

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

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

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

From issues at kolab.org  Thu Dec 10 10:38:10 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 10 Dec 2009 09:38:10 +0000
Subject: [Kolab-devel] [issue3992] Print layout problem,
	if a url is to long (rt#5872)
In-Reply-To: <1260437890.96.0.589307228254.issue3992@kolab.org>
Message-ID: <1260437890.96.0.589307228254.issue3992@kolab.org>


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

Split from kolab/issue3908.
print layout problem if body contains a very long url (see testmail-url.mbox)

----------
assignedto: allen
files: testmail-url.mbox
keyword: enterprise35, kde client, kkc
messages: 22767
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Print layout problem, if a url is to long (rt#5872)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3992>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testmail-url.mbox
Type: application/mbox
Size: 4032 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091210/a0dd4b22/testmail-url.bin

From ml at radoeka.nl  Thu Dec 10 10:52:33 2009
From: ml at radoeka.nl (Richard Bos)
Date: Thu, 10 Dec 2009 10:52:33 +0100
Subject: [Kolab-devel] Separating sources from OpenPKG packaging
In-Reply-To: <20091210092536.608231e7elltz0ys@webmail.pardus.de>
References: <20091208231529.53047dgndzthsohs@webmail.pardus.de>
	<20091209075133.GA47405@xs4all.nl>
	<20091210092536.608231e7elltz0ys@webmail.pardus.de>
Message-ID: <200912101052.33489.ml@radoeka.nl>

Op donderdag 10 december 2009 09:25:36 schreef Gunnar Wrobel:
> I don't quite follow. If you look at the current directories in CVS  
> HEAD then nearly all of them only contain OpenPKG related stuff. The  
> build Makefile, the spec file, additional patches etc. They are all  
> used to build an RPM from these components.
>
> The three packages I mentioned differ from that structure as they  
> contain source code. For all other packages source code is being  
> downloaded as *.tar.{gz,bz2} from an external server.
>
> So the goal would be to move the sources to a separate directory where  
> we do the *.tar.gz packaging and upload to files.kolab.org.
>
> The remaining directories server/{kolabd, kolab-webadmin, perl-kolab}  
> would then only contain the build machinery in the same way the other  
> packages do.

Clear.  Moving the sources to the directory src, seems a good thing to do :)
Which actually means that in the future if someone does not deal with openpkg 
he or she does not need to check out the cvs module server, but only the 
module src.

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

From issues at kolab.org  Thu Dec 10 12:03:16 2009
From: issues at kolab.org (Bernhard Reiter)
Date: Thu, 10 Dec 2009 11:03:16 +0000
Subject: [Kolab-devel] [issue3993] Show if "vacation" in the general sieve
	script is active
In-Reply-To: <1260442996.54.0.504678639361.issue3993@kolab.org>
Message-ID: <1260442996.54.0.504678639361.issue3993@kolab.org>


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

I've figured that it would be cool if the vacation warning would also
show up, if my general sieve script just containts the sieve 
function "vacation". Of course the dialog should be different and explain to me 
that it is a general sieve script and possibly offer to jump in the sieve 
upload/download functionality.

I believe this would be a cool feature for E5 Kmail.
Ludwig, can you create an upstream issue report for this, if there is none?
(bugs.kde.org)

----------
assignedto: ludwig
keyword: enterprise5, kde client
messages: 22778
nosy: allen, bernhard, ludwig, till, vkrause
priority: minor bug
status: unread
title: Show if "vacation" in the general sieve script is active

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


From wrobel at pardus.de  Fri Dec 11 09:52:01 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 11 Dec 2009 09:52:01 +0100
Subject: [Kolab-devel] Fwd: Introducing OpenPKG 4.x
In-Reply-To: <886E32F6-F502-4390-9096-50CCDF4EC985@kdab.com>
References: <200912080808.11106.martin.konold@erfrakon.de>
	<886E32F6-F502-4390-9096-50CCDF4EC985@kdab.com>
Message-ID: <20091211095201.42712xr88n61hjy8@webmail.pardus.de>

Quoting Paul Adams <paul at kdab.com>:

> Hi Martin (et al),
>
> On 8 Dec 2009, at 07:08, Martin Konold wrote:
>> I therefore propose to prepare a decision with regards to using
>> OpenPKG within
>> the Kolab Project.
>
> Hasn't the decision been made for us?...

I think so, too. I always disliked OpenPKG from a technical  
perspective but I am convinced that the possibility to install the  
Kolab Server on the most common base distributions gave our solution  
additional value. So in that regard I did like it.

But it is of course inacceptable if everyone that installs the Kolab  
Server has to pay licensing fees. I'll try to call Thomas Lotterer  
about this but I think the original mail is already quite clear about  
it.

And in that case I would also say that the decision has been made for us.

>
> The new licensing model, at least just after the brief description in
> this email, sounds unfriendly towards Free Software.
>
> Either way, setting aside some time to discuss the future of Kolab
> packaging is not a bad idea.

I think we should start discussing the different available options on  
the list so that we get an overview on the different options including  
their pros and cons.

Cheers,

Gunnar

>
>
> All the best,
> Paul
>
> --
> Paul J. Adams | paul at kdab.com | Software Engineer
> Klar?lvdalens Datakonsult AB, a KDAB Group company
> Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - Qt Experts - Platform-independent software solutions
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



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

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

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

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

From alex at ap-consulting.co.uk  Fri Dec 11 10:57:14 2009
From: alex at ap-consulting.co.uk (Alex Potter)
Date: Fri, 11 Dec 2009 09:57:14 +0000
Subject: [Kolab-devel] Fwd: Introducing OpenPKG 4.x
In-Reply-To: <20091211095201.42712xr88n61hjy8@webmail.pardus.de>
References: <200912080808.11106.martin.konold@erfrakon.de>
	<886E32F6-F502-4390-9096-50CCDF4EC985@kdab.com>
	<20091211095201.42712xr88n61hjy8@webmail.pardus.de>
Message-ID: <200912110957.14858.alex@ap-consulting.co.uk>

On Friday 11 Dec 2009 08:52:01 Gunnar Wrobel wrote:
> I think we should start discussing the different available options on  
> the list so that we get an overview on the different options including  
> their pros and cons.
> 

Writing as the administrator of our family email system, I'd be very unhappy 
at a move away from the current licensing model for kolab.

Do you have any idea of the installed base, apart from the ones you support 
directly, of course?

Here, the systems are debian-based. My openpkg 'live' system is on ubuntu 
8.04, and I'm currently installing kolab on Debian squeeze using the native 
packages, so far without success.

Regards

Alex



From math.parent at gmail.com  Fri Dec 11 13:37:13 2009
From: math.parent at gmail.com (Mathieu Parent)
Date: Fri, 11 Dec 2009 13:37:13 +0100
Subject: [Kolab-devel] Fwd: Introducing OpenPKG 4.x
In-Reply-To: <200912110957.14858.alex@ap-consulting.co.uk>
References: <200912080808.11106.martin.konold@erfrakon.de>
	<886E32F6-F502-4390-9096-50CCDF4EC985@kdab.com>
	<20091211095201.42712xr88n61hjy8@webmail.pardus.de>
	<200912110957.14858.alex@ap-consulting.co.uk>
Message-ID: <960738410912110437l3e702d8csdaf75b23faf9af4c@mail.gmail.com>

Hi,


On Fri, Dec 11, 2009 at 10:57 AM, Alex Potter <alex at ap-consulting.co.uk> wrote:
> On Friday 11 Dec 2009 08:52:01 Gunnar Wrobel wrote:
>> I think we should start discussing the different available options on
>> the list so that we get an overview on the different options including
>> their pros and cons.
>>
>
> Writing as the administrator of our family email system, I'd be very unhappy
> at a move away from the current licensing model for kolab.

As I understand, the Kolab devs don't want to change the licensing
model of Kolab.

> Do you have any idea of the installed base, apart from the ones you support
> directly, of course?
>
> Here, the systems are debian-based. My openpkg 'live' system is on ubuntu
> 8.04, and I'm currently installing kolab on Debian squeeze using the native
> packages, so far without success.

For the Debian native package, report your problems as bugs
(bugs.debian.org) or ask on the mailing list pkg-kolab as you have
already done for other (resolved) problems. It didn't appeared that
you have "no success", so please report!


> Regards
>
> Alex


From wilde at intevation.de  Fri Dec 11 17:37:10 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Fri, 11 Dec 2009 17:37:10 +0100
Subject: [Kolab-devel] Brain Dump of the Week -- copied from /dev/null
Message-ID: <s7wd42lbh6x.fsf@intevation.de>

Hi *,

well, technically this ought to be a double issue, as there was no BDotW
last week already...  Unfortunately my brain refuses to spill out
anything worth reporting right now.

This is mainly caused by the fact that I was on holidays last week and
as Thomas was ill last week and still is up to today.  This week I was
mainly busy working on an offer for an possible customer[1] and keeping
everyone happy at Intevation[2].

So the only people working hard for the increasingly unlikely
2.2.3 release are Gunnar, Kalle (khruskowski) -- big thanks to them!

All in all you will have to stay tuned until next week, for a hopefully
more interesting BDotW...  Anyway in the big picture[3] it shouldn't
matter to much.  ;-)

cheers
and keep on hacking!
sascha

[1]  which included Kolab-Server, so this week was not all the way lost
     from the view of the Kolab project...  :-)
[2]  As some of you might know Thomas and I are the system
     administrators at Intevation as well as server developers...
[3]  http://blogs.discovermagazine.com/badastronomy/2009/12/08/hubble-digs-deep-to-see-baby-galaxies/
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer:   Frank Koormann,  Bernhard Reiter,  Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091211/678d720f/attachment.bin

From math.parent at gmail.com  Fri Dec 11 17:54:12 2009
From: math.parent at gmail.com (Mathieu Parent)
Date: Fri, 11 Dec 2009 17:54:12 +0100
Subject: [Kolab-devel] Fwd: Introducing OpenPKG 4.x
In-Reply-To: <20091211095201.42712xr88n61hjy8@webmail.pardus.de>
References: <200912080808.11106.martin.konold@erfrakon.de>
	<886E32F6-F502-4390-9096-50CCDF4EC985@kdab.com>
	<20091211095201.42712xr88n61hjy8@webmail.pardus.de>
Message-ID: <960738410912110854t175242acp579967601dd89f1d@mail.gmail.com>

On Fri, Dec 11, 2009 at 9:52 AM, Gunnar Wrobel <wrobel at pardus.de> wrote:
...
> I think we should start discussing the different available options on the
> list so that we get an overview on the different options including their
> pros and cons.

Let's do it!

I have setup a page on the wiki:
<https://wiki.kolab.org/index.php/Developer_packaging_platform_comparison>

Currently, two solutions have been mentionned:
- OpenSUSE Build service
- Project Builder

Please update the wiki page or discuss here!

>
> Cheers,
>
> Gunnar

Mathieu Parent


From ml at radoeka.nl  Fri Dec 11 21:35:27 2009
From: ml at radoeka.nl (Richard Bos)
Date: Fri, 11 Dec 2009 21:35:27 +0100
Subject: [Kolab-devel] Brain Dump of the Week -- copied from /dev/null
In-Reply-To: <s7wd42lbh6x.fsf@intevation.de>
References: <s7wd42lbh6x.fsf@intevation.de>
Message-ID: <200912112135.27950.ml@radoeka.nl>

Sascha,

Op vrijdag 11 december 2009 17:37:10 schreef Sascha Wilde:
> So the only people working hard for the increasingly unlikely 2.2.3

do you mean not in time, not this year or not at all?  If the latter what is 
the plan (release wise)?

-- 
Richard


From thomas at btspuhler.com  Sat Dec 12 20:09:58 2009
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sat, 12 Dec 2009 12:09:58 -0700
Subject: [Kolab-devel] gunnar: server/perl-kolab MANIFEST, 1.9,
	1.10 Makefile.PL, 1.17, 1.18
In-Reply-To: <200912042111.46642.ml@radoeka.nl>
References: <20091204112321.CE25D60057F@lists.intevation.de>
	<200912042048.00069.ml@radoeka.nl>
	<200912042111.46642.ml@radoeka.nl>
Message-ID: <200912121209.58876.thomas@btspuhler.com>

On Friday 04 December 2009 01:11:46 pm Richard Bos wrote:
> Op vrijdag 04 december 2009 20:47:59 schreef Richard Bos:
> > It goes wrong file executing 'perl Makefile.PL'.  I added a check to it,
> > being:
> > sub MY::postamble {
> >     if (-e "../Base.mk")
> >     {
> >         copy("../Base.mk", "./") or die "Could not copy ../Base.mk";
> >     } else {
> >         die "../Base.mk does not exist";  <<<<<<<<<<
> >     }
> >     my $add = "include Base.mk
> >
> > Now when I run 'perl Makefile.PL', it fails with:
> > perl-kolab-2.2.2.90_cvs20091204> perl Makefile.PL
> > ../Base.mk does not exist at Makefile.PL line 103.
>
> When I use the original Makefile.PL and remove "include Base.mk", 'make
> install' complains:
>
> chmod 755 /usr/src/packages/BUILD/perl-
> kolab-2.2.2.90_cvs20091204/ME//kolab/sbin/*
> /bin/sh: -q: invalid option
> I think it fails at:
> ifeq \"x\$(PLATTAG)\" \"x\"
>         PLATTAG = \$(shell /usr/bin/rpm -q --qf=\"%{ARCH}-%{OS}\"
> openpkg)-\$(HOME:/%=%)
> endif
>
> Ain't possible to use a perl function for it:
>  perl -V
> Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
>   Platform:
>     osname=linux, osvers=2.6.27, archname=i586-linux-thread-multi
> ........
>
> Perhaps something like:
> perl-kolab> perl -V:vendorlib
> vendorlib='/usr/lib/perl5/vendor_perl/5.10.0';
>
> /perl-kolab> perl -V:sitelib
> sitelib='/usr/lib/perl5/site_perl/5.10.0';
>
> or
> 5.10.0> perl -V:myarchname
> myarchname='i686-linux';
>
> /usr/lib/perl5/5.10.0> perl -V:archname
> archname='i586-linux-thread-multi';
>
> Don't know what you're looking for.  More info in 'perldoc perltoc'
What is the status on this. I just tried to build it on Mandriva and get 
Makefile:948: Base.mk: No such file or directory
make: *** No rule to make target `Base.mk'.  Stop.
-- 
Thomas


From ml at radoeka.nl  Sat Dec 12 20:47:39 2009
From: ml at radoeka.nl (Richard Bos)
Date: Sat, 12 Dec 2009 20:47:39 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab MANIFEST, 1.9,
	1.10 Makefile.PL, 1.17, 1.18
In-Reply-To: <200912121209.58876.thomas@btspuhler.com>
References: <20091204112321.CE25D60057F@lists.intevation.de>
	<200912042111.46642.ml@radoeka.nl>
	<200912121209.58876.thomas@btspuhler.com>
Message-ID: <200912122047.39235.ml@radoeka.nl>

Op zaterdag 12 december 2009 20:09:58 schreef Thomas Spuhler:
> > Don't know what you're looking for.  More info in 'perldoc perltoc'
> 
> What is the status on this. I just tried to build it on Mandriva and get 
> Makefile:948: Base.mk: No such file or directory
> make: *** No rule to make target `Base.mk'.  Stop.

This should help: https://issues.kolab.org/issue3990
if you use this https://issues.kolab.org/file1290/Makefile.PL.patch patch, 
your build will work again :)

-- 
Richard


From thomas at btspuhler.com  Sat Dec 12 22:40:18 2009
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sat, 12 Dec 2009 14:40:18 -0700
Subject: [Kolab-devel] gunnar: server/perl-kolab MANIFEST, 1.9,
	1.10 Makefile.PL, 1.17, 1.18
In-Reply-To: <200912122047.39235.ml@radoeka.nl>
References: <20091204112321.CE25D60057F@lists.intevation.de>
	<200912121209.58876.thomas@btspuhler.com>
	<200912122047.39235.ml@radoeka.nl>
Message-ID: <200912121440.18920.thomas@btspuhler.com>

On Saturday 12 December 2009 12:47:39 pm Richard Bos wrote:
> Op zaterdag 12 december 2009 20:09:58 schreef Thomas Spuhler:
> > > Don't know what you're looking for.  More info in 'perldoc perltoc'
> >
> > What is the status on this. I just tried to build it on Mandriva and get
> > Makefile:948: Base.mk: No such file or directory
> > make: *** No rule to make target `Base.mk'.  Stop.
>
> This should help: https://issues.kolab.org/issue3990
> if you use this https://issues.kolab.org/file1290/Makefile.PL.patch patch,
> your build will work again :)
Yes, it does build. Thanks

-- 
Thomas


From tr at erdfunkstelle.de  Sat Dec 12 22:45:11 2009
From: tr at erdfunkstelle.de (Thomas Reitelbach)
Date: Sat, 12 Dec 2009 22:45:11 +0100
Subject: [Kolab-devel] Kontact for Windows - new Beta?
In-Reply-To: <200912072108.49200.tr@erdfunkstelle.de>
References: <200912072108.49200.tr@erdfunkstelle.de>
Message-ID: <200912122245.11648.tr@erdfunkstelle.de>

Am Montag, 7. Dezember 2009 21:08:49 schrieb Thomas Reitelbach:
> Hello developers list,
> 
> I regularly visit the beta-page for kontact for windows, hoping that there
> will be an updated beta package for download available.
> The last beta (2009-06) I tested had a bug that was critical to me
>  (timezone handling in the calendar) and since june I hope to get a new
>  beta for testing.
> 
> Would it be possible to create a new beta for download?
> Or are there instructions for building kontact for windows myself? I
>  already managed to build regular KDE packages for windows, but didn't try
>  kdepim yet.
> 
> Any help would be very appreciated :-)
> I'm willing to debug and fill bug reports where I'm able to!

Hi Kolab-Developers,

as I did not get a reply I guess this is the wrong list for such questions. 
Can you tell me where I can ask this question instead? I'm sorry to bother you 
again.

Cheers
Thomas


From thomas at btspuhler.com  Sun Dec 13 01:05:42 2009
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sat, 12 Dec 2009 17:05:42 -0700
Subject: [Kolab-devel] gunnar: server/perl-kolab MANIFEST, 1.9,
	1.10 Makefile.PL, 1.17, 1.18
In-Reply-To: <200912121440.18920.thomas@btspuhler.com>
References: <20091204112321.CE25D60057F@lists.intevation.de>
	<200912122047.39235.ml@radoeka.nl>
	<200912121440.18920.thomas@btspuhler.com>
Message-ID: <200912121705.42634.thomas@btspuhler.com>

On Saturday 12 December 2009 02:40:18 pm Thomas Spuhler wrote:
> On Saturday 12 December 2009 12:47:39 pm Richard Bos wrote:
> > Op zaterdag 12 december 2009 20:09:58 schreef Thomas Spuhler:
> > > > Don't know what you're looking for.  More info in 'perldoc perltoc'
> > >
> > > What is the status on this. I just tried to build it on Mandriva and
> > > get Makefile:948: Base.mk: No such file or directory
> > > make: *** No rule to make target `Base.mk'.  Stop.
> >
> > This should help: https://issues.kolab.org/issue3990
> > if you use this https://issues.kolab.org/file1290/Makefile.PL.patch
> > patch, your build will work again :)
>
> Yes, it does build. Thanks
But it doesn't install: 

error: Failed dependencies:
        pear(smarty/Smarty.class.php) is needed by kolab-
webadmin-2.2.2-1mdv2010.0.noarch

rpm -q -l php-smarty gives:
/usr/share/php/smarty/Smarty.class.php

-- 
Thomas


From ml at radoeka.nl  Sun Dec 13 10:42:27 2009
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 13 Dec 2009 10:42:27 +0100
Subject: [Kolab-devel] gunnar: server/perl-kolab MANIFEST, 1.9,
	1.10 Makefile.PL, 1.17, 1.18
In-Reply-To: <200912121705.42634.thomas@btspuhler.com>
References: <20091204112321.CE25D60057F@lists.intevation.de>
	<200912121440.18920.thomas@btspuhler.com>
	<200912121705.42634.thomas@btspuhler.com>
Message-ID: <200912131042.28297.ml@radoeka.nl>

Op zondag 13 december 2009 01:05:42 schreef Thomas Spuhler:
> On Saturday 12 December 2009 02:40:18 pm Thomas Spuhler wrote:
> > On Saturday 12 December 2009 12:47:39 pm Richard Bos wrote:
> > > Op zaterdag 12 december 2009 20:09:58 schreef Thomas Spuhler:
> > > > > Don't know what you're looking for.  More info in 'perldoc perltoc'
> > > >
> > > > What is the status on this. I just tried to build it on Mandriva and
> > > > get Makefile:948: Base.mk: No such file or directory
> > > > make: *** No rule to make target `Base.mk'.  Stop.
> > >
> > > This should help: https://issues.kolab.org/issue3990
> > > if you use this https://issues.kolab.org/file1290/Makefile.PL.patch
> > > patch, your build will work again :)
> >
> > Yes, it does build. Thanks
> 
> But it doesn't install:
> 
> error: Failed dependencies:
>         pear(smarty/Smarty.class.php) is needed by kolab-
> webadmin-2.2.2-1mdv2010.0.noarch
> 
> rpm -q -l php-smarty gives:
> /usr/share/php/smarty/Smarty.class.php

What has perl-kolab to do with it?  Is perl-kolab removing 
smarty/Smarty.class.php

What do you mean it does not install?  Is "it" an rpm?  I assume that "make 
install DESTDIR=$PWD/TEST" works for you, isn't it?

-- 
Richard


From issues at kolab.org  Mon Dec 14 11:38:50 2009
From: issues at kolab.org (Karl-Heinz Ruskowski)
Date: Mon, 14 Dec 2009 10:38:50 +0000
Subject: [Kolab-devel] [issue3995] Horde Login fails,
	'Error: IMAP Authentication cancelled'
In-Reply-To: <1260787130.01.0.899337780206.issue3995@kolab.org>
Message-ID: <1260787130.01.0.899337780206.issue3995@kolab.org>


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

Horde Login fails with kolab_2_2_branch. Error message in horde.log looks like this:

Dec 14 11:28:52 HORDE [error] [nag] IMAP error. Server: ozomatli.aztec. Error:
IMAP Authentication cancelled [pid 26921 on line 281 of
"/kolab/var/kolab/www/client/nag/lib/Nag.php"]
Dec 14 11:28:52 HORDE [error] [nag] IMAP error. Server: ozomatli.aztec. Error:
IMAP Authentication cancelled [pid 26921 on line 281 of
"/kolab/var/kolab/www/client/nag/lib/Nag.php"]
Dec 14 11:28:52 HORDE [debug] [nag] Hook _prefs_change_hook_display_tasklists in
application horde not called. [pid 26921 on line 1683 of
"/kolab/var/kolab/www/client/lib/Horde.php"]

----------
assignedto: wrobel
keyword: release, server
messages: 22826
nosy: khruskowski, thomas, wilde, wrobel
priority: critical
status: unread
title: Horde Login fails, 'Error: IMAP Authentication cancelled'

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


From wilde at intevation.de  Mon Dec 14 12:56:08 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Mon, 14 Dec 2009 12:56:08 +0100
Subject: [Kolab-devel] Brain Dump of the Week -- copied from /dev/null
In-Reply-To: <200912112135.27950.ml@radoeka.nl> (Richard Bos's message of
	"Fri, 11 Dec 2009 21:35:27 +0100")
References: <s7wd42lbh6x.fsf@intevation.de> <200912112135.27950.ml@radoeka.nl>
Message-ID: <s7wy6l5ydk7.fsf@intevation.de>

Richard Bos <ml at radoeka.nl> writes:

> Sascha,
>
> Op vrijdag 11 december 2009 17:37:10 schreef Sascha Wilde:
>> So the only people working hard for the increasingly unlikely 2.2.3
>
> do you mean not in time, not this year or not at all?  If the latter what is 
> the plan (release wise)?

I meant not in time (i.e. not this month) -- but Thomas just told me,
that he still believes in releasing 2.2.3 this year, so I might have
been to pessimistic!  :)

cheers
sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer:   Frank Koormann,  Bernhard Reiter,  Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091214/af383d52/attachment.bin

From issues at kolab.org  Mon Dec 14 14:46:38 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 14 Dec 2009 13:46:38 +0000
Subject: [Kolab-devel] [issue3996] The name of a to a task attached mail
	with utf-8 symbols	in the subject is confusing
In-Reply-To: <1260798398.67.0.447862671265.issue3996@kolab.org>
Message-ID: <1260798398.67.0.447862671265.issue3996@kolab.org>


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

tested with Kontact e35 20091211.1061424-kk1

Test:
1. Send a mail to yourself with an ? (Euro) symbol in the subject and sync.
2. Start to create a task.
3. D'n'D the Euro mail to the attachment field of the task and choose copy to.
4. Look at the name of the attached mail.
=> The name of the attached mail is confusing

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 22837
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: The name of a to a task attached mail with utf-8 symbols in the subject is confusing

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


From wilde at intevation.de  Mon Dec 14 16:27:38 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Mon, 14 Dec 2009 16:27:38 +0100
Subject: [Kolab-devel] Fwd: Introducing OpenPKG 4.x
In-Reply-To: <960738410912110854t175242acp579967601dd89f1d@mail.gmail.com>
	(Mathieu Parent's message of "Fri, 11 Dec 2009 17:54:12 +0100")
References: <200912080808.11106.martin.konold@erfrakon.de>
	<886E32F6-F502-4390-9096-50CCDF4EC985@kdab.com>
	<20091211095201.42712xr88n61hjy8@webmail.pardus.de>
	<960738410912110854t175242acp579967601dd89f1d@mail.gmail.com>
Message-ID: <s7weimxtw2d.fsf@intevation.de>

Mathieu Parent <math.parent at gmail.com> writes:
> On Fri, Dec 11, 2009 at 9:52 AM, Gunnar Wrobel <wrobel at pardus.de> wrote:
> ...
>> I think we should start discussing the different available options on the
>> list so that we get an overview on the different options including their
>> pros and cons.
>
> Let's do it!
>
> I have setup a page on the wiki:
> <https://wiki.kolab.org/index.php/Developer_packaging_platform_comparison>
>
> Currently, two solutions have been mentionned:
> - OpenSUSE Build service
> - Project Builder

FWIW, I'm a big fan[1] of pkgsrc[2] (the application pool of netbsd).  It has
advantages similar to OpenPKG in being very portable, allowing binary
and source[3] distribution and providing a defined environment with all
applications included we would need to build upon.

Pros:
- Free Software (a _must_)
- Highly portable
- Platform- (and distribution-) independent
- Security maintained
- Regular releases (four times a year)
- IMHO very nice tools and a good design[4]
- Good documentation for package builders (and of the whole system)
- Can generate rpm from pkgsrc packages.  This needs further
  evaluation but might be interesting at some point.

Cons:
- Maybe a bit to many releases (I'm currently not sure how fast we would
  have to follow to get security updates -- this would need further
  evaluation)
- Related: No policies on guaranteed maintained lifetime for releases
- Does things a bit differently, when you are used to package systems
  common on GNU/Linux systems.[5]
- No commercial support available from upstream[6]

cheers
sascha

[1]  We have not yet decided (or even in depth discussed) this problem
     in the Server development team at Intevation, so my personal views
     in this mail are by no means an official statement by Intevation.
[2]  http://www.netbsd.org/docs/software/packages.html
[3]  As tar-balls!  Which IMO would be an improvement.
[4]  At least when you like the BSD way of doing things
[5]  IMO no real con, but it has to be accepted that people need to learn a
     few new commands and concepts, while OpenPKG was some sort of RPM.
[6]  But there are various commercial NetBSD (and therefor pkgsrc)
     consultants and developers listed on netbsd.org
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer:   Frank Koormann,  Bernhard Reiter,  Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091214/6d900ce2/attachment.bin

From wrobel at pardus.de  Tue Dec 15 10:17:11 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 15 Dec 2009 10:17:11 +0100
Subject: [Kolab-devel] Kontact for Windows - new Beta?
In-Reply-To: <200912122245.11648.tr@erdfunkstelle.de>
References: <200912072108.49200.tr@erdfunkstelle.de>
	<200912122245.11648.tr@erdfunkstelle.de>
Message-ID: <20091215101711.105438le643mouu0@webmail.pardus.de>

Quoting Thomas Reitelbach <tr at erdfunkstelle.de>:

> Am Montag, 7. Dezember 2009 21:08:49 schrieb Thomas Reitelbach:
>> Hello developers list,
>>
>> I regularly visit the beta-page for kontact for windows, hoping that there
>> will be an updated beta package for download available.
>> The last beta (2009-06) I tested had a bug that was critical to me
>>  (timezone handling in the calendar) and since june I hope to get a new
>>  beta for testing.
>>
>> Would it be possible to create a new beta for download?
>> Or are there instructions for building kontact for windows myself? I
>>  already managed to build regular KDE packages for windows, but didn't try
>>  kdepim yet.
>>
>> Any help would be very appreciated :-)
>> I'm willing to debug and fill bug reports where I'm able to!
>
> Hi Kolab-Developers,
>
> as I did not get a reply I guess this is the wrong list for such questions.
> Can you tell me where I can ask this question instead? I'm sorry to  
> bother you
> again.

This is the right list. That has been no response so far might have  
many different reasons though. I would assume that there is no fixed  
schedule yet. But I added Bernhard and Till on cc. They might have an  
idea.

Cheers,

Gunnar

>
> Cheers
> Thomas
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



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

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



From issues at kolab.org  Tue Dec 15 14:24:27 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 15 Dec 2009 13:24:27 +0000
Subject: [Kolab-devel] [issue3997] Wrong status information of a deleted
	event.
In-Reply-To: <1260883467.77.0.772404306877.issue3997@kolab.org>
Message-ID: <1260883467.77.0.772404306877.issue3997@kolab.org>


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

tested with Kontact e35 20091211.1061424-kk1

Test:
1. A sends an invitation to B and C.
2. C accepts the event.
3. B rejects the event.
4. A enters the update mails into his calendar.
5. A changes the time of the event.
6. B rejects again.
(I'm not sure, if B should need to reject again, because he had already rejected
the event, anyway...)
7. C enters the change into his calendar.
8. A deletes the test event.
9. B can remove the event from his calendar, but no event was in his calendar.
10.C gets a update mail with: This invitation was rejected.
(German: Diese Einladung wurde abgelehnt)
   He didn't reject the invitation, A deleted the event.
This seems wrong to me.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 22861
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Wrong status information of a deleted event.

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


From issues at kolab.org  Tue Dec 15 14:40:14 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 15 Dec 2009 13:40:14 +0000
Subject: [Kolab-devel] [issue3998] The organizor changes are wrong in an
	update mail sent	after accepting a counter proposal
In-Reply-To: <1260884414.9.0.318685957131.issue3998@kolab.org>
Message-ID: <1260884414.9.0.318685957131.issue3998@kolab.org>


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

tested with Kontact e35 20091211.1061424-kk1

Test:
1. A invites B and C to an event.
2. C accepts.
3. B makes a counter proposal: one hour later.
4. A enters C's update into his calendar.
5. A accepts B's counter proposal and sends the update mail to the attendees.
=> C gets an update mail, which says that his status is changed to needs action.
   (Althrough he has already accepted the event)
=> B gets an update mail telling him that the title of the event had been
changed and all attendees had been added.
  (But the title of the event didn't changed.)

I think the problem is that B saved a "Counter proposal:" event in his calendar
and reuses it for the test event.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 22862
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: The organizor changes are wrong in an update mail sent after accepting a counter proposal

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


From issues at kolab.org  Tue Dec 15 14:46:58 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 15 Dec 2009 13:46:58 +0000
Subject: [Kolab-devel] [issue3999] Kontact sometimes changes from mail part
	to the calendar	part.
In-Reply-To: <1260884818.47.0.752685574876.issue3999@kolab.org>
Message-ID: <1260884818.47.0.752685574876.issue3999@kolab.org>


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

tested with Kontact e35 20091211.1061424-kk1

Test:
1. A sends an invitation to B.
2. B starts his kontact in mail part, syncs and accepts the invitation.
=> B's kontact jumps to the calendar part.
The user is confused by this unwanted switch to the calendar part.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 22863
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Kontact sometimes changes from mail part to the calendar part.

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


From issues at kolab.org  Tue Dec 15 15:03:20 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 15 Dec 2009 14:03:20 +0000
Subject: [Kolab-devel] [issue4000] A user rejects a delegation,
	the delegator cannot react on this.
In-Reply-To: <1260885800.19.0.177294152986.issue4000@kolab.org>
Message-ID: <1260885800.19.0.177294152986.issue4000@kolab.org>


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

tested with Kontact e35 20091211.1061424-kk1

Test:
1. A invites B to an event.
2. B delegates the event to C.(And wants to stay informed about this event.)
3. C rejects the event.
4. A enters the updates into his calendar.
5. B gets a mail that he needs to react on the event, but no actions are shown.
He can only enter the event into his calendar.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 22864
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: A user rejects a delegation, the delegator cannot react on this.

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


From issues at kolab.org  Tue Dec 15 15:54:28 2009
From: issues at kolab.org (Heiner)
Date: Tue, 15 Dec 2009 14:54:28 +0000
Subject: [Kolab-devel] [issue4001] synchronisation of multiple calendars
In-Reply-To: <1260888868.69.0.73812359077.issue4001@kolab.org>
Message-ID: <1260888868.69.0.73812359077.issue4001@kolab.org>


New submission from Heiner <mephisto at gmx.net>:

I have written a patch against kronolith in current kolab 2.2.2 server that
allows users to synchronise several calendars with SyncML.
The patch applies to /kolab/var/kolab/www/client/kronolith and modifies
config/prefs.php, lib/prefs.php and lib/api.php.
.diff-files are contained in the attached file
kolab_2.2.2_sync_multiple_calendars_diff.tar.gz.
I have submitted the patch to the horde bug tracker already, see
http://bugs.horde.org/ticket/8734

Best regards
Heiner

----------
files: kolab_2.2.2_sync_multiple_calendars_diff.tar.gz
messages: 22867
nosy: jaywalker
priority: feature
status: unread
title: synchronisation of multiple calendars

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4001>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kolab_2.2.2_sync_multiple_calendars_diff.tar.gz
Type: application/gzip
Size: 2615 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091215/dc46e7a9/kolab_2.2.2_sync_multiple_calendars_diff.tar.bin

From wrobel at pardus.de  Tue Dec 15 16:03:51 2009
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 15 Dec 2009 16:03:51 +0100
Subject: [Kolab-devel] Fwd: Introducing OpenPKG 4.x
In-Reply-To: <960738410912110854t175242acp579967601dd89f1d@mail.gmail.com>
References: <200912080808.11106.martin.konold@erfrakon.de>
	<886E32F6-F502-4390-9096-50CCDF4EC985@kdab.com>
	<20091211095201.42712xr88n61hjy8@webmail.pardus.de>
	<960738410912110854t175242acp579967601dd89f1d@mail.gmail.com>
Message-ID: <20091215160351.113831azuj9vbc6c@webmail.pardus.de>

Hi Mathieu,

this is going to be a long mail. Summary at the bottom :)

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

> On Fri, Dec 11, 2009 at 9:52 AM, Gunnar Wrobel <wrobel at pardus.de> wrote:
> ...
>> I think we should start discussing the different available options on the
>> list so that we get an overview on the different options including their
>> pros and cons.
>
> Let's do it!
>
> I have setup a page on the wiki:
> <https://wiki.kolab.org/index.php/Developer_packaging_platform_comparison>
>

Thanks!!!

I added a short summary on top and the licensing information from
the recent mail from OpenPKG to clarify why we consider changing
the distribution.

I did actually try to call OpenPKG twice just to get some
personal feedback from them but they seem to be in holiday
already. They don't offer a way to leave them any messages. I
guess I could mail them but I think the letter Martin Konold
forwarded was already clear enough. I just would have liked to
discuss it in person.

To me the move away from OpenPKG seems to be unavoidable now.

I would like to reprint the requirements you added to the wiki
page:

  Requirements

     * MUST be FOSS

     * MUST be available without charging clients

     * MUST cover major Linux distributions (see on distrowatch or
       Wikipedia) : Ubuntu, Fedora, openSUSE, Debian, mandriva,
       ...

     * MAY include a build service

     * MAY include automated tests

I think they are complete. Does anyone have something to add?

> Currently, two solutions have been mentionned:
> - OpenSUSE Build service
> - Project Builder

I'd like to split the "solutions" part somewhat further.

You listed two build services as possible successors to
OpenPKG. The outcome of these build services would be Kolab
Server images/builds for several different distributions. This is
a worthy goal and I believe it would help with some of the
problems we are currently having. It should be a part of our
strategy.

But I say "a part" as these build services will yield different
flavors of the Kolab Server. Each distribution specific build
could have its unique problems. If we would declare such a build
service as successor to OpenPKG then this would mean that we need
to test the resulting builds for each distribution. And that was
a central part of the quality control strategy: Just testing a
*single* distribution which customers can install on any base
distribution.

Testing is a limitation for us. The guys at Intevation are doing
a tremendous job concerning the quality of the server. As this
requires significant man power I really don't see how we could
extend that effort beyond a single distribution.

Back to the build services: We could of course use such a build
service but restrict testing to a single distribution built by
the service. This is in fact what I'd like us to do. But that
means that the original question remains the same: Which
distribution will we test instead of OpenPKG? Which distribution
gets our commercial support?

This is the primary question to me.

I do see two broad categories into which the solution might fall:

  1) Source based distributions (OpenPKG, pkgsrc, Gentoo, ...)
  2) Binary distributions (Ubuntu, Fedora, Suse, Debian, ...)

Source based distributions have the great advantage that we test
only a single distribution. Nevertheless the user can install
this system on many platforms. Most of the source based systems
support many variants. Of course this has a major drawback: While
you can install on many platforms you still install a new
distribution within the one you are used to which means to have
to learn the OpenPKG toolset.

A binary distribution would have the advantage that everyone used
to that distribution would feel at home immediately. The
disadvantage would be that we remove support for platforms we
have been supporting so far.

As much as I dislike OpenPKG I have always considered the choice
of a source based distribution to be a good one. Of course people
were unhappy with using the OpenPKG toolset rather than the one
provided by their favored distribution. This has fostered several
native ports and expressed a certain disagreement with the
OpenPKG choice. But my impression was also that there are many,
many people which are happy with the simplicity and robustness of
the Kolab server. Using OpenPKG has allowed us to provide a
consistent and high quality over many platforms.

I'm absolutely convinced that we should not leave users behind by
removing support for platforms we supported before. Using a
binary distribution as the base we support for the Kolab Server
is no option to me.

Back to the build services: Assuming we choose the distribution
we want to support then I see no reason why we should not use one
of the build systems you mentioned. The OpenSUSE build system
would of course only work if it supports the distribution we
chose. The project builder seems more generic.

The build service would hopefully reduce the amount of duplicated
work necessary to build the Kolab server on the different
distributions. All the required packaging information could
probably be centralized in one repository.

It should also help us to improve the quality of the native ports
as this is one problem we currently see: A user that wants to
install Kolab might start to try with a native port. These are
usually maintained by less people than the OpenPKG variant and so
the chances for problems are slightly higher. If the user hits a
problem he might have difficulties getting support from the
mailing lists. I know how often I have to say that I don't know
what the state of a specific native port actually is and how the
problem might be solved.
I would hope that using a build service helps indicating early
that a commit might cause problems on one of the distributions
supported by the build service. It would improve my awareness of
the state of the native ports which would be a good thing.

On top of the supported distribution and an optional automatic
build system I see automated testing. We should investigate if it
would be possible to use a testing framework that allows testing
the different Kolab Server builds equally well.

This would help us in development as problems might be discovered
early. It would also reduce our testing effort as some checks are
performed automatically. In addition it would also help the
quality of the native ports.

Summary
=======

I believe the primary focus of the discussion is the quality of
the Kolab Server. To keep the standard high we absolutely MUST

  - select a single distribution that will be tested and supported
    by the Kolab consortium

We SHOULD

  - find a build service that makes building the Kolab Server on
    different distributions easier and helps dissolving the
    current barrier between Kolab/OpenPKG and the native ports.

  - investigate automatic testing further to reduce the effort
    required for testing, to improve development and to help the
    native ports.

Cheers,

Gunnar


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

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

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

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

From bernhard at intevation.de  Wed Dec 16 10:04:55 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 16 Dec 2009 10:04:55 +0100
Subject: [Kolab-devel] Kontact for Windows - new Beta?
In-Reply-To: <20091215101711.105438le643mouu0@webmail.pardus.de>
References: <200912072108.49200.tr@erdfunkstelle.de>
	<200912122245.11648.tr@erdfunkstelle.de>
	<20091215101711.105438le643mouu0@webmail.pardus.de>
Message-ID: <200912161005.00547.bernhard@intevation.de>

Hi Thomas,

Am Dienstag, 15. Dezember 2009 10:17:11 schrieb Gunnar Wrobel:
> > Am Montag, 7. Dezember 2009 21:08:49 schrieb Thomas Reitelbach:
> >> I regularly visit the beta-page for kontact for windows, hoping that
> >> there will be an updated beta package for download available.
> >> The last beta (2009-06) I tested had a bug that was critical to me
> >> ?(timezone handling in the calendar) and since june I hope to get a new
> >> ?beta for testing.
> >>
> >> Would it be possible to create a new beta for download?

our plan is to publish one new beta from the e4 branch within the next weeks.
We had several snapshot cycles to fix the timezone issue
and sooner or later we will have found and fixed all defects in that area.

Note that this upcoming enterprise4 beta will most likely be the last beta 
from the enterprise4 branch. We will soon release alphas of the enterprise5 
(e5) branch and then focus on this branch and stabilise it as fast as we can.

> >> Or are there instructions for building kontact for windows myself? I
> >> ?already managed to build regular KDE packages for windows, but didn't
> >> try kdepim yet.

techbase.kde.org and the kde-windows mailinglist are places where you can get 
help to build Kontact. To build the enterprise4 version you would need you 
the enterprise4 svn branches, for which are are targets in the current 
emerge.

Best,
Bernhard
-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091216/ae5d7272/attachment.bin

From wilde at intevation.de  Wed Dec 16 17:02:50 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Wed, 16 Dec 2009 17:02:50 +0100
Subject: [Kolab-devel] List of issues for Kolab Server 2.2.3
In-Reply-To: <20091204093510.98433309d2m3gesk@webmail.pardus.de> (Gunnar
	Wrobel's message of "Fri, 04 Dec 2009 09:35:10 +0100")
References: <20091020172924.577027525.thomas@intevation.de>
	<20091116232903.184470z9qm8t1cg8@webmail.pardus.de>
	<20091124000646.133563d7ga1eg680@webmail.pardus.de>
	<20091124112336.627744926.thomas@intevation.de>
	<20091124210623.10962hqtw9tktscg@webmail.pardus.de>
	<20091125091114.022422160.thomas@intevation.de>
	<20091204093510.98433309d2m3gesk@webmail.pardus.de>
Message-ID: <s7w3a3aoqj9.fsf@intevation.de>

An embedded and charset-unspecified text was scrubbed...
Name: TODO
Url: http://kolab.org/pipermail/kolab-devel/attachments/20091216/2cfa16d2/TODO.txt
-------------- next part --------------

cheers
sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer:   Frank Koormann,  Bernhard Reiter,  Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091216/2cfa16d2/attachment.bin

From issues at kolab.org  Thu Dec 17 14:13:35 2009
From: issues at kolab.org (Richard Bos)
Date: Thu, 17 Dec 2009 13:13:35 +0000
Subject: [Kolab-devel] [issue4002] Incorrect value for email_domain in
	freebusy/config.php
In-Reply-To: <1261055615.05.0.879909383335.issue4002@kolab.org>
Message-ID: <1261055615.05.0.879909383335.issue4002@kolab.org>


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

I diffed the config files of a running kolab configuration with the config files
that I get with current (cvs) kolab.

There is an unexpected diff for the freebusy configuration file:

I used the email domain "mydomain.com", but the hostname "linux-geis.host.nl" is
used...

(- is installed and running kolab, + is from current (cvs) kolab)
srv/www/htdocs/freebusy/config.php:
/* What is our default mail domain? This is used if any users do not have
 * '@domain' specified after their username as part of their email address.
 */
-$conf['fb']['email_domain'] = 'mydomain.com';
+$conf['fb']['email_domain'] = 'linux-geis.host.nl';


This is what is used in /etc/kolab/kolabfilter.conf:
-$conf['filter']['email_domain'] = 'mydomain.com';
+$conf['kolab']['filter']['email_domain'] = 'mydomain.com';

In the template files this is:
freebusy.conf.template:$conf['fb']['email_domain'] = '@@@fqdnhostname@@@';  <<<
Looks wrong
resmgr.conf.template:$conf['kolab']['filter']['email_domain'] =
'@@@postfix-mydomain@@@'; 

It looks wrong, but it might be good dunno.  I assume this issue will make clear
what it should be...

----------
assignedto: wrobel
keyword: server
messages: 22911
nosy: rbos, thomas, wilde, wrobel
priority: bug
status: unread
title: Incorrect value for email_domain in  freebusy/config.php

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


From ludwig.reiter at intevation.de  Thu Dec 17 14:25:24 2009
From: ludwig.reiter at intevation.de (Ludwig Reiter)
Date: Thu, 17 Dec 2009 14:25:24 +0100
Subject: [Kolab-devel] New native Windows Client: Kontact enterprise4
	20091204-3
Message-ID: <200912171425.33212.ludwig.reiter@intevation.de>

Hello,

I have uploaded a new beta version of the Kontact enterprise4 Windows client: 
version 20091204-3.

This version can be downloaded at:
http://files.kolab.org/clients/kontact-enterprise4/windows/beta-huge-debug/20091204-3

It contains a lot of bugfixes (See the logs from 2009-06-05 to 2009-12-04 of 
NewsLog.txt [1] for details).
Make sure to read the corresponding README file [2] before use. This version 
is still BETA. It is not recommended for productive use.

Best Regards,
Ludwig


[1] 
http://files.kolab.org/clients/kontact-enterprise4/windows/beta-huge-debug/NewsLog.txt
[2] 
http://files.kolab.org/clients/kontact-enterprise4/windows/beta-huge-debug/20091204-3/README-kontact-20091204-3-en.txt

-- 
Intevation GmbH, Osnabr?ck
Firmensitz: Neuer Graben 17, 49074 Osnabr?ck
Registereintrag: Amtsgericht Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091217/e7f13cb0/attachment.bin

From thomas at btspuhler.com  Thu Dec 17 15:30:52 2009
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Thu, 17 Dec 2009 07:30:52 -0700
Subject: [Kolab-devel] kolab-webadmin not installing in native Mandriva
In-Reply-To: <200912121209.58876.thomas@btspuhler.com>
References: <20091204112321.CE25D60057F@lists.intevation.de>
	<200912042111.46642.ml@radoeka.nl>
	<200912121209.58876.thomas@btspuhler.com>
Message-ID: <200912170730.52557.thomas@btspuhler.com>

Kolab-webadmin built nicely, but refuses to install in a native Mandriva 
distro
I get the following: 
error: Failed dependencies:
        pear(smarty/Smarty.class.php) is needed by kolab-
webadmin-2.2.2-1mdv2010.0.noarch

rpm -q -l php-smarty gives:
/usr/share/php/smarty/Smarty.class.php

It seems the required package is installed.


-- 
Thomas


From ml at radoeka.nl  Thu Dec 17 15:45:32 2009
From: ml at radoeka.nl (Richard Bos)
Date: Thu, 17 Dec 2009 15:45:32 +0100
Subject: [Kolab-devel] kolab-webadmin not installing in native Mandriva
In-Reply-To: <200912170730.52557.thomas@btspuhler.com>
References: <20091204112321.CE25D60057F@lists.intevation.de>
	<200912042111.46642.ml@radoeka.nl>
	<200912121209.58876.thomas@btspuhler.com>
	<200912170730.52557.thomas@btspuhler.com>
Message-ID: <20091217144532.GA65010@xs4all.nl>

On Thu, Dec 17, 2009 at 07:30:52AM -0700, Thomas Spuhler wrote:
> Kolab-webadmin built nicely, but refuses to install in a native Mandriva 
> distro
> I get the following: 
> error: Failed dependencies:
>         pear(smarty/Smarty.class.php) is needed by kolab-
> webadmin-2.2.2-1mdv2010.0.noarch
> 
> rpm -q -l php-smarty gives:
> /usr/share/php/smarty/Smarty.class.php

Is this dist_conf variable set correctly:
mandriva:kolab_php_smarty_prefix=Smarty

-- 
Richard


From wilde at intevation.de  Thu Dec 17 17:56:12 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Thu, 17 Dec 2009 17:56:12 +0100
Subject: [Kolab-devel] Kolab Server 2.2.3 RC1 -- please test!
Message-ID: <s7wws0l5ykz.fsf@intevation.de>

Good news everyone!

Thanks to a tremendous afford of Thomas, I'm happy to announce that we
have just put the 2.2.3 release candidate on line.  

And when I write "release candidate" I really mean it, so unless anyone
finds a really nasty regression the packages will be renamed to release
on Dec 23ed -- and become our little Christmas present.  :-) 

So go to https://files.kolab.org/server/beta/kolab-server-2.2.3-rc-1/
and grep your copy today!

Thomas and I are grateful for any feedback, problem reports as well as
success stories.

cheers
sascha
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer:   Frank Koormann,  Bernhard Reiter,  Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091217/1a7d168f/attachment.bin

From thomas at btspuhler.com  Fri Dec 18 04:09:22 2009
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Thu, 17 Dec 2009 20:09:22 -0700
Subject: [Kolab-devel] kolab-webadmin not installing in native Mandriva
In-Reply-To: <20091217144532.GA65010@xs4all.nl>
References: <20091204112321.CE25D60057F@lists.intevation.de>
	<200912170730.52557.thomas@btspuhler.com>
	<20091217144532.GA65010@xs4all.nl>
Message-ID: <200912172009.22839.thomas@btspuhler.com>

On Thursday 17 December 2009 07:45:32 am Richard Bos wrote:
> On Thu, Dec 17, 2009 at 07:30:52AM -0700, Thomas Spuhler wrote:
> > Kolab-webadmin built nicely, but refuses to install in a native Mandriva
> > distro
> > I get the following:
> > error: Failed dependencies:
> >         pear(smarty/Smarty.class.php) is needed by kolab-
> > webadmin-2.2.2-1mdv2010.0.noarch
> >
> > rpm -q -l php-smarty gives:
> > /usr/share/php/smarty/Smarty.class.php
>
> Is this dist_conf variable set correctly:
> mandriva:kolab_php_smarty_prefix=Smarty

it set as:
kolab_php_smarty_prefix=Smarty


-- 
Thomas


From richard at radoeka.nl  Fri Dec 18 09:19:31 2009
From: richard at radoeka.nl (Richard Bos)
Date: Fri, 18 Dec 2009 09:19:31 +0100
Subject: [Kolab-devel] kolab-webadmin not installing in native Mandriva
In-Reply-To: <200912172009.22839.thomas@btspuhler.com>
References: <20091204112321.CE25D60057F@lists.intevation.de>
	<20091217144532.GA65010@xs4all.nl>
	<200912172009.22839.thomas@btspuhler.com>
Message-ID: <200912180919.32052.richard@radoeka.nl>

Op vrijdag 18 december 2009 04:09:22 schreef Thomas Spuhler:
> > > rpm -q -l php-smarty gives:
> > > /usr/share/php/smarty/Smarty.class.php
> >
> > Is this dist_conf variable set correctly:
> > mandriva:kolab_php_smarty_prefix=Smarty
> 
> it set as:
> kolab_php_smarty_prefix=Smarty

That seems wrong:
kolab-webadmin> grep -R kolab_php_smarty_prefix *
php/admin/include/mysmarty.php.in:require_once('@kolab_php_smarty_prefix@/Smarty.class.php');

And you have: smarty/Smarty.class.php, hence kolab_php_smarty_prefix must be 
set to smarty...


-- 
Richard Bos
Without a home the journey is endless


From issues at kolab.org  Fri Dec 18 10:27:09 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 18 Dec 2009 09:27:09 +0000
Subject: [Kolab-devel] [issue4003] Crash after copying a mail to a quota
	full OnlineIMAP	inbox
In-Reply-To: <1261128429.38.0.871769589079.issue4003@kolab.org>
Message-ID: <1261128429.38.0.871769589079.issue4003@kolab.org>


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

tested with Kontact e35 20091211.1061424-kk1

Test:
the size of an OnlineIMAP account is less than 1MB.
1. Send a large mail (900KB) to another user.
2. Close kontact and set the quota of the account to 1MB on the server.
3. Start Kontact.
4. Copy the largemail from the local folders to the inbox of the imap account.
=> Crash.

Output:
kontact: imapaccountbase.cpp:898: QString
KMail::ImapAccountBase::prettifyQuotaError(const QString&, KIO::Job*):
Zusicherung »folder« nicht erfüllt.
*** KMail got signal 6 (Crashing)
KCrash: Application 'kontact' crashing...

Backtrace:
See copy-overload-20091218.kcrash

----------
assignedto: allen
files: copy-overload-20091218.kcrash
keyword: enterprise35, kde client
messages: 22918
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Crash after copying a mail to a quota full OnlineIMAP inbox

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4003>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: copy-overload-20091218.kcrash
Type: application/octet-stream
Size: 4663 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091218/44c1ab2c/copy-overload-20091218-0001.exe

From issues at kolab.org  Fri Dec 18 10:45:48 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 18 Dec 2009 09:45:48 +0000
Subject: [Kolab-devel] [issue4004] calendar prints should contain a print
	date (rt#5927)
In-Reply-To: <1261129548.62.0.928856352693.issue4004@kolab.org>
Message-ID: <1261129548.62.0.928856352693.issue4004@kolab.org>


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

Every print of the calendar should contain the date of the print. (In German:
"Stand:..."). 
So if I print a calendar week on the 18th Dez 2009, the printout should contain
a line with "Date of print: Fr. 2009-12-18" or in German "Stand: Fr. 18.12.2009"
or so.

Please estimate first and then wait on an okay before continuing.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22919
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: calendar prints should contain a print date (rt#5927)

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


From thomas at intevation.de  Fri Dec 18 11:58:02 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Fri, 18 Dec 2009 11:58:02 +0100
Subject: [Kolab-devel] Call for testing and proposal for
	kolab-test-toolbox
In-Reply-To: <20091204084157.16567iqooz02mz4s@webmail.pardus.de>
References: <960738410912031029x63e4a937ocf38c6c6411f60f0@mail.gmail.com>
	<20091204084157.16567iqooz02mz4s@webmail.pardus.de>
Message-ID: <20091218115515.834030348.thomas@intevation.de>

* Gunnar Wrobel <wrobel at pardus.de> [20091204 08:42]:
> Quoting Mathieu Parent <math.parent at gmail.com>:
>> I just have commited kolab-test-toolbox.pl to CVS.
>
> Very nice! Thanks a lot.

Yes, indeed!

> I did move this from the "testing" directory to a new "ci" (for  
> continuous integration) hierarchy. I also added my older "ec2" directory 
> there (see below). I'm pretty certain Thomas also has a few ideas 
> concerning CI but I hope it makes sense to keep the things that will be 
> needed in that area within utils/ci.

I have ideas for that, but the Xen+lenny+OpenPKG part of
kolab-test-toolbox already looks like something I want to implement
my ideas :)

> Does it make sense to directly package this in a decent perl package?  
> Similar to perl-kolab?

Probably not yet, or do you expect that end users will run this?

Regards,
Thomas

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091218/da4a0448/attachment.bin

From thomas at btspuhler.com  Fri Dec 18 15:23:57 2009
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Fri, 18 Dec 2009 07:23:57 -0700
Subject: [Kolab-devel] kolab-webadmin not installing in native Mandriva
In-Reply-To: <200912180919.32052.richard@radoeka.nl>
References: <20091204112321.CE25D60057F@lists.intevation.de>
	<200912172009.22839.thomas@btspuhler.com>
	<200912180919.32052.richard@radoeka.nl>
Message-ID: <200912180723.57500.thomas@btspuhler.com>

On Friday 18 December 2009 01:19:31 am Richard Bos wrote:
> Op vrijdag 18 december 2009 04:09:22 schreef Thomas Spuhler:
> > > > rpm -q -l php-smarty gives:
> > > > /usr/share/php/smarty/Smarty.class.php
> > >
> > > Is this dist_conf variable set correctly:
> > > mandriva:kolab_php_smarty_prefix=Smarty
> >
> > it set as:
> > kolab_php_smarty_prefix=Smarty
>
> That seems wrong:
> kolab-webadmin> grep -R kolab_php_smarty_prefix *
> php/admin/include/mysmarty.php.in:require_once('@kolab_php_smarty_prefix@/S
>marty.class.php');
>
> And you have: smarty/Smarty.class.php, hence kolab_php_smarty_prefix must
> be set to smarty...

didn't make a difference. (I tried both before posting) and just did it again.

-- 
Thomas


From wilde at intevation.de  Fri Dec 18 18:29:53 2009
From: wilde at intevation.de (Sascha Wilde)
Date: Fri, 18 Dec 2009 18:29:53 +0100
Subject: [Kolab-devel] Brain Dump of the Week -- High Hopes
Message-ID: <s7wskb842cu.fsf@intevation.de>

Hi *,

another week is over -- and once again I wonder where it's gone...  ;-)
The most exciting news these days is that we actually made it and
released an RC of Server 2.2.3.

As I wrote already in my announcement mail, we are serious about the RC,
no known problems or wishes which ought to be fixed in the final
release -- so if we don't get to know of any showstopper within the next
few days we will actually have an release on Dec. 23!

I hope very much that many people will find the time and give the RC a
try, even though the holidays are already knocking at the door.

What else?  In preparation of the release I did some commits on both the
2.2.x branch and HEAD and doing so I was once again reminded, that there
are quite a few changes in 2.2.3 which need to be merged.  This is a
tedious and sometimes even boring task -- but never the less a very
important one as HEAD is the future of Kolab Server and already contains
many important improvements.

Any help on this will be highly appreciated.  People who'd like to
volunteer should have a look at the release-notes.txt file in head, for
all the changes marked with the TODO tag we need to verify that they are
implemented and working in HEAD.  The issue tacker[1] also helps, as
in some issues it is documented what still needs to be done in HEAD.

There is a bunch more topics swirling around in my head but I'll have to
cache and sort them out a bit before I can write on them here.  So stay
tuned until the next BDotW...

...which might take until next year.
so happy holidays and a happy new year to all of you in advance!

cheers
sascha

[1]  https://issues.kolab.org/
-- 
Sascha Wilde                                          OpenPGP key: 4BB86568
http://www.intevation.de/~wilde/                  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck; AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer:   Frank Koormann,  Bernhard Reiter,  Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091218/52195f5e/attachment.bin

From tr at erdfunkstelle.de  Sat Dec 19 08:56:49 2009
From: tr at erdfunkstelle.de (Thomas Reitelbach)
Date: Sat, 19 Dec 2009 08:56:49 +0100
Subject: [Kolab-devel] New native Windows Client: Kontact enterprise4
	20091204-3
In-Reply-To: <200912171425.33212.ludwig.reiter@intevation.de>
References: <200912171425.33212.ludwig.reiter@intevation.de>
Message-ID: <200912190856.49234.tr@erdfunkstelle.de>

Am Donnerstag, 17. Dezember 2009 14:25:24 schrieb Ludwig Reiter:
> Hello,
> 
> I have uploaded a new beta version of the Kontact enterprise4 Windows
>  client: version 20091204-3.

Thank you very much for your work!
I'll download and install it soon for testing.

Cheers and happy christmas to all!
Thomas


From thomas at btspuhler.com  Sun Dec 20 18:43:37 2009
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sun, 20 Dec 2009 10:43:37 -0700
Subject: [Kolab-devel] kolab-webadmin not installing in native Mandriva
In-Reply-To: <200912180723.57500.thomas@btspuhler.com>
References: <20091204112321.CE25D60057F@lists.intevation.de>
	<200912180919.32052.richard@radoeka.nl>
	<200912180723.57500.thomas@btspuhler.com>
Message-ID: <200912201043.38233.thomas@btspuhler.com>

On Friday 18 December 2009 07:23:57 am Thomas Spuhler wrote:
> On Friday 18 December 2009 01:19:31 am Richard Bos wrote:
> > Op vrijdag 18 december 2009 04:09:22 schreef Thomas Spuhler:
> > > > > rpm -q -l php-smarty gives:
> > > > > /usr/share/php/smarty/Smarty.class.php
> > > >
> > > > Is this dist_conf variable set correctly:
> > > > mandriva:kolab_php_smarty_prefix=Smarty
> > >
> > > it set as:
> > > kolab_php_smarty_prefix=Smarty
> >
> > That seems wrong:
> > kolab-webadmin> grep -R kolab_php_smarty_prefix *
> > php/admin/include/mysmarty.php.in:require_once('@kolab_php_smarty_prefix@
> >/S marty.class.php');
> >
> > And you have: smarty/Smarty.class.php, hence kolab_php_smarty_prefix must
> > be set to smarty...
>
> didn't make a difference. (I tried both before posting) and just did it
> again.

I am puzzled, there are actually two dependencies that are reported missing 
during install, and both files are there:
/etc/kolab/session_vars.php
and
/usr/share/php/smarty/Smarty.class.php

putting this line into the spec file solves the problem:

%define _requires_exceptions 	pear(/usr/share/php/smarty/Smarty.class.php)\\|
pear(/etc/kolab/session_vars.php)

This problem must have been existing for a few years. I found this line in the 
spec file done by my predecessor for 2.1.0 (and may be before)
I also had to put an absolute path into the dist_conf/mandriva


-- 
Thomas


From aspineux at gmail.com  Mon Dec 21 10:42:46 2009
From: aspineux at gmail.com (Alain Spineux)
Date: Mon, 21 Dec 2009 10:42:46 +0100
Subject: [Kolab-devel] Fwd: Introducing OpenPKG 4.x
In-Reply-To: <20091215160351.113831azuj9vbc6c@webmail.pardus.de>
References: <200912080808.11106.martin.konold@erfrakon.de>
	<886E32F6-F502-4390-9096-50CCDF4EC985@kdab.com>
	<20091211095201.42712xr88n61hjy8@webmail.pardus.de>
	<960738410912110854t175242acp579967601dd89f1d@mail.gmail.com>
	<20091215160351.113831azuj9vbc6c@webmail.pardus.de>
Message-ID: <71fe4e760912210142g70c8499ere817e7b6688f55b5@mail.gmail.com>

Hi

Here are some comment about what I read in previous post:

What about the appliance model ?
1. Choose a base distribution
2. Build an auto-install CD that will finish the normal distribution
installation by the kolab installation
3. This appliance could be installed as a virtual machine on other system
This way, the choose distribution will be supported, and kolab could
be installed on other system as a virtual machine.


Why not to make a survey on the mailing list about which distribution
kolab users use ?


What about solaris user ?


Please forget about fedora, (a new fedora every 6 month could be hard
to support :) thing about Centos



On Tue, Dec 15, 2009 at 4:03 PM, Gunnar Wrobel <wrobel at pardus.de> wrote:
> Hi Mathieu,
>
> this is going to be a long mail. Summary at the bottom :)
>
> Quoting Mathieu Parent <math.parent at gmail.com>:
>
>> On Fri, Dec 11, 2009 at 9:52 AM, Gunnar Wrobel <wrobel at pardus.de> wrote:
>> ...
>>>
>>> I think we should start discussing the different available options on the
>>> list so that we get an overview on the different options including their
>>> pros and cons.
>>
>> Let's do it!
>>
>> I have setup a page on the wiki:
>> <https://wiki.kolab.org/index.php/Developer_packaging_platform_comparison>
>>
>
> Thanks!!!
>
> I added a short summary on top and the licensing information from
> the recent mail from OpenPKG to clarify why we consider changing
> the distribution.
>
> I did actually try to call OpenPKG twice just to get some
> personal feedback from them but they seem to be in holiday
> already. They don't offer a way to leave them any messages. I
> guess I could mail them but I think the letter Martin Konold
> forwarded was already clear enough. I just would have liked to
> discuss it in person.
>
> To me the move away from OpenPKG seems to be unavoidable now.
>
> I would like to reprint the requirements you added to the wiki
> page:
>
> ?Requirements
>
> ? ?* MUST be FOSS
>
> ? ?* MUST be available without charging clients
>
> ? ?* MUST cover major Linux distributions (see on distrowatch or
> ? ? ?Wikipedia) : Ubuntu, Fedora, openSUSE, Debian, mandriva,
> ? ? ?...
>
> ? ?* MAY include a build service
>
> ? ?* MAY include automated tests
>
> I think they are complete. Does anyone have something to add?
>
>> Currently, two solutions have been mentionned:
>> - OpenSUSE Build service
>> - Project Builder
>
> I'd like to split the "solutions" part somewhat further.
>
> You listed two build services as possible successors to
> OpenPKG. The outcome of these build services would be Kolab
> Server images/builds for several different distributions. This is
> a worthy goal and I believe it would help with some of the
> problems we are currently having. It should be a part of our
> strategy.
>
> But I say "a part" as these build services will yield different
> flavors of the Kolab Server. Each distribution specific build
> could have its unique problems. If we would declare such a build
> service as successor to OpenPKG then this would mean that we need
> to test the resulting builds for each distribution. And that was
> a central part of the quality control strategy: Just testing a
> *single* distribution which customers can install on any base
> distribution.
>
> Testing is a limitation for us. The guys at Intevation are doing
> a tremendous job concerning the quality of the server. As this
> requires significant man power I really don't see how we could
> extend that effort beyond a single distribution.
>
> Back to the build services: We could of course use such a build
> service but restrict testing to a single distribution built by
> the service. This is in fact what I'd like us to do. But that
> means that the original question remains the same: Which
> distribution will we test instead of OpenPKG? Which distribution
> gets our commercial support?
>
> This is the primary question to me.
>
> I do see two broad categories into which the solution might fall:
>
> ?1) Source based distributions (OpenPKG, pkgsrc, Gentoo, ...)
> ?2) Binary distributions (Ubuntu, Fedora, Suse, Debian, ...)
>
> Source based distributions have the great advantage that we test
> only a single distribution. Nevertheless the user can install
> this system on many platforms. Most of the source based systems
> support many variants. Of course this has a major drawback: While
> you can install on many platforms you still install a new
> distribution within the one you are used to which means to have
> to learn the OpenPKG toolset.
>
> A binary distribution would have the advantage that everyone used
> to that distribution would feel at home immediately. The
> disadvantage would be that we remove support for platforms we
> have been supporting so far.
>
> As much as I dislike OpenPKG I have always considered the choice
> of a source based distribution to be a good one. Of course people
> were unhappy with using the OpenPKG toolset rather than the one
> provided by their favored distribution. This has fostered several
> native ports and expressed a certain disagreement with the
> OpenPKG choice. But my impression was also that there are many,
> many people which are happy with the simplicity and robustness of
> the Kolab server. Using OpenPKG has allowed us to provide a
> consistent and high quality over many platforms.
>
> I'm absolutely convinced that we should not leave users behind by
> removing support for platforms we supported before. Using a
> binary distribution as the base we support for the Kolab Server
> is no option to me.
>
> Back to the build services: Assuming we choose the distribution
> we want to support then I see no reason why we should not use one
> of the build systems you mentioned. The OpenSUSE build system
> would of course only work if it supports the distribution we
> chose. The project builder seems more generic.
>
> The build service would hopefully reduce the amount of duplicated
> work necessary to build the Kolab server on the different
> distributions. All the required packaging information could
> probably be centralized in one repository.
>
> It should also help us to improve the quality of the native ports
> as this is one problem we currently see: A user that wants to
> install Kolab might start to try with a native port. These are
> usually maintained by less people than the OpenPKG variant and so
> the chances for problems are slightly higher. If the user hits a
> problem he might have difficulties getting support from the
> mailing lists. I know how often I have to say that I don't know
> what the state of a specific native port actually is and how the
> problem might be solved.
> I would hope that using a build service helps indicating early
> that a commit might cause problems on one of the distributions
> supported by the build service. It would improve my awareness of
> the state of the native ports which would be a good thing.
>
> On top of the supported distribution and an optional automatic
> build system I see automated testing. We should investigate if it
> would be possible to use a testing framework that allows testing
> the different Kolab Server builds equally well.
>
> This would help us in development as problems might be discovered
> early. It would also reduce our testing effort as some checks are
> performed automatically. In addition it would also help the
> quality of the native ports.
>
> Summary
> =======
>
> I believe the primary focus of the discussion is the quality of
> the Kolab Server. To keep the standard high we absolutely MUST
>
> ?- select a single distribution that will be tested and supported
> ? by the Kolab consortium
>
> We SHOULD
>
> ?- find a build service that makes building the Kolab Server on
> ? different distributions easier and helps dissolving the
> ? current barrier between Kolab/OpenPKG and the native ports.
>
> ?- investigate automatic testing further to reduce the effort
> ? required for testing, to improve development and to help the
> ? native ports.
>
> Cheers,
>
> Gunnar
>
>
> --
> ______ http://kdab.com _______________ http://kolab-konsortium.com _
>
> p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
>
> ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
> E-mail : p at rdus.de ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Dr. Gunnar Wrobel
> Tel. ? : +49 700 6245 0000 ? ? ? ? ? ? ? ? ? ? ? ? ?Bundesstrasse 29
> Fax ? ?: +49 721 1513 52322 ? ? ? ? ? ? ? ? ? ? ? ? ?D-20146 Hamburg
> --------------------------------------------------------------------
> ? >> Mail at ease - Rent a kolab groupware server at p at rdus <<
> --------------------------------------------------------------------
>
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
Alain Spineux
aspineux gmail com
Your email 100% available with Emailgency  |  http://www.emailgency.com


From issues at kolab.org  Mon Dec 21 16:40:49 2009
From: issues at kolab.org (Bernhard Reiter)
Date: Mon, 21 Dec 2009 15:40:49 +0000
Subject: [Kolab-devel] [issue4005] Attachments should open in read-only
	folders(rt#5915)
In-Reply-To: <1261410049.07.0.598885768459.issue4005@kolab.org>
Message-ID: <1261410049.07.0.598885768459.issue4005@kolab.org>


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

This has been split out from kolab/issue3961 (Mail attachment of a task should 
be persistent) for the case that the folder of the tasks is shared read only.
I am quite sure that testing will reveal the same issu es will all attachment
types (at least appointments and tasks).

Testing was done with:
4:3.5.10.enterprise.0.20091211.1063352-kk3 Lenny.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22935
nosy: allen, bernhard, ludwig, till, tmcguire
priority: bug
status: unread
title: Attachments should open in read-only folders(rt#5915)

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


From thomas at intevation.de  Tue Dec 22 09:39:00 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Tue, 22 Dec 2009 09:39:00 +0100
Subject: [Kolab-devel] Kolab Server 2.2.3 RC1 -- please test!
In-Reply-To: <s7wws0l5ykz.fsf@intevation.de>
References: <s7wws0l5ykz.fsf@intevation.de>
Message-ID: <20091222092916.308399655.thomas@intevation.de>

* Sascha Wilde <wilde at intevation.de> [20091217 17:56]:
> Thanks to a tremendous afford of Thomas, I'm happy to announce that we
> have just put the 2.2.3 release candidate on line.  
> 
> And when I write "release candidate" I really mean it, so unless anyone
> finds a really nasty regression the packages will be renamed to release
> on Dec 23ed -- and become our little Christmas present.  :-) 
> 
> So go to https://files.kolab.org/server/beta/kolab-server-2.2.3-rc-1/
> and grep your copy today!
> 
> Thomas and I are grateful for any feedback, problem reports as well as
> success stories.

Santa might know if you have been good or bad, but we don't know if
2.2.3-rc1 works for you or not.

We did not receive any feedback yet, not even an "I tried it and it
did not immediately bite me", so maybe the final release should be
postponed until we get at least one report?

So please give us feedback to save Christmas! :)

Regards,
Thomas Arendsen Hein

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091222/8b177ce9/attachment.bin

From issues at kolab.org  Thu Dec  3 10:58:11 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 03 Dec 2009 09:58:11 -0000
Subject: [Kolab-devel] [issue3987] Knotes: Black note
In-Reply-To: <1259834290.32.0.378255293064.issue3987@kolab.org>
Message-ID: <1259834290.32.0.378255293064.issue3987@kolab.org>


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

Tested with Kontact e35 20091127.1055372-kk1

Test:
1. startkde
-> a plain kde is started, without running kontact or knotes.
2. Start knotes
-> kwallet pops up.
3. Enter the kwallet password. Ok.
-> kontact starts, knotes icon is in the system tray.
4. Open kontact, switch to notes and delete all notes.
5. Sync.
6. Switch in kontact to notes and create a new note.
-> A note is in kontact and a black note is displayed in the kde environment.
This is wrong. See the screenshot.

----------
assignedto: allen
files: black-note-20091203.png
keyword: enterprise35, kde client
messages: 22696
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Knotes: Black note

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3987>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: black-note-20091203.png
Type: image/png
Size: 86137 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091203/db3768b1/black-note-20091203-0001.png

From issues at kolab.org  Fri Dec 11 12:39:31 2009
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 11 Dec 2009 11:39:31 +0000
Subject: [Kolab-devel] [issue3994] The calendar/event view configuration
	dialog is too wide.
In-Reply-To: <1260531571.03.0.754481568716.issue3994@kolab.org>
Message-ID: <1260531571.03.0.754481568716.issue3994@kolab.org>


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

observed with Kontact e35 20091204.1058393-kk1

Test:
1.Switch to the calendar.
2. Open the configuation dialog.
3. Switch to the view section.
=> The dialog is very wide, because the todo view part is on the side of the
monthview part.
I expect it to be below the monthview part.

----------
assignedto: allen
files: view-dialog-20091211.png
keyword: enterprise35, kde client
messages: 22791
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: The calendar/event view configuration dialog is too wide.

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue3994>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: view-dialog-20091211.png
Type: image/png
Size: 105951 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091211/073dc722/view-dialog-20091211-0001.png

From martin.konold at erfrakon.de  Tue Dec 22 10:33:27 2009
From: martin.konold at erfrakon.de (Martin Konold)
Date: Tue, 22 Dec 2009 10:33:27 +0100
Subject: [Kolab-devel] Fwd: Cyrus IMAPd 2.3.16 Released
Message-ID: <200912221033.28665.martin.konold@erfrakon.de>


Hi,

the Kolab specific annotations patch has finally be accepted with Cyrus.

This means yet another step towards reducing the number of patches.

While today the Kolab Server 2.2.3 RC1 was released I would like to discuss if 
we want to use Cyrus Imapd 2.3.16 instead of 2.3.13. 

On one hand this could delay the release of Kolab 2.2.3 but on the other hand 
the current 2.2.3 stuff is not tested much anyway.

Cyrus Imapd 2.3.16 contains multiple skiplist and bdb fixes and decreasing the 
amount of Kolab specific patches is always a major goal.

Opinions welcome!

Yours,
-- martin
----------  Forwarded Message  ----------

Subject: Cyrus IMAPd 2.3.16 Released
Date: Monday 21 December 2009
From: Ken Murchison <murch at andrew.cmu.edu>
To: Cyrus Mailing List <info-cyrus at lists.andrew.cmu.edu>, cyrus-
announce at lists.andrew.cmu.edu, cyrus-devel at lists.andrew.cmu.edu, cyrus-
project at lists.andrew.cmu.edu

I am pleased to announce the release of Cyrus IMAPd 2.3.16.  This
release should be considered production quality.  Major changes in the 
release are the following:

- Added 'user_deny.db' to be able to selectively deny users access to
   Cyrus services.
- Added 'popuseimapflags' option which enables setting and
   obeying IMAP flags in the POP server.
- Added optimized method of handling an empty maildrop in pop3d.
   (based on work of Cyril Servant <elfejoyeux at gmail.com>)
- Added 'annotation_definitions' option for specifying
   external (third-party) annotations. (courtesy of Thomas
   Viehmann <tv at beamnet.de>)
- Added COMPRESSion to replication protocol. (courtesy of Bron Gondwana
   <brong at fastmail.fm>)

For full details, please see doc/changes.html and
doc/install-upgrade.html which are included in the distribution.

URLs for this release:
ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.16.tar.gz
or
http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.3.16.tar.gz


Questions and comments can be directed to
info-cyrus at lists.andrew.cmu.edu (public list), or cyrus-bugs at andrew.cmu.edu.

Happy Holidays!

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University















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


From alex at ap-consulting.co.uk  Tue Dec 22 11:25:01 2009
From: alex at ap-consulting.co.uk (Alex Potter)
Date: Tue, 22 Dec 2009 10:25:01 +0000
Subject: [Kolab-devel] Kolab Server 2.2.3 RC1 -- please test!
In-Reply-To: <20091222092916.308399655.thomas@intevation.de>
References: <s7wws0l5ykz.fsf@intevation.de>
	<20091222092916.308399655.thomas@intevation.de>
Message-ID: <200912221025.01859.alex@ap-consulting.co.uk>

On Tuesday 22 December 2009 08:39:00 Thomas Arendsen Hein wrote:
> So please give us feedback to save Christmas! :)
> 
I've just completed a clean install on an Ubuntu 8.04 test system.
Compilation and installation proceeded without incident.
The system has only had limited testing.

Is there an automated test suite to give the system a hammering?

Alex


From math.parent at gmail.com  Tue Dec 22 11:27:37 2009
From: math.parent at gmail.com (Mathieu Parent)
Date: Tue, 22 Dec 2009 11:27:37 +0100
Subject: [Kolab-devel] Fwd: Cyrus IMAPd 2.3.16 Released
In-Reply-To: <200912221033.28665.martin.konold@erfrakon.de>
References: <200912221033.28665.martin.konold@erfrakon.de>
Message-ID: <960738410912220227p1b12c294q21ee8bdf12f15847@mail.gmail.com>

Hello,

On Tue, Dec 22, 2009 at 10:33 AM, Martin Konold
<martin.konold at erfrakon.de> wrote:
>
> Hi,
>
> the Kolab specific annotations patch has finally be accepted with Cyrus.
>
> This means yet another step towards reducing the number of patches.

Can someone update
https://wiki.kolab.org/index.php/Kolab-major-app-patches What are the
remaining patches?

Mathieu Parent


From thomas at intevation.de  Tue Dec 22 12:40:03 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Tue, 22 Dec 2009 12:40:03 +0100
Subject: [Kolab-devel] Fwd: Cyrus IMAPd 2.3.16 Released
In-Reply-To: <200912221033.28665.martin.konold@erfrakon.de>
References: <200912221033.28665.martin.konold@erfrakon.de>
Message-ID: <20091222123508.212531499.thomas@intevation.de>

* Martin Konold <martin.konold at erfrakon.de> [20091222 10:33]:
> the Kolab specific annotations patch has finally be accepted with Cyrus.
> 
> This means yet another step towards reducing the number of patches.

Yay!

> While today the Kolab Server 2.2.3 RC1 was released I would like to discuss if 
> we want to use Cyrus Imapd 2.3.16 instead of 2.3.13. 
> 
> On one hand this could delay the release of Kolab 2.2.3 but on the other hand 
> the current 2.2.3 stuff is not tested much anyway.

Sorry, I won't delay 2.2.3 for a new Cyrus. This part has been
tested very much, the "not tested much" part only applies to
specific Kolab parts, e.g. the Kolab filter, and only partially as
many things have been tested, just not as much as in previous
releases. Still I think it behaves much better than 2.2.0 and 2.2.2,
so there is no point in delaying 2.2.3.

> Cyrus Imapd 2.3.16 contains multiple skiplist and bdb fixes and decreasing the 
> amount of Kolab specific patches is always a major goal.

I definitively want this for HEAD so the next release can include it!

Regards,
Thomas

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From tr at erdfunkstelle.de  Tue Dec 22 16:19:27 2009
From: tr at erdfunkstelle.de (Thomas Reitelbach)
Date: Tue, 22 Dec 2009 16:19:27 +0100
Subject: [Kolab-devel] New native Windows Client: Kontact enterprise4
	20091204-3
Message-ID: <200912221619.27322.tr@erdfunkstelle.de>

Am Samstag, 19. Dezember 2009 08:56:49 schrieb Thomas Reitelbach:
> Am Donnerstag, 17. Dezember 2009 14:25:24 schrieb Ludwig Reiter:
> > Hello,
> >
> > I have uploaded a new beta version of the Kontact enterprise4 Windows
> >  client: version 20091204-3.
>
> Thank you very much for your work!
> I'll download and install it soon for testing.

I downloaded and installed the new beta and it runs smoothly. The timezone 
issues (which prevented me from using the previous beta) seems to be solved 
:-)))
I'm currently using the new beta and our other workstations use Kontact for 
linux, enterprise35 branch - even the combined use of both clients runs smooth 
without problems.

But I found one bug and reported it to bugs.kde.org - is this the correct 
bugtracker? On this list I see kolab/issues with different numbers than 
bugs.kde.org, so do you guys receive my bug [Bug 219543] or should I use a 
different tracker?

Thank you for all your work!

Cheers
Thomas


Unser Notdienst ist jederzeit erreichbar!


From thomas at btspuhler.com  Tue Dec 22 17:45:44 2009
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Tue, 22 Dec 2009 09:45:44 -0700
Subject: [Kolab-devel] Fwd: Introducing OpenPKG 4.x
In-Reply-To: <71fe4e760912210142g70c8499ere817e7b6688f55b5@mail.gmail.com>
References: <200912080808.11106.martin.konold@erfrakon.de>
	<20091215160351.113831azuj9vbc6c@webmail.pardus.de>
	<71fe4e760912210142g70c8499ere817e7b6688f55b5@mail.gmail.com>
Message-ID: <200912220945.44466.thomas@btspuhler.com>

On Monday 21 December 2009 02:42:46 am Alain Spineux wrote:
> Hi
>
> Here are some comment about what I read in previous post:
>
> What about the appliance model ?
> 1. Choose a base distribution
> 2. Build an auto-install CD that will finish the normal distribution
> installation by the kolab installation
> 3. This appliance could be installed as a virtual machine on other system
> This way, the choose distribution will be supported, and kolab could
> be installed on other system as a virtual machine.
>
>
> Why not to make a survey on the mailing list about which distribution
> kolab users use ?
>
>
> What about solaris user ?
>
>
> Please forget about fedora, (a new fedora every 6 month could be hard
> to support :) thing about Centos
>
> On Tue, Dec 15, 2009 at 4:03 PM, Gunnar Wrobel <wrobel at pardus.de> wrote:
> > Hi Mathieu,
> >
> > this is going to be a long mail. Summary at the bottom :)
> >
> > Quoting Mathieu Parent <math.parent at gmail.com>:
> >> On Fri, Dec 11, 2009 at 9:52 AM, Gunnar Wrobel <wrobel at pardus.de> wrote:
> >> ...
> >>
> >>> I think we should start discussing the different available options on
> >>> the list so that we get an overview on the different options including
> >>> their pros and cons.
> >>
> >> Let's do it!
> >>
> >> I have setup a page on the wiki:
> >> <https://wiki.kolab.org/index.php/Developer_packaging_platform_compariso
> >>n>
> >
> > Thanks!!!
> >
> > I added a short summary on top and the licensing information from
> > the recent mail from OpenPKG to clarify why we consider changing
> > the distribution.
> >
> > I did actually try to call OpenPKG twice just to get some
> > personal feedback from them but they seem to be in holiday
> > already. They don't offer a way to leave them any messages. I
> > guess I could mail them but I think the letter Martin Konold
> > forwarded was already clear enough. I just would have liked to
> > discuss it in person.
> >
> > To me the move away from OpenPKG seems to be unavoidable now.
> >
> > I would like to reprint the requirements you added to the wiki
> > page:
> >
> >  Requirements
> >
> >    * MUST be FOSS
> >
> >    * MUST be available without charging clients
> >
> >    * MUST cover major Linux distributions (see on distrowatch or
> >      Wikipedia) : Ubuntu, Fedora, openSUSE, Debian, mandriva,
> >      ...
> >
> >    * MAY include a build service
> >
> >    * MAY include automated tests
> >
> > I think they are complete. Does anyone have something to add?
> >
> >> Currently, two solutions have been mentionned:
> >> - OpenSUSE Build service
> >> - Project Builder
> >
> > I'd like to split the "solutions" part somewhat further.
> >
> > You listed two build services as possible successors to
> > OpenPKG. The outcome of these build services would be Kolab
> > Server images/builds for several different distributions. This is
> > a worthy goal and I believe it would help with some of the
> > problems we are currently having. It should be a part of our
> > strategy.
> >
> > But I say "a part" as these build services will yield different
> > flavors of the Kolab Server. Each distribution specific build
> > could have its unique problems. If we would declare such a build
> > service as successor to OpenPKG then this would mean that we need
> > to test the resulting builds for each distribution. And that was
> > a central part of the quality control strategy: Just testing a
> > *single* distribution which customers can install on any base
> > distribution.
> >
> > Testing is a limitation for us. The guys at Intevation are doing
> > a tremendous job concerning the quality of the server. As this
> > requires significant man power I really don't see how we could
> > extend that effort beyond a single distribution.
> >
> > Back to the build services: We could of course use such a build
> > service but restrict testing to a single distribution built by
> > the service. This is in fact what I'd like us to do. But that
> > means that the original question remains the same: Which
> > distribution will we test instead of OpenPKG? Which distribution
> > gets our commercial support?
> >
> > This is the primary question to me.
> >
> > I do see two broad categories into which the solution might fall:
> >
> >  1) Source based distributions (OpenPKG, pkgsrc, Gentoo, ...)
> >  2) Binary distributions (Ubuntu, Fedora, Suse, Debian, ...)
> >
> > Source based distributions have the great advantage that we test
> > only a single distribution. Nevertheless the user can install
> > this system on many platforms. Most of the source based systems
> > support many variants. Of course this has a major drawback: While
> > you can install on many platforms you still install a new
> > distribution within the one you are used to which means to have
> > to learn the OpenPKG toolset.
> >
> > A binary distribution would have the advantage that everyone used
> > to that distribution would feel at home immediately. The
> > disadvantage would be that we remove support for platforms we
> > have been supporting so far.
> >
> > As much as I dislike OpenPKG I have always considered the choice
> > of a source based distribution to be a good one. Of course people
> > were unhappy with using the OpenPKG toolset rather than the one
> > provided by their favored distribution. This has fostered several
> > native ports and expressed a certain disagreement with the
> > OpenPKG choice. But my impression was also that there are many,
> > many people which are happy with the simplicity and robustness of
> > the Kolab server. Using OpenPKG has allowed us to provide a
> > consistent and high quality over many platforms.
> >
> > I'm absolutely convinced that we should not leave users behind by
> > removing support for platforms we supported before. Using a
> > binary distribution as the base we support for the Kolab Server
> > is no option to me.
> >
> > Back to the build services: Assuming we choose the distribution
> > we want to support then I see no reason why we should not use one
> > of the build systems you mentioned. The OpenSUSE build system
> > would of course only work if it supports the distribution we
> > chose. The project builder seems more generic.
> >
> > The build service would hopefully reduce the amount of duplicated
> > work necessary to build the Kolab server on the different
> > distributions. All the required packaging information could
> > probably be centralized in one repository.
> >
> > It should also help us to improve the quality of the native ports
> > as this is one problem we currently see: A user that wants to
> > install Kolab might start to try with a native port. These are
> > usually maintained by less people than the OpenPKG variant and so
> > the chances for problems are slightly higher. If the user hits a
> > problem he might have difficulties getting support from the
> > mailing lists. I know how often I have to say that I don't know
> > what the state of a specific native port actually is and how the
> > problem might be solved.
> > I would hope that using a build service helps indicating early
> > that a commit might cause problems on one of the distributions
> > supported by the build service. It would improve my awareness of
> > the state of the native ports which would be a good thing.
> >
> > On top of the supported distribution and an optional automatic
> > build system I see automated testing. We should investigate if it
> > would be possible to use a testing framework that allows testing
> > the different Kolab Server builds equally well.
> >
> > This would help us in development as problems might be discovered
> > early. It would also reduce our testing effort as some checks are
> > performed automatically. In addition it would also help the
> > quality of the native ports.
> >
> > Summary
> > =======
> >
> > I believe the primary focus of the discussion is the quality of
> > the Kolab Server. To keep the standard high we absolutely MUST
> >
> >  - select a single distribution that will be tested and supported
> >   by the Kolab consortium
> >
> > We SHOULD
> >
> >  - find a build service that makes building the Kolab Server on
> >   different distributions easier and helps dissolving the
> >   current barrier between Kolab/OpenPKG and the native ports.
> >
> >  - investigate automatic testing further to reduce the effort
> >   required for testing, to improve development and to help the
> >   native ports.
> >
> > Cheers,
> >
> > Gunnar
> >
> >
> > --
> > ______ http://kdab.com _______________ http://kolab-konsortium.com _
> >
> > p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
> >
> > ____ http://www.pardus.de _________________ http://gunnarwrobel.de _
> > E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
> > Tel.   : +49 700 6245 0000                          Bundesstrasse 29
> > Fax    : +49 721 1513 52322                          D-20146 Hamburg
> > --------------------------------------------------------------------
> >   >> Mail at ease - Rent a kolab groupware server at p at rdus <<
> > --------------------------------------------------------------------
> >
> >
> > _______________________________________________
> > Kolab-devel mailing list
> > Kolab-devel at kolab.org
> > https://kolab.org/mailman/listinfo/kolab-devel

I think whatever will be chosen, testing native distributions will be a big 
plus for adoption of Kolab. Right now, it involves a lot of work to get it 
working in a native Mandriva environment, even just to build on native 
distributions. This environment will not guarantee that it will build on the 
native environment, but I believe it will make it easy if adjustments are 
needed

-- 
Thomas


From ml at radoeka.nl  Tue Dec 22 20:54:36 2009
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 22 Dec 2009 20:54:36 +0100
Subject: [Kolab-devel] Fwd: Cyrus IMAPd 2.3.16 Released
In-Reply-To: <200912221033.28665.martin.konold@erfrakon.de>
References: <200912221033.28665.martin.konold@erfrakon.de>
Message-ID: <200912222054.36853.ml@radoeka.nl>

Hi Martin,

Op dinsdag 22 december 2009 10:33:27 schreef Martin Konold:
> he Kolab specific annotations patch has finally be accepted with Cyrus.
> 
> This means yet another step towards reducing the number of patches.
> 
> While today the Kolab Server 2.2.3 RC1 was released I would like to discuss
>  if  we want to use Cyrus Imapd 2.3.16 instead of 2.3.13.
> 
> On one hand this could delay the release of Kolab 2.2.3 but on the other
>  hand  the current 2.2.3 stuff is not tested much anyway.
> 
> Cyrus Imapd 2.3.16 contains multiple skiplist and bdb fixes and decreasing
>  the  amount of Kolab specific patches is always a major goal.

This are the changes to the Cyrus IMAP Server since 2.3.15:
- Added user_deny.db to be able to selectively deny users access to Cyrus 
services.
- Added disconnect_on_vanished_mailbox option. See imapd.conf(5) for details
- Reworked SQL detection code in configure. See install-upgrade.html for more 
details.
- Added popuseimapflags option which enables setting and obeying IMAP flags in 
the POP server.
- Added optimized method of handling an empty maildrop in pop3d. Requires 
statuscache to be enabled. (based on work of Cyril Servant ) 
- Added annotation_definitions option for specifying external (third-party) 
annotations. (courtesy of Thomas Viehmann )
- Added sync_compress option to compress replication traffic
- Added user_folder_limit option to limit the number of folders a non-admin 
user is allowed to create.
- Added -x option to cyr_expire to disable expunge
- Track idle state so a shutdown doesn't leave idled killing random other 
processes on a busy system
- Fix missing closedir() - bug #3159 (thanks Simon Matter)
- Make Cyrus compile with older GCC (thanks Simon Matter)

I don't see a reference to kolab related patches, not to skiplist 
improvements.

In the changelog toward 2.3.15 there is a reference to skiplist:
- Fixed a skiplist foreach bug and various datatype size issues that caused 
problems on some 64 bit architectures

It looks like the kolab related patches will be available in cyrus-2.3.17.

-- 
Richard


From martin.konold at erfrakon.de  Tue Dec 22 21:07:14 2009
From: martin.konold at erfrakon.de (Martin Konold)
Date: Tue, 22 Dec 2009 21:07:14 +0100
Subject: [Kolab-devel] Fwd: Cyrus IMAPd 2.3.16 Released
In-Reply-To: <200912222054.36853.ml@radoeka.nl>
References: <200912221033.28665.martin.konold@erfrakon.de>
	<200912222054.36853.ml@radoeka.nl>
Message-ID: <200912222107.15534.martin.konold@erfrakon.de>

On Tuesday 22 December 2009 20:54:36 Richard Bos wrote:

Hi Richard,

> This are the changes to the Cyrus IMAP Server since 2.3.15:

The relevant changes are further below. There are 3 releases between our stuff 
and the most recent Cyrus Imapd release.

> - Added annotation_definitions option for specifying external (third-party)
> annotations. (courtesy of Thomas Viehmann )

This is the patch which is required for Kolab.

> I don't see a reference to kolab related patches, not to skiplist
> improvements.

Kolab related patch: see above.

Skiplist and bdb stuff further below.

> It looks like the kolab related patches will be available in cyrus-2.3.17.

No.

Regards,
-- martin


From ml at radoeka.nl  Tue Dec 22 21:11:42 2009
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 22 Dec 2009 21:11:42 +0100
Subject: [Kolab-devel] Fwd: Cyrus IMAPd 2.3.16 Released
In-Reply-To: <200912222107.15534.martin.konold@erfrakon.de>
References: <200912221033.28665.martin.konold@erfrakon.de>
	<200912222054.36853.ml@radoeka.nl>
	<200912222107.15534.martin.konold@erfrakon.de>
Message-ID: <200912222111.42460.ml@radoeka.nl>

Op dinsdag 22 december 2009 21:07:14 schreef Martin Konold:
> > This are the changes to the Cyrus IMAP Server since 2.3.15:
> 
> The relevant changes are further below. There are 3 releases between our
>  stuff  and the most recent Cyrus Imapd release.

Ah, I see now what  you mean :)

> > - Added annotation_definitions option for specifying external
> > (third-party) annotations. (courtesy of Thomas Viehmann )
> 
> This is the patch which is required for Kolab.

I see.  I did not recognize it, because of the unfamiliar name.  I would have 
expected your name there, of another core kolab-ber. 

-- 
Richard


From issues at kolab.org  Wed Dec 23 10:39:57 2009
From: issues at kolab.org (Bernhard Reiter)
Date: Wed, 23 Dec 2009 09:39:57 +0000
Subject: [Kolab-devel] [issue4006] Drag source for full window emails
In-Reply-To: <1261561197.94.0.887244005159.issue4006@kolab.org>
Message-ID: <1261561197.94.0.887244005159.issue4006@kolab.org>


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

Just had an idea: It would be cool if there is a drag and drop source
in a full window email. (The view you get if you double click on an email).

At least with enterprise35 there is none and it would be handy.
The use case if you want to attach and email to a new email and you have
the first email open already. I've noticed that some people open an email and 
then go to search for emails in other folders, so they have the email available 
on screen.

Assigning to Volker for a first (quick) thought about the idea. 
(I haven't tested e5 for this yet, my aim is to not forget the idea.)
Reassing to me then.

----------
assignedto: vkrause
keyword: enterprise5, kde client
messages: 22938
nosy: allen, bernhard, ludwig, till, vkrause
priority: wish
status: unread
title: Drag source for full window emails

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


From issues at kolab.org  Wed Dec 23 16:03:05 2009
From: issues at kolab.org (Bernhard Reiter)
Date: Wed, 23 Dec 2009 15:03:05 +0000
Subject: [Kolab-devel] [issue4007] Event editor: Missing label for repeat
	(recurrance)
In-Reply-To: <1261580585.32.0.151346034972.issue4007@kolab.org>
Message-ID: <1261580585.32.0.151346034972.issue4007@kolab.org>


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

The event dialog misses a label for "recurrance" (or "repeat").
See kontact-20091223-1.png.

This is probably a coding oversight in
koeditorgeneralevent.cpp, which reads:

  QLabel *label = new QLabel( i18n( "Repeat:" ), timeBoxFrame );
  layoutTimeBox->addWidget( label, 2, 0 );
  QBoxLayout *recLayout = new QHBoxLayout();
  layoutTimeBox->addMultiCellLayout( recLayout, 2, 2, 1, 4 );
  mRecEditButton = new QPushButton( i18n("Does not repeat..."), timeBoxFrame );
  recLayout->addWidget( mRecEditButton );
  connect( mRecEditButton, SIGNAL(clicked()), SIGNAL(editRecurrence()) );
  recLayout->addStretch( 1 );

  label = new QLabel( i18n("Reminder:"), timeBoxFrame );
  layoutTimeBox->addWidget( label, 3, 0 );
  QBoxLayout *alarmLineLayout = new QHBoxLayout();
  layoutTimeBox->addMultiCellLayout( alarmLineLayout, 3, 3, 1, 4 );
  initAlarm( timeBoxFrame, alarmLineLayout );
  alarmLineLayout->addStretch( 1 );

The first quited two lines are fishy, a) there is a "QLabel *label"
which is missing from the other lines and "label" is reused.


e35 Etch Version: 4:3.5.10.enterprise.0.20091222.1065138-kk1
(I accept this a regression, because we had actually fixed this dialog.)

----------
assignedto: allen
files: kontact-20091223-1.png
keyword: enterprise35, kde client, kkc
messages: 22944
nosy: allen, bernhard, ludwig, tmcguire
priority: bug
status: unread
title: Event editor: Missing label for repeat (recurrance)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4007>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kontact-20091223-1.png
Type: image/png
Size: 41278 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091223/b5cc0f8b/kontact-20091223-1-0001.png

From thomas at intevation.de  Wed Dec 23 17:47:39 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Wed, 23 Dec 2009 17:47:39 +0100
Subject: [Kolab-devel] Kolab Server 2.2.3 Final Release
Message-ID: <20091223174644.208283374.thomas@intevation.de>

Hi!

I just promoted last week's release candidate to be the final release
of Kolab Server 2.2.3, which contains about 50 enhancements and fixes
compared to the previous release.

A security issue was fixed in the web client and this release also
includes the previously released security updates for ClamAV and the
Cyrus IMAP server.

Upgrading from 2.2.2 should be straightforward, but make sure you follow
the upgrade instructions in 1st.README as the default format for IMAP
databases was changed back to skiplist.

Documentation and OpenPKG packages are available from
http://files.kolab.org/server/release/kolab-server-2.2.3/
as shown on http://kolab.org/download.html and from the mirrors
listed on http://kolab.org/mirrors.html

http://files.kolab.org/RSYNC.txt explains how to get (or mirror)
the files via rsync.

All files updated since 2.2.2 are available in the directory
server/development-2.2/20091217-since-20090515/

You can check the integrity of the downloaded files with:

$ gpg --keyserver keys.gnupg.net --recv-key 5816791A
  or import the key from https://www.intevation.de/~thomas/gpg_pub_key.asc
  (the same key that I used to sign this email)
$ gpg --verify SHA1SUMS.sig
$ sha1sum -c SHA1SUMS

Binary packages for Debian GNU/Linux 5.0 (lenny/stable) on x86 platforms
can be found in the ix86-debian5.0 directory next to the sources.
This will probably be the last release to additionally provide binary
packages for Debian GNU/Linux 4.0 (etch/oldstable), too.

For install instructions and more information about this release, look at
http://files.kolab.org/server/release/kolab-server-2.2.3/sources/1st.README and
http://files.kolab.org/server/release/kolab-server-2.2.3/sources/release-notes.txt

Please report any problems you encounter in our issue tracker:
https://issues.kolab.org/

Regards,
Thomas Arendsen Hein

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091223/b6c8e1d3/attachment.bin

From bernhard at intevation.de  Mon Dec 28 19:34:05 2009
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 28 Dec 2009 19:34:05 +0100
Subject: [Kolab-devel] New native Windows Client: Kontact enterprise4
	20091204-3
In-Reply-To: <200912221619.27322.tr@erdfunkstelle.de>
References: <200912221619.27322.tr@erdfunkstelle.de>
Message-ID: <200912281934.06316.bernhard@intevation.de>

Am Dienstag, 22. Dezember 2009 16:19:27 schrieb Thomas Reitelbach:
> I downloaded and installed the new beta and it runs smoothly. The timezone
> issues (which prevented me from using the previous beta) seems to be solved
>
> :-)))
>
> I'm currently using the new beta and our other workstations use Kontact for
> linux, enterprise35 branch - even the combined use of both clients runs
> smooth without problems.

Thanks for testing and reporting!

> But I found one bug and reported it to bugs.kde.org - is this the correct
> bugtracker? On this list I see kolab/issues with different numbers than
> bugs.kde.org, so do you guys receive my bug [Bug 219543] or should I use a
> different tracker?

For the e4 series of kontact, report to issues.kolab.org.
Note that we will most likely switch to e5 development soon, and for e5 
bugs.kde.org currently is the right tracker.

Best,
Bernhard


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998
Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20091228/d3221c5c/attachment.bin

From ml at radoeka.nl  Mon Dec 28 21:39:12 2009
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 28 Dec 2009 21:39:12 +0100
Subject: [Kolab-devel] kolab_bootstrap fails on a fresh installed system
Message-ID: <200912282139.12276.ml@radoeka.nl>

Hi,

'kolab_bootstrap -b' fails with the following error:

IMPORTANT NOTE:
use login=manager and passwd=xxxxx when you log into the webinterface!

Enter fully qualified hostname of slave kolab server e.g. thishost.domain.tld (empty when done): 
prepare LDAP database...                                                                         
DEBUG: tpl = /etc/kolab/templates/slapd.access.template.in                                       
Use of uninitialized value $cfg in concatenation (.) or string at /usr/lib/perl5/vendor_perl/5.10.0/Kolab/Conf.pm line 622, <TEMPLATE> line 3978.                                                                                                                       
DEBUG: cfg =                                                                                                                        
Use of uninitialized value $cfg in hash element at /usr/lib/perl5/vendor_perl/5.10.0/Kolab/Conf.pm line 623, <TEMPLATE> line 3978.  
Use of uninitialized value $cfg in hash element at /usr/lib/perl5/vendor_perl/5.10.0/Kolab/Conf.pm line 623, <TEMPLATE> line 3978.  
Use of uninitialized value $cfg in hash element at /usr/lib/perl5/vendor_perl/5.10.0/Kolab/Conf.pm line 623, <TEMPLATE> line 3978.  
Use of uninitialized value in scalar assignment at /usr/lib/perl5/vendor_perl/5.10.0/Kolab/Conf.pm line 119, <TEMPLATE> line 3978.  

I added the "DEBUG:" statements.

This is in the following part of the code:
615     # defaults to all templates
616     $args{templates} = [ keys %templates ] if !exists $args{templates};
617     my $cfg;
618     my $tpl;
619     foreach $tpl (@{$args{templates}}) {
620         $cfg = $templates{$tpl};
621 print "DEBUG: tpl = $tpl\n";
622 print "DEBUG: cfg = $cfg\n";
623         build($tpl, $cfg, $ownership{$cfg}, $permissions{$cfg}, $commentchar{$cfg});
624      }

The function is called with:
477       Kolab::Conf::rebuildTemplates(
478             dorunonchange =>0,
479             templates => [
480               "$templatedir/slapd.access.template.in",
481               "$templatedir/slapd.conf.template.in",
482               "$templatedir/slapd.replicas.template.in"
483             ],
484         );

Any idea what is wrong?

This is on native openSUSE, where I removed the previously installed rpms and
re-installed the packages fresh from the repository.

-- 
Richard


From issues at kolab.org  Mon Dec 28 22:01:02 2009
From: issues at kolab.org (Thomas Reitelbach)
Date: Mon, 28 Dec 2009 21:01:02 +0000
Subject: [Kolab-devel] [issue4008] licking on an URL in an E-Mail message
	opens the wrong	URL in the browser
In-Reply-To: <1262034062.2.0.664462377523.issue4008@kolab.org>
Message-ID: <1262034062.2.0.664462377523.issue4008@kolab.org>


New submission from Thomas Reitelbach <tr at erdfunkstelle.de>:

Summary: Clicking on an URL in an E-Mail message opens the wrong URL in the
browser
Product: kmail
OS/Version: MS Windows
Version:           1.10.1 (enterprise4 0.20091204.1058385) (using 4.2.2 (KDE
4.2.2), MinGW 3.4.5)
Compiler:          gcc.exe
OS:                Microsoft Windows (i686) release 5.1 (XP Professional)

I'm using Kontact for Windows, beta from 2009-12-04, e4 branch.

I received an E-Mail (plain text!) which has a Link to a website inside. When I
click on this address it opens in the browser, but the browser opens the wrong
URL.

This is the Mail message (example from mailman, happens on other messages as
well):
===================================================
The kde-i18n-de at kde.org mailing list has 1 request(s) waiting for your
consideration at:

        https://mail.kde.org/mailman/admindb/kde-i18n-de

Please attend to this at your earliest convenience.  This notice of
pending requests, if any, will be sent out daily.


Pending posts:
From: michalm at jabster.pl on Sun Dec 20 22:17:06 2009
Subject: [Bug 219421] K3b/German: apostrophes in audio patterns should not be
translated
Cause: Post by non-member to a members-only list
===================================================

When I click on the Adress https://mail.kde.org/mailman/admindb/kde-i18n-de it
will ask me for an application to open this address with. I choose Firefox,
which immediately launches 2 windows. One firefox-window opens with the default
homepage, the other one shows an error page that the URL cannot be found. In
the address bar of firefox I see this URL instead of the correct one:
http://mailman/admindb/kde-i18n-de

A similiar error happens with Internet explorer, which tries to load
c:///C:/mailman/admindb/kde-i18n-de instead.

It seems, URL handling in the email message window is not working correct - it
is beeing detected as a local URL instead of a http(s) url.

Cheers
Thomas

----------
keyword: enterprise4, kde client, windows
messages: 22954
nosy: reitelbach
priority: bug
status: unread
title: licking on an URL in an E-Mail message opens the wrong URL in the browser

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


From ml at radoeka.nl  Mon Dec 28 22:20:03 2009
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 28 Dec 2009 22:20:03 +0100
Subject: [Kolab-devel] kolab_bootstrap fails on a fresh installed system
In-Reply-To: <200912282139.12276.ml@radoeka.nl>
References: <200912282139.12276.ml@radoeka.nl>
Message-ID: <200912282220.03255.ml@radoeka.nl>

Op maandag 28 december 2009 21:39:12 schreef Richard Bos:
> Hi,
> 
> 'kolab_bootstrap -b' fails with the following error:
> 
> IMPORTANT NOTE:
> use login=manager and passwd=xxxxx when you log into the webinterface!
> 
> Enter fully qualified hostname of slave kolab server e.g.
>  thishost.domain.tld (empty when done): prepare LDAP database...
> DEBUG: tpl = /etc/kolab/templates/slapd.access.template.in
> Use of uninitialized value $cfg in concatenation (.) or string at
>  /usr/lib/perl5/vendor_perl/5.10.0/Kolab/Conf.pm line 622, <TEMPLATE> line
>  3978. DEBUG: cfg =
> Use of uninitialized value $cfg in hash element at
>  /usr/lib/perl5/vendor_perl/5.10.0/Kolab/Conf.pm line 623, <TEMPLATE> line
>  3978. Use of uninitialized value $cfg in hash element at
>  /usr/lib/perl5/vendor_perl/5.10.0/Kolab/Conf.pm line 623, <TEMPLATE> line
>  3978. Use of uninitialized value $cfg in hash element at
>  /usr/lib/perl5/vendor_perl/5.10.0/Kolab/Conf.pm line 623, <TEMPLATE> line
>  3978. Use of uninitialized value in scalar assignment at
>  /usr/lib/perl5/vendor_perl/5.10.0/Kolab/Conf.pm line 119, <TEMPLATE> line
>  3978.
> 
> I added the "DEBUG:" statements.
> 
> This is in the following part of the code:
> 615     # defaults to all templates
> 616     $args{templates} = [ keys %templates ] if !exists $args{templates};
> 617     my $cfg;
> 618     my $tpl;
> 619     foreach $tpl (@{$args{templates}}) {
> 620         $cfg = $templates{$tpl};
> 621 print "DEBUG: tpl = $tpl\n";
> 622 print "DEBUG: cfg = $cfg\n";
> 623         build($tpl, $cfg, $ownership{$cfg}, $permissions{$cfg},
>  $commentchar{$cfg}); 624      }
> 
> The function is called with:
> 477       Kolab::Conf::rebuildTemplates(
> 478             dorunonchange =>0,
> 479             templates => [
> 480               "$templatedir/slapd.access.template.in",
> 481               "$templatedir/slapd.conf.template.in",
> 482               "$templatedir/slapd.replicas.template.in"
> 483             ],
> 484         );
> 
> Any idea what is wrong?

Found the culprit!  The above templates should have been used without ".in" 
suffix.

Something else that happens during bootstrap is this:
Enter fully qualified hostname of slave kolab server e.g. thishost.domain.tld 
(empty when done): 
prepare LDAP database... 
Use of uninitialized value $Kolab::config{"is_master"} in string eq at 
/usr/lib/perl5/vendor_perl/5.10.0/Kolab/Conf.pm line 470, <GEN5> line 16.

This did not happen before. Can this be fixed?

-- 
Richard


From thomas at intevation.de  Tue Dec 29 12:55:06 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Tue, 29 Dec 2009 12:55:06 +0100
Subject: [Kolab-devel] Kolab Server 2.2.3 RC1 -- please test!
In-Reply-To: <200912221025.01859.alex@ap-consulting.co.uk>
References: <s7wws0l5ykz.fsf@intevation.de>
	<20091222092916.308399655.thomas@intevation.de>
	<200912221025.01859.alex@ap-consulting.co.uk>
Message-ID: <20091229125243.999744323.thomas@intevation.de>

* Alex Potter <alex at ap-consulting.co.uk> [20091222 11:25]:
> Is there an automated test suite to give the system a hammering?

There are some scripts in CVS /utils/testing that work on a running
Kolab server and there are automated tests for the PHP components
that will be called with 'make test' in a CVS checkout.

Regards,
Thomas Arendsen Hein

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From thomas at intevation.de  Tue Dec 29 13:03:45 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Tue, 29 Dec 2009 13:03:45 +0100
Subject: [Kolab-devel] kolab_bootstrap fails on a fresh installed system
In-Reply-To: <200912282220.03255.ml@radoeka.nl>
References: <200912282139.12276.ml@radoeka.nl>
	<200912282220.03255.ml@radoeka.nl>
Message-ID: <20091229125741.673641135.thomas@intevation.de>

* Richard Bos <ml at radoeka.nl> [20091228 22:20]:
> Op maandag 28 december 2009 21:39:12 schreef Richard Bos:
> > 'kolab_bootstrap -b' fails with the following error:
> > 
> > Use of uninitialized value $cfg in concatenation (.) or string at
> >  /usr/lib/perl5/vendor_perl/5.10.0/Kolab/Conf.pm line 622, <TEMPLATE> line
> > 
> > The function is called with:
> > 477       Kolab::Conf::rebuildTemplates(
> > 478             dorunonchange =>0,
> > 479             templates => [
> > 480               "$templatedir/slapd.access.template.in",
> > 481               "$templatedir/slapd.conf.template.in",
> > 482               "$templatedir/slapd.replicas.template.in"
> > 483             ],
> > 484         );
> > 
> > Any idea what is wrong?
> 
> Found the culprit!  The above templates should have been used without ".in" 
> suffix.

Mathieu changed this in HEAD on December 13th.

I did not have time to look at changes in HEAD for a while.

> Something else that happens during bootstrap is this:
> Enter fully qualified hostname of slave kolab server e.g. thishost.domain.tld 
> (empty when done): 
> prepare LDAP database... 
> Use of uninitialized value $Kolab::config{"is_master"} in string eq at 
> /usr/lib/perl5/vendor_perl/5.10.0/Kolab/Conf.pm line 470, <GEN5> line 16.
> 
> This did not happen before. Can this be fixed?

Might be a similar new change. Maybe you can look at the recent
changes on the kolab-commits list?

Regards,
Thomas Arendsen Hein

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From thomas at intevation.de  Tue Dec 29 13:12:58 2009
From: thomas at intevation.de (Thomas Arendsen Hein)
Date: Tue, 29 Dec 2009 13:12:58 +0100
Subject: [Kolab-devel] Separating sources from OpenPKG packaging
In-Reply-To: <20091209075133.GA47405@xs4all.nl>
References: <20091208231529.53047dgndzthsohs@webmail.pardus.de>
	<20091209075133.GA47405@xs4all.nl>
Message-ID: <20091229131129.146771067.thomas@intevation.de>

* Richard Bos <ml at radoeka.nl> [20091209 08:51]:
> So, actually what you want to do is to move the directories
>  server/kolabd/kolabd           to src/kolabd
>  server/kolab-admin/kolab-admin to src/kolab-admin
>  and
>  server/perl-kolab              to src/perl-kolab

Please keep everything somewhere below server, I don't want a
different module (or directory) here, only subdirectories of server.

Regards,
Thomas Arendsen Hein

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From ml at radoeka.nl  Tue Dec 29 13:47:54 2009
From: ml at radoeka.nl (Richard Bos)
Date: Tue, 29 Dec 2009 13:47:54 +0100
Subject: [Kolab-devel] kolab_bootstrap fails on a fresh installed system
In-Reply-To: <20091229125741.673641135.thomas@intevation.de>
References: <200912282139.12276.ml@radoeka.nl>
	<200912282220.03255.ml@radoeka.nl>
	<20091229125741.673641135.thomas@intevation.de>
Message-ID: <200912291347.54685.ml@radoeka.nl>

Op dinsdag 29 december 2009 13:03:45 schreef Thomas Arendsen Hein:
> > Found the culprit!  The above templates should have been used without
> > ".in"  suffix.
> 
> Mathieu changed this in HEAD on December 13th.

Yes, I know.


> I did not have time to look at changes in HEAD for a while.
> 
> > Something else that happens during bootstrap is this:
> > Enter fully qualified hostname of slave kolab server e.g.
> > thishost.domain.tld  (empty when done):
> > prepare LDAP database... 
> > Use of uninitialized value $Kolab::config{"is_master"} in string eq at 
> > /usr/lib/perl5/vendor_perl/5.10.0/Kolab/Conf.pm line 470, <GEN5> line 16.
> > 
> > This did not happen before. Can this be fixed?
> 
> Might be a similar new change. 

Indeed.

> Maybe you can look at the recent changes on the kolab-commits list?

The ChangeLog is the place where I would look.  I could have a look at, but I 
was just testing packages.  With the current packages I have I can't go to the 
kolab webinterface.  Because of these "not working" changes to cvs, I don't if 
this (not working admin interface) is due to bad packages or just the code :(

Hopefully, Mathieu is around so he can have a look at it.

-- 
Richard


From issues at kolab.org  Wed Dec 30 20:36:39 2009
From: issues at kolab.org (Richard Bos)
Date: Wed, 30 Dec 2009 19:36:39 +0000
Subject: [Kolab-devel] [issue4009] kolab_bootstrap contains dangerous code,
	could remove whole filesystem....
In-Reply-To: <1262201799.97.0.0418824492063.issue4009@kolab.org>
Message-ID: <1262201799.97.0.0418824492063.issue4009@kolab.org>


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

There is some dangerous code in kolab_bootstrap, that might remove a whole
filesystem....

kolab_bootstrap contains:
296   print "Cleaning up LDAP\n";
297   system("cd \"$Kolab::config{'ldapserver_dir'}\"; rm -f *");

In case the change directory to the $Kolab::config{'ldapserver_dir'} does not
succeed, or the variable is not defined correctly, things may go quite wrong
(in case one is unlucky).

In the example below I replaced "rm -f *", with "echo rm -f *".  The code is
now:
299   print "Cleaning up LDAP\n";
300   $Kolab::config{'ldapserver_dir'} = "/var/lib/lldap";
301   print "ldapserver_dir = ".$Kolab::config{'ldapserver_dir'}."\n";
302   system("pwd; cd \"$Kolab::config{'ldapserver_dir'}\"; pwd; echo rm -f
*");

When executing this:
# cd /
# /usr/sbin/kolab_bootstrap -b

The result is:
.......
Cleaning up LDAP
ldapserver_dir = /var/lib/lldap
/
sh: line 0: cd: /var/lib/lldap: No such file or directory
/
rm -f bin boot dev etc home lib lost+found media mnt opt proc root sbin selinux
srv sys tmp usr var

Without echo, I would be crying now!

----------
messages: 22967
nosy: mathieu.parent, rbos, thomas, wilde, wrobel
priority: bug
status: unread
title: kolab_bootstrap contains dangerous code, could remove whole filesystem....

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


From ml at radoeka.nl  Wed Dec 30 20:38:00 2009
From: ml at radoeka.nl (Richard Bos)
Date: Wed, 30 Dec 2009 20:38:00 +0100
Subject: [Kolab-devel] kolab_bootstrap fails on a fresh installed system
In-Reply-To: <20091229125741.673641135.thomas@intevation.de>
References: <200912282139.12276.ml@radoeka.nl>
	<200912282220.03255.ml@radoeka.nl>
	<20091229125741.673641135.thomas@intevation.de>
Message-ID: <200912302038.01248.ml@radoeka.nl>

Hi,

Op dinsdag 29 december 2009 13:03:45 schreef Thomas Arendsen Hein:
> > Something else that happens during bootstrap is this:
> > Enter fully qualified hostname of slave kolab server e.g.
> > thishost.domain.tld  (empty when done):
> > prepare LDAP database... 
> > Use of uninitialized value $Kolab::config{"is_master"} in string eq at 
> > /usr/lib/perl5/vendor_perl/5.10.0/Kolab/Conf.pm line 470, <GEN5> line 16.
> > 
> > This did not happen before. Can this be fixed?
> 
> Might be a similar new change. Maybe you can look at the recent
> changes on the kolab-commits list?

It has been fixed.  I just committed the change to cvs, I think that the 
change is obvious.  I also added some lines to prevent warnings like:
creating backup of CA data                                              
mv: cannot stat `*.pem': No such file or directory                      

While investigating this issue, I came acros some dangerous code in 
kolab_bootstrap.  I made an issue for it:
https://issues.kolab.org/issue4009
I gave it a priority bug, but perhaps urgent is better?

-- 
Richard