Re: [Evolution] infinitive wait for network events
I upgraded to 3.8.3 with F19 and network timeout problems got even worse. Marking mailbox as copy folder locally for offline operation stopped taking any effect whatsoever. No message with attachments is loading, staying on Retrieving message 'nn' forever. The same message has already been loaded previously with 3.6.4. Did local storage format change? Eugene. 07.05.2013, 21:25, Adam Tauno Williams awill...@whitemice.org: On Tue, 2013-05-07 at 21:51 -0400, Eugene wrote: On 05/06/2013 05:51 AM, Pete Biggs wrote: For many releases, including the latest in Fedora 18 Please give version numbers for Evolution, not the distro you use - not everyone uses the same distro so they don't know which versions you are talking about. F18 is 3.6.4 I've noticing that evolution does not handle network delays properly. It will spin in wait state indefinitely. Please see included screenshot. I wonder how to diagnose and prevent infinitive waits. The only way to end the process is to to brute force kill signals. This has been talked about before on this list. Yes, it is a known issue, but I seem to remember that the solution requires some other work to be done first. My experience of the issue is that many of the problems stem from looking up contacts on a remote service (so that Evo can decide if it's going to try and display images from the network) - it's not the LDAP code itself that's the problem, more the type of traffic that LDAP generates. So try enabling Never load images from the Internet (you can always explicitly load them with Ctrl-I) to see if it makes it any better. If it is a well known problem I am surprised it is not yet fixed. I believe it is fixed, but not on your version [which is not the current version]. 3.6.x certainly had some connection management issues, at least with HTML messages, and especially behind a proxy server. I have not need these issues on 3.8.x. Not sure about LDAP but load images is not enabled. I do not recall ever seeing connection issues regarding LDAP. Regardless, if any network operation takes more then reasonable time it should either abort itself or allow user to abort it. Agree. Main reason I started this thread is to seek diagnostic help as I clearly stated in my question. I apologize if inline attachment caused problems. It didn't cause any problems, and was fine by me. There are just some people here you are grumpy about attachments [although they use an excellent mail client that handles them gracefully ;) ]. I've been using evolution since early betas and the only reason I still on it because sometimes I must use redirect feature that is missing in thunderbird. But amount of daily problems caused by unhanded timeouts and other glitches makes me question myself if fighting constant issues really worth the trouble If you see constant connection issues and loading of messages for HTML messages is disabled... I suspect there might be something else wrong in addition. It was annoying in 3.6.x, but certainly not debilitating. Any chance there is an overloaded NAT involved that is prematurely terminating your connections? [Die NAT Die! All hail IPv6, our deliverer!] Have your tried running with CAMEL_DEBUG enabled and see if that enlightens you about anything https://live.gnome.org/Evolution/Debugging? But, seriously, 3.8.x is a *MUCH* better Evolution. 3.6.x Evolution and GNOME were pretty good. 3.8.x is excellent and very solid. I know nothing about Fedora [at this point you would have to drag me away from openSUSE in chains - it just @*$*@^* WORKS!] but certainly they provide some reasonable way to update to the latest * * *STABLE* * * version of GNOME. Did I mention that 3.8.x is the current * * *STABLE* * * version of GNOME. If I didn't, I should have. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] infinitive wait for network events
I upgraded to 3.8.3 with F19 and network timeout problems got even worse. Marking mailbox as copy folder locally for offline operation stopped taking any effect whatsoever. No message with attachments is loading, staying on Retrieving message 'nn' forever. Have you followed the debugging hints at https://projects.gnome.org/evolution/bugs.shtml Running Evo from the command line with CAMEL_DEBUG=all might give you sufficient hints as to where the problem is. Alternatively, getting a backtrace when Evo is stuck will give those that know about such things sufficient info to tell you what it is doing at the time. P. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] infinitive wait for network events
I've been using evolution since early betas and the only reason I still on it because sometimes I must use redirect feature that is missing in thunderbird. https://addons.mozilla.org/en-US/thunderbird/addon/mailredirect/ P. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] infinitive wait for network events
Not sure about LDAP but load images is not enabled. I do not recall ever seeing connection issues regarding LDAP. The mention of LDAP came from me - most of the connection issues I had were solved when I stopped Evo from looking up contacts in my remote LDAP address book to see if it should display images. The LDAP address book on its own was fine; the loading of images was fine if I didn't have the LDAP setup; but the two of them together gave lots of problems. Main reason I started this thread is to seek diagnostic help as I clearly stated in my question. I apologize if inline attachment caused problems. It didn't cause any problems, and was fine by me. There are just some people here you are grumpy about attachments [although they use an excellent mail client that handles them gracefully ;) ]. But it wasn't an attachment, it was in-line text; and Evo didn't handle it at all, let alone gracefully; it just displayed the uuencoded data. P. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] infinitive wait for network events
On 05/08/2013 04:31 AM, Pete Biggs wrote: I've been using evolution since early betas and the only reason I still on it because sometimes I must use redirect feature that is missing in thunderbird. https://addons.mozilla.org/en-US/thunderbird/addon/mailredirect/ Does not appear to work anymore and hasn't been updated for a while. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] infinitive wait for network events
On 05/06/2013 05:51 AM, Pete Biggs wrote: For many releases, including the latest in Fedora 18 Please give version numbers for Evolution, not the distro you use - not everyone uses the same distro so they don't know which versions you are talking about. F18 is 3.6.4 I've noticing that evolution does not handle network delays properly. It will spin in wait state indefinitely. Please see included screenshot. I wonder how to diagnose and prevent infinitive waits. The only way to end the process is to to brute force kill signals. This has been talked about before on this list. Yes, it is a known issue, but I seem to remember that the solution requires some other work to be done first. My experience of the issue is that many of the problems stem from looking up contacts on a remote service (so that Evo can decide if it's going to try and display images from the network) - it's not the LDAP code itself that's the problem, more the type of traffic that LDAP generates. So try enabling Never load images from the Internet (you can always explicitly load them with Ctrl-I) to see if it makes it any better. If it is a well known problem I am surprised it is not yet fixed. Not sure about LDAP but load images is not enabled. Regardless, if any network operation takes more then reasonable time it should either abort itself or allow user to abort it. I this case clicking on the red circle next to stuck network operation does not make any effect on the stuck network operation! Several releases ago clicking on the red circle always terminated stuck network operation. Main reason I started this thread is to seek diagnostic help as I clearly stated in my question. I apologize if inline attachment caused problems. I've been using evolution since early betas and the only reason I still on it because sometimes I must use redirect feature that is missing in thunderbird. But amount of daily problems caused by unhanded timeouts and other glitches makes me question myself if fighting constant issues really worth the trouble Eugene. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] infinitive wait for network events
On Tue, 2013-05-07 at 21:51 -0400, Eugene wrote: On 05/06/2013 05:51 AM, Pete Biggs wrote: For many releases, including the latest in Fedora 18 Please give version numbers for Evolution, not the distro you use - not everyone uses the same distro so they don't know which versions you are talking about. F18 is 3.6.4 I've noticing that evolution does not handle network delays properly. It will spin in wait state indefinitely. Please see included screenshot. I wonder how to diagnose and prevent infinitive waits. The only way to end the process is to to brute force kill signals. This has been talked about before on this list. Yes, it is a known issue, but I seem to remember that the solution requires some other work to be done first. My experience of the issue is that many of the problems stem from looking up contacts on a remote service (so that Evo can decide if it's going to try and display images from the network) - it's not the LDAP code itself that's the problem, more the type of traffic that LDAP generates. So try enabling Never load images from the Internet (you can always explicitly load them with Ctrl-I) to see if it makes it any better. If it is a well known problem I am surprised it is not yet fixed. I believe it is fixed, but not on your version [which is not the current version]. 3.6.x certainly had some connection management issues, at least with HTML messages, and especially behind a proxy server. I have not need these issues on 3.8.x. Not sure about LDAP but load images is not enabled. I do not recall ever seeing connection issues regarding LDAP. Regardless, if any network operation takes more then reasonable time it should either abort itself or allow user to abort it. Agree. Main reason I started this thread is to seek diagnostic help as I clearly stated in my question. I apologize if inline attachment caused problems. It didn't cause any problems, and was fine by me. There are just some people here you are grumpy about attachments [although they use an excellent mail client that handles them gracefully ;) ]. I've been using evolution since early betas and the only reason I still on it because sometimes I must use redirect feature that is missing in thunderbird. But amount of daily problems caused by unhanded timeouts and other glitches makes me question myself if fighting constant issues really worth the trouble If you see constant connection issues and loading of messages for HTML messages is disabled... I suspect there might be something else wrong in addition. It was annoying in 3.6.x, but certainly not debilitating. Any chance there is an overloaded NAT involved that is prematurely terminating your connections? [Die NAT Die! All hail IPv6, our deliverer!] Have your tried running with CAMEL_DEBUG enabled and see if that enlightens you about anything https://live.gnome.org/Evolution/Debugging? But, seriously, 3.8.x is a *MUCH* better Evolution. 3.6.x Evolution and GNOME were pretty good. 3.8.x is excellent and very solid. I know nothing about Fedora [at this point you would have to drag me away from openSUSE in chains - it just @*$*@^* WORKS!] but certainly they provide some reasonable way to update to the latest * * *STABLE* * * version of GNOME. Did I mention that 3.8.x is the current * * *STABLE* * * version of GNOME. If I didn't, I should have. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] infinitive wait for network events
On Tue, 2013-05-07 at 22:24 -0400, Adam Tauno Williams wrote: But, seriously, 3.8.x is a *MUCH* better Evolution. 3.6.x Evolution and GNOME were pretty good. 3.8.x is excellent and very solid. I know nothing about Fedora The current release of Fedora (F18) supports Evo 3.6. F19 will support Evo 3.8 when it comes out in the next month or two. poc ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] infinitive wait for network events
I appreciate your response. However the purpose of this list is to make evolution mail client behave property, utilizing any form of bug reports available. Err, no. The purpose of *this* list is to help people with Evolution - the people who do help (like POC and many others) do so in their spare time and, to be honest, anything that puts a barrier in the way doesn't really encourage us to do anything. I suppose the image delivery method should not stop any knowledgeable programmer from opening it. Granted, it would take more then one click to see the image I'm a sysadmin and programmer, and know how to decode encoded things, but its not something I need to do very often. Hence in order to deal with your image I need to install the tools necessary, cut and paste the data into a file, run that file through the decoder, open an image viewer, find and click on the image, then I might know what you are talking about. Yes, it would take more than one click. but inline encoding guarantees that the image is present in archives So would having it as an attached image. forever and isn't at mercy of third party image hosting service. Sometimes we get people who don't know how (or don't think it's important) to reduce the size of an image and the mailing list software rejects the message as too big - then putting on a third party site is the only alternative (and PasteBin isn't an image hosting service). P. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] infinitive wait for network events
For many releases, including the latest in Fedora 18 Please give version numbers for Evolution, not the distro you use - not everyone uses the same distro so they don't know which versions you are talking about. I've noticing that evolution does not handle network delays properly. It will spin in wait state indefinitely. Please see included screenshot. I wonder how to diagnose and prevent infinitive waits. The only way to end the process is to to brute force kill signals. This has been talked about before on this list. Yes, it is a known issue, but I seem to remember that the solution requires some other work to be done first. My experience of the issue is that many of the problems stem from looking up contacts on a remote service (so that Evo can decide if it's going to try and display images from the network) - it's not the LDAP code itself that's the problem, more the type of traffic that LDAP generates. So try enabling Never load images from the Internet (you can always explicitly load them with Ctrl-I) to see if it makes it any better. P. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] infinitive wait for network events
On Sun, 2013-05-05 at 23:33 -0500, Eugene wrote: I suppose the image delivery method should not stop any knowledgeable programmer from opening it. What makes you think that all, or even most, of the members of this list are programmers? If you want to reach Evo developers, this is not the best way to do it. The Evolution Hackers list may be better. And if you are asking for help, making people jump through hoops before they can even understand the question is a losing proposition. poc ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] infinitive wait for network events
Am Sonntag, den 05.05.2013, 23:33 -0500 schrieb Eugene: Hi Patrick, I appreciate your response. However the purpose of this list is to make evolution mail client behave property, utilizing any form of bug reports available. I suppose the image delivery method should not stop any knowledgeable programmer from opening it. Granted, it would take more then one click to see the image but inline encoding guarantees that the image is present in archives forever and isn't at mercy of I haven't been able to see any image here ??? What I see: begin-base64 664 EvoForever.png iVBORw0KGgoNSUhEUgAABZYkCAIAAACVNviJA3NCSVQICAjb 4U/gGXRFWHRTb2Z0d2FyZQBnbm9tZS1zY3JlZW5zaG907wO/PgAAHM5J and so on for maybe 200 lines :-( Is here something wrong ? -- Thomas Prost thomas.pr...@prosts.info ProstsInfo ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] infinitive wait for network events
On Mon, 2013-05-06 at 18:06 +0200, Thomas Prost wrote: I haven't been able to see any image here ??? Is here something wrong ? No, it was just not sent as an attachment file, but encoded and inline. See previous emails in this thread. andre -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] infinitive wait for network events
On Sun, 2013-05-05 at 23:33 -0500, Eugene wrote: Hi Patrick, I appreciate your response. However the purpose of this list is to make evolution mail client behave property, utilizing any form of bug reports available. I suppose the image delivery method should not stop any knowledgeable programmer from opening it. Granted, it would take more then one click to see the image but inline encoding guarantees that the image is present in archives forever and isn't at mercy of third party image hosting service. +1 I *despise* pastebin services; they just created disassociated content. But images can be attached to bugs, and bug referenced by links. -- Adam Tauno Williams mailto:awill...@whitemice.org GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] infinitive wait for network events
On Mon, 2013-05-06 at 10:51 +0100, Pete Biggs wrote: For many releases, including the latest in Fedora 18 Please give version numbers for Evolution, not the distro you use +1 - not everyone uses the same distro so they don't know which versions you are talking about. Even people using the same version of the same distro may be using different versions of *applications* I've noticing that evolution does not handle network delays properly. It will spin in wait state indefinitely. Please see included screenshot. I wonder how to diagnose and prevent infinitive waits. The only way to end the process is to to brute force kill signals. netstat --verbose --program --numeric --tcp That should show network connections. This has been talked about before on this list. Yes, it is a known issue, but I seem to remember that the solution requires some other work to be done first. My experience of the issue is that many of the problems stem from looking up contacts on a remote service (so that Evo can decide if it's going to try and display images from the network) - it's not the LDAP code itself that's the problem, more the type of traffic that LDAP generates. So try enabling Never load images from the Internet (you can always explicitly load them with Ctrl-I) to see if it makes it any better. Wasn't load-images issues resolved in 3.8.x? At least the issue relating the proxy servers [I thought the webkit message component fixed that]. -- Adam Tauno Williams mailto:awill...@whitemice.org GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] infinitive wait for network events
This has been talked about before on this list. Yes, it is a known issue, but I seem to remember that the solution requires some other work to be done first. My experience of the issue is that many of the problems stem from looking up contacts on a remote service (so that Evo can decide if it's going to try and display images from the network) - it's not the LDAP code itself that's the problem, more the type of traffic that LDAP generates. So try enabling Never load images from the Internet (you can always explicitly load them with Ctrl-I) to see if it makes it any better. Wasn't load-images issues resolved in 3.8.x? At least the issue relating the proxy servers [I thought the webkit message component fixed that]. Yeah, but Fedora 18 has Gnome 3.6 and hence Evo 3.6.4 (currently). P. ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
[Evolution] infinitive wait for network events
For many releases, including the latest in Fedora 18 I've noticing that evolution does not handle network delays properly. It will spin in wait state indefinitely. Please see included screenshot. I wonder how to diagnose and prevent infinitive waits. The only way to end the process is to to brute force kill signals. Eugene. begin-base64 664 EvoForever.png iVBORw0KGgoNSUhEUgAABZYkCAIAAACVNviJA3NCSVQICAjb 4U/gGXRFWHRTb2Z0d2FyZQBnbm9tZS1zY3JlZW5zaG907wO/PgAAHM5J REFUeJzt3XlYE9f6B/B3EiBAkER2UBFU3NoqFRUVtXVFVNSKirbVW2217W2r vdpFa7XWfbm1aqu11r2KW23dEMGt14obiLuyWNl3CGQje+b3x2h+KWRiCJkw yPt5eHziZM7MZL45Zw6HWYi4uLjIyEhgt6QLSY29Cegfhg8eTr3AaFgI02Ez TIfNMB3WwmhYC6NhM0yHtTAa1sJo2MyQjkPjboflDFuMGl2tKo3RsAqmw2aY DpthOqyF0bAWRsNmmA5rYTSshdGwmXE6nEbcDoQQQgghhBBCCCEL4RAGQggh hBBCCCGEmgAcwkAIIYQQQgghhFATgEMYCCGEEEIIIYQQagJwCAMhhBBCCCGE EEJNQJN5IgmyIZGo8tTpkyqV0niis7PzqKhoDw/PxtoqRMF02AzTYTNMh7Uw GtbCaNgM02EtjIa1MBo2s2E6OITR7IhElQmJ8QP7DwgObmc8PTv7ScKZ+KgR o7CGNyJMh80wHTbDdFgLo2EtjIbNMB3WwmhYC6NhM9umgxeSNC/UtyeibwQ/ I+uMj99pDy/q54yPn9uT7Ih+EQmJ8SJRZWNvZjOF6bAZpsNmmA5rYTSshdGw GabDWhgNa2E0bGbzdGx2FoZEIrl8+a9HGQ/z8nJjJ025dv2ql6d3UFBQeO8+ PB7PVmupRa1W79yzlyCI6dOmOjk5MbSWF4ZIVJlwJj6iXwQ/6+97s97v27q1 m4ODRqPRajRiheLOOzO67dge0TciITE+KrKh45Q6ne7WnbsEQGj3blwu11Yf 4QVmz3S0Wu3pxCQCICpyuIMDnor1fPZMR6FQfPDJHIIgftq0wcXFxVYfwWpX r13v2ye8sbfCHHumo9Fo9h88RBDEm7GTHB0dbfURXlR2PujcuXcPALq/8goe dJ7LzrXmwOEjBEFMnjgBa40lMB3Wsmc0JEkWl5QAgL+fH0EQNvoELyw715pD vx0lCJgUE4O1xhJMpGObszAyMtIvXb4UHBw0KmrE6FEjj/x22M/X28tLePt2 2sJF89Mz0m2yFgNRVdVfl5PLy8sVSmWlSFQpEimUypzc3P0HDxUXl9CV0uv1 p88kfjJ33vjYKZHRY9/94MNNW36q76oHRUY1bNsbU3zCyYh+EW5Psu+9NzNU IHBzcNDr9SRJkiTpyuWGEMTdd9/jZ2RF9I04dfqkdatQq9VlZWVKpVKr1SoU ihqFQqvVVopEqWlpYomErtSgyCjDT3TMxIXffFtZKbL2U/5jsXYr1XB2SCcn N3fDj5szMjNVKrVEIhFLJCqVWqlUlpaVqdVqulJWpHPt+o23p787ZsLEzVt/ tm5Tjf30y3a6DWv4wi1kh3SeZOesXf/9o/QMqVSaX1CQn58vlUofPkpfu/77 7JwcMwX1ev2Ro79//OncyOix4ybGfvTpf1LTblFv0e26evnqmyV1J7KqJbRD OtVi8bUbKRWVlUqlUlRVJaqqUiqVefn5R47+UVJaSlcKWzY7HXTKy5UqFXXQ USgUWq1WJBLdTLslwYMOPTtEIxaLU1JTK0UipVJZVV39rNYUHP3jWGlpGV0p m3TV6rLJTrbtoc0M1qaD/QE7RFNcUnLwyG+5efk6nU6j0Wg0Gp1OJ5PJnmRn KxQKulLYptmj1kgkqWlpIpFIqVJVV1dXVVUrVar8goLfjx8vLcNaYw4T6djg D7AFBQW3bqUNfG2Ak6NTZWWFUChQq9WBbQJ5PEdvL8+goMDt27fNnv1pYJvA hq+L8uDhw4ysLKVKNWzI4KlvTgEAgbv7oSNH792/zyGIKbGTTJbaun1Hdnb2 6KiowDZtBO7uAODiWu+/cB47fLCBG9+IlEplcHC7M+H9XvXwcOVyNRoNqX+K 1OtdOJxglSpt2r9GlJWcPX/WulVUV1eLJRKdTufv79/tlZcBgMfjpabdKiou BiB69niVriC1YzVabW5e3vZde77/4YflS74xv64PPpmz9YeNZmawLqzGitgO 6Rw/GZ907rxEKl28YP7wIUMAgM93LSoulsvlAODr40NXsL7pbNy8JXZizKgR I2wyOH34t6MfznyPbqvsww7pHD12LCExSSKRLl+yeMO6tQDg4+OzacvW5KtX ORzOZ5/OMVlKr9cv/GZJQWHRtLfffKlzFyAgNzfP38+Xepdu1zUcq1pCO6ST kZH595MnarVqYP/+k2LGA0CLFi1+P37iwcNHBIeY8MY4uoLNvGWzx0FHLJZI pDqd3t/P95WXXgIAHo+Xdut2UXExEBD2Kh50TLNDNJlZj59k56hU6v4R/ag6 0qJFi2MnTj1MTycIYvy4sSZLme+qPTcCOjbZybY9tJnB2nSg2fcH7BDNpb8u X7+RUiOvmfHONF9fXwBwcHAoKi6pqqoigAgODqIriG0a09FkPX6cnZOjUqki +vYdP3YsALRwczt+8tSjjAyCIN4YM4auYDOvNcBMOvUYwqipqbl//96Dhw/u 3b+r0WgM0/l8t169wvLzc9VqlUaj1el0JElKZVKV2hEA+HzXjh07bNi03tWF //9r5XI7de7cKaRTp06d+Xy+iZWZ1aljR6VS1bVLZwAIbNOGmjiwfz8Asl/f PnSlks6e27H1J09Pj/quzphAIGhIcTbQa7XOBKHVaAgAkiT1er1Op9PpdHqd jgeg12obsnB3d3edTicQCgGA6nwAQId27QCgXXCQmYKGHevl6dm6VasZsz54 7royMjPNz2BdWI0bMaPpRA4bKpaIo0eOBAAfH29qolAgAKOwTKpvOiWlpWNG jeJwmL3Vjv2TYjSdUSNGVIvFb4yNBgBq+A8AxkWPJoEcHTWCrlTi2XMlpWXb f9psuF4vwN+/IZthIRa2hIym0759O6VK1TEkBABat2pFTewbHk6SZHivnmYK YssGTB90WrjrdHqBwB0A3J+1Y+3aBZNABgcFmSmI0QDD0bQLDlapVCEdOgBA q4AAamKf8N4kkL160tYa812150ZAxyY72T6HNgMWpgPYHwAAhqPpE95bJpf3 j+gHAM7Pjuy+Pj4ApPeznptJ2KYBw9EEBwWpVKoO7dsDQEDA075WeO9eJJC9 wsLMFMRaQ7FtOvUYwuByud4+3h11Hdzd3XQ6DTy9LIuoLBfpdbrCwkKSJIEA 6tJ6eU2NUvl013t6evj7+vn5+xgtihPg7+cudOdy6x2PVqt1c3MbNmRwremd O3Xq3KlTWXm5Uql0dnauW7Brly7L16yZNWNG504da11Utu77DVevXZfKZK0C /L+YO7drl8679v565+69Df9dS82wat1/XV1c53z870GRURcTEwBg0ltTw3q8 eu/+g/KKCm8vz3lz5rwa2h0ASJL84/iJo8eOFxUXU2Wp+Y0ZFlLrvxlZWVu3 bc98/LhFC7fIoUOnT5ta351jIa1GwyEIIAjqHJ6n3yCdTq/TNWSxGo1Go9X6 1/kNytfXx9fXRyKRaDQaSwYUdTqdIUGSJA8cPnIy/rRMLu/dM2z2vz8UCATZ OTkz3v8Qnp0EtfLbJX37hE+e9q8eoaGXLicHtmm9ZeMGMNqxJhdidcRMYygd pVLp5emx+KsFtaa7urq6uroqlUqdTmfJBeTPTWfcxFgAGB87BQAWfvlFr55h daMxWRDoq4DhbLfWrVrN+3R2aLduYJSvPZNiKJ0ahaJlS+GKOqPyPcN69Azr UVxSolAoTN4XI+n8+Vkzppu535DJXUe3/1Uq1Y49ey8nX5FIpaHdXlny9ULj W6X8eenSnn1x361e6eHhYZOW0OYYSken0/H5/NcG9K81vWNIh44hHcorKpQq lbMFt3xqzi0bcwcdtVptOO3IwNfHx9fHRyKV4kHnuZisNa7Ur2HGQjq0D+nQ vryiQqVSmWy46LpqJiPQaDS/7Nx18X+XSCBfHzBg1nvvOjk6AoCZaKxusuoe 2ujWbkNsS6fucpptf4ChaBQKhbOz87vv/KvWdIHAXSBwr6mp0Wq1ltzCDNs0 RmqNq2tE3761poe0bx/Svn1FRSXWGkvYMJ36XUii0WoVCmW1uEr7bKSEAJDX yD1JD5lcrtPpAEAobAkAJAlSmYwkSYIg+Hy+k7OjTqc3LIckQa/Xg56s7+YC QPLVqzKZvG94uIdHy1pvPXyUvmT5ilYB/t+vW1u34MIvP/95+465X8739vIa Fz16xPBhrq6u1Ft9evcaM3qUG5+fePbcuu837Nq2NXLo0F/jDpRXVHh7eanV 6r+Sk9evWW28tPKKiraBgSOGD/Pz8T1z9uz6TT/8unM7ACQkJh04fGTenNmB gW1ycvMWmrqMnM7qdd9NmhCz4IvPlEqlUqmq126pF61GQxAEEARQXyBqHEyr 1TWsep+MPy2WSKIih/v51u5QFhYV/XH8REuh8K0pk02WFYvFJEnqSfJJds62
Re: [Evolution] infinitive wait for network events
On Sun, 2013-05-05 at 13:53 -0500, Eugene wrote: For many releases, including the latest in Fedora 18 I've noticing that evolution does not handle network delays properly. It will spin in wait state indefinitely. Please see included screenshot. I wonder how to diagnose and prevent infinitive waits. The only way to end the process is to to brute force kill signals. Eugene. begin-base64 664 EvoForever.png iVBORw0KGgoNSUhEUgAABZYkCAIAAACVNviJA3NCSVQICAjb 4U/gGXRFWHRTb2Z0d2FyZQBnbm9tZS1zY3JlZW5zaG907wO/PgAAHM5J Please: 1) Learn how to send screenshots in email for when you need to do that (hint: send as an attachment), BUT 2) Don't send screenshots directly to the list but to pastebin.com or a similar service, then post the URL. poc ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] infinitive wait for network events
Hi Patrick, I appreciate your response. However the purpose of this list is to make evolution mail client behave property, utilizing any form of bug reports available. I suppose the image delivery method should not stop any knowledgeable programmer from opening it. Granted, it would take more then one click to see the image but inline encoding guarantees that the image is present in archives forever and isn't at mercy of third party image hosting service. Eugene. 05.05.2013, 14:20, Patrick O'Callaghan p...@usb.ve: Please: 1) Learn how to send screenshots in email for when you need to do that (hint: send as an attachment), BUT 2) Don't send screenshots directly to the list but to pastebin.com or a similar service, then post the URL. poc ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
