> When invoking gpg as a backgrounded tool, it's important to let gpg
> know that it is backgrounded, to avoid spurious prompts or other
> In particular, https://bugs.debian.org/913614 was a regression in
> GnuPG which causes problems when importing keys without a terminal,
> but gpg expects one.
> Ensuring that notmuch-emacs always invokes gpg as a background process
> should avoid some of these unnecessary failure.
1) I only skimmed the debian bug, but I hard the impression Werner said
that --batch implied --no-tty?
2) How urgent is this? It will probably be at more than month before the
next notmuch release, due to some sphinx issues that need some
attention. Should we do a 0.28.2 point release ? I'd say basically if
you think it's worth patching for debian we should do the point release
Re: [PATCH] emacs: Invoke gpg with --batch and --no-tty
On Sat 2019-02-09 17:12:52 -0400, David Bremner wrote:
> 1) I only skimmed the debian bug, but I hard the impression Werner said
> that --batch implied --no-tty?
Make sure that the TTY (terminal) is never used for any output.
This option is needed in some cases because GnuPG sometimes
prints warnings to the TTY even if --batch is used.
So i think that --batch does not imply --no-tty.
Why GnuPG might insist on causing an error if it has no tty in those
cases, i can't really justify, but there it is.
> 2) How urgent is this? It will probably be at more than month before the
> next notmuch release, due to some sphinx issues that need some
> attention. Should we do a 0.28.2 point release ? I'd say basically if
> you think it's worth patching for debian we should do the point release
> for everyone.
This is one part of a two-part bug, both of which i bear some
responsibility for. The other part is the aforementioned
https://bugs.debian.org/913614, the fix for which is already in both
testing and stretch-proposed-updates. Luckily, if *either* GnuPG or
notmuch-emacs is fixed, the problem goes away. But both fixes are in
principle the right thing to do, so please queue this for the notmuch
mainline at least.
i don't think there's any urgency here from a debian perspective, since
we're unlikely to get anything fixed before the next point release
anyway, and the other leg of the bug is already solved in the next point
If there are other cleanups you're thinking about trying to get into
debian stretch's next point release, by all means fold this one in,
Other operating systems or vendors might want to include this patch if
they're running some version of GnuPG that makes the same mistakes as