On Mon, 27 Jul 2020, Sandro Tosi wrote:
On Thu, 28 May 2020 13:56:59 -0400 (EDT) Scott Talbert <s...@techie.net> wrote:
On Tue, 26 May 2020, Jonathan Dowland wrote:
archivemail seems to be a good candidate to RM due to dead upstream.
However, it still has a relatively high popcon, so people seem to be using
it.
I'm willing to take a stab at porting to Python 3 if anyone is available to
test it? The port effort doesn't look that bad at first glance, but I
don't use this package.
I'm happy to test anything you produce, but I'd warn you that I think
it's quite a significant piece of work. From what I remember when I last
looked at hacking a feature into it (#736327), archivemail uses the
older of two different APIs provided by the python "mailbox" library,
and only the newer one was carried forward to Python 3. So moving away
from that older API is a big part of the work.
You were right. This was harder than I expected. :) Mainly it is
exactly as you described - the rfc822.Message class (which doesn't exist
in Python 3) does not map exactly to the email.message.Message class. I'm
stuck at the moment with figuring out how to calculate the message size.
In rfc822.Message, you could access the file handle directly and get the
size that way.
do you have any plan on completing this port? I'm not a user of
archivemail but it looks like it should be removed, not salvaged:
* no new upstream releases since 2011 (!)
* last upload to debian in 2014
* retired from fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1777616
maybe it's time to let it go?
If i dont hear otherwise in a week, i'll file for its removal
No, I kind of gave up. It did turn out to be harder than I expected, and
some of the APIs in the older email APIs don't exist in the new ones, so
it wasn't clear what to do there.
I would say it can go, but I don't use it so my opinion doesn't matter
much.
Scott
