[Evolution] Bug#638936: Bug fix for 3.0.3: Re: Bug#638936: Stability of evo?

[Svante Signell]

On Tue, 2011-10-11 at 08:12 +0200, Milan Crha wrote:
> On Tue, 2011-10-11 at 08:03 +0200, Svante Signell wrote:
> > On Tue, 2011-10-11 at 07:55 +0200, Yves-Alexis Perez wrote:
> > > On mar., 2011-10-11 at 07:51 +0200, Svante Signell wrote:
> > > > The remaining hang problems with 3.0.3 is now claimed to be solved
> > > > upstream, see below. Do you think it is possible to get an updated 3.0.3
> > > > until 3.2.1 is out? 
> > > 
> > > 3.0.3 has been uploaded to unstable on sep 2 and migrated to testing on
> > > sep 13.
> > 
> > Yes, but the patch for bugzilla bug 660615 is not included in upstream
> > 3.0.3, it is only checked in to 3.2.1 and 3.3.1 sources, see the log
> > messages in the previous mail. That's the reason for my question. I
> > changed the Subject for clarity.
> 
> 	Hi,
> to be honest, the patch from the aforementioned Gnome's bugzilla bug was
> rather about "when I press 'cancel', I want to cancel the current POP3
> operation", than about stability as such. Nonetheless, creating a test
> package for Debian will give you at least an opportunity to cancel stale
> POP3 operation. I would tell more, but the linked pastebins are gone in
> your debian bug, so I cannot verify. Still, this can be just a
> workaround, instead of fixing the issue of "why it hang at all". (I do
> not recall precisely what we found, was it about server not responding
> for an unknown reason and evolution waiting for the reply from it?)

This is what I have from you earlier as a response to the backtrace:
(So it looks like the hang would still be there, even with the cancel
patch (and in 3.2.x, master)! Should I reopen 660615?)

--- Comment #1 from Milan Crha <mcrha at redhat.com> 2011-10-03 07:43:36
UTC ---
Thanks for a bug report. The backtrace shows the POP3 is waiting for a
greeting reply of your server, which takes long for some reason. But
looking into the backtrace more closely I see that the POP3 provider
doesn't use the cancellable into subsequent calls, thus it cannot be
cancelled on user's wish. I see it's still the same in 3.2.0 and git
master, thus I'm confirming this.