Created attachment 678064 [details] stderr output Description of problem: After some updates last week evolution is unable to fetch email from the exchange server. Version-Release number of selected component (if applicable): evolution-ews-3.6.1-1.fc18.x86_64 How reproducible: always Steps to Reproduce: 1. start evolution 2. click on a message 3. Actual results: i get the message Retrieving message 'AAMkAGY0MTIyZTQ3LTY1Y2YtNGZiMC05MWMwLTMwMmIyZWIyMzNiYQBGAAAAAAC/kaQYQakVRKRN5HMzMg+7BwCrWVoMAzYATKwqb0KuBWQxAAACHYfQAACj1fQf1yKrTr9n9xJ595X0AABAXb2dAAA=' and nothing more. No indication of work being done. No CPU load. No timeouts. I can continue using evolution, and my other email accounts (google and another imap account) work fine. Expected results: Additional info: i see no evolution packages in yum.log around the time this stopped working, but some gnome packages got updated. could that be relevant? i'll append stderr output from evolution.
Thanks for a bug report. It would be good to know how this happened. I'm pretty sure the issue is with: > (evolution:6687): libeews-CRITICAL **: e_ews_connection_new: assertion > `uri != NULL' failed Then the rest is just caused by this. Do you have configured your EWS account through Gnome Online Accounts, or directly in Evolution? If the later, please try to open Preferences of the EWS account, by right-clicking its name in the folder tree on the left, and go to Receiving Email tab and click Fetch URL button, which should re-initiate the url in settings, thus then confirm the change with OK and restart evolution (not necessarily needed, but just in case). Also, could you provide output of: $ rpm -qa | grep evolution | sort please?
It was defined directly in evolution on f17, then upgraded to f18 beta. It worked fine until recently. I removed the definition in evolution and defined in GOA instead. Worked fine :-) If it is possible to fix this in a more user friendly way that would be very nice. evolution-3.6.2-3.fc18.x86_64 evolution-data-server-3.6.2-3.fc18.x86_64 evolution-ews-3.6.1-1.fc18.x86_64 evolution-help-3.6.2-3.fc18.noarch evolution-mapi-3.6.2-1.fc18.x86_64 evolution-pst-3.6.2-3.fc18.x86_64
Hmm, there might break the configuration then, for some reason I cannot figure out. A simple recreate of the account, even from within evolution itself, will fix it the same as entering it in Online Accounts. I'm not sure how to fix this internally, basically because of an unknown cause. The warnings on console are there for cases which "should not happen", but if they do, then people are notified at least by this way. These messages are usually useful for developers only, regular users may not understand them much (that's why they are on console, form my point of view). That said, there is not much to do if not known what happened. It could be anything like unexpected system crash, an update of some package, or even an update of evolution related packages, running migration code which broke it - though it's pretty unlikely. Your list of packages looks fine to me.
@birger Mine just stopped working with a similar problem... I can't authenticate anymore and I have been fine for awhile. What settings did you use in GOA to get it to work? I'm on exchange 2010 sontek@beast$ rpm -qa | grep evolution | sort evolution-3.6.3-2.fc18.x86_64 evolution-data-server-3.6.3-2.fc18.x86_64 evolution-ews-3.6.3-2.fc18.x86_64 evolution-mapi-3.6.3-2.fc18.x86_64
sontek@beast$ EWS_DEBUG=2 evolution The request headers <?xml version="1.0" encoding="UTF-8" standalone="no"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><SOAP-ENV:Header><types:RequestServerVersion xmlns:types="http://schemas.microsoft.com/exchange/services/2006/types" Version="Exchange2007_SP1"/></SOAP-ENV:Header><SOAP-ENV:Body xmlns:messages="http://schemas.microsoft.com/exchange/services/2006/messages"><messages:SyncFolderHierarchy xmlns="http://schemas.microsoft.com/exchange/services/2006/types"><messages:FolderShape><BaseShape>AllProperties</BaseShape></messages:FolderShape></messages:SyncFolderHierarchy></SOAP-ENV:Body></SOAP-ENV:Envelope> > POST /ews/exchange.asmx HTTP/1.1 > Soup-Debug-Timestamp: 1362544105 > Soup-Debug: SoupSessionAsync 1 (0x2f183f0), ESoapMessage 1 (0x2b1d3c0), SoupSocket 1 (0x7febac005030) > Host: exg6.exghost.com > User-Agent: Evolution/3.6.3 > Connection: Keep-Alive > Content-Type: text/xml; charset=utf-8 > > <?xml version="1.0" encoding="UTF-8" standalone="no"?> > <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><SOAP-ENV:Header><types:RequestServerVersion xmlns:types="http://schemas.microsoft.com/exchange/services/2006/types" Version="Exchange2007_SP1"/></SOAP-ENV:Header><SOAP-ENV:Body xmlns:messages="http://schemas.microsoft.com/exchange/services/2006/messages"><messages:SyncFolderHierarchy xmlns="http://schemas.microsoft.com/exchange/services/2006/types"><messages:FolderShape><BaseShape>AllProperties</BaseShape></messages:FolderShape></messages:SyncFolderHierarchy></SOAP-ENV:Body></SOAP-ENV:Envelope> < HTTP/1.1 401 Unauthorized < Soup-Debug-Timestamp: 1362544105 < Soup-Debug: ESoapMessage 1 (0x2b1d3c0) < Server: Microsoft-IIS/7.5 < Set-Cookie: exchangecookie=91d001b3df0341ebb0a022ae588838e2; expires=Thu, 06-Mar-2014 04:30:14 GMT; path=/; HttpOnly < WWW-Authenticate: Negotiate < WWW-Authenticate: NTLM < X-Powered-By: ASP.NET < P3P: CP="CAO PSA OUR" < Date: Wed, 06 Mar 2013 04:30:13 GMT < Content-Length: 0
The first Unauthorized is fine and is usually there, but there should follow the second, which may use a password. I can think of various issues, like gnome-keyring not providing the password for some reason, evolution-source-registry being busy with other account password prompt, making starve the ews account password prompt, or even a system update brought in a package which has some regression (ews doesn't have many dependencies, it's using libsoup, and it uses glib2 and glib-networking; dependencies of these packages are not much know to me currently).
Just had this happen to me on F19 as well - ie. Evo seems to forget the uri or some such - but I was also able to work around it by removing the account from g-o-a and then readding it again
Hmm, can it be that gnome-online-accounts forgot the URL and evolution updated its sources based on it?
I don't think so - I've had this happen again and this time I was able fix it by simply removing all evolution's config: rm -rf ~/.local/share/evolution ~/.config/evolution ~/.cache/evolution and restarted evo and it worked. I'm thinking that perhaps evo has the sources files open or something but then it doesn't shut down cleanly and so the settings become lost - I had a look into it a bit more and in one instance most of the settings were retained (under ~/.config/evolution/sources) but not the various URLs - hence the error when reopening evolution)
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This is working in Fedora 20 now.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.