[needs-packaging] evolution-mapi

[Andrew Starr-Bochicchio]

Evolution extension for MS Exchange 2007 servers
License: GPLv2+
URL: http://www.go-evolution.org/MAPIProvider
Source: http://ftp.gnome.org/pub/gnome/sources/evolution-mapi/

TO DO:

  Necessary:

    Upgrade: evolution-data-server to (>= 2.25.2) Bug #320299
                    evolution to (>= 2.25.2) Bug #320329

  Probably should also:

    Sync: openchange (1:0.8-1) from Debian Experimental
                    samba4 (4.0.0~alpha6-1) from Debian Experimental - DONE

ISSUES:

This error keeps this package from building even after resolving the dependencies. Following the advise from evolution-mapi's FAQ (http://www.go-evolution.org/MAPI_FAQ#Compiling_from_source), the package builds correctly. Line 404 of /usr/include/samba-4.0/ndr.h must be commented out. This is provided by libndr-dev from samba4. I'm not sure how to handle this packaging wise.

In file included from /usr/include/samba-4.0/dcerpc.h:32,
                 from /usr/include/libmapi/libmapi.h:46,
                 from exchange-mapi-connection.h:30,
                 from exchange-mapi-folder.c:24:
/usr/include/samba-4.0/ndr.h:404: error: expected declaration specifiers or ‘...’ before ‘comparison_fn_t’
exchange-mapi-folder.c: In function ‘exchange_mapi_peek_folder_list’:
exchange-mapi-folder.c:130: warning: dereferencing type-punned pointer will break strict-aliasing rules
exchange-mapi-folder.c:135: warning: dereferencing type-punned pointer will break strict-aliasing rules
exchange-mapi-folder.c: In function ‘exchange_mapi_folder_list_free’:
exchange-mapi-folder.c:164: warning: dereferencing type-punned pointer will break strict-aliasing rules
exchange-mapi-folder.c:173: warning: dereferencing type-punned pointer will break strict-aliasing rules
exchange-mapi-folder.c: In function ‘exchange_mapi_folder_list_add’:
exchange-mapi-folder.c:183: warning: dereferencing type-punned pointer will break strict-aliasing rules
exchange-mapi-folder.c:190: warning: dereferencing type-punned pointer will break strict-aliasing rules
exchange-mapi-folder.c:198: warning: dereferencing type-punned pointer will break strict-aliasing rules
make[4]: *** [exchange-mapi-folder.lo] Error 1
make[4]: Leaving directory `/home/andrew/Desktop/ev-mapi/evolution-mapi-0.25.5/src/libexchangemapi'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/andrew/Desktop/ev-mapi/evolution-mapi-0.25.5/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/andrew/Desktop/ev-mapi/evolution-mapi-0.25.5'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/andrew/Desktop/ev-mapi/evolution-mapi-0.25.5'
make: *** [debian/stamp-makefile-build] Error 2
dpkg-buildpackage: failure: debian/rules build gave error exit status 2
debuild: fatal error at line 1329:
dpkg-buildpackage -rfakeroot -D -us -uc failed

[Jelmer Vernooij (jelmer)]

I'm working on improving your packaging to allow building against Evolution 2.24.3 (which is in Jaunty at the moment) and on installing in the right places.

[Andrew Starr-Bochicchio (andrewsomething)]

@ Jelmer

Feel free, I don't mind the help. Though hopefully, evo and e-d-s 2.25.x should land in Jaunty soon.

[Jelmer Vernooij (jelmer)]

My latest branch builds properly against the version in jaunty, and loading the plugin in evolution works - allowing the creation of Exchange MAPI accounts.

I don't have a Exchange server handy here at the moment, so it would be nice if other people could the package a try. I've uploaded a package built from this branch to my own PPA; https://edge.launchpad.net/~jelmer/+archive/ppa

The following things still need to be fixed:

 * Right now we regenerate configure as part of the Debian build process since we patch configure.in. I'm not sure the way I do this at the moment is the cleanest way.
 * There are several remaining lintian warnings that need to be fixed:
E: evolution-mapi: pkg-has-shlibs-control-file-but-no-actual-shared-libs
W: evolution-mapi: postinst-has-useless-call-to-ldconfig
W: evolution-mapi: postrm-has-useless-call-to-ldconfig
W: evolution-mapi: binary-or-shlib-defines-rpath ./usr/lib/evolution/2.24/plugins/liborg-gnome-exchange-mapi.so /usr/lib/evolution/2.24
W: evolution-mapi: debian-changelog-file-is-a-symlink
W: libexchangemapi1.0-0: package-name-doesnt-match-sonames libexchangemapi-1.0-0

[Sebastien Bacher (seb128)]

thank you for your work there, some comments:
- the tarball have a COPYING, is that you who changed to COPYING.LGPL2 and COPYING.LGPL3? the sources states either can be used and the upstream COPYING is a LGPL one so what the COPYING says should be enough there
- the debian copyright doesn't needs to list that autotools are under GPL

not sure that the library split is required, is anything else going to use this one? the packaging changes Jelmer did are mostly incorrect though, running autotools at build time is not something desktop packages are doing so the rules change and the extra build-depends are not required, the version coded in the install files also means it'll not build using the new evolution-data-server which will be uploaded to jaunty

otherwise the packaging seems to be mostly correct

[Jelmer Vernooij (jelmer)]

On Mon, 2009-01-26 at 22:50 +0000, Sebastien Bacher wrote:
> thank you for your work there, some comments:
> - the tarball have a COPYING, is that you who changed to COPYING.LGPL2 and COPYING.LGPL3? the sources states either can be used and the upstream COPYING is a LGPL one so what the COPYING says should be enough there
Current SVN, on which the original packaging is based, has COPYING.LGPL2
and COPYING.LGPL3.

> - the debian copyright doesn't needs to list that autotools are under GPL
I've already fixed this (it's just not in my PPA yet), and corrected the
 fact that upstream is LGPL2.1 | LGPL3 rather than LGPL2+.

> not sure that the library split is required, is anything else going to
> use this one? the packaging changes Jelmer did are mostly incorrect
> though, running autotools at build time is not something desktop
> packages are doing so the rules change and the extra build-depends are
> not required, the version coded in the install files also means it'll
> not build using the new evolution-data-server which will be uploaded to
> jaunty
I had to patch configure.in to get it to build with the current version
of evolution (which works fine with evolution-mapi) and to get it to
build, because it requires a define for GNU_SOURCE (although that could
be somewhere else as well). When should I be regenerating configure in
this case if not at build-time ?

Cheers,

Jelmer

--
Jelmer Vernooij <email address hidden> - http://samba.org/~jelmer/
Jabber: <email address hidden>

[Sebastien Bacher (seb128)]

> When should I be regenerating configure in this case if not at build-time ?

the desktop packages usually have autotools patches which do the configure update, it's easier to run once the command using a known to work version than adding extra depends on relying on whatever version will be available at build time to be compatible with the source

[Jelmer Vernooij (jelmer)]

Ok, I've changed the package to not regenerate configure. The licensing information should also be up to date now.

The exchangemapi library is generic and should be usable by others (not aware of any other users of it at the moment though). Fwiw, the old exchange plugin also exported a similar library that is packaged separately.

[Andrew Starr-Bochicchio (andrewsomething)]

@ Sebastien
> - the tarball have a COPYING, is that you who changed to COPYING.LGPL2 and COPYING.LGPL3? the
> sources states either can be used and the upstream COPYING is a LGPL one so what the COPYING
> says should be enough there

For some reason the copyright information in SVN at the time of release differs from the tarball.

@ Jelmer

As I mentioned above, evo and e-d-s 2.25.x should be in Jaunty shortly, so the debate on when to regenerate configure, ect... is basically academic.

[Jelmer Vernooij (jelmer)]

On Tue, 2009-01-27 at 02:16 +0000, Andrew Starr-Bochicchio wrote:
> @ Jelmer
>
> As I mentioned above, evo and e-d-s 2.25.x should be in Jaunty shortly,
> so the debate on when to regenerate configure, ect... is basically
> academic.
There's two other changes I've made to the configure file as well:

 * Defining GNU_SOURCE (fixes the bug you mentioned earlier in this
report, related to libndr-dev). This one could also be fixed by just
overriding CFLAGS, of course.
 * Allowing linkage against libmapi > 0.8. This would matter for libmapi
0.8.1, which we hope to release soon (but may or may not end up in
jaunty).

I've also forwarded these (as well as the fix for linking against
2.24.3) upstream.

Cheers,

Jelmer
--
Jelmer Vernooij <email address hidden> / https://launchpad.net/~jelmer/
IRC: jelmer / Jabber: <email address hidden>

[Jelmer Vernooij (jelmer)]

On Tue, 2009-01-27 at 02:42 +0000, Jelmer Vernooij wrote:
> On Tue, 2009-01-27 at 02:16 +0000, Andrew Starr-Bochicchio wrote:
> > @ Jelmer
> >
> > As I mentioned above, evo and e-d-s 2.25.x should be in Jaunty shortly,
> > so the debate on when to regenerate configure, ect... is basically
> > academic.
> There's two other changes I've made to the configure file as well:
>
> * Defining GNU_SOURCE (fixes the bug you mentioned earlier in this
> report, related to libndr-dev). This one could also be fixed by just
> overriding CFLAGS, of course.
> * Allowing linkage against libmapi > 0.8. This would matter for libmapi
> 0.8.1, which we hope to release soon (but may or may not end up in
> jaunty).
>
> I've also forwarded these (as well as the fix for linking against
> 2.24.3) upstream.
The package now builds with current Jauntu and works from the linked
branch (also uploaded to my PPA). Do you still prefer to wait until
evolution 2.25.2 ? If not, I think it's ready to be uploaded to REVU.

Cheers,

Jelmer

--
Jelmer Vernooij <email address hidden>

[Sebastien Bacher (seb128)]

you can upload to revu, the jaunty version can be changed once the new evolution is uploaded if required

[Jelmer Vernooij (jelmer)]

On Wed, 2009-01-28 at 17:30 +0000, Sebastien Bacher wrote:
> you can upload to revu, the jaunty version can be changed once the new
> evolution is uploaded if required

Uploaded to REVU:
http://revu.ubuntuwire.com/details.py?package=evolution-mapi

Built from the bzr package at lp:~jelmer/evolution-mapi/ubuntu

--
Jelmer Vernooij <email address hidden> - http://samba.org/~jelmer/
Jabber: <email address hidden>

[James Ward (jamesward)]

Thanks Jelmer for putting this in a PPA. I gave it a try but it doesn't want to login:
(evolution:9081): libexchangemapi-WARNING **:
exchange-mapi-connection.c(136): exchange_mapi_connection_new: Login failed

Also I'm getting a strange warning:
exchange-mapi-connection.c(75): Entering mapi_profile_load
(evolution:9081): libexchangemapi-WARNING **:
MAPI profile database @ /home/jamesw/.evolution/mapi-profiles.ldb not found

Any ideas? Thanks.

[Gavin Hamill (gdh)]

Apologies if this end-user request is polluting a dev thread. Just installed Jaunty, added your ppa and installed evolution-mapi. all deps were dragged in just perfectly... alas evo complains:

root@gdh-jaunty:~# evolution
** Message:
 Google Group Not found

(evolution:4086): e-utils-WARNING **: can't load plugin '/usr/lib/evolution/2.24/plugins/liborg-gnome-exchange-mapi.so': /usr/lib/libexchangemapi-1.0.so.0: undefined symbol: icalrecurrencetype_as_string_r
Setting up initial mail tree
addressbook_migrate (0.0.0)
mapi_auto_detect_cb
commit
** (evolution:4086): DEBUG: mailto URL command: evolution %s
** (evolution:4086): DEBUG: mailto URL program: evolution
e-data-server-ui-Message: Key file does not have group 'Passwords-ExchangeMAPI'
libexchangemapi-Message: exchange-mapi-connection.c(130): exchange_mapi_connection_new: lock(connect_lock)

[mark stover (stovenator)]

I'm trying to build the package on Jaunty, amd64 using bzr version 86. The build seems to compile fine, but the debian packaging fails to link to libical, and libedataserverui correctly.

dpkg-shlibdeps: warning: symbol icalcomponent_as_ical_string_r used by debian/evolution-mapi/usr/lib/evolution-data-server-1.2/extensions/libecalbackendmapi.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol e_passwords_ask_password used by debian/evolution-mapi/usr/lib/evolution/2.24/plugins/liborg-gnome-exchange-mapi.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol e_passwords_forget_password used by debian/evolution-mapi/usr/lib/evolution/2.24/plugins/liborg-gnome-exchange-mapi.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol e_passwords_get_password used by debian/evolution-mapi/usr/lib/evolution/2.24/plugins/liborg-gnome-exchange-mapi.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol icalcomponent_as_ical_string_r used by debian/libexchangemapi1.0-0/usr/lib/libexchangemapi-1.0.so.0.0.0 found in none of the libraries.
dpkg-shlibdeps: warning: symbol icalrecurrencetype_as_string_r used by debian/libexchangemapi1.0-0/usr/lib/libexchangemapi-1.0.so.0.0.0 found in none of the libraries.

It appears that it is trying to link to the libical libraries that are included in evolution-dataserver-2.24 (but those are older libraries than the libical0 that's currently available on Jaunty).

Let me know if there's any more information you need.

[C de-Avillez (hggdh2)]

@mark stover: Jaunty has just updated Evo to 2.25.90; Jemel had the packages set for 2.24.x (which were then the available ones for Jaunty). This may be part of your issue.

[Jelmer Vernooij (jelmer)]

I'll have a look at uploading packages against 2.25.90.

[mark stover (stovenator)]

I've got 2.24.3 from Jaunty for Evolution and all the dev libraries. I'll wait until Jelmer re-ups for 2.25.90 and try again.

[mark stover (stovenator)]

Okay, so I installed a fresh version of Jaunty Jackalope x64 yesterday, did an apt-get upgrade to the latest everything (Alpha 4), and apt-get installed the following packages and their dependencies:

evolution, bzr, bzr-svn, bzr-builddeb, debhelper, gnome-common, libglib2.0-dev, gtk-doc-tools, evolution-data-server, evolution-data-server-dev, libedataserver1.2-dev, libedataserverui1.2-dev, libebackend1.2-dev, libecal1.2-dev, libedata-cal1.2-dev, libedata-book1.2-dev, libcamel1.2-dev, evolution-plugins, evolution-dev, libmapi-dev, libmapi0-dev, libtalloc-dev, libdcerpc-dev, libsamba-hostconfig-dev, libldb-samba4-dev, tdb-dev, samba4-dev,
 cdbs

Evolution was at 2.25.90-0ubuntu1 . I then did a bzr branch lp:~jelmer/evolution-mapi/ubuntu , which grabbed ver. 88. I attempted ./autogen.sh to make sure I had all the dependencies (actually did this a number of times til all dependencies were satisfied). I then did a "mkdir m4" and "aclocal -I m4" to satisfy the m4 requirements. Then, finally I ran bzr-buildpackage. I was still getting three symbol not found errors:

dpkg-shlibdeps: warning: symbol e_passwords_ask_password used by debian/evolution-mapi/usr/lib/evolution/2.26/plugins/liborg-gnome-exchange-mapi.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol e_passwords_forget_password used by debian/evolution-mapi/usr/lib/evolution/2.26/plugins/liborg-gnome-exchange-mapi.so found in none of the libraries.
dpkg-shlibdeps: warning: symbol e_passwords_get_password used by debian/evolution-mapi/usr/lib/evolution/2.26/plugins/liborg-gnome-exchange-mapi.so found in none of the libraries.

After a bit of hacking, I added to configure.ac:

PKG_CHECK_MODULES(LIBEDATASERVERUI, libedataserverui-$EDS_PACKAGE >= eds_minimum_version)
edataserverui_privincludedir=`$PKG_CONFIG --variable=privincludedir libedataserverui-$EDS_PACKAGE`
AC_SUBST(edataserverui_privincludedir)

And added to src/libexchangemapi/Makefile.am :

$(LIBEDATASERVERUI_CFLAGS) \
$(LIBEDATASERVERUI_LIBS) \

At this point, bzr-buildpackage was able to compile without the symbol not found messages. However, I'm still getting a SegFault whenever I try to use the MAPI plugin to create an account.

I'm not sure if I should report the SegFault here, or upstream. I can get a gdb trace if you'd like me to. Let me know if there's anything else you need.

[fuchur (ckellner-gmx)]

Should this work with evolution 2.25-0? for me it seems it does not: clicking authenticate when I set up the profile in ubuntu results in a long wait and then mapi_e_network_error

[fuchur (ckellner-gmx)]

after experimenting a bit with server settings I now get an ecCachedModeRequired error followed by a segmentation fault.

[C de-Avillez (hggdh2)]

@mark, fuchur: could you please open a new bug -- upstream is OK --, and give us the link? A GDB backtrace would really help, by the way.

[mark stover (stovenator)]

Actually, there is already a bug which looks exactly like what I am encountering at http://bugzilla.gnome.org/show_bug.cgi?id=560757

I can provide a stacktrace, but I don't have all of the symbols.

[C de-Avillez (hggdh2)]

@mark: the upstream bug does not seem to be (directly) related to evo-mapi. This is the offending piece of the BT:

#0 0xb630e9f6 in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0xb63102f8 in *__GI_abort () at abort.c:88
#2 0xb6350873 in malloc_printerr (action=2, str=0xb640a2e5 "corrupted double-linked list", ptr=0x84afa90) at malloc.c:5999
^^^^^^^^^^^

So LIBC went on and gave out a SIGABRT. It seems an Evo upgrade was being performed/tried when this happened...

[mark stover (stovenator)]

Bug created at http://bugzilla.gnome.org/show_bug.cgi?id=571579

[Jaap Haitsma (jaap)]

evolution-mapi is now in universe

[Didier Roche-Tolomelli (didrocks)]

This package is released in ubuntu… No need to forward the request upstream.

Please, open a new bug for other issues.

[Darren Worrall (dazworrall)]

Should this be ready for public consumption yet? I've tried it at various stages of Jaunty and have never been able to make a connection to my Exchange 2007 box - I assumed it was because it was a work in progress?

[rdasilva (rdasilva-acm)]

I agree with Otacon. I've tried it many times against Exchange 2007 with no luck. Has this been vetted as even functional?

Otacon, I have a question... does your Exchange 2007 implementation require SSL? Mine does and I see no option to set it in the Exchange MAPI setup. Might this be our problem? I have read posts in the Ubuntu forums by people who have been successful getting it to connect.