Martijn Pieters | 1 May 17:23 2003

Re: offlineimap rev 467

On Tue, Apr 29, 2003 at 11:30:32AM -0500, Automatic Subversion Change Mailer wrote:
> Log:
>   * When sep was /, the new Maildir support code would recursively try to 
>     scan ., resulting in huge paths and an eventual crash.  Fixed with
>     a one-line patch to Maildir.py.

Thanks John, this patch works for me and saves me filing a bug report. :)

--

-- 
Martijn Pieters
| Software Engineer  mailto:mj <at> zope.com
| Zope Corporation   http://www.zope.com/
| Creators of Zope   http://www.zope.org/
---------------------------------------------

John Goerzen | 6 May 15:51 2003

OfflineIMAP 3.99.16 released

From the changelog:

offlineimap (3.99.16) unstable; urgency=low

  * This is a 4.0 TRACK release, and may be unstable or in flux!
  * When sep was /, the new Maildir support code would recursively try to 
    scan ., resulting in huge paths and an eventual crash.  Fixed with
    a one-line patch to Maildir.py.  Fixes [complete.org #60].
    Closes: #191318.
  * Added some significant debug code to folder/IMAP.py when saving a new
    message with APPEND.  This should make it easier to track down bugs both
    in OfflineIMAP and in mail servers that implement this poorly.
  * Fixed adding of X-OfflineIMAP header when the message starts out with
    no headers.  (This should not generally occur.)  This should help
    with some "invalid literal for long()" problems.

John Goerzen | 6 May 16:29 2003

OfflineIMAP 3.99.17 released

offlineimap (3.99.17) unstable; urgency=low

  * Fixed two potential obscure race conditions in folder/Maildir.py.
    + Condition 1 involved the gettimeseq() function.  This function
      accesses per-module variables but does not have a lock.  It may have
      been possible for this to have been called in such a way that timeseq
      was not properly updated.
    + Condition 2 involved the call to gettimeseq().  Since the timeseq is
      based on the system clock, we now use the time as reported inside
      timeseq() rather than outside.  This way, we can be assured that the
      same value is in use both places.
  * Added debug code to savemessage in folder/Maildir.py to try to track
    down a mysterious 0-length file bug.

Jean Jordaan | 12 May 22:18 2003
Picon

AttributeError: 'NoneType' object has no attribute 'StringTypes'

Hi all

I'm trying out OfflineIMAP for the first time. I got it to start syncing,
and it did fine for about 132 messages. Then it stopped like so:

jean <at> klippie jean $ offlineimap -u Curses.Blinkenlights
Thread 'Copy message 104613 from INBOX' terminated with exception:
Traceback (most recent call last):
   File "/usr/lib/python2.2/site-packages/offlineimap/threadutil.py", line 153, 
in run
     Thread.run(self)
   File "/usr/lib/python2.2/threading.py", line 396, in run
     apply(self.__target, self.__args, self.__kwargs)
   File "/usr/lib/python2.2/site-packages/offlineimap/folder/Base.py", line 272, 
in copymessageto
     message = self.getmessage(uid)
   File "/usr/lib/python2.2/site-packages/offlineimap/folder/IMAP.py", line 109, 
in getmessage
     return imapobj.uid('fetch', '%d' % uid, 
'(BODY.PEEK[])')[1][0][1].replace("\r\n", "\n")
TypeError: unsubscriptable object

No debug messages were logged for Copy message 104613 from INBOX.
Unhandled exception in thread:
Traceback (most recent call last):
   File "/usr/lib/python2.2/threading.py", line 415, in __bootstrap
     s = _StringIO()
   File "/usr/lib/python2.2/StringIO.py", line 53, in __init__
     if type(buf) not in types.StringTypes:
AttributeError: 'NoneType' object has no attribute 'StringTypes'
(Continue reading)

John Goerzen | 15 May 05:31 2003

Development status; looking for some help

Hello,

You may have noticed that there's been little activity on OfflineIMAP the
past week.  Truth is, things have been very hectic over here and I just
haven't had the time.

Which brings up another point: OfflineIMAP is getting to take up too much of
my time.  The time I spend chasing down bugs that other people have, adding
features others request, etc. is starting to be too much.

I'd like to hear from you, the OfflineIMAP community, about solutions and
suggestions.

Here are some brainstorms to get us started.  Note that mentioning something
here does not necessarily intend to state that I like the idea.

 * Get more people actively involved with coding.

 * Have some "mentors" work with incoming bug reports, doing triage,
   gathering  information, and hopefully tracking down the problem -- even
   if they can't actually fix it.

 * Have a set of expert users who use OfflineIMAP in a variety of
   configurations and are capable of detailed bug tracking or basic Python
   coding.

 * Find some option to provide monetary support for OfflineIMAP so I can do
   the above personally.

My preference is #1 -- I'd be pleased to find some more active coders out
(Continue reading)


Gmane