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?

I would reinstall both just to be on the safe side.

Nice, this looks way better.

Is roundcubemail-core still installed in the old version? If yes, uninstall it first (after manually patching the prerm script), then proceed with apt upgrade.

In T6971#96146, @johndoe wrote:

Sorry, even with version 1.5.2-0~kolab4 apt-get upgrade does not work.

Do you get a specific error message? I believe the tricky part is probably to get the old roundcubemail-core package uninstalled as described above in T6971#96134: edit /var/lib/dpkg/info/roundcubemail-core.prerm, comment out the line with reload_apache, then perform the package upgrade.

Python 3 bindings for libkolabxml are on their way and should be available in a few hours once the build finishes.

I have fixed the dependency issues in OBS. The new roundcubemail should now play along nicely with the rest of the Kolab packages.

Correcting myself: the dependency on roundcubemail-plugins-kolab (>= 3.0) might be harmless after all, but roundcubemail-skin-kolab definitely reeks of problems.

It seems that the many individual Roundcube + plugin packages have been consolidated into one big 'standalone' package that bundles them all together (https://obs.kolabsys.com/package/show/Kolab:16/roundcubemail-selfcontained).

Actually, cyruslib.py is not external; it is part of the pykolab package. Its source lies in the root of the pykolab repository.

Looks good to me.

@vanmeeuwen, how should we proceed here? This is an effort to get the PyKolab codebase into a state where it works with Python 3 without breaking existing systems that are still based on legacy Python 2. Given that background, the commit looks plausible to me.

In D3448#41491, @ghane wrote:

pykolab.auth ERROR [11820] Authentication cache failed: TypeError("'<=' not supported between instances of 'TypeError' and 'int'")

Wait - so somewhere, someone tries to call debug() with a level argument that has the type TypeError? That doesn't sound right at all...

The only rfc822 function used below is rfc822.parsedate(); according to https://docs.python.org/3.10/library/email.utils.html, its email counterpart is not not email.parsedate() but email.utils.parsedate().

Do you have a backtrace of a call to debug() that triggers this type error? I wonder if it might be preferable to fix the root cause rather than the symptom.

Could you add to the summary of this differential a description of the concrete error that is being solved here? I presume that some part of Python (which one?) complained about one of the file descriptors for stdin/ stdout/ stderr being unavailable, but it would be great to make that explicit.

Looks good to me, thanks!

Thanks a lot! See D1966 for my review comments.

Thanks!

Hopefully fixed through the addition of a %pretrans scriptlet as described in https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacement/. Please reopen if the problem persists.

Thanks for the diff!

1. Install Arcanist on your system.
2. Clone the PyKolab Git repository.
3. Create a commit from your patch.
4. Type arc diff to submit the commit for review.

Do you happen to have a log containing a backtrace for the case where the sender column is too short? After skimming the code, I would assume SQLAlchemy throws an exception which then gets caught in bin/kolab_smtp_access_policy.py:1717. That's obviously too late.

Ooh, this is a subtle bug!

I guess we can close this?

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.

I have just pushed a new, patched revision of the pykolab package. Please try it out and report back if it fixes the problem for you.

I'll take care of this.

Thanks for reviewing this differential! It needs to be landed by someone with Free/Busy Developers group membership.

Apparently I need to be added to the PyKolab Developers group to be able to land changes.

Thanks for the review! I tried to arc land the changes but seem to lack permission to do so:

Exception: You do not have permission to push to this repository.
fatal: Could not read from remote repository.

I have abandoned D3190 and submitted the individual commits in D3223, D3226, D3229, D3232, D3235, D3241 and D3244.