*** Bug 683855 has been marked as a duplicate of this bug. ***

Just for a record, the above bug fails in LDAP authentication.

My theory is that the evolution-alarm-notification starts calendar and book factories, but too early, thus something is not initialized yet, probably the gnome-keyring, thus since then authentication fails. By restarting factories the gnome-keyring daemon is running, thus the authentication works. The book factory is run by the calendar factory for the Birthdays & Anniversaries calendar.

Is this just with 3.4 or with 3.5 as well?

I would think the centralized authentication in 3.5 would solve this quite well.  The gnome-keyring calls made from the registry service should activate the keyring daemon if needed, so I don't think there's such a thing as starting too early.

Reports are from 3.4.x only, and I had hard time to reproduce it, as it did it for me about 1 of 5 relogins. I meant with gnome-keyring initialization its unlocking, as I believe the daemon is run properly after start, only the keys are not unlocked yet. But I can be completely wrong. Let's see how 3.6.x will behave.

I've just discovered this in my .xsession-errors file:

e-data-server-ui-Message: Unable to find password(s) in keyring (Keyring reports: No matching results)
** Message: already started, ignoring error
** Message: already started, ignoring error
Gtk-Message: Failed to load module "canberra-gtk-module"

Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x2a0000b (Messaging )
Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed.

(gnome-shell:3105): eds-WARNING **: edsf-persona-store.vala:2078: Error in address book view query: GDBus.Error:org.gnome.evolution.dataserver.AddressBook.OtherError: LDAP error 0x32 (Insufficient access)

(gnome-shell:3105): eds-WARNING **: edsf-persona-store.vala:2088: Error is considered unrecoverable. Removing persona store.

(gnome-shell:3105): folks-WARNING **: Failed to find primary PersonaStore with type ID 'eds' and ID '1347438902.4516.0@mordor'.
Individuals will not be linked properly and creating new links between Personas will not work.
The configured primary PersonaStore's backend may not be installed. If you are unsure, check with your distribution.

