On 23/01/15 13:20, Guilhem Moulin wrote:
[T]he next step would be to mail gnupg-de...@gnupg.org, at least if the
culprit is not the OSX maintainer (I dunno how things work there;
assuming these macports are not built by upstream).
MacPorts is basically FreeBSD ports, for Mac OS X. So it functions
roughly equivalently to, eg, Gentoo -- the portfile points at where to
download the source, what dependencies need to be installed before
building, and provides some build/install instructions (which in some
cases might include some MacPorts-specific patches). The MacPorts
project maintains the port files, and typically user's own computers
actually build the software, so upstream isn't involve unless someone
pushes patches up to them (or reports bugs to them).
The gnupg portfile is here:
https://trac.macports.org/browser/trunk/dports/mail/gnupg/Portfile
and it only points at one patch:
https://trac.macports.org/browser/trunk/dports/mail/gnupg/files/patch-gpg_agent-launchd.diff
which seems tiny, and I suspect unrelated to the problem.
So in theory this is upstream code triggering it for some reason. But
it'd probably take a bunch of debugging to figure out why. I might try
to have a look one day when I have a few hours spare, but it won't be
this month :-) (And yes, if someone does find the root cause then
taking that to the GnuPG upstream seems like the obvious next step.)
(Completely random hunch: maybe there's something Linux specific that is
able to look in, eg, /proc for the tty and recover from stderr being
redirected that way. If so it'd be a "happens to work on Linux"
situation rather than a "fails only on OS X" situation.)
Alright. How about an error [on OS X if GPG_TTY is not set] then?
That would be okay with me. I was suggesting a warning only to avoid
forcing everyone to set GPG_TTY to continue. But maybe they have to set
it to get sensible use anyway.
While I agree a warning might be hard to spot, if it's near the start of
the output and people do have problems there's a decent chance they'll
scroll back far enough to spot it. So either is fine with me.
Great. The manpage includes some of it already, but TBH I didn't know
SSL_CERT_DIR/SSL_CERT_FILE would affect the server authentication.
Me neither, until I spent a while digging through the various perl
modules invoked via Mail::Mailer, looking for a way to get it to accept
my organisation-wide CA. (Recent perl versions do actually do
reasonable SSL certificate validation by default; and Mail::Mailer and
friends do not have a way to pass through the parameters to
override/fine tune that. Hence resorting to stuffing things into %ENV.)
Ewen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
