Justus Winter <jus...@sequoia-pgp.org> writes: > David Bremner <da...@tethera.net> writes: > >> Justus Winter <jus...@sequoia-pgp.org> writes: >> >>> Hello, >>> >>> I just embarrassed myself a little by sending the same mail over and >>> over again. The reason for that is that notmuch-emacs signaled failure, >>> i.e. it displayed an error message in the status buffer and didn't close >>> the compose buffer, yet it did in fact send the mail. >>> >>> I suspect that my configuration has to do with that and someone is >>> trying to be helpful. So I use msmtp with the authentication password >>> encrypted using OpenPGP. Then, I use 'gpg --no-tty -q -d ...' as >>> msmtp's passwordeval function. Now, my OpenPGP key has expired, but >>> that doesn't stop GnuPG from decrypting the secret, and in fact it >>> returns the status code 0. It also prints >>> >>> gpg: Note: secret key 08CC70F8D8CC765A expired at Mon 25 Jul 2022 >>> 05:31:26 PM CEST >>> >>> to stderr, which is picked up by notmuch-emacs, it says >>> >>> sending...failed to gpg: Note: secret key 08CC70F8D8CC765A expired at Mon >>> 25 Jul 2022 05:31:26 PM CEST >>> >>> in the status buffer while the compose buffer stays open. >>> >>> I suspect that this is not notmuch's fault, but I don't know where else >>> to turn to with this bug report. >> >> I guess the first step is to see if you can duplicate the problem with >> plain M-x message-mode. The mechanics of sending should be identical in >> notmuch-message-mode unless (surprise!) I misremember something. > > It does indeed happen with the plain message mode. And I think I have > identified the code in emacs that turns any output, stdout and stderr, > into errors: > > % cat -n emacs/lisp/mail/sendmail.el > [...] > 1343 (exit-value (apply #'call-process-region > args))) > 1344 (cond ((or (null exit-value) (eq 0 exit-value))) > 1345 ((numberp exit-value) > 1346 (setq error t) > 1347 (error "Sending...failed with exit value > %d" exit-value)) > 1348 ((stringp exit-value) > 1349 (setq error t) > 1350 (error "Sending...terminated by signal: > %s" exit-value)) > 1351 (t > 1352 (setq error t) > 1353 (error "SENDMAIL-SEND-IT -- fall > through: %S" exit-value)))) > 1354 (or fcc-was-found > 1355 (error "No recipients"))) > 1356 (if mail-interactive > 1357 (with-current-buffer errbuf > 1358 (goto-char (point-min)) > 1359 (while (re-search-forward "\n\n* *" nil t) > 1360 (replace-match "; ")) > 1361 (unless (zerop (buffer-size)) > 1362 (setq error t) > 1363 (error "Sending...failed to %s" > 1364 (buffer-substring (point-min) > (point-max))))))) > > Apparently, that behavior goes back to the initial checkin of that > file. I refuse to believe that Dan and me are the only ones having > problems with that in 30 years... I'll report it upstream.
Can you paste the upstream bug number here as well please? Thanks, Dan _______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
