Created attachment 692938 [details] Partial Screenshot of Evolution showing the EWS account with no folders Description of problem: Last week, (running Evolution 2.6.2, EWS 2.6.1), everything worked fine. This morning I started up Evolution 2.6.2, EWS 2.6.1 and no folders were displayed. (see attached image) I deleted the account and recreated it. Everything is fine. I then updated Fedora 18 and because Evolution was included, I decided to reboot the machine. When the machine came up, I logged in and started Evolution 2.6.3, EWS 2.6.3. Again it did not show the folders from Exchange (same as picture mentioned above). Version-Release number of selected component (if applicable): evolution-2.6.2 and evolution-ews-2.6.1 evolution-2.6.3 and evolution-ews-2.6.3 How reproducible: Start Evolution, look at list of folders. Steps to Reproduce: 1. Start Evolution 2. Look at list of folders 3. Actual results: No folders displayed under EWS account No events visible in Calendar Expected results: Normal list of folders under EWS account. Usual events in Calendar. Additional info:
Just now I closed Evolution and restarted it. Now all the folders are there. I guess now we wait until tomorrow when I boot the machine and start Evolution fresh. See if it is still ok or if it fails to show the folders again.
I forgot to mention in my last comment that, even though the mail folders were showing, the none of the calendar entries were visible. Not the EWS entries, not the local entries, not Google calendar entries. I received a meeting attendance request and, magically, all my calendars started displaying.
Thanks for a bug report. I suggest to run evolution from a terminal, with EWS debugging on, thus it'll show what's going wrong. You can do that with this command: $ EWS_DEBUG=2 evolution but, I guess this has something to do with the way you connect to your Exchange server. Is you server hidden in a corporate VPN, or requires other special connection abilities/steps to be reachable? Another issue can be a password prompt, that a background process failed to get to your password (the calendars and the like are managed by evolution-source-registry in 3.6.x (you've typo in the version)). If it's about password prompt, then it might be bug #828321.
Before I describe what happened today, I should probably describe my setup. I'm running Fedora 18 on an HP EliteBook (laptop). The company I work for uses Microsoft's Office 365 (outlook.com) as the Exchange server. I have 3 local calendars, 1 Exchange calendar, and 1 Google calendar (from my phone, Android all the way :-). I booted the machine this morning and started evolution with the command you requested. This time the mail folders displayed just fine, but none of the calendars displayed. The new messages included a meeting attendance request to be added to my Exchange calendar. I accepted the request, but the calendars still didn't display. I exited evolution, gathered up the output in the terminal and saved it to a file. and cleared the terminal. I restarted evolution with the same debugging command. This time the mail folders are shown and the calendars are shown. I exited evolution and saved the terminal output to a different file. I restarted evolution with the same debugging command. Now the calendars are not shown. I exited evolution and saved the terminal output to a different file. I restarted evolution with the same debugging command. Now the calendars are shown. The two times that the calendars were shown were when evolution started after it had been shut down with the calendars displayed. I have files of the output from the first three runs. I search through them for my exchange password and didn't find it. I have not looked much closer to them. Is there any info in them that would be helpful to you? (I will hang on to them as long as you need me to.)
Any critical warnings might be useful. The command logs only evolution's activity, which is basically what email does. The calendar activities reside in evolution-calendar-factory process, but the main "is the calendar shown or not" is led by evolution-source-registry, which lets know all its clients what sources are currently available and notifies them about changes. That you once see the calendar and the other time not is strange. If I got it right, you open evolution in the Mail view (evolution -c mail), then you switch to Calendar view and the exchange calendars are missing. Then you close evolution, and run it, which will open it in Calendar view (like evolution -c calendar), and then the exchange Calendar is there. Then you switch to Mail view and close evolution. And the next start the trip repeats. Is it correct?
Your scenario of what I am doing is correct, but when I switched to the Calendar view not just the exchange calendar was missing, all the calendars were missing, even the local and Google calendars. This morning I booted the machine and started evolution in mail view. It started up and the mail stuff looked fine. I switched to calendar view and all the calendars were there so I don't know what is going on. Here are the messages that I found in the three files: From the first file (open in mail switch to calendar): ... skip bunch of XML ... (evolution:3949): IBUS-WARNING **: Unable to connect to ibus: Could not connect: Connection refused ... skip more XML ... (evolution:3949): Gtk-WARNING **: EAttachmentBar 0x2c2e5b0 is mapped but not visible (evolution:3949): Gtk-WARNING **: EAttachmentBar 0x2c2e5b0 is mapped but not visible (evolution:3949): Gtk-WARNING **: EAttachmentBar 0x2c2e5b0 is mapped but visible=0 child_visible=1 parent GtkBox 0x7f8cc802dac0 mapped=1 (evolution:3949): Gtk-WARNING **: EAttachmentBar 0x2c2e5b0 is mapped but not visible (evolution:3949): Gtk-WARNING **: EAttachmentBar 0x2c2e5b0 is mapped but visible=0 child_visible=1 parent GtkBox 0x7f8cc802dac0 mapped=1 ... ends with more XML ... From the second file (open in calendar switch to mail): ... skip some XML ... (evolution:5532): IBUS-WARNING **: Unable to connect to ibus: Could not connect: Connection refused ... skip the rest of the XML ... (evolution:5532): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (evolution:5532): GLib-GObject-CRITICAL **: g_object_unref: assertion `object->ref_count > 0' failed From the third file (open in mail switch to calendar): ... skip some XML ... (evolution:5953): IBUS-WARNING **: Unable to connect to ibus: Could not connect: Connection refused ... skip the rest of the XML ...
If all of them, then it might seem like an issue with communication between evolution and evolution-source-registry, though I would expect the same issue in Mail view too. I think the problem is when the evolution-source-registry is run. If it's run "too early" after boot, then it can be related to bug I mentioned in comment #3. About the warnings, the ibus one seems to be about input methods or something around that - most likely unrelated to our problem, at least directly unrelated. Those about EAttachmentBar are introduced in gtk3 3.6.x, some validation, but nobody told me what that is about the last time I asked (approximately not more than two weeks ago), though they seem harmless, as they only do some validation on widgets (eating CPU). Those g_object_unref(), hmm, I see them from time to time too, but very very very rarely. Nothing I even tried to reproduce or hunt. I think, the next time you'll get to this issue, close evolution, and kill all the evolution* processes, I think 'pkill evolution' takes them all down, or just do 'ps ax | grep evolution' and 'kill -9 PID' one after another, with the source registry as the first (thus it'll be re-run when gnome-shell restarts evolution-calendar-factory). Then the process should be running properly, when the parts it depends on are fully initialized. I'm sorry for such vague hints, but I've not much idea what can be wrong here, except of the things I already mentioned. And, sadly, it doesn't do that on my machine, while I use evolution-ews too.
Ok. This morning I booted the computer, logged in, and started evolution. It came up with no mail folders, but all the calendar entries were fine. I shut it down, killed all of the evolution* processes, then restarted it. Now everything is fine.
I just recalled, maybe you face the same, sometimes, there happens that I run evolution with one of the evolution-ews folders being selected from the last session, but there are suddenly no folders. The only way is to close evolution and run it away, ideally with other than EWS folder being selected. The console is full of critical warnings about enum types and such. I know when it started [1], but I do not know what's behind it. [1] https://bugzilla.gnome.org/show_bug.cgi?id=681837
For the last few days, it seems to be working fine. I normally exit evolution with one of the EWS folders selected and I generally don't have the problem you mentioned.
I have the exact same problem. (In reply to comment #9) > I just recalled, maybe you face the same, sometimes, there happens that I > run evolution with one of the evolution-ews folders being selected from the > last session, but there are suddenly no folders. The only way is to close > evolution and run it away, ideally with other than EWS folder being > selected. The console is full of critical warnings about enum types and > such. I know when it started [1], but I do not know what's behind it. > > [1] https://bugzilla.gnome.org/show_bug.cgi?id=681837
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.
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.