From soliva at comcept.ch  Sat Jan  2 13:04:42 2010
From: soliva at comcept.ch (ComCept Soliva)
Date: Sat, 2 Jan 2010 13:04:42 +0100
Subject: [Kolab-devel] Kolab Server 2.2.3 Final > Solaris 10
Message-ID: <000001ca8ba3$c4cefcb0$4e6cf610$@ch>

Hi all

First of all a Happy New Year to all Developers and good progress with
Kolab2 in the new year :-)

I was able to test on Solaris 10 Sparc the new release. From this point of
view some issues was solved some issues still exists but are solveable!

I documented the overall installation within the Wiki incl. Listing issues
etc.:

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

Following issues still exist:

https://www.intevation.de/roundup/kolab/issue1809
https://www.intevation.de/roundup/kolab/issue3315
https://www.intevation.de/roundup/kolab/issue1779

Following issues was recognized during installation etc. but for me this did
not have any impact:

If the installation scripts is started you will see follwing errors:

+ cp /kolabtmp/openpkg-20071227-20071227_kolab2.src.rpm
/tmp/install-kolab....201 
+ cp /kolabtmp/openpkg-20071227-20071227_kolab2.src.sh
/tmp/install-kolab....201 
+ ln -sf /kolabtmp/00INDEX.rdf /tmp/install-kolab....201 
ln: -sf: No such file or directory
ln: /tmp/install-kolab....201/00INDEX.rdf: Cross-device link
+ find /kolabtmp -name *.rpm ! -name openpkg-2*.rpm -exec ln -sf {}
/tmp/install-kolab....201 ; 
ln: -sf: No such file or directory
ln: /tmp/install-kolab....201/PEAR-Net_LDAP2-2.0.0RC5-1.src.rpm:
Cross-device link
ln: -sf: No such file or directory
ln: /tmp/install-kolab....201/gcc-4.2.2-20080101.src.rpm: Cross-device link
ln: -sf: No such file or directory
ln: /tmp/install-kolab....201/PEAR-Horde-Channel-1.0-20090119.src.rpm:
Cross-device link
ln: -sf: No such file or directory
ln: /tmp/install-kolab....201/pkgconfig-0.23-20080117.src.rpm: Cross-device
link
............................................................................
..............
............................................................................
..............
............................................................................
..............
............................................................................
..............


This error comes from following positions within the script:



  ln -sf "$SRCDIR/00INDEX.rdf" "$WORKDIR"
  find "$SRCDIR" $FIND1 -name "*.rpm" \! -name "openpkg-2*.rpm" -exec ln -sf
'{}' "$WORKDIR" \;
}





    PACKAGES=`remove_from_list "$EXCLUDEPKGS" "$PACKAGES"`

    find "$DIR" $FIND1 -name "*.$PLATTAG.rpm" -exec ln -sf '{}'
"$PREFIX/RPM/PKG/" \;
    echo "----------- SETUP COMPLETED -----------"
    echo
    echo " Now running:"
    echo
    echo "   $PREFIX/bin/openpkg build -kKBuZ -r \"$DIR\" -p \"$PLATTAG\"
$DEFINE $PACKAGES | sh"
    echo
    echo "---------------------------------------"
    "$PREFIX/bin/openpkg" build -kKBuZ -r "$DIR" -p "$PLATTAG" $DEFINE
$PACKAGES | sh || exit $?
Fi


The reason for this ist hat Solaris 10 does not know the option "ln -sf".
Again as mentioned I only saw the error but I did not have any impact and
the final installation including "bootstrap" etc. was running fine as the
server is know up and running.

I'm looking forward regarding your discussion regarding openPKG V4 etc.
which I saw within the Developer List etc. All logs from the installation
are still available. If you like it tell me otherwise I will delete them in
a view days.

Kind regards

Andrea
 


From math.parent at gmail.com  Sun Jan  3 18:25:23 2010
From: math.parent at gmail.com (Mathieu Parent)
Date: Sun, 3 Jan 2010 18:25:23 +0100
Subject: [Kolab-devel] kolab_bootstrap fails on a fresh installed system
In-Reply-To: <200912302038.01248.ml@radoeka.nl>
References: <200912282139.12276.ml@radoeka.nl>
	<200912282220.03255.ml@radoeka.nl>
	<20091229125741.673641135.thomas@intevation.de>
	<200912302038.01248.ml@radoeka.nl>
Message-ID: <960738411001030925h28259e65o9a7d234aaf93dfc8@mail.gmail.com>

On Wed, Dec 30, 2009 at 8:38 PM, Richard Bos <ml at radoeka.nl> wrote:
> snip
> 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
>
Thanks for those changes. I tested my previous changes with
templates.in and forgot to remove the suffix. Sorry. I definitely need
to find a better way to test CVS HEAD.

>snip
> --
> Richard

Mathieu Parent


From wilde at intevation.de  Mon Jan  4 13:22:33 2010
From: wilde at intevation.de (Sascha Wilde)
Date: Mon, 04 Jan 2010 13:22:33 +0100
Subject: [Kolab-devel] Security Issue 26 for Kolab Server (SpamAssassin)
Message-ID: <s7wvdfinjp2.fsf@intevation.de>

Kolab Security Issue 26 20100104
================================

Package:              Kolab Server, SpamAssassin
Vulnerability:        mail lossage
Kolab Specific:       no
Dependent Packages:   none


Summary
~~~~~~~

The Apache SpamAssassin spam filter shipping with Kolab Server
includes an rule named FH_DATE_PAST_20XX which triggers on most mail
with a Date header that includes the year 2010 or later.

This adds 3.2 to the spam score of nearly every mail send past 2009.


Affected Versions
~~~~~~~~~~~~~~~~~

This affects versions of SpamAssassin 3.2.0 to 3.2.5.
Kolab Server 2.2.3 and previous releases are affected.


Fix
~~~

Add the following line to
/kolab/etc/kolab/templates/local.cf.template:

score FH_DATE_PAST_20XX 0.0

or update your kolabd package:

OpenPKG packages for Kolab Server 2.2.3 are available from
http://files.kolab.org/server/security-updates/20100104/
or from the mirrors listed on http://kolab.org/mirrors.html

A binary RPM for Kolab Server 2.2.3 (ix86 Debian GNU/Linux Lenny)
is available as kolabd-2.2.3-20100104.ix86-debian5.0-kolab.rpm

A binary RPM for Kolab Server 2.2.3 (ix86 Debian GNU/Linux Etch)
is available as kolabd-2.2.3-20100104.ix86-debian4.0-kolab.rpm

After that run as root: /kolab/sbin/kolabconf

Older versions of Kolab Server don't have local.cf.template, you
will have to edit /kolab/etc/spamassassin/local.cf and after that
restart amavisd with: /kolab/etc/rc.d/rc.amavisd restart

You can check the integrity of the downloaded files with:

$ gpg --keyserver keys.gnupg.net --recv-key 4BB86568
$ gpg --verify SHA1SUMS.sig
$ sha1sum -c SHA1SUMS

The source package can be compiled and installed on your Kolab Server with:

# su - kolab
$ openpkg rpm --rebuild ...path/to.../kolabd-2.2.3-20100104.src.rpm
$ openpkg rpm -Uvh /kolab/RPM/PKG/kolabd-2.2.3-20100104.<ARCH>-<OS>-kolab.rpm	
$ exit
# /kolab/sbin/kolabconf

To install a binary package, just skip the --rebuild step.


Details
~~~~~~~

http://wiki.apache.org/spamassassin/Rules/FH_DATE_PAST_20XX
	Description of the problematic rule including note on the
	misbehavior of older versions.

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269
	Bug report in the official upstream tracker.

Timeline
~~~~~~~~
    20100101 Upstream Bug Report
    20100102 Discussion and hotfix on kolab-users at kolab.org
    20100104 Updated kolabd package available and Kolab Server
             security advisory published.
-- 
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/20100104/ca0d1113/attachment.bin

From ml at radoeka.nl  Mon Jan  4 17:48:52 2010
From: ml at radoeka.nl (Richard Bos)
Date: Mon, 4 Jan 2010 16:48:52 +0000
Subject: [Kolab-devel] richard: server/perl-kolab/sbin
	kolab_bootstrap.in, 1.14, 1.15
In-Reply-To: <20091230192222.87EDD60014C@lists.intevation.de>
References: <20091230192222.87EDD60014C@lists.intevation.de>
Message-ID: <201001041648.52232.ml@radoeka.nl>

Op woensdag 30 december 2009 19:22:22 schreef cvs at kolab.org:
> +$Kolab::config{"is_master"} = $is_master;

/me wondering if some code needs to be done for this.  There are now variables 
used for the 'master' status of kolab, being: is_master and 
$Kolab::config{"is_master"}.  This could lead to problems in the future when 
code is added that affects the 'master' status variable.  I would propose to 
replace all $is_master with $Kolab::config{"is_master"} to prevent confusion 
in the future....

-- 
Richard


From issues at kolab.org  Tue Jan  5 12:19:16 2010
From: issues at kolab.org (Bernhard Reiter)
Date: Tue, 05 Jan 2010 11:19:16 +0000
Subject: [Kolab-devel] [issue4011] crash when printing events to a printer
	(not a file)
In-Reply-To: <1262690356.96.0.202925001416.issue4011@kolab.org>
Message-ID: <1262690356.96.0.202925001416.issue4011@kolab.org>


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

A customer with Version 1.2.9 (enterprise35 20090918.1030082) on Debian
reports frequent crashes when printing a day or a week of appointments
to a printer. Printing to file seems to work. 
Though I cannot directly reproduce, here is a backtrace I have from the user.

Is there a good chance that this has been fixed meanwhile?

>  [KCrash handler]
>  #5  KCal::Calendar::events (this=0x0, date=@0xbf9fb1d4, 
>      sortField=KCal::EventSortStartDate, 
>      sortDirection=KCal::SortDirectionAscending) at calendar.cpp:255
>  #6  0xb54e3af3 in CalPrintDay::print (this=0x9162ca8, p=@0xbf9fb22c, 
>      width=697, height=1059) at calprintdefaultplugins.cpp:717
>  #7  0xb54da5eb in CalPrintPluginBase::doPrint (this=0x9162ca8, 
>      printer=0xbf9fb3d4) at calprintpluginbase.cpp:167
>  #8  0xb54cdcd5 in CalPrinter::doPrint (this=0xbf9fb5dc, 
>      selectedStyle=0x9162ca8, dlgorientation=CalPrinter::eOrientPrinter, 
>      preview=false) at calprinter.cpp:156
>  #9  0xb54ce220 in CalPrinter::print (this=0xbf9fb5dc, type=100, 
>      fd=@0x8c4e988, td=@0x8c4e988, selectedIncidences=@0xbf9fb63c, 
>      preview=false) at calprinter.cpp:121
>  #10 0xb56b99e7 in KOEventPopupMenu::print (this=0x8c4e8b8)
>      at koeventpopupmenu.cpp:145
>  #11 0xb56bbff0 in KOEventPopupMenu::qt_invoke (this=0x8c4e8b8, _id=61, 
>      _o=0xbf9fb6f8) at koeventpopupmenu.moc:273
>  #12 0xb701ad4f in QObject::activate_signal (this=0x8c4f9c0, clist=0x8c4f0d8, 
>      o=0xbf9fb6f8) at kernel/qobject.cpp:2356
>  #13 0xb73a3bbb in QSignal::signal (this=0x8c4f9c0, t0=@0x8c4f9e8)
>      at .moc/debug-shared-mt/moc_qsignal.cpp:100
>  #14 0xb703a8d2 in QSignal::activate (this=0x8c4f9c0) at 
kernel/qsignal.cpp:212
>  #15 0xb713fd59 in QPopupMenu::mouseReleaseEvent (this=0x8c4e8b8, 
e=0xbf9fbc14)
>      at widgets/qpopupmenu.cpp:1697

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22981
nosy: allen, bernhard, till, tmcguire
priority: urgent
status: unread
title: crash when printing events to a printer (not a file)

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


From issues at kolab.org  Wed Jan  6 17:13:13 2010
From: issues at kolab.org (Bernhard Reiter)
Date: Wed, 06 Jan 2010 16:13:13 +0000
Subject: [Kolab-devel] [issue4013] Make KMail-Archive format input the
	default
In-Reply-To: <1262794393.68.0.454478875107.issue4013@kolab.org>
Message-ID: <1262794393.68.0.454478875107.issue4013@kolab.org>


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

In the import menu item, please make the importing the KMail Archive format the 
default.

