Package Details: openchange 2.3-7

Git Clone URL: (read-only)
Package Base: openchange
Description: A portable, open source implementation of Microsoft Exchange server and Exchange protocols.
Upstream URL:
Licenses: GPL3
Submitter: a1russell
Maintainer: DJ_L
Last Packager: Zrax
Votes: 28
Popularity: 0.000013
First Submitted: 2010-08-20 16:19
Last Updated: 2016-06-03 16:20

Latest Comments

Zrax commented on 2017-10-19 01:11

I don't use this package any more. Feel free to adopt it and add your fixes.

corossig commented on 2017-10-18 13:14

Patch for fixing compilation :

DJ_L commented on 2016-07-11 23:08

I'm sorry I've never followed up on my previous comment. The Zentyal folks have continued development of OpenChange and are doing their releases (tagged) from here: which "should" work out of the box with 4.4 (though I have not tested it myself).

DJ_L commented on 2016-06-07 01:57

Hey, just FYI, while nothing is happening at official upstream, the inverse team is working on bringing it up to Samba-4.2. Should see something this week.

student975 commented on 2016-06-06 10:35

Is working now, thanks!

Zrax commented on 2016-06-03 16:22

It looks like they renamed their pkgconfig file in 0.9... :( I've added a patch to make it work again.

student975 commented on 2016-06-03 15:40

Hi! Have got:

checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) none
checking for CHECK... yes
checking for NANOMSG... no
configure: error: Install nanomsg library >= 0.5
==> ERROR: A failure occurred in build().
==> ERROR: Makepkg was unable to build openchange.
==> Restart building openchange ? [y/N]
==> -----------------------------------


~ $ pacman -Qs nanomsg
local/nanomsg 0.9-1
Simple high-performance implementation of several "scalability protocols"

How to resolve?

DJ_L commented on 2016-05-24 23:54

Well, it compiles fine here after fixing the configure check for nanomsg, just add 'sed 's@libnanomsg@nanomsg@g' -i at end of prepare() in the PKGBUILD file.

Not sure why you are using that really old patch Ser_Olmy, use the ones Zrax has included in the snapshot above and all is well. I'm making the assumption that you are not using Arch. PKGBUILD files are just shell scripts, some variables are prepopulated (like pkgdir and srcdir), but you can basically just source the file and run the three functions after accounting for those two pacman variables and you should be good to go.

As to future proofing this package for only the EDS use case, just kill the makedepends on python2-pylons, remove (or comment just in case development returns) the OCSManager and RPCProxy blocks, and add the above mentioned fix for nanomsg, and you are good to go.

DJ_L commented on 2016-05-24 16:59

I've quit using it at this point, no reason to continue to support a 7 year old version of Outlook (I've removed it from the SOGo packages entirely). Are you needing OpenChange, or just libmapi for EDS? I know the SOGo folks have it working correctly with 4.3.8. That said, I can take a look when I get home this evening and see if I might be able to coax it into compiling again, but I probably wouldn't be able to test it for several days. I had thought about breaking out libmapi as a separate package for the EDS use case.

Ser_Olmy commented on 2016-05-24 11:03

DJ_L, I for one would be /very/ interested in seeing OpenChange being patched to work with the latest versions of Samba. Both you and Zrax have some great work in patching various issues that arose when the Samba project closed off access to internal APIs.

As of right now, there are some mapiproxy issues preventing OpenChange from compiling against the most recent version of Samba (4.4.3). After applying the openchange-remove-server_id_str-1.patch, I get the following error;

mapiproxy/dcesrv_mapiproxy.c: In function 'mapiproxy_op_bind':
mapiproxy/dcesrv_mapiproxy.c:225:25: error: storage size of 'idbuf' isn't known
struct server_id_buf idbuf:
I'm certainly no developer, but it looks to me like the definition of server_id_buf is unavailable. It seems this would also affect mapiproxy/modules/mpm_cache.c.

Any chance you could look into the issue? I'd be happy to provide testing feedback.

All comments