From daniel.morlock at gmail.com Fri Aug 1 10:11:44 2014 From: daniel.morlock at gmail.com (Daniel Morlock) Date: Fri, 01 Aug 2014 10:11:44 +0200 Subject: [Kolab-devel] Kolab 3.2 Migration Message-ID: Hi, we almost finished the Gentoo packages for Kolab 3.2. Now we're challenging the migration path from Kolab 3.1 to Kolab 3.2. To determine the database changes between those versions, we could setup a fresh Kolab 3.1 and a fresh Kolab 3.2, run the "setup-kolab" script and compare the differences. Since this is a really hard way to go, we are wondering whether there is an easier way to get the changes? How to you migrate enterprise updates? You do offer an migration path, do you? Also the "setup-kolab" tool is one-way only and - as far as I know - it only supports a fresh installation but no updates. Are there any attempts to add update routines? Thanks, Daniel. From vanmeeuwen at kolabsys.com Mon Aug 4 01:31:24 2014 From: vanmeeuwen at kolabsys.com (Jeroen van Meeuwen (Kolab Systems)) Date: Mon, 04 Aug 2014 01:31:24 +0200 Subject: [Kolab-devel] Bugzilla Restructuring Message-ID: <1cc0176798e9ed1a430d84d536d62a56@kolabsys.com> Hi there, I know you're all in great anticipation of the forthcoming release of Kolab 3.3, which is to be released at or around August 14th, but we have instead restructured Bugzilla (such a dissapointment, nay?). We believe the new structure better allows us to track "what has happened" with a particular piece of software, such as Roundcube or PyKolab, and therefore be better at doing releases (because we have appropriate milestones now), changelogs, update instructions, and so forth. One major aspect is that we have also introduced a set of new ticket statuses. You will find a description of their intended meaning here: http://docs.kolab.org/developer-guide/bugzilla.html This will be the canonical location for further updates to the Bugzilla workflow. Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 From vanmeeuwen at kolabsys.com Mon Aug 4 01:40:18 2014 From: vanmeeuwen at kolabsys.com (Jeroen van Meeuwen (Kolab Systems)) Date: Mon, 04 Aug 2014 01:40:18 +0200 Subject: [Kolab-devel] Kolab 3.3 release forthcoming Message-ID: Hi there, As mentioned in the other email, we have a pending release of Kolab 3.3 this month, at or around the 14th (which is six months after the Kolab 3.2 release on Valentine's day, henceforth to be referred to as Kolab Release day). From experience (and from looking at my agenda) I know it's *NOT* going to be the 14th, rather after the following weekend (the 19th or 20th). Also from experience, I'm asking you to get your bug reports in *NOW*; - use Kolab:Development to install what is to become Kolab 3.3, if at all possible (otherwise, log bug), - test functionality -- most things have had one or another change, - those with the ability to test upgrades, please do -- especially with regards to existing mail spools. I'm looking forward to your reports of failure, I'll take every single one of them as a compliment ;-) That said, if you report one and I go "oh, nice catch!", you've earned yourself a beer. Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 From vanmeeuwen at kolabsys.com Mon Aug 4 02:05:35 2014 From: vanmeeuwen at kolabsys.com (Jeroen van Meeuwen (Kolab Systems)) Date: Mon, 04 Aug 2014 02:05:35 +0200 Subject: [Kolab-devel] Kolab 3.2 Migration In-Reply-To: References: Message-ID: <67b46b9da4973012b8acfbd48e8bcab1@kolabsys.com> On 2014-08-01 10:11, Daniel Morlock wrote: > Hi, > > we almost finished the Gentoo packages for Kolab 3.2. Now we're > challenging the migration path from Kolab 3.1 to Kolab 3.2. To > determine > the database changes between those versions, we could setup a fresh > Kolab 3.1 and a fresh Kolab 3.2, run the "setup-kolab" script and > compare the differences. Since this is a really hard way to go, we are > wondering whether there is an easier way to get the changes? > > How to you migrate enterprise updates? You do offer an migration path, > do you? > > Also the "setup-kolab" tool is one-way only and - as far as I know - it > only supports a fresh installation but no updates. Are there any > attempts to add update routines? > The "setup-kolab" routine is indeed a one-shot, one-kill delivery mechanism with the *sole* purpose of initially setting up a Kolab server. As for the enterprise -- this works so much differently, you can't really compare it. For one, upgrades are different from updates over there. That said, we support updates of course, prohibit requiring manual intervention, refactoring bug fixes and enhancements to not require database schema upgrades, etc. Like I said, it's completely different ;-) Database schema upgrades to those components that indeed do need database schema upgrades every once in a while are triggered by their respective packages, in a post installation routine: Line 300-303 at https://obs.kolabsys.com/package/view_file/Kolab:Development/roundcubemail/roundcubemail.spec?expand=1: > /usr/share/roundcubemail/bin/updatedb.sh \ > --dir /usr/share/doc/roundcubemail-%{version}/SQL/ \ > --package core || : \ > >/dev/null 2>&1 and: Line 188-206 at https://obs.kolabsys.com/package/view_file/Kolab:Development/roundcubemail-plugins-kolab/roundcubemail-plugins-kolab.spec?expand=1 > for plugin in calendar kolab_activesync kolab_addressbook \ > kolab_auth kolab_config kolab_delegation kolab_files \ > kolab_folders kolab_notes libkolab libcalendaring odfviewer \ > owncloud piwik_analytics tasklist; do > > for dir in `find /usr/share/roundcubemail/plugins/${plugin}/ > -type d -name "SQL"`; do > # Skip plugins with multiple drivers and no kolab driver > if [ ! -z "$(echo $dir | grep driver)" ]; then > if [ -z "$(echo $dir | grep kolab)" ]; then > continue > fi > fi > > /usr/share/roundcubemail/bin/updatedb.sh \ > --dir $dir \ > --package ${plugin} \ > >/dev/null 2>&1 || : > done > done > Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 From tobias at tobru.ch Wed Aug 6 21:47:44 2014 From: tobias at tobru.ch (Tobias Brunner) Date: Wed, 06 Aug 2014 21:47:44 +0200 Subject: [Kolab-devel] Vagrantfile for Debian Message-ID: <4d097a88d44bc896219d1af6652015d0@tobrunet.ch> Hi all, I'm working on a Vagrantfile to easily start a Debian machine and install the development version of Kolab on it. The initial working version can be found here: https://github.com/tobru/kolab3-vagrant If anyone wants to work on it (f.e. move from shell provisioning to Puppet), don't hesitate to send a pull request. Cheers, Tobias From dh at dotlan.net Thu Aug 7 02:15:16 2014 From: dh at dotlan.net (Daniel Hoffend) Date: Thu, 07 Aug 2014 00:15:16 +0000 Subject: [Kolab-devel] Kolab 3.3 feedback In-Reply-To: Message-ID: Hi Jeroen here's some feedback, but bear with me, I tested it on a clean Debian7 VM. So I don't know wether there's a bug or there's a packaging error. I would have started to see if it's a real debian packing problem or a real bug, but the OBS Systems seems to be down. It won't let me branch a package to fix a simple thing like the missing itip module in pykolab (already reported). At some point I stopped reporting bugs cause I couldn't find the right product in the new organized bugzilla ... Maybe I should start testing on Centos first, but my life system runs debian, so I'm interested in getting the debian version running so I can do a test migration. Here's the list: # setup-kolab 2014-08-07 00:54:09,422 pykolab.conf ERROR Could not change permissions on /var/log/kolab/pykolab.log: OSError(2, 'No such file or directory') Old bug but still present: https://issues.kolab.org/show_bug.cgi?id=2798 Likely not critical but people will still see it. # wallace itip module missing Known bug: https://issues.kolab.org/show_bug.cgi?id=3250 Simple packaging fix, but OBS seems to not work right now oh btw, I would like to test wallace and resource booking within the calendar, but the documentation doesn't provide an example on how wallace has to be integrated. Or which process decided that the invitation email of a resource has to be forwared to the wallace daemon on 10026 Is it just configurig the content-filter in the section 127.0.0.1:10025 of the master file to content_filter = smtp-wallace:[127.0.0.1]:10026? # Mixed character sets for new created database tables Verious tables (kolab_alarms and all syncrotron) have "no" exlicit characterset configured in their initial file (which takes system default which could be different then all the other tables). It's not a big issue but this "could in theory" be a problem someday. There's even one table in roundcube itself that has no specific charset configured instead of utf8. Reported: https://issues.kolab.org/show_bug.cgi?id=3262 # kolab-webadmin ## shared folders IMAP Access Rights > New Uncaught TypeError: Cannot read property 'match' of undefined example.com/kolab-webadmin/js/kolab_admin.js:1897 Line: 1897: subject_select.val(acl.subject.match(/^(anyone|anonymous)$/i) ? acl.subject : 'user').change(); Can't report the problem, cause I can't open a Bug for the product Web Administration Panel / user interface # roundcube ## config the default kolab_addressbook.inc.php is a duplicate of config.inc.php. The config is correct in the roundcubemail-plugins-kolab debian package. likely in postinst something ist wrong. ## no folders * no folders are visible in the folders section in all modules like mail, contacts, calendar, etc * folders are visible under folder management * this causes all kinds of strange results ## right click mail message Uncaught TypeError: Cannot read property 'ml' of undefined contextmenu.js?s=1391242078:274 273: var msg = rcmail.env.messages[matches[1]]; 274: if(!msg.ml) ## Notebooks Create a notebook, it doesn't appear (caue no folders are shown). It's not visible under folder management but "kolab lm" will show it. ## Tags not enabled per default in config.inc.php? That's inteded cause it's too new? Can't test it right now cause something is wrong with the contextmenu ===== well ... that's all for today. maybe we can get things looked at in the next days, I know this is a pretty short test cycle for a beta before the release gets its "stable" marker. P.S. if you really want to get things tested before you declare a version as "stable" I would recommend to give the community more time to test ... especially in the summer where lots of people are likely on vacation. -- Kind regards, Daniel Hoffend ------ Originalnachricht ------ Von: "Jeroen van Meeuwen (Kolab Systems)" An: "Kolab Development Coordination Mailing List" Gesendet: 04.08.2014 01:40:18 Betreff: [Kolab-devel] Kolab 3.3 release forthcoming >Hi there, > >As mentioned in the other email, we have a pending release of Kolab 3.3 >this month, at or around the 14th (which is six months after the Kolab >3.2 release on Valentine's day, henceforth to be referred to as Kolab >Release day). > >From experience (and from looking at my agenda) I know it's *NOT* going >to be the 14th, rather after the following weekend (the 19th or 20th). > >Also from experience, I'm asking you to get your bug reports in *NOW*; > > - use Kolab:Development to install what is to become Kolab 3.3, if at >all possible (otherwise, log bug), > > - test functionality -- most things have had one or another change, > > - those with the ability to test upgrades, please do -- especially >with regards to existing mail spools. > >I'm looking forward to your reports of failure, I'll take every single >one of them as a compliment ;-) > >That said, if you report one and I go "oh, nice catch!", you've earned >yourself a beer. > >Kind regards, > >Jeroen van Meeuwen > >-- Systems Architect, Kolab Systems AG > >e: vanmeeuwen at kolabsys.com >m: +44 74 2516 3817 >w: http://www.kolabsys.com > >pgp: 9342 BF08 >_______________________________________________ >devel mailing list >devel at lists.kolab.org >https://lists.kolab.org/mailman/listinfo/devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2423 bytes Desc: not available URL: From mike.brady at devnull.net.nz Thu Aug 7 06:04:04 2014 From: mike.brady at devnull.net.nz (Brady, Mike) Date: Thu, 07 Aug 2014 16:04:04 +1200 Subject: [Kolab-devel] Kolab 3.3 release forthcoming In-Reply-To: References: Message-ID: On 2014-08-04 11:40, Jeroen van Meeuwen (Kolab Systems) wrote: > Hi there, > > As mentioned in the other email, we have a pending release of Kolab > 3.3 this month, at or around the 14th (which is six months after the > Kolab 3.2 release on Valentine's day, henceforth to be referred to as > Kolab Release day). > > From experience (and from looking at my agenda) I know it's *NOT* > going to be the 14th, rather after the following weekend (the 19th or > 20th). > > Also from experience, I'm asking you to get your bug reports in *NOW*; > > - use Kolab:Development to install what is to become Kolab 3.3, if > at all possible (otherwise, log bug), > > - test functionality -- most things have had one or another change, > > - those with the ability to test upgrades, please do -- especially > with regards to existing mail spools. > > I'm looking forward to your reports of failure, I'll take every single > one of them as a compliment ;-) > > That said, if you report one and I go "oh, nice catch!", you've earned > yourself a beer. > > Kind regards, > > Jeroen van Meeuwen Should I be able to upgrade from 3.1 to 3.3? From machniak at kolabsys.com Thu Aug 7 08:56:06 2014 From: machniak at kolabsys.com (Aleksander Machniak) Date: Thu, 07 Aug 2014 08:56:06 +0200 Subject: [Kolab-devel] Kolab 3.3 feedback In-Reply-To: References: Message-ID: <53E32306.10505@kolabsys.com> On 08/07/2014 02:15 AM, Daniel Hoffend wrote: > # kolab-webadmin > > ## shared folders > > IMAP Access Rights > New > Uncaught TypeError: Cannot read property 'match' of undefined > example.com/kolab-webadmin/js/kolab_admin.js:1897 > > Line: 1897: > subject_select.val(acl.subject.match(/^(anyone|anonymous)$/i) ? > acl.subject : 'user').change(); https://issues.kolab.org/show_bug.cgi?id=3267 > ## no folders > > * no folders are visible in the folders section in all modules like > mail, contacts, calendar, etc > * folders are visible under folder management > * this causes all kinds of strange results Probably this one https://issues.kolab.org/show_bug.cgi?id=3253 > ## right click mail message > > Uncaught TypeError: Cannot read property 'ml' of undefined > contextmenu.js?s=1391242078:274 > > 273: var msg = rcmail.env.messages[matches[1]]; > 274: if(!msg.ml) https://issues.kolab.org/show_bug.cgi?id=3266 -- Aleksander Machniak Web Developer, Kolab Systems AG ------------------------------------------------------- PGP:19359DC1 - http://www.kolabsys.com - http://alec.pl From sruli at saurymper.com Wed Aug 6 22:53:48 2014 From: sruli at saurymper.com (Sruli Saurymper) Date: Wed, 06 Aug 2014 21:53:48 +0100 Subject: [Kolab-devel] setup-kolab missing in 3.3 Message-ID: <53E295DC.6010301@saurymper.com> Hi, After installing kolab 3.3 on centos 6.5 and running setup-kolab i get a command not found error. Sruli From stuartiannaylor at thursbygarden.org Thu Aug 7 08:49:00 2014 From: stuartiannaylor at thursbygarden.org (=?utf-8?Q?Stuart_Naylor?=) Date: Thu, 7 Aug 2014 07:49:00 +0100 Subject: [Kolab-devel] Vagrantfile for Debian Message-ID: Tobias, Great that you have setup up a vagrantfile. Never used Vagrant before and of all horrors my desktop is still windows. Honest its due to the RAID card :) I posted on the list after a few unsuccessful attempts to install kolab for a VM But vagrant should be even better as it has the install script. Many thanks as I have never used vagrant before and its a good idea. I never managed to get the debian version running because of an error with the roundcube database. So here goes :) Stuart -----Original message----- > From:Tobias Brunner > Sent: Wednesday 6th August 2014 20:47 > To: users at lists.kolab.org; devel at lists.kolab.org > Subject: Vagrantfile for Debian > > Hi all, > > I'm working on a Vagrantfile to easily start a Debian machine and > install the development version of Kolab on it. The initial working > version can be found here: https://github.com/tobru/kolab3-vagrant > If anyone wants to work on it (f.e. move from shell provisioning to > Puppet), don't hesitate to send a pull request. > > Cheers, > Tobias > > _______________________________________________ > users mailing list > users at lists.kolab.org > https://lists.kolab.org/mailman/listinfo/users > From torsten at kolab.org Thu Aug 7 10:57:22 2014 From: torsten at kolab.org (Torsten Grote) Date: Thu, 07 Aug 2014 10:57:22 +0200 Subject: [Kolab-devel] Kolab 3.3 release forthcoming In-Reply-To: References: Message-ID: <3992984.xBSN6iXZMx@t7laptop1> On Thursday 07 August 2014 16:04:04 Brady, Mike wrote: > Should I be able to upgrade from 3.1 to 3.3? Would be nice. Please test if it works for you. Kind Regards, Torsten -- Torsten Grote Kolab.org Community Manager e: torsten at kolab.org w: https://Kolab.org pgp: 0x2175A534A4F2EFA3 From torsten at kolab.org Thu Aug 7 10:59:21 2014 From: torsten at kolab.org (Torsten Grote) Date: Thu, 07 Aug 2014 10:59:21 +0200 Subject: [Kolab-devel] Kolab 3.3 feedback In-Reply-To: References: Message-ID: <2515047.F4GY2FKzg9@t7laptop1> Hi Daniel, thanks a lot for your thorough testing! Doing this on Debian is totally fine. On Thursday 07 August 2014 00:15:16 Daniel Hoffend wrote: > the OBS Systems seems to be down. It won't let me branch a package to fix a > simple thing like the missing itip module in pykolab (already reported). Yes I noticed the same thing. This is very unfortunate, since most of the issues you have found would be quite easy to fix, if we could branch packages. Kind Regards, Torsten -- Torsten Grote Kolab.org Community Manager e: torsten at kolab.org w: https://Kolab.org pgp: 0x2175A534A4F2EFA3 From thom_zieg at live.de Thu Aug 7 13:03:35 2014 From: thom_zieg at live.de (Thomas Z.) Date: Thu, 7 Aug 2014 13:03:35 +0200 Subject: [Kolab-devel] Upgrade Kolab 3.2 to 3.3 on Centos 6.5 Message-ID: Dear List, brave as I am I did a yum update on my system. Update itself went without a problem; at least everything is running and working, only Roundcube makes some problems: 1. Roundcube (now?) tries to verify the URL and adds some kind of key, but this only leads to a "Page not found" error in apache. I assume something changed for httpd/conf.d/roundcube.conf but I was not yet able to determine it. I disabled the check in the php source and went on without the key 2. Roundcube only sees the Inbox but no other folder. It is the same picture as https://issues.kolab.org/show_bug.cgi?id=3253 [1]. Did a script not run which updates the metadata or shoud I downgrade cyrus? 3. The right-click menu does not show in Roundcube 4. From the image in the Planet-Kolab post I miss the tag cloud in the lower left corner for mails. From my impression, Roundcube got only partially updated. I did not further investigate this. That's it for now. Thomas Links: ------ [1] https://issues.kolab.org/show_bug.cgi?id=3253 -------------- next part -------------- An HTML attachment was scrubbed... URL: From torsten at kolab.org Thu Aug 7 13:31:53 2014 From: torsten at kolab.org (Torsten Grote) Date: Thu, 07 Aug 2014 13:31:53 +0200 Subject: [Kolab-devel] Upgrade Kolab 3.2 to 3.3 on Centos 6.5 In-Reply-To: References: Message-ID: <1948541.fKq88XNRbI@t7laptop1> Hi Thomas, On Thursday 07 August 2014 13:03:35 Thomas Z. wrote: > brave as I am I did a yum update on my system. That's brave indeed. Make sure to change your repository config to 3.3 once the final has been released. > 2. Roundcube only sees the Inbox but no other folder. It is the same > picture as https://issues.kolab.org/show_bug.cgi?id=3253 [1]. Did a > script not run which updates the metadata or shoud I downgrade cyrus? You could try both workarounds described in the ticket and report back there which one worked. For me a downgrade fixed it. > 3. The right-click menu does not show in Roundcube That is this ticket: https://issues.kolab.org/show_bug.cgi?id=3266 > 4. From the image in the Planet-Kolab post I miss the tag cloud in the > lower left corner for mails. From my impression, Roundcube got only > partially updated. I did not further investigate this. You need to add the 'kolab_tags' plugin to your roundcube config. Kind Regards, Torsten -- Torsten Grote Kolab.org Community Manager e: torsten at kolab.org w: https://Kolab.org pgp: 0x2175A534A4F2EFA3 From aj at ajaissle.de Fri Aug 8 11:18:03 2014 From: aj at ajaissle.de (Aeneas =?ISO-8859-1?Q?Jai=DFle?=) Date: Fri, 08 Aug 2014 11:18:03 +0200 Subject: [Kolab-devel] Bugzilla Restructuring In-Reply-To: <1cc0176798e9ed1a430d84d536d62a56@kolabsys.com> References: <1cc0176798e9ed1a430d84d536d62a56@kolabsys.com> Message-ID: <5085160.W0MptAqcVK@aen1.ajaissle.de> Am Montag, 4. August 2014, 01:31:24 schrieb Jeroen van Meeuwen: > Hi there, > > I know you're all in great anticipation of the forthcoming release of > Kolab 3.3, which is to be released at or around August 14th, but we have > instead restructured Bugzilla (such a dissapointment, nay?). > > We believe the new structure better allows us to track "what has > happened" with a particular piece of software, such as Roundcube or > PyKolab, and therefore be better at doing releases (because we have > appropriate milestones now), changelogs, update instructions, and so > forth. > > One major aspect is that we have also introduced a set of new ticket > statuses. You will find a description of their intended meaning here: > > http://docs.kolab.org/developer-guide/bugzilla.html > > This will be the canonical location for further updates to the Bugzilla > workflow. > > Kind regards, > > Jeroen van Meeuwen > > Hi Jeroen, with the re-ordering I see a lot of products have been added[1], but only a few can be picked when opening a new bug report: * Contextmenu Plugin * Kolab Desktop Client * Kolab Groupware Plugins * Kolab Server * Kolab Websites * Mozilla Thunderbird * pear?Net_LDAP3 * Syncroton * UCS [1] https://issues.kolab.org/describecomponents.cgi -- ____ /@ ~-. Aeneas Jai?le \/ __ .- | ? aj at ajaissle.de // // @ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From diane at ghic.org Sun Aug 10 08:53:45 2014 From: diane at ghic.org (Diane Trout) Date: Sat, 09 Aug 2014 23:53:45 -0700 Subject: [Kolab-devel] test failure in libkolab Message-ID: <7912172.Dj0HhZSQLN@myrada> Hello, I was looking into why birthdays aren't being serialized (Kolab Bug #2739) when I discovered make test was failing in format test. I tried with both 0.5.2 from Debian and a fresh checkout of libkolab from git. I think the relevant message is: QDEBUG : FormatTest::testDistlist(v3distlistSimple) /tmp/libkolab/tests/formattest.cpp : 51 Actual: msg->headerByType( X_KOLAB_TYPE_HEADER )->as7BitString(): "X-Kolab-Type: application/x- vnd.kolab.distribution-list" Expceted: expectedMsg->headerByType( X_KOLAB_TYPE_HEADER )->as7BitString(): "X-Kolab-Type: application/x-vnd.kolab.contact.distlist" I can solve it by changing the X-Kolab-Type value. --- a/tests/testfiles/v3/contacts/distlist.vcf.mime +++ b/tests/testfiles/v3/contacts/distlist.vcf.mime @@ -1,5 +1,5 @@ Date: Mon, 23 Apr 2012 12:46:37 +0200 -X-Kolab-Type: application/x-vnd.kolab.contact.distlist +X-Kolab-Type: application/x-vnd.kolab.distribution-list X-Kolab-Mime-Version: 3.0 User-Agent: Libkolab-0.1.0 Content-Type: multipart/mixed; boundary="nextPart1365947.WmFcbPlLFA" However I'm not sure which version is the one intended, .../x- vnd.kolab.contact.distlist or x-vnd.kolab.distribution-list. Diane From machniak at kolabsys.com Sun Aug 10 09:12:00 2014 From: machniak at kolabsys.com (Aleksander Machniak) Date: Sun, 10 Aug 2014 09:12:00 +0200 Subject: [Kolab-devel] test failure in libkolab In-Reply-To: <7912172.Dj0HhZSQLN@myrada> References: <7912172.Dj0HhZSQLN@myrada> Message-ID: <53E71B40.9040607@kolabsys.com> On 08/10/2014 08:53 AM, Diane Trout wrote: > --- a/tests/testfiles/v3/contacts/distlist.vcf.mime > +++ b/tests/testfiles/v3/contacts/distlist.vcf.mime > @@ -1,5 +1,5 @@ > Date: Mon, 23 Apr 2012 12:46:37 +0200 > -X-Kolab-Type: application/x-vnd.kolab.contact.distlist > +X-Kolab-Type: application/x-vnd.kolab.distribution-list > X-Kolab-Mime-Version: 3.0 > User-Agent: Libkolab-0.1.0 > Content-Type: multipart/mixed; boundary="nextPart1365947.WmFcbPlLFA" Looks good. Could you open a ticket on issues.kolab.org? http://git.kolab.org/libkolab/commit/?id=c12b60228acb4c7ed67dbdbcf68031704c16b9ab -- Aleksander Machniak Software Developer Kolab Systems AG: http://kolabsys.com PGP: 19359DC1 From tobias at tobru.ch Sun Aug 10 16:59:29 2014 From: tobias at tobru.ch (Tobias Brunner) Date: Sun, 10 Aug 2014 16:59:29 +0200 Subject: [Kolab-devel] Vagrantfile for Debian In-Reply-To: References: Message-ID: Hi, > I never managed to get the debian version running because of an error > with the roundcube database. > So here goes :) This Vagrantfile won't help you with this. It uses the official Debian packages and they seem to have some problems ATM. But the Vagrantfile helps to have a quick setup to help fixing this problems and test future versions. Cheers, Tobias From tobias at tobru.ch Sun Aug 10 17:01:20 2014 From: tobias at tobru.ch (Tobias Brunner) Date: Sun, 10 Aug 2014 17:01:20 +0200 Subject: [Kolab-devel] Vagrantfile for Debian In-Reply-To: <4d097a88d44bc896219d1af6652015d0@tobrunet.ch> References: <4d097a88d44bc896219d1af6652015d0@tobrunet.ch> Message-ID: <3095b3d69525ea4d6d8b5c91c13deef8@tobrunet.ch> Hi all, The Vagrantfile now uses Puppet to provision Kolab. Here is a blog post describing the Vagrantfile a bit more: https://tobrunet.ch/articles/kolab-3-vagrant-box-with-puppet-provisioning/ Cheers, Tobias On 06.08.2014 21:47, Tobias Brunner wrote: > Hi all, > > I'm working on a Vagrantfile to easily start a Debian machine and > install the development version of Kolab on it. The initial working > version can be found here: https://github.com/tobru/kolab3-vagrant > If anyone wants to work on it (f.e. move from shell provisioning to > Puppet), don't hesitate to send a pull request. > > Cheers, > Tobias > > _______________________________________________ > users mailing list > users at lists.kolab.org > https://lists.kolab.org/mailman/listinfo/users From StuartIanNaylor at inbox.com Sun Aug 10 22:56:11 2014 From: StuartIanNaylor at inbox.com (Stuart Naylor) Date: Sun, 10 Aug 2014 21:56:11 +0100 Subject: [Kolab-devel] LDAP port configuration. Message-ID: <1542262.2uRcp0gHsq@home-pc> Just thought I would mention as I had a look and the port config seems to be hard coded in many places. You might have scenario's where you want to co-exist with other LDAP's on the same IP. It would be great to be able to assign non standard ports for the DS. If kolab-setup would allow this then it would make single server interoperability with other LDAP's much easier. Stuart ____________________________________________________________ FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop! Check it out at http://www.inbox.com/marineaquarium -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at boddie.org.uk Sun Aug 10 23:16:34 2014 From: paul at boddie.org.uk (Paul Boddie) Date: Sun, 10 Aug 2014 23:16:34 +0200 Subject: [Kolab-devel] LDAP port configuration. In-Reply-To: <1542262.2uRcp0gHsq@home-pc> References: <1542262.2uRcp0gHsq@home-pc> Message-ID: <201408102316.34687.paul@boddie.org.uk> On Sunday 10. August 2014 22.56.11 Stuart Naylor wrote: > Just thought I would mention as I had a look and the port config > seems to be hard coded in many places. Where were you looking? > You might have scenario's where you want to co-exist with other > LDAP's on the same IP. It would be great to be able to assign non > standard ports for the DS. As far as I remember, the LDAP server port is configurable. In the work I've done on setup-kolab (known as kolab-setup on some distributions), you can even nominate a remote LDAP server, but you obviously then don't get to initialise this server using setup-kolab (since the process involves running programs on the actual LDAP server host). > If kolab-setup would allow this then it would make single server > interoperability with other LDAP's much easier. I think you mean coexistence rather than interoperability, but I get your point. Paul From diane at ghic.org Mon Aug 11 05:55:02 2014 From: diane at ghic.org (Diane Trout) Date: Sun, 10 Aug 2014 20:55:02 -0700 Subject: [Kolab-devel] test failure in libkolab In-Reply-To: <53E71B40.9040607@kolabsys.com> References: <7912172.Dj0HhZSQLN@myrada> <53E71B40.9040607@kolabsys.com> Message-ID: <2394038.qtbYqQ3gPn@myrada> Sure. https://issues.kolab.org/show_bug.cgi?id=3280 I wasn't quite sure what category to file it in. Diane On Sunday, August 10, 2014 09:12:00 Aleksander Machniak wrote: > On 08/10/2014 08:53 AM, Diane Trout wrote: > > --- a/tests/testfiles/v3/contacts/distlist.vcf.mime > > +++ b/tests/testfiles/v3/contacts/distlist.vcf.mime > > @@ -1,5 +1,5 @@ > > > > Date: Mon, 23 Apr 2012 12:46:37 +0200 > > > > -X-Kolab-Type: application/x-vnd.kolab.contact.distlist > > +X-Kolab-Type: application/x-vnd.kolab.distribution-list > > > > X-Kolab-Mime-Version: 3.0 > > User-Agent: Libkolab-0.1.0 > > Content-Type: multipart/mixed; boundary="nextPart1365947.WmFcbPlLFA" > > Looks good. Could you open a ticket on issues.kolab.org? > > http://git.kolab.org/libkolab/commit/?id=c12b60228acb4c7ed67dbdbcf68031704c1 > 6b9ab From thom_zieg at live.de Tue Aug 12 20:39:42 2014 From: thom_zieg at live.de (Thomas Z.) Date: Tue, 12 Aug 2014 20:39:42 +0200 Subject: [Kolab-devel] Possible typo in roundcube rcmail.php Message-ID: /usr/share/roundcubemail/program/include/rcmail.php about line 240 if (!$contacts) { // there's no default, just return if ($default) { return null; } should be (assuming the comment is correct and the error message I get logged is false) if (!$contacts) { // there's no default, just return if (!$default) { <------ return null; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From liste at gelpi.it Wed Aug 13 10:46:10 2014 From: liste at gelpi.it (Gelpi Andrea) Date: Wed, 13 Aug 2014 10:46:10 +0200 Subject: [Kolab-devel] fix kolabd crashing on startup In-Reply-To: <20131113191237.176a5c1c@tbb-phenom> References: <20131113191237.176a5c1c@tbb-phenom> Message-ID: <53EB25D2.9000201@gelpi.it> Il 13/11/2013 19:12, Michael ha scritto: > Hi, > > I'm using Kolab 3.1 from: > deb-src http://obs.kolabsys.com:82/Kolab:/3.1/Debian_7.0/ ./ > deb-src http://obs.kolabsys.com:82/Kolab:/3.1:/Updates/Debian_7.0/ ./ > Build date: 11-Nov-2013 > > kolabd/kolab-server is crashing if there's no dirsrv/389 online. > For me that's the case nearly at every system-boot because kolabd apparently > starts faster than 389 can initialise. > After reading this old post I checked my kolab 3.2 installed from same repos on debian 7.5. I had the same problem, but I found a simpler solution. In /etc/init.d/kolab-server I add dirsrv to Required-Start: line ### BEGIN INIT INFO # Provides: kolab-server # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Required-Start: $remote_fs $local_fs $network dirsrv . . . ### END INIT INFO After that I removed and re-added kolab-server to startup sequence with: update-rc.d -f kolab-server remove update-rc.d kolab-server defaults The last 2 commands change the order in /etc/rc?.d/ Now kolab-server start after dirsrv and don't crash anymore. -- ing. Andrea Gelpi *************************************************** La Terra non la abbiamo ereditata dai nostri avi, ma la abbiamo presa in prestito dai nostri bambini. *************************************************** We do not inherit the Earth from our parents, but borrow it from our children. *************************************************** From pasik at iki.fi Wed Aug 13 13:02:32 2014 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Wed, 13 Aug 2014 14:02:32 +0300 Subject: [Kolab-devel] Multi domain administrators in Kolab 3.2 In-Reply-To: <03c5e525c5998a3913a7dff08da8a734@kolab.org> References: <53BECF22.6050603@gelpi.it> <03c5e525c5998a3913a7dff08da8a734@kolab.org> Message-ID: <20140813110232.GI12451@reaktio.net> On Mon, Jul 14, 2014 at 10:12:48AM +0200, Timotheus Pokorra wrote: > Hello Andrea, > > at TBits.net, we have created a patch that allows domain administrators. > Our customers can manage their (multiple) domains. > This patch is not part of upstream, and it has some modifications in > LDAP and PHP. > > You are welcome to have a look and investigate for yourself, if it > is useful to you. > > I am just in the process of updating the scripts and patches to > Kolab 3.2, and improving the unit tests. > > Please see the documentation at > https://github.com/TBits/KolabScripts/wiki and the code at > https://github.com/TBits/KolabScripts/tree/Kolab3.2 > Great to see these patches for Kolab 3.2 ! Thanks a lot. Do you have any plans to upstream these patches? -- Pasi > All the best, > Timotheus > > > On 2014-07-10 19:36, Gelpi Andrea wrote: > >Hi, > > it wood be great if it is possible to have an administrator for only > >some domains as it was in kolab server 2.x. > > > >To better explain. > > > >I have 3 separate domain (not alias domain) for example domain-a, > >domain-b and domain-c. > > > >Is it possible to create an administrator for domain-b and domain-c but > >not domain-a? > >Where can I find documentation? > > > >Thanks. > _______________________________________________ > devel mailing list > devel at lists.kolab.org > https://lists.kolab.org/mailman/listinfo/devel From vanmeeuwen at kolabsys.com Wed Aug 13 13:05:06 2014 From: vanmeeuwen at kolabsys.com (Jeroen van Meeuwen (Kolab Systems)) Date: Wed, 13 Aug 2014 13:05:06 +0200 Subject: [Kolab-devel] Bugzilla Restructuring In-Reply-To: <5085160.W0MptAqcVK@aen1.ajaissle.de> References: <1cc0176798e9ed1a430d84d536d62a56@kolabsys.com> <5085160.W0MptAqcVK@aen1.ajaissle.de> Message-ID: <5df8c8900901fca86747dc6f5e95604b@kolabsys.com> On 2014-08-08 11:18, Aeneas Jai?le wrote: > Hi Jeroen, > > with the re-ordering I see a lot of products have been added[1], but > only a few can be picked when opening a new bug report: > Hi, I should have fixed this now. Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 From dh at dotlan.net Wed Aug 13 14:31:04 2014 From: dh at dotlan.net (Daniel Hoffend) Date: Wed, 13 Aug 2014 12:31:04 +0000 Subject: [Kolab-devel] Kolab 3.3 feedback In-Reply-To: Message-ID: Hello this is a follow up on my initial test run of Kolab 3.3. Last evening/night I started to reinstall my testsystem again and tried to configure and test a few things that were announced as the big new features of Kolab 3.3. Well ... apart from stuff that is not enabled by default or parameter that haven't been configured I came a cross lots of default configuration, packaging or other bugs. Since up until now I couldn't report most of them as bugs in bugzilla or even fix them in OBS so here's my long list of notes. Maybe I just don't know how to configure things the right way but some stuff is a bit chaotic. Some the bugs have already been opened as ticket but I'll list them (again) just to have a full list of stuff that I came across. Oh and I still have the opinion that features the system provides should be enabled by default (wallace for resource management, kolab_tags, etc). People still can disable them if they don't need them but they start to wonder if there's a function (like resource booking) that is enabled by default in roundcube but won't work until actually include wallace in the mail flow. If I find the time I'll open bug if that's speeds up the error finding :-) -- Best Regards Daniel ============================================================================================= roundcubemail ------------- ## debian package bug missing public_html folder FIXED: Already fixed at the time when I finished my notes roundcubemail-plugin-contextmenu -------------------------------- ## incompatible The contextenu 1.x won't work with roundcube 1.1 but 2.x has problems that needs to be resolved in the upstream package first before packaging Ticket: https://issues.kolab.org/show_bug.cgi?id=3266 pykolab ------- ## error message during first setup-kolab (on debian) 2014-08-13 10:46:46,371 pykolab.conf ERROR Could not change permissions on /var/log/kolab/pykolab.log: OSError(2, 'No such file or directory') old bug but still present: https://issues.kolab.org/show_bug.cgi?id=2798 ## ldap/folderacl_entry_attribute The new config parameter used for ACL management of shared folders is missing the example kolab.conf, the setup-kolab generated kolab.conf and has no default value in case it's not configured 2014-08-13 11:55:25,835 pykolab.conf WARNING Option ldap/folderacl_entry_attribute does not exist in config file /etc/kolab/kolab.conf, pulling from defaults 2014-08-13 11:55:25,836 pykolab.conf WARNING Option does not exist in defaults.# Workaround: kolab.conf: ldap/folderacl_entry_attribute = acl + kolab-server restart ## error when creating a new shared folder 2014-08-13 11:57:22,253 pykolab.auth ERROR An error occured using _paged_search: CYRUSError(99, 'SETACL', 'Mailbox does not exist') $ kolab sync -d 9 2>&1 | grep ^.SET [SETANNOTATION shared/GroupCal at dotlan.info] OK: None [SETACL GroupCal at dotlan.info daniel.hoffend at dotlan.info lrswipkxtecdn] BAD: Mailbox does not exist sounds like a missing "shared/" prefix in the folder name when trying to set acl. ## invalid default imap uri default cyrus-imap/uri in kolab.conf points to imaps://localhost:993 even imaps is not configured in the vanilla installation resulting in kolab-freebusy not working until this has changed or ssl is configured cyrus-imapd ----------- ## Problem with metadata/folders Ticket: https://issues.kolab.org/show_bug.cgi?id=3253 Workaround: echo "suppress_capabilities: METADATA" >> /etc/imapd.conf + restart But this should be fixed in the upsteam package first I guess. postfix ------- ## wallace not activated by default wallace deamons are running but are not configured to be used in the vanilla default installation workaround: /etc/postfix/master.conf 127.0.0.1:10025 [...] -o content_filter=smtp-wallace:[127.0.0.1]:10026 resources/wallace ----------------- ## Summary * booking of single resources == FAIL (NDR) * booking of resource collection == SUCCESS * booking of resource collection at the same time == ERROR ## booking single resource 1) enable wallace via postfix master.conf 2) create resource beamer1 3) create appointment + book resource beamer1 + save I receive a non-delivery-notification even the mail is getting processed by wallace and the mailbox in general should exist # kolab lm | grep beamer1 shared/Resources/beamer1 at dotlan.info Aug 13 13:08:32 kolab33 postfix/smtp[26293]: 0212E23157: to=, relay=127.0.0.1[127.0.0.1]:10026, delay=0.05, delays=0.04/0.01/0/0, dsn=2.0.0, status=sent (250 Ok) Aug 13 13:08:32 kolab33 postfix/qmgr[26270]: 0212E23157: removed Aug 13 13:08:32 kolab33 postfix/smtpd[26294]: connect from localhost[127.0.0.1] Aug 13 13:08:32 kolab33 postfix/smtpd[26294]: 2D16223157: client=localhost[127.0.0.1] Aug 13 13:08:32 kolab33 postfix/cleanup[26292]: 2D16223157: message-id= Aug 13 13:08:32 kolab33 postfix/qmgr[26270]: 2D16223157: from=, size=2225, nrcpt=1 (queue active) Aug 13 13:08:32 kolab33 postfix/smtpd[26294]: disconnect from localhost[127.0.0.1] Aug 13 13:08:32 kolab33 postfix/lmtp[26295]: 2D16223157: to=, relay=kolab33.dotlan.info[/var/lib/imap/socket/lmtp], delay=0.06, delays=0.03/0.01/0/0.01, dsn=5.1.1, status=bounced (host kolab33.dotlan.info[/var/lib/imap/socket/lmtp] said: 550-Mailbox unknown. Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown (in reply to RCPT TO command)) Aug 13 13:08:32 kolab33 postfix/cleanup[26299]: 39BD223176: message-id=<20140813110832.39BD223176 at kolab33.dotlan.info> Aug 13 13:08:32 kolab33 postfix/bounce[26297]: 2D16223157: sender non-delivery notification: 39BD223176 ## booking resource collection 1) create resource collection beamers + add beamer1 2) create appointment + book resource collection beamers + save SUCCESS * from: beamers - Reservation Request for test1 was Delegated * from: beamer1 - Reservation Request for test1 was Accepted 3) create appointment different date/time + book resource collection beamers + save Note: You don't see the freebusys calendar of the resources. it's completely empty SUCCESS 4) create appointment same date/time + book resource collection beamers + save ERROR: 2014-08-13 13:28:04,387 pykolab.wallace ERROR Module resources.execute() failed on message '/var/spool/pykolab/wallace/tmp5yiKgw' with error: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/wallace/__init__.py", line 67, in pickup_message result_filepath = modules.execute(module, filepath) File "/usr/lib/python2.7/dist-packages/wallace/modules.py", line 116, in execute return modules[name]['function'](*args, **kw) File "/usr/lib/python2.7/dist-packages/wallace/module_resources.py", line 336, in execute (available_resource, itip_event) = check_availability(itip_events, resource_dns, resources, receiving_attendee) File "/usr/lib/python2.7/dist-packages/wallace/module_resources.py", line 482, in check_availability if done: UnboundLocalError: local variable 'done' referenced before assignment the incoming file is laying in the spool file and is blocking all other incoming wallace resource requests until I empty the spool folder 5) rm /var/spool/pykolab/wallace/resources/incoming/* + restart wallace ## other tracebacks here's another traceback that I've seen when I tried to clean up the messes 2014-08-13 13:29:34,984 pykolab.wallace ERROR Module resources.execute() failed on message '/var/spool/pykolab/wallace/resources/incoming/tmpRtIZs8' with error: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/wallace/__init__.py", line 67, in pickup_message result_filepath = modules.execute(module, filepath) File "/usr/lib/python2.7/dist-packages/wallace/modules.py", line 116, in execute return modules[name]['function'](*args, **kw) File "/usr/lib/python2.7/dist-packages/wallace/module_resources.py", line 325, in execute delete_resource_event(itip_event['uid'], resources[resource]) File "/usr/lib/python2.7/dist-packages/wallace/module_resources.py", line 705, in delete_resource_event targetfolder = imap.folder_quote(resource['kolabtargetfolder']) KeyError: 'kolabtargetfolder' kolab-freebusy -------------- I kinda feel helpless with correct way on how to configure freebusy and make it work ## debian package bug * missing folder /var/{lib,cache}/kolab-freebusy workaround: mkdir -p /var/{cache,lib}/kolab-freebusy ; chown kolab:kolab /var/{cache,lib}/kolab-freebusy ## config.ini.sample * logfolder should be ./logs not ./log * rename kolab-ldap to kolab-users * add kolab-resources * comment out exchange (leave it as example only) * default imap connection points to imaps but ssl is not configured in the default installation ' filter @yourdomain not replaced by the default domain during setup-kolab ## strange search / database error with debug level = 100 ==> /var/log/kolab-freebusy/freebusy.log <== [...] [2014-08-13 13:44:50] web.DEBUG: Trying directory kolab-users .... [...] [2014-08-13 13:44:50] ldap.INFO: Found 1 entries for (&(objectClass=kolabInetOrgPerson)(|(uid=daniel.hoffend at dotlan.info)(mail=daniel.hoffend at dotlan.info)(alias=daniel.hoffend at dotlan.info))) {"mail":["daniel.hoffend at dotlan.info"]} [] ==> /var/log/kolab-freebusy/errors <== [13-Aug-2014 13:44:50 +0200]: DB Error: Configuration error. Unsupported database driver: in /usr/share/kolab-freebusy/lib/Roundcube/rcube_db.php on line 78 (GET /freebusy/daniel.hoffend at dotlan.info) ## lib vs cache confusion? $ kolab-freebusyd --generateall 2>&1 | grep wrote (11:43:50) fbaggregatorjob.cpp(103): wrote "/var/lib/kolab-freebusy/daniel.hoffend at dotlan.info.ifb" root at kolab33:/var/log/kolab-freebusy# egrep -i "^(cache|fb)" /etc/kolab-freebusy/config.ini fbsource = file:/var/lib/kolab-freebusy/%s.ifb fbsource = file:/var/cache/kolab-freebusy/%s.ifb fbsource = imap://cyrus-admin:xxxxx at localhost:143/%kolabtargetfolder?acl=lrs cacheto = /var/cache/kolab-freebusy/%mail.ifb fbsource = imap://%mail:xxxxx at localhost:143/?proxy_auth=cyrus-admin cacheto = /var/cache/kolab-freebusy/%mail.ifb ## cron * is it usefull or should freebusy always be generated on demand * missing cron job to actually generate the freebusy files * not really clear if we should configre nothing (on demand) or via cron or via fbdaemon (sample file) which seems to be on the TODO list /etc/cron.d/kolab-freebusy */15 * * * * root [ $(pgrep kolab-freebusyd >/dev/null 2>&1; echo $?) -ne 0 ] && QT_NO_GLIB=1 kolab-freebusyd --generateall >/var/log/kolab-freebusyd.log 2>&1 ## resources empty FB for resource collecion. this might be okay [2014-08-13 13:52:21] ldap.INFO: No entry found for (&(objectClass=kolabInetOrgPerson)(|(uid=resource-collection-beamers at dotlan.info)(mail=resource-collection-beamers at dotlan.info)(alias=resource-collection-beamers at dotlan.info))) [] [] [2014-08-13 13:52:21] web.INFO: Returning empty Free/Busy list for user resource-collection-beamers at dotlan.info [] [] trying to show the specific freebusy times of a single resource ==> Search OK, but FAILED [2014-08-13 13:53:51] ldap.INFO: Found 1 entries for (&(objectClass=kolabsharedfolder)(mail=resource-beamer-beamer1 at dotlan.info)) {"mail":["resource-beamer-beamer1 at dotlan.info"],"kolabtargetfolder":["shared/Resources/beamer1 at dotlan.info"]} [] [13-Aug-2014 13:53:51 +0200]: DB Error: Configuration error. Unsupported database driver: in /usr/share/kolab-freebusy/lib/Roundcube/rcube_db.php on line 78 (GET /freebusy/resource-beamer-beamer1 at dotlan.info.ifb) kolab-syncroton + others ------------------------ ## Mixed table characterset in mysql.initial.sql files reported already in my previous mail: https://issues.kolab.org/show_bug.cgi?id=3262 kolab-notes ----------- ## missing + button while plugins like addressbook have a [+] button bottom toolbar, the notes plugin does not ## locales A few german locales are missing. I know it's time to register at transoflex or whatever it is called :-) kolab-tags ---------- Even announced as new feature for the roundcube mail clients, it's not enabed by default. From timotheus at kolab.org Wed Aug 13 21:23:08 2014 From: timotheus at kolab.org (Timotheus Pokorra) Date: Wed, 13 Aug 2014 21:23:08 +0200 Subject: [Kolab-devel] Multi domain administrators in Kolab 3.2 In-Reply-To: <20140813110232.GI12451@reaktio.net> References: <53BECF22.6050603@gelpi.it> <03c5e525c5998a3913a7dff08da8a734@kolab.org> <20140813110232.GI12451@reaktio.net> Message-ID: <111a2f5ad2d6aa4e16c0b832b4d11c19@kolab.org> Hello Pasi, > Great to see these patches for Kolab 3.2 ! Thanks a lot. > > Do you have any plans to upstream these patches? I certainly wish they would go upstream, but I also understand that there are different ways of running multi domain and domain admin environments. My main goal at the moment is still to migrate our users from Kolab 2.x to Kolab 3.x, and I think the patch solution is quite good for me at this point. Of course I have fixed a number of bugs already upstream that are unrelated to the TBits multidomain patches but come to surface during my work on the multidomain patches. I hope this helps, Timotheus From pasik at iki.fi Thu Aug 14 09:58:45 2014 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Thu, 14 Aug 2014 10:58:45 +0300 Subject: [Kolab-devel] Multi domain administrators in Kolab 3.2 In-Reply-To: <111a2f5ad2d6aa4e16c0b832b4d11c19@kolab.org> References: <53BECF22.6050603@gelpi.it> <03c5e525c5998a3913a7dff08da8a734@kolab.org> <20140813110232.GI12451@reaktio.net> <111a2f5ad2d6aa4e16c0b832b4d11c19@kolab.org> Message-ID: <20140814075845.GN12451@reaktio.net> On Wed, Aug 13, 2014 at 09:23:08PM +0200, Timotheus Pokorra wrote: > Hello Pasi, > > >Great to see these patches for Kolab 3.2 ! Thanks a lot. > > > >Do you have any plans to upstream these patches? > > I certainly wish they would go upstream, but I also understand that > there are different ways of running multi domain and domain admin > environments. > Yep. Then again *some* form of multi domain and domain admin should be supported by kolab out-of-the-box.. those who need something else could add extra patches or develop optional features. > My main goal at the moment is still to migrate our users from Kolab > 2.x to Kolab 3.x, and I think the patch solution is quite good for > me at this point. > OK. Yeah your patch solution definitely helps a lot! Btw do you know if your patches will work with the kolab 3.3 packages? I didn't try yet, but I will soon. > Of course I have fixed a number of bugs already upstream that are > unrelated to the TBits multidomain patches but come to surface > during my work on the multidomain patches. > Good stuff. Thanks a lot for that aswell! -- Pasi > I hope this helps, > Timotheus > > > _______________________________________________ > devel mailing list > devel at lists.kolab.org > https://lists.kolab.org/mailman/listinfo/devel From bruederli at kolabsys.com Thu Aug 14 10:16:03 2014 From: bruederli at kolabsys.com (=?ISO-8859-1?Q?Thomas_Br=FCderli?=) Date: Thu, 14 Aug 2014 10:16:03 +0200 Subject: [Kolab-devel] Kolab 3.3 feedback In-Reply-To: References: Message-ID: <53EC7043.7050109@kolabsys.com> Daniel Hoffend wrote: > Hello > > this is a follow up on my initial test run of Kolab 3.3. Last > evening/night I started to reinstall my testsystem again and tried to > configure and test a few things that were announced as the big new > features of Kolab 3.3. Well ... apart from stuff that is not enabled by > default or parameter that haven't been configured I came a cross lots of > default configuration, packaging or other bugs. Hi Daniel Thanks a lot for reporting your findings! See some comments further below. > roundcubemail-plugin-contextmenu > -------------------------------- > > ## incompatible > > The contextenu 1.x won't work with roundcube 1.1 but 2.x has problems > that needs to be resolved in the upstream package first before packaging > Ticket: https://issues.kolab.org/show_bug.cgi?id=3266 Known issue, we're working on that. > resources/wallace > ----------------- > > ## Summary > > * booking of single resources == FAIL (NDR) > * booking of resource collection == SUCCESS > * booking of resource collection at the same time == ERROR > > ## booking single resource > > 1) enable wallace via postfix master.conf > 2) create resource beamer1 > 3) create appointment + book resource beamer1 + save > > I receive a non-delivery-notification even the mail is getting processed > by wallace and the mailbox in general should exist The message should be fully consumed by wallace and don't get passed along. Need to investigate this. > ## booking resource collection > > 1) create resource collection beamers + add beamer1 > 2) create appointment + book resource collection beamers + save > > SUCCESS > * from: beamers - Reservation Request for test1 was Delegated > * from: beamer1 - Reservation Request for test1 was Accepted > > 3) create appointment different date/time + book resource collection > beamers + save > > Note: You don't see the freebusys calendar of the resources. it's > completely empty Filed in https://issues.kolab.org/show_bug.cgi?id=3324 > SUCCESS > > 4) create appointment same date/time + book resource collection beamers > + save > > ERROR: > [...] > UnboundLocalError: local variable 'done' referenced before assignment > > the incoming file is laying in the spool file and is blocking all other > incoming wallace resource requests until I empty the spool folder Filed in https://issues.kolab.org/show_bug.cgi?id=3312 and fixed in git master. > > 5) rm /var/spool/pykolab/wallace/resources/incoming/* + restart wallace > > ## other tracebacks > > here's another traceback that I've seen when I tried to clean up the messes > > [...] > line 705, in delete_resource_event > targetfolder = imap.folder_quote(resource['kolabtargetfolder']) > KeyError: 'kolabtargetfolder' Filed under https://issues.kolab.org/show_bug.cgi?id=3312 and fixed in git master. > kolab-freebusy > -------------- > > I kinda feel helpless with correct way on how to configure freebusy and > make it work > > ## debian package bug > > * missing folder /var/{lib,cache}/kolab-freebusy > workaround: mkdir -p /var/{cache,lib}/kolab-freebusy ; chown > kolab:kolab /var/{cache,lib}/kolab-freebusy > > ## config.ini.sample > > * logfolder should be ./logs not ./log > * rename kolab-ldap to kolab-users > * add kolab-resources > * comment out exchange (leave it as example only) > * default imap connection points to imaps but ssl is not configured in > the default installation > ' filter @yourdomain not replaced by the default domain during setup-kolab These are just samples and are not supposed to be adapted by setup-kolab for only serve as reference for manual configuration. > ## strange search / database error > > with debug level = 100 > > ==> /var/log/kolab-freebusy/freebusy.log <== > [...] > [2014-08-13 13:44:50] web.DEBUG: Trying directory kolab-users .... > [...] > [2014-08-13 13:44:50] ldap.INFO: Found 1 entries for > (&(objectClass=kolabInetOrgPerson)(|(uid=daniel.hoffend at dotlan.info)(mail=daniel.hoffend at dotlan.info)(alias=daniel.hoffend at dotlan.info))) > {"mail":["daniel.hoffend at dotlan.info"]} [] > ==> /var/log/kolab-freebusy/errors <== > [13-Aug-2014 13:44:50 +0200]: DB Error: Configuration error. Unsupported > database driver: in > /usr/share/kolab-freebusy/lib/Roundcube/rcube_db.php on line 78 (GET > /freebusy/daniel.hoffend at dotlan.info) You likely have fbsource = imap://... configured which is not recommended for productive systems. However, the imap:// source uses the Roundcube framework to access event data in IMAP and also attempts to use caching for this. Symlinking /etc/roundcubemail/config.inc.php and /etc/roundcubemail/defaults.inc.php in /etc/kolab-freebusy/ should resolve these errors. > ## lib vs cache confusion? > > $ kolab-freebusyd --generateall 2>&1 | grep wrote > (11:43:50) fbaggregatorjob.cpp(103): wrote > "/var/lib/kolab-freebusy/daniel.hoffend at dotlan.info.ifb" > > root at kolab33:/var/log/kolab-freebusy# egrep -i "^(cache|fb)" > /etc/kolab-freebusy/config.ini > fbsource = file:/var/lib/kolab-freebusy/%s.ifb > fbsource = file:/var/cache/kolab-freebusy/%s.ifb > fbsource = > imap://cyrus-admin:xxxxx at localhost:143/%kolabtargetfolder?acl=lrs > cacheto = /var/cache/kolab-freebusy/%mail.ifb > fbsource = imap://%mail:xxxxx at localhost:143/?proxy_auth=cyrus-admin > cacheto = /var/cache/kolab-freebusy/%mail.ifb cacheto is optional and not required when free-busy data is generated by kolab-freebusyd --generateall into /var/lib/kolab-freebusy/. Some basic information is available here: http://docs.kolab.org/architecture-and-design/kolab-freebusy.html But full documentation of the configuration options is yet missing. > > ## cron > > * is it usefull or should freebusy always be generated on demand > * missing cron job to actually generate the freebusy files > * not really clear if we should configre nothing (on demand) or via cron > or via fbdaemon (sample file) which seems to be on the TODO list > > /etc/cron.d/kolab-freebusy > */15 * * * * root [ $(pgrep kolab-freebusyd >/dev/null 2>&1; echo $?) > -ne 0 ] && QT_NO_GLIB=1 kolab-freebusyd --generateall >>/var/log/kolab-freebusyd.log 2>&1 kolab-freebusyd now has a daemon mode which is the preferred way to run it. It's intended to let the kolab-freebusy service connect to the daemon and get updated free-busy data when requested: [directory "kolab-ldap"] ... fbsource = "fbdaemon://localhost:4455?user=%mail" This is all bleeding-edge development and unfortunately isn't yet all reflected in setup-kolab. > ## resources > > empty FB for resource collecion. this might be okay https://issues.kolab.org/show_bug.cgi?id=3165 > [2014-08-13 13:52:21] ldap.INFO: No entry found for > (&(objectClass=kolabInetOrgPerson)(|(uid=resource-collection-beamers at dotlan.info)(mail=resource-collection-beamers at dotlan.info)(alias=resource-collection-beamers at dotlan.info))) > [] [] > [2014-08-13 13:52:21] web.INFO: Returning empty Free/Busy list for user > resource-collection-beamers at dotlan.info [] [] > > trying to show the specific freebusy times of a single resource ==> > Search OK, but FAILED > > [2014-08-13 13:53:51] ldap.INFO: Found 1 entries for > (&(objectClass=kolabsharedfolder)(mail=resource-beamer-beamer1 at dotlan.info)) > {"mail":["resource-beamer-beamer1 at dotlan.info"],"kolabtargetfolder":["shared/Resources/beamer1 at dotlan.info"]} > [] > [13-Aug-2014 13:53:51 +0200]: DB Error: Configuration error. Unsupported > database driver: in > /usr/share/kolab-freebusy/lib/Roundcube/rcube_db.php on line 78 (GET > /freebusy/resource-beamer-beamer1 at dotlan.info.ifb) Same as above and should be solved with kolab-freebusy daemon. > kolab-notes > ----------- > > ## missing + button > > while plugins like addressbook have a [+] button bottom toolbar, the > notes plugin does not True. The notes plugin has a "Create note" button in the top toolbar, same as in calendars and tasks. But could be added in the list footer for consistency reasons. > ## locales > > A few german locales are missing. I know it's time to register at > transoflex or whatever it is called :-) https://www.transifex.com/projects/p/kolab/ it is :-) Kind regards, Thomas From vanmeeuwen at kolabsys.com Thu Aug 14 18:05:38 2014 From: vanmeeuwen at kolabsys.com (Jeroen van Meeuwen (Kolab Systems)) Date: Thu, 14 Aug 2014 18:05:38 +0200 Subject: [Kolab-devel] HOWTO: Block a Kolab release using Bugzilla Message-ID: <2133980aa749fcd30459e1076977e04f@kolabsys.com> Hi there, some of you may have noticed a large number of Bugzilla notification emails these days, which relates to our attempts to create some structure. We could use your help, and so here's what we intend to do: We have a guy sitting on top of so-called tracker bugs [1], and to make sure that we pay sufficient attention to the things we find important enough to get resolved before we pull the trigger on releasing Kolab 3.3, normally all tickets that block this tracker bug should be resolved, released, verified and closed, *or* explicitly postponed. If you find something that should be taken in to consideration for Kolab 3.3 (which we plan to release sooner rather than later), please also consider blocking this tracker bug, by entering either its number (3341) or its alias (K3.3) in to the "Blocks" field of a new or already open ticket. Please note that our time is limited (as is yours, I imagine), so we cannot make any guarantees -- but at least you'll have a chance we'll try ;-) Kind regards, Jeroen van Meeuwen [1] https://issues.kolab.org/show_bug.cgi?id=k3.3 -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 From dh at dotlan.net Fri Aug 15 13:54:26 2014 From: dh at dotlan.net (Daniel Hoffend) Date: Fri, 15 Aug 2014 11:54:26 +0000 Subject: [Kolab-devel] Kolab 3.3 feedback In-Reply-To: <53EC7043.7050109@kolabsys.com> Message-ID: Hi Thomas Thomas Br?derli wrote: >The message should be fully consumed by wallace and don't get passed >along. Need to investigate this. I'm debugging as well. seems like wallace is doing the wrong lookup using shared at example.org instead of resource-beamer-beamer1 at example.org Not sure exactly where the error is buried. >These are just samples and are not supposed to be adapted by >setup-kolab >for only serve as reference for manual configuration. Well but the packing is copying config.ini.sample to /etc/kolab-freebusy/config.ini and then setup-kolab is overwriting parts of the configuration using the given defaults. But it looks with the newest changes in setup-kolab and freebusy that the default configuration seems usable apart from the imaps:// certificate problem. >You likely have fbsource = imap://... configured which is not >recommended for productive systems. Well ... it's the configuration that is supplied in the default vanilla setup and the only option apart from --generateall that works in kolab <= 3.3 This database error only happens when all directory configurations have been searched and ended up with no result. In this case it seems that freebusy is trying to do another lookup run with an empty or non-given configuration ending with the given database driver error. >However, the imap:// source uses the Roundcube framework to access >event >data in IMAP and also attempts to use caching for this. > >Symlinking /etc/roundcubemail/config.inc.php and >/etc/roundcubemail/defaults.inc.php in /etc/kolab-freebusy/ should >resolve these errors. Yes that works and the packages have already been updated. It was a packaging error. >cacheto is optional and not required when free-busy data is generated >by >kolab-freebusyd --generateall into /var/lib/kolab-freebusy/. > >Some basic information is available here: >http://docs.kolab.org/architecture-and-design/kolab-freebusy.html > >But full documentation of the configuration options is yet missing. That's was the biggest problem. Without a proper configuration I could only take the sample configurations and made them run. And tbh. I personally prefer the imaps:// over the generateall method because the ldap+imap version is also accepting alias addresses while the generated version only matches the primary mail which doesn't always has to be the address people are used to use. >kolab-freebusyd now has a daemon mode which is the preferred way to run >it. It's intended to let the kolab-freebusy service connect to the >daemon and get updated free-busy data when requested: > >[directory "kolab-ldap"] >... >fbsource = "fbdaemon://localhost:4455?user=%mail" > >This is all bleeding-edge development and unfortunately isn't yet all >reflected in setup-kolab. Ah you're speaking about "that" daemon :-) # kolab-freebusyd --help | grep daemon -d, --daemon Run daemon (todo) Which is marked as "todo" an therefore I didn't even looked at it that the development has been finished. I guess a init rc file is missing. IMHO I would consider imaps:// access for kolab-freebusy webservice the way to go for Kolab 3.3 (as it is close to release) and the fbdaemon could become the prefered method for the next Kolab version (3.4?). This way there's enough time to actually test and prepare the daemon. -- Best Regards Daniel Hoffend -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2423 bytes Desc: not available URL: From paul at boddie.org.uk Fri Aug 15 14:46:55 2014 From: paul at boddie.org.uk (Paul Boddie) Date: Fri, 15 Aug 2014 14:46:55 +0200 Subject: [Kolab-devel] Kolab 3.3 feedback In-Reply-To: References: Message-ID: <201408151446.55700.paul@boddie.org.uk> On Friday 15. August 2014 13.54.26 Daniel Hoffend wrote: > > Thomas Br?derli wrote: > >The message should be fully consumed by wallace and don't get passed > >along. Need to investigate this. > > I'm debugging as well. seems like wallace is doing the wrong lookup > using shared at example.org instead of resource-beamer-beamer1 at example.org > Not sure exactly where the error is buried. Is this caused by a bad "result_format" setting in the /etc/postfix/ldap/virtual_alias_maps_sharedfolders.cf file? I made a change to avoid this in my own code a while back and it seemed to fix the problem: result_format = It was something of a case of trial and error, printing out what Postfix was generating and tracing the flow of execution in Wallace. Paul From dh at dotlan.net Fri Aug 15 15:20:04 2014 From: dh at dotlan.net (Daniel Hoffend) Date: Fri, 15 Aug 2014 15:20:04 +0200 Subject: [Kolab-devel] Fwd: Kolab 3.3 feedback References: Message-ID: <78A24980-1ADA-40F2-936A-DE1C6A314CCA@dotlan.net> Forgot to answer to the mailinglist > Von: Daniel Hoffend > Datum: 15. August 2014 15:01:10 MESZ > An: Paul Boddie > Betreff: Re: [Kolab-devel] Kolab 3.3 feedback > > I've to take a closer look cause the mail routing works fine for resource collections. But you might be right cause resource collections don't have an imap folder (kolabtargetfolder) > > -- > Best regards > Daniel Hoffend > >>> Am 15.08.2014 um 14:46 schrieb Paul Boddie : >>> >>> On Friday 15. August 2014 13.54.26 Daniel Hoffend wrote: >>> >>> Thomas Br?derli wrote: >>>> The message should be fully consumed by wallace and don't get passed >>>> along. Need to investigate this. >>> >>> I'm debugging as well. seems like wallace is doing the wrong lookup >>> using shared at example.org instead of resource-beamer-beamer1 at example.org >>> Not sure exactly where the error is buried. >> >> Is this caused by a bad "result_format" setting in the >> /etc/postfix/ldap/virtual_alias_maps_sharedfolders.cf file? I made a change to >> avoid this in my own code a while back and it seemed to fix the problem: >> >> result_format = >> >> It was something of a case of trial and error, printing out what Postfix was >> generating and tracing the flow of execution in Wallace. >> >> Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From liste at gelpi.it Fri Aug 15 19:10:53 2014 From: liste at gelpi.it (Gelpi Andrea) Date: Fri, 15 Aug 2014 19:10:53 +0200 Subject: [Kolab-devel] Kolab 3.2 multi domain documentation issue Message-ID: <53EE3F1D.2090802@gelpi.it> Hi, documentation at http://docs.kolab.org/howtos/multi-domain.html is not complete. In Roundcube Cahnges there is: $config['kolab_auth_addressbook'] = Array( (...snip...) 'base_dn' => 'ou=People,%dc', (...snip...) 'groups' => Array( 'base_dn' => 'ou=Groups,%dc', (...snip...) 'domain_base_dn' => 'cn=kolab,cn=config', 'domain_filter' => '(&(objectclass=domainrelatedobject)(associateddomain=%s))', 'domain_name_attr' => 'associateddomain', (...snip...) Here a line is missing. search_base_db must be change from 'ou=People,dc=example,dc=com' to 'ou=People,%dc' without this line modification Global Address Book is working only in first domain. The correct page should be: $config['kolab_auth_addressbook'] = Array( (...snip...) 'base_dn' => 'ou=People,%dc', (...snip...) 'search_base_dn' => 'ou=People,%dc', (...snip...) 'groups' => Array( 'base_dn' => 'ou=Groups,%dc', (...snip...) 'domain_base_dn' => 'cn=kolab,cn=config', 'domain_filter' => '(&(objectclass=domainrelatedobject)(associateddomain=%s))', 'domain_name_attr' => 'associateddomain', (...snip...) Regards, -- ing. Andrea Gelpi *************************************************** La Terra non la abbiamo ereditata dai nostri avi, ma la abbiamo presa in prestito dai nostri bambini. *************************************************** We do not inherit the Earth from our parents, but borrow it from our children. *************************************************** From liste at gelpi.it Sat Aug 16 12:20:16 2014 From: liste at gelpi.it (Gelpi Andrea) Date: Sat, 16 Aug 2014 12:20:16 +0200 Subject: [Kolab-devel] Kolab 3.2 multi domain documentation issue In-Reply-To: <53EE3F1D.2090802@gelpi.it> References: <53EE3F1D.2090802@gelpi.it> Message-ID: <53EF3060.9010302@gelpi.it> Il 15/08/2014 19:10, Gelpi Andrea ha scritto: > Hi, > documentation at http://docs.kolab.org/howtos/multi-domain.html > is not complete. > > In Roundcube Cahnges there is: > > $config['kolab_auth_addressbook'] = Array( > (...snip...) > 'base_dn' => 'ou=People,%dc', > (...snip...) > 'groups' => Array( > 'base_dn' => 'ou=Groups,%dc', > (...snip...) > 'domain_base_dn' => 'cn=kolab,cn=config', > 'domain_filter' => > '(&(objectclass=domainrelatedobject)(associateddomain=%s))', > 'domain_name_attr' => 'associateddomain', > (...snip...) > > Here a line is missing. > > search_base_db must be change from 'ou=People,dc=example,dc=com' to > 'ou=People,%dc' > > without this line modification Global Address Book is working only in > first domain. > > The correct page should be: > > $config['kolab_auth_addressbook'] = Array( > (...snip...) > 'base_dn' => 'ou=People,%dc', > (...snip...) > 'search_base_dn' => 'ou=People,%dc', > (...snip...) > 'groups' => Array( > 'base_dn' => 'ou=Groups,%dc', > (...snip...) > 'domain_base_dn' => 'cn=kolab,cn=config', > 'domain_filter' => > '(&(objectclass=domainrelatedobject)(associateddomain=%s))', > 'domain_name_attr' => 'associateddomain', > (...snip...) > > Regards, > Yesterday I forgot to say that the file that need to be modify as above is only /etc/roundcubemail/config.inc.php Documentation is OK for file /etc/roundcubemail/kolab_auth.inc.php -- ing. Andrea Gelpi *************************************************** La Terra non la abbiamo ereditata dai nostri avi, ma la abbiamo presa in prestito dai nostri bambini. *************************************************** We do not inherit the Earth from our parents, but borrow it from our children. *************************************************** From torsten at kolab.org Mon Aug 18 10:11:36 2014 From: torsten at kolab.org (Torsten Grote) Date: Mon, 18 Aug 2014 10:11:36 +0200 Subject: [Kolab-devel] Kolab 3.2 multi domain documentation issue In-Reply-To: <53EE3F1D.2090802@gelpi.it> References: <53EE3F1D.2090802@gelpi.it> Message-ID: <1753833.QbMjhhOpjs@t7laptop1> Hi Andrea, On Friday 15 August 2014 19:10:53 Gelpi Andrea wrote: > documentation at http://docs.kolab.org/howtos/multi-domain.html > is not complete. Thanks a lot for helping to polish the documentation. The preferred way of submitting changes at the moment is via pull requests on github. You can fork the repository here: https://github.com/kanarip/kolab-docs Kind Regards, Torsten -- Torsten Grote Kolab.org Community Manager e: torsten at kolab.org w: https://Kolab.org pgp: 0x2175A534A4F2EFA3 From bruederli at kolabsys.com Mon Aug 18 13:12:35 2014 From: bruederli at kolabsys.com (=?UTF-8?B?VGhvbWFzIEJyw7xkZXJsaQ==?=) Date: Mon, 18 Aug 2014 13:12:35 +0200 Subject: [Kolab-devel] Possible typo in roundcube rcmail.php In-Reply-To: References: Message-ID: <53F1DFA3.3040503@kolabsys.com> Thomas Z. wrote: > /usr/share/roundcubemail/program/include/rcmail.php > about line 240 > > if (!$contacts) { > // there's no default, just return > if ($default) { > return null; > } > > > should be (assuming the comment is correct and the error message I get > logged is false) > > if (!$contacts) { > // there's no default, just return > if (!$default) { <------ > return null; > } Nope, the code is correct. $default being true means that the default address book was requested. If not exists, we can exit here. ~Thomas From issues at kolab.org Tue Aug 19 12:04:46 2014 From: issues at kolab.org (aheinecke) Date: Tue, 19 Aug 2014 10:04:46 +0000 Subject: [Kolab-devel] [issue4872] PGP/MIME messages with attachments have invalid signatures In-Reply-To: <1408442686.43.0.0407354354349.issue4872@kolab.org> Message-ID: <1408442686.43.0.0407354354349.issue4872@kolab.org> PGP/MIME messages created with e3.5 have invalid signatures. They are verified in other e3.5 clients but are shown as invalid in KMail2, thunderbird / enigmail and most importantly with gpgparsemail. Attached is an example mail that leads to: ./gpgparsemail --crypto ~/Documents/Signature\ test\ with\ attachment.mbox .Return-Path: .Received: from localhost (localhost.localdomain [127.0.0.1]) . by kolab.intevation.de (Cyrus v2.3.16-kolab-nocaps) with LMTPA; . Tue, 19 Aug 2014 11:41:31 +0200 .X-Sieve: CMU Sieve 2.3 .Received: from localhost (localhost.localdomain [127.0.0.1]) . by kolab.intevation.de (Postfix) with ESMTP id 31A4194D166 . for ; Tue, 19 Aug 2014 11:41:31 +0200 (CEST) .X-Virus-Scanned: by amavisd-new at intevation.de .X-Spam-Flag: NO .X-Spam-Score: -1.8 .X-Spam-Level: .X-Spam-Status: No, score=-1.8 tagged_above=-999 required=3.5 . tests=[ALL_TRUSTED=-1.8] .Received: from localhost (localhost.localdomain [127.0.0.1]) . by kolab.intevation.de (Postfix) with ESMTP id C219994D167 . for ; Tue, 19 Aug 2014 11:41:30 +0200 (CEST) .Received: from thoe.hq.intevation.de (aktaia.hq.intevation.de [192.168.11.254]) . (Authenticated sender: emanuel.schuetze at intevation.de) . by kolab.intevation.de (Postfix) with ESMTPSA id ADA8694D166 . for ; Tue, 19 Aug 2014 11:41:30 +0200 (CEST) .To: Andre Heinecke .Subject: Signature test with attachment .From: Emanuel =?iso-8859-1?q?Sch=FCtze?= .Date: Tue, 19 Aug 2014 11:41:28 +0200 .MIME-Version: 1.0 .Content-Type: multipart/signed; . boundary="nextPart5165717.X30Rp5ctXb"; . protocol="application/pgp-signature"; . micalg=pgp-sha1 .Content-Transfer-Encoding: 7bit .Message-Id: <201408191141.30234.emanuel.schuetze at intevation.de> .X-Kolab-Scheduling-Message: FALSE h media: multipart signed h signed.protocol: application/pgp-signature b down b part :--nextPart5165717.X30Rp5ctXb c begin_hash .Content-Type: multipart/mixed; . boundary="Boundary-01=_Kvx8Tab1lRZFVOd" .Content-Transfer-Encoding: 7bit .Content-Disposition: inline h media: multipart mixed b down b part :--Boundary-01=_Kvx8Tab1lRZFVOd .Content-Type: text/plain; . charset="us-ascii" .Content-Transfer-Encoding: 7bit .Content-Disposition: inline h media: text plain This email with attachment is signed with OpenPGP. b part :--Boundary-01=_Kvx8Tab1lRZFVOd .Content-Type: text/plain; . charset="iso-8859-1"; . name="testfile.txt" .Content-Transfer-Encoding: 7bit .Content-Disposition: attachment; . filename="testfile.txt" h media: text plain This is a test file. b last b up :--Boundary-01=_Kvx8Tab1lRZFVOd-- b part c end_hash :--nextPart5165717.X30Rp5ctXb .Content-Type: application/pgp-signature; name=signature.asc .Content-Description: This is a digitally signed message part. h media: application pgp-signature c begin_signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlPzG8oACgkQoeOGQ2mpEfyLbwCfT0yHqxFGhniLX8exG30ynOaX q58An0coFTv+uELN+Ncrjfjs0Ve0LDlZ =7oXL -----END PGP SIGNATURE----- b last c end_signature b up gpg: reading options from `/home/aheinecke/.gnupg/gpg.conf' gpg: Signature made Tue 19 Aug 2014 11:41:30 AM CEST using DSA key ID 69A911FC c [GNUPG:] BADSIG A1E3864369A911FC Emanuel Sch??tze gpg: BAD signature from "Emanuel Sch??tze " secmem usage: 1408/1408 bytes in 2/2 blocks of pool 1408/32768 ---------- assignedto: aheinecke files: Signature test with attachment.mbox keyword: enterprise35, kde client messages: 28849 nosy: aheinecke, emanuel priority: urgent status: unread title: PGP/MIME messages with attachments have invalid signatures ______________________________________ Kolab issue tracker ______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: Signature test with attachment.mbox Type: application/mbox Size: 2600 bytes Desc: not available URL: From marbetschar at gmail.com Wed Aug 20 14:19:49 2014 From: marbetschar at gmail.com (Marco Betschart) Date: Wed, 20 Aug 2014 14:19:49 +0200 Subject: [Kolab-devel] Installing Kolab on CentOS fails :( Message-ID: <3D4BD1D7-EB62-436D-87C9-CF7F4332640D@gmail.com> Dear Kolab Devs! I currently try to install Kolab on a CentOS box using the following manual: http://docs.kolab.org/installation-guide/centos.html Unfortunately installing fails since a GPG key could not be found: Downloading Packages: warning: rpmts_HdrFromFdno: Header V3 RSA/SHA1 Signature, key ID b4f6d430: NOKEY Retrieving key from http://obs.kolabsys.com/repositories/Kolab:/3.2/CentOS_6/repodata/repomd.xml.key Any ideas how to solve this issue? Thanks Marco From da at it25.de Fri Aug 22 20:48:06 2014 From: da at it25.de (Dirk Ahrnke) Date: Fri, 22 Aug 2014 20:48:06 +0200 Subject: [Kolab-devel] No initial bug status Message-ID: <53F79066.5040905@it25.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, when trying to add a new bug at https://issues.kolab.org/enter_bug.cgi?product=UCS I get: No bug status is available on bug creation. Please report the problem to devel at lists.kolab.org. Regards - -- Dirk Ahrnke -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBAgAGBQJT95BmAAoJEESkzLL8GFWzw48IAMkvSNqHavHx1+6nmOaqrQwR W6Kem8KxQyWqqtjeoeQYwo115xlwfjKfjLI+EVykUNWNb9E3yYpkqmEN/04sO0QY c6ddQeaPsS34jtLD3bFZ+1NOJQDVfOYsL+OcqkyFLUBnKJrT6bEUQifIdDORjLn2 qJnUm+JWEXuOfNgNIeHdAo5x70Yd08cyvtmF3f3lvCS6WTtIHbWHxbrOx5NNx15Y Fzx1NzG/qJ/b50J06FpyegBOmrX8w4Oli0zrjsqVLKdV+wJYRsfH+ubfgklLZ2j/ sAhcLmOUrFtkB1wHE/+vH2XhBdWpzE2jGrWn3umhQd9IHL0JucG+fQgByvHko7Q= =ic1c -----END PGP SIGNATURE----- From sven at narfation.org Sun Aug 24 23:12:40 2014 From: sven at narfation.org (Sven Eckelmann) Date: Sun, 24 Aug 2014 23:12:40 +0200 Subject: [Kolab-devel] Bug#748614: [libkolab0] looses information about birthdays In-Reply-To: <2452203.y7IuQpjIue@myrada> References: <1406879357.24586.YahooMailNeo@web133202.mail.ir2.yahoo.com> <67006856.zFepznJKF3@myrada> <2452203.y7IuQpjIue@myrada> Message-ID: <2679848.eKV6P1RDkS@sven-edge> reassign 748614 libkolab0 0.5.2-1 reassign 732213 libkolab0 0.5.2-1 forcemerge 748614 732213 retitle 748614 [libkolab0] looses information about birthdays tags 748614 + patch upstream forwarded 748614 https://issues.kolab.org/show_bug.cgi?id=2739 thanks Hi, the problem of the unsaved kaddressbook date-values doesn't seem to be in libkolabxml1 or kdepim-runtime but in libkolab0. I've just created a patch to fix it for me. Maybe this patch or a variation of it could be included as part of the next libkolab upload. Please also include it in the upstream bug #2739. Kind regards, Sven -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-KDateTime-with-only-valid-date.patch Type: text/x-patch Size: 1509 bytes Desc: not available URL: From timotheus at kolab.org Tue Aug 26 15:34:01 2014 From: timotheus at kolab.org (Timotheus Pokorra) Date: Tue, 26 Aug 2014 15:34:01 +0200 Subject: [Kolab-devel] Multi domain administrators in Kolab 3.2 In-Reply-To: <20140814075845.GN12451@reaktio.net> References: <53BECF22.6050603@gelpi.it> <03c5e525c5998a3913a7dff08da8a734@kolab.org> <20140813110232.GI12451@reaktio.net> <111a2f5ad2d6aa4e16c0b832b4d11c19@kolab.org> <20140814075845.GN12451@reaktio.net> Message-ID: Hello Pasi, > Btw do you know if your patches will work with the kolab 3.3 packages? > I didn't try yet, but I will soon. I have now fixed my patches so that they work for Kolab 3.3 see the source at https://github.com/TBits/KolabScripts/tree/Kolab3.3 I have now nightly tests, which now succeed for Kolab 3.3 as well: http://lbs.solidcharity.com/detail/tbits.net/kolab-test/kolab-test hope this helps, Timotheus From pasik at iki.fi Tue Aug 26 16:32:40 2014 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Tue, 26 Aug 2014 17:32:40 +0300 Subject: [Kolab-devel] Multi domain administrators in Kolab 3.2 In-Reply-To: References: <53BECF22.6050603@gelpi.it> <03c5e525c5998a3913a7dff08da8a734@kolab.org> <20140813110232.GI12451@reaktio.net> <111a2f5ad2d6aa4e16c0b832b4d11c19@kolab.org> <20140814075845.GN12451@reaktio.net> Message-ID: <20140826143240.GI12451@reaktio.net> On Tue, Aug 26, 2014 at 03:34:01PM +0200, Timotheus Pokorra wrote: > Hello Pasi, > > >Btw do you know if your patches will work with the kolab 3.3 packages? > >I didn't try yet, but I will soon. > I have now fixed my patches so that they work for Kolab 3.3 > see the source at https://github.com/TBits/KolabScripts/tree/Kolab3.3 > > I have now nightly tests, which now succeed for Kolab 3.3 as well: > http://lbs.solidcharity.com/detail/tbits.net/kolab-test/kolab-test > Great. I'll try them later this week and let you know how it goes. Thanks! -- Pasi > hope this helps, > Timotheus From issues at kolab.org Tue Aug 26 17:57:30 2014 From: issues at kolab.org (aheinecke) Date: Tue, 26 Aug 2014 15:57:30 +0000 Subject: [Kolab-devel] [issue4873] Crash when moving folder with subfolders from dimap to imap account (RT#10270) In-Reply-To: <1409068650.75.0.446080291316.issue4873@kolab.org> Message-ID: <1409068650.75.0.446080291316.issue4873@kolab.org> To reproduce 1. Create a folder with a subfolder and a sub subfolder. On a dimap account. 2. Put some mails into this folder. 3. Sync 4. Move the folder to an online imap account. -> Sometimes (not always) the job hangs in the online imap account on "Retrieving folder contents of the new folder". If you touch the account configuration (open the account config and close it again) the hang is resolved but a segmentation fault occurs. It is possible that the segfault would also occur when the job timeouts as the "Opening account config" trick was not part of the Original Report. kmail: Failed to copy one subfolder, let's not continue: aheinecke2 online imap/inbox/testfolder2/folder1/testfolder2 kmail: [void KMail::RenameJob::folderCopyComplete(bool)] false kmail: WARNING: [void KMail::RenameJob::folderCopyComplete(bool)] could not copy folder kmail: [void KMFolderMgr::slotRenameDone(QString, bool)] false kmail: [void KMail::RenameJob::folderCopyComplete(bool)] false kmail: WARNING: [void KMail::RenameJob::folderCopyComplete(bool)] could not copy folder kmail: [void KMFolderMgr::slotRenameDone(QString, bool)] false kmail: [void KMail::RenameJob::folderCopyComplete(bool)] true kmail: deleting old folder kmail: [void KMFolderMgr::slotRenameDone(QString, bool)] true Program received signal SIGSEGV, Segmentation fault. 0x00007fffe8a331ab in FolderStorage::close (this=0x71, owner=0x7fffe8da708d "copyfolder", aForced=false) at ../../kmail/folderstorage.cpp:104 104 if (mOpenCount <= 0) return; (gdb) bt #0 0x00007fffe8a331ab in FolderStorage::close (this=0x71, owner=0x7fffe8da708d "copyfolder", aForced=false) at ../../kmail/folderstorage.cpp:104 #1 0x00007fffe8a0fae0 in KMFolder::close (this=0xf64530, owner=0x7fffe8da708d "copyfolder", force=false) at ../../kmail/kmfolder.cpp:493 ---------- assignedto: aheinecke keyword: enterprise35, kde client messages: 28851 nosy: aheinecke, emanuel priority: critical status: in-progress title: Crash when moving folder with subfolders from dimap to imap account (RT#10270) ______________________________________ Kolab issue tracker ______________________________________ From da at it25.de Wed Aug 27 20:30:10 2014 From: da at it25.de (Dirk Ahrnke) Date: Wed, 27 Aug 2014 20:30:10 +0200 Subject: [Kolab-devel] No initial bug status In-Reply-To: <53F79066.5040905@it25.de> References: <53F79066.5040905@it25.de> Message-ID: <53FE23B2.4070004@it25.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Can someone please have a look at this? Am 22.08.2014 20:48, schrieb Dirk Ahrnke: > Hi, > > when trying to add a new bug at > https://issues.kolab.org/enter_bug.cgi?product=UCS I get: > > No bug status is available on bug creation. Please report the > problem to devel at lists.kolab.org. > > Regards > > _______________________________________________ devel mailing list > devel at lists.kolab.org > https://lists.kolab.org/mailman/listinfo/devel > Thanks, - -- Dirk Ahrnke -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBAgAGBQJT/iOyAAoJEESkzLL8GFWzZGEH/A64sdIc8+DhWQgXPbQL4/2N NkcZkLU/zr8tJJJqHyd7HhF0SB6fF2nJDSRi4j16b7y8NhO/+iZtc+3wYmMxJmbJ RjNiEaYBTCXTYC7kalveNvrB+ugnQsam0uCow25y6sj/fQjvaiFUSCnnwIUzr9Qi PUR2/iXn/WHOT+P4OPAwfeG0Hf36cel/VhHIGOUPcwUihsOx7z/GUW0rFCFc3mia x8bqp8wlnoGLE2FPfzPSM0zCHRL4sdjJ6lrihchgSti+r/eaKplWKMj74eC2SIYa WPfx1tlXwy5SLyA8bUkIHjK+1SaTKwa7rh9wumDVmB/xzApMxA2DUpIMELoOCqw= =UMkD -----END PGP SIGNATURE-----