Split out from kolab/issue3747 (Better archiving function for a branch 
(subtree) of folders (rt#5817))

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22995
nosy: allen, bernhard, emanuel, ludwig, till, tmcguire
priority: bug
status: unread
title: Make KMail-Archive format input the default

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


From issues at kolab.org  Wed Jan  6 17:16:11 2010
From: issues at kolab.org (Bernhard Reiter)
Date: Wed, 06 Jan 2010 16:16:11 +0000
Subject: [Kolab-devel] [issue4014] Better Archiving zip -> tar.bz2 default.
	No /tmp usage.	(rt#5817)
In-Reply-To: <1262794571.86.0.611356852425.issue4014@kolab.org>
Message-ID: <1262794571.86.0.611356852425.issue4014@kolab.org>


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

Currently it seems the zip archiving is suboptimal (Size, missing directories)
please make tar.bz2 the default on GNU/Linux.

Also would it be possible to get a tar.bz2 without the use of an 
intermediate /tmp/kde-xxs/ktar..x.tar file?

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 22996
nosy: allen, bernhard, emanuel, ludwig, till, tmcguire
priority: bug
status: unread
title: Better Archiving zip -> tar.bz2 default. No /tmp usage. (rt#5817)

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


From issues at kolab.org  Thu Jan  7 12:59:33 2010
From: issues at kolab.org (Bernhard Reiter)
Date: Thu, 07 Jan 2010 11:59:33 +0000
Subject: [Kolab-devel] [issue4015] Archiving file selector does not keep the
	suggested file	name when changing the directory. (rt#5817)
In-Reply-To: <1262865573.93.0.900352774014.issue4015@kolab.org>
Message-ID: <1262865573.93.0.900352774014.issue4015@kolab.org>


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

3.5.10.enterprise.0.20091211.1065532-kk4
when trying to go a different directory in the file selector for writing
the archive file, it will lose the suggested filename.
The suggested filename should stay there. (Similiar like it does 
with saving message as.)

Split out from kolab/issue3747 (Better archiving function for a branch 
(subtree) of folders (rt#5817).

----------
assignedto: tmcguire
keyword: enterprise35, kde client, kkc
messages: 23005
nosy: allen, bernhard, emanuel, till, tmcguire
priority: bug
status: unread
title: Archiving file selector does not keep the suggested file name when changing the directory. (rt#5817)

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


From wrobel at pardus.de  Fri Jan  8 14:37:45 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 08 Jan 2010 14:37:45 +0100
Subject: [Kolab-devel] Call for testing and proposal
	for	kolab-test-toolbox
In-Reply-To: <20091218115515.834030348.thomas@intevation.de>
References: <960738410912031029x63e4a937ocf38c6c6411f60f0@mail.gmail.com>
	<20091204084157.16567iqooz02mz4s@webmail.pardus.de>
	<20091218115515.834030348.thomas@intevation.de>
Message-ID: <20100108143745.72299xh27st31x68@webmail.pardus.de>

Quoting Thomas Arendsen Hein <thomas at 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?

No but developers on different distributions. Having a decent tar.gz  
might help.

Cheers,

Gunnar

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



-- 
____ 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 wrobel at pardus.de  Fri Jan  8 14:41:21 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 08 Jan 2010 14:41:21 +0100
Subject: [Kolab-devel] Brain Dump of the Week -- High Hopes
In-Reply-To: <s7wskb842cu.fsf@intevation.de>
References: <s7wskb842cu.fsf@intevation.de>
Message-ID: <20100108144121.634352b24myfudc0@webmail.pardus.de>

Quoting Sascha Wilde <wilde at 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.

I'm on this now. I should be able to remove all TODOs during the next  
two weeks. Of course people are welcome to double check that I don't  
miss anything :) As Sascha mentioned there are a lot of things  
currently just available in the kolab_2_2_branch.

Cheers,

Gunnar

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



-- 
______ 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/20100108/6a86abbd/attachment.bin

From wrobel at pardus.de  Fri Jan  8 15:51:35 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 08 Jan 2010 15:51:35 +0100
Subject: [Kolab-devel] Fwd: Cyrus IMAPd 2.3.16 Released
In-Reply-To: <200912222111.42460.ml@radoeka.nl>
References: <200912221033.28665.martin.konold@erfrakon.de>
	<200912222054.36853.ml@radoeka.nl>
	<200912222107.15534.martin.konold@erfrakon.de>
	<200912222111.42460.ml@radoeka.nl>
Message-ID: <20100108155135.11512t97fgiyg800@webmail.pardus.de>

Quoting Richard Bos <ml at 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.

The original patch we had was not accepted by the cyrus team. I don't  
know why Thomas actually wrote his patch but it had a higher quality  
and allowed configuring the actual annotation entries which was  
considered mandatory by the cyrus team.

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/20100108/e47f24bb/attachment.bin

From wrobel at pardus.de  Fri Jan  8 15:51:36 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 08 Jan 2010 15:51:36 +0100
Subject: [Kolab-devel] Fwd: Cyrus IMAPd 2.3.16 Released
In-Reply-To: <200912222111.42460.ml@radoeka.nl>
References: <200912221033.28665.martin.konold@erfrakon.de>
	<200912222054.36853.ml@radoeka.nl>
	<200912222107.15534.martin.konold@erfrakon.de>
	<200912222111.42460.ml@radoeka.nl>
Message-ID: <20100108155136.14737a743nb3w680@webmail.pardus.de>

Quoting Richard Bos <ml at 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.

The original patch we had was not accepted by the cyrus team. I don't  
know why Thomas actually wrote his patch but it had a higher quality  
and allowed configuring the actual annotation entries which was  
considered mandatory by the cyrus team.

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/20100108/cc255c0b/attachment.bin

From wrobel at pardus.de  Fri Jan  8 15:54:53 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 08 Jan 2010 15:54:53 +0100
Subject: [Kolab-devel] Fwd: Cyrus IMAPd 2.3.16 Released
In-Reply-To: <20091222123508.212531499.thomas@intevation.de>
References: <200912221033.28665.martin.konold@erfrakon.de>
	<20091222123508.212531499.thomas@intevation.de>
Message-ID: <20100108155453.202865mh91aktzwg@webmail.pardus.de>

Quoting Thomas Arendsen Hein <thomas at 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!

I updated the patches and the package for 2.3.16 last week. So we will  
have it in the next version. Maybe some of the native distributions  
are quicker testing it and can report back if everything looks okay :)

Feedback would be good as I had some conflicts in the current patch  
queue for cyrus and so there were changes that need testing. The one  
thing was the annotation patch of course and the second thing that  
needed modification was logging the expunge operation when  
auto-expunging mailboxes on logout.

Cheers,

Gunnar

>
> 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
>
> _______________________________________________
> 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/20100108/bf9ff01e/attachment.bin

From wrobel at pardus.de  Fri Jan  8 16:12:00 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 08 Jan 2010 16:12:00 +0100
Subject: [Kolab-devel] Separating sources from OpenPKG packaging
In-Reply-To: <20091229131129.146771067.thomas@intevation.de>
References: <20091208231529.53047dgndzthsohs@webmail.pardus.de>
	<20091209075133.GA47405@xs4all.nl>
	<20091229131129.146771067.thomas@intevation.de>
Message-ID: <20100108161200.64545k3ai5dxk1s0@webmail.pardus.de>

Quoting Thomas Arendsen Hein <thomas at 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.
>

Can you detail why?

Keeping them on the same level would indicate to me that the source  
directories have similar content to the packaging directories. Which  
they don't.

Cheers,

Gunnar

> 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
>
> _______________________________________________
> 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/20100108/9c3498a4/attachment-0001.bin

From wrobel at pardus.de  Fri Jan  8 16:17:27 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 08 Jan 2010 16:17:27 +0100
Subject: [Kolab-devel] Kolab Server 2.2.3 Final > Solaris 10
In-Reply-To: <000001ca8ba3$c4cefcb0$4e6cf610$@ch>
References: <000001ca8ba3$c4cefcb0$4e6cf610$@ch>
Message-ID: <20100108161727.18612q09qlfzonms@webmail.pardus.de>

Quoting ComCept Soliva <soliva at comcept.ch>:

> Hi all
>
> First of all a Happy New Year to all Developers and good progress with
> Kolab2 in the new year :-)
>
> I was able to test on Solaris 10 Sparc the new release. From this point of
> view some issues was solved some issues still exists but are solveable!
>
> I documented the overall installation within the Wiki incl. Listing issues
> etc.:
>
> https://wiki.kolab.org/index.php/Solaris
>
> Following issues still exist:
>
> https://www.intevation.de/roundup/kolab/issue1809
> https://www.intevation.de/roundup/kolab/issue3315
> https://www.intevation.de/roundup/kolab/issue1779
>
> Following issues was recognized during installation etc. but for me this did
> not have any impact:
>
> If the installation scripts is started you will see follwing errors:
>
> + cp /kolabtmp/openpkg-20071227-20071227_kolab2.src.rpm
> /tmp/install-kolab....201
> + cp /kolabtmp/openpkg-20071227-20071227_kolab2.src.sh
> /tmp/install-kolab....201
> + ln -sf /kolabtmp/00INDEX.rdf /tmp/install-kolab....201
> ln: -sf: No such file or directory
> ln: /tmp/install-kolab....201/00INDEX.rdf: Cross-device link
> + find /kolabtmp -name *.rpm ! -name openpkg-2*.rpm -exec ln -sf {}
> /tmp/install-kolab....201 ;
> ln: -sf: No such file or directory
> ln: /tmp/install-kolab....201/PEAR-Net_LDAP2-2.0.0RC5-1.src.rpm:
> Cross-device link
> ln: -sf: No such file or directory
> ln: /tmp/install-kolab....201/gcc-4.2.2-20080101.src.rpm: Cross-device link
> ln: -sf: No such file or directory
> ln: /tmp/install-kolab....201/PEAR-Horde-Channel-1.0-20090119.src.rpm:
> Cross-device link
> ln: -sf: No such file or directory
> ln: /tmp/install-kolab....201/pkgconfig-0.23-20080117.src.rpm: Cross-device
> link
> ............................................................................
> ..............
> ............................................................................
> ..............
> ............................................................................
> ..............
> ............................................................................
> ..............
>
>
> This error comes from following positions within the script:
>
>
>
>   ln -sf "$SRCDIR/00INDEX.rdf" "$WORKDIR"
>   find "$SRCDIR" $FIND1 -name "*.rpm" \! -name "openpkg-2*.rpm" -exec ln -sf
> '{}' "$WORKDIR" \;
> }
>
>
>
>
>
>     PACKAGES=`remove_from_list "$EXCLUDEPKGS" "$PACKAGES"`
>
>     find "$DIR" $FIND1 -name "*.$PLATTAG.rpm" -exec ln -sf '{}'
> "$PREFIX/RPM/PKG/" \;
>     echo "----------- SETUP COMPLETED -----------"
>     echo
>     echo " Now running:"
>     echo
>     echo "   $PREFIX/bin/openpkg build -kKBuZ -r \"$DIR\" -p \"$PLATTAG\"
> $DEFINE $PACKAGES | sh"
>     echo
>     echo "---------------------------------------"
>     "$PREFIX/bin/openpkg" build -kKBuZ -r "$DIR" -p "$PLATTAG" $DEFINE
> $PACKAGES | sh || exit $?
> Fi
>
>
> The reason for this ist hat Solaris 10 does not know the option "ln -sf".
> Again as mentioned I only saw the error but I did not have any impact and
> the final installation including "bootstrap" etc. was running fine as the
> server is know up and running.
>
> I'm looking forward regarding your discussion regarding openPKG V4 etc.
> which I saw within the Developer List etc.

Moving away from OpenPKG means that we might drop support for some  
distributions or installation variants. Or maybe the quality for some  
of these variants might change. Though I definitely hope that we find  
a solution that avoids dropping support for any of the variants we  
currently support and I also hope that we are able to limit quality  
changes to positive ones :)

Might be hard though. Lets hope for the best.

Cheers,

Gunnar

> All logs from the installation
> are still available. If you like it tell me otherwise I will delete them in
> a view days.
>
> Kind regards
>
> Andrea
>
>
> _______________________________________________
> 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/20100108/9f5ab4f6/attachment.bin

From wrobel at pardus.de  Fri Jan  8 16:27:20 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 08 Jan 2010 16:27:20 +0100
Subject: [Kolab-devel] richard:
	server/perl-kolab/sbin	kolab_bootstrap.in, 1.14, 1.15
In-Reply-To: <201001041648.52232.ml@radoeka.nl>
References: <20091230192222.87EDD60014C@lists.intevation.de>
	<201001041648.52232.ml@radoeka.nl>
Message-ID: <20100108162720.20624v7iwuqsmpkw@webmail.pardus.de>

Quoting Richard Bos <ml at radoeka.nl>:

> Op woensdag 30 december 2009 19:22:22 schreef cvs at kolab.org:
>> +$Kolab::config{"is_master"} = $is_master;
>
> /me wondering if some code needs to be done for this.  There are now  
> variables
> used for the 'master' status of kolab, being: is_master and
> $Kolab::config{"is_master"}.  This could lead to problems in the future when
> code is added that affects the 'master' status variable.  I would propose to
> replace all $is_master with $Kolab::config{"is_master"} to prevent confusion
> in the future....

Can you open an issue with your suggestion? Thomas is currently away  
until the beginning of february and issues are harder to forget :)

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/20100108/8ea14f6d/attachment.bin

From issues at kolab.org  Fri Jan  8 16:32:59 2010
From: issues at kolab.org (Gunnar Wrobel)
Date: Fri, 08 Jan 2010 15:32:59 +0000
Subject: [Kolab-devel] [issue4017] Do not install kolab.php with Horde
In-Reply-To: <1262964779.22.0.335280394878.issue4017@kolab.org>
Message-ID: <1262964779.22.0.335280394878.issue4017@kolab.org>


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

It should be possible to avoid installation of the config/kolab.php file in the
kolab web client. This way we don't get a kolab.php.rpmnew file and don't
confuse people.

----------
assignedto: wrobel
keyword: web client
messages: 23024
nosy: bernhard, martin, thomas, wilde, wrobel
priority: minor bug
status: unread
title: Do not install kolab.php with Horde

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


From wrobel at pardus.de  Fri Jan  8 21:57:46 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Fri, 08 Jan 2010 21:57:46 +0100
Subject: [Kolab-devel] wilde: server/kolabd/kolabd/templates
	local.cf.template.in, 1.1, 1.1.2.1
In-Reply-To: <20100104101647.E5780600563@lists.intevation.de>
References: <20100104101647.E5780600563@lists.intevation.de>
Message-ID: <20100108215746.236771qq03rjqesc@webmail.pardus.de>

Hi Sascha,

Quoting cvs at kolab.org:

> Author: wilde
>
> Update of /kolabrepository/server/kolabd/kolabd/templates
> In directory doto:/tmp/cvs-serv9934/kolabd/kolabd/templates
>
> Modified Files:
>       Tag: kolab_2_2_branch
> 	local.cf.template.in
> Log Message:
> Disabled FH_DATE_PAST_20XX in spamassassin.
>
>
> Index: local.cf.template.in
> ===================================================================
> RCS file:  
> /kolabrepository/server/kolabd/kolabd/templates/local.cf.template.in,v
> retrieving revision 1.1
> retrieving revision 1.1.2.1
> diff -u -d -r1.1 -r1.1.2.1
> --- local.cf.template.in	29 Apr 2008 14:50:49 -0000	1.1
> +++ local.cf.template.in	4 Jan 2010 10:16:45 -0000	1.1.2.1
> @@ -96,3 +96,7 @@
>  # Don't score some common cases too high:
>  score HELO_LOCALHOST 1
>  score TVD_SPACE_RATIO 1
> +
> +# The FH_DATE_PAST_20XX test is broken for 2010 and later
> +# see kolab-vendor-notice-26 for details.
> +score FH_DATE_PAST_20XX 0.0
>
>
> _______________________________________________
> Kolab-commits mailing list
> Kolab-commits at kolab.org
> https://kolab.org/mailman/listinfo/kolab-commits
>

I assume this can be removed if we upgrade to the next version of  
spamassassin. But I don't know if or when that will happen for the  
next Kolab server. So I'd suggest avoiding to merge your commit right  
now but leave a TODO item in our release notes. Do you agree?

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/20100108/2ef2e966/attachment.bin

From issues at kolab.org  Sat Jan  9 16:31:25 2010
From: issues at kolab.org (Xavier Luthi)
Date: Sat, 09 Jan 2010 15:31:25 +0000
Subject: [Kolab-devel] [issue4018] Installation on Kolab server 2.2.3 from
	Sources on Debian	fails
In-Reply-To: <1263051085.97.0.124218435318.issue4018@kolab.org>
Message-ID: <1263051085.97.0.124218435318.issue4018@kolab.org>


New submission from Xavier Luthi <xluthi at gmail.com>:

When trying to install Kolab server 2.2.3 (Version 20091217) from sources
following the 1st.README instructions on Debian sid, the compilation fails on
regex.o


updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
config.status: creating testsuite/Makefile
config.status: creating config.h
config.status: executing default commands
if [ x"" != x ] && [ ! -d pic ]; then \
          mkdir pic; \
        else true; fi
touch stamp-picdir
if [ x"" != x ]; then \
          cc -c -DHAVE_CONFIG_H -g -fkeep-inline-functions -I.
-I/kolab/RPM/TMP/gcc-4.2.2/obj/../libiberty/../include  -W -Wall -pedantic
-Wwrite-strings -Wstrict-prototypes -Wc++-compat 
/kolab/RPM/TMP/gcc-4.2.2/obj/../libiberty/regex.c -o pic/regex.o; \
        else true; fi
cc -c -DHAVE_CONFIG_H -g -fkeep-inline-functions -I.
-I/kolab/RPM/TMP/gcc-4.2.2/obj/../libiberty/../include  -W -Wall -pedantic
-Wwrite-strings -Wstrict-prototypes -Wc++-compat
/kolab/RPM/TMP/gcc-4.2.2/obj/../libiberty/regex.c -o regex.o
/kolab/RPM/TMP/ccEtbcDx.s: Assembler messages:
/kolab/RPM/TMP/ccEtbcDx.s:10: Error: unknown pseudo-op: `.cfi_sections'
make[3]: *** [regex.o] Error 1
make[2]: *** [all-stage1-libiberty] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [bootstrap-lean] Error 2
error: Bad exit status from /kolab/RPM/TMP/rpm-tmp.31049 (%build)


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


The complete installation log file is attached.



The same problem has already been encountered on Ubuntu 9.10 for Kolab server
2.2.2. See http://www.kolab.org/pipermail/kolab-users/2009-December/010713.html


Cheers,
  Xavier

----------
files: kolab-install-20100109-1.log
keyword: debian, server
messages: 23027
nosy: xluthi
priority: urgent
status: unread
title: Installation on Kolab server 2.2.3 from Sources on Debian fails

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4018>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kolab-install-20100109-1.log
Type: application/octet-stream
Size: 32905 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100109/41409a19/kolab-install-20100109-1-0001.exe

From issues at kolab.org  Sun Jan 10 21:32:17 2010
From: issues at kolab.org (Richard Bos)
Date: Sun, 10 Jan 2010 20:32:17 +0000
Subject: [Kolab-devel] [issue4019] Change $is_master to
	$Kolab::config{"is_master"} for	consistentcy
In-Reply-To: <1263155537.71.0.248616347891.issue4019@kolab.org>
Message-ID: <1263155537.71.0.248616347891.issue4019@kolab.org>


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

> Op woensdag 30 december 2009 19:22:22 schreef cvs at kolab.org:
>> +$Kolab::config{"is_master"} = $is_master;
>
> /me wondering if some code needs to be redone for this.  There are now  
> 2 variables used for the 'master' status of kolab, being: $is_master and
> $Kolab::config{"is_master"}.  This could lead to problems in the future when
> code is added that affects the 'master' status variable.  I would propose to
> replace all $is_master with $Kolab::config{"is_master"} to prevent confusion
> in the future....

Gunnar replied with:
Can you open an issue with your suggestion? Thomas is currently away  
until the beginning of february and issues are harder to forget :)

----------
keyword: server
messages: 23029
nosy: mathieu.parent, rbos, thomas, wilde, wrobel
priority: bug
status: unread
title: Change $is_master to $Kolab::config{"is_master"} for consistentcy

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


From thomas at btspuhler.com  Mon Jan 11 04:57:00 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sun, 10 Jan 2010 20:57:00 -0700
Subject: [Kolab-devel] kolab-horde-framework needed for kolab
Message-ID: <201001102057.00752.thomas@btspuhler.com>

Is kolab-horde-framework needed for the kolab to work?
I am still talking about kolab-2.1.0
The reason is that kolab depends on kolab-horde-framework and kolab-horde-
framework conflicts with php-pear-Service_Weather in the Mandriva native 
installation in the current cooker.

-- 
Thomas


From issues at kolab.org  Mon Jan 11 08:02:48 2010
From: issues at kolab.org (Tom Reijnders)
Date: Mon, 11 Jan 2010 07:02:48 +0000
Subject: [Kolab-devel] [issue4020] As domain-maintainer,
	list of domains in Create User form is empty
In-Reply-To: <1263193368.37.0.410586880991.issue4020@kolab.org>
Message-ID: <1263193368.37.0.410586880991.issue4020@kolab.org>


New submission from Tom Reijnders <reijnders at tor.nl>:

OpenSuSE 11.1, UNSTABLE installation server: kolab-2.2.2.90_cvs20091219-3.2

In a multi-domain setup, a domain-maintainer could not create a new user, 
because in the Create user form, the list of domains is empty. Effectively a 
domain-maintainer cannot add a new user to 'his/her' domain.

I had to change the acces to internal ldap objects for domain-maintainers to 
get this working:
in /etc/kolab/templates/slapd.conf.template

access to dn.regex="(.*,)?cn=internal,@@@base_dn@@@"
        by group/kolabGroupOfNames="cn=admin,cn=internal,@@@base_dn@@@" write
        by group/kolabGroupOfNames="cn=maintainer,cn=internal,@@@base_dn@@@" 
write
        by group/kolabGroupOfNames="cn=domain-
maintainer,cn=internal,@@@base_dn@@@" write
        by self write
        by dn="cn=nobody,cn=internal,@@@base_dn@@@" read
        by anonymous auth stop

(Added the domain-maintainer group)

----------
keyword: web admin
messages: 23030
nosy: torinfo
priority: urgent
status: unread
title: As domain-maintainer, list of domains in Create User form is empty

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


From issues at kolab.org  Mon Jan 11 08:13:39 2010
From: issues at kolab.org (Tom Reijnders)
Date: Mon, 11 Jan 2010 07:13:39 +0000
Subject: [Kolab-devel] [issue4021] LDAP Errors displaying users as
	domain-maintainer
In-Reply-To: <1263194019.7.0.400701688311.issue4021@kolab.org>
Message-ID: <1263194019.7.0.400701688311.issue4021@kolab.org>


New submission from Tom Reijnders <reijnders at tor.nl>:

OpenSuSE 11.1, UNSTABLE installation server, kolab-2.2.2.90_cvs20091219-3.2

In a multi-domain setup, when displaying the users as domain-maintainer, I get 
two LDAP errors:

Errors:
LDAP Error: Can't read maintainers group: No such object
LDAP Error: Can't read maintainers group: No such object


See also attached screendump. It doesn't seem to influence opertaions thuogh.

----------
files: LDAP_Error.png
keyword: web admin
messages: 23031
nosy: torinfo
priority: bug
status: unread
title: LDAP Errors displaying users as domain-maintainer

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4021>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LDAP_Error.png
Type: image/x-png
Size: 66526 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100111/90c307ff/LDAP_Error-0001.bin

From wrobel at pardus.de  Mon Jan 11 09:24:13 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 11 Jan 2010 09:24:13 +0100
Subject: [Kolab-devel] kolab-horde-framework needed for kolab
In-Reply-To: <201001102057.00752.thomas@btspuhler.com>
References: <201001102057.00752.thomas@btspuhler.com>
Message-ID: <20100111092413.92639dq6vc9wodv4@webmail.pardus.de>

Hi Thomas,

Quoting Thomas Spuhler <thomas at btspuhler.com>:

> Is kolab-horde-framework needed for the kolab to work?

In a way - yes. We stil use the Horde framework libraries but we  
package them differently nowadays.

> I am still talking about kolab-2.1.0
> The reason is that kolab depends on kolab-horde-framework and kolab-horde-
> framework conflicts with php-pear-Service_Weather in the Mandriva native
> installation in the current cooker.

The PEAR part should not be in the horde framework package. You should  
have a package that packages only the Horde framework code and add  
PEAR packages separately.

Cheers,

Gunnar

>
> --
> Thomas
>
> _______________________________________________
> 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/20100111/3ea9d088/attachment.bin

From issues at kolab.org  Mon Jan 11 14:46:31 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Mon, 11 Jan 2010 13:46:31 +0000
Subject: [Kolab-devel] [issue4022] Kontact crahes if opening an invitation
	mail without	attendees (rt#5931)
In-Reply-To: <1263217591.55.0.507864641835.issue4022@kolab.org>
Message-ID: <1263217591.55.0.507864641835.issue4022@kolab.org>


New submission from Emanuel Schuetze <emanuel at intevation.de>:

Kontact crahes if opening an (external) invitation mail without attendees.
(tested with e35 20091211-1065532)

On 07.01.2010 17:23, Allen Winter <allen at kdab.com> wrote:
> A fix is in place and ready for testing.
> This was a case of an invitation without any attendees.
>
> e35 -> r1071135
> e4 -> r1071151
> enterprise35.0.20091211.1061417 -> r1071136
> enterprise35.0.20091218.1063500 -> r1071143
> enterprise35.0.20100101.1068602 -> r1071145

----------
assignedto: emanuel
keyword: enterprise35, kde client, kkc
messages: 23043
nosy: allen, emanuel
priority: bug
status: testing
title: Kontact crahes if opening an invitation mail without attendees (rt#5931)

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


From wilde at intevation.de  Mon Jan 11 17:49:19 2010
From: wilde at intevation.de (Sascha Wilde)
Date: Mon, 11 Jan 2010 17:49:19 +0100
Subject: [Kolab-devel] wilde: server/kolabd/kolabd/templates
	local.cf.template.in, 1.1, 1.1.2.1
In-Reply-To: <20100108215746.236771qq03rjqesc@webmail.pardus.de> (Gunnar
	Wrobel's message of "Fri, 08 Jan 2010 21:57:46 +0100")
References: <20100104101647.E5780600563@lists.intevation.de>
	<20100108215746.236771qq03rjqesc@webmail.pardus.de>
Message-ID: <s7waawk4meo.fsf@intevation.de>

Gunnar Wrobel <wrobel at pardus.de> writes:
>> +# The FH_DATE_PAST_20XX test is broken for 2010 and later
>> +# see kolab-vendor-notice-26 for details.
>> +score FH_DATE_PAST_20XX 0.0
>
> I assume this can be removed if we upgrade to the next version of
> spamassassin.

Yes, It is supposed to be fixed upstream.

> But I don't know if or when that will happen for the
> next Kolab server. So I'd suggest avoiding to merge your commit right
> now but leave a TODO item in our release notes. Do you agree?

Id prefer it the other way around: Merge it in head but leave a TODO
that it might/should be removed when we update spamassassin.  The
rational is that I don't want to stumble across known (and fixed) issues
when testing HEAD.

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/20100111/c4d89482/attachment.bin

From sascha at deutschkron.de  Mon Jan 11 18:18:18 2010
From: sascha at deutschkron.de (Sascha Deutschkron)
Date: Mon, 11 Jan 2010 18:18:18 +0100
Subject: [Kolab-devel] How to get involved?
Message-ID: <201001111818.22295.sascha@deutschkron.de>

Hi guys,

I'm a senior software developer - with a new toy: an Android phone.
I'm also using and administrating Kolab Groupware Server for a couple of years 
now and I just love it.
Naturally, I want to combine those three passions of mine - software 
development, Android, Kolab.

Therefore, I want to write Kolab clients (calendar, contacts, tasks etc.) for 
the Android system (since I couldn't find any ready solution out there).

How can I get involved? What do I need? How's the process?


Thanks in advance!

Kindest regards
Sascha

-- 
Fear can hold you prisoner.
Hope can set you free!
-------------- 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/20100111/c7ec2a59/attachment.bin

From wrobel at pardus.de  Mon Jan 11 22:49:17 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Mon, 11 Jan 2010 22:49:17 +0100
Subject: [Kolab-devel] How to get involved?
In-Reply-To: <201001111818.22295.sascha@deutschkron.de>
References: <201001111818.22295.sascha@deutschkron.de>
Message-ID: <20100111224917.216229mx21bz02qk@webmail.pardus.de>

Hi Sascha,

Quoting Sascha Deutschkron <sascha at deutschkron.de>:

> Hi guys,
>
> I'm a senior software developer - with a new toy: an Android phone.
> I'm also using and administrating Kolab Groupware Server for a  
> couple of years
> now and I just love it.
> Naturally, I want to combine those three passions of mine - software
> development, Android, Kolab.
>
> Therefore, I want to write Kolab clients (calendar, contacts, tasks etc.) for
> the Android system (since I couldn't find any ready solution out there).
>
> How can I get involved? What do I need? How's the process?

Puh, broad question ... :) Let me give you my view as a client  
developer (Kolab webclient / Horde):

I'd start with choosing the technology you want to use. This is  
probably no easy choice. I could imagine the following options:

  1) having a local Kolab client on the android
  2) using a web based Kolab client
  3) Synchronize the data with the server

For 1) the easiest choice would be to look into Kontact: Can you  
compile it for the android and run it there? Which fixes might be  
needed to get it running? Kontact is by far the most tested and  
feature rich Kolab client out there. So being able to use it with  
minor modifications is the best way to go for a local client. Of  
course you could also consider starting from scratch but in my opinion  
coding a complete groupware client is extremely demanding. And for  
Kolab you need all that Kolab Format reading, the IMAP caching and so  
on and so on. Usually takes a lot of time.

For 2) you check how good or bad the current Kolab web client looks on  
the android. What does it need to look better or be more useable?

For 3) you'd look into the different data exchange models the android  
might support. Does it do SyncML or ActiveSync? Other forms of  
synchronization available? Mind you: I consider synchronizing a lot  
less effective than a real client. Synchronizing data usually  
introduces another transport of data and as groupware data tends to be  
complex each synchronization method usually comes with its own set of  
problems.

In all three areas you can expect to be ongoing work to support mobile  
phones. Once you chose the technology check if you can join the effort.

Hope that helps.

Cheers,

Gunnar

>
>
> Thanks in advance!
>
> Kindest regards
> Sascha
>
> --
> Fear can hold you prisoner.
> Hope can set you free!
>



-- 
______ 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/20100111/16bb1b94/attachment.bin

From sascha at deutschkron.de  Tue Jan 12 07:48:42 2010
From: sascha at deutschkron.de (Sascha Deutschkron)
Date: Tue, 12 Jan 2010 07:48:42 +0100
Subject: [Kolab-devel] How to get involved?
In-Reply-To: <20100111224917.216229mx21bz02qk@webmail.pardus.de>
References: <201001111818.22295.sascha@deutschkron.de>
	<20100111224917.216229mx21bz02qk@webmail.pardus.de>
Message-ID: <201001120748.47130.sascha@deutschkron.de>

Am Montag, 11. Januar 2010 22:49:17 schrieb Gunnar Wrobel:
> Hi Sascha,
> 
> Quoting Sascha Deutschkron <sascha at deutschkron.de>:
> > Hi guys,
> >
> > I'm a senior software developer - with a new toy: an Android phone.
> > I'm also using and administrating Kolab Groupware Server for a
> > couple of years
> > now and I just love it.
> > Naturally, I want to combine those three passions of mine - software
> > development, Android, Kolab.
> >
> > Therefore, I want to write Kolab clients (calendar, contacts, tasks etc.)
> > for the Android system (since I couldn't find any ready solution out
> > there).
> >
> > How can I get involved? What do I need? How's the process?
> 
> Puh, broad question ... :) Let me give you my view as a client
> developer (Kolab webclient / Horde):
> 
> I'd start with choosing the technology you want to use. This is
> probably no easy choice. I could imagine the following options:
> 
>   1) having a local Kolab client on the android
>   2) using a web based Kolab client
>   3) Synchronize the data with the server
> 
> For 1) the easiest choice would be to look into Kontact: Can you
> compile it for the android and run it there? Which fixes might be
> needed to get it running? Kontact is by far the most tested and
> feature rich Kolab client out there. So being able to use it with
> minor modifications is the best way to go for a local client. Of
> course you could also consider starting from scratch but in my opinion
> coding a complete groupware client is extremely demanding. And for
> Kolab you need all that Kolab Format reading, the IMAP caching and so
> on and so on. Usually takes a lot of time.
> 
> For 2) you check how good or bad the current Kolab web client looks on
> the android. What does it need to look better or be more useable?
> 
> For 3) you'd look into the different data exchange models the android
> might support. Does it do SyncML or ActiveSync? Other forms of
> synchronization available? Mind you: I consider synchronizing a lot
> less effective than a real client. Synchronizing data usually
> introduces another transport of data and as groupware data tends to be
> complex each synchronization method usually comes with its own set of
> problems.
> 
> In all three areas you can expect to be ongoing work to support mobile
> phones. Once you chose the technology check if you can join the effort.
> 
> Hope that helps.
> 
> Cheers,
> 
> Gunnar
> 
> > Thanks in advance!
> >
> > Kindest regards
> > Sascha
> >
> > --
> > Fear can hold you prisoner.
> > Hope can set you free!
> >
>     >> Mail at ease - Rent a kolab groupware server at p at rdus <<
> 
> --------------------------------------------------------------------
> 
Hi Gunnar,

thanks for your answer. Yes, I plan to write a local Kolab client for Android. 
Therefore I enlisted with this forum here because I thought that would be the 
correct place to start. But the more I think about it the more I get the 
impression that I will have to start a new open source project of my own.
Intentionally I wanted to join an open source community to achieve my plans. 
And I thought kolab-devel would be a community to develop Kolab clients. Was I 
wrong?
If so, I will simply start my own little project.

Sorry for asking maybe dumb questions but although I'm working with open 
source now for about 15 years, I never came around to join one community. And 
now that I finally find the time for it, it seems that I have to start my own 
community - right?

Cheers
Sascha

-- 
Fear can hold you prisoner.
Hope can set you free!
-------------- 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/20100112/36f98640/attachment.bin

From bernhard at intevation.de  Tue Jan 12 09:38:05 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 12 Jan 2010 09:38:05 +0100
Subject: [Kolab-devel] How to get involved?
In-Reply-To: <201001120748.47130.sascha@deutschkron.de>
References: <201001111818.22295.sascha@deutschkron.de>
	<20100111224917.216229mx21bz02qk@webmail.pardus.de>
	<201001120748.47130.sascha@deutschkron.de>
Message-ID: <201001120938.09278.bernhard@intevation.de>

Sascha,

Am Dienstag, 12. Januar 2010 07:48:42 schrieb Sascha Deutschkron:
> thanks for your answer. Yes, I plan to write a local Kolab client for
> Android. Therefore I enlisted with this forum here because I thought that
> would be the correct place to start. 

yes, this is the right place and you are highly welcome!
We would love to have an Android Kolab client and we have happy to assist you 
with anything that you can assist you with! :)

> But the more I think about it the more 
> I get the impression that I will have to start a new open source project of
> my own. Intentionally I wanted to join an open source community to achieve
> my plans. And I thought kolab-devel would be a community to develop Kolab
> clients. Was I wrong?
> If so, I will simply start my own little project.

You are absolutely right about that kolab-devel@ is the place to start and ask
any questions that you have. Occasionally you could also use kolab-format@ and 
the user lists, e.g. to ask format questions or to announce your plans and 
test versions for other users.

The wiki.kolab.org is open to take up your plans, finding and documentation!
We also offer to you the platform wald.intevation.org for file and SCM space
for your code, if that is useful for you.

Note that I am usually makeing a difference just in language between 
community, an initiative and a software product. We as kolab-devel@ are the 
Kolab server and client initiative a part of the Kolab community. We do 
create several software products and thus we use several software 
repositories and other infrastructure things.

> Sorry for asking maybe dumb questions but although I'm working with open
> source now for about 15 years, I never came around to join one community.
> And now that I finally find the time for it, it seems that I have to start
> my own community - right?

Well you do both from my point of view, you do join the Kolab Community and I 
hope you will join our initiative on kolab-devel at . At the same time you might 
or might not need your own repository, e.g. on wald for your new code. But 
that depends on your technical choices. 

Best Regards,
Bernhard

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

From wrobel at pardus.de  Tue Jan 12 09:38:43 2010
From: wrobel at pardus.de (Gunnar Wrobel)
Date: Tue, 12 Jan 2010 09:38:43 +0100
Subject: [Kolab-devel] How to get involved?
In-Reply-To: <201001120748.47130.sascha@deutschkron.de>
References: <201001111818.22295.sascha@deutschkron.de>
	<20100111224917.216229mx21bz02qk@webmail.pardus.de>
	<201001120748.47130.sascha@deutschkron.de>
Message-ID: <20100112093843.268663sdovo1jrwg@webmail.pardus.de>

Hi Sascha,

Quoting Sascha Deutschkron <sascha at deutschkron.de>:

> Am Montag, 11. Januar 2010 22:49:17 schrieb Gunnar Wrobel:
>> Hi Sascha,
>>
>> Quoting Sascha Deutschkron <sascha at deutschkron.de>:
>> > Hi guys,
>> >
>> > I'm a senior software developer - with a new toy: an Android phone.
>> > I'm also using and administrating Kolab Groupware Server for a
>> > couple of years
>> > now and I just love it.
>> > Naturally, I want to combine those three passions of mine - software
>> > development, Android, Kolab.
>> >
>> > Therefore, I want to write Kolab clients (calendar, contacts, tasks etc.)
>> > for the Android system (since I couldn't find any ready solution out
>> > there).
>> >
>> > How can I get involved? What do I need? How's the process?
>>
>> Puh, broad question ... :) Let me give you my view as a client
>> developer (Kolab webclient / Horde):
>>
>> I'd start with choosing the technology you want to use. This is
>> probably no easy choice. I could imagine the following options:
>>
>>   1) having a local Kolab client on the android
>>   2) using a web based Kolab client
>>   3) Synchronize the data with the server
>>
>> For 1) the easiest choice would be to look into Kontact: Can you
>> compile it for the android and run it there? Which fixes might be
>> needed to get it running? Kontact is by far the most tested and
>> feature rich Kolab client out there. So being able to use it with
>> minor modifications is the best way to go for a local client. Of
>> course you could also consider starting from scratch but in my opinion
>> coding a complete groupware client is extremely demanding. And for
>> Kolab you need all that Kolab Format reading, the IMAP caching and so
>> on and so on. Usually takes a lot of time.
>>
>> For 2) you check how good or bad the current Kolab web client looks on
>> the android. What does it need to look better or be more useable?
>>
>> For 3) you'd look into the different data exchange models the android
>> might support. Does it do SyncML or ActiveSync? Other forms of
>> synchronization available? Mind you: I consider synchronizing a lot
>> less effective than a real client. Synchronizing data usually
>> introduces another transport of data and as groupware data tends to be
>> complex each synchronization method usually comes with its own set of
>> problems.
>>
>> In all three areas you can expect to be ongoing work to support mobile
>> phones. Once you chose the technology check if you can join the effort.
>>
>> Hope that helps.
>>
>> Cheers,
>>
>> Gunnar
>>
>> > Thanks in advance!
>> >
>> > Kindest regards
>> > Sascha
>> >
>> > --
>> > Fear can hold you prisoner.
>> > Hope can set you free!
>> >
>>     >> Mail at ease - Rent a kolab groupware server at p at rdus <<
>>
>> --------------------------------------------------------------------
>>
> Hi Gunnar,
>
> thanks for your answer. Yes, I plan to write a local Kolab client  
> for Android.
> Therefore I enlisted with this forum here because I thought that would be the
> correct place to start. But the more I think about it the more I get the
> impression that I will have to start a new open source project of my own.
> Intentionally I wanted to join an open source community to achieve my plans.
> And I thought kolab-devel would be a community to develop Kolab  
> clients. Was I
> wrong?
> If so, I will simply start my own little project.
>
> Sorry for asking maybe dumb questions but although I'm working with open
> source now for about 15 years, I never came around to join one community. And
> now that I finally find the time for it, it seems that I have to start my own
> community - right?

I hope I did not give you the impression that you asked a dumb  
question. Not at all and that would not have been my intention. I was  
not certain about the approach you'd like to choose and just tried to  
highlight the different options that I can imagine.

So if you want to code your own client then yes: you'd start kind of  
your own little community. However I would hope that this community  
has strong ties to the Kolab community.

Look at the current clients: The outlook connectors have their  
"Outlook environment", the Kontact client usually lives on Linux but  
is going to extend into the Windows and Mobile phone area, and Horde  
provides a web based client. These are very different environments  
which of course have different communities attached to them.  
Especially since each of the actual clients is a full groupware client  
and the Kolab connectivity is usually just a small part of the client.

But that Kolab part inevitably forms the link into the Kolab  
community. The connectivity to the Kolab server relies on the  
definition of the Kolab Format which is being worked on by the Kolab  
community. The clients usually connect to the free/busy system which  
also means that they have to talk to the server in specific fashion.

And of course the Kolab community is probably the best place to find  
people interested in joining your efforts.

And if you start from scratch then finding people to team up with  
might be the crucial factor. As I mentioned above under "1) having a  
local Kolab client on the android" coding a groupware client from  
scratch may be quite demanding. The current clients are somewhere in  
the area of 100 - 200 person years in coding effort (see ohloh.net).  
Of course these are rough estimates.

Cheers,

Gunnar

>
> Cheers
> Sascha
>
> --
> Fear can hold you prisoner.
> Hope can set you free!
>



-- 
______ 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/20100112/b571df29/attachment.bin

From bernhard at intevation.de  Tue Jan 12 09:50:46 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 12 Jan 2010 09:50:46 +0100
Subject: [Kolab-devel] Android client (Re:  How to get involved?)
In-Reply-To: <20100111224917.216229mx21bz02qk@webmail.pardus.de>
References: <201001111818.22295.sascha@deutschkron.de>
	<20100111224917.216229mx21bz02qk@webmail.pardus.de>
Message-ID: <201001120950.49683.bernhard@intevation.de>

Am Montag, 11. Januar 2010 22:49:17 schrieb Gunnar Wrobel:
> ? 1) having a local Kolab client on the android
> ? 2) using a web based Kolab client
> ? 3) Synchronize the data with the server
>
> For 1) the easiest choice would be to look into Kontact: Can you ?
> compile it for the android and run it there? Which fixes might be ?
> needed to get it running? Kontact is by far the most tested and ?
> feature rich Kolab client out there.

Am Dienstag, 12. Januar 2010 07:48:42 schrieb Sascha Deutschkron:
>  Yes, I plan to write a local Kolab client for Android.

So the technical subchoice is: Do you want to base it on KDE Kontact,
which is the current leading Free Software Kolab client or do you want to base 
it on a different piece of software?  

If you aim for KDE Kontact, the next step is to see if you could get Qt ported 
to Android. So far I've heard (not confirmed my self) that this will be 
difficult, but not impossible, e.g. see 
http://www.kdedevelopers.org/node/4070 . Android apparently uses a Java based 
GUI. It well may be too much for a single developer. But if you get Qt ported 
on Android for good, you are certainly almost done and have a good result.
To go this road you would need to actively try to seek other people to take 
part of the load of porting Qt.

The other road is to pick any capable IMAP email client which already is Free 
Software and more capable with the Android Java GUi and extend it.


Best Regards,
Bernhard

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

From dusty at qwer.tk  Tue Jan 12 10:16:31 2010
From: dusty at qwer.tk (Hermann Himmelbauer)
Date: Tue, 12 Jan 2010 10:16:31 +0100
Subject: [Kolab-devel] Android client (Re:  How to get involved?)
In-Reply-To: <201001120950.49683.bernhard@intevation.de>
References: <201001111818.22295.sascha@deutschkron.de>
	<20100111224917.216229mx21bz02qk@webmail.pardus.de>
	<201001120950.49683.bernhard@intevation.de>
Message-ID: <201001121016.31757.dusty@qwer.tk>

Am Dienstag 12 Januar 2010 09:50:46 schrieb Bernhard Reiter:
> Am Montag, 11. Januar 2010 22:49:17 schrieb Gunnar Wrobel:
> > ? 1) having a local Kolab client on the android
> > ? 2) using a web based Kolab client
> > ? 3) Synchronize the data with the server
> >
> > For 1) the easiest choice would be to look into Kontact: Can you ?
> > compile it for the android and run it there? Which fixes might be ?
> > needed to get it running? Kontact is by far the most tested and ?
> > feature rich Kolab client out there.
>
> Am Dienstag, 12. Januar 2010 07:48:42 schrieb Sascha Deutschkron:
> >  Yes, I plan to write a local Kolab client for Android.
>
> So the technical subchoice is: Do you want to base it on KDE Kontact,
> which is the current leading Free Software Kolab client or do you want to
> base it on a different piece of software?
>
> If you aim for KDE Kontact, the next step is to see if you could get Qt
> ported to Android. So far I've heard (not confirmed my self) that this will
> be difficult, but not impossible, e.g. see
> http://www.kdedevelopers.org/node/4070 . Android apparently uses a Java
> based GUI. It well may be too much for a single developer. But if you get
> Qt ported on Android for good, you are certainly almost done and have a
> good result. To go this road you would need to actively try to seek other
> people to take part of the load of porting Qt.

I wonder if that would "really be it": First, the question is if the Android 
hardware is capable of running Kontact in regards to RAM / CPU power. The 
second thing in question is the GUI: Kontact is designed for a desktop 
environment, not for a mobile phone with a touchscreen.

> The other road is to pick any capable IMAP email client which already is
> Free Software and more capable with the Android Java GUi and extend it.

This was also my first thought - I assume that there will be the following 
available in Android:

- An IMAP email client
- Some calendar application
- Some addressbook/contact application

If these applications are open-source, it should be possible to integrate them 
into Kolab:

- Any IMAP email client should work right away. Maybe it's necessary to tune 
the client in some way (shared folders and the like)

- For calendar/contacts the offline capabilities are mandatory, I think, while 
for E-Mails it's not. Therefore I can think of a synchronization approach via 
e.g. a specific IMAP connector, similar to Toltec / Konsec. I assume that 
there is some code available for this connector that can be cloned/translated 
into Java - maybe a side-effect could be some Java library that is reusable 
for other projects?

Btw., another approach for calendar/contacts+syncing would be to utilize an 
existing synchronization framework, e.g. Funambol: If someone writes a good 
connector for Kolab <-> Funambol, Android will be able to sync (I assume 
Funambol has sync capabilities for Android), moreover, this would enable any 
other mobile to sync via Funambol to Kolab.

Just my 2 cents...

Best Regards and Good Luck!

Hermann

-- 
hermann at qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7


From issues at kolab.org  Tue Jan 12 12:53:07 2010
From: issues at kolab.org (Bernhard Reiter)
Date: Tue, 12 Jan 2010 11:53:07 +0000
Subject: [Kolab-devel] [issue4023] Size check before starting the archiving
	process.
In-Reply-To: <1263297187.85.0.57495131442.issue4023@kolab.org>
Message-ID: <1263297187.85.0.57495131442.issue4023@kolab.org>


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

This is about the wish to check the needed and available size on disk
before starting the archival of emails an objects.
(Split out from kolab/issue3747 (Better archiving function for a branch 
(subtree) of folders)

msg22980:
|1) What would it take to add a dialog that estimates the free 
|disc space compared to the maximum space needed?

Tmcguire wrote to me:
This would be difficult, see details below.
Details:
Currently, KMail does not provide reliable means to get the folder size of its 
folders: Although there is a "size" column in the folder tree, that is size on 
disk, and does not include size on the server for online IMAP.
So quite a bit of refactoring would be necessary to get reliable size 
information of folders.
Getting the free disk space is hopefully not that difficult, but I haven't 
looked at the details yet.
What I have no idea of is how to estimate the compression ratio, I don't think 
that is easily possible. The dialog could only show total folder size compared 
to the free disk space.

----------
assignedto: bernhard
keyword: enterprise35, enterprise5, kde client, kkc
messages: 23065
nosy: bernhard, emanuel, ludwig, tmcguire
priority: bug
status: unread
title: Size check before starting the archiving process.

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


From bernhard at intevation.de  Tue Jan 12 13:05:32 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Tue, 12 Jan 2010 13:05:32 +0100
Subject: [Kolab-devel] Android client (Re:  How to get involved?)
In-Reply-To: <201001121016.31757.dusty@qwer.tk>
References: <201001111818.22295.sascha@deutschkron.de>
	<201001120950.49683.bernhard@intevation.de>
	<201001121016.31757.dusty@qwer.tk>
Message-ID: <201001121305.35965.bernhard@intevation.de>

Am Dienstag, 12. Januar 2010 10:16:31 schrieb Hermann Himmelbauer:
> > If you aim for KDE Kontact, the next step is to see if you could get Qt
> > ported to Android. So far I've heard (not confirmed my self) that this
> > will be difficult, but not impossible, e.g. see
> > http://www.kdedevelopers.org/node/4070 . Android apparently uses a Java
> > based GUI. It well may be too much for a single developer. But if you get
> > Qt ported on Android for good, you are certainly almost done and have a
> > good result. To go this road you would need to actively try to seek other
> > people to take part of the load of porting Qt.
>
> I wonder if that would "really be it": First, the question is if the
> Android hardware is capable of running Kontact in regards to RAM / CPU
> power. 

Yes, it will be enough power. See the kde-maemo@ efforts and search for 
Windows CE and N900 on techbase.kde.org.

> The second thing in question is the GUI: Kontact is designed for a 
> desktop environment, not for a mobile phone with a touchscreen.

There will be a mobile phone capable gui design for Kontact soon
throughout the year, I will write more about this (hopefully) in the next 
days.

> Btw., another approach for calendar/contacts+syncing would be to utilize an
> existing synchronization framework, e.g. Funambol: If someone writes a good
> connector for Kolab <-> Funambol, Android will be able to sync (I assume
> Funambol has sync capabilities for Android), moreover, this would enable
> any other mobile to sync via Funambol to Kolab.

A funambol to Kolab Server connector is in the pipeline by an (to me) external 
party. I expect more news about it through Q1 2010.

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/20100112/976abb3f/attachment.bin

From issues at kolab.org  Tue Jan 12 13:10:48 2010
From: issues at kolab.org (Richard Bos)
Date: Tue, 12 Jan 2010 12:10:48 +0000
Subject: [Kolab-devel] [issue4024] Lots of tmp files in kolab's
	configuration directory
In-Reply-To: <1263298248.72.0.275139504994.issue4024@kolab.org>
Message-ID: <1263298248.72.0.275139504994.issue4024@kolab.org>


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

There are really lots of temp files left behind since Mathieu's change to
kolabconf.  For example:

linux-geis:/etc/kolab # ls -ltr tmp*.kolabtmp | wc -l
793

linux-geis:/etc/kolab # ls -ltr tmp*.kolabtmp  | tail -10
-rw------- 1 root root  2979 Jan 12 12:07 tmp2287Y.kolabtmp
-rw------- 1 root root  2408 Jan 12 12:07 tmptNa73.kolabtmp
-rw------- 1 root root   882 Jan 12 12:07 tmpOyqGc.kolabtmp
-rw------- 1 root root  3262 Jan 12 12:07 tmpzoTAh.kolabtmp
-rw------- 1 root root  5634 Jan 12 12:07 tmp91hes.kolabtmp
-rw------- 1 root root  1845 Jan 12 12:07 tmpaZ0qk.kolabtmp
-rw------- 1 root root  1066 Jan 12 12:07 tmpYFp4E.kolabtmp
-rw------- 1 root root    49 Jan 12 12:07 tmpf26jn.kolabtmp
-rw------- 1 root root  6331 Jan 12 12:07 tmpJue3H.kolabtmp
-rw------- 1 root root   696 Jan 12 12:07 tmpG6z4t.kolabtmp


linux-geis:/etc/kolab # cat tmpG6z4t.kolabtmp
##  Copyright (c) 2004 Klaraelvdalens Datakonsult AB
##     Written by Steffen Hansen <steffen at klaralvdalens-datakonsult.se>
##
## This program is Free Software under the GNU General Public License (>=v2).
## Read the file COPYING that comes with this packages for details.

#=================================================================
# THIS FILE IS AUTOMATICALLY WRITTEN BY THE KOLAB CONFIG BACKEND.
# MANUAL CHANGES ARE LOST UNLESS MADE IN THE TEMPLATE FILE:
#
#  /etc/kolab/templates/slapd.replicas.template
#
# Changes can be activated by running /usr/sbin/kolabconf
#=================================================================

# Replica statements for inclusion in slapd.conf


Probably caused by this code in /usr/lib/perl5/vendor_perl/5.10.0/Kolab/Conf.pm:
134     if (!($config = new File::Temp( TEMPLATE => 'tmpXXXXX',
135                                     DIR => $Kolab::config{"kolabdir"},
136                                     SUFFIX => '.kolabtmp',
137                                     UNLINK => 0 ))) {
138         Kolab::log('T', "Unable to open configuration file `$cfg': $!",
KOLAB_ERROR);
139         exit(1);
140     }

