Re: [Evolution-hackers] Can't build evolution-data-server master on ubuntu maverick
Am Montag, den 06.09.2010, 08:18 +0200 schrieb Milan Crha: > On Sat, 2010-09-04 at 05:30 +0200, Thomas Mittelstaedt wrote: > > .libs/libebook_1_2_la-e-book.o: In function > > `e_book_new_default_addressbook': > > /home/tuxdistro/src/evolution/obj/evolution-data-server/addressbook/libebook/../../../../evolution-data-server/addressbook/libebook/e-book.c:3329: > > undefined reference to `e_source_list_peek_default_source' > > Hi, > I suppose you do not have latest master sources of the > evolution-data-server. The "missing" function is part of > libedataserver/e-source-list.c and it links to libedataserver-1.2.la, > which I see it used in the Makefile.am in addressbook/libebook. The > function was added just recently. > 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 Indeed I did not have the latest sources even though I switched branches via > git branch master followed by a git pull origing master I probably misread the message saying something like "... your tree is ahead by xxx commits". A git reset --hard origin/master fixed it. But still, evolution-data-server/addressbook/libebook does not install: make[1]: Verlasse Verzeichnis '/home/tom/src/evolution/obj/evolution-data-server/addressbook/libebook' t...@ubuntu:~/src/evolution/obj/evolution-data-server/addressbook/libebook$ make install make install-am make[1]: Betrete Verzeichnis '/home/tom/src/evolution/obj/evolution-data-server/addressbook/libebook' make[2]: Betrete Verzeichnis '/home/tom/src/evolution/obj/evolution-data-server/addressbook/libebook' test -z "/opt/evo/lib" || /bin/mkdir -p "/opt/evo/lib" /bin/bash ../../libtool --mode=install /usr/bin/install -c libebook-1.2.la '/opt/evo/lib' libtool: install: warning: relinking `libebook-1.2.la' libtool: install: (cd /home/tom/src/evolution/obj/evolution-data-server/addressbook/libebook; /bin/bash /home/tom/src/evolution/obj/evolution-data-server/libtool --silent --tag CC --mode=relink ccache gcc -g -version-info 13:1:3 -Wl,--no-undefined -o libebook-1.2.la -rpath /opt/evo/lib libebook_1_2_la-e-book-marshal.lo libebook_1_2_la-e-address-western.lo libebook_1_2_la-e-book-query.lo libebook_1_2_la-e-book-view.lo libebook_1_2_la-e-book.lo libebook_1_2_la-e-contact.lo libebook_1_2_la-e-destination.lo libebook_1_2_la-e-name-western.lo libebook_1_2_la-e-vcard.lo ../../addressbook/libegdbus/libegdbus-book.la ../../camel/libcamel-1.2.la ../../libedataserver/libedataserver-1.2.la -pthread -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lxml2 -lgconf-2 -lglib-2.0 -pthread -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lnss3 -lnssutil3 -lsmime3 -lssl3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lsqlite3 -lz ) .libs/libebook_1_2_la-e-book.o: In function `e_book_new_default_addressbook': /home/tom/src/evolution/obj/evolution-data-server/addressbook/libebook/../../../../evolution-data-server/addressbook/libebook/e-book.c:3329: undefined reference to `e_source_list_peek_default_source' collect2: ld returned 1 exit status libtool: install: error: relink `libebook-1.2.la' with the above command before installing it make[2]: *** [install-libLTLIBRARIES] Fehler 1 make[2]: Verlasse Verzeichnis '/home/tom/src/evolution/obj/evolution-data-server/addressbook/libebook' make[1]: *** [install-am] Fehler 2 make[1]: Verlasse Verzeichnis '/home/tom/src/evolution/obj/evolution-data-server/addressbook/libebook' Looking at the installed libraries, nm tells me that the function indeed is undefined: t...@ubuntu:~/src/evolution/obj/evolution-data-server/addressbook/libebook$ nm /opt/evo/lib/libebook-1.2.so /opt/evo/lib/libedataserver-1.2.so |grep peek_def U e_source_list_peek_default_source 00015eed T e_source_list_peek_default_source But there are more functions like e_source_list... which are undefined according to nm, but about which the linker does not complain. -- thomas ___ 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] Can't build evolution-data-server master on ubuntu maverick
Am Dienstag, den 07.09.2010, 07:06 -0400 schrieb Matthew Barnes: > On Sat, 2010-09-04 at 09:12 +0200, Thomas Mittelstaedt wrote: > > More errors trying to compile gtkhtml: > > Use ./configure --disable-deprecated-warning-flags to work around the > GdkGC errors. GTK+ deprecated GdkGC very late in the GNOME development > cycle and we're not going to deal with it this close to a stable > release. > > Passing this option won't be necessary once the version becomes 2.32. > It's enabled by default for unstable versions, disabled by default for > stable versions. > > ___ > evolution-hackers mailing list > evolution-hackers@gnome.org > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers Thank you, that worked to build gtkhtml. Some oddity about autogen.sh, though: I usually executed autogen.sh from /obj/gtkhtml via PKG_CONFIG_PATH=/opt/evo/lib/pkgconfig/ CC='ccache gcc' CFLAGS=-g bash ./autogen.sh --prefix='/opt/evo' --disable-deprecated-warning-flags But autogen.sh would not do its job, i.e. regenerating the configure script. So, it called the existing ../../gtkhtml/configure which was old. I had to go to the source directory, execute autogen.sh from there and interrupt it after it called configure, since this is supposed be done from the object directory. -- thomas ___ 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] evolution-kolab: Subclassing and extending IMAPX
Hi everyone. After some time working on different places within our Plugin, I'm back to our IMAPX part. We would like to use the IMAPX implementation for our backends as well as for the Evolution Email part when Kolab access is configured. Thing is, we cannot just use the plain IMAPX implementation since we need to support the IMAP ANNOTATEMORE draft to access Kolab's (i.e. Cyrus') folder annotations to tell the different folder types apart. Distinguishing between the different folder types is vital because it lets us know which entries the respective folders hold (Email, Contacts, TODOs, Calendar entries, ...). Depending on the folder type, each of our IMAP-Providers (Email in Evolution, Address and Calendar in the backends) will care for a given folder type or a set of folder types. When in Email context - i.e. within Evolution - our IMAPX derivative would not display Address folders or Calendar folders. The Address provider will only care for contact folder types, and the Calendar provider will take care of TODOs, notes, appointments etc. (in short: all Calendar data). Now, we have several issues here. Presently, this whole folder annotation stuff which is implemented in the Cyrus imapd (which is what the Kolab people use) is based on version 05(!) of the IMAP ANNOTATEMORE draft and it will stay this way for some time. The IMAP ANNOTATEMORE draft is what eventually turned into RFC5464 "The IMAP METADATA Extension", but RFC5464 is not what Cyrus currently implements. There are efforts to incorporate RFC5464 into a future release of Cyrus (its in the plannings for 2.4, current stable is 2.3). It will be quite a while, maybe years, before this will happen, and in the meantime we will be stuck with this early version of the ANNOTATEMORE draft. Up to version 07 of the draft, the old ANNOTATEMORE syntax and semantics are used and Cyrus advertises this in it's CAPABILITY response. This was changed afterwards and turned into METADATA before the final draft version 10 (the intermediate ANNOTATEMORE2 has never been implemented anywhere, AFAIK). ANNOTATEMORE and METADATA differ in the syntax they use and they have some minor semantic differences. Why am I writing this: IMAPX supports neither ANNOTATEMORE nor METADATA. My initial thought of patching IMAPX directly IMHO does not make too much sense presently because there is no imapd as yet which supports RFC5464 (true??) and ANNOTATEMORE is a draft and it's already been obsoleted by RFC5464 (so littering the IMAPX code with ANNOTATEMORE would not be too nice). This made me think whether we could extend IMAPX within our plugin and the ANNOTATEMORE (and METADATA) extensions could prove their ground there first, before finally being pulled upstream, if the Evolution maintainers would wish for that. Apart from the ANNOTATEMORE/METADATA extensions, which are upstream candidates, there are some Kolab-specific extensions, which most probably do not make sense upstream. These could be kept within the plugin code, even if the ANNOTATEMORE/METADATA should get pulled upstream and subsequently removed from our plugin code some day. The Kolab extensions include an API extension to IMAPX which enables us to configure a "context" into IMAPX. The "context" would be defined by the set of folder type a certain IMAPX instance should care for. By default, it would be "every folder but the known Kolab PIM folders". This default would be used within Evolution, so Evolution does not need to know about an extended API and use the provider as-is (it would then not present Kolab PIM folders to the Email frontend). From within our backend code, we could re-configure the respective provider instances via the extended API as to care for contact folders (EBookBackend) and for calendar data (ECalBackend) only. This way, we would still have multiple access to the IMAP server, but each mailbox would only be accessed by one IMAPX provider instance at a time (left alone the "delete mailbox" part, for which we will have to think up a good solution, still). The folder annotations can be retrieved without actually SELECTing a mailbox. Each provider instance would keep it's own cache, but would cache it's own folder types only. This way, there should not occure any duplicate caching. Does this sound "sound" to you? :-) IF it does, then the next question would be how to do that technically. From within our plugin code, we cannot directly access IMAPX headers, since (for good reason) they are not installed (and we would like to be able to link against installed Evo and E-D-S libs for user convenience). Still, I would like to avoid duplicating all of IMAPX within our plugin, but instead use the existing code wherever possible and just redefine the single functions which we need to extend or change. This would keep a patchset as small as possible while not really diverting from upstream. Due to time constraints we cannot currently car
