Am Sa., 27. Mai 2023 um 14:31 Uhr schrieb David Bremner <>:
> Michael J Gruber <> writes:
> >
> > Are all gpg related tests emacs based? Either gpg or emacs is the red
> > herring here, or both ...
> The issue (at least on rawhide) seems to be the interaction between gpg
> and emacs
> A fix seems to be in progress. Do you have problems with gpg versions
> other than 2.4.1?

Yes. "It's complicated". Packages in Fedora copr buildroots:

epel-8          gnupg2-2.2.20-3.el8_6   emacs-1:26.1-10.el8_8.2
epel-9          gnupg2-2.3.3-2.el9_0    emacs-27.2-8.el9_2.1
fedora-37       gnupg2-2.3.8-1.fc37     emacs-1:28.2-3.fc37
fedora-38       gnupg2-2.4.0-3.fc38     emacs-28.2-4.fc38
fedora-39       gnupg2-2.4.1-1.fc39     emacs-28.2-6.fc39

RHEL/EPEL/ELN do not have "dtach" and thus skip the pertaining tests!
(I'll try this with dtach one day.)

notmuch master 0.37^62.gd155f29e (increased lisp timeout 120)
(workee epel-8 epel-9)
no workee fedora-37 fedora-38 fedora-39

notmuch 0.37 (standard lisp timeout 0.1)
no workee fedora-39
everything else works

notmuch 0.37  (increased lisp timeout 120)
(workee epel-8 epel-9)
no workee fedora-37 fedora-38 fedora-39

That is, on F37 and F38 failing:

On F39 failing:

Now, I don't know how the timeouts interact and whether increasing the
lisp timeout makes the overall timeout kick-in when it should not, of
course. Maybe this produces "false fails" on F37 and F38 because you
expect some lisp code to "hang" rather than return, and with the
increased timeout the test gets killed instead? "Fixing" T350/T357 for
the wrong reasons there, I guess. Based on that new hypothesis, I
omitted the lisp timeout again, and sure enough, it's only
fedora-39/rawhide failing again with T350/T357. So here is hoping that
gnupg2-2.4.0 vs gnupg2-2.4.1 indeed makes the difference!

notmuch mailing list --
To unsubscribe send an email to

Reply via email to