It looks like that the files are not removed (automatically).

Why is kolab configuration directory used for this and not /tmp?

----------
keyword: server
messages: 23067
nosy: mathieu.parent, rbos, thomas, wilde, wrobel
priority: bug
status: unread
title: Lots of tmp files in kolab's configuration directory

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


From sascha at deutschkron.de  Tue Jan 12 18:14:57 2010
From: sascha at deutschkron.de (Sascha Deutschkron)
Date: Tue, 12 Jan 2010 18:14:57 +0100
Subject: [Kolab-devel] Android client (Re:  How to get involved?)
In-Reply-To: <201001121305.35965.bernhard@intevation.de>
References: <201001111818.22295.sascha@deutschkron.de>
	<201001121016.31757.dusty@qwer.tk>
	<201001121305.35965.bernhard@intevation.de>
Message-ID: <201001121815.02207.sascha@deutschkron.de>

Am Dienstag, 12. Januar 2010 13:05:32 schrieb Bernhard Reiter:
> Am Dienstag, 12. Januar 2010 10:16:31 schrieb Hermann Himmelbauer:
> > > If you aim for KDE Kontact, the next step is to see if you could get Qt
> > > ported to Android. So far I've heard (not confirmed my self) that this
> > > will be difficult, but not impossible, e.g. see
> > > http://www.kdedevelopers.org/node/4070 . Android apparently uses a Java
> > > based GUI. It well may be too much for a single developer. But if you
> > > get Qt ported on Android for good, you are certainly almost done and
> > > have a good result. To go this road you would need to actively try to
> > > seek other people to take part of the load of porting Qt.
> >
> > I wonder if that would "really be it": First, the question is if the
> > Android hardware is capable of running Kontact in regards to RAM / CPU
> > power.
> 
> Yes, it will be enough power. See the kde-maemo@ efforts and search for
> Windows CE and N900 on techbase.kde.org.
> 
> > The second thing in question is the GUI: Kontact is designed for a
> > desktop environment, not for a mobile phone with a touchscreen.
> 
> There will be a mobile phone capable gui design for Kontact soon
> throughout the year, I will write more about this (hopefully) in the next
> days.

Would that mobile-Kontact also link in with the phone's contacts - so that I 
can easily call my Kolab contacts and/or see who's calling?

> 
> > Btw., another approach for calendar/contacts+syncing would be to utilize
> > an existing synchronization framework, e.g. Funambol: If someone writes a
> > good connector for Kolab <-> Funambol, Android will be able to sync (I
> > assume Funambol has sync capabilities for Android), moreover, this would
> > enable any other mobile to sync via Funambol to Kolab.
> 
> A funambol to Kolab Server connector is in the pipeline by an (to me)
>  external party. I expect more news about it through Q1 2010.
> 
> Bernhard
> 

-- 
Fear can hold you prisoner.
Hope can set you free!
-------------- 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/20100112/1debb15c/attachment.bin

From issues at kolab.org  Tue Jan 12 18:37:18 2010
From: issues at kolab.org (Sascha Wilde)
Date: Tue, 12 Jan 2010 17:37:18 +0000
Subject: [Kolab-devel] [issue4025] Users can not change theire password (in
	2.2.3)
In-Reply-To: <1263317838.33.0.623257083761.issue4025@kolab.org>
Message-ID: <1263317838.33.0.623257083761.issue4025@kolab.org>


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

With the new Server 2.2.3 users can not change their own password
using the admin interface anymore.

When trying to change the Password using kolab web admin one gets the
error:

LDAP Error: Could not modify object cn=Test Eins,dc=example,dc=com: Insufficient
access

This was reported by users and verified by me using a fresh
installation of 2.2.3.

Gunnar, could you please have a look at this, soon?  Thanks!

----------
assignedto: wrobel
keyword: server
messages: 23073
nosy: bernhard, martin, thomas, wilde, wrobel
priority: critical
status: unread
title: Users can not change theire password (in 2.2.3)

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


