GNOME Bugzilla – Bug 590251
Does not compile with evo/eds master
Last modified: 2009-10-02 10:37:30 UTC
Evolution 2.27.5 + dbus-hybrid branch mv -f .deps/exchange-config-listener.Tpo .deps/exchange-config-listener.Po mv -f .deps/exchange-autoconfig-wizard.Tpo .deps/exchange-autoconfig-wizard.Po Found cached translation database exchange-component.c:145: warning: unused parameter ‘servant’ exchange-component.c:147: warning: unused parameter ‘select_item’ exchange-component.c:148: warning: unused parameter ‘ev’ exchange-component.c:164: warning: unused parameter ‘ev’ exchange-component.c:194: warning: unused parameter ‘servant’ exchange-component.c:195: warning: unused parameter ‘ev’ exchange-component.c:206: warning: unused parameter ‘user_data’ exchange-component.c:213: warning: unused parameter ‘servant’ exchange-component.c:214: warning: unused parameter ‘ev’ exchange-component.c:224: warning: unused parameter ‘servant’ exchange-component.c:225: warning: unused parameter ‘now_interactive’ exchange-component.c:226: warning: unused parameter ‘new_view_xid’ exchange-component.c:227: warning: unused parameter ‘ev’ exchange-component.c:293: warning: unused parameter ‘revision’ Merging translations into GNOME_Evolution_Exchange_Storage_2.28.server. exchange-component.c:362: warning: unused parameter ‘config_listener’ exchange-component.c:393: warning: unused parameter ‘config_listener’ exchange-component.c:413: warning: unused parameter ‘status’ exchange-change-password.c:46: warning: unused parameter ‘entry’ mv -f .deps/exchange-component.Tpo .deps/exchange-component.Po mv -f .deps/exchange-change-password.Tpo .deps/exchange-change-password.Po exchange-storage.c:126: warning: unused parameter ‘account’ exchange-storage.c:139: warning: unused parameter ‘account’ mv -f .deps/exchange-storage.Tpo .deps/exchange-storage.Po mv -f .deps/exchange-migrate.Tpo .deps/exchange-migrate.Po mv -f .deps/ximian-connector-setup.Tpo .deps/ximian-connector-setup.Po /bin/sh ../libtool --tag=CC --mode=link gcc -g -O0 -Wl,--allow-shlib-undefined -fgnu89-inline -DG_DISABLE_DEPRECATED -DPANGO_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -Wall -Wextra -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter -Wdeclaration-after-statement -Werror-implicit-function-declaration -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-declarations -Wmissing-include-dirs -Wmissing-noreturn -Wnested-externs -Wpointer-arith -Wredundant-decls -Wundef -Wwrite-strings -Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare -Wno-sign-compare -L/home/dbus/opt/gnome2/lib -L/home/dbus/opt/gnome2/lib -o exchange-connector-setup ximian-connector-setup.o exchange-config-listener.o exchange-autoconfig-wizard.o -lldap -llber -lresolv -lnsl -Wl,-R/usr/lib/evolution/2.26 -pthread -L/home/dbus/opt/gnome2/lib -L/usr/lib/evolution/2.26 -L/lib -leshell -leutil -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lgnomevfs-2 -lgnomecanvas-2 -lgnome-2 -lpopt -lart_lgpl_2 -ledataserverui-1.2 -ledata-book-1.2 -lebook-1.2 -ldbus-glib-1 -ldbus-1 -ledata-cal-1.2 -lebackend-1.2 -lecal-1.2 -lical -licalss -licalvcal -lglade-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lz -lfontconfig -lcamel-provider-1.2 -lcamel-1.2 -ledataserver-1.2 -lsqlite3 -lxml2 -lgconf-2 -lsoup-2.4 -lbonobo-2 -lgio-2.0 -lbonobo-activation -lgmodule-2.0 -lORBit-2 -lgthread-2.0 -lrt -lgobject-2.0 -lglib-2.0 -Wl,-R/usr/lib/evolution/2.26 -pthread -L/home/dbus/opt/gnome2/lib -L/usr/lib/evolution/2.26 -L/lib -leshell -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lgnomevfs-2 -lgnomecanvas-2 -lgnome-2 -lpopt -lart_lgpl_2 -ledataserverui-1.2 -lglade-2.0 -lebook-1.2 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lz -lfontconfig -ledataserver-1.2 -ldbus-glib-1 -lxml2 -lgconf-2 -lbonobo-2 -lbonobo-activation -lORBit-2 -lgthread-2.0 -lrt -ldbus-1 -lebackend-1.2 -lexchange-storage-1.2 -lsoup-2.4 -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 main.c:76: warning: unused parameter ‘factory’ main.c:97: warning: unused parameter ‘factory’ main.c:97: warning: unused parameter ‘data’ main.c:142: warning: unused parameter ‘factory’ main.c:142: warning: unused parameter ‘data’ main.c: In function ‘setup_addressbook_factory’: main.c:152: error: implicit declaration of function ‘e_data_book_factory_new’ main.c:152: warning: nested extern declaration of ‘e_data_book_factory_new’ main.c:152: warning: assignment makes pointer from integer without a cast main.c:163: error: implicit declaration of function ‘e_data_book_factory_register_backend’ main.c:163: warning: nested extern declaration of ‘e_data_book_factory_register_backend’ main.c:173: error: implicit declaration of function ‘e_data_book_factory_activate’ main.c:173: warning: nested extern declaration of ‘e_data_book_factory_activate’ make[2]: *** [main.o] Error 1 make[2]: *** Waiting for unfinished jobs.... mv -f .deps/migr-test.Tpo .deps/migr-test.Po libtool: link: gcc -g -O0 -Wl,--allow-shlib-undefined -fgnu89-inline -DG_DISABLE_DEPRECATED -DPANGO_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -Wall -Wextra -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter -Wdeclaration-after-statement -Werror-implicit-function-declaration -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-declarations -Wmissing-include-dirs -Wmissing-noreturn -Wnested-externs -Wpointer-arith -Wredundant-decls -Wundef -Wwrite-strings -Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-sign-compare -Wno-sign-compare -o exchange-connector-setup ximian-connector-setup.o exchange-config-listener.o exchange-autoconfig-wizard.o -Wl,-R/usr/lib/evolution/2.26 -pthread -Wl,-R/usr/lib/evolution/2.26 -pthread -L/home/dbus/opt/gnome2/lib -L/usr/lib/evolution/2.26 -L/lib -leutil -L/usr/lib /home/dbus/opt/gnome2/lib/libedata-book-1.2.so /home/dbus/opt/gnome2/lib/libedata-cal-1.2.so /home/dbus/opt/gnome2/lib/libecal-1.2.so -lical -licalss -licalvcal /home/dbus/opt/gnome2/lib/libcamel-provider-1.2.so -leshell -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lgnomevfs-2 -lgnomecanvas-2 -lgnome-2 -lpopt -lart_lgpl_2 /home/dbus/opt/gnome2/lib/libedataserverui-1.2.so /home/dbus/opt/gnome2/lib/libebook-1.2.so /home/dbus/opt/gnome2/lib/libcamel-1.2.so -lsqlite3 -lkrb4 -ldes425 -lssl3 -lsmime3 -lnss3 -ldbus-glib-1 -ldbus-1 /home/dbus/opt/gnome2/lib/libebackend-1.2.so /home/dbus/opt/gnome2/lib/libexchange-storage-1.2.so -lkrb5 -lk5crypto -lcom_err -lgssapi_krb5 /home/dbus/opt/gnome2/lib/libedataserver-1.2.so -lbonobo-2 -lbonobo-activation -lORBit-2 -lplc4 -lplds4 -lnspr4 -lglade-2.0 -lgtk-x11-2.0 /home/dbus/opt/gnome2/lib/libxml2.so -ldl -lm -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lz -lfontconfig -lgthread-2.0 -lrt -lgconf-2 -lgnome-keyring -lpthread -lldap -llber -lresolv -lnsl -lsoup-2.4 -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -pthread -Wl,-rpath -Wl,/home/dbus/opt/gnome2/lib -Wl,-rpath -Wl,/home/dbus/opt/gnome2/lib rm GNOME_Evolution_Exchange_Storage_2.28.server.in make[2]: Leaving directory `/home/dbus/src/git/evolution-exchange/storage' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/dbus/src/git/evolution-exchange' make: *** [all] Error 2
I have a private branch that converts the addressbook and calendar backends in evolution-exchange to GTypeModules. It's part of my ongoing effort to kill off the exchange-storage process. Haven't tested it yet, but could serve as a starting point at least. I'll post a patch shortly.
Created attachment 139576 [details] [review] Convert Bonobo servers to GTypeModules Here's an initial patch. Note this builds off my patch in bug #456240 comment #8, which moves all Exchange-related code in E-D-S to Evolution-Exchange. Apply that, then apply this.
Created attachment 140287 [details] [review] Patch based on Evolution Exchange 2.27.90 Here's the same patch adapted to current git master. It does not depend on bug #456240, or even on the dbus-hybrid branch. Not tested because I don't have access to an Exchange 2003 server at the moment, but builds fine and passes distcheck.
*** Bug 592158 has been marked as a duplicate of this bug. ***
Will look through the patch and incorporate changes for exchange to work with the dbus changes. Created a bug in eds for supporting multiple factories, http://bugzilla.gnome.org/show_bug.cgi?id=592159 .
Matt, are you planning to remove the mail-stub during evolution 2.30 release ? I see that with this patch, exchange backend will become like any other backends in eds. So if the mail-stub is going to be removed for 2.30, this makes sense. Then it means i need not work on http://bugzilla.gnome.org/show_bug.cgi?id=592159 :)
(In reply to comment #6) > Matt, are you planning to remove the mail-stub during evolution 2.30 release ? I hope to, yes. I have a good start on it already.
Fine, just ensure if it would be possible for completion in 2.30. Once we go ahead with these changes, it would become hard to get back.. I will test this patch with exchange tomorrow to ensure, address-book/cal works fine. If it does, i will close the bug 592159 and this patch can be taken in. I wonder if there is any other external backend written like exchange using different address-space. Do you know any ? I would probably discuss it in e-h list to ensure that no other backend's use it like exchange, we would need to fix bug 592159.
(In reply to comment #8) > Fine, just ensure if it would be possible for completion in 2.30. Once we go > ahead with these changes, it would become hard to get back.. I don't know why we would want to revert back to the old design. IIUC, evolution-exchange was designed as a separate process simply to bypass GPL linking restrictions back before it was open-sourced. There's no need for a separate process these days. Also, I'm not sure I understand the urgency over the mail-stub part. It looks like it's independent from the data server modules. Or maybe I'm missing something? In other words, just as a temporary stop-gap, couldn't the exchange-storage process continue to provide mailer functionality while the addressbook and calendar backends run directly in the data server process? In any case, I will try to complete the mail-stub removal by 2.30. > I wonder if there is any other external backend written like exchange using > different address-space. Do you know any ? I don't know of any. Even if there are, is that something we want to continue to support?
*** Bug 592268 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > (In reply to comment #8) > > Fine, just ensure if it would be possible for completion in 2.30. Once we go > > ahead with these changes, it would become hard to get back.. > > I don't know why we would want to revert back to the old design. IIUC, > evolution-exchange was designed as a separate process simply to bypass GPL > linking restrictions back before it was open-sourced. There's no need for a > separate process these days. > > Also, I'm not sure I understand the urgency over the mail-stub part. It looks > like it's independent from the data server modules. Or maybe I'm missing > something? In other words, just as a temporary stop-gap, couldn't the > exchange-storage process continue to provide mailer functionality while the > addressbook and calendar backends run directly in the data server process? There are some advantages in maintaining all components in a single address-space such as, a) Maintaining a single connection with the server for all components a) Sharing the folder hierarchies There can be more. These are the things we may need to address while thinking of removing mail-stub and bring cal/address-book components into eds. Sharing the connections with all the components would be the major part which would need to be fixed. iirc I think exchange connections are limited to some number (not sure about the exact number). Already exchange process uses two connections for sync/async sessions. > > In any case, I will try to complete the mail-stub removal by 2.30. > > > I wonder if there is any other external backend written like exchange using > > different address-space. Do you know any ? > > I don't know of any. Even if there are, is that something we want to continue > to support? If some backends were written like exchange, we would need to support them.
For connection problem, may be we could create a dbus-service which can act as an auth-agent to share the connection with the processes, is it possible? For groupwise connector, i know its possible this way to share connections, not sure for exchange. Matt, have you thought about the cases at comment #11 ? It would be better to have solutions for these before getting the code in. I will be testing the patch today and if cases at comment #11 can be dealt with, we can go ahead with committing the patch.
Matt, with ur patch and removing e_data_book_factory references from exhchange, I could build exchange. But it wont make exchange work as it depends on global_exchange_component, needs more changes. Varadhan, it would be great if you could provide some info on the above concern areas so that we can decide on a right way for exchange.. To be clear. am not against these changes :) just being cautious for 2.30. These tasks needs to be done now or sometime anyways..
Note that global_exchange_component is a Bonobo "EvolutionComponent" and will have to die when kill-bonobo is merged, so we're jumping in the deep end here one way or another. I don't have any answers yet. Need to finish the calendar and then think on this some more.
I think the only problem is with managing the connections. Please open a new bug for that and I will put a solution for the same. Commit this patch for the build break.
You got it. Committed the patch to master: http://git.gnome.org/cgit/evolution-exchange/commit/?id=10ea5b8144ba5a5f34a13e0fec450437d4aeb63f There's some valuable discussion here. Why don't we leave this bug open and continue working on the connection issue and anything else eds-dbus broke.
Adjusting summary to broaden the scope of the bug.
*** Bug 593609 has been marked as a duplicate of this bug. ***
Let me try it.
Created commit c151611 in eex master (2.29.1+). What I noticed is that the camel operations are blocking evolution's UI, but the fix should be done in evolution, to not call camel operations in a main thread. (For example choosing a large folder (600+ messages), which wasn't fetched in yet, takes some time, during which the UI is frozen. Other bug, other effort.) The next step is a movement of evo plugin to eex package.