Ye olde Apple mktemp

Ye olde Apple mktemp

[Ralph Seichter]

Another quirk that occurs during the configuration phase on older macOS
versions (when they were still called OS X, actually) in the MacPorts
build farm:

  Checking for GMime session key extraction support...
  usage: mktemp [-d] [-q] [-t prefix] [-u] template ...
         mktemp [-d] [-q] [-u] -t prefix
  No.

Hooray for that ancient mktemp binary. :-/ The following local patch
solves the issue for me:

diff --git a/configure b/configure
index 8b80f0e0..fa715946 100755
--- a/configure
+++ b/configure
@@ -529,7 +529,7 @@ int main () {
     return 0;
 }
 EOF
-    if ! TEMP_GPG=$(mktemp -d); then
+    if ! TEMP_GPG=$(mktemp -d -t /tmp); then
         printf 'No.\nCould not make tempdir for testing session-key support.\n'
         errors=$((errors + 1))
     elif ${CC} ${CFLAGS} ${gmime_cflags} _check_session_keys.c ${gmime_ldflags} -o _check_session_keys \

Alas, "mktemp -d -t /tmp" is incompatible with GNU coreutils' mktemp,
while "mktemp -d -p /tmp" is not understood by Apple's variant because
of the "-p". I don't know what syntax would be universally acceptable.

Is there a way to pass platform-dependent parameters to mktemp with the
current build mechanics?

-Ralph

Re: Ye olde Apple mktemp

[Tomi Ollila]

On Mon, Jun 10 2019, Ralph Seichter wrote:

> Another quirk that occurs during the configuration phase on older macOS
> versions (when they were still called OS X, actually) in the MacPorts
> build farm:
>
>   Checking for GMime session key extraction support...
>   usage: mktemp [-d] [-q] [-t prefix] [-u] template ...
>          mktemp [-d] [-q] [-u] -t prefix
>   No.
>
> Hooray for that ancient mktemp binary. :-/ The following local patch
> solves the issue for me:
>
> diff --git a/configure b/configure
> index 8b80f0e0..fa715946 100755
> --- a/configure
> +++ b/configure
> @@ -529,7 +529,7 @@ int main () {
>      return 0;
>  }
>  EOF
> -    if ! TEMP_GPG=$(mktemp -d); then
> +    if ! TEMP_GPG=$(mktemp -d -t /tmp); then
>          printf 'No.\nCould not make tempdir for testing session-key support.\n'
>          errors=$((errors + 1))
>      elif ${CC} ${CFLAGS} ${gmime_cflags} _check_session_keys.c ${gmime_ldflags} -o _check_session_keys \
>
> Alas, "mktemp -d -t /tmp" is incompatible with GNU coreutils' mktemp,
> while "mktemp -d -p /tmp" is not understood by Apple's variant because
> of the "-p". I don't know what syntax would be universally acceptable.
>
> Is there a way to pass platform-dependent parameters to mktemp with the
> current build mechanics?

Hmm, we have:

test/test-lib.sh:TEST_TMPDIR=$(mktemp -d "${TMPDIR:-/tmp}/notmuch-test-$$.XXXXXX")

does that test work ?

does

TEMP_GPG=$(mktemp -d /tmp/tmp.XXXXXX)

make any difference ?

if it doesn't, then we just have to do uname=$(uname) earlier
and add `-t` to mktemp(1) parameters in case it is darwin
(ot something) 

Tomi

>
> -Ralph

Re: Ye olde Apple mktemp

[Ralph Seichter]

* Ralph Seichter:

> The following local patch solves the issue for me [...]

Well, it does solve the mktemp call failing due to a missing
parameter. There is however additional fun [1] to be had once mktemp
succeeds:

-----snip-----
Checking for GMime session key extraction support... gpg: can't connect to the agent: File name too long
gpg: error getting the KEK: No agent running
gpg: error reading '[stdin]': No agent running
gpg: import from '[stdin]' failed: No agent running
No.
*** Error: Could not extract session keys from encrypted message.

This is likely due to your GMime having been built against a old
version of GPGME.

Please try to rebuild your version of GMime against a more recent
version of GPGME (at least GPGME 1.8.0).
Your current GPGME development version is: 1.13.0-unknown
-----snip-----

I found a GNUPGHOME length limit mentioned in a Debian bug [2] and other
places; looks like the Notmuch build is running into that limit. That
configure does not regcognize GPGME 1.13.0 is of course only a minor
issue, but the GnuPG error breaks the build.

-Ralph

[1] https://build.macports.org/builders/ports-10.10_x86_64-builder/builds/88616/steps/install-port/logs/stdio
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847206