From issues at kolab.org  Wed Jan 13 11:22:19 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 13 Jan 2010 10:22:19 +0000
Subject: [Kolab-devel] [issue4026] mail will be printed with wrong header,
	if it is printed from a mail window(rt#5935)
In-Reply-To: <1263378139.05.0.264195169703.issue4026@kolab.org>
Message-ID: <1263378139.05.0.264195169703.issue4026@kolab.org>


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

observed with Kontact e35 20100101.1071145-kk2

Test:
1. Double click on a mail.
=> The mail is shown in window.
2. Select view->header->all in the window
3. Press on print and print the mail to a file.
=> The mail is printed in the main header style and not in the selected header
style.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23077
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: mail will be printed with wrong header, if it is printed from a mail window(rt#5935)

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


From issues at kolab.org  Wed Jan 13 12:50:16 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Wed, 13 Jan 2010 11:50:16 +0000
Subject: [Kolab-devel] [issue4027] Kontact crahes if store event attachment
	inline (rt#5941)
In-Reply-To: <1263383416.33.0.644484666959.issue4027@kolab.org>
Message-ID: <1263383416.33.0.644484666959.issue4027@kolab.org>


New submission from Emanuel Schuetze <emanuel at intevation.de>:

Tested with e35 20100101.1071145:
1. Create new event
2. Add new attachment file
3. activate "store attachment inline"
4. OK (attachment window)
5. OK (event window)
6. Reopen event
7. Open attachment properties via context menu
=> Input field shows _no_ attachment name!

8. Click OK.
=> Kontact crashes!
(Crash report attached)

9. Restart Kontact
10. Switch to calendar view
=> "Conflict detected" for created event! (Seems something was wrong during
storing event before crash?!)

----------
assignedto: allen
files: kontact.kcrash
keyword: enterprise35, kde client, kkc
messages: 23081
nosy: allen, emanuel
priority: urgent
status: unread
title: Kontact crahes if store event attachment inline  (rt#5941)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4027>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kontact.kcrash
Type: application/octet-stream
Size: 2723 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100113/1cc99a2f/kontact.exe

From issues at kolab.org  Wed Jan 13 14:43:20 2010
From: issues at kolab.org (Martin Zapfl)
Date: Wed, 13 Jan 2010 13:43:20 +0000
Subject: [Kolab-devel] [issue4028] Restart of openLDAP slave causes can' t
	contact ldap	server errors
In-Reply-To: <1263390200.15.0.358371997124.issue4028@kolab.org>
Message-ID: <1263390200.15.0.358371997124.issue4028@kolab.org>


New submission from Martin Zapfl <mailinglists at tbits.net>:

openLDAP slave server is restarted on every change in LDAP entries. It happens
even if users change their password. This causes the message "can't contact ldap
server" in several logfiles and results. Services like imap are not reachable
for a short time.
Is this a normal behaviour in LDAP replication?

----------
assignedto: martinzapfl
keyword: server
messages: 23083
nosy: martinzapfl
priority: bug
status: chatting
title: Restart of openLDAP slave causes can' t contact ldap server errors

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


From issues at kolab.org  Thu Jan 14 11:59:40 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 14 Jan 2010 10:59:40 +0000
Subject: [Kolab-devel] [issue4029] Save a attachment of a mail from the
	composer: no	filename (rt#5940)
In-Reply-To: <1263466780.97.0.802529231556.issue4029@kolab.org>
Message-ID: <1263466780.97.0.802529231556.issue4029@kolab.org>


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

tested with Kontact e35 20100101.1071145-kk2

Test
1. Start to create a new mail.
2. Add an attachment.
3. RMB on the attachment and "Save as"
=> The save file dialog doesn't contain a default filename.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23098
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Save a attachment of a mail from the composer: no filename (rt#5940)

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


From issues at kolab.org  Thu Jan 14 12:55:08 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 14 Jan 2010 11:55:08 +0000
Subject: [Kolab-devel] [issue4030] The filename of an UTF-16 text attachment
	is displayed	wrongly (rt#5942)
In-Reply-To: <1263470108.45.0.694565639155.issue4030@kolab.org>
Message-ID: <1263470108.45.0.694565639155.issue4030@kolab.org>


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

tested with Kontact e35 20100101.1071145-kk2

Test:
1. Open composer.
2. Add a UTF-16 encoded file attachment.
=> The filename of this attachment is displayed wrongly.

E.g. use dies_ist_ein-text_mit_ganz_langem-dateinamen2.txt as attachment.

----------
assignedto: allen
files: dies_ist_ein-text_mit_ganz_langem-dateinamen2.txt
keyword: enterprise35, kde client, kkc
messages: 23099
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: The filename of an UTF-16 text attachment is displayed wrongly (rt#5942)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4030>
______________________________________
-------------- next part --------------
þÿüöä

From thomas at btspuhler.com  Fri Jan 15 06:03:58 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Thu, 14 Jan 2010 22:03:58 -0700
Subject: [Kolab-devel] slapd.conf.template
Message-ID: <201001142203.58846.thomas@btspuhler.com>

The template now has the possiblity to have the modules loaded or use 
statically compiled modules
There is a line in the /dist/conf/distribution file called:
ldapserver_modulepath=false
What are the options beside "false"

I need to modules to be loaded.

-- 
Thomas


From math.parent at gmail.com  Fri Jan 15 11:21:40 2010
From: math.parent at gmail.com (Mathieu Parent)
Date: Fri, 15 Jan 2010 11:21:40 +0100
Subject: [Kolab-devel] slapd.conf.template
In-Reply-To: <201001142203.58846.thomas@btspuhler.com>
References: <201001142203.58846.thomas@btspuhler.com>
Message-ID: <960738411001150221v510c4b30o1576b72c87129a2b@mail.gmail.com>

Hello,


On Fri, Jan 15, 2010 at 6:03 AM, Thomas Spuhler <thomas at btspuhler.com> wrote:
> The template now has the possiblity to have the modules loaded or use
> statically compiled modules
> There is a line in the /dist/conf/distribution file called:
> ldapserver_modulepath=false
> What are the options beside "false"

The path to the module directory

> I need to modules to be loaded.
dist_conf/debian as an example

Regards

Mathieu Parent


From benoit.mortier at opensides.be  Fri Jan 15 13:45:06 2010
From: benoit.mortier at opensides.be (Benoit Mortier)
Date: Fri, 15 Jan 2010 13:45:06 +0100
Subject: [Kolab-devel] Fwd: Introducing OpenPKG 4.x
In-Reply-To: <20091209132413.GA67956@xs4all.nl>
References: <200912080808.11106.martin.konold@erfrakon.de>
	<200912091255.14803.benoit.mortier@opensides.be>
	<20091209132413.GA67956@xs4all.nl>
Message-ID: <201001151345.07092.benoit.mortier@opensides.be>

Le Wednesday 09 December 2009 14:24:13 Richard Bos, vous avez ?crit?:
> Benoit,

Hello,

Sorry for my so late answer but never got around to write it..

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

No such a list doesn't exist. The idea behind project builder is that the 
distribution vector to your software are the linux distribution.

The tool is made so you can do everything will only one tool: 

- Package building for 60 dsitributions
- Testing of the package in a clean distribution chroot/ virtual machine 
including install/removal to test correct behaviour
- Creating of the special repository needed by the various distribution 
yast, apt, yum etc...
-  Creating of ftp repository for tar.gz 
etc...

is a real tool for developper and packagers

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


From issues at kolab.org  Fri Jan 15 14:51:40 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 15 Jan 2010 13:51:40 +0000
Subject: [Kolab-devel] [issue4031] Sending a mail encrypted to an address
	with gpg-key and	an address with SMIME key problem (rt#5938)
In-Reply-To: <1263563500.25.0.749733635662.issue4031@kolab.org>
Message-ID: <1263563500.25.0.749733635662.issue4031@kolab.org>


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

tested with Kontact e35 20100101.1074782-kk4

Test:
A has a secret and public Openpgp key configured
A has only B's Openpgp public key (trusted)
A has only C's SMIME public certificate (trusted)
1. A opens a composer.
2. A adds B and C to the mail.
3. A clicks on encryption button and select "all"
4. A sends the mail
=> He is asked about the keys (In the key dialog is C's SMIME key fingerprint)
5. He presses on "Ok".
=> The mail is send without error.
6. C looks at the mail, but cannot decrypt it, because it is a Openpgp Mail.

I expect a warning/error msg if Kontact tries to mix up Openpgp and SMIME.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23111
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Sending a mail encrypted to an address with gpg-key and an address with SMIME key problem (rt#5938)

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


From issues at kolab.org  Fri Jan 15 16:09:14 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 15 Jan 2010 15:09:14 +0000
Subject: [Kolab-devel] [issue4032] Todos summary shows no todos in offline
	(rt#5944)
In-Reply-To: <1263568154.3.0.533464607469.issue4032@kolab.org>
Message-ID: <1263568154.3.0.533464607469.issue4032@kolab.org>


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

observed with Kontact e35 20100101.1074782-kk4

Test:
Some todos are displayed in the summary in Online Modus.
1. Switch to Offline Modus.
2. Close and restart kontact.
3. Switch to the summary.
=> the todo summary is empty.
4. Switch to the to-do part and back to the summary.
=> the todo summary is filled again.

Users are confused, because the summary is empty after a restart.
Please estimate first and wait on an okay.
Estimation is kkc.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23116
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Todos summary shows no todos in offline (rt#5944)

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


From wilde at intevation.de  Fri Jan 15 18:18:58 2010
From: wilde at intevation.de (Sascha Wilde)
Date: Fri, 15 Jan 2010 18:18:58 +0100
Subject: [Kolab-devel] Security Issue 27 for Kolab Server (Kolab Web Admin)
Message-ID: <s7whbqni8vx.fsf@intevation.de>

Kolab Security Issue 27 20100115
================================

Package:              Kolab Server, Kolab Web Admin
Vulnerability:        Users can not change their password
Kolab Specific:       yes
Dependent Packages:   none


Summary
~~~~~~~

The Kolab Web Admin interface allows Kolab users to manipulate some of
their user data using a web browser.  Most importantly it enables
users to change their passwords.

In the kolab-webadmin package shipped with Kolab Server release 2.2.3,
the web admin interface fails to save changed user data (an LDAP error
is issued).


Affected Versions
~~~~~~~~~~~~~~~~~

This affects version 2.2.3-20091217 of kolab-webadmin.
Kolab Server 2.2.3 is affected.


Fix
~~~

Update your kolab-webadmin package:

OpenPKG packages for Kolab Server 2.2.3 are available from
https://files.kolab.org/server/security-updates/20100115/
or from the mirrors listed on http://kolab.org/mirrors.html

A binary RPM for Kolab Server 2.2.3 (ix86 Debian GNU/Linux Lenny)
is available as kolab-webadmin-2.2.3-20100115.ix86-debian5.0-kolab.rpm

A binary RPM for Kolab Server 2.2.3 (ix86 Debian GNU/Linux Etch)
is available as kolab-webadmin-2.2.3-20100115.ix86-debian4.0-kolab.rpm

You can check the integrity of the downloaded files with:

$ gpg --keyserver keys.gnupg.net --recv-key 4BB86568
$ gpg --verify SHA1SUMS.sig
$ sha1sum -c SHA1SUMS

The source package can be compiled and installed on your Kolab Server with:

# su - kolab
$ openpkg rpm --rebuild ...path/to.../kolab-webadmin-2.2.3-20100115.src.rpm
$ openpkg rpm -Uvh /kolab/RPM/PKG/kolab-webadmin-2.2.3-20100115.<ARCH>-<OS>-kolab.rpm	

To install a binary package, just skip the --rebuild step.


Details
~~~~~~~

https://issues.kolab.org/issue4025
	Bug report in the official kolab issue tracker.


Timeline
~~~~~~~~
    20100103 First report per private mail
    20100112 Public problem report
    20100115 Updated kolab-webadmin package available and Kolab Server
             security advisory published.
-- 
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/20100115/62a3b5cf/attachment.bin

From thomas at btspuhler.com  Sat Jan 16 19:15:04 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sat, 16 Jan 2010 11:15:04 -0700
Subject: [Kolab-devel] slapd.conf.template
In-Reply-To: <960738411001150221v510c4b30o1576b72c87129a2b@mail.gmail.com>
References: <201001142203.58846.thomas@btspuhler.com>
	<960738411001150221v510c4b30o1576b72c87129a2b@mail.gmail.com>
Message-ID: <201001161115.04755.thomas@btspuhler.com>

On Friday 15 January 2010 03:21:40 am Mathieu Parent wrote:
> Hello,
>
> On Fri, Jan 15, 2010 at 6:03 AM, Thomas Spuhler <thomas at btspuhler.com> 
wrote:
> > The template now has the possiblity to have the modules loaded or use
> > statically compiled modules
> > There is a line in the /dist/conf/distribution file called:
> > ldapserver_modulepath=false
> > What are the options beside "false"
>
> The path to the module directory
>
> > I need to modules to be loaded.
>
> dist_conf/debian as an example
>
> Regards
>
> Mathieu Parent
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel

I have a heck of a time to get this working. I would like to have the native 
installation as close as possible to the openpkg, but a lot of things don't 
work out, mostly with openldap:
1. I put  ldapserver_modulepath : /user/lib/openldap INTO /dist_conf/mandriva 
and get in 
/etc/kolab/kolab.globals: ldapserver_modulepath : /user/lib/openldap

2. this results in the /etc/kolab/templates with:
@@@if ldapserver_modulepath@@@
modulepath     @@/user/lib/openldap@@

which seems correct

3. this results when trying to do a kolab-bootstrap -b in 
/etc/openldap/slapd.conf:
modulepath     @@/user/lib/openldap@@
moduleload     back_bdb
moduleload     back_monitor
moduleload     refint
moduleload     unique

Why the @@?
AND the @@ are in the other slapd.access and slapd.replcas to but there I have 
@@@

4. when taking the @@ off, the system cannot find the back_monitor module, BUT 
it is at the location. all the other modules load OK
When taking modulepath     @@/user/lib/openldap@@ off in slapd.conf and the @@@ 
in the other two files as well, slaptest passes.

I hate to patch these three files.
 
-- 
Thomas


From thomas at btspuhler.com  Sat Jan 16 19:33:29 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sat, 16 Jan 2010 11:33:29 -0700
Subject: [Kolab-devel] Patch submission
In-Reply-To: <960738411001150221v510c4b30o1576b72c87129a2b@mail.gmail.com>
References: <201001142203.58846.thomas@btspuhler.com>
	<960738411001150221v510c4b30o1576b72c87129a2b@mail.gmail.com>
Message-ID: <201001161133.29986.thomas@btspuhler.com>

Please accept the following patch

-- 
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kolabsrv.diff
Type: text/x-patch
Size: 818 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100116/9ce807da/kolabsrv.bin

From ml at radoeka.nl  Sat Jan 16 21:33:57 2010
From: ml at radoeka.nl (Richard Bos)
Date: Sat, 16 Jan 2010 20:33:57 +0000
Subject: [Kolab-devel] Patch submission
In-Reply-To: <201001161133.29986.thomas@btspuhler.com>
References: <201001142203.58846.thomas@btspuhler.com>
	<960738411001150221v510c4b30o1576b72c87129a2b@mail.gmail.com>
	<201001161133.29986.thomas@btspuhler.com>
Message-ID: <201001162033.57548.ml@radoeka.nl>

Op zaterdag 16 januari 2010 18:33:29 schreef Thomas Spuhler:
> Please accept the following patch

Committed.

-- 
Richard


From ml at radoeka.nl  Sat Jan 16 22:20:05 2010
From: ml at radoeka.nl (Richard Bos)
Date: Sat, 16 Jan 2010 21:20:05 +0000
Subject: [Kolab-devel] slapd.conf.template
In-Reply-To: <201001161115.04755.thomas@btspuhler.com>
References: <201001142203.58846.thomas@btspuhler.com>
	<960738411001150221v510c4b30o1576b72c87129a2b@mail.gmail.com>
	<201001161115.04755.thomas@btspuhler.com>
Message-ID: <201001162120.05593.ml@radoeka.nl>

Op zaterdag 16 januari 2010 18:15:04 schreef u:
> I have a heck of a time to get this working. I would like to have the
>  native  installation as close as possible to the openpkg, but a lot of
>  things don't work out, mostly with openldap:
> 1. I put  ldapserver_modulepath : /user/lib/openldap INTO
>  /dist_conf/mandriva  and get in
> /etc/kolab/kolab.globals: ldapserver_modulepath : /user/lib/openldap

As it uses @ldapserver_modulepath@

> 2. this results in the /etc/kolab/templates with:
> @@@if ldapserver_modulepath@@@
> modulepath     @@/user/lib/openldap@@
>
> which seems correct

It is not, because it should: /user/lib/openldap
 
> 3. this results when trying to do a kolab-bootstrap -b in 
> /etc/openldap/slapd.conf:
> modulepath     @@/user/lib/openldap@@
> moduleload     back_bdb
> moduleload     back_monitor
> moduleload     refint
> moduleload     unique
> 
> Why the @@?
> AND the @@ are in the other slapd.access and slapd.replcas to but there I
>  have  @@@

Because the template is wrong.  I believe that the attached patch is needed. 
Can you test it and report the results?

Reason is that the makefile replaces @if ldapserver_modulepath@ and not
@@@if ldapserver_modulepath@@@, see:
dist_conf> grep ldapserver_modulepath common
        -e 's=[@]ldapserver_modulepath[@]=$(ldapserver_modulepath)=g' \

> 4. when taking the @@ off, the system cannot find the back_monitor module,
>  BUT  it is at the location. all the other modules load OK
> When taking modulepath     @@/user/lib/openldap@@ off in slapd.conf and 
the
>  @@@  in the other two files as well, slaptest passes.
> 
> I hate to patch these three files.

See what happens with patch applied.  If it still fails, more info is needed.


-- 
Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slapd.conf.template.in.modulepath.patch
Type: text/x-patch
Size: 385 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100116/917c413e/slapd.conf.template.in.modulepath.bin

From ml at radoeka.nl  Sat Jan 16 22:30:45 2010
From: ml at radoeka.nl (Richard Bos)
Date: Sat, 16 Jan 2010 21:30:45 +0000
Subject: [Kolab-devel] slapd.conf.template
In-Reply-To: <201001161115.04755.thomas@btspuhler.com>
References: <201001142203.58846.thomas@btspuhler.com>
	<960738411001150221v510c4b30o1576b72c87129a2b@mail.gmail.com>
	<201001161115.04755.thomas@btspuhler.com>
Message-ID: <201001162130.45368.ml@radoeka.nl>

Op zaterdag 16 januari 2010 18:15:04 schreef u:
> Why the @@?
> AND the @@ are in the other slapd.access and slapd.replcas to but there I
>  have  @@@

some additional information:
@@@variables are replaced by kolabconf (which is e.g. run during 
kolab_bootstrap and after changing settings in the webinterface).

@variables are replaced by the build system, these are replaced during the 
package build.  @if ldapserver_modulepath@ is a typical variable that is 
changed during the make (it's only different between distributions).

-- 
Richard


From thomas at btspuhler.com  Sun Jan 17 05:35:45 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sat, 16 Jan 2010 21:35:45 -0700
Subject: [Kolab-devel] slapd.conf.template
In-Reply-To: <201001162120.05593.ml@radoeka.nl>
References: <201001142203.58846.thomas@btspuhler.com>
	<201001161115.04755.thomas@btspuhler.com>
	<201001162120.05593.ml@radoeka.nl>
Message-ID: <201001162135.45781.thomas@btspuhler.com>

On Saturday 16 January 2010 02:20:05 pm Richard Bos wrote:
> Op zaterdag 16 januari 2010 18:15:04 schreef u:
> > I have a heck of a time to get this working. I would like to have the
> >  native  installation as close as possible to the openpkg, but a lot of
> >  things don't work out, mostly with openldap:
> > 1. I put  ldapserver_modulepath : /user/lib/openldap INTO
> >  /dist_conf/mandriva  and get in
> > /etc/kolab/kolab.globals: ldapserver_modulepath : /user/lib/openldap
>
> As it uses @ldapserver_modulepath@
>
> > 2. this results in the /etc/kolab/templates with:
> > @@@if ldapserver_modulepath@@@
> > modulepath     @@/user/lib/openldap@@
> >
> > which seems correct
>
> It is not, because it should: /user/lib/openldap
>
> > 3. this results when trying to do a kolab-bootstrap -b in
> > /etc/openldap/slapd.conf:
> > modulepath     @@/user/lib/openldap@@
> > moduleload     back_bdb
> > moduleload     back_monitor
> > moduleload     refint
> > moduleload     unique
> >
> > Why the @@?
> > AND the @@ are in the other slapd.access and slapd.replcas to but there I
> >  have  @@@
>
> Because the template is wrong.  I believe that the attached patch is
> needed. Can you test it and report the results?
>
> Reason is that the makefile replaces @if ldapserver_modulepath@ and not
> @@@if ldapserver_modulepath@@@, see:
> dist_conf> grep ldapserver_modulepath common
>         -e 's=[@]ldapserver_modulepath[@]=$(ldapserver_modulepath)=g' \
>
> > 4. when taking the @@ off, the system cannot find the back_monitor
> > module, BUT  it is at the location. all the other modules load OK
> > When taking modulepath     @@/user/lib/openldap@@ off in slapd.conf and
>
> the
>
> >  @@@  in the other two files as well, slaptest passes.
> >
> > I hate to patch these three files.
>
> See what happens with patch applied.  If it still fails, more info is
> needed.
1. This patch worked as making this:
/etc/openldap/slapd.conf:
modulepath     /user/lib/openldap
moduleload     back_bdb
moduleload     back_monitor
moduleload     refint
moduleload     unique

But this line needs to go:
modulepath     /user/lib/openldap
otherwise it cannot find module back_monitor.

2. This patch did not fix this line in slap.access.template and 
slap.replicas.template
@@@print getLDAPAccess()@@@

-- 
Thomas


From thomas at btspuhler.com  Sun Jan 17 05:41:12 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sat, 16 Jan 2010 21:41:12 -0700
Subject: [Kolab-devel] slapd.conf.template
In-Reply-To: <201001162120.05593.ml@radoeka.nl>
References: <201001142203.58846.thomas@btspuhler.com>
	<201001161115.04755.thomas@btspuhler.com>
	<201001162120.05593.ml@radoeka.nl>
Message-ID: <201001162141.12899.thomas@btspuhler.com>

On Saturday 16 January 2010 02:20:05 pm Richard Bos wrote:
> Op zaterdag 16 januari 2010 18:15:04 schreef u:
> > I have a heck of a time to get this working. I would like to have the
> >  native  installation as close as possible to the openpkg, but a lot of
> >  things don't work out, mostly with openldap:
> > 1. I put  ldapserver_modulepath : /user/lib/openldap INTO
> >  /dist_conf/mandriva  and get in
> > /etc/kolab/kolab.globals: ldapserver_modulepath : /user/lib/openldap
>
> As it uses @ldapserver_modulepath@
>
> > 2. this results in the /etc/kolab/templates with:
> > @@@if ldapserver_modulepath@@@
> > modulepath     @@/user/lib/openldap@@
> >
> > which seems correct
>
> It is not, because it should: /user/lib/openldap
>
> > 3. this results when trying to do a kolab-bootstrap -b in
> > /etc/openldap/slapd.conf:
> > modulepath     @@/user/lib/openldap@@
> > moduleload     back_bdb
> > moduleload     back_monitor
> > moduleload     refint
> > moduleload     unique
> >
> > Why the @@?
> > AND the @@ are in the other slapd.access and slapd.replcas to but there I
> >  have  @@@
>
> Because the template is wrong.  I believe that the attached patch is
> needed. Can you test it and report the results?
>
> Reason is that the makefile replaces @if ldapserver_modulepath@ and not
> @@@if ldapserver_modulepath@@@, see:
> dist_conf> grep ldapserver_modulepath common
>         -e 's=[@]ldapserver_modulepath[@]=$(ldapserver_modulepath)=g' \
>
> > 4. when taking the @@ off, the system cannot find the back_monitor
> > module, BUT  it is at the location. all the other modules load OK
> > When taking modulepath     @@/user/lib/openldap@@ off in slapd.conf and
>
> the
>
> >  @@@  in the other two files as well, slaptest passes.
> >
> > I hate to patch these three files.
>
> See what happens with patch applied.  If it still fails, more info is
> needed.

Please submit this patch, it will at least solve the slapd.conf.template file 
and should not harm any others.

-- 
Thomas


From ml at radoeka.nl  Sun Jan 17 12:16:47 2010
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 17 Jan 2010 11:16:47 +0000
Subject: [Kolab-devel] slapd.conf.template
In-Reply-To: <201001162135.45781.thomas@btspuhler.com>
References: <201001142203.58846.thomas@btspuhler.com>
	<201001162120.05593.ml@radoeka.nl>
	<201001162135.45781.thomas@btspuhler.com>
Message-ID: <201001171116.48616.ml@radoeka.nl>

Op zondag 17 januari 2010 04:35:45 schreef Thomas Spuhler:
> > See what happens with patch applied.  If it still fails, more info is
> > needed.
> 
> 1. This patch worked as making this:
> /etc/openldap/slapd.conf:
> modulepath     /user/lib/openldap
> moduleload     back_bdb
> moduleload     back_monitor
> moduleload     refint
> moduleload     unique

OK

> But this line needs to go:
> modulepath     /user/lib/openldap
> otherwise it cannot find module back_monitor.

Can you provide a content list of the directory /user/lib/openldap
Perhaps you should use back_monitor.la to load the monitor.  What happens 
when the reverse the order of the back_ modules, like this:
moduleload     back_monitor
moduleload     back_bdb
moduleload     refint
moduleload     unique


> 2. This patch did not fix this line in slap.access.template and 
> slap.replicas.template
> @@@print getLDAPAccess()@@@

This is correct.  The @@@print <argument>@@@ (here getLDAPAccess is the 
argument) instruction, is interpreted by kolabconf.  It prints the output of 
getLDAPAccess.

See (in perl-ldap):
ChangeLog:      * lib/Kolab/Conf.pm, sbin/kolabconf.in: new @@@print@@@ 
macro
lib/Kolab/Conf.pm:            # @@@print func([arg])@@@
(line 202)


-- 
Richard


From ml at radoeka.nl  Sun Jan 17 12:20:31 2010
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 17 Jan 2010 11:20:31 +0000
Subject: [Kolab-devel] slapd.conf.template
In-Reply-To: <201001162141.12899.thomas@btspuhler.com>
References: <201001142203.58846.thomas@btspuhler.com>
	<201001162120.05593.ml@radoeka.nl>
	<201001162141.12899.thomas@btspuhler.com>
Message-ID: <201001171120.31989.ml@radoeka.nl>

Op zondag 17 januari 2010 04:41:12 schreef Thomas Spuhler:
> > See what happens with patch applied.  If it still fails, more info is
> > needed.
> 
> Please submit this patch, it will at least solve the slapd.conf.template
>  file  and should not harm any others.

Done.

-- 
Richard


From thomas at btspuhler.com  Sun Jan 17 16:20:09 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sun, 17 Jan 2010 08:20:09 -0700
Subject: [Kolab-devel] slapd.conf.template
In-Reply-To: <201001171116.48616.ml@radoeka.nl>
References: <201001142203.58846.thomas@btspuhler.com>
	<201001162135.45781.thomas@btspuhler.com>
	<201001171116.48616.ml@radoeka.nl>
Message-ID: <201001170820.09649.thomas@btspuhler.com>

On Sunday 17 January 2010 04:16:47 am Richard Bos wrote:
> Op zondag 17 januari 2010 04:35:45 schreef Thomas Spuhler:
> > > See what happens with patch applied.  If it still fails, more info is
> > > needed.
> >
> > 1. This patch worked as making this:
> > /etc/openldap/slapd.conf:
> > modulepath     /user/lib/openldap
> > moduleload     back_bdb
> > moduleload     back_monitor
> > moduleload     refint
> > moduleload     unique
>
> OK
>
> > But this line needs to go:
> > modulepath     /user/lib/openldap
> > otherwise it cannot find module back_monitor.
>
> Can you provide a content list of the directory /user/lib/openldap
see attachment
> Perhaps you should use back_monitor.la to load the monitor.  What happens
> when the reverse the order of the back_ modules, like this:
> moduleload     back_monitor
> moduleload     back_bdb
> moduleload     refint
> moduleload     unique
It works when I drop the modulepath line
>
> > 2. This patch did not fix this line in slap.access.template and
> > slap.replicas.template
> > @@@print getLDAPAccess()@@@
>
> This is correct.  The @@@print <argument>@@@ (here getLDAPAccess is the
> argument) instruction, is interpreted by kolabconf.  It prints the output
> of getLDAPAccess.
It's not getting translate, Slaptest complains
>
> See (in perl-ldap):
> ChangeLog:      * lib/Kolab/Conf.pm, sbin/kolabconf.in: new @@@print@@@
> macro
> lib/Kolab/Conf.pm:            # @@@print func([arg])@@@
> (line 202)



-- 
Thomas
-------------- next part --------------
total 1476
lrwxrwxrwx 1 root root     22 2010-01-16 20:07 accesslog-2.4.so.2 -> accesslog-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  39236 2009-10-12 05:43 accesslog-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    952 2009-10-12 05:42 accesslog.la*
lrwxrwxrwx 1 root root     22 2010-01-16 20:07 accesslog.so -> accesslog-2.4.so.2.5.2*
-rwxr-xr-x 1 root root   8828 2009-10-12 05:43 addpartial.so*
-rwxr-xr-x 1 root root   5636 2009-10-12 05:43 allop.so*
lrwxrwxrwx 1 root root     21 2010-01-16 20:07 auditlog-2.4.so.2 -> auditlog-2.4.so.2.5.2*
-rwxr-xr-x 1 root root   9700 2009-10-12 05:43 auditlog-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    946 2009-10-12 05:42 auditlog.la*
lrwxrwxrwx 1 root root     21 2010-01-16 20:07 auditlog.so -> auditlog-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  28172 2009-10-12 05:43 autogroup.so*
-rwxr-xr-x 1 root root  28176 2009-10-12 05:43 autogroup.so.0*
-rwxr-xr-x 1 root root  28180 2009-10-12 05:43 autogroup.so.0.0.0*
lrwxrwxrwx 1 root root     24 2010-01-16 20:07 back_dnssrv-2.4.so.2 -> back_dnssrv-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  13648 2009-10-12 05:43 back_dnssrv-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    964 2009-10-12 05:42 back_dnssrv.la*
lrwxrwxrwx 1 root root     24 2010-01-16 20:07 back_dnssrv.so -> back_dnssrv-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     22 2010-01-16 20:07 back_ldap-2.4.so.2 -> back_ldap-2.4.so.2.5.2*
-rwxr-xr-x 1 root root 127716 2009-10-12 05:43 back_ldap-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    952 2009-10-12 05:42 back_ldap.la*
lrwxrwxrwx 1 root root     22 2010-01-16 20:07 back_ldap.so -> back_ldap-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     22 2010-01-16 20:07 back_meta-2.4.so.2 -> back_meta-2.4.so.2.5.2*
-rwxr-xr-x 1 root root 120804 2009-10-12 05:43 back_meta-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    952 2009-10-12 05:42 back_meta.la*
lrwxrwxrwx 1 root root     22 2010-01-16 20:07 back_meta.so -> back_meta-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     25 2010-01-16 20:07 back_monitor-2.4.so.2 -> back_monitor-2.4.so.2.5.2*
-rwxr-xr-x 1 root root 106364 2009-10-12 05:43 back_monitor-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    970 2009-10-12 05:42 back_monitor.la*
lrwxrwxrwx 1 root root     25 2010-01-16 20:07 back_monitor.so -> back_monitor-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     22 2010-01-16 20:07 back_null-2.4.so.2 -> back_null-2.4.so.2.5.2*
-rwxr-xr-x 1 root root   9596 2009-10-12 05:43 back_null-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    952 2009-10-12 05:42 back_null.la*
lrwxrwxrwx 1 root root     22 2010-01-16 20:07 back_null.so -> back_null-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     24 2010-01-16 20:07 back_passwd-2.4.so.2 -> back_passwd-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  13692 2009-10-12 05:43 back_passwd-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    964 2009-10-12 05:42 back_passwd.la*
lrwxrwxrwx 1 root root     24 2010-01-16 20:07 back_passwd.so -> back_passwd-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     23 2010-01-16 20:07 back_relay-2.4.so.2 -> back_relay-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  13800 2009-10-12 05:43 back_relay-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    958 2009-10-12 05:42 back_relay.la*
lrwxrwxrwx 1 root root     23 2010-01-16 20:07 back_relay.so -> back_relay-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     23 2010-01-16 20:07 back_shell-2.4.so.2 -> back_shell-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  17784 2009-10-12 05:43 back_shell-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    958 2009-10-12 05:42 back_shell.la*
lrwxrwxrwx 1 root root     23 2010-01-16 20:07 back_shell.so -> back_shell-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     22 2010-01-16 20:07 back_sock-2.4.so.2 -> back_sock-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  18056 2009-10-12 05:43 back_sock-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    952 2009-10-12 05:42 back_sock.la*
lrwxrwxrwx 1 root root     22 2010-01-16 20:07 back_sock.so -> back_sock-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     21 2010-01-16 20:07 back_sql-2.4.so.2 -> back_sql-2.4.so.2.5.2*
-rwxr-xr-x 1 root root 182232 2009-10-12 05:43 back_sql-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    996 2009-10-12 05:42 back_sql.la*
lrwxrwxrwx 1 root root     21 2010-01-16 20:07 back_sql.so -> back_sql-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     20 2010-01-16 20:07 collect-2.4.so.2 -> collect-2.4.so.2.5.2*
-rwxr-xr-x 1 root root   9700 2009-10-12 05:43 collect-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    940 2009-10-12 05:42 collect.la*
lrwxrwxrwx 1 root root     20 2010-01-16 20:07 collect.so -> collect-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     23 2010-01-16 20:07 constraint-2.4.so.2 -> constraint-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  22120 2009-10-12 05:43 constraint-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    958 2009-10-12 05:42 constraint.la*
lrwxrwxrwx 1 root root     23 2010-01-16 20:07 constraint.so -> constraint-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     16 2010-01-16 20:07 dds-2.4.so.2 -> dds-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  30692 2009-10-12 05:43 dds-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    916 2009-10-12 05:42 dds.la*
lrwxrwxrwx 1 root root     16 2010-01-16 20:07 dds.so -> dds-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     18 2010-01-16 20:07 deref-2.4.so.2 -> deref-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  13632 2009-10-12 05:43 deref-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    928 2009-10-12 05:42 deref.la*
lrwxrwxrwx 1 root root     18 2010-01-16 20:07 deref.so -> deref-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     21 2010-01-16 20:07 dyngroup-2.4.so.2 -> dyngroup-2.4.so.2.5.2*
-rwxr-xr-x 1 root root   9668 2009-10-12 05:43 dyngroup-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    946 2009-10-12 05:42 dyngroup.la*
lrwxrwxrwx 1 root root     21 2010-01-16 20:07 dyngroup.so -> dyngroup-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     20 2010-01-16 20:07 dynlist-2.4.so.2 -> dynlist-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  26324 2009-10-12 05:43 dynlist-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    940 2009-10-12 05:42 dynlist.la*
lrwxrwxrwx 1 root root     20 2010-01-16 20:07 dynlist.so -> dynlist-2.4.so.2.5.2*
-rwxr-xr-x 1 root root   2340 2009-10-12 05:43 lastmod.so*
lrwxrwxrwx 1 root root     21 2010-01-16 20:07 memberof-2.4.so.2 -> memberof-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  30584 2009-10-12 05:43 memberof-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    946 2009-10-12 05:42 memberof.la*
lrwxrwxrwx 1 root root     21 2010-01-16 20:07 memberof.so -> memberof-2.4.so.2.5.2*
-rwxr-xr-x 1 root root   2336 2009-10-12 05:43 nops.so*
lrwxrwxrwx 1 root root     19 2010-01-16 20:07 pcache-2.4.so.2 -> pcache-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  72284 2009-10-12 05:43 pcache-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    934 2009-10-12 05:42 pcache.la*
lrwxrwxrwx 1 root root     19 2010-01-16 20:07 pcache.so -> pcache-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     20 2010-01-16 20:07 ppolicy-2.4.so.2 -> ppolicy-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  34640 2009-10-12 05:43 ppolicy-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    960 2009-10-12 05:42 ppolicy.la*
lrwxrwxrwx 1 root root     20 2010-01-16 20:07 ppolicy.so -> ppolicy-2.4.so.2.5.2*
-rwxr-xr-x 1 root root   4368 2009-10-12 05:43 pw-kerberos.so*
-rwxr-xr-x 1 root root   3484 2009-10-12 05:43 pw-netscape.so*
lrwxrwxrwx 1 root root     19 2010-01-16 20:07 refint-2.4.so.2 -> refint-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  18052 2009-10-12 05:43 refint-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    934 2009-10-12 05:42 refint.la*
lrwxrwxrwx 1 root root     19 2010-01-16 20:07 refint.so -> refint-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     20 2010-01-16 20:07 retcode-2.4.so.2 -> retcode-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  26416 2009-10-12 05:43 retcode-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    940 2009-10-12 05:42 retcode.la*
lrwxrwxrwx 1 root root     20 2010-01-16 20:07 retcode.so -> retcode-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     16 2010-01-16 20:07 rwm-2.4.so.2 -> rwm-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  55428 2009-10-12 05:43 rwm-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    916 2009-10-12 05:42 rwm.la*
lrwxrwxrwx 1 root root     16 2010-01-16 20:07 rwm.so -> rwm-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     19 2010-01-16 20:07 seqmod-2.4.so.2 -> seqmod-2.4.so.2.5.2*
-rwxr-xr-x 1 root root   5400 2009-10-12 05:43 seqmod-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    934 2009-10-12 05:42 seqmod.la*
lrwxrwxrwx 1 root root     19 2010-01-16 20:07 seqmod.so -> seqmod-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  16240 2009-10-12 05:43 slapd-sha2.so*
lrwxrwxrwx 1 root root     15 2010-01-16 20:07 smbpwd.so -> smbpwd.so.0.0.0*
lrwxrwxrwx 1 root root     15 2010-01-16 20:07 smbpwd.so.0 -> smbpwd.so.0.0.0*
-rwxr-xr-x 1 root root  10536 2009-10-12 05:43 smbpwd.so.0.0.0*
lrwxrwxrwx 1 root root     19 2010-01-16 20:07 sssvlv-2.4.so.2 -> sssvlv-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  22176 2009-10-12 05:43 sssvlv-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    934 2009-10-12 05:42 sssvlv.la*
lrwxrwxrwx 1 root root     19 2010-01-16 20:07 sssvlv.so -> sssvlv-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     21 2010-01-16 20:07 syncprov-2.4.so.2 -> syncprov-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  46992 2009-10-12 05:43 syncprov-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    946 2009-10-12 05:42 syncprov.la*
lrwxrwxrwx 1 root root     21 2010-01-16 20:07 syncprov.so -> syncprov-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     24 2010-01-16 20:07 translucent-2.4.so.2 -> translucent-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  26472 2009-10-12 05:43 translucent-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    964 2009-10-12 05:42 translucent.la*
lrwxrwxrwx 1 root root     24 2010-01-16 20:07 translucent.so -> translucent-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     19 2010-01-16 20:07 unique-2.4.so.2 -> unique-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  26308 2009-10-12 05:43 unique-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    934 2009-10-12 05:42 unique.la*
lrwxrwxrwx 1 root root     19 2010-01-16 20:07 unique.so -> unique-2.4.so.2.5.2*
lrwxrwxrwx 1 root root     20 2010-01-16 20:07 valsort-2.4.so.2 -> valsort-2.4.so.2.5.2*
-rwxr-xr-x 1 root root  13916 2009-10-12 05:43 valsort-2.4.so.2.5.2*
-rwxr-xr-x 1 root root    940 2009-10-12 05:42 valsort.la*
lrwxrwxrwx 1 root root     20 2010-01-16 20:07 valsort.so -> valsort-2.4.so.2.5.2*

From thomas at btspuhler.com  Sun Jan 17 16:23:43 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sun, 17 Jan 2010 08:23:43 -0700
Subject: [Kolab-devel] slapd.conf.template
In-Reply-To: <201001171116.48616.ml@radoeka.nl>
References: <201001142203.58846.thomas@btspuhler.com>
	<201001162135.45781.thomas@btspuhler.com>
	<201001171116.48616.ml@radoeka.nl>
Message-ID: <201001170823.43254.thomas@btspuhler.com>

On Sunday 17 January 2010 04:16:47 am Richard Bos wrote:
> Op zondag 17 januari 2010 04:35:45 schreef Thomas Spuhler:
> > > See what happens with patch applied.  If it still fails, more info is
> > > needed.
> >
> > 1. This patch worked as making this:
> > /etc/openldap/slapd.conf:
> > modulepath     /user/lib/openldap
> > moduleload     back_bdb
> > moduleload     back_monitor
> > moduleload     refint
> > moduleload     unique
>
> OK
>
> > But this line needs to go:
> > modulepath     /user/lib/openldap
> > otherwise it cannot find module back_monitor.
>
> Can you provide a content list of the directory /user/lib/openldap
> Perhaps you should use back_monitor.la to load the monitor.  What happens
> when the reverse the order of the back_ modules, like this:
> moduleload     back_monitor
> moduleload     back_bdb
> moduleload     refint
> moduleload     unique
>
> > 2. This patch did not fix this line in slap.access.template and
> > slap.replicas.template
> > @@@print getLDAPAccess()@@@
>
> This is correct.  The @@@print <argument>@@@ (here getLDAPAccess is the
> argument) instruction, is interpreted by kolabconf.  It prints the output
> of getLDAPAccess.
>
> See (in perl-ldap):
> ChangeLog:      * lib/Kolab/Conf.pm, sbin/kolabconf.in: new @@@print@@@
> macro
> lib/Kolab/Conf.pm:            # @@@print func([arg])@@@
> (line 202)

 slaptest
/etc/openldap/slapd.conf: line 28: <replica-pidfile> keyword is obsolete 
(ignored)
/etc/openldap/slapd.conf: line 29: <replogfile> keyword is obsolete (ignored)
/etc/openldap/slapd.conf: line 30: <replicationinterval> keyword is obsolete 
(ignored)
/etc/openldap/slapd.conf: line 65: <replica> keyword is obsolete (ignored)
/etc/openldap/slapd.access: line 10: unknown directive <@@@print> inside 
backend database definition.
slaptest: bad configuration file!


-- 
Thomas


From ml at radoeka.nl  Sun Jan 17 17:33:14 2010
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 17 Jan 2010 16:33:14 +0000
Subject: [Kolab-devel] slapd.conf.template
In-Reply-To: <201001170820.09649.thomas@btspuhler.com>
References: <201001142203.58846.thomas@btspuhler.com>
	<201001171116.48616.ml@radoeka.nl>
	<201001170820.09649.thomas@btspuhler.com>
Message-ID: <201001171633.14645.ml@radoeka.nl>

Op zondag 17 januari 2010 15:20:09 schreef Thomas Spuhler:
> > Perhaps you should use back_monitor.la to load the monitor.  What happens
> > when the reverse the order of the back_ modules, like this:
> > moduleload     back_monitor
> > moduleload     back_bdb
> > moduleload     refint
> > moduleload     unique
> 
> It works when I drop the modulepath line

What about the .la suffix?  Did you try it with that?  Like:
moduleload     back_monitor.la
moduleload     back_bdb.la
moduleload     refint
moduleload     unique

-- 
Richard


From ml at radoeka.nl  Sun Jan 17 17:33:16 2010
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 17 Jan 2010 16:33:16 +0000
Subject: [Kolab-devel] slapd.conf.template
In-Reply-To: <201001170823.43254.thomas@btspuhler.com>
References: <201001142203.58846.thomas@btspuhler.com>
	<201001171116.48616.ml@radoeka.nl>
	<201001170823.43254.thomas@btspuhler.com>
Message-ID: <201001171633.16537.ml@radoeka.nl>

Op zondag 17 januari 2010 15:23:43 schreef Thomas Spuhler:
> /etc/openldap/slapd.access: line 10: unknown directive <@@@print> inside 
> backend database definition.
> slaptest: bad configuration file!

I gave you the hint already in a previous email.  @@@print is macro 
interpreted by kolabconf.

See (in perl-ldap):
ChangeLog:      * lib/Kolab/Conf.pm, sbin/kolabconf.in: new @@@print@@@ 
macro
lib/Kolab/Conf.pm:            # @@@print func([arg])@@@
(line 202)

What do you've at line 202?  In other words, I think that you need to update 
you perl-ldap package to the latest cvs version!


-- 
Richard


From thomas at btspuhler.com  Sun Jan 17 18:22:07 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sun, 17 Jan 2010 10:22:07 -0700
Subject: [Kolab-devel] slapd.conf.template
In-Reply-To: <201001171633.14645.ml@radoeka.nl>
References: <201001142203.58846.thomas@btspuhler.com>
	<201001170820.09649.thomas@btspuhler.com>
	<201001171633.14645.ml@radoeka.nl>
Message-ID: <201001171022.07286.thomas@btspuhler.com>

On Sunday 17 January 2010 09:33:14 am Richard Bos wrote:
> Op zondag 17 januari 2010 15:20:09 schreef Thomas Spuhler:
> > > Perhaps you should use back_monitor.la to load the monitor.  What
> > > happens when the reverse the order of the back_ modules, like this:
> > > moduleload     back_monitor
> > > moduleload     back_bdb
> > > moduleload     refint
> > > moduleload     unique
> >
> > It works when I drop the modulepath line
>
> What about the .la suffix?  Did you try it with that?  Like:
> moduleload     back_monitor.la
yes, I did
But when deleting the modulepath line it's not needed
> moduleload     back_bdb.la
> moduleload     refint
> moduleload     unique

-- 
Thomas


From thomas at btspuhler.com  Sun Jan 17 18:37:18 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sun, 17 Jan 2010 10:37:18 -0700
Subject: [Kolab-devel] slapd.conf.template
In-Reply-To: <201001171633.16537.ml@radoeka.nl>
References: <201001142203.58846.thomas@btspuhler.com>
	<201001170823.43254.thomas@btspuhler.com>
	<201001171633.16537.ml@radoeka.nl>
Message-ID: <201001171037.18445.thomas@btspuhler.com>

On Sunday 17 January 2010 09:33:16 am Richard Bos wrote:
> Op zondag 17 januari 2010 15:23:43 schreef Thomas Spuhler:
> > /etc/openldap/slapd.access: line 10: unknown directive <@@@print> inside
> > backend database definition.
> > slaptest: bad configuration file!
>
> I gave you the hint already in a previous email.  @@@print is macro
> interpreted by kolabconf.
>
> See (in perl-ldap):
> ChangeLog:      * lib/Kolab/Conf.pm, sbin/kolabconf.in: new @@@print@@@
> macro
> lib/Kolab/Conf.pm:            # @@@print func([arg])@@@
> (line 202)
OK, I am behind with the perl-kolab version
>
> What do you've at line 202?  In other words, I think that you need to
> update you perl-ldap package to the latest cvs version!
This is what the distro has:
# rpm -qa |grep perl-ldap
perl-ldap-0.39-1mdv2010.0

-- 
Thomas


From thomas at btspuhler.com  Sun Jan 17 19:04:26 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sun, 17 Jan 2010 11:04:26 -0700
Subject: [Kolab-devel] perl-kolab, kolab.mk missing
In-Reply-To: <960738411001150221v510c4b30o1576b72c87129a2b@mail.gmail.com>
References: <201001142203.58846.thomas@btspuhler.com>
	<960738411001150221v510c4b30o1576b72c87129a2b@mail.gmail.com>
Message-ID: <201001171104.26484.thomas@btspuhler.com>

The file name was changed in the manifest from Kolab.mk to kolab.mk, but the 
file is not in the package.
Will this file be added or will the makefile be changed?

-- 
Thomas


From ml at radoeka.nl  Sun Jan 17 20:48:39 2010
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 17 Jan 2010 19:48:39 +0000
Subject: [Kolab-devel] slapd.conf.template
In-Reply-To: <201001171037.18445.thomas@btspuhler.com>
References: <201001142203.58846.thomas@btspuhler.com>
	<201001171633.16537.ml@radoeka.nl>
	<201001171037.18445.thomas@btspuhler.com>
Message-ID: <201001171948.39167.ml@radoeka.nl>

Op zondag 17 januari 2010 17:37:18 schreef Thomas Spuhler:
> > What do you've at line 202?  In other words, I think that you need to
> > update you perl-ldap package to the latest cvs version!
> 
> This is what the distro has:
> # rpm -qa |grep perl-ldap
> perl-ldap-0.39-1mdv2010.0

Sorry, I should have written:
In other words, I think that you need to update you _perl-kolab_ package to 
the latest cvs version!

-- 
Richard


From ml at radoeka.nl  Sun Jan 17 21:00:00 2010
From: ml at radoeka.nl (Richard Bos)
Date: Sun, 17 Jan 2010 20:00:00 +0000
Subject: [Kolab-devel] slapd.conf.template
In-Reply-To: <201001171022.07286.thomas@btspuhler.com>
References: <201001142203.58846.thomas@btspuhler.com>
	<201001171633.14645.ml@radoeka.nl>
	<201001171022.07286.thomas@btspuhler.com>
Message-ID: <201001172000.00599.ml@radoeka.nl>

Op zondag 17 januari 2010 17:22:07 schreef Thomas Spuhler:
> On Sunday 17 January 2010 09:33:14 am Richard Bos wrote:
> > Op zondag 17 januari 2010 15:20:09 schreef Thomas Spuhler:
> > > > Perhaps you should use back_monitor.la to load the monitor.  What
> > > > happens when the reverse the order of the back_ modules, like this:
> > > > moduleload     back_monitor
> > > > moduleload     back_bdb
> > > > moduleload     refint
> > > > moduleload     unique
> > >
> > > It works when I drop the modulepath line
> >
> > What about the .la suffix?  Did you try it with that?  Like:
> > moduleload     back_monitor.la
> 
> yes, I did
> But when deleting the modulepath line it's not needed

I'm confused now.  If you add the suffix '.la' it works, is that what you say?  
Than why not use it like that?  Hmm, I see; you still need to patch the file.  
So you either need to patch it by removing the modulepath line, or you need to 
patch the modulenames and add the suffix '.la'.

What happens if you remove the modulepath and use the suffix '.la'?  Perhaps 
that is a generic solution for all?

Otherwise the code should be changed to something like:
@@@if ldapserver_moduleload@@@
@@@if ldapserver_modulepath@@@
modulepath     @ldapserver_modulepath@
@@@endif@@@
moduleload     back_bdb
moduleload     back_monitor
moduleload     refint
moduleload     unique
@@@endif@@@

I'm not sure, if nested @@@if's are possible.  If you investigate the 
slapd.conf further, you'll find more nested @@@if's so I think it works.  It 
might be necessary to replace more @@@if ldapserver_modulepath@@@ into 
@@@if ldapserver_moduleload@@@ if you want to activate this change.

I actually find it better to use a separate variable that is used to enable 
module loading.  For example: if the module loading is disabled, the 
modulepath will now be preserved.  With the current code it will be altered to 
'false'.


-- 
Richard


From thomas at btspuhler.com  Sun Jan 17 20:05:08 2010
From: thomas at btspuhler.com (Thomas Spuhler)
Date: Sun, 17 Jan 2010 12:05:08 -0700
Subject: [Kolab-devel] slapd.conf.template
In-Reply-To: <201001172000.00599.ml@radoeka.nl>
References: <201001142203.58846.thomas@btspuhler.com>
	<201001171022.07286.thomas@btspuhler.com>
	<201001172000.00599.ml@radoeka.nl>
Message-ID: <201001171205.08616.thomas@btspuhler.com>

On Sunday 17 January 2010 01:00:00 pm Richard Bos wrote:
> Op zondag 17 januari 2010 17:22:07 schreef Thomas Spuhler:
> > On Sunday 17 January 2010 09:33:14 am Richard Bos wrote:
> > > Op zondag 17 januari 2010 15:20:09 schreef Thomas Spuhler:
> > > > > Perhaps you should use back_monitor.la to load the monitor.  What
> > > > > happens when the reverse the order of the back_ modules, like this:
> > > > > moduleload     back_monitor
> > > > > moduleload     back_bdb
> > > > > moduleload     refint
> > > > > moduleload     unique
> > > >
> > > > It works when I drop the modulepath line
> > >
> > > What about the .la suffix?  Did you try it with that?  Like:
> > > moduleload     back_monitor.la
> >
> > yes, I did
But it did not make a difference
> > But when deleting the modulepath line it's not needed
>
> I'm confused now.  If you add the suffix '.la' it works, is that what you
> say? Than why not use it like that?  Hmm, I see; you still need to patch
> the file. So you either need to patch it by removing the modulepath line,
> or you need to patch the modulenames and add the suffix '.la'.
>
> What happens if you remove the modulepath and use the suffix '.la'? 
> Perhaps that is a generic solution for all?
>
> Otherwise the code should be changed to something like:
> @@@if ldapserver_moduleload@@@
> @@@if ldapserver_modulepath@@@
> modulepath     @ldapserver_modulepath@
> @@@endif@@@
> moduleload     back_bdb
> moduleload     back_monitor
> moduleload     refint
> moduleload     unique
> @@@endif@@@
OK will work on this
>
> I'm not sure, if nested @@@if's are possible.  If you investigate the
> slapd.conf further, you'll find more nested @@@if's so I think it works. 
> It might be necessary to replace more @@@if ldapserver_modulepath@@@ into
> @@@if ldapserver_moduleload@@@ if you want to activate this change.
>
> I actually find it better to use a separate variable that is used to enable
> module loading.  For example: if the module loading is disabled, the
> modulepath will now be preserved.  With the current code it will be altered
> to 'false'.

-- 
Thomas


From alain.abbas at libertech.fr  Mon Jan 18 08:28:20 2010
From: alain.abbas at libertech.fr (alain abbas)
Date: Mon, 18 Jan 2010 08:28:20 +0100
Subject: [Kolab-devel] Kolab Z-Push 0.2 only working one-way,
	mobile-to-server broken
In-Reply-To: <201001180145.07639.rmayr@debian.org>
References: <201001180145.07639.rmayr@debian.org>
Message-ID: <5867F440-E9D8-440D-9E79-FE46CDF65D34@libertech.fr>

hi
create a file debug.txt in z-push dir with right at 666 , test a  
synchro and send me this file please ,you can send me too the logfile  
(/var/log/z-push/access.log) tje name is in config.txt

try with the iphone i m sure its ok

Le 18 janv. 2010 ? 01:44, Rene Mayrhofer <rmayr at debian.org> a ?crit :

> Hi everybody,
>
> [Please CC me in replies, I am currently not subscribed to kolav- 
> devel.]
>
> I have been trying to get Activesync/Z-Push synchronization to a  
> Kolab server
> running during the past 2 days. The setup is inside a VM running  
> Debian
> squeeze with the most recent native Debian packages of Kolab and  
> Horde. Z-Push
> was taken from svn trunk today (and I also tried version 1.2.3RC  
> with no
> improvement), the Kolab backend 0.2 as linked from the Wiki page and  
> configured
> as described.
> Test clients are an iPhone 3GS wiith OS 3.1.2, a Motorola Milestone  
> (German
> Android firmware 2.0) and a HTC Hero (with stock HTC Android Cupcake/ 
> 1.5
> including the HTC Activesync implementation). If necessary, I can  
> add a Nokia
> N95, a HTC Touch Diamond, and (probably within a week) a Nokia N900  
> to the mix
> to cover all major mobile platforms with the exception of Blackberry.
>
> All mobile clients currently show the same behaviour, indepedently  
> of the
> synchronization period (push, manual, or poll): they can fetch  
> contacts and
> calendar items from the server (either created with Kontact from KDE  
> 4.3 or
> using the Horde webclient), but no item created on any of the  
> clients gets
> synchronized to the server.
> Unfortunately, the standard z-push log doesn't seem to indicate any  
> particular
> reason for this, which is why I am asking for pointers this way.  
> RTFM would be
> welcome, a request for more debugging logs better, or a "oh a we  
> know that,
> apply this patch" response obviously best ;-) I can probably help in  
> creating
> debug logs using different clients, although I am not much of a PHP  
> coder and
> thus reluctant to go into the code myself.
>
> PS: There is a second issue of the Motorola Milestone not displaying  
> the
> option of synchronizing the calendar at all. Contacts can be  
> selected and get
> fetched from the server, but there is no calendar options. The same  
> client
> (built-in Android 2.0 I assume) works for both contacts and calendar  
> when
> connected to an Exchange 2007 server, though.
>
> Any pointers would be highy appreciated,
> Rene


From issues at kolab.org  Mon Jan 18 11:49:04 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 18 Jan 2010 10:49:04 +0000
Subject: [Kolab-devel] [issue4033] calendar print: week-schedule big time
	numbers didn't fit	the border
In-Reply-To: <1263811744.67.0.113141275041.issue4033@kolab.org>
Message-ID: <1263811744.67.0.113141275041.issue4033@kolab.org>


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

tested with Kontact e35 20100115.1075236-kk1

Test:
1. Switch to calendar part.
2. Print a week with schedule to a file.
3. Look at the output.
=> The big time numbers in the schedule are cut from the border. 
See print5.ps

----------
assignedto: allen
files: print5.ps
keyword: enterprise35, kde client
messages: 23129
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: calendar print: week-schedule big time numbers didn't fit the border

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4033>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: print5.ps
Type: application/postscript
Size: 70982 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100118/8577d65d/print5-0001.ps

From issues at kolab.org  Mon Jan 18 11:53:39 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 18 Jan 2010 10:53:39 +0000
Subject: [Kolab-devel] [issue4034] print calendar: daily : The day string is
	in the calendar
In-Reply-To: <1263812019.16.0.71211236825.issue4034@kolab.org>
Message-ID: <1263812019.16.0.71211236825.issue4034@kolab.org>


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

tested with Kontact e35 20100115.1075236-kk1

Test:
1. Switch to Calendar.
2. Print a day with dayview.
3. Look at the output.
The date string is in the calendar border. So it looks like it is broken.
See: print6.ps

----------
assignedto: allen
files: print6.ps
keyword: enterprise35, kde client
messages: 23130
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: print calendar: daily : The day string is in the calendar

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4034>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: print6.ps
Type: application/postscript
Size: 57158 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100118/cba46c9c/print6-0001.ps

From issues at kolab.org  Mon Jan 18 12:02:23 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 18 Jan 2010 11:02:23 +0000
Subject: [Kolab-devel] [issue4035] Dates in the create event dialog are not
	localized into	German format.
In-Reply-To: <1263812543.27.0.622571532229.issue4035@kolab.org>
Message-ID: <1263812543.27.0.622571532229.issue4035@kolab.org>


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

tested with Kontact e35 20100115.1075236-kk1

Test:
Use German as lanuage.
1. Start to create a new event.
2. Look at the Start and End date.
=> The dates are in the wrong date format. I expect them to be in German date
format.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23132
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Dates in the create event dialog are not localized into German format.

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


From issues at kolab.org  Mon Jan 18 12:13:47 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 18 Jan 2010 11:13:47 +0000
Subject: [Kolab-devel] [issue4036] calendar print: tasks are wrongly printed
In-Reply-To: <1263813227.12.0.852229842168.issue4036@kolab.org>
Message-ID: <1263813227.12.0.852229842168.issue4036@kolab.org>


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

tested with Kontact e35 20100115.1075236-kk1

Test:
1. Create some tasks.
2. Print the week.
3. Look at the output.
Some tasks have three times before the describtion. 
Some tasks have just 0:00 as time.
E.g. look in print7.ps at 2010-01-16

----------
assignedto: allen
files: print7.ps
keyword: enterprise35, kde client
messages: 23133
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: calendar print: tasks are wrongly printed

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4036>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: print7.ps
Type: application/postscript
Size: 65985 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100118/22d66f07/print7-0001.ps

From issues at kolab.org  Mon Jan 18 12:18:01 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 18 Jan 2010 11:18:01 +0000
Subject: [Kolab-devel] [issue4037] calendar print: header dates are wrongly
	localized
In-Reply-To: <1263813481.61.0.104896702709.issue4037@kolab.org>
Message-ID: <1263813481.61.0.104896702709.issue4037@kolab.org>


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

tested with kontact e35 20100115.1075236-kk1

Test:
Use Erman Kontact
1. Switch to calendar.
2. Print a week.
3. Look at the output.
The header is like "Montag 11 Januar 2010" should be "Montag 11. Januar 2010".
The dot after the date number is missing.

----------
assignedto: allen
files: print7.ps
keyword: enterprise35, kde client
messages: 23134
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
status: unread
title: calendar print: header dates are wrongly localized

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4037>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: print7.ps
Type: application/postscript
Size: 65985 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100118/088c8233/print7-0001.ps

From issues at kolab.org  Mon Jan 18 12:54:53 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 18 Jan 2010 11:54:53 +0000
Subject: [Kolab-devel] [issue4038] After deletion of an event the small
	monthview is not	updated.
In-Reply-To: <1263815693.85.0.0155451710091.issue4038@kolab.org>
Message-ID: <1263815693.85.0.0155451710091.issue4038@kolab.org>


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

tested with Kontact e35 20100115.1075236-kk1

Test:
1. Switch to the calendar.
2. Create a new whole day event at a day without an event.
=> The date number of the day is now bold.
3. Delete the test event.
=> the date number in the month view stays bold.
4. Switch to another month and back again.
=> the date is normal again.
Is there a reason, why the month view is not updated after a deletion of an event?
I expect days to be bold in the monthview, if they contain an event.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23138
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: After deletion of an event the small monthview is not updated.

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


From issues at kolab.org  Mon Jan 18 13:57:56 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 18 Jan 2010 12:57:56 +0000
Subject: [Kolab-devel] [issue4039] Size of an embedded event attachment is
	too small.
In-Reply-To: <1263819476.73.0.786315982035.issue4039@kolab.org>
Message-ID: <1263819476.73.0.786315982035.issue4039@kolab.org>


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

tested with Kontact e35 201015.1075236-kk1

Test:
1. Switch to the calendar.
2. Create a new event with an embedded png-file attachment.
3. Reopen the event.
4. Look at the properties of the attachment via context menu.
=> The size is 12 B but is actually 16KB.
I expect the right size in this case. So I think that the attachment is not
embedded correctly.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23141
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Size of an embedded event attachment is too small.

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


From bernhard at intevation.de  Mon Jan 18 18:06:32 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 18 Jan 2010 18:06:32 +0100
Subject: [Kolab-devel] dot.kde.org on kdepim meeting -- client roadmap
Message-ID: <201001181806.36327.bernhard@intevation.de>

Traditionally the KDEPIM developers met in Osnabr?ck
this is the development community which brings us all KDE Kontact,
so there is overlap between the Kolab community and the KDEPIM community.

The new dot article reflects two items which are interesting for us as Kolab 
community:
http://dot.kde.org/2010/01/14/annual-osnabr?ck-pim-meeting-brings-exciting-announcements-and-ambitious-plans

a) There will be a Kontact and Kolab Groupware client for mobile clients base 
on the Kontact Enterprise5 branch.
b)  on the benefits of rich clients and how they fit into the  future 
landscape of PIM applications

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/20100118/7094483f/attachment.bin

From alain.abbas at libertech.fr  Tue Jan 19 09:56:56 2010
From: alain.abbas at libertech.fr (Alain abbas)
Date: Tue, 19 Jan 2010 09:56:56 +0100
Subject: [Kolab-devel] Kolab Z-Push 0.2 only working one-way,
	mobile-to-server broken
In-Reply-To: <201001181109.07044.rmayr@debian.org>
References: <201001180145.07639.rmayr@debian.org>
	<5867F440-E9D8-440D-9E79-FE46CDF65D34@libertech.fr>
	<201001181109.07044.rmayr@debian.org>
Message-ID: <4B5573D8.9040904@libertech.fr>

hi

there are a miss in your installation
:26 [2058] z-push/backend_0.2/diffbackend.php:21 
include_once(backend.php) [<a 
href='function.include-once'>function.include-once</a>]: failed to open 
stream: No such file or directory (2)

the Kolab backend must be in the directory backend with the others 
z-push files
try like that

regards



Rene Mayrhofer a ?crit :
> Hi Alain,
>
> Am Montag, 18. Januar 2010 08:28:20 schrieb alain abbas:
>   
>> create a file debug.txt in z-push dir with right at 666 , test a
>> synchro and send me this file please ,you can send me too the logfile
>> (/var/log/z-push/access.log) tje name is in config.txt
>>
>> try with the iphone i m sure its ok
>>     
>
> I disabled the accounts on the Milestone and the Hero, then disabled the 
> account on the iPhone. The attached debug and log files show what happened in 
> the first few minutes after activating contacts and calendar on the iPhone 
> again (3 contacts and 3 calendar items got synced from the server to the 
> phone) and adding a new calendar item (today, 14:15) on the iPhone (which did 
> not get pushed to the server).
>
> best regards,
> Rene
>  
>   
>> Le 18 janv. 2010 ? 01:44, Rene Mayrhofer <rmayr at debian.org> a ?crit :
>>     
>>> Hi everybody,
>>>
>>> [Please CC me in replies, I am currently not subscribed to kolav-
>>> devel.]
>>>
>>> I have been trying to get Activesync/Z-Push synchronization to a
>>> Kolab server
>>> running during the past 2 days. The setup is inside a VM running
>>> Debian
>>> squeeze with the most recent native Debian packages of Kolab and
>>> Horde. Z-Push
>>> was taken from svn trunk today (and I also tried version 1.2.3RC
>>> with no
>>> improvement), the Kolab backend 0.2 as linked from the Wiki page and
>>> configured
>>> as described.
>>> Test clients are an iPhone 3GS wiith OS 3.1.2, a Motorola Milestone
>>> (German
>>> Android firmware 2.0) and a HTC Hero (with stock HTC Android Cupcake/
>>> 1.5
>>> including the HTC Activesync implementation). If necessary, I can
>>> add a Nokia
>>> N95, a HTC Touch Diamond, and (probably within a week) a Nokia N900
>>> to the mix
>>> to cover all major mobile platforms with the exception of Blackberry.
>>>
>>> All mobile clients currently show the same behaviour, indepedently
>>> of the
>>> synchronization period (push, manual, or poll): they can fetch
>>> contacts and
>>> calendar items from the server (either created with Kontact from KDE
>>> 4.3 or
>>> using the Horde webclient), but no item created on any of the
>>> clients gets
>>> synchronized to the server.
>>> Unfortunately, the standard z-push log doesn't seem to indicate any
>>> particular
>>> reason for this, which is why I am asking for pointers this way.
>>> RTFM would be
>>> welcome, a request for more debugging logs better, or a "oh a we
>>> know that,
>>> apply this patch" response obviously best ;-) I can probably help in
>>> creating
>>> debug logs using different clients, although I am not much of a PHP
>>> coder and
>>> thus reluctant to go into the code myself.
>>>
>>> PS: There is a second issue of the Motorola Milestone not displaying
>>> the
>>> option of synchronizing the calendar at all. Contacts can be
>>> selected and get
>>> fetched from the server, but there is no calendar options. The same
>>> client
>>> (built-in Android 2.0 I assume) works for both contacts and calendar
>>> when
>>> connected to an Exchange 2007 server, though.
>>>
>>> Any pointers would be highy appreciated,
>>> Rene
>>>       


From issues at kolab.org  Tue Jan 19 11:36:10 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 19 Jan 2010 10:36:10 +0000
Subject: [Kolab-devel] [issue4040] Alarm with OnlineIMAP account not working.
In-Reply-To: <1263897370.93.0.870896049814.issue4040@kolab.org>
Message-ID: <1263897370.93.0.870896049814.issue4040@kolab.org>


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

tested with Kontact e35 20100115.1075236-kk1

Test:
Use an OnlineIMAP account.
1. Create an event that alarm should trigger in some minutes.
2. Wait on the alarm.
=> No alarm is triggered after 5 mins.
Probaly the alarm function doesn't work with an OnlineIMAP account.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23162
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Alarm with OnlineIMAP account not working.

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


From issues at kolab.org  Tue Jan 19 11:56:13 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 19 Jan 2010 10:56:13 +0000
Subject: [Kolab-devel] [issue4041] Recurrence of an extended alarm is not
	completly working.
In-Reply-To: <1263898573.29.0.390493369493.issue4041@kolab.org>
Message-ID: <1263898573.29.0.390493369493.issue4041@kolab.org>


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

tested with Kontact e35 20100115.1075236-kk1

Test:
1. Create a alarm with extended alarm in a few minutes, with three times alarm
recurrence after 1 minute.
2. Wait for the alarm.
=> first reminder pops up. 
3. Press "Close All".
4. Wait for the next alarm.
=> No second reminder appears. 
I expect the second reminder appear after nearly 1 minute, because I have
configured the alarm with 3 recurrences.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23163
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Recurrence of an extended alarm is not completly working.

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


From issues at kolab.org  Tue Jan 19 12:08:40 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 19 Jan 2010 11:08:40 +0000
Subject: [Kolab-devel] [issue4042] minutes field in the extended alarm
	dialog has a problem.
In-Reply-To: <1263899320.4.0.617361545356.issue4042@kolab.org>
Message-ID: <1263899320.4.0.617361545356.issue4042@kolab.org>


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

tested with Kontact e35 20100115.1075236-kk1

Test:
1. Start to create a new event.
2. Click on the extended alarm button.
=> Extended alarm dialog appears.
3. Click in the time difference minutes field and enter a different time.
4. Click on okay.
5. Reopen the extended alarm dialog.
=> The old time is set.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23164
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: minutes field in the extended alarm dialog has a problem.

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


From issues at kolab.org  Tue Jan 19 12:16:20 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 19 Jan 2010 11:16:20 +0000
Subject: [Kolab-devel] [issue4043] extended alarm: Own reminder dialog text
	is ignored.
In-Reply-To: <1263899780.12.0.229047498116.issue4043@kolab.org>
Message-ID: <1263899780.12.0.229047498116.issue4043@kolab.org>


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

tested with Kontact e35 20100115.1075236-kk1

Test:
1. Create a new event with extended alarm in a few minutes and text for the
reminder(right bottom of the extended alarm dialog.)
2. Wait on the reminder.
=> The reminder pops up, but does't display the text in any way.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23165
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: extended alarm: Own reminder dialog text is ignored.

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


From issues at kolab.org  Wed Jan 20 10:50:58 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 20 Jan 2010 09:50:58 +0000
Subject: [Kolab-devel] [issue4044] Wish: Mail window should close after
	pressing on	reply/forward(rt#5945)
In-Reply-To: <1263981058.65.0.134039411838.issue4044@kolab.org>
Message-ID: <1263981058.65.0.134039411838.issue4044@kolab.org>


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

observed with Kontact e35 20100115.1075236-kk1

Our customer wishes for:
It should be configurable that the the mail window should close, if pressed on
reply or forward in this mail window and a composer opens.

At the moment the mail window stays open, after pressing reply/forward in it.

Test:
1. Switch to mail part.
2. Double click on a mail.
=> Mail window of this mail opens.
3. Click on/Choose reply or forward.

Please estimate(kkc). Wait on an okay, before implementing it.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23179
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Wish: Mail window should close after pressing on reply/forward(rt#5945)

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


From issues at kolab.org  Thu Jan 21 11:18:16 2010
From: issues at kolab.org (Georg Greve)
Date: Thu, 21 Jan 2010 10:18:16 +0000
Subject: [Kolab-devel] [issue4045] Allow (mandatory) header field setting
	(requirement) for	sending mail
In-Reply-To: <1264069096.2.0.562524808273.issue4045@kolab.org>
Message-ID: <1264069096.2.0.562524808273.issue4045@kolab.org>


New submission from Georg Greve <greve at intevation.de>:

Allow definition of header fields that should be added to the Kmail Composer
list of fields to be defined by the user as the mail is being composed, either as

 (a) free text field
 (b) pull-down list of options (optionally starting with "PLEASE SELECT")

and it should be possible to make definition of this field a mandatory
requirement for being able to send the mail. This setting should be "pinnable"
through the Kiosk mode.

----------
keyword: kde client
messages: 23195
nosy: greve
priority: wish
status: unread
title: Allow (mandatory) header field setting (requirement) for sending mail

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


From issues at kolab.org  Thu Jan 21 11:22:28 2010
From: issues at kolab.org (Georg Greve)
Date: Thu, 21 Jan 2010 10:22:28 +0000
Subject: [Kolab-devel] [issue4046] Allow selection of specific fields for
	mandatory display	in message window
In-Reply-To: <1264069348.17.0.169160532978.issue4046@kolab.org>
Message-ID: <1264069348.17.0.169160532978.issue4046@kolab.org>


New submission from Georg Greve <greve at intevation.de>:

It would be very nice if it were possible to define header fields that will
always be displayed in Kmail alongside the standard ones, ideally with some
layout options (e.g. text size, style, color) for the field in general and
specific predefined values of the field.

----------
keyword: kde client
messages: 23196
nosy: greve
priority: wish
status: unread
title: Allow selection of specific fields for mandatory display in message window

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


From ludwig.reiter at intevation.de  Fri Jan 22 12:22:15 2010
From: ludwig.reiter at intevation.de (Ludwig Reiter)
Date: Fri, 22 Jan 2010 12:22:15 +0100
Subject: [Kolab-devel] Question about the kolab storage format: Tag revision.
Message-ID: <201001221222.15495.ludwig.reiter@intevation.de>

Hi,

in the kolab.xml in a mail of an event is the tag <revision> which seems 
always to be 0. What is this tag for?

Thanks,
Ludwig


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


From soliva at comcept.ch  Sun Jan 24 11:31:48 2010
From: soliva at comcept.ch (ComCept Soliva)
Date: Sun, 24 Jan 2010 11:31:48 +0100
Subject: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
Message-ID: <000001ca9ce0$6f9c92e0$4ed5b8a0$@ch>

Hi all

With the new version I overlooked a error message meaning I tested the
server overall really in real time including Horde but I can not identify
something which is not working even as soon as I modify something in Kolab
Web Admin I have following error in the php error log:

[23-Jan-2010 14:59:36] PHP Warning:  ldap_search() [<a
href='function.ldap-search'>function.ldap-search</a>]: Search: Invalid DN
syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 204
[23-Jan-2010 14:59:36] PHP Warning:  ldap_get_entries(): supplied argument
is not a valid ldap result resource in
/opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424

Is this already recognized? Is it not known....I tried to figure out what is
wrong but actually I could not?!

Any suggestion?

By the way is there a documentation about Master/Slave configuration meaning
how this works etc. I could not find anything. Any hints would be
appriciated.

Kind regards

Andrea Soliva

Mail: soliva at comcept.ch 


From issues at kolab.org  Sun Jan 24 12:01:07 2010
From: issues at kolab.org (Gohmann)
Date: Sun, 24 Jan 2010 11:01:07 +0000
Subject: [Kolab-devel] [issue4047] N97 syncml does not work with the horde
	version in Kolab
In-Reply-To: <1264330867.23.0.286047681322.issue4047@kolab.org>
Message-ID: <1264330867.23.0.286047681322.issue4047@kolab.org>


New submission from Gohmann <gohmann at univention.de>:

As described here [1] syncml with the Nokia N97 mobile phone does not work with
an old version of horde. I think the horde version in Kolab is too old.

I did a short test with Horde Groupware Webmail Edition 1.2.5 and it seems to work. 

[1] http://archives.free.net.ph/message/20091208.211028.d2d1c84b.en.html

----------
keyword: syncml, web client
messages: 23218
nosy: stefan
status: unread
title: N97 syncml does not work with the horde version in Kolab

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


From issues at kolab.org  Mon Jan 25 10:17:04 2010
From: issues at kolab.org (Arvid Requate)
Date: Mon, 25 Jan 2010 09:17:04 +0000
Subject: [Kolab-devel] [issue4048] Some German translations missing in
	kronolith
In-Reply-To: <1264411024.84.0.690630463489.issue4048@kolab.org>
Message-ID: <1264411024.84.0.690630463489.issue4048@kolab.org>


New submission from Arvid Requate <requate at univention.de>:

A coluple of German translations are missing in kronolith:

In the top menu icon subtexts
"Options", "Help", "Log out"

In the options dialog:
"Options for Kalender"
"Edit options for"
Dropdown Menu: "Choose Application:", "Global Options"

In the edit dialog for an event:
"Set start time"
"Set start time" (again in the set end time field)
"Dauer: Day(s) Hour(s) Minutes"
"Load Attendee List"
"Save Attendee List"

Under "Kalender Verwalten">"Neuen lokalen Kalender erstellen":
"Relevance:
 owners/administrators
 readers
 no one"

Under "Kalender Verwalten">"Rechte ?ndern":
"Extended free/busy access"

----------
messages: 23219
nosy: requate
status: unread
title: Some German translations missing in kronolith

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


From issues at kolab.org  Mon Jan 25 14:36:41 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 25 Jan 2010 13:36:41 +0000
Subject: [Kolab-devel] [issue4049] Calendar / Task: inline attachment of an
	invitation isn't	working.
In-Reply-To: <1264426601.8.0.654244455309.issue4049@kolab.org>
Message-ID: <1264426601.8.0.654244455309.issue4049@kolab.org>


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

tested with Kontact e35 20100122.1078643-kk1

Test:
1. A invites B with an inline png-file attachment.
2. B syncs and tries to open the png attachment.
=> Fails to open.
3. B saves the png attachment.
4. B tries to open it with kuickshow. 
=> This fails. The saved attachment has a 3B size.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23235
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Calendar / Task: inline attachment of an invitation isn't working.

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


From bernhard at intevation.de  Mon Jan 25 14:36:45 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon, 25 Jan 2010 14:36:45 +0100
Subject: [Kolab-devel] Search: Invalid DN syntax function.ldap-search
In-Reply-To: <000001ca9ce0$6f9c92e0$4ed5b8a0$@ch>
References: <000001ca9ce0$6f9c92e0$4ed5b8a0$@ch>
Message-ID: <201001251436.49129.bernhard@intevation.de>

Am Sonntag, 24. Januar 2010 11:31:48 schrieb ComCept Soliva:
> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_search() [<a
> href='function.ldap-search'>function.ldap-search</a>]: Search: Invalid DN
> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 204
> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_get_entries(): supplied argument
> is not a valid ldap result resource in
> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>
> Is this already recognized? Is it not known....I tried to figure out what
> is wrong but actually I could not?!
>
> Any suggestion?

My suggestion is to check the given line 204 and see which argument
is used there (maybe add a statement to print it out).

> By the way is there a documentation about Master/Slave configuration
> meaning how this works etc. I could not find anything. Any hints would be
> appriciated.

I think the documentation is in the architecture documents.
The idea is pretty simple: Replicate the directory server on the slave
(for which there is a bootstrap) have all read access on the slave accounts go 
to the slave LDAP server and all write access (only by webadmin) to the 
master.

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/20100125/fe41e017/attachment.bin

From issues at kolab.org  Mon Jan 25 14:58:27 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 25 Jan 2010 13:58:27 +0000
Subject: [Kolab-devel] [issue4050] Properties dialog of event/task
	attachments says in	German says "Anhang eingebettet speichern"
In-Reply-To: <1264427907.14.0.236916872057.issue4050@kolab.org>
Message-ID: <1264427907.14.0.236916872057.issue4050@kolab.org>


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

tested with Kontact e35 20100122.1078643-kk1

Test:
Use German as language.
1. Create a task with attachment.
2. Edit this task.
3. Open the properties dialog of the attachment.
=> Greyed out is the line "Anhang eingebettet speichern"
It should be "Anhang eingebettet gespeichert" or so in this case.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23236
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Properties dialog of event/task attachments says in German says "Anhang eingebettet speichern"

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


From issues at kolab.org  Tue Jan 26 12:00:21 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 26 Jan 2010 11:00:21 +0000
Subject: [Kolab-devel] [issue4052] copy+paste of an appointment in
	side-by-side view creates	the appointment at a wrong time.(rt#5951)
In-Reply-To: <1264503621.39.0.76423229762.issue4052@kolab.org>
Message-ID: <1264503621.39.0.76423229762.issue4052@kolab.org>


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

tested with Kontact e35 20100122.1078643-kk1

Test:
Req: calendar in side-by-side view. week selected (Monday-Sunday)
1. Create an event at the Tuesdays.
2. Select the event and RMB->Copy on the event.
3. Select a time on Friday.
4. RMB->Paste
5. Choose the right calendar resource.
=> The event is inserted on the wrong weekday (Monday) at the wrong time.(old time)

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23243
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: copy+paste of an appointment in side-by-side view creates the appointment at a wrong time.(rt#5951)

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


From issues at kolab.org  Tue Jan 26 13:39:30 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 26 Jan 2010 12:39:30 +0000
Subject: [Kolab-devel] [issue4053] reminder of an event with recurrence
	shows wrong	date.(rt#5953)
In-Reply-To: <1264509570.82.0.879735556487.issue4053@kolab.org>
Message-ID: <1264509570.82.0.879735556487.issue4053@kolab.org>


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

tested with Kontact e35 20100122.1078643-kk1

The reminder of a event with recurrence shows the date of the first event in the
"to" column and not the date of the current event.

See the screenshot for a German reminder, which shows the problem: "To" = "Bis"

Test:
1. Create a new event with recurrence and alarm. So that the second recurrence
event is in a few minutes.
2. Wait on the alarm.
3. Look at the reminder.
=> The "To"- column contains a wrong date. I expect here the date of the current
event and not of the first event.

----------
assignedto: allen
files: reminder-20100126.png
keyword: enterprise35, kde client, kkc
messages: 23244
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: reminder of an event with recurrence shows wrong date.(rt#5953)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4053>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reminder-20100126.png
Type: image/png
Size: 37055 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100126/38068350/reminder-20100126-0001.png

From issues at kolab.org  Tue Jan 26 14:35:30 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 26 Jan 2010 13:35:30 +0000
Subject: [Kolab-devel] [issue4054] Umlauts and sending contacts
	problem(rt#5956)
In-Reply-To: <1264512930.38.0.196997291758.issue4054@kolab.org>
Message-ID: <1264512930.38.0.196997291758.issue4054@kolab.org>


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

tested with Kontact e35 20100122.1078643-kk1

Test:
1. A creates a contact with umlauts "Testy T?st"
2. A sends the contact via context menu "send contact..." to B.
=> A mail with a vcf attachment is sent.
3. B syncs and looks at the mail.
4. B opens the vcf attachment.
=> The umlaut "?" is broken.
Seems to be an encoding problem. In the vcard attachment the FN: and N: part
doesn't contain a special encoding for the umlauts.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23247
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Umlauts and sending contacts problem(rt#5956)

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


From issues at kolab.org  Tue Jan 26 15:33:26 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Tue, 26 Jan 2010 14:33:26 +0000
Subject: [Kolab-devel] [issue4055] Workweek after restart is today and next
	4 days.(rt#5958)
In-Reply-To: <1264516406.19.0.641362190895.issue4055@kolab.org>
Message-ID: <1264516406.19.0.641362190895.issue4055@kolab.org>


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

tested with Kontact e35 20100122.1078643-kk1

Test:
Req: Today is not Monday.
1. Switch to the calendar.
2. Set view workweek.
=> The current workweek is selected.
3. Restart kontact.
=> Today and the next 4 days are selected, but not the current workweek.
I expect that the current workweek is selected after restart in this case.

Please estimate first. Wait on ok, before implementing.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23251
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Workweek after restart is today and next 4 days.(rt#5958)

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


From thomas at kdab.com  Tue Jan 26 16:47:20 2010
From: thomas at kdab.com (Thomas McGuire)
Date: Tue, 26 Jan 2010 16:47:20 +0100
Subject: [Kolab-devel] Question about the kolab storage format: Tag
	revision.
In-Reply-To: <201001221222.15495.ludwig.reiter@intevation.de>
References: <201001221222.15495.ludwig.reiter@intevation.de>
Message-ID: <201001261647.31112.thomas@kdab.com>

Hi,

On Friday 22 January 2010 12:22:15 Ludwig Reiter wrote:
> in the kolab.xml in a mail of an event is the tag <revision> which seems
> always to be 0. What is this tag for?

I couldn't find any mention of the revision tag at 
http://www.kolab.org/doc/kolabformat-2.0rc7-html/index.html.
Kontact never sets that value, so it is always written as 0. Also, Kontact 
reads this value, but never uses it in any way.

So I don't know what the revision field is for.


Regards,
Thomas
-- 
Thomas McGuire | thomas at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100126/0ea1db00/attachment.bin

From issues at kolab.org  Wed Jan 27 11:02:47 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 27 Jan 2010 10:02:47 +0000
Subject: [Kolab-devel] [issue4056] calendar month view: It is not visible in
	the big	calendar,
	which day is selected in the small month calendar.(rt#5960)
In-Reply-To: <1264586567.36.0.143983237422.issue4056@kolab.org>
Message-ID: <1264586567.36.0.143983237422.issue4056@kolab.org>


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

tested with Kontact e35 20100122.1078643-kk1

Test:
1. Switch to the calendar and activate the monthview.
2. Click on a day in the small month calendar in the upper left.
3. Look at the month view calendar.
=> The selected day is not really visible.
4. Select a day in the calendar.
=> The day is is selected in a different selection mode and visible selected.
I don't think, that there should be two selection modes.
Perhaps change the appearence of the mini-calendar selection mode, that it looks
like the calendar selection mode.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23258
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: calendar month view: It is not visible in the big calendar, which day is selected in the small month calendar.(rt#5960)

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


From issues at kolab.org  Wed Jan 27 11:29:34 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 27 Jan 2010 10:29:34 +0000
Subject: [Kolab-devel] [issue4057] Attach file: if filedialog default
	directory doesn't exit,
	it should use the home directory of the user as default.(rt#5962)
In-Reply-To: <1264588174.65.0.798894724082.issue4057@kolab.org>
Message-ID: <1264588174.65.0.798894724082.issue4057@kolab.org>


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

tested with Kontact e35 20100122.1078643-kk1

If in the attach file dialog a different directory is selected, the next time
the the attach dialog will be opened, the default directory is the before
seleted directory.
If the directory no longer exists, an error msg is shown. But in this case
kontact should use the user's home directory instead. (After a restart of
kontact, this directory is used.)

Please estimate first.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23260
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Attach file: if filedialog default directory doesn't exit, it should use the home directory of the user as default.(rt#5962)

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


From issues at kolab.org  Wed Jan 27 12:07:35 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 27 Jan 2010 11:07:35 +0000
Subject: [Kolab-devel] [issue4058] German translation of "No Suggestions" of
	the auto	spellchecking is missing.(rt#5964)
In-Reply-To: <1264590455.29.0.0846306782843.issue4058@kolab.org>
Message-ID: <1264590455.29.0.0846306782843.issue4058@kolab.org>


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

tested with Kontact e35 20100122.1078643-kk1

Test:
Req: Use aspell and German common for spellchecking.
Use German as language.
1. Start to create a new mail.
2. Enter something like "dsdfinfecmfm" or so and some spaces.
=> The word is displayed in red.
3. RMB on the word.
=> Because no Suggestion for this word can be found. It says, "No Suggestions"
But this is not translated into German.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23262
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: German translation of "No Suggestions" of the auto spellchecking is missing.(rt#5964)

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


From issues at kolab.org  Wed Jan 27 12:27:06 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 27 Jan 2010 11:27:06 +0000
Subject: [Kolab-devel] [issue4059] After deactivating of a calendar the
	small monthview is	not updated.(rt#5966)
In-Reply-To: <1264591626.49.0.647522558419.issue4059@kolab.org>
Message-ID: <1264591626.49.0.647522558419.issue4059@kolab.org>


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

tested with Kontact e35 20100122.1078643-kk1

Test:
In the calendar are some event.
Some days are displayed as bold in the small month calendar.
1. Deactivate all calendar resources.
=> The same days are displayed as bold.
Only days with events, which are displayed in the calendar, should be displayed
bold in the small month calendar.

Please estimate.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23263
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: After deactivating of a calendar the small monthview is not updated.(rt#5966)

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


From issues at kolab.org  Wed Jan 27 14:54:12 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 27 Jan 2010 13:54:12 +0000
Subject: [Kolab-devel] [issue4060] Wish: Auto-spellchecking: action to add
	new suggestion in	context menu(rt#5969)
In-Reply-To: <1264600452.67.0.572457509295.issue4060@kolab.org>
Message-ID: <1264600452.67.0.572457509295.issue4060@kolab.org>


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

tested with Kontact e35 20100122.1078643-kk1

Test:
1. Start to create a new mail.
2. Enter  a wrong word and spaces.
=> The word is display in red.
3. RMB on the word.
=> A list of suggestions pops up.
A new action "New Suggestion" should inserted into this context menu.
Which asks for a word, which is inserted in the suggestion dictionary.

Please estimate first and wait on an okay.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23264
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: Wish: Auto-spellchecking: action to add new suggestion in context menu(rt#5969)

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


From issues at kolab.org  Wed Jan 27 15:09:46 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 27 Jan 2010 14:09:46 +0000
Subject: [Kolab-devel] [issue4061] Show all mails after opening a mbox file
	with kontact	(rt#5970)
In-Reply-To: <1264601386.45.0.00514417532208.issue4061@kolab.org>
Message-ID: <1264601386.45.0.00514417532208.issue4061@kolab.org>


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

tested with Kontact e35 20100122.1078643-kk1

Test:
0. Switch to the mail part.
1. Select 3 mail and save them. (RMB->Save as...)
2. Open the mbox file.
=> A warning pops up and only the first mail is opened.
The users want all messages to be opened. Xor all mails to be saved seperatly.
I expect kontact to open a dialog to choose what to do and giving the user
information about how much mails are in the mbox: Open the first mail or open
all mails. 

Please estimate first and wait on a okay.

----------
assignedto: allen
keyword: enterprise35, kde client
messages: 23265
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: Show all mails after opening a mbox file with kontact (rt#5970)

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


From issues at kolab.org  Wed Jan 27 15:38:04 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Wed, 27 Jan 2010 14:38:04 +0000
Subject: [Kolab-devel] [issue4062] declined counterproposal asks for answer,
	but there are no buttons.(rt#5973)
In-Reply-To: <1264603084.45.0.732715189206.issue4062@kolab.org>
Message-ID: <1264603084.45.0.732715189206.issue4062@kolab.org>


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

tested with Kontact e35 20100122.1078643-kk1

Test:
1. A invites B.
2. B makes a counter proposal and sends it to A.
3. A delinces the counter proposal.
4. B looks at his mails. 
The update mail of the declined cp has two flaws:
* It says, B has declined the cp. But it was A.
* It asked for a response, but no action buttons are in the update mail.
The right person should be named as decliner and the user should be informed
about the way how to response. (Buttons?, Use the old invitation?)

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23266
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: bug
status: unread
title: declined counterproposal asks for answer, but there are no buttons.(rt#5973)

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


From issues at kolab.org  Wed Jan 27 15:52:47 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Wed, 27 Jan 2010 14:52:47 +0000
Subject: [Kolab-devel] [issue4063] New task is not visible in calendar
	side-by-side view
In-Reply-To: <1264603967.0.0.770715396257.issue4063@kolab.org>
Message-ID: <1264603967.0.0.770715396257.issue4063@kolab.org>


New submission from Emanuel Schuetze <emanuel at intevation.de>:

tested with enterprise35 20100122.1078643:

1. create new task
2. switch to calendar 
2a. month view: task is visible
2b. agenda view (merged calender view): task is visible
2c. agenda view (side-by-side view): task is _not_ visible!
=> Calendar should show task in extra side-by-side calendar if the task
ressource is enabled.

Maybe a subsequent error:
3. deactivate and reactivate the task ressource
4. switch to month view
=> Task is _not_ visible!
5. switch to task component of Kontact and open created task of step (1)
=> Task has now a due time ("00:00")!
6. Deactivate option "time associated". Ok.
7. Switch to calendar month view.
=> Task is again visible.

Seems to be a problem with step (3)?

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23267
nosy: allen, emanuel
priority: urgent
status: unread
title: New task is not visible in calendar side-by-side view

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


From issues at kolab.org  Wed Jan 27 16:05:56 2010
From: issues at kolab.org (Emanuel Schuetze)
Date: Wed, 27 Jan 2010 15:05:56 +0000
Subject: [Kolab-devel] [issue4064] Task with associated due time "00:00"
	isn't displayed in	all calendar views
In-Reply-To: <1264604756.3.0.556898479113.issue4064@kolab.org>
Message-ID: <1264604756.3.0.556898479113.issue4064@kolab.org>


New submission from Emanuel Schuetze <emanuel at intevation.de>:

1. create new task
2. activate "time associated" and set due time to "00:00"
=> Task isn't show in all calendar view!

Please notice also kolab/issue4063 (New task is not visible in calendar
side-by-side view). But it seems to be an other problem.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23268
nosy: allen, emanuel
priority: urgent
status: unread
title: Task with associated due time "00:00" isn't displayed in all calendar views

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


From issues at kolab.org  Thu Jan 28 10:34:31 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 28 Jan 2010 09:34:31 +0000
Subject: [Kolab-devel] [issue4065] Wish: Create new event: it should be
	possible to add it	into many calendar resources (rt#5952)
In-Reply-To: <1264671271.05.0.90348114273.issue4065@kolab.org>
Message-ID: <1264671271.05.0.90348114273.issue4065@kolab.org>


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

It should be possible to add a event into many calendar resources with the
creation of the event.

Test:
Req two calendar resources activated.
1. Switch to calendar.
2. Create a new event.
=> Choose resource dialog pops up.
With this choose calendar resource dialog it should be possible to enter the
event into more than one calendar resource.

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23271
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Wish: Create new event: it should be possible to add it into many calendar resources (rt#5952)

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


From issues at kolab.org  Thu Jan 28 11:12:12 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Thu, 28 Jan 2010 10:12:12 +0000
Subject: [Kolab-devel] [issue4066] Problems with quota warning(rt#5955)
In-Reply-To: <1264673532.52.0.666468436956.issue4066@kolab.org>
Message-ID: <1264673532.52.0.666468436956.issue4066@kolab.org>


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

tested with Kontact e35 20100122.1078643-kk1

I have add a second dimap account with a 11MB quota to my kontact.
Problems:
1.
Even after I had added 86% of the quota to folders of the 2nd dimap account, no
quota warning appeared. 
I expect a quota warning at greater or equal than 80%. 

2.
At 86% the folders get red. The users expect them to get red at 80%-85%, too.

3.
Favorite folder gets red after a second sync. The users expect the favorite
folders will get red, if the folders get red. 

The 2nd one is the main problem.

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

----------
assignedto: allen
keyword: enterprise35, kde client, kkc
messages: 23272
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Problems with quota warning(rt#5955)

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


From bernhard at intevation.de  Thu Jan 28 11:33:26 2010
From: bernhard at intevation.de (Bernhard Reiter)
Date: Thu, 28 Jan 2010 11:33:26 +0100
Subject: [Kolab-devel] Question about the kolab storage format: Tag
	revision.
In-Reply-To: <201001261647.31112.thomas@kdab.com>
References: <201001221222.15495.ludwig.reiter@intevation.de>
	<201001261647.31112.thomas@kdab.com>
Message-ID: <201001281133.30154.bernhard@intevation.de>

Am Dienstag, 26. Januar 2010 16:47:20 schrieb Thomas McGuire:
> On Friday 22 January 2010 12:22:15 Ludwig Reiter wrote:
> > in the kolab.xml in a mail of an event is the tag <revision> which seems
> > always to be 0. What is this tag for?
>
> I couldn't find any mention of the revision tag at
> http://www.kolab.org/doc/kolabformat-2.0rc7-html/index.html.
> Kontact never sets that value, so it is always written as 0. 

Okay, so it should not be written out then.
(Unless another client created it and it is preserved.)

> Also, Kontact 
> reads this value, but never uses it in any way.
>
> So I don't know what the revision field is for.


-- 
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/20100128/909c8a46/attachment.bin

From soliva at comcept.ch  Thu Jan 28 13:11:22 2010
From: soliva at comcept.ch (ComCept Soliva)
Date: Thu, 28 Jan 2010 13:11:22 +0100
Subject: [Kolab-devel]  Search: Invalid DN syntax function.ldap-search
In-Reply-To: <201001251436.49129.bernhard@intevation.de>
References: <000001ca9ce0$6f9c92e0$4ed5b8a0$@ch>
	<201001251436.49129.bernhard@intevation.de>
Message-ID: <000301caa013$021da340$0658e9c0$@ch>

Hi 

It is from my point of view clear the search function but even I see the
lines I can not identify what is false and why?:

syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 204


201    function search( $base, $filter, $attrs = false ) {
   202      $this->freeSearchResult();
   203      if( $attrs ) {
   204            $this->search_result = ldap_search( $this->connection,
$base, $filter, $attrs );
   205          } else {
   206            $this->search_result = ldap_search( $this->connection,
$base, $filter );
   207          }
   208      return $this->search_result;
   209    }


is not a valid ldap result resource in
/opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424

   411    // Count the number of occurences of an email address
   412    // in users' mail and alias attributes and in dist. lists.
   413    // This can be used to check for uniqueness etc.
   414    function countMail( $base, $mail , $excludedn=false ) {
   415          // First count users
   416          $filter = '(|(|(mail='.$this->escape($mail).')
   417                         (alias='.$this->escape($mail).')
   418                       )
   419                       (uid='.$this->escape($mail).')
   420                     )';
   421          $res = $this->search( $this->dn_escape($base), $filter,
array( 'dn' ) );
   422          $count = 0;
   423
   424          $entries = ldap_get_entries( $this->connection, $res );
   425          if( $excludedn ) {
   426            for ( $i = 0; $i < count( $entries ); $i++ ) {
   427                  if( is_null( $entries[$i] ) ) continue;
   428                  if( KolabLDAP::unescape_dn_value($entries[$i]['dn'])
== KolabLDAP::unescape_dn_value($excludedn) ) continue;
   429                  debug("found ".$entries[$i]['dn'] );
   430                  $count++;
   431            }
   432          } else $count += $entries['count'];


Kind regards

Andrea Soliva

Mail: soliva at comcept.ch 
-----Urspr?ngliche Nachricht-----
Von: Bernhard Reiter [mailto:bernhard at intevation.de] Im Auftrag von
kolab-devel-bounces at kolab.org
Gesendet: Montag, 25. Januar 2010 14:37
An: kolab-devel at kolab.org
Betreff: Re: [Kolab-devel] Search: Invalid DN syntax function.ldap-search

Am Sonntag, 24. Januar 2010 11:31:48 schrieb ComCept Soliva:
> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_search() [<a
> href='function.ldap-search'>function.ldap-search</a>]: Search: Invalid DN
> syntax in /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line
204
> [23-Jan-2010 14:59:36] PHP Warning: ?ldap_get_entries(): supplied argument
> is not a valid ldap result resource in
> /opt/kolab/var/kolab/php/admin/include/ldap.class.php on line 424
>
> Is this already recognized? Is it not known....I tried to figure out what
> is wrong but actually I could not?!
>
> Any suggestion?

My suggestion is to check the given line 204 and see which argument
is used there (maybe add a statement to print it out).

> By the way is there a documentation about Master/Slave configuration
> meaning how this works etc. I could not find anything. Any hints would be
> appriciated.

I think the documentation is in the architecture documents.
The idea is pretty simple: Replicate the directory server on the slave
(for which there is a bootstrap) have all read access on the slave accounts
go 
to the slave LDAP server and all write access (only by webadmin) to the 
master.

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


From issues at kolab.org  Thu Jan 28 14:03:35 2010
From: issues at kolab.org (Axel Spoerl)
Date: Thu, 28 Jan 2010 13:03:35 +0000
Subject: [Kolab-devel] [issue4067] Syncml: Multiple contact folders
In-Reply-To: <1264683815.98.0.795361241493.issue4067@kolab.org>
Message-ID: <1264683815.98.0.795361241493.issue4067@kolab.org>


New submission from Axel Spoerl <axel at spoerls.net>:

When selecting more than one contact folder to be synced via SyncML, the email
records are being transmitted incorrectly from the server to the client. An
invalid email record containing "Array at localhost" is added to the original list
of email addresses. This applies to all contacts stored in additional folders
(i.e. shared contact folders). All contacts in the user's original contact
folder are being trasmitted correctly.

----------
messages: 23276
nosy: axel-vienna
priority: bug
status: unread
title: Syncml: Multiple contact folders

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


From issues at kolab.org  Thu Jan 28 14:11:01 2010
From: issues at kolab.org (Axel Spoerl)
Date: Thu, 28 Jan 2010 13:11:01 +0000
Subject: [Kolab-devel] [issue4068] SynML: Duplicate telephone number types
In-Reply-To: <1264684261.26.0.220513662966.issue4068@kolab.org>
Message-ID: <1264684261.26.0.220513662966.issue4068@kolab.org>


New submission from Axel Spoerl <axel at spoerls.net>:

When a contact is stored with two different phone numbers of the same type (e.g.
two mobile phone numbers), only the last number with a duplicate type is being
transmitted from the server to the client. All other telephone numbers are being
ommitted (also those with other types).

(1) Example
Numbers stored in server record:
Work: +43 1 1111111
Home: +43 1 2222222
Mobile: +43 664 3333333
Mobile: +43 664 4444444

Numbers trasmitted to the client via SyncML
Mobile: +43 664 4444444

(2) Workaround
If a different number type is assigned to one of the duplicates, all numbers are
transmitted correctly.

Numbers stored in server record:
Work: +43 1 1111111
Home: +43 1 2222222
Mobile: +43 664 3333333
Pager: +43 664 4444444

Numbers trasmitted to the client via SyncML
Work: +43 1 1111111
Home: +43 1 2222222
Mobile: +43 664 3333333
Pager: +43 664 4444444

----------
messages: 23277
nosy: axel-vienna
priority: bug
status: unread
title: SynML: Duplicate telephone number types

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


From issues at kolab.org  Thu Jan 28 14:13:54 2010
From: issues at kolab.org (Axel Spoerl)
Date: Thu, 28 Jan 2010 13:13:54 +0000
Subject: [Kolab-devel] [issue4069] SynML: New client contact entries ommitted
In-Reply-To: <1264684434.22.0.133916741859.issue4069@kolab.org>
Message-ID: <1264684434.22.0.133916741859.issue4069@kolab.org>


New submission from Axel Spoerl <axel at spoerls.net>:

If a SyncML client creates a new contact entry, it is correctly being
transmitted to the server but not stored in Kolab. Probably, a definition of a
default storage folder for new entries is missing (in case more than one sync
folders have been selected).

----------
messages: 23278
nosy: axel-vienna
priority: bug
status: unread
title: SynML: New client contact entries ommitted

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


From issues at kolab.org  Thu Jan 28 16:18:55 2010
From: issues at kolab.org (Falk Scheerschmidt)
Date: Thu, 28 Jan 2010 15:18:55 +0000
Subject: [Kolab-devel] [issue4070] Kolab 2.2.3 upgrade issue in Debian Lenny
In-Reply-To: <1264691935.34.0.928236104931.issue4070@kolab.org>
Message-ID: <1264691935.34.0.928236104931.issue4070@kolab.org>


New submission from Falk Scheerschmidt <falk at wildsmile.de>:

since kolab 2.2.3 is out, i can not upgrade the package without these commands:

$ touch /etc/apache2/sites-available/kolab
$ a2ensite kolab

i think the postinstall script doesn't handle the case, that the kolab site in
apache doesn't exists.

----------
messages: 23280
nosy: falk
priority: bug
status: unread
title: Kolab 2.2.3 upgrade issue in Debian Lenny

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


From issues at kolab.org  Fri Jan 29 13:53:06 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Fri, 29 Jan 2010 12:53:06 +0000
Subject: [Kolab-devel] [issue4072] too small window: kleopatra: German
	export secret	key(rt#5848)
In-Reply-To: <1264769586.5.0.745893951304.issue4072@kolab.org>
Message-ID: <1264769586.5.0.745893951304.issue4072@kolab.org>


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

tested with Kontact e35 20100122.1078643-kk1

Test:
Fresh debian/lenny account with imported secret S/MIME key.
language: German.
1. Start kontact
2. Open kleopatra
3. Export the secrect key.
=> the border of the select key dialog covers the Cancel button

See export-20100129.png for details.

----------
assignedto: allen
files: export-20100129.png
keyword: enterprise35, kde client
messages: 23291
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: minor bug
status: unread
title: too small window: kleopatra: German export secret key(rt#5848)

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4072>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: export-20100129.png
Type: image/png
Size: 32674 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100129/f43c3f5e/export-20100129-0001.png

From issues at kolab.org  Sun Jan 31 12:59:08 2010
From: issues at kolab.org (jochen may)
Date: Sun, 31 Jan 2010 11:59:08 +0000
Subject: [Kolab-devel] [issue4073] Problems with Event View on Kontact/Win XP
In-Reply-To: <1264939148.0.0.330109979178.issue4073@kolab.org>
Message-ID: <1264939148.0.0.330109979178.issue4073@kolab.org>


New submission from jochen may <gerribaldi at jmay.org>:

I create on Linux a new event, for example from 10.00 ? 11.00. On the Linux 
clients and on Horde everything looks good, no matter wich kind of view i 
chose (? Day, Weekly or Month). On Windows the day and weekly view are ok. 
When i display a month, the time of the event show 1 hour to early. In this 
case from 9.00 ? 10.00. A double click on the event show me the right time. 
Also on the left site, where the detailed information of this event are 
displayed, the time is ok.

Kontact is running in Version 1.3 (enterprise4 0.20091204.1058385) on 
Windows XP SP2

----------
keyword: kde client, windows
messages: 23303
nosy: jochen
priority: bug
status: unread
title: Problems with Event View on Kontact/Win XP

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


From issues at kolab.org  Sun Jan 31 13:01:22 2010
From: issues at kolab.org (jochen may)
Date: Sun, 31 Jan 2010 12:01:22 +0000
Subject: [Kolab-devel] [issue4074] Kontact on Win don't show calender/adress
	book in offline	mode
In-Reply-To: <1264939282.62.0.178100651809.issue4074@kolab.org>
Message-ID: <1264939282.62.0.178100651809.issue4074@kolab.org>


New submission from jochen may <gerribaldi at jmay.org>:

When Kontact is running offline, i can not access the calender and the 
adress book. But the notes and tasks are working. I try to explain this: 
Kontact is running online, everything ist ok and i can access both. Now i 
shutdown kontact and disconnected from the network. Now i restart kontact and 
switch to the calender. In the ressource window (in the left bottom corner) 
are still my imap ressource (but without the subfolders, like shared.calender, 
own calender, ...). I need to delete the imar ressource and add a new one with 
the right mouse button. There i choose imap-calender via kmail and voila, my 
calender incl. the subfolders are back. The same happens to the adress book. 
This is happen every time i start kontact offline

Kontact is running in Version 1.3 (enterprise4 0.20091204.1058385) on 
Windows XP SP2

----------
keyword: kde client, windows
messages: 23304
nosy: jochen
priority: bug
status: unread
title: Kontact on Win don't show calender/adress book in offline mode

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


From issues at kolab.org  Tue Jan  5 15:46:51 2010
From: issues at kolab.org (Bernhard Reiter)
Date: Tue, 05 Jan 2010 14:46:51 -0000
Subject: [Kolab-devel] [issue4012] Calender view update problem,
	if the same appointment is moved on the server in other folders
In-Reply-To: <1262702806.66.0.667226306317.issue4012@kolab.org>
Message-ID: <1262702806.66.0.667226306317.issue4012@kolab.org>


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

Setup: Have one user which has write access to two calenders G1 and G2.
The property of G1 and G2 is that they are accepting all invitations
immedeately, I am using group accounts on a Kolab Server with the policy of
accepting everything. Side-by-side calender view enabled.

a) Make an appointment and invite G1 and G2. Sync on the calender view.
   (It is not necessary to leave the calender view to see the issue.)
   Now in all three calenders you can see all three appointment at the
same time (kontact-20100105-1.png)

b) Now move the appointment in your own calender to another hour. Say yes to 
   send out the emails. And press calender sync.
   Observation: Your appointment is gone and now in the last G2 calender.
                G1 and G2 are still at the same place.
   See(kontact-20100105-2.png)
Expectation my appointment should stay there.
c) Now press sync again and my appointment jumps to G1.
   (kontact-20100105-3.png)
Further syncs do not change anything. Though I expect all to be fine
on the server. Switching back and forth to other views also does not help.

d) Disabling only my calender folder, makes it go okay.
(kontact-20100105-4.png)

e) Switching the other two folders also makes them look right.

So this most likely is a view update problem. Please try to fix right
away and if you can with a save patch to the 20091211 tag as well.

 Send, sync, see all three.
        Move M one hour. Asks for email sending, yes should be done.

        Gone from M, there in G1 (old) and twice G2 (old and new).
        Solution: switch resource folder on an off and all is good.
        But users will move the old appointment.


Reproduced with:
3.5.10.enterprise.0.20091211.1065532-kk4

----------
assignedto: allen
files: kontact-20100105-2.png
keyword: enterprise35, kde client, kkc
messages: 22985
nosy: allen, bernhard, emanuel, ludwig, till, tmcguire, vkrause
priority: critical
status: unread
title: Calender view update problem, if the same appointment is moved on the server in other folders

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4012>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kontact-20100105-2.png
Type: image/png
Size: 108283 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100105/fa6e3dee/kontact-20100105-2-0001.png

From rmayr at debian.org  Mon Jan 18 01:53:56 2010
From: rmayr at debian.org (Rene Mayrhofer)
Date: Mon, 18 Jan 2010 00:53:56 -0000
Subject: [Kolab-devel] Kolab Z-Push 0.2 only working one-way,
	mobile-to-server broken
Message-ID: <201001180145.07639.rmayr@debian.org>

Hi everybody,

[Please CC me in replies, I am currently not subscribed to kolav-devel.]

I have been trying to get Activesync/Z-Push synchronization to a Kolab server 
running during the past 2 days. The setup is inside a VM running Debian 
squeeze with the most recent native Debian packages of Kolab and Horde. Z-Push 
was taken from svn trunk today (and I also tried version 1.2.3RC with no 
improvement), the Kolab backend 0.2 as linked from the Wiki page and configured 
as described.
Test clients are an iPhone 3GS wiith OS 3.1.2, a Motorola Milestone (German 
Android firmware 2.0) and a HTC Hero (with stock HTC Android Cupcake/1.5 
including the HTC Activesync implementation). If necessary, I can add a Nokia 
N95, a HTC Touch Diamond, and (probably within a week) a Nokia N900 to the mix 
to cover all major mobile platforms with the exception of Blackberry.

All mobile clients currently show the same behaviour, indepedently of the 
synchronization period (push, manual, or poll): they can fetch contacts and 
calendar items from the server (either created with Kontact from KDE 4.3 or 
using the Horde webclient), but no item created on any of the clients gets 
synchronized to the server. 
Unfortunately, the standard z-push log doesn't seem to indicate any particular 
reason for this, which is why I am asking for pointers this way. RTFM would be 
welcome, a request for more debugging logs better, or a "oh a we know that, 
apply this patch" response obviously best ;-) I can probably help in creating 
debug logs using different clients, although I am not much of a PHP coder and 
thus reluctant to go into the code myself.

PS: There is a second issue of the Motorola Milestone not displaying the 
option of synchronizing the calendar at all. Contacts can be selected and get 
fetched from the server, but there is no calendar options. The same client 
(built-in Android 2.0 I assume) works for both contacts and calendar when 
connected to an Exchange 2007 server, though.

Any pointers would be highy appreciated,
Rene
-------------- 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/20100118/b4ea7238/attachment-0001.bin

From rmayr at debian.org  Mon Jan 18 11:09:28 2010
From: rmayr at debian.org (Rene Mayrhofer)
Date: Mon, 18 Jan 2010 10:09:28 -0000
Subject: [Kolab-devel] Kolab Z-Push 0.2 only working one-way,
	mobile-to-server broken
In-Reply-To: <5867F440-E9D8-440D-9E79-FE46CDF65D34@libertech.fr>
References: <201001180145.07639.rmayr@debian.org>
	<5867F440-E9D8-440D-9E79-FE46CDF65D34@libertech.fr>
Message-ID: <201001181109.07044.rmayr@debian.org>

Hi Alain,

Am Montag, 18. Januar 2010 08:28:20 schrieb alain abbas:
> create a file debug.txt in z-push dir with right at 666 , test a
> synchro and send me this file please ,you can send me too the logfile
> (/var/log/z-push/access.log) tje name is in config.txt
> 
> try with the iphone i m sure its ok

I disabled the accounts on the Milestone and the Hero, then disabled the 
account on the iPhone. The attached debug and log files show what happened in 
the first few minutes after activating contacts and calendar on the iPhone 
again (3 contacts and 3 calendar items got synced from the server to the 
phone) and adding a new calendar item (today, 14:15) on the iPhone (which did 
not get pushed to the server).

best regards,
Rene
 
> Le 18 janv. 2010 ? 01:44, Rene Mayrhofer <rmayr at debian.org> a ?crit :
> > Hi everybody,
> >
> > [Please CC me in replies, I am currently not subscribed to kolav-
> > devel.]
> >
> > I have been trying to get Activesync/Z-Push synchronization to a
> > Kolab server
> > running during the past 2 days. The setup is inside a VM running
> > Debian
> > squeeze with the most recent native Debian packages of Kolab and
> > Horde. Z-Push
> > was taken from svn trunk today (and I also tried version 1.2.3RC
> > with no
> > improvement), the Kolab backend 0.2 as linked from the Wiki page and
> > configured
> > as described.
> > Test clients are an iPhone 3GS wiith OS 3.1.2, a Motorola Milestone
> > (German
> > Android firmware 2.0) and a HTC Hero (with stock HTC Android Cupcake/
> > 1.5
> > including the HTC Activesync implementation). If necessary, I can
> > add a Nokia
> > N95, a HTC Touch Diamond, and (probably within a week) a Nokia N900
> > to the mix
> > to cover all major mobile platforms with the exception of Blackberry.
> >
> > All mobile clients currently show the same behaviour, indepedently
> > of the
> > synchronization period (push, manual, or poll): they can fetch
> > contacts and
> > calendar items from the server (either created with Kontact from KDE
> > 4.3 or
> > using the Horde webclient), but no item created on any of the
> > clients gets
> > synchronized to the server.
> > Unfortunately, the standard z-push log doesn't seem to indicate any
> > particular
> > reason for this, which is why I am asking for pointers this way.
> > RTFM would be
> > welcome, a request for more debugging logs better, or a "oh a we
> > know that,
> > apply this patch" response obviously best ;-) I can probably help in
> > creating
> > debug logs using different clients, although I am not much of a PHP
> > coder and
> > thus reluctant to go into the code myself.
> >
> > PS: There is a second issue of the Motorola Milestone not displaying
> > the
> > option of synchronizing the calendar at all. Contacts can be
> > selected and get
> > fetched from the server, but there is no calendar options. The same
> > client
> > (built-in Android 2.0 I assume) works for both contacts and calendar
> > when
> > connected to an Exchange 2007 server, though.
> >
> > Any pointers would be highy appreciated,
> > Rene
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug.txt.gz
Type: application/x-gzip
Size: 53894 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100118/f8997df7/debug.txt-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: z-push.log.gz
Type: application/x-gzip
Size: 1301 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100118/f8997df7/z-push.log-0001.bin
-------------- 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/20100118/f8997df7/attachment-0001.bin

From rmayr at debian.org  Wed Jan 20 21:32:41 2010
From: rmayr at debian.org (Rene Mayrhofer)
Date: Wed, 20 Jan 2010 20:32:41 -0000
Subject: [Kolab-devel] Kolab Z-Push 0.2 only working one-way,
	mobile-to-server broken
In-Reply-To: <4B5573D8.9040904@libertech.fr>
References: <201001180145.07639.rmayr@debian.org>
	<201001181109.07044.rmayr@debian.org>
	<4B5573D8.9040904@libertech.fr>
Message-ID: <201001202131.56552.rmayr@debian.org>

Am Dienstag, 19. Januar 2010 09:56:56 schrieb Alain abbas:
> there are a miss in your installation
> 
> :26 [2058] z-push/backend_0.2/diffbackend.php:21
> 
> include_once(backend.php) [<a
> href='function.include-once'>function.include-once</a>]: failed to open
> stream: No such file or directory (2)
> 
> the Kolab backend must be in the directory backend with the others
> z-push files
> try like that

I already had it installed according to the Wiki page - the kolab.php and 
diffbackend.php were symlinked from backend_0.2 to backend/. To be sure, I now 
completely removed the backend_0.2 directory, so that all files are now only in 
backend/, with no duplicates. Looking at the line given in one of the error 
messages, I also corrected KOLAB_INDEX in config.php to use the full pathname 
(/srv/z-push/kolabindex in my case). I still have the same problem that 
calendar and contact items are not copied from the devices (I tried it with an 
iPhone 3GS) to the server. 

My config.php and the new debug.txt are attached. Is there anything else I can 
try?

best regards,
Rene

> Rene Mayrhofer a ?crit :
> > Hi Alain,
> >
> > Am Montag, 18. Januar 2010 08:28:20 schrieb alain abbas:
> >> create a file debug.txt in z-push dir with right at 666 , test a
> >> synchro and send me this file please ,you can send me too the logfile
> >> (/var/log/z-push/access.log) tje name is in config.txt
> >>
> >> try with the iphone i m sure its ok
> >
> > I disabled the accounts on the Milestone and the Hero, then disabled the
> > account on the iPhone. The attached debug and log files show what
> > happened in the first few minutes after activating contacts and calendar
> > on the iPhone again (3 contacts and 3 calendar items got synced from the
> > server to the phone) and adding a new calendar item (today, 14:15) on the
> > iPhone (which did not get pushed to the server).
> >
> > best regards,
> > Rene
> >
> >> Le 18 janv. 2010 ? 01:44, Rene Mayrhofer <rmayr at debian.org> a ?crit :
> >>> Hi everybody,
> >>>
> >>> [Please CC me in replies, I am currently not subscribed to kolav-
> >>> devel.]
> >>>
> >>> I have been trying to get Activesync/Z-Push synchronization to a
> >>> Kolab server
> >>> running during the past 2 days. The setup is inside a VM running
> >>> Debian
> >>> squeeze with the most recent native Debian packages of Kolab and
> >>> Horde. Z-Push
> >>> was taken from svn trunk today (and I also tried version 1.2.3RC
> >>> with no
> >>> improvement), the Kolab backend 0.2 as linked from the Wiki page and
> >>> configured
> >>> as described.
> >>> Test clients are an iPhone 3GS wiith OS 3.1.2, a Motorola Milestone
> >>> (German
> >>> Android firmware 2.0) and a HTC Hero (with stock HTC Android Cupcake/
> >>> 1.5
> >>> including the HTC Activesync implementation). If necessary, I can
> >>> add a Nokia
> >>> N95, a HTC Touch Diamond, and (probably within a week) a Nokia N900
> >>> to the mix
> >>> to cover all major mobile platforms with the exception of Blackberry.
> >>>
> >>> All mobile clients currently show the same behaviour, indepedently
> >>> of the
> >>> synchronization period (push, manual, or poll): they can fetch
> >>> contacts and
> >>> calendar items from the server (either created with Kontact from KDE
> >>> 4.3 or
> >>> using the Horde webclient), but no item created on any of the
> >>> clients gets
> >>> synchronized to the server.
> >>> Unfortunately, the standard z-push log doesn't seem to indicate any
> >>> particular
> >>> reason for this, which is why I am asking for pointers this way.
> >>> RTFM would be
> >>> welcome, a request for more debugging logs better, or a "oh a we
> >>> know that,
> >>> apply this patch" response obviously best ;-) I can probably help in
> >>> creating
> >>> debug logs using different clients, although I am not much of a PHP
> >>> coder and
> >>> thus reluctant to go into the code myself.
> >>>
> >>> PS: There is a second issue of the Motorola Milestone not displaying
> >>> the
> >>> option of synchronizing the calendar at all. Contacts can be
> >>> selected and get
> >>> fetched from the server, but there is no calendar options. The same
> >>> client
> >>> (built-in Android 2.0 I assume) works for both contacts and calendar
> >>> when
> >>> connected to an Exchange 2007 server, though.
> >>>
> >>> Any pointers would be highy appreciated,
> >>> Rene
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.php
Type: application/x-php
Size: 3720 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100120/eb846bcf/config-0001.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug.txt.gz
Type: application/x-gzip
Size: 25069 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100120/eb846bcf/debug.txt-0001.bin
-------------- 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/20100120/eb846bcf/attachment-0001.bin

From issues at kolab.org  Mon Jan 25 15:32:36 2010
From: issues at kolab.org (Ludwig Reiter)
Date: Mon, 25 Jan 2010 14:32:36 -0000
Subject: [Kolab-devel] [issue4051] Side-by-Side view scale problem
In-Reply-To: <1264429950.97.0.183107130766.issue4051@kolab.org>
Message-ID: <1264429950.97.0.183107130766.issue4051@kolab.org>


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

tested with Kontact e35 20100122.1078643-kk1

Test:
1. Switch to calendar with side-by-side view.
=> Scale and calendar don't fit.

See screenshot.

----------
assignedto: allen
files: side-by-side-20100125.png
keyword: enterprise35, kde client
messages: 23240
nosy: allen, laurent, ludwig, till, tmcguire, vkrause
priority: urgent
status: unread
title: Side-by-Side view scale problem

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4051>
______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: side-by-side-20100125.png
Type: image/png
Size: 115613 bytes
Desc: not available
Url : http://kolab.org/pipermail/kolab-devel/attachments/20100125/7657dba0/side-by-side-20100125-0001.png

From =?utf-8?q?Thomas_B=C3=B6rnert_=3Cissues=40kolab=2Eorg=3E?= at issues.kolab.org  Fri Jan 29 10:38:50 2010
From: =?utf-8?q?Thomas_B=C3=B6rnert_=3Cissues=40kolab=2Eorg=3E?= at issues.kolab.org (=?utf-8?q?Thomas_B=C3=B6rnert_=3Cissues=40kolab=2Eorg=3E?=@issues.kolab.org)
Date: Fri, 29 Jan 2010 09:38:50 -0000
Subject: [Kolab-devel] [issue4071] kolabfilter catchall bcc problem
In-Reply-To: <1264757928.99.0.71039437933.issue4071@kolab.org>
Message-ID: <1264757928.99.0.71039437933.issue4071@kolab.org>


New submission from Thomas B?rnert <tb at tbits.net>:

kolab version 2.2.3

kolab account info at domain.de configured as catchall with alias @domain.de

new mail send to kolab/postfix
from: sender at domain.de
to: receipient at domain.de
bcc: bcc at domain.de

the bcc mail will not being delivered

the postfix log shows
---------------------

Jan 29 09:57:32 kolab01 <info> postfix/smtpd[11223]: EEE3D94100:
client=pd95c69dc.dip0.t-ipconnect.de[217.92.105.220], sasl_method=PLAIN,
sasl_username=pop-12345-0001
Jan 29 09:57:33 kolab01 <info> postfix/cleanup[11024]: EEE3D94100:
message-id=<4B62A2D9.1080606 at domain.de>
Jan 29 09:57:33 kolab01 <info> postfix/qmgr[10890]: EEE3D94100:
from=<sender at domain.de>, size=603, nrcpt=2 (queue active)
Jan 29 09:57:33 kolab01 <info> postfix/smtpd[11027]: connect from
localhost.localdomain[127.0.0.1]
Jan 29 09:57:33 kolab01 <info> postfix/smtpd[11027]: 5886B94105:
client=localhost.localdomain[127.0.0.1]
Jan 29 09:57:33 kolab01 <info> postfix/smtpd[11223]: disconnect from
pd95c69dc.dip0.t-ipconnect.de[217.92.105.220]
Jan 29 09:57:33 kolab01 <info> postfix/cleanup[11028]: 5886B94105:
message-id=<4B62A2D9.1080606 at domain.de>
Jan 29 09:57:33 kolab01 <info> postfix/qmgr[10890]: 5886B94105:
from=<sender at domain.de>, size=761, nrcpt=1 (queue active)
Jan 29 09:57:33 kolab01 <info> postfix/smtpd[11027]: disconnect from
localhost.localdomain[127.0.0.1]
Jan 29 09:57:33 kolab01 <info> postfix/pipe[11025]: EEE3D94100:
to=<info at domain.de>, orig_to=<recipient at domain.de>, relay=kolabfilter,
delay=0.72, delays=0.46/0/0/0.27, dsn=2.0.0, status=sent (delivered via
kolabfilter service)
Jan 29 09:57:33 kolab01 <info> postfix/pipe[11025]: EEE3D94100:
to=<info at domain.de>, orig_to=<bcc at domain.de>, relay=kolabfilter, delay=0.72,
delays=0.46/0/0/0.27, dsn=2.0.0, status=sent (delivered via kolabfilter service)
Jan 29 09:57:33 kolab01 <info> postfix/qmgr[10890]: EEE3D94100: removed
Jan 29 09:57:33 kolab01 <info> postfix/pipe[12082]: 5886B94105:
to=<info at domain.de>, relay=kolabmailboxfilter, delay=0.42,
delays=0.11/0.01/0/0.3, dsn=2.0.0, status=sent (delivered via kolabmailboxfilter
service)
Jan 29 09:57:33 kolab01 <info> postfix/qmgr[10890]: 5886B94105: removed

the log from kolabfilter shows
------------------------------

Jan 29 09:57:33 Kolab Filter [debug] [horde] Arguments: Horde_Argv_Values Object
(
    [sender] => sender at domain.de
    [recipient] => Array
        (
            [0] => info at domain.de
            [1] => info at domain.de
        )

    [host] => mail.tbits.net
    [client] => 217.92.105.220
    [user] => pop-12345-0001
    [config] => /kolab/etc/kolab/kolabfilter.conf
)
 [on line 244 of "/kolab/lib/php/Horde/Kolab/Filter/Base.php"]
Jan 29 09:57:33 Kolab Filter [info] [horde] Horde_Kolab_Filter_Content
successfully completed (sender=sender at domain.de, recipients=info at domain.de,
info at domain.de, client_address=217.92.105.220, id=<4B62A2D9.1080606 at domain.de>)
[on line 141 of "/kolab/lib/php/Horde/Kolab/Filter/Base.php"]
Jan 29 09:57:33 Kolab Filter [debug] [horde] Arguments: Horde_Argv_Values Object
(
    [sender] => sender at domain.de
    [recipient] => Array
        (
            [0] => info at domain.de
        )

    [host] => mail.tbits.net
    [client] => 127.0.0.1
    [user] =>
    [config] => /kolab/etc/kolab/kolabfilter.conf
)
 [on line 244 of "/kolab/lib/php/Horde/Kolab/Filter/Base.php"]
Jan 29 09:57:33 Kolab Filter [debug] [horde] Filter_Incoming successfully
completed. [on line 174 of "/kolab/lib/php/Horde/Kolab/Filter/Incoming.php"]
Jan 29 09:57:33 Kolab Filter [info] [horde] Horde_Kolab_Filter_Incoming
successfully completed (sender=sender at domain.de, recipients=info at domain.de,
client_address=127.0.0.1, id=<4B62A2D9.1080606 at domain.de>) [on line 141 of
"/kolab/lib/php/Horde/Kolab/Filter/Base.php"]
Jan 29 09:58:16 Kolab Filter [debug] [horde] Arguments: Horde_Argv_Values Object

problem
-------

it's only the mail to recipient stored in the inbox, the bcc mail is missing.

----------
assignedto: tboernert
keyword: kolab-2.1
messages: 23286
nosy: bernhard, tboernert
priority: minor bug
status: unread
title: kolabfilter catchall bcc problem

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