Port for evolution, based on devans evolution-data-server

[gwhitney]

Years ago, I was active with macports and had a login (in fact I still have a wiki page), but it's been so long I'm not really up to speed on how to contribute ports directly any longer, and I don't even know how to log in as the "macports me" any more.

But I recently had an interest in getting Evolution, the classic gnome email/calendar/addressbook app, running on my mac running El Capitan. The attached Portfile and patches worked; they are heavily based on Dave Evans' evolution-data-server port. If it would be helpful to get me back up to speed as a maintainer to move this along, feel free to point me in the right direction.

Some notes:

• some of the patches were for the sake of running with gnome-autoar, but I eventually punted on that because the gnome-autoar api has changed considerably since evolution 3.20.5 was released (and that's the version of evolution-data-server in Dave Evans' port, and evolution has to match that). When evolution updates, likely the gnome-autoar support can be re-enabled (and I would be happy to give that a try at that point).
• I patched both configure and configure.ac in parallel, but since this build does not run autogen, the patches to configure.ac are not strictly necessary. But it seemed worthwhile to submit the configure.ac patches anyway, in case anyone working on this at any point wants to run autogen

Let me know what (else) I can do to (help) make this evolution port available to anyone who happens to be interested.

Best regards, Glen
--
Glen Whitney
President, National Museum of Mathematics

[gwhitney]

Cc Me!

[gwhitney]

Actually, I recovered my trac password as gwhitney@…; since I don't really want two trac logins, I am going to change this over to gwhitney@…, which apparently does still get to me. But nevertheless, I am not currently up to speed on how to put ports directly into the system, so I would still appreciate either help with this port or pointers on how to get back up to speed (and of course, I have no idea if I still have permission to update MacPorts after all this time).

Thanks! Glen

[gwhitney]

Cc Me!

[gwhitney]

Cc Me!

[neverpanic (Clemens Lang)]

I don't think we revoke commit bits, and your trac password is also your svn passowrd, so committing should still work.

As for the Portfile:

• Current policy is to have sha256 and rmd160 hashes, at least two hash types are mandatory.
• Don't depend on p5-something, choose a specific version of Perl instead and make sure the port uses exactly that. Our current "blessed" default is 5.24

I think devans is the most qualified reviewer for gnome ports; I've put him on Cc.

[neverpanic (Clemens Lang)]

configure: WARNING: unrecognized options: --with-krb5, --enable-introspection

it seems your --with-krb5 option isn't used and evolution does not provide GObject introspection at all, so you should probably remove the gobject-introspection portgroup and the line enabling it.

If you only added the p5-xml-parser dependency for intltool's broken configure check, there's a different solution for that. See ​https://bugs.launchpad.net/intltool/+bug/1197875. Apply this patch to m4/intltool.m4 and use_autoreconf yes. Note that when autoreconfiguring, you may need a yelp dependency, too.

Configure failed to find libpst, because it wasn't set up to install its shared library:

checking for LIBPST... no
configure: error:

	libpst not found (or version < 0.6.54)

	If you want to disable PST importing support,
	please append --disable-pst-import to configure.

I fixed this in r152898.

[neverpanic (Clemens Lang)]

You actually need yelp-tools as well, when running autoreconf.

[dbevans (David B. Evans)]

Note that GNOME 3.22.0 is in the process of being released this week and I'm currently updating the various GNOME ports as they are released. This should be completed by the end of this week at which time I will begin committing these changes. Evolution has already been released as version 3.22.0 so you might want to wait until all the updated dependencies have been committed and then update this port to match. For instance, I've already ported (but not yet committed) gnome-autoar which is required by the updated port.

Also please feel free to add yourself as maintainer, openmaintainer. Although it might look like it at first glance, I have no monopoly on GNOME ports and would welcome the help.

[dbevans (David B. Evans)]

Since evolution requires intltool as a build dependency, some special handling is required. Our version of intltool provides a specially patched version of intltool.m4 which deals with our support for multiple Perl versions and, to properly use that, the port not only needs autoreconf but also intltoolize in the correct sequence before configure is run. The safest way that I have found of doing this is to run autogen.sh instead of configure as configure.cmd and add the following additional build dependencies

• autoconf
• automake
• libtool

