Re: [Evolution-hackers] evolution-exchange 2.32.0 build error
On Sun, 2010-11-14 at 20:52 +0100, Sasa Ostrouska wrote: On Sun, Nov 14, 2010 at 12:46 PM, Sasa Ostrouska cas...@gmail.com wrote: On Sat, Nov 13, 2010 at 11:54 AM, tjoen tj...@dds.nl wrote: On Sat, 2010-11-13 at 01:18 +0100, Sasa Ostrouska wrote: I have troubles with evolution-exchange. CCLD libebookbackendexchange.la libtool: link: only absolute run-paths are allowed make[2]: *** [libebookbackendexchange.la] Error 1 Try a $ make -n log Search in log for libebookbackendexchange.la Here is what I get: s...@quadser:~/evolution-exchange-2.32.0$ make -n evo-exch.log make[3]: *** No rule to make target `../../server/lib/libexchange.la', Even better would be: make -n evo-exch.log 21 Also attaching the complete log. Some mailinglists don't like attachments. Better is to paste only the relevant libebookbackendexchange.la part. I think it is someting like a -Llib. If not, then an error in one of the .la ___ 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] evolution-exchange 2.32.0 build error
On Mon, Nov 15, 2010 at 10:13 AM, tjoen tj...@dds.nl wrote: On Sun, 2010-11-14 at 20:52 +0100, Sasa Ostrouska wrote: On Sun, Nov 14, 2010 at 12:46 PM, Sasa Ostrouska cas...@gmail.com wrote: On Sat, Nov 13, 2010 at 11:54 AM, tjoen tj...@dds.nl wrote: On Sat, 2010-11-13 at 01:18 +0100, Sasa Ostrouska wrote: I have troubles with evolution-exchange. CCLD libebookbackendexchange.la libtool: link: only absolute run-paths are allowed make[2]: *** [libebookbackendexchange.la] Error 1 Try a $ make -n log Search in log for libebookbackendexchange.la Here is what I get: s...@quadser:~/evolution-exchange-2.32.0$ make -n evo-exch.log make[3]: *** No rule to make target `../../server/lib/libexchange.la', Even better would be: make -n evo-exch.log 21 Also attaching the complete log. Some mailinglists don't like attachments. Better is to paste only the relevant libebookbackendexchange.la part. I think it is someting like a -Llib. If not, then an error in one of the .la Here we go, the last few lines: mv -f .deps/libexchange_storage_la-exchange-hierarchy-webdav.Tpo .deps/libexchange_storage_la-exchange-hierarchy-webdav.Plo echo CC libexchange_storage_la-exchange-hierarchy.lo;/bin/sh ../../libtool --silent --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -DG_DISABLE_DEPRECATED -DPANGO_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DE_BOOK_DISABLE_DEPRECATED -DE_CAL_DISABLE_DEPRECATED -DG_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES -DGSEAL_ENABLE -Wall -Wextra -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter -Wdeclaration-after-statement -Werror-implicit-function-declaration -Wformat-security -Winit-self -Wmissing-declarations -Wmissing-include-dirs -Wmissing-noreturn -Wnested-externs -Wpointer-arith -Wredundant-decls -Wundef -Wwrite-strings -fno-strict-aliasing -DG_LOG_DOMAIN=\evolution-exchange-storage\ -DPREFIX=\/usr\ -DSYSCONFDIR=\/usr/etc\ -DDATADIR=\/usr/share\ -DLIBDIR=\/usr/share\ -DCONNECTOR_LOCALEDIR=\/usr/share/locale\ -DCONNECTOR_GLADEDIR=\\ -I../.. -I../../server/lib -I../../server/xntlm -I../../server/lib -pthread -DQT_SHARED -DORBIT2=1 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14 -I/usr/lib64/qt/include/QtGui -I/usr/include/drm -I/usr/include/libdrm -I/usr/lib64/qt/include/QtCore -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/libxml2 -I/usr/include/libsoup-2.4 -DCAMEL_HAVE_NSS -DCAMEL_HAVE_SSL -pthread -DORBIT2=1 -DQT_SHARED -I/usr/include/evolution-data-server-2.32 -I/usr/include/nspr -I/usr/include/nss -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/gconf/2 -I/usr/include/libsoup-2.4 -I/usr/include/orbit-2.0 -I/usr/include/libical -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14 -I/usr/lib64/qt/include/QtGui -I/usr/include/drm -I/usr/include/libdrm -I/usr/lib64/qt/include/QtCore -I/usr/include/evolution-data-server-2.32/groupwise -I/usr/include -DLDAP_DEPRECATED-g -O2 -fno-strict-aliasing -MT libexchange_storage_la-exchange-hierarchy.lo -MD -MP -MF .deps/libexchange_storage_la-exchange-hierarchy.Tpo -c -o libexchange_storage_la-exchange-hierarchy.lo `test -f 'exchange-hierarchy.c' || echo './'`exchange-hierarchy.c mv -f .deps/libexchange_storage_la-exchange-hierarchy.Tpo .deps/libexchange_storage_la-exchange-hierarchy.Plo echo CC libexchange_storage_la-exchange-oof.lo;/bin/sh ../../libtool --silent --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -DG_DISABLE_DEPRECATED -DPANGO_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DE_BOOK_DISABLE_DEPRECATED -DE_CAL_DISABLE_DEPRECATED -DG_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES -DGSEAL_ENABLE -Wall -Wextra -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter -Wdeclaration-after-statement -Werror-implicit-function-declaration -Wformat-security -Winit-self -Wmissing-declarations -Wmissing-include-dirs -Wmissing-noreturn -Wnested-externs -Wpointer-arith -Wredundant-decls -Wundef -Wwrite-strings -fno-strict-aliasing -DG_LOG_DOMAIN=\evolution-exchange-storage\ -DPREFIX=\/usr\ -DSYSCONFDIR=\/usr/etc\ -DDATADIR=\/usr/share\ -DLIBDIR=\/usr/share\ -DCONNECTOR_LOCALEDIR=\/usr/share/locale\ -DCONNECTOR_GLADEDIR=\\ -I../.. -I../../server/lib -I../../server/xntlm -I../../server/lib -pthread -DQT_SHARED -DORBIT2=1 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0
[Evolution-hackers] A quick evo-* git head build question
my latest build attempt with glib, gtk+, evo-* all at git head appears to fail due to some api changes. Could someone post me the (highest?) tag/branch levels of glib, gtk+ that will allow me to build evo-* git head? thanks, reid ___ 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] A quick evo-* git head build question
On Mon, 2010-11-15 at 08:49 -0500, Reid Thompson wrote: my latest build attempt with glib, gtk+, evo-* all at git head appears to fail due to some api changes. Could someone post me the (highest?) tag/branch levels of glib, gtk+ that will allow me to build evo-* git head? The master branch of gtk+ is for version 3, which we don't support yet. The latest release of gtk+ which Evolution can use is 2.23.2, or the gtk-2-24 branch in git. ___ 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] Rethinking account management
Let's talk D-Bus. I've started integrating the redesigned, key-file based ESource APIs in a branch of Evolution-Data-Server and so far it's actually simplifying the affected code. I'm leaving mail aside for now and just focusing on calendars and address books. I'm gonna have to remove some functions from libebook and libecal which don't make sense anymore. More about those later. But I also realized I'm gonna have to change the getCal() and getBook() D-Bus methods. I was a bit horrified to realize over the weekend the way we select a backend from the factory processes when requesting a new EBook or ECal. We convert an ESource object to XML and transmit the -entire- XML string over D-Bus, only to have the factory process reconstruct the ESource object from the XML string, extract the URI string from the ESource object, and extract the scheme from the URI. The scheme is used as a hash table key for registered backends. Holy convoluted design, Bat Man! With the new APIs, apart from GConf migration we won't be constructing ESources from XML anymore. So here's how it's gonna work: getCal() and getBook() will just take the ESource's UID string, the factory process will look up the corresponding ESource object from its own registry and call e_source_get_backend() to get the hash table key. Done. That part's easy. What I'm concerned about is avoiding a repeat of the issues we encountered last cycle when we changed the local backend name from file to local. In particular, we need to make sure the client and servers are using the same D-Bus API at run time. This is proving to be a real problem as users upgrade from Evolution 2.30 to 2.32 but leave the factory processes from 2.30 running. There's some debate about the best way to handle D-Bus API changes, but after talking to a few colleagues it seems the simplest approach is to append a digit to the interface name, like we do for shared libraries. I kinda wanted to tweak the names anyway, so here's my proposal for the new D-Bus interface names: Old: org.gnome.evolution.dataserver.addressbook.BookFactory org.gnome.evolution.dataserver.calendar.CalFactory org.gnome.evolution.dataserver.addressbook.Book org.gnome.evolution.dataserver.calendar.Cal New: org.gnome.evolution.dataserver.AddressBookFactory.0 org.gnome.evolution.dataserver.CalendarFactory.0 org.gnome.evolution.dataserver.AddressBook.0 org.gnome.evolution.dataserver.Calendar.0 In the future, if we have to break a D-Bus interface again we'll increment the digit. Then if the user upgrades E-D-S to a version that implements Calendar.1 but is still running an e-calendar-factory that implements Calendar.0, then when Evolution is launched the session bus will have to relaunch the upgraded e-calendar-factory binary and the old e-calendar-factory process will lose its well-known D-Bus name (at least I think that's how it works... in any case, D-Bus knows what to do). If there's no objections I'd like to get new interface names into 2.91 now so I can increment the interface versions on my account-management branch and not have to worry about this anymore. ___ 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] evolution-exchange 2.32.0 build error
On Mon, 2010-11-15 at 10:24 +0100, Sasa Ostrouska wrote: On Mon, Nov 15, 2010 at 10:13 AM, tjoen tj...@dds.nl wrote: On Sun, 2010-11-14 at 20:52 +0100, Sasa Ostrouska wrote: On Sun, Nov 14, 2010 at 12:46 PM, Sasa Ostrouska cas...@gmail.com wrote: On Sat, Nov 13, 2010 at 11:54 AM, tjoen tj...@dds.nl wrote: On Sat, 2010-11-13 at 01:18 +0100, Sasa Ostrouska wrote: I have troubles with evolution-exchange. CCLD libebookbackendexchange.la libtool: link: only absolute run-paths are allowed make[2]: *** [libebookbackendexchange.la] Error 1 Looks like this one is solved because below is a different error. ... make[3]: *** No rule to make target `../../server/lib/libexchange.la', needed by `libexchange-storage.la'. Stop. make[3]: Leaving directory `/home/sasa/evolution-exchange-2.32.0/server/storage' Doesn't know how to make libexchange.la. Look in server/storage/Makefile why. ___ 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] evolution-exchange 2.32.0 build error
On Mon, Nov 15, 2010 at 6:41 PM, tjoen tj...@dds.nl wrote: On Mon, 2010-11-15 at 10:24 +0100, Sasa Ostrouska wrote: On Mon, Nov 15, 2010 at 10:13 AM, tjoen tj...@dds.nl wrote: On Sun, 2010-11-14 at 20:52 +0100, Sasa Ostrouska wrote: On Sun, Nov 14, 2010 at 12:46 PM, Sasa Ostrouska cas...@gmail.com wrote: On Sat, Nov 13, 2010 at 11:54 AM, tjoen tj...@dds.nl wrote: On Sat, 2010-11-13 at 01:18 +0100, Sasa Ostrouska wrote: I have troubles with evolution-exchange. CCLD libebookbackendexchange.la libtool: link: only absolute run-paths are allowed make[2]: *** [libebookbackendexchange.la] Error 1 Looks like this one is solved because below is a different error. Yeah, it seems strange to me, why this error solved out itself. Maybe is the setup I use with the build-system. ... make[3]: *** No rule to make target `../../server/lib/libexchange.la', needed by `libexchange-storage.la'. Stop. make[3]: Leaving directory `/home/sasa/evolution-exchange-2.32.0/server/storage' Doesn't know how to make libexchange.la. Look in server/storage/Makefile why. Ok, thanks for the tip, will look into that Makefile, but I suspect that most probably all of that is caused by a wrongly installed nss. Where I'm looking right now. This of course then makes confusion on e-d-s which then makes problems on evolution-exchange. Thanks for now. Rgds Saxa ___ 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 - Nov 17 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates - 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
Re: [Evolution-hackers] Rethinking account management
Hi, On Mon, 2010-11-15 at 11:45 -0500, Matthew Barnes wrote: I was a bit horrified to realize over the weekend the way we select a backend from the factory processes when requesting a new EBook or ECal. We convert an ESource object to XML and transmit the -entire- XML string over D-Bus, only to have the factory process reconstruct the ESource object from the XML string, extract the URI string from the ESource object, and extract the scheme from the URI. The scheme is used as a hash table key for registered backends. Well, it's not complete, the reconstructed ESource is passed into e_data_book_new, so the backend can access it and knows where to connect. With the new APIs, apart from GConf migration we won't be constructing ESources from XML anymore. So here's how it's gonna work: getCal() and getBook() will just take the ESource's UID string, the factory process will look up the corresponding ESource object from its own registry and call e_source_get_backend() to get the hash table key. Done. That's kinda limiting, isn't it? As you allow only saved sources to be opened, though for example all test suits are not saving their sources, but just construct them on the fly and pass them to the factory. ... If there's no objections I'd like to get new interface names into 2.91 now so I can increment the interface versions on my account-management branch and not have to worry about this anymore. Sounds fine to me. 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
