Hi, Plese understand I am not the upstream but I am a package maintainer who is acting as a messanger between you and him.
When the upstream thinks it is resolved by the newer version, unless we have a hard fact proving otherwise, it is very unlikely for us to change his mind. On Fri, Nov 18, 2011 at 08:32:53PM +0100, Roland Koebler wrote: ... > No, all these changes don't affect the problem. ... > No, it isn't. The changes are completely independent of this problem. I see. You may convinced me here but I still do not have a hard fact to be presented to the upstream. I need confirmation of bug under the latest version. > Ok, here's some more explanation: Yes, this is very helpful for upstream to understand the issue. > The problem is in the class POP3RetrieverBase, function _getmsglist, > in the two lines > response, msglist, octets = self.conn.uidl() > and > response, msglist, octets = self.conn.list() > > Both lines connect to the POP3-server and get a list of messages. > Now, the problem is, that the code assumes that the the 2nd (later) > call gets the *same* msglist from the server as the 1st call. If the > server returns a different msglist on the 2nd call, a few lines later > (in "self.msgsizes[self.msgid_by_msgnum[msgnum]] = msgsize") a > KeyError occurs. So this is a simple race condition bug. [1] > > And my patch solves this race condition. > > > [1] Additionally, Yahoo sometimes seems to behave strangely, so that > this "race condition" occurs all the time until a new mail arrives > in the Yahoo-POP3-mailbox. So, there's probably a bug in the Yahoo > POP3 server, too. If this "race condition" can be reproduced with detailed analisys, the upstream will be convinced easily. I guess this may be due to thier spam filter logic. On Google service, I vaguely recall seeing some mails come up on web screen of inbox then disapears to spam box. Yahoo may not be all that different. In order to analyze this, it may be interesting to make copies as first (response, msglist, octets) as (response1, msglist1, octets1) = (response, msglist, octets) and check if the second (response, msglist, octets) matches with this, at least, whene it hit this funny condition. Without this, upstream may call this very rare case and bug of Yahoo. If you do, upstream will be convinced. Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