autogen.sh is included in the ​upstream git repo but may not be included in the evolution tarball. If this is the case, I have been adding a copy of it from the repo to the files directory and then merging this into the tarball source in the post-patch phase. See port eog as an example of how this is done.

[gwhitney]

Thanks for looking at this, Dave. I didn't realize about the 3.22 release. I had implemented all of the very helpful suggestions through comment 9 (thanks, cal@...!) and just verified that the resulting port builds from an empty MacPorts install. But I will hold off on checking this in until I get things working with 3.22. If there's any way you could be so kind as to send me some sort of ping when the dependencies are available as ports at 3.22, Dave, I'd really appreciate it. At that time I will also convert to your suggested workaround for intltool as opposed to the one cal supplied.

In the meantime, I am updating all of the attachments to reflect the current state of affairs, which is working fine with the port tree as it stands after cal@'s patch to libpst (I had a similar one but forgot about it when I submitted this ticket, oops). And if anyone can be so kind as to point me to some reminders about how I actually check in this port once it is finalized, I'd be very appreciative. Nine years (since my last macports activity) is a long time, and I want to get things right. Best regards, Glen

[gwhitney]

Portfile updated through comment #9

[gwhitney]

patch for intltool as suggested by cal@...; the patch-configure.diff may now be dropped

[dbevans (David B. Evans)]

Just to be clear, cal's patch to the local intltool.m4 has already been applied in the intltool port. Using the procedure that I recommended will replace the local intltool.m4 with the patched version provided by intltool as part of the reconfiguration process.

New Portfile for gnome-autoar committed in r152938. It doesn't need any updated post-3.22.0 dependencies to build.

[gwhitney]

Replying to devans@…:

Just to be clear, cal's patch to the local intltool.m4 has already been applied in the intltool port. Using the procedure that I recommended will replace the local intltool.m4 with the patched version provided by intltool as part of the reconfiguration process.

Yes, I see that it is better to use a patched intltool than to constantly re-patch it in place every time; I will modify the evolution Portfile accordingly.

New Portfile for gnome-autoar committed in r152938. It doesn't need any updated post-3.22.0 dependencies to build.

Cool. When I see that you've upped evolution-data-server to 3.22.0, I will take that as a signal to try to get evolution 3.22.0 building with gnome-autoar, and wrap this port up. Thanks!

[dbevans (David B. Evans)]

Replying to gwhitney@…:

Cool. When I see that you've upped evolution-data-server to 3.22.0, I will take that as a signal to try to get evolution 3.22.0 building with gnome-autoar, and wrap this port up. Thanks!

I'll also make an entry here when I've reached that milestone.

[dbevans (David B. Evans)]

evolution-data-server @3.22.0 committed in r153307. evolution-data-server (and evolution 3.22.0) now depend on webkit2-gtk rather than webkit-gtk3 (#52398). You should also check configure.ac for other revised/additional dependencies. Looking forward to your revised submission.

[gwhitney]

Terrific. Just upgraded to Sierra. Will reboot on this sometime next week. Best, Glen

[dbevans (David B. Evans)]

Just updated evolution-data-server to version 3.22.1 in r153770. evolution @3.22.1 is also available now.

[gwhitney]

Sorry about the delay. Right after this message, I will attach the evolution portfile, and as a bonus, patches to four other ports that allow evolution (and its whole tree of dependencies) to be compiled with variants +quartz -x11 +no_x11. This includes patches to gcr that remove its dependency on the X11 backend for gdk.

The quartz evolution executable is working pretty well for me :-) and the entire compilation goes through with the default Macports variants.conf and produces an executable that starts up fine.

So, I would appreciate anyone's feedback on what further review/vetting needs to be done to get these patches checked in to MacPorts and whether in the end I should do it with my ages-old commit rights or someone more current should.

Thanks for your feedback on these ports! Glen

[gwhitney]

2016 Oct 16 version of evolution Portfile. Ignore all previous attachments.

[dbevans (David B. Evans)]

OK, I can help you. I'm particularly interested in the +quartz versions and your mods to your gcr. Looks like you have been busy!

[gwhitney]

upstream autogen.sh from the source repository, not included in release tarball

[gwhitney]

Only patch file for 2016 Oct 16 version of Portfile

[gwhitney]

Replying to gwhitney@…:

Sorry about the delay. Right after this message, I will attach the evolution portfile,

