Looks like fixed versions have been rolled out.

I just double-checked: the fix is published, but apparently the package version didn't get bumped.

Looks like we can close this one. Thanks @mroland for the analysis and patch!

No news yet from my side, sorry. Working life has grabbed me again, and I'll need a couple of contiguous undisturbed hours to narrow down the problem.

Thanks for investigating this! I can confirm that D3980 solves the synchronisation issue with Kontact for me, but like @johndoe I still have to log in with my full email address. With a shortlogin, iRony does not find the associated principal.

(Sorry about my tone in yesterday's last-night comment; I was a tad frustrated. I'd like to do what I can to help fix this as quickly as possible.)

It looks like the workaround (logging into iRony with the full email address) works fine with DAVx5 (on Android) but doesn't work with Kontact or Thunderbird.

I have found a workaround for my problem: log in with the full email address (e.g. firstname.lastname@example.org). It seems that logging in with the username only (e.g. firstname.lastname) is currently broken, but I haven't yet found out why.

... and I can reproduce the calendar-discovery issue: no calendars are discoverable via CalDAV any more; trying to access an existing URL gives me HTTP 404. I shouldn't have upgraded yet. 🙄

Which version of the roundcubemail package is installed on your system? I have 1:1.5.3-0~kolab2 and the line numbers from your log don't match the code I see on my system.

Do you have any helpful log entries, for example in /var/log/iRony/errors.log?

👂 No objections heard since yesterday; marking this as Resolved.

Awesome! Closing this issue then. Glad to have this sorted out so we can begin the new year with a working Kolab installation.

@raptor2101, does updating to irony_0.4.6-7~kolab1 fix the issue for you?

I assume this is related to T7097, so I'm closing this task as a duplicate.

Which version of the php-kolabformat package is installed on your system? I presume it's already >= 1.3.0.

Thanks! Upgrading the code base is of course better than downgrading the dependencies. I was just unsure whether there are additional incompatibilities besides the children property being deprecated.

Thanks for clarifying! Unless somebody still has any objections, I believe we can close this issue.

Reopening because the compatibility issue between iRony and sabre/vobject needs to be addressed as well.

Does /var/log/iRony/errors.log contain any helpful information?

@mollekopf, @machniak: Could one of you please adjust buildroundcubemailtarball.sh, recreate the tarball and bump the packages? I cannot do it myself because I don't have access to ssh://git@git.kolab.org/source/roundcubemail-skin-elastic.git.

The offending change was made here in the file buildroundcubemailtarball.sh: https://obs.kolabsys.com/package/rdiff/Kolab:16/roundcubemail-selfcontained?rev=13

Wait, that means the roundcubemail package is bundling the wrong version of sabre/vobject. It should contain 3.5.3 but actually contains 4.x. What a mess...

Ah right, you have to downgrade all of the following packages (they're built from the same source package):

• libkolabxml1v5
• php-kolabformat
• python-kolabformat

Turns out php-kolabformat_1.3.0-0~kolab1 shouldn't even be available on Ubuntu 18.04 and Debian 10 since the build has been disabled in OBS - but the packages resulting from a previous build were kept in place. I have wiped these stale & broken binaries from the repository.

I think I've found the root cause: it looks like php-kolabformat_1.3.0-0~kolab1 seems to be missing the file /usr/share/php/kolabformat.php, which was still present in php-kolabformat_1.2.1-0~kolab3.

The bug reporters refer to Ubuntu 18.04 and Debian 10, so that's PHP 7.2 and 7.3, respectively.

@machniak, do you have an idea what's going wrong here regarding the object-creation errors? How come these new_*() functions are overloaded?

I want to fix this, but I need some information. First the skin issue:

I managed to fix using the web interface skin problem by adding a symlink

What symlink is missing?

A fixed version of the irony package is underway: https://obs.kolabsys.com/request/show/3105

I believe I've found the underlying issue: typed properties (i.e. class member variables) were not introduced until PHP 7.4.0.
Source: https://www.php.net/manual/en/language.oop5.properties.php

Typed properties were introduced in PHP 7.4.0. Make sure that Kolab also works
with older PHP instalations.

Okay, next try (note the leading backslash):

protected \Sabre\CardDAV\Xml\Request\AddressBookQueryReport $query;

If that doesn't work either, let's just go back to omitting the type name.

Needs revision; doesn't fix the issue yet.

Looks like commit https://git.kolab.org/rI59977da735b6892075fffc802e4b656d94d75cd2 is to blame.

Hmm, so replacing the relative symlink with an absolute symlink fixes the problem for you? Interesting.

The symptoms sound closely related to T7109; closing this as a duplicate.

This is strange - /usr/share/roundcubemail/vendor shouldn't be empty. Did the recent upgrade of the roundcubemail package fail? Is it in a half-installed state?

Abandoning this in favour of D3944.

Yeah, apparently the inclusion of updates from Kolab:16:Testing into Kolab:16 has to be done manually. Glad the Roundcube upgrade path is now finally working as expected.

@mollekopf, will updates residing in Kolab:16:Testing be pushed to Kolab:16 automatically or is manual intervention needed? In other words, should I file an inclusion request?

The patch doesn't apply cleanly because the following hunk is already present on master:

try:
    import httplib
except ImportError:
    import http.client as httplib

Could you rebase the commit onto master?

This is missing the import stuff, isn't it?

A fixed version is already in Kolab:16:Testing; it should hit the Kolab:16 repository soon.

Correction: that simple fix apparently doesn't do the trick.

I believe there's an integer conversion missing in line 116 of pykolab/imap_utf7.py - it should probably be:

res.append(chr(int(c)))

Rebase to master

On second thought, these changes are in no way specific to Python 3, so let's get them into master right away.

Hmm, where can I see in Phabricator for which target branch this diff is intended? It should go into dev/python3, but I can't tell from the web interface.

Turns out the changes in wallace/__init__.py and wallace/modules.py have already landed on master - see commits 63532e93 and c2b69efb. Could you drop them from this diff and keep only the changes to wallace/module_gpgencrypt.py?