(In reply to comment #5)
> (gnome-shell:3105): eds-WARNING **: edsf-persona-store.vala:2078: Error in
> address book view query:
> GDBus.Error:org.gnome.evolution.dataserver.AddressBook.OtherError: LDAP error
> 0x32 (Insufficient access)

I think it's because the password being used to login to LDAP server was either none or incorrect.

Not possible Milan, since after killing  /usr/libexec/evolution-addressbook-factory, everything works perfectly (without supplying a new password)...So the password is there for sure.

Just like mentioned in the dupe bug 683855...

*** Bug 671608 has been marked as a duplicate of this bug. ***

Created attachment 230089 [details] [review]
proposed evo workaround

for evolution;

Could anyone of you try to reproduce this with this workaround, please? This only postpones evolution-alarm-notify start by 10 seconds, thus anything it will start will start it later after boot, hopefully when other dependent processes like gnome-keyring are fully initialized. It'll show whether it's caused by this or not, if the alarm-notify is the only process which runs the book/calendar factory. If there are more processes invoking any of these factories right after start, then probably bad luck.

I created a test builds for Fedora, to make it easier for testing:
Fedora 17: http://koji.fedoraproject.org/koji/taskinfo?taskID=4737595
Fedora 18: http://koji.fedoraproject.org/koji/taskinfo?taskID=4737609

Another test, for a lack of reminder notifications, would be to get rid of
   /etc/xdg/autostart/evolution-alarm-notify.desktop
file temporarily. Evolution itself starts evolution-alarm-notify on its own since 3.6.0.

fixed in 3.6 for me, on three machines.

For the record, Ubuntu is doing something similar in their evolution package using the X-GNOME-Autostart-Delay desktop file key they invented.  Unfortunately that X-GNOME key is not supported by GNOME despite appearances.


Description: Delay alarm-notifier by 30 seconds. It's not necessary to have in the critical path during boot, and it's quite expensive.
Author: Martin Pitt <martin.pitt@ubuntu.com>
Forwarded: Not yet, depends on https://bugzilla.gnome.org/show_bug.cgi?id=608402

Index: evolution-3.2.0/data/evolution-alarm-notify.desktop.in
===================================================================
--- evolution-3.2.0.orig/data/evolution-alarm-notify.desktop.in	2011-09-24 16:37:39.000000000 -0400
+++ evolution-3.2.0/data/evolution-alarm-notify.desktop.in	2011-09-27 09:48:51.844023949 -0400
@@ -13,3 +13,4 @@
 X-GNOME-Bugzilla-Product=evolution
 X-GNOME-Bugzilla-Component=calendar
 X-GNOME-Bugzilla-Version=3.6.x
+X-GNOME-Autostart-Delay=30
Index: evolution-3.2.0/data/evolution-alarm-notify.desktop.in.in
===================================================================
--- evolution-3.2.0.orig/data/evolution-alarm-notify.desktop.in.in	2011-09-27 09:49:10.504024009 -0400
+++ evolution-3.2.0/data/evolution-alarm-notify.desktop.in.in	2011-09-27 09:49:17.344024031 -0400
@@ -13,3 +13,4 @@
 X-GNOME-Bugzilla-Product=evolution
 X-GNOME-Bugzilla-Component=calendar
 X-GNOME-Bugzilla-Version=@BASE_VERSION@.x
+X-GNOME-Autostart-Delay=30

Sadly this doesn't work on 3.4.4 at least - using evolution 3.4.4 from your koji builds on F17, evolution-addressbook-factory starts at basically the same time as evolution-alarm-notify still:


ll /proc/ --full-time | grep `pidof evolution-addressbook-factory`
dr-xr-xr-x.  8 apm     apm                   0 2012-11-29 11:44:56.530586020 +1030 1800

ls /proc/ --full-time | grep `pidof evolution-alarm-notify`
dr-xr-xr-x.  8 apm     apm                   0 2012-11-29 11:44:55.588585148 +1030 1660

ie. there is only a delay of about a second between the two, not 10 seconds

(In reply to comment #10)
> fixed in 3.6 for me, on three machines.

I guess without the koji build, right?

(In reply to comment #12)
> Sadly this doesn't work on 3.4.4 at least - using evolution 3.4.4 from your
> koji builds on F17, evolution-addressbook-factory starts at basically the same
> time as evolution-alarm-notify still:

Do you see the countdown when you run evolution-alarm-notify on console? It's located at
   /usr/libexec/evolution/3.4/evolution-alarm-notify
If the addressbook factory process is run even when you move away the .desktop file (see the last paragraph of comment #9), then it means another application is using EBook/EBookClient, which starts the factory.

Milan, in my case, I have disabled alarm notification from genome-session-properties entry for it (I created that). And alarm notification program does not start at all on my computer (the reason I created a session entry for it in the past). I just checked it just to be sure and I can confirm that I do not have it running. This also means that my evo does not start it automatically I guess. Evolution is 3.4.4 and "show reminders in notificaiton area" is checked in the preferences...

Anyway, is there any point in trying this since I don't even have it running? If yes, I will try it.

FYI, I am running gentoo.

@Milan - Yes I saw the countdown in .xsession-errors so it was definitely using the proposed fix - I haven't tried moving away the .desktop file yet - will try that soon and get back to you.

(In reply to comment #13)
> (In reply to comment #10)
> > fixed in 3.6 for me, on three machines.
> 
> I guess without the koji build, right?
Yes. Just plain arch packages. Had a look at it, there's no patch involved.

Even when I move away the autostart desktop file, evolution-addressbook-factory is still run and I still get the same error so something else is causing it to be run.

(In reply to comment #17)
> Even when I move away the autostart desktop file, evolution-addressbook-factory
> is still run and I still get the same error so something else is causing it to
> be run.

Hrm, something else runs it... I'm afraid we cannot easily check what runs it. My initial idea was an evolution-calendar-process runs it, when it is asked for Birthdays&Anniversaries calendar, which does lookups in configured addressbooks for this calendar. If it's run by the calendar factory - which is also used by alarm notify, but you do not have it running on start now - then the other one can be gnomeshell-calendar-server. I do not know how it checks for calendars which is should open, though I expect it'll open those selected in Evolution's Calendar view. Do you have the Birthdays&Anniversaries calendar checked there?

Yes I have the Birthdays & Anniversaries calendar checked in Evolution.

Does it help to uncheck it? Same as in Edit->Preferences->Calendar and Tasks, tab Reminders (or formerly Alarms), uncheck it from calendars for reminders. That way neither the gnome-calendar-server (I hope), nor the evolution-alarm-notify should check for it the next start, thus no evolution-addressbook-factory should be running.

Nope - even when unchecked in the main Calendar view of evolution and also when unchecked in Reminders for Calendar and Tasks preferences it still starts immediately at login :(

Even after the years, I still see password issues from time to time, but very sporadically. Evolution uses libsecret for it now. My idea of "the process starts too early, thus the password provider is not available yet" is completely wrong. I've got a password issue even when just restarting all the evolution processes. Restarting them once gain cures the issue.

The error itself, reported by the libsecret, says something about incorrectly received password data or something like that. I do not have the error handy right now. As it's reported by the libsecret, I tend to move this bug report there.

(In reply to Milan Crha from comment #22)
> I do not have the error handy right now.

The message on the console is this:
   Message: received an invalid or unencryptable secret

This is mentioned in bug #714128, which points to bug #769666, thus I close this as a duplicate of the later.

*** This bug has been marked as a duplicate of bug 769666 ***