It's because of default php versions on Debian:
Debian 10 - php 7.3
Debian 11 - php 7.4
Debian 12 - php 8.2

I'm still on Debian 10 - a new test-install on Debian 12 throws errors when logging in to kolab-webadmin. Didn't investigate further...

Thanks for this happy news :-)

This has now been merged into Kolab:16, though the package is still building, but should become available shortly.

Thx for the News!

Problem is with loading order of php modules. On Ubuntu the fix for me was:

mv /etc/php7.4/cli/conf.d/30-kolabformat.ini /etc/php7.4/cli/conf.d/32-kolabformat.ini
mv /etc/php7.4/apache2/conf.d/30-kolabformat.ini /etc/php7.4/apache2/conf.d/32-kolabformat.ini

We're working on a fix for packaging.

The broken install dependency kolab-webclient -> roundcubemail-plugins-kolab should be fixed by https://obs.kolabsys.com/request/show/3262, which is currently under review.

Superseded by https://obs.kolabsys.com/request/show/3262, which includes an additional fix for the upgrade path by adding a conflict with roundcubemail-plugins-kolab.

Seems to be fixed by D3692 and rPbd3a9e74745461089d7afc4e51a39c21958907bf.

Judging by the last comment, it looks like this has been fixed. Closing as Resolved; please reopen if I'm mistaken.

Fix proposed in https://obs.kolabsys.com/request/show/3261. @machniak, @mollekopf, could you please take a look and push it through to Kolab:16 if it's okay?

Any further Developments here?

Very old.

Packaged and released in 1.5.4.11

Latest roundcubemail package on Ubuntu 18.04 is 1.5.4.7-1~kolab1_all.deb, which as far as I can see has Net_SMTP in version 1.10.1 built-in. So, all should be ok, but I don't have Ubuntu system to verify on.

@mollekopf, imap.user_mailbox_create() returns False on error.

Duplicate of T6688.

I think it is better to pass the invitation to Inbox for manual processing.

imap.user_mailbox_create() always returns a string, so this should be fine. Is there a command-line way to reproduce this issue?

Fixed in roundcubemail-selfcontained

D3692 and D3710 should fix this
I ran into same error, when testing for Python 3

According to the log, the script tries to create a user named '@'. That's, well, weird. Unfortunately, I'm not sufficiently familiar with the pykolab codebase to make a qualified guess where this username may have originated from.

Hello sicherha,

Hello sicherha,

Umm, yeah, the docs are somewhat outdated because the build pipeline appears to be broken (T6055)...

Is there a release date for Kolab for Debian Buster?
https://docs.kolab.org/installation-guide/index.html does not mention anything.

Looking at the email source the for the invitation there's this part (IDs changed, so it's not proper link to test with):

I see Debian 10 has been added in OBS, is anyone working on adding CentOS 8?

I didn't know that wallace created generate calender placeholder. Do they have an update for this? Hoping that they fix it as soon as possible.

Any thoughts about how to fix this issue?

Yes I agree a 1000% (three zeros!)
I taught about it a while ago, but was very busy,

Hello gpunk,

Changing to hight, since it is a non working advertised feature -- hence a blocking problem .

Patch seems to work. I haven't seen this issue after applying the patch. Thanks a lot!

I've updated my kolab installation from Debian 9 to 10. All in all nothing major. Highlights:

If you feel courageous enough, I would say it's ready for field testing. Should you encounter any remaining rough edges, please report them so they can be ironed out.

I've seen in OBS that we now build packages for Debian 10.
What's your opinion: Is it probably ready to upgrade my instance?
The only package failing to build is chwala - where I could possiby use the old package...

@machniak Thanks a lot! I'll try the patch. This .ics arrived from Microsoft Exchange Server 2010 (based on the PRODID field in .ics).

Fixed.

Further investigation shows that actually Kolab format has CutypeRoom and CutypeUnknown defined. So, we can add these to the map, but still we should probably silently ignore unsupported values.

According to RFC5545 ROOM, UNKNOWN, X-* are valid values. Those aren't supported by Kolab, but we definitely should not throw exceptions on these. I wouldn't touch the map variable. Probably better to handle these in set_cutype().

I believe this was already fixed back in June with https://obs.kolabsys.com/package/rdiff/Kolab:Winterfell/kolab?linkrev=base&rev=37.

I'm working on providing Debian 10 packages for Kolab 16.

According to https://obs.kolabsys.com/project/show/Kolab:Winterfell
RHEL_8 and Debian_10.0 have been added to Winterfell.
So my most pressing wishes have been granted :-)

Fixed in 3841f63fbd42 [roundcubemail master] and eee719e6d2f87 [roundcubemail-plugins-kolab master].

This issue is a bug in Roundcube sql cache, so is reproducible with $config['imap_cache'] = 'db' and of course only when using MySQL engine. No issue if it's set to memcache, redis or disabled.

This ticket is both old, as well as appears to be out-dated, in the sense that further updates to guam have been made available that also, supposedly, work, and was originally reported by an employee for another one of our then-employees to address.

Correcting the priority from 60/40 to Normal

Correcting the priority from 60/40 to Normal

Correcting the priority from 60/40 to Normal

Correcting the priority from 60/40 to Normal

This should be documented here, shouldn't it?
https://docs.kolab.org/upgrade-guide/kolab-16.html

In T2289#37694, @vanmeeuwen wrote:

The immediate workaround is to set smtp-wallace_destination_recipient_limit = 1 in /etc/postfix/main.cf.

Duplicate of T4049.

No more support for Debian Wheezy.

Patch applied in 239783c3dd576.

Hello,
i reported the problem by the beginning of 2017 using the mailing list.
Since it hasn't been resolved, i disabled guam by changing the cyrus config.
This was with version 0.9.2-1.
Now, today i gave it a try and installed version 0.9.2-3. (Running on debian jessie).
Thunderbird can get the mails in the inbox, but when it starts to index the folders, thunderbird hangs.
On the server i strace the guam process and see, that there are unjoined threads and they never join.
Perhaps a hint, since erlang is based on threads.
As for now, i disabled guam again.

Hi. Any chance to get some feedback on this? If the change needs to be adjusted, or a related ticket needs to be created, i just need to know it.

Add changes in wallace for correct handling too