Re: [Evolution] Calendar stuck in "Searching for existing versions of this appointment"

[Ignacio Mas Ivars <nacho kth se>]

Hi again,
Ok! I have killed the bonobo daemon, --force-shutdown evo and check that
there was no process left in ps -ax... I have started e-d-s in a
terminal (trace attached) and evo in another, but still the same
behavior. There is a new message:

libecalbackendfile-WARNING **: e-cal-backend-file.c:478: Tried to add an
already existing recurrence
in server_log_handler

Bad the calendar factory seems to start fine... 

Thanks for your time!
/Nacho

On Thu, 2007-05-31 at 03:55 -0600, P Chenthill wrote:
> Hi Ignacio,
> 
> On Thu, 2007-05-31 at 11:30 +0200, Ignacio Mas Ivars wrote:
> > evolution:10727): libecal-WARNING **: e-cal.c:1128: Could not activate
> > calendar factory (OAFIID:GNOME_Evolution_DataServer_CalFactory:1.2)
> The calendar factory is not created in EDS at all. You need to set the
> BONOBO_ACTIVATION_PATH correctly.
> 
> $export BONOBO_ACTIVATION_PATH=<prefix>/lib/bonobo/servers:<followed by
> other paths where the bonobo servers files are there say
> like /opt/gnome>
> 
> Then kill the running activation server
> $pkill -9 bonobo
> 
> Then
> $evolution --force-shutdown
> 
> Restart evolution. 
> 
> You can also try running EDS from a separate terminal with the paths set
> properly and start evolution. 
> $/<prefix>/libexec/evolution-data-server-1.12.
> 
> If the problem persists get us the messages which appear on the EDS
> terminal. 
> 
> - Chenthill.

evolution-data-server-Message: Starting server
e-data-server-Message: adding type `EBookBackendGroupwiseFactory'
e-data-server-Message: adding type `EBookBackendFileFactory'
e-data-server-Message: adding type `ECalBackendContactsEventsFactory'
e-data-server-Message: adding type `EBookBackendLDAPFactory'
e-data-server-Message: adding type `EBookBackendVCFFactory'
e-data-server-Message: adding type `ECalBackendCalDAVEventsFactory'
e-data-server-Message: adding type `ECalBackendGroupwiseTodosFactory'
e-data-server-Message: adding type `ECalBackendGroupwiseEventsFactory'
e-data-server-Message: adding type `ECalBackendGroupwiseJournalFactory'
e-data-server-Message: adding type `ECalBackendFileTodosFactory'
e-data-server-Message: adding type `ECalBackendFileEventsFactory'
e-data-server-Message: adding type `ECalBackendFileJournalFactory'
e-data-server-Message: adding type `ECalBackendWeatherEventsFactory'
e-data-server-Message: adding type `ECalBackendHttpTodosFactory'
e-data-server-Message: adding type `ECalBackendHttpEventsFactory'
in server_log_handler
evolution-data-server-Message: Server up and running
cal = 0x80568c0
cal = 0x80568f0
in server_log_handler

(evolution-data-server-1.12:21620): libecalbackendfile-WARNING **: e-cal-backend-file.c:478: Tried to add an already existing recurrence
in server_log_handler

(evolution-data-server-1.12:21620): libecalbackendfile-WARNING **: e-cal-backend-file.c:478: Tried to add an already existing recurrence
in server_log_handler

(evolution-data-server-1.12:21620): libecalbackendfile-WARNING **: e-cal-backend-file.c:478: Tried to add an already existing recurrence
cal = 0x8056920
impl_GNOME_Evolution_Addressbook_BookFactory_getBook
 + file:///home/nacho/.evolution/addressbook/local/system
 => 0x8056980
impl_GNOME_Evolution_Addressbook_Book_open (0x8056980)

(evolution-data-server-1.12:21620): libedata-book-WARNING **: impl_GNOME_Evolution_Addressbook_Book_getBookView ((contains "x-evolution-any-field" ""))

e_data_book_respond_get_book_view
starting book view thread
starting initial population of book view
signalling parent thread
returning from start_book_view
cal = 0x8072800
book_view file uref
finished population of book view
cal = 0x8d34e60
cal = 0x8d34f80
cal = 0x8d34fb0
cal = 0x8d35000
cal = 0x8d35030
cal = 0x8072830
cal = 0x8d35460

** (evolution:21660): DEBUG: mailto URL command: evolution %s
** (evolution:21660): DEBUG: mailto URL program: evolution
libnm_glib_nm_state_cb: dbus returned an error.
  (org.freedesktop.DBus.Error.ServiceUnknown) The name org.freedesktop.NetworkManager was not provided by any .service files
Loading Bogofilter as the default junk plugin
Thread b68136c0 >

received: A00004 OK FETCH completed.

Thread b246eb90 >
Folder get message '1020' folder info ->
Subject: 
To: me
Cc: 
mailing list: 
From: someone
UID: 1020
Flags: 0010
< b246eb90 >
CamelException.setv((nil), 2, 'Failed to cache 1: No such file or directory')
Setting part content type to 'text/plain; charset=iso-8859-1' contentinfo type is 'text/plain; charset=iso-8859-1'
CamelException.setv((nil), 2, 'Failed to cache 2: No such file or directory')
Setting part content type to 'text/html; charset=iso-8859-1' contentinfo type is 'text/html; charset=iso-8859-1'
Setting part content type to 'text/calendar; method=REQUEST; name=meeting.ics' contentinfo type is 'text/calendar; method=REQUEST; name=meeting.ics'
Setting message content type to 'multipart/alternative; boundary="----_=_NextPart_001_01C7A2D4.E5E3DF52"' contentinfo type is 'multipart/alternative'
Thread b246eb90 >
CamelFolder:get_message('INBOX/2Calendar', '1020') =
class: CamelMimeMessage
mime-type: multipart/alternative; boundary="----_=_NextPart_001_01C7A2D4.E5E3DF52"
content class: CamelMultipart
content mime-type: multipart/alternative; boundary="----_=_NextPart_001_01C7A2D4.E5E3DF52"
  class: CamelMimePart
  mime-type: text/plain; charset=iso-8859-1
  content class: CamelImapWrapper
  content mime-type: text/plain; charset=iso-8859-1
  class: CamelMimePart
  mime-type: text/html; charset=iso-8859-1
  content class: CamelImapWrapper
  content mime-type: text/html; charset=iso-8859-1
  class: CamelMimePart
  mime-type: text/calendar; method=REQUEST; name=meeting.ics
  content class: CamelImapWrapper
  content mime-type: text/calendar; method=REQUEST; name=meeting.ics
< b246eb90 >
Increasing itip formatter search count to 1
Increasing itip formatter search count to 2
Increasing itip formatter search count to 3
Increasing itip process 21660: The last reference on a connection was dropped without closing the connection. This is a bug in an application. See dbus_connection_unref() documentation for details.
Most likely, the application was supposed to call dbus_connection_close(), since this is a private connection.
formatter search count to 4
Decreasing itip formatter search count to 3
Decreasing itip formatter search count to 2
Decreasing itip formatter search count to 1