Re: [Evolution-hackers] libdb performance issue? (was: Re: libebook: errors when using asynchronous contact addition/removal functions)
On Fri, 2011-05-13 at 15:44 +0200, Patrick Ohly wrote: In libebook, I get a Timeout was reached because the asynchronous operation doesn't complete quickly enough. Same for the attempt to delete the contacts. The gError-code is 24, which is indeed E_BOOK_ERROR_NOT_SUPPORTED. Hi, as long as it's GError, you cannot compare only GError::code, because the correct way to identify the error is using the whole pair GError::domain and GError::code. Your domain for Timeout was reached is most likely G_IO_ERROR with a code G_IO_ERROR_TIMED_OUT. This means, for GDBus calls, that the call didn't finish in a default time, the server side didn't reply to the method invocation on time. (As Patrick suggested too). The new eclient stuff will not suffer of this (unless some backend will block main thread for too long). As a workaround, in 3.0, was added e_data_server_util_set_dbus_call_timeout(), which can be called by clients. I've no idea about libdb, thus only referring to the error. I have one notice though, the EBook calls are served and processed mostly as soon as they come, and they can come in parallel too. The backend itself may make sure that it'll not make any trouble, like by some busy lock. The sync calendar backend does this differently, it has a flag for using such internal busy lock, thus no call can overlap with another, if the backend implementation wishes to do so. I guess this kind of functionality might be useful when added to EBookBackendSync too. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
On Thu, 2011-05-12 at 12:44 +0200, Patrick Ohly wrote:
I found this in e-data-cal-view.c notify_remove():
280 /* TODO: store ECalComponentId instead of just uid*/
281 uid = g_strdup (id-uid);
282 g_array_append_val (priv-removes, uid);
In other words, removes always come without rid, even if the actual
event that was removed was not the parent but a detached recurrence.
...
It'll lead to a change of the D-Bus API. For master that shouldn't
be a problem, but I also want this in MeeGo for KCal-EDS, based on
2.32. I guess we have to bite the bullet and maintain a MeeGo version
with a different API than regular 2.32.x.
Hi,
I noticed it too, recently (at the beginning of this week, actually).
I suggest to not change the D-Bus API, rather encode the string pair
into the string, like uid\nrid. I was planning to do so in the master
branch, but didn't do that yet.
One more question about e_cal_backend_notify_object_removed(): it takes
iCalendar 2.0 object strings as parameter in addition to the id. If both
are set, it acts like object_updated. If the new object is NULL, it
checks whether the old_object matches the view. Is that really
necessary? There is a second check whether the ID is in the view in
e_data_cal_view_notify_objects_removed():
701 for (l = ids; l; l = l-next) {
702 ECalComponentId *id = l-data;
703 if (g_hash_table_lookup (priv-ids, id))
704 notify_remove (view, id);
705 }
At least that is my understanding. So is it safe to pass only the ID and
old_object = object = NULL?
You can pass both NULL if the old_object was completely removed. The
call if the object matches the view was kept there in time when the test
for !old_object was added. I do not recall exact circumstances, but I
think there was some rationale why it is so, though looking at it the
call of e_data_cal_view_object_matches() in
e_cal_backend_notify_object_removed() really seems unnecessary. Maybe it
was because of no expectations on the behaviour of
e_data_cal_view_notify_objects_removed_1().
Hope that helps a bit,
Milan
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Compile Evolution-Mapi 3.1.1 - Error on libmapi.h
On Sun, 2011-05-15 at 22:39 -0700, tudstudent wrote: ... When compiling evolution-mapi-3.1.1 I get stuck with the following error: ... exchange-mapi-connection.c: In function 'exchange_mapi_util_get_attachments': exchange-mapi-connection.c:1272:5: warning: passing argument 2 of 'cast_SPropValue' from incompatible pointer type /usr/include/libmapi/libmapi.h:262:11: note: expected 'struct mapi_SPropValue *' but argument is of type 'struct SPropValue *' exchange-mapi-connection.c:1272:5: error: too few arguments to function 'cast_SPropValue' /usr/include/libmapi/libmapi.h:262:11: note: declared here ... The file libmapi.h is present and is from the latest openchange (0.10). Hi, is it possible you've installed two different libmapi.h or openchange versions, thus the configure part was done against a different openchange version? The 3.1.x, same as 3.0.x and couple versions before, has conditional compilations for detecting when to use what, and this API change is part of this detection. Could you check what has your config.h and config.log in the evo-mapi build directory and what signature the cast_SPropValue function of libmapi.h is, please? Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Compile Evolution-Mapi 3.1.1 - Error on libmapi.h
Milan Crha wrote: On Sun, 2011-05-15 at 22:39 -0700, tudstudent wrote: ... When compiling evolution-mapi-3.1.1 I get stuck with the following error: ... exchange-mapi-connection.c: In function 'exchange_mapi_util_get_attachments': exchange-mapi-connection.c:1272:5: warning: passing argument 2 of 'cast_SPropValue' from incompatible pointer type /usr/include/libmapi/libmapi.h:262:11: note: expected 'struct mapi_SPropValue *' but argument is of type 'struct SPropValue *' exchange-mapi-connection.c:1272:5: error: too few arguments to function 'cast_SPropValue' /usr/include/libmapi/libmapi.h:262:11: note: declared here ... The file libmapi.h is present and is from the latest openchange (0.10). Hi, is it possible you've installed two different libmapi.h or openchange versions, thus the configure part was done against a different openchange version? The 3.1.x, same as 3.0.x and couple versions before, has conditional compilations for detecting when to use what, and this API change is part of this detection. Could you check what has your config.h and config.log in the evo-mapi build directory and what signature the cast_SPropValue function of libmapi.h is, please? Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers When I check for multiple versions of libmapi: code locate libmapi.h /usr/include/libmapi/libmapi.h /code So I have only 1 libmapi.h installed on my system. Furthermore I have looked into libmapi.h: uint32_tcast_SPropValue(TALLOC_CTX *, struct mapi_SPropValue *, struct SPropValue *); I hope I give you correct information. I did not understand what you wanted to have so I tried my best. What do you want with config.log and the other (better said what do I need to check specificly). -- View this message in context: http://old.nabble.com/Compile-Evolution-Mapi-3.1.1--%3E-Error-on-libmapi.h-tp31626288p31626473.html Sent from the Gnome - Evolution - Dev mailing list archive at Nabble.com. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Compile Evolution-Mapi 3.1.1 - Error on libmapi.h
On Sun, 2011-05-15 at 23:33 -0700, tudstudent wrote: So I have only 1 libmapi.h installed on my system. Furthermore I have looked into libmapi.h: uint32_tcast_SPropValue(TALLOC_CTX *, struct mapi_SPropValue *, struct SPropValue *); I hope I give you correct information. I did not understand what you wanted to have so I tried my best. What do you want with config.log and the other (better said what do I need to check specificly). OK, so your openchange has the mem_ctx parameter, which makes sense. Search the config.log file for SPropValue string. It'll give you two checks with its description and two defines. Mine defines are: #define HAVE_MEMCTX_ON_CAST_SPROPVALUE 1 #define HAVE_MEMCTX_ON_CAST_MAPI_SPROPVALUE 1 The same defines should be defined in config.h. Is it possible your evo-mapi compilation doesn't use correct config.h? I suppose you have those two defines defined same as I do. Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libdb performance issue? (was: Re: libebook: errors when using asynchronous contact addition/removal functions)
On Mo, 2011-05-16 at 08:11 +0200, Milan Crha wrote: On Fri, 2011-05-13 at 15:44 +0200, Patrick Ohly wrote: In libebook, I get a Timeout was reached because the asynchronous operation doesn't complete quickly enough. Same for the attempt to delete the contacts. The gError-code is 24, which is indeed E_BOOK_ERROR_NOT_SUPPORTED. Hi, as long as it's GError, you cannot compare only GError::code, because the correct way to identify the error is using the whole pair GError::domain and GError::code. Your domain for Timeout was reached is most likely G_IO_ERROR with a code G_IO_ERROR_TIMED_OUT. Indeed, that explains it. In principle I know that, I just forgot to check in this case ;-} The new eclient stuff will not suffer of this (unless some backend will block main thread for too long). The EClient may not time out, but taking several minutes of 100% CPU time just to safe a handful of contacts just can't be right. I've no idea about libdb, thus only referring to the error. I have one notice though, the EBook calls are served and processed mostly as soon as they come, and they can come in parallel too. The backend itself may make sure that it'll not make any trouble, like by some busy lock. libdb is supposed to be thread-safe, so in theory shouldn't need such a lock. Either libdb is broken or EDS is not using it correctly (wrong environment, for example). Looking at the DB API [1] I see this flag for opening the environment: DB_INIT_LOCK Initialize the locking subsystem. This subsystem should be used when multiple processes or threads are going to be reading and writing a Berkeley DB database, so that they do not interfere with each other. If all threads are accessing the database(s) read-only, locking is unnecessary. When the DB_INIT_LOCK flag is specified, it is usually necessary to run a deadlock detector, as well. See db_deadlock and DB_ENV-lock_detect() for more information. EDS does not pass this flag, although it has concurrent reads *and* writes. The behavior in that case is undefined as far as I can tell. The downside of using DB_INIT_LOCK is that deadlocks are possible and need to be checked by regularly calling lock_detect(). It might be easier to set DB_INIT_CDB, which enforces multiple reads/single writer access without deadlocks. I'll give that a try. [1] http://download.oracle.com/docs/cd/E17076_02/html/api_reference/C/envopen.html -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libdb performance issue? (was: Re: libebook: errors when using asynchronous contact addition/removal functions)
[Milan, can you please keep other people on CC?
I know that you personally prefer to not be CCed on mailing list emails
and I try to remember that in my own replies, but others are not on the
list and may depend on being CCed. For example, I don't know whether
Chris is subscribed.]
On Mo, 2011-05-16 at 11:12 +0200, Patrick Ohly wrote:
It might be easier to set DB_INIT_CDB, which enforces multiple
reads/single writer access without deadlocks. I'll give that a try.
And it works beautifully. One word added to the source code and the
stress test passes reliably and quickly :-)
Patch attached. Okay to submit into master (not tested there, though)
and gnome-2-32 branches (which is where I have tested it)?
--
Bye, Patrick Ohly
--
patrick.o...@gmx.de
http://www.estamos.de/
From 2b4cff9230a049d5ad7fe86873aba9a7bba35af1 Mon Sep 17 00:00:00 2001
From: Patrick Ohly patrick.o...@intel.com
Date: Mon, 16 May 2011 11:21:04 +0200
Subject: [PATCH] addressbook file backend: libdb must be initialized for concurrent read/write
Very bad performance (100% CPU load, several minutes run time) were
seen for multiple concurrent writes. gdb shows that libdb is
apparently busy polling while writing.
The libdb API docs for DB_ENV-open() imply that either DB_INIT_CDB or
DB_INIT_LOCK must be used in apps which are not read-only, like
EDS. This patch adds DB_INIT_CDB because it is simple and fixes the
performance problem.
In some rare cases, DB_INIT_LOCK might provide better performance by
allowing concurrent writes of independent data, but that seems too
complicated for not enough gain right now (must check for deadlocks).
---
addressbook/backends/file/e-book-backend-file.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/addressbook/backends/file/e-book-backend-file.c b/addressbook/backends/file/e-book-backend-file.c
index d21c527..372ade5 100644
--- a/addressbook/backends/file/e-book-backend-file.c
+++ b/addressbook/backends/file/e-book-backend-file.c
@@ -1146,7 +1146,18 @@ e_book_backend_file_load_source (EBookBackend *backend,
(gpointer (*)(gpointer , gsize))g_try_realloc,
g_free);
- db_error = (*env-open) (env, NULL, DB_CREATE | DB_INIT_MPOOL | DB_PRIVATE | DB_THREAD, 0);
+ /*
+ * We need either DB_INIT_CDB or DB_INIT_LOCK, because we will have
+ * multiple threads reading and writing concurrently without
+ * any locking above libdb.
+ *
+ * DB_INIT_CDB enforces multiple reader/single writer by locking inside
+ * the database. It is used instead of DB_INIT_LOCK because DB_INIT_LOCK
+ * may deadlock, which would have to be called in a separate thread.
+ * Considered too complicated for not enough gain (= concurrent writes)
+ * at this point.
+ */
+ db_error = (*env-open) (env, NULL, DB_INIT_CDB | DB_CREATE | DB_INIT_MPOOL | DB_PRIVATE | DB_THREAD, 0);
if (db_error != 0) {
env-close(env, 0);
g_warning (db_env_open failed with %s, db_strerror (db_error));
--
1.7.2.5
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libdb performance issue? (was: Re: libebook: errors when using asynchronous contact addition/removal functions)
On Mon, 2011-05-16 at 11:35 +0200, Patrick Ohly wrote: And it works beautifully. One word added to the source code and the stress test passes reliably and quickly :-) Patch attached. Okay to submit into master (not tested there, though) and gnome-2-32 branches (which is where I have tested it)? Yes please, master, gnome-3-0 and if you want then gnome-2-32 too. Thanks. Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Compile Evolution-Mapi 3.1.1 - Error on libmapi.h
Okey, maybe it makes sense to describe how I run the package:
./configure CFLAGS=-I/usr/lib64/samba4/include
make (which delivers me the errors)
code
configure:14060: result: no
configure:14063: checking libmapi cast_SPropValue function with three params
configure:14078: gcc -o conftestconftest.c 5
In file included from conftest.c:30:0:
/usr/include/libmapi/libmapi.h:49:20: fatal error: dcerpc.h: No such file or
directory
compilation terminated.
configure:14078: $? = 1
configure: failed program was:
| /* confdefs.h */
/code
code
| #include libmapi/libmapi.h
| int
| main ()
| {
| cast_SPropValue (NULL, NULL, NULL)
| ;
| return 0;
| }
configure:14089: result: no
configure:14092: checking libmapi cast_mapi_SPropValue function with three
params
configure:14107: gcc -o conftestconftest.c 5
In file included from conftest.c:30:0:
/usr/include/libmapi/libmapi.h:49:20: fatal error: dcerpc.h: No such file or
directory
compilation terminated.
configure:14107: $? = 1
configure: failed program was:
| /* confdefs.h */
/code
Milan Crha wrote:
On Sun, 2011-05-15 at 23:33 -0700, tudstudent wrote:
So I have only 1 libmapi.h installed on my system. Furthermore I have
looked
into libmapi.h:
uint32_tcast_SPropValue(TALLOC_CTX *, struct
mapi_SPropValue
*, struct SPropValue *);
I hope I give you correct information. I did not understand what you
wanted
to have so I tried my best.
What do you want with config.log and the other (better said what do I
need
to check specificly).
OK, so your openchange has the mem_ctx parameter, which makes sense.
Search the config.log file for SPropValue string. It'll give you two
checks with its description and two defines. Mine defines are:
#define HAVE_MEMCTX_ON_CAST_SPROPVALUE 1
#define HAVE_MEMCTX_ON_CAST_MAPI_SPROPVALUE 1
The same defines should be defined in config.h. Is it possible your
evo-mapi compilation doesn't use correct config.h? I suppose you have
those two defines defined same as I do.
Milan
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
--
View this message in context:
http://old.nabble.com/Compile-Evolution-Mapi-3.1.1--%3E-Error-on-libmapi.h-tp31626288p31627272.html
Sent from the Gnome - Evolution - Dev mailing list archive at Nabble.com.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Compile Evolution-Mapi 3.1.1 - Error on libmapi.h
On Mon, 2011-05-16 at 01:45 -0700, tudstudent wrote: Okey, maybe it makes sense to describe how I run the package: ./configure CFLAGS=-I/usr/lib64/samba4/include make (which delivers me the errors) ... /usr/include/libmapi/libmapi.h:49:20: fatal error: dcerpc.h: No such file or Try with these set: export LD_LIBRARY_PATH=$PREFIX/lib:$PREFIX/samba/lib export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig: $PREFIX/samba/lib/pkgconfig:$PREFIX/share/pkgconfig Then you might be able to get sane results when invoking: $ pkg-config --cflags libmapi which should cover your -I too (by the way, it might not be in lib64). Hope that helps, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libdb performance issue? (was: Re: libebook: errors when using asynchronous contact addition/removal functions)
On Mo, 2011-05-16 at 13:05 +0200, Milan Crha wrote: On Mon, 2011-05-16 at 11:35 +0200, Patrick Ohly wrote: And it works beautifully. One word added to the source code and the stress test passes reliably and quickly :-) Patch attached. Okay to submit into master (not tested there, though) and gnome-2-32 branches (which is where I have tested it)? Yes please, master, gnome-3-0 and if you want then gnome-2-32 too. Thanks. Okay, done. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] e_cal_remove_object_with_mod() + empty rid: semantic?
On Do, 2011-05-12 at 13:17 +0200, Milan Crha wrote: On Thu, 2011-05-12 at 12:44 +0200, Patrick Ohly wrote: I found this in e-data-cal-view.c notify_remove(): 280 /* TODO: store ECalComponentId instead of just uid*/ 281 uid = g_strdup (id-uid); 282 g_array_append_val (priv-removes, uid); In other words, removes always come without rid, even if the actual event that was removed was not the parent but a detached recurrence. ... It'll lead to a change of the D-Bus API. For master that shouldn't be a problem, but I also want this in MeeGo for KCal-EDS, based on 2.32. I guess we have to bite the bullet and maintain a MeeGo version with a different API than regular 2.32.x. Hi, I noticed it too, recently (at the beginning of this week, actually). I suggest to not change the D-Bus API, rather encode the string pair into the string, like uid\nrid. I was planning to do so in the master branch, but didn't do that yet. That's still a D-Bus API change: a libecal which receives a UID entry in that format won't know what to do with it. But it'll be easier to implement that way, so I'll give it a try first. I'll do it as uid[\nrid] so that entries without an rid continue to look exactly like the current ones. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Compile Evolution-Mapi 3.1.1 - Error on libmapi.h
Oke, this is what i did with above message: export LD_LIBRARY_PATH=$PREFIX/lib:$PREFIX/samba/lib export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PREFIX/samba/lib/pkgconfig:$PREFIX/share/pkgconfig then: pkg-config --cflags libmapi This delivers the next error: Package talloc was not found in the pkg-config search path. Perhaps you should add the directory containing `talloc.pc' to the PKG_CONFIG_PATH environment variable Package 'talloc', required by 'MAPI', not found This package is installed. Milan Crha wrote: On Mon, 2011-05-16 at 01:45 -0700, tudstudent wrote: Okey, maybe it makes sense to describe how I run the package: ./configure CFLAGS=-I/usr/lib64/samba4/include make (which delivers me the errors) ... /usr/include/libmapi/libmapi.h:49:20: fatal error: dcerpc.h: No such file or Try with these set: export LD_LIBRARY_PATH=$PREFIX/lib:$PREFIX/samba/lib export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig: $PREFIX/samba/lib/pkgconfig:$PREFIX/share/pkgconfig Then you might be able to get sane results when invoking: $ pkg-config --cflags libmapi which should cover your -I too (by the way, it might not be in lib64). Hope that helps, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers -- View this message in context: http://old.nabble.com/Compile-Evolution-Mapi-3.1.1--%3E-Error-on-libmapi.h-tp31626288p31631218.html Sent from the Gnome - Evolution - Dev mailing list archive at Nabble.com. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - May 18 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates Check out http://live.gnome.org/Evolution/CommunityMeet for more details. - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] GPG signature position
Hi everybody, I'm a little annoyed at the position of the signature verification in Evolution. I want to put it in the top, right below the header. Even better if it can be partially hidden. I know to make some changes like this might need to change the source code, but is there a way to display the signature in the top by just configuration files? It doesn't have to be part of the header, like I suggested, just the same way it is now, but on the top. I work use GPG in my emails daily and the position gets annoying after many emails having to scroll down. Thanks in advance to anybody with ideas -- Felipe Castillo signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Compile Evolution-Mapi 3.1.1 - Error on libmapi.h
On Mon, 2011-05-16 at 10:35 -0700, tudstudent wrote: export LD_LIBRARY_PATH=$PREFIX/lib:$PREFIX/samba/lib export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PREFIX/samba/lib/pkgconfig: $PREFIX/share/pkgconfig then: pkg-config --cflags libmapi This delivers the next error: Package talloc was not found in the pkg-config search path. Perhaps you should add the directory containing `talloc.pc' to the PKG_CONFIG_PATH environment variable Package 'talloc', required by 'MAPI', not found This package is installed. Hi, good, then you know where to look next. Solve this and it'll work for you. I cannot tell you anything more than the pkg-config does, the message is self-describing. By the way, I thought it's obvious but it seems it wasn't, in those two exports at the beginning, you should replace $PREFIX with a prefix where your samba4 is installed, probably /usr if you do not compile it yourself. Also check the paths exist for you, or change them accordingly to your system/setup. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
