User Details
- User Since
- Feb 4 2016, 9:02 AM (327 w, 4 d)
Sun, May 8
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.
Apr 10 2022
@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.
Mar 20 2022
Wait - so somewhere, someone tries to call debug() with a level argument that has the type TypeError? That doesn't sound right at all...
Mar 16 2022
Mar 15 2022
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().
Mar 14 2022
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.
Mar 13 2022
Mar 12 2022
Looks good to me, thanks!
Mar 11 2022
Thanks a lot! See D1966 for my review comments.
Mar 6 2022
Feb 13 2022
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.
Feb 7 2022
Thanks for the diff!
Feb 6 2022
Feb 4 2022
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.
Feb 3 2022
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.
Jan 19 2022
Thanks for reviewing this differential! It needs to be landed by someone with Free/Busy Developers group membership.
Jan 11 2022
Jan 10 2022
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.
Jan 8 2022
Jan 6 2022
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.
Oct 24 2021
Jun 4 2021
May 24 2021
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).