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.

Superseded by D3223, D3226, D3229, D3232, D3235, D3241 and D3244.

Fixed - better late than never.

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?

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.

Hmm, does Arcanist offer a way to do fast-forward merges?

Superseded by D2548. Turns out the first commit is no longer needed (and I messed up the diff during rebase).

Superseded by D2542.