Re: [Evolution-hackers] Evo master dumps core: missing GConf key
On Solaris, we used gconftool2 --makefile-install-rule to update the schema files. But it also dumps this core. If I log out and log in again, it works. Jeff On Tue, 2009-11-24 at 16:08 -0500, Paul Smith wrote: On Tue, 2009-11-24 at 15:01 -0500, Matthew Barnes wrote: Run this as yourself (not super user): gconftool-2 --install-schema-file .../shell/apps_evolution_shell.schemas That worked, although it still dumped core until I also added the evolution-mail.schemas file. Now it starts OK. I do see a few weird things (minor glitches) in the presentation so I wonder if there are more of these I need to do? I've never needed to do this before when going to a newer version of Evo; is this supposed to happen automatically some how when a newer version starts up? Should I run --install-schema-file for all the *.schema files in that directory, just in case, or might that break things? Cheers! ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] zombie threads on 2.25.92 in Solaris
On 2.25.92, I found a lot of zombie threads on Solaris when I saw the stack trace of evolution. pstack 19326 19326: evolution - lwp# 1 / thread# 1 feef13b7 pollsys (8b22208, e, 8046f5c, 0) fee970b4 poll (8b22208, e, 8c, fec614f0, 80a3f6c) + 4c fec61508 g_poll (8b22208, e, 8c, fec52f16) + 24 fec53343 g_main_context_iterate (80a3f68, 1, 1, 8080080) + 43b fec539f1 g_main_loop_run (815e670, 815e670, 804706c, fede4656) + 1dd fede46a7 bonobo_main (80471cc, 80470b4, feffb7b4, 0, f9f31a30, 0) + 6b 080652ad main (1, 80470f8, 8047100) + 411 0805ba0a _start (1, 8047234, 0, 804723e, 8047272, 8047297) + 7a - lwp# 54 / thread# 54 fec7b708 g_thread_create_proxy(), exit value = 0x ** zombie (exited, not detached, not yet joined) ** - lwp# 28 / thread# 28 fec7b708 g_thread_create_proxy(), exit value = 0x ** zombie (exited, not detached, not yet joined) ** - lwp# 136 / thread# 136 fec7b708 g_thread_create_proxy(), exit value = 0x ** zombie (exited, not detached, not yet joined) ** . Did you see this also? Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
On OpenSolaris, libbdb is not shipped so Evolution still uses the private copy of BDB. Jeff On Mon, 2008-10-06 at 22:15 +0530, Srinivasa Ragavan wrote: Rob, IIRC, I had replied to Ross on a similar query, start GNOME 2.24. Still OpenSUSE ships with in-built libdb. I'm not aware of any other distro. JPR, who use to maintain Evolution few years back, gave me the notes on why it was decided to go this way (forking libdb). So if we have answers for all those points, I'm fine for that. We don't want to break anything thatz fine otherwise. I'm not tracking libdb at all, if you have the answers, then lets recalculate and plan for it in 2.26. -Srini. On Mon, 2008-10-06 at 14:59 +0100, Rob Bradford wrote: Since we're at the start of the cycle shall we go ahead and drop the included libdb ? and thus add a formal requirement on using the system version. AFAIK all the distributors ship with using the system version... I've updated the bug #410164 with a patch that makes this change. Regards, Rob ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers email message attachment, Attached message - Re: [Evolution-hackers] Removing libdb from EDS source Forwarded Message From: Srinivasa Ragavan [EMAIL PROTECTED] To: Ross Burton [EMAIL PROTECTED] Cc: Evolution Hackers evolution-hackers@gnome.org Subject: Re: [Evolution-hackers] Removing libdb from EDS source Date: Mon, 05 May 2008 10:59:16 +0530 Ross, I had a chat with JP and He pointed me to a old README. === The issue was around no backwards compatability, from the old README: - Berkeley's libdb - 3.1.17 db3 is available from http://www.sleepycat.com. Make sure to get 3.1.17, it isn't the latest version. --- IMPORTANT WARNING --- The on-disk format of DB files has been changing between versions 2, 3 and 4. Also, because of the libdb API, there is no way to easily handle the different formats from within the application. For this reason, Evolution has chosen to use one specific version of the library (version 3) and stick to it, so that users do not need to convert their addressbook files to use them with different version of Evolution. That's why Evolution REQUIRES libdb 3.1.17, and NO OTHER VERSION. If you force the check to accept a version different from 3.1.17, your binary of Evolution will be using a different format from the chosen one; this means that it will not be able to read addressbook databases created by other versions of Evolution which were compiled in the standard way. Also, we DO NOT GUARRANTEE that Evolution will work with different versions of libdb at all, even if it can be trivially made to compile against them. SPECIAL NOTE FOR BINARY PACKAGERS: If you are making binary packages for end-users (e.g. if you are a distribution vendor), please statically link Evolution to Berkeley DB 3.1.17, as mandated by the configure.in check. DO NOT patch configure.in to work around the check. Forcing the check to link to a different version of the library will only give headaches and pain to your users, who will see their addressbook disappear and will complain to us (the Evolution team) about losing their data. Besides, libdb will be linked statically, which means that your distribution doesn't actually need to ship DB 3.1.17 itself separately. The Evolution team will be infinitely grateful for your co-operation. Thanks. This proved quite painful for distros (hanging on to a specific version) though so we moved it inside e-d-s eventually. That way we always had a known quantity. === Ross, if we have an answer for this, we can close on this immediately. -Srini. On Fri, 2008-04-25 at 08:46 +0530, Srinivasa Ragavan wrote: Ross, IIRC, it was done because, every libdb update broke Evolution or libdb wasn't so stable release over release. Also OpenSUSE uses statically linked libdb. But most of the hackers I know, dynamically link libdb. I'm favor of the change. But lemme ping some old evolution hackers who were part of this change, to understand what they feel about it. -Srini On Thu, 2008-04-24 at 14:42 +0100, Ross Burton wrote: Hi, I think that we should remove the fork of Berkeley DB from the Evolution Data Server source. Debian, Ubuntu, Gentoo and Fedora all use --with-libdb to dynamically link to a system library, so it is known to work. This would involve removing libdb from svn, and always dynamically linking to libdb instead. --with-libdb would still exist for people who want to use a custom
[Evolution-hackers] MAPI Exchange Connector will replace current Exchange connector?
Hi, I have two questions on MAPI Exchange connector. 1. When will MAPI connector officially become one part of Evolution? 2. If MAPI connector is in, will the current Exchange OWA connector be removed? or they will both exist? Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] make dist error in evolution-data-server
I used the old version of intltool 0.36 and the problem went away. So I guess the new version of intltool caused the problem. Jeff Srinivasa Ragavan wrote: intltoolize (GNU intltool) 0.40.0 -Srini. PS: I didn't release 2.23.5 (I was on some training), and Johnny did it. On Wed, 2008-07-30 at 12:05 +0800, Jeff Cai wrote: Which version of intltoolize did you use? Jeff Srinivasa Ragavan wrote: On Wed, 2008-07-30 at 10:49 +0800, Jeff Cai wrote: Gilles Dartiguelongue wrote: Le mardi 29 juillet 2008 à 14:09 +0800, Jeff Cai a écrit : $make dist make: *** No rule to make target `intltool-merge.in', needed by `distdir'. Stop. I'm curious about how you make it work. either it's missing in EXTRA_DIST or you need to run intltoolize --force (or just use autogen.sh, it does all the dirty first run things) intltoolize --force can not produce those files. Srini, how did you produce the tar ball at the release time? I checkout from svn, do a complete autogen.sh, make install and then I do a make dist as everyone. I have never faced it anytime. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] make dist error in evolution-data-server
$make dist make: *** No rule to make target `intltool-merge.in', needed by `distdir'. Stop. I'm curious about how you make it work. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution 2.24 can't connect to IMAP servers on Solaris
Hi
Please refer to bug http://bugzilla.gnome.org/show_bug.cgi?id=541188.
Since Evolution was upgraded from 2.22 to 2.23.1, it can't connect to
IMAP or POP3 servers in 'No encryption' mode. But If you run Evolution
2.22 in GNOME 2.23, the issue will go away. This means it is not the
platform reason.
After some investigation, I know that errno is not correct after making
a call to connect,
In camel-tcp-stream-raw.c:socket_connect, connect returns -1 with errno 0. In
normal case, connect should return -1 with errno 150. Please refer to the
following code:
int fdmax, status;
fd_set rdset, wrset;
#ifndef G_OS_WIN32
flags = fcntl (fd, F_GETFL);
fcntl (fd, F_SETFL, flags | O_NONBLOCK);
#else
{
u_long yes = 1;
ioctlsocket (fd, FIONBIO, yes);
}
#endif
if (connect (fd, h-ai_addr, h-ai_addrlen) == 0) {
#ifndef G_OS_WIN32
fcntl (fd, F_SETFL, flags);
#else
{
u_long no = 0;
ioctlsocket (fd, FIONBIO, no);
}
#endif
return fd;
}
if (!SOCKET_ERROR_IS_EINPROGRESS ()) {
errnosav = errno;
SOCKET_CLOSE (fd);
errno = errnosav;
return -1;
}
Do you know some changes after 2.22 for Evolution have caused the problem?
Jeff
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] evolution-data-server 2.23.2 build error: e_file_cache_get_type is not defined
evolution-data-server-2.23.2/docs/reference/calendar/libedata-cal cc -i -xO4 -xspace -xstrconst -xpentium -mr -xregs=no%frameptr -i -xO4 -xspace -xstrconst -xpentium -mr -xregs=no%frameptr -I/usr/include/mps -I/usr/include/mps -Wl,-zignore -Wl,-zcombreloc -Wl,-Bdirect -o .libs/libedata-cal-scan .libs/libedata-cal-scan.o -L/usr/lib -L/usr/lib/mps ../../../../calendar/libedata-cal/.libs/libedata-cal-1.2.so /export/home/caiqm/packages/BUILD/SUNWevolution-data-server-2.23.2/evolution-data-server-2.23.2/calendar/libecal/.libs/libecal-1.2.so /export/home/caiqm/packages/BUILD/SUNWevolution-data-server-2.23.2/evolution-data-server-2.23.2/libedataserver/.libs/libedataserver-1.2.so -ldl -lplc4 -lplds4 -lnspr4 -lsoup-2.4 ../../../../libebackend/.libs/libebackend-1.2.so -lxml2 -lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation -lORBit-2 -lgio-2.0 -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lpthread -lthread -lgconf-2 -lglib-2.0 -R/usr/lib -R/usr/lib/mps creating libedata-cal-scan gtk-doc: Running scanner libedata-cal-scan ld.so.1: libedata-cal-scan: fatal: relocation error: file evolution-data-server-2.23.2/calendar/libedata-cal/.libs/libedata-cal-1.2.so.6: symbol e_file_cache_get_type: referenced symbol not found ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] what are camel-index-control and camel-lock-helper for?
å¨ 2006-05-10ä¸ç 07:52 -0400ï¼Jeffrey Stedfaståéï¼ camel-lock-helper is a program that helps lock mbox files (like /var/spool/mail) that require privs that the user account does not have. when does mbox files need to be locked by this program? camel-index-control has something to do with the mbox.ibex.* files - might try to optomise their sizes or something. I don't remember. After these files being optimized, Evolution can still use them directly? On Wed, 2006-05-10 at 18:02 +0800, Jeff Cai wrote: Hi I find two executable program camel-index-control and camel-lock-helper under /usr/bin? who knows what these two programs do? Jeff Cai ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] A multithread problem
Hi,all
I found an implict multithread problem. I want to see
whether anybody could give me more information about it.
In function message-list.c:mail_regen_list,
a new message is created and put into a thread queue,
meanwhile, the message is also prepended to a regen list of the message
list.
But, the regen list is not protected by a mutex which maybe lead to a
severe problem because
it will be changed in thread function regen_list_free and
regen_list_regened,
is this a bug of evolution?
/* if we're busy already kick off timeout processing, so normal updates
are immediate */
if (ml-regen == NULL)
*
the new message is put into a thread queue
ml_regen_timeout(m);
else {
ml-regen_timeout_msg = m;
ml-regen_timeout_id = g_timeout_add(500,
(GSourceFunc)ml_regen_timeout, m);
}
static gboolean
ml_regen_timeout(struct _regen_list_msg *m)
{
e_profile_event_emit(list.regenerate, m-folder-full_name,
0);
***
This code is not protected
***
m-ml-regen = g_list_prepend(m-ml-regen, m);
/* TODO: we should manage our own thread stuff, would make
cancelling outstanding stuff easier */
e_thread_put (mail_thread_queued, (EMsg *)m);
m-ml-regen_timeout_msg = NULL;
m-ml-regen_timeout_id = 0;
return FALSE;
}
regen_list_free (struct _mail_msg *mm)
{
struct _regen_list_msg *m = (struct _regen_list_msg *)mm;
int i;
e_profile_event_emit(list.regenerated, m-folder-full_name,
0);
if (m-summary) {
for (i = 0; i m-summary-len; i++)
camel_folder_free_message_info (m-folder,
m-summary-pdata[i]);
g_ptr_array_free (m-summary, TRUE);
}
if (m-tree)
camel_folder_thread_messages_unref (m-tree);
g_free (m-search);
g_free (m-hideexpr);
camel_object_unref (m-folder);
if (m-changes)
camel_folder_change_info_free (m-changes);
/* we have to poke this here as well since we might've been
cancelled and regened wont get called */
*
This code is not protected
*
m-ml-regen = g_list_remove(m-ml-regen, m);
g_object_unref(m-ml);
}
Jeff Cai
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