Oops, note that the autogen.sh file I just posted is needed, and the new version of the configure.ac patch (the ".2" should be removed from the file name, the .2 was automatically added to the file name by the upload.

[gwhitney]

patch to libnotify port Portfile; solely removes the port dependency on xorg-libsm which appears to be unnecessary

[gwhitney]

patch to libcanberra portfile so it can be compiled with gtk3+quartz; needs three new patchfiles to be attached; patch-configure-x11.diff (which is just the old patch-configure.diff renamed), patch-configure-quartz.diff, and patch_libcanberra-gtk.pc.in.diff

[gwhitney]

patchfile for libcanberra

[gwhitney]

patchfile for libcanberra

[gwhitney]

patchfile for libcanberra

[gwhitney]

patch to webkit2-gtk port to allow it to be compiled completely free of xorg ports; requires four patches to the WebCore source to follow

[gwhitney]

patchfile for webkit2-gtk

[gwhitney]

patchfile for webkit2-gtk

[gwhitney]

patchfile for webkit2-gtk

[gwhitney]

patchfile for webkit2-gtk

[gwhitney]

patch to gcr to alleviate x11 backend dependency; requires seven patchfiles attached hereafter

[gwhitney]

patchfile for gcr

[gwhitney]

patchfile for gcr

[gwhitney]

patchfile for gcr

[gwhitney]

patchfile for gcr

[gwhitney]

patchfile for gcr

[gwhitney]

patchfile for gcr

[gwhitney]

patchfile for gcr

[gwhitney]

OK, done posting all of the port patches. Note that it ended up slightly confusing: patch-configure.ac.2.diff goes with the evolution port, and patch-configure.ac.3.diff goes with the gcr port, and both should be renamed patch-configure.ac.diff in their respective "files" directory. Looking forward to feedback; thanks for your help, Dave!

[dbevans (David B. Evans)]

I've got the various files downloaded and applied and am trying a default build of evolution as we speak will let you know in a while if there are any questions.

One suggestion, no need to add a just +x11 variant unless -x11 makes sense and -x11 doesn't mean +quartz.

However, if you can build with either of the gtk3 X11 or gtk3 Quartz backends then having both variants +x11 +quartz makes sense but you need to mark them as conflicting (only one at a time). Default variant should be +x11 in this case.

Will look at the patches for the other ports in the meantime.

[gwhitney]

Replying to devans@…:

One suggestion, no need to add a just +x11 variant unless -x11 makes sense and -x11 doesn't mean +quartz.

However, if you can build with either of the gtk3 X11 or gtk3 Quartz backends then having both variants +x11 +quartz makes sense but you need to mark them as conflicting (only one at a time). Default variant should be +x11 in this case.

Sorry I am not fully understanding this advice. The latest version of the evolution port can be compiled with x11 support, in which case it requires gnome-desktop, and it must be the case that the x11 gdk backend is available; or without x11 support, in which case it does not require gnome-desktop, and relies on whatever (default) gdk backend has been installed. There are no other differences, and evolution-x11 will compile just fine on top of the x11 gdk backend. I don't actually see why evolution-x11 and evolution+x11 couldn't in theory coexist.

However, there does need to be at least one variant flag, because in an x11 environment, typically you would want the gnome-desktop integration, whereas there needs to be a way to turn it off in case only the quartz gdk backend has been compiled.

I hope that makes the situation with the evolution port and its interaction with the gdk backends clear enough for you to now advise me what the variant flag or flags should be. I would be glad to implement whatever variant scheme you feel is best.

[dbevans (David B. Evans)]

Replying to gwhitney@…:

Replying to devans@…:

One suggestion, no need to add a just +x11 variant unless -x11 makes sense and -x11 doesn't mean +quartz.

However, if you can build with either of the gtk3 X11 or gtk3 Quartz backends then having both variants +x11 +quartz makes sense but you need to mark them as conflicting (only one at a time). Default variant should be +x11 in this case.

Sorry I am not fully understanding this advice. The latest version of the evolution port can be compiled with x11 support, in which case it requires gnome-desktop, and it must be the case that the x11 gdk backend is available; or without x11 support, in which case it does not require gnome-desktop, and relies on whatever (default) gdk backend has been installed. There are no other differences, and evolution-x11 will compile just fine on top of the x11 gdk backend. I don't actually see why evolution-x11 and evolution+x11 couldn't in theory coexist.

Well, you need to understand that the variants are not tags, they are toggles. So if you assert a +variant then the opposite -variant must mean something. So if your port requires X11 and only builds that way then you don't need a +x11 because -x11 is non-sensical -- it can't build without x11.

To handle the case where gtk3 +x11 is not installed you need to check if it's installed at configure time, for example, by using require_active_variants from the active_variants 1.1 PortGroup.

gnome-desktop, is, in fact an example of this.

On the other hand, if you can build either with X11 support or Quartz support then declaring both +x11 and +quartz is OK but you must declare them as conflicting because you can't do both at the same time. Here -x11 is sensible because you CAN build without X11 support and the same for -quartz.

There actually are ports where you can disable X11 support and not use sometime else such as Quartz. An example would be a port that provides a library that doesn't depend on X11 but can optionally build a demo app to needs X11 for it's GUI. In that case +x11 by itself makes sense.

However, there does need to be at least one variant flag, because in an x11 environment, typically you would want the gnome-desktop integration, whereas there needs to be a way to turn it off in case only the quartz gdk backend has been compiled.

In which case you would declare +quartz also.

I hope that makes the situation with the evolution port and its interaction with the gdk backends clear enough for you to now advise me what the variant flag or flags should be. I would be glad to implement whatever variant scheme you feel is best.

Will give you an opinion after I see how everything plays together ;-)

