Note that all changes I have made so far should™ be backward-compatible with Python >= 2.6, so they wouldn't necessitate any changes to our existing packaging.

Could you create differential(s)? It should be possible to do this having patches via https://git.kolab.org/differential/diff/create/. Or just by using arc diff on your git clone.

Submitted D3190, which has ended up being sort of... bulky. There are several commits in this differential; does Phabricator offer no option to review these commits individually like Git{Hu,La}b do, without the author having to create a separate differential per commit?

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

Thanks for the excellent work @sicherha!

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.

Please make sure you have the correct access rights
and the repository exists.

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

In T6805#94630, @sicherha wrote:

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

Done

some module names changed in python3 D3355

gettext.lgettext removed in 3.10 D3367

gettext.lgettext become deprecated since version 3.8, removed in version 3.10.

gettext.l....
"Warning: These functions should be avoided in Python 3, because they return encoded bytes. It’s much better to use alternatives which return Unicode strings instead, since most Python applications will want to manipulate human readable text as strings instead of bytes. Further, it’s possible that you may get unexpected Unicode-related exceptions if there are encoding problems with the translated strings." from https://docs.python.org/3.8/library/gettext.html

some manuals of interest:
Cheat-Sheet: Writing Python 2-3 compatible code:
https://python-future.org/compatible_idioms.html

That is the main work in my opinion:
Strings and bytes!
Unicode (text) string literals vs Byte-string literals
https://docs.python.org/3/howto/pyporting.html#text-versus-binary-data

D3391 based on:
https://python-future.org/compatible_idioms.html#imports-relative-to-a-package

[Python 3]basestring to six string_types D3403

make compability to python3 and equality to pykolab code as exist in pykolab/utils.py for example.

external cyruslib.py not python3 compatible.

kolabformat is only packing python2 libraries, used by wallace

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

The kolabformat Python module is provided by the libkolabxml repository. It is auto-generated by SWIG, so getting Python 3 bindings as well should hopefully be relatively easy.

sqlalchemy.interfaces.PoolListener in pykolab/telemetry.py is deprecated since v0.7 and removed in v1.4
gettext.lgettext is removed in Python v 3.10

In new Ubuntu 22.04 LTS both functions/methods are not available.

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

Hi,

I looked into python3 support on centos 8, but I believe we'll have to update the OBS first to get support for modular support.
I'll look into that over the coming weeks and will then look into getting everything up to pykolab python3 ready and packaged.

Thanks for spearheading the python3 transition!

FWIW, current pykolab master now runs with under python3 on centos8 at least. I'm sure there are still some rough corners, but most part should be working.

It's not currently fully backwards compatible to python2 though.

with D3884 D3863 D3710 some rough corners should work again.
as "/Personal Calendar" "/Personal Contacts"

tested git version: kolabd kolab-cli kolab-saslauthd

• with Python3 debian (buster and bullseye), Ubuntu (22.04 LTS) :
• with python 2.7 debian buster

still not tested wallace and bin dir policy and telemetry skripts