gpgme : upgrade to 1.8.0 and +qt5 variant

[RJVB (René Bertin)]

This is an upgrade for port:gpgme to bring it to 1.8.0 and also introduce a +qt5 variant so that future KF5 ports can use its QGpgME library.

Surprisingly gpgme 1.8 introduces a number of missing function declarations which apparently were declared properly in 1.7.0 (or not used). We may want to notify upstream, but maybe we should first figure out the best fix. The current implementation provides the missing prototypes, as I am not sure what the effect would be of using an alternative (better?) fix: configure.cppflags-append -D__DARWIN_C_LEVEL=200112L. There are also a few cases where I could use a proper fix (add a missing strings.h header and use the qstrdup() equivalent of strdup() in Qt code).

Similarly, the CMake files need correction of the shared library extension, something done currently in the post-destroot but that probably ought to be reported upstream as it wasn't required in the earlier versions.

The QGpgME library is call libqgpgme by default, which unfortunately is the same name used by the equivalent (but Qt4-based) library provided by port:kdepimlibs4 . The current proposal avoids this through a patch of the build system that renames the library to libq5gpgme, rather than figuring out how to change that port once more to allow co-existence. This has been tested and seems to work for me.

[RJVB (René Bertin)]

updated Portfile (diff against macports-ports master/head)

[RJVB (René Bertin)]

adds the missing function declarations

[RJVB (René Bertin)]

renames libqgpgme to libq5gpgme

[RJVB (René Bertin)]

updated Portfile (diff against macports-ports master/head)

[lbschenkel (Leonardo Brondani Schenkel)]

I do not necessarily oppose merging your contributions, but I would like to raise the question if we should report this to upstream instead and wait for a bugfix release instead of making divergent changes downstream which would increase the burden of maintaining the package.

[dbevans (David B. Evans)]

I agree with Leonardo. These issues and proposed solutions should be forwarded upstream. Additionally, there really are two differenct issues here that should be addressed individually

 * the missing symbol issues that cause the basic build of 1.8 to fail
 * support for qt5

I have to confess that I haven't done anything with the first issue for a while because I thought the appropriate bug fix release must surely be in the works but apparently not. I'll get the lead out and give them a push on this.

As to qt5 support, renaming libraries, etc I suggest the reporter take the lead in coordinating that upstream before we do anything further here.

Marking this as an upstream issue for now. Please attach a reference to any upstream bug reports that may be generated so the issues can be tracked.

[RJVB (René Bertin)]

I can look into reporting upstream tomorrow, but I think we should also figure out the proper way to get the strdup prototype from the string.h header.

Once we have a few correct patches for what are clearly issues it should be much easier to get those patches accepted. Either way, it is rarely a good idea to wait for a bugfix release if you already have fixes and/or workarounds.

The only question I have is when 1.8.1 can be expected. I think I've already seen it mentioned somewhere (IIRC in relation to bugs in 1.8.0), but to me gpgme is just another dependency, not something I work with directly so I'm following its evolution closely. I'd expect the port maintainers to be doing that a bit more ;)

David: the library renaming is all that's advisable for Qt5 support, and it is not really an upstream issue. We can raise the idea upstream, but I think their position will be that we should find our own solution if we want to be able to install the Qt4 and Qt5 libraries in the same directory - and it's not like we've never done this kind of thing before. From what I understand, QGpgME is included with gpgme as largely a courtesy so the KDE PIM developers don't have to continue to provide it. KDE PIM 5 has done nothing to allow coinstallation with KDE PIM 4, which probably explains why the library wasn't renamed as the Qt5 versions of so many other libraries were.

Sadly we're not close to being able to retire kdepimlibs4, and it's a crucial package for me and anyone else using KMail. We *could* try to change the Qt4 gpgme libraries, but I have a feeling that might be less straightforward than with the Qt5 version.

Edit: as explained in a comment in the Portfile, QGpgME announces its library name and install location via .cmake files. Those are modified too, so any well-behaved dependent package will continue to find the things it needs.

[RJVB (René Bertin)]

If you prefer we (Marko and I) can also take care of the QGpgME library as a separate port (depending on port:gpgme), so we can address any issues with it ourselves. That would make sense, given how the component comes from KDE and will presumably be used primarily by KDE (KF5) applications.

[dbevans (David B. Evans)]

I agree that sounds like a better approach and would allow you guys to work on that independently in a more contained environment.

I'll look at the strdup issues in the next day or so with an eye to a slightly simpler solution after I understand more clearly exactly what's going on.

[dbevans (David B. Evans)]

Apparently the macOS strdup issue has been discussed upstream and they recommend adding

-D_DARWIN_C_SOURCE=900000L

to CFLAGS and CXXFLAGS.

See ​https://www.mail-archive.com/gnupg-users@gnupg.org/msg31883.html

