Opened 4 years ago

Last modified 3 years ago

#60350 assigned defect

jpilot: Keyring plugin no longer built (/opt/local/lib missing from LDFLAGS)

Reported by: ewenmcneill (Ewen McNeill) Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc:
Port: jpilot

Description

The jpilot port used to include a Keyring plugin which allowed access to an (old) Palm password database (GNU Keyring). It seem as of recent versions of MacPorts, this plugin is no longer being built, which means that the keyring is no longer accessible. I'm not 100% sure of the criteria causing it not to be built, as I have one MacPorts system without it, and another (possibly slightly older install?) that does include it. On the system without it:

ewen@mandir:~$ port contents jpilot | grep -i keyring
ewen@mandir:~$ port contents jpilot | grep -i plugins
  /opt/local/lib/jpilot/plugins/libexpense.so
  /opt/local/lib/jpilot/plugins/libsynctime.so
ewen@mandir:~$ 

From playing with the configure script it appears the problem is that both -lgcrypt and -lcrypto are failing to be linked, even if both ports are manually installed, which causes configure to detect neither is available, and disable the plugin:

checking for libgcrypt-config... /opt/local/bin/libgcrypt-config
checking for LIBGCRYPT - version >= 1.2.0... yes (1.8.5)
checking LIBGCRYPT API version... okay
checking for gcry_md_hash_buffer in -lgcrypt... no
checking for SSLeay_version in -lcrypto... no
[...]
configure: WARNING: OpenSSL library not found, Keyring will not be built
[...]
Compiling KeyRing plugin...............   no

After a lot of fiddling, I've found a work around to get it to build:

ewen@mandir:~$ sudo port install libgcrypt
[..]
ewen@mandir:~$ sudo port clean jpilot
--->  Cleaning jpilot
ewen@mandir:~$ LDFLAGS="-L/opt/local/lib" sudo --preserve-env=LDFLAGS port upgrade -s -k -n --force jpilot
--->  Computing dependencies for jpilot
--->  Fetching distfiles for jpilot
--->  Verifying checksums for jpilot
--->  Extracting jpilot
--->  Configuring jpilot
--->  Building jpilot
--->  Staging jpilot into destroot
--->  Deactivating jpilot @1.8.2_0
--->  Cleaning jpilot
--->  Uninstalling jpilot @1.8.2_0
--->  Cleaning jpilot
--->  Computing dependencies for jpilot
--->  Installing jpilot @1.8.2_0
--->  Activating jpilot @1.8.2_0
--->  Cleaning jpilot
--->  Scanning binaries for linking errors
--->  No broken files found.                             
--->  No broken ports found.
ewen@mandir:~$ port contents jpilot | grep -i plugins
  /opt/local/lib/jpilot/plugins/libexpense.so
  /opt/local/lib/jpilot/plugins/libkeyring.so
  /opt/local/lib/jpilot/plugins/libsynctime.so
ewen@mandir:~$ 

having discovered from config.log that it was the linking failing, because the default link library search arguments were not including /opt/local/lib. And that I could manually get it to link by including -L/opt/local/lib in the test command lines it was using.

This seems related to #44402, but that had surprise dependencies on libgcrypt that weren't declared, and now it seems to be necessary to use libgcrypt *and* do something to persuade it to be linked in.

Since the Keyring plugin is the sole reason I still use jpilot (ie, to access old passwords in my old password database which haven't yet been copied over), without the keyring plugin jpilot is effectively useless to me.

I'm on macOS 10.14.6 in case it's relevant. I'm not sure how long this has been broken, as I haven't tried to use jpilot on this particular broken system for a while (and it has been working fine on another system for years, at least up to a week or so ago; I don't have that other system with me at present to check).

Could someone please add libgcrypt as a dependency of jpilot, and ensure that /opt/local/lib is in the linking path? I think that would solve both #44402 and this ticket.

Thanks,

Ewen

ewen@mandir:~$ port installed libgcrypt openssl
The following ports are currently installed:
  libgcrypt @1.8.5_0 (active)
  openssl @1.1.1e_0
  openssl @1.1.1f_0 (active)
ewen@mandir:~$ 

Change History (4)

comment:1 Changed 4 years ago by mf2k (Frank Schima)

In the future, please add the port maintainer(s) to Cc (port info --maintainers jpilot), if any.

comment:2 Changed 4 years ago by mf2k (Frank Schima)

Owner: set to kristian.peters@…
Status: newassigned

comment:3 Changed 4 years ago by ewenmcneill (Ewen McNeill)

In the future, please add the port maintainer(s) to Cc (port info --maintainers jpilot), if any.

Thanks for adding the port CC. I did try to figure out who to CC, but the commands I could find searching weren't displaying anyone addresses.

It'd help a lot if:

  1. The ticket system could auto-add CCs of the maintainers of the ports based on the port names entered; or
  1. At least the ticket system on the "new ticket" page could show the precise command needed to find the maintainer to CC. (The command to find the maintainer seems to be hard to find by searching for it -- searching seems to turn up commands which don't work. Which doesn't exactly help those of us filing tickets infrequently...)

FTR, I see it is included in https://guide.macports.org/#project.tickets.guidelines, if you know where to look, but the one thing I keep forgetting is buried in the middle of two long paragraphs and thus harder to find even if one knows to look there. So it'd really help if the "new ticket" banner text read:

Please read the Ticket Guidelines before submitting!

For port issues, please CC the maintainer (Run port info --maintainer <portname>)

because I suspect that's the most frequently accidentally omitted detail on port tickets :-)

Ewen

Version 0, edited 4 years ago by ewenmcneill (Ewen McNeill) (next)

comment:4 Changed 3 years ago by mf2k (Frank Schima)

Owner: kristian.peters@… deleted

See #60351.

Note: See TracTickets for help on using tickets.