[dbevans (David B. Evans)]

BTW, I just committed my working copy of evolution to my stable test repo if you want to take a look. If you still have svn commit access, you can make changes to this directly using svn.

​​http://svn.macports.org/repository/macports/users/devans/GNOME-3/stable/dports/gnome/evolution

[gwhitney]

Replying to devans@…:

On the other hand, if you can build either with X11 support or Quartz support then declaring both +x11 and +quartz is OK but you must declare them as conflicting because you can't do both at the same time. Here -x11 is sensible because you CAN build without X11 support and the same for -quartz.

Based on this it seems to me, the current implementation of a single toggle +/-x11 captures exactly what is going on: evolution requires gdk (indirectly via evolution-data-server) whether it is +x11 or -x11, but evolution -x11 will compile on top of _any_ macports installation of gdk, whereas evolution +x11 will only compile on top of gdk with the X11 backend and adds gnome desktop integration via the gnome-desktop port.

Isn't that just the right semantics for a single defined variant called "x11"?

Anyhow no rush, looking forward to hearing how it's working for you and if the X11-independent gcr looks reasonable to you. If so, I'd be happy either to submit an upstream patch for that or to have you do so, since I know that issue has been open for a long time in the gcr issue tracker.

[gwhitney]

(side note: the authentication for trac has changed? I now only see a "github login", and when I clicked on that, it logged me in, but not using my gwhitney@… email address, but rather a different address. Are the old trac accounts gone? Thanks for letting me know.)

In using evolution compiled via MacPorts with an email account on which I have a backlog of 100K+ messages (really), I discovered a bug in evolution-data-server in which it uses alloca on an array the size of which is the number of threads in the folder. Needless to say, with 100k+ threads, that alloca blew away my stack. I attach the evolution-data-server Portfile change here and the associated patch file. I have already filed an upstream bug report with the patch on evolution-data-server, hopefully it can be incorporated into a release soon. In the meantime, I think it is worthwhile to patch it in MacPorts, as anyone using evolution could get into dangerous territory for their stack as a mailbox grows.

[gwhitney]

patch to evolution-data-server to incorporate fix to potentially unbounded alloca

[gwhitney]

actual patch to evolution-data-server code, in the "camel" library

[larryv (Lawrence Velázquez)]

Replying to gwhitney:

(side note: the authentication for trac has changed? I now only see a "github login", and when I clicked on that, it logged me in, but not using my gwhitney@… email address, but rather a different address. Are the old trac accounts gone? Thanks for letting me know.)

Will handle this outside of the ticket.

[gwhitney]

Replying to gwhitney:

In the meantime, I think it is worthwhile to patch it in MacPorts, as anyone using evolution could get into dangerous territory for their stack as a mailbox grows.

The upstream patch has been accepted and will be in the next minor release. So it may be moot to patch it in MacPorts, when it will come with the next minor version bump. I will leave that judgment to more regular MacPorts committers.