[RJVB (René Bertin)]

OK, I'll see how easy it is to build just the QGpgME component; hopefully it's just a matter of setting languages=qt. I didn't want to say it, but yeah, it'll allow us to avoid multiple-captains-on-a-ship disagreements ;) Either way, having a gpgme-qt5 port will allow dependents to use a regular depspec and not the active_variants hack.

If others have tested the easy solution of setting _DARWIN_C_SOURCE to a suitable value that that will indeed be the more elegant approach. Check the patchfile though, there are 1 or 2 locations where I had to include a headerfile (strings.h) for strcasecmp, without having to provide an explicit prototype. Maybe that header will be included automagically when _DARWIN_C_SOURCE is set, but I don't think that that would be a proper fix.

[RJVB (René Bertin)]

​https://bugs.gnupg.org/gnupg/msg9634

[dbevans (David B. Evans)]

Replying to RJVB:

OK, I'll see how easy it is to build just the QGpgME component; hopefully it's just a matter of setting languages=qt. I didn't want to say it, but yeah, it'll allow us to avoid multiple-captains-on-a-ship disagreements ;) Either way, having a gpgme-qt5 port will allow dependents to use a regular depspec and not the active_variants hack.

You've changed the proposal a bit. We agreed on QGpgME (using qt5 and depending on gpgme) as a separate port. If you want gpgme-qt5 it needs to be a subport of gpgme to avoid confusion.

If others have tested the easy solution of setting _DARWIN_C_SOURCE to a suitable value that that will indeed be the more elegant approach. Check the patchfile though, there are 1 or 2 locations where I had to include a headerfile (strings.h) for strcasecmp, without having to provide an explicit prototype. Maybe that header will be included automagically when _DARWIN_C_SOURCE is set, but I don't think that that would be a proper fix.

Manually setting _DARWIN_C_SOURCE bothers me a bit but is what upstream insists on using saying "works for me" (but only testing on darwin15). I'm thinking that including <cstring> instead of <strings.h> may be another alternative. Will check this out after getting a cup of coffee under my belt.

[RJVB (René Bertin)]

Replying to dbevans:

You've changed the proposal a bit. We agreed on QGpgME (using qt5 and depending on gpgme) as a separate port. If you want gpgme-qt5 it needs to be a subport of gpgme to avoid confusion.

No problem. I think we'd be the only ones making a difference between qpgme-qt5 as a subport or as a separate port, but I have already started working on a port:qgpgme so the point is moot.

Manually setting _DARWIN_C_SOURCE bothers me a bit but is what upstream insists on

It also bothered me hence the alternative patch - but at least if this does lead to unforeseen side-effects there will be reason to file a bug report. Actually, I considered setting _DARWIN_C_LEVEL, because that's what my string.h contains (but I'm not on my Mac right now).

What surprises me is that I've never run into this issue before. Wouldn't _DARWIN_C_LEVEL and/or _DARWIN_C_SOURCE be set appropriately by selecting the right C dialect using a directive? I think that would be more correct, no?

[RJVB (René Bertin)]

OK, I have a working port:qgpgme port. Turns out qgpgme 1.7.0 builds and runs fine against gpgme 1.8.0 .

Keep me posted what you plan to do with gpgme, upgrade to 1.8.0 asap or wait for upstream fixes. I don't think there's haste with qgpgme so it can wait for gpgme 1.8x to land.

[dbevans (David B. Evans)]

Will do. Should have something by the end of this week. Lots of stuff wants to get done before then.

[dbevans (David B. Evans)]

In 175d12d/macports-ports:

gpgme: update to version 1.8.0

Fix C, C++ build issues. Qt bindings to be handled in a separate port.
Remove outdated Id tag line.

Closes: #53122

[RJVB (René Bertin)]

One remark w.r.t. one of the comments: gpgme only supports Qt5 from what I can see. So the question of co-existence of support for different Qt versions is moot.

[dbevans (David B. Evans)]

Replying to RJVB:

One remark w.r.t. one of the comments: gpgme only supports Qt5 from what I can see. So the question of co-existence of support for different Qt versions is moot.

Yes, other than it dictates the installation paths.

[RJVB (René Bertin)]

Doh, of course.

[RJVB (René Bertin)]

ABCDEFGHIJKMNOPQRSTUVWXYZ O:-)

I think you also missed this:

        reinplace "s|@libsuffix@|.dylib|g" ${destroot}${prefix}/lib/cmake/Gpgmepp/GpgmeppConfig.cmake
        reinplace "s|.so|.dylib|g" ${destroot}${prefix}/lib/cmake/Gpgmepp/GpgmeppConfig.cmake

[dbevans (David B. Evans)]

In 690ac3a3/macports-ports:

gpgme: fixup library suffix in installed GpgmeppConfig.cmake

See: #53122