* [bug?] emacs interface - some mark read tag changes may have failed
@ 2022-06-06 11:01 Giovanni Biscuolo
2022-06-06 12:12 ` David Bremner
0 siblings, 1 reply; 7+ messages in thread
From: Giovanni Biscuolo @ 2022-06-06 11:01 UTC (permalink / raw)
To: notmuch
[-- Attachment #1.1: Type: text/plain, Size: 975 bytes --]
Hello,
I use notmuch via emacs since long ago (at least 3 years) and all is
working great
...except today I received a message (reply) that emacs-notmuch have
problems showing, if I try to open it (press return on the message in
the notmuch-search buffer) it hangs forever and I can just interrupt
the notmuch-show command using CTRL-g; after I press CTRL-g I get this
text in the buffer:
[some mark read tag changes may have failed]
I launched emacs with:
emacs -Q --eval "(require 'notmuch)"
If I
notmuch show --format=raw id:26ee39e3-fa3a-52f3-1a3f-0d222e2613f8@di.unimi.it
in a terminal I get the whole message with no errors, so I think it
should be an emacs interface error
how can I debug this kind of errors?
is there a way i can reply to the affected email dumping the raw message in
a text file and using it with emacs as if it's a "normal message"?
Thanks! Gio'
--
Giovanni Biscuolo
Xelera IT Infrastructures
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug?] emacs interface - some mark read tag changes may have failed
2022-06-06 11:01 [bug?] emacs interface - some mark read tag changes may have failed Giovanni Biscuolo
@ 2022-06-06 12:12 ` David Bremner
2022-06-06 13:18 ` Giovanni Biscuolo
0 siblings, 1 reply; 7+ messages in thread
From: David Bremner @ 2022-06-06 12:12 UTC (permalink / raw)
To: Giovanni Biscuolo, notmuch
Giovanni Biscuolo <g@xelera.eu> writes:
> after I press CTRL-g I get this text in the buffer:
> [some mark read tag changes may have failed]
This is essentially notmuch-emacs complaining that it was interrupted,
so not really telling us about the underlying issue.
>
> I launched emacs with:
>
> emacs -Q --eval "(require 'notmuch)"
>
To be honest, I'm a bit surprised this works. How does emacs find
notmuch.el in this case? Or did you maybe mean emacs -q?
> how can I debug this kind of errors?
>
I suggest using M-x toggle-debug-on-quit, so that you get a traceback.
It may help to specify versions of notmuch and emacs when reporting problems.
> is there a way i can reply to the affected email dumping the raw message in
> a text file and using it with emacs as if it's a "normal message"?
>
If you can get the text you want, then you can copy and paste it into a
message composition buffer (e.g. from C-x m). notmuch show --format=text
may offer your best bet of recovering message text.
d
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug?] emacs interface - some mark read tag changes may have failed
2022-06-06 12:12 ` David Bremner
@ 2022-06-06 13:18 ` Giovanni Biscuolo
2022-06-06 13:57 ` David Bremner
0 siblings, 1 reply; 7+ messages in thread
From: Giovanni Biscuolo @ 2022-06-06 13:18 UTC (permalink / raw)
To: David Bremner, notmuch
[-- Attachment #1.1: Type: text/plain, Size: 3313 bytes --]
Hello David,
thank you for your help!
I found a pettern in how the problems affects me
The message is S/MIME signed:
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060701080209070400040907"
I searched all messages having mimetype application/pkcs7-signature and
found that I can read almost every one of them /except/ some of them
have the very same behaviour
Some of the S/MIME signed messages do display correctly /but/ after some
delay, others display immediatly, some never display and I have to
interrupt (CTRL-g)
There is also an old signed message (2019-07-23) from the same sender
I'm /sure/ I was able to read at the time, but now I'm not able to open
it anymore (in Emacs)
David Bremner <david@tethera.net> writes:
> Giovanni Biscuolo <g@xelera.eu> writes:
>
>> after I press CTRL-g I get this text in the buffer:
>> [some mark read tag changes may have failed]
>
> This is essentially notmuch-emacs complaining that it was interrupted,
> so not really telling us about the underlying issue.
OK, I understand now
>> I launched emacs with:
>>
>> emacs -Q --eval "(require 'notmuch)"
>>
> To be honest, I'm a bit surprised this works. How does emacs find
> notmuch.el in this case? Or did you maybe mean emacs -q?
I'm using Guix to install Emacs and all related packages, AFAIU Guix
loads all the needed libraries anyway; to be sure startes Emacs in an
isolated container [1] with only emacs and emacs-notmuch as available
packages, exposing (i.e. maiking it read-only in the container) my
maildir to be able to read messages and notmuch database; this is what I
did:
guix shell --container --network --expose=/var/mail/giovanni=/var/mail/giovanni emacs emacs-notmuch --preserve='^DISPLAY$' -- emacs -Q --eval "(require 'notmuch)"
...and opening it this way I was finally able to open the message!
The visible difference I find between the two instances of emacs - my
default one and the one started in a container - is that in my default
one Emacs is verifying signatures ("Good signature by" in many S/MIME
signed messages, not all) but the one in the container is not doing the
signature verification, I can see it comparing how the same message is
displayed in both instances
>> how can I debug this kind of errors?
>>
>
> I suggest using M-x toggle-debug-on-quit, so that you get a traceback.
>
> It may help to specify versions of notmuch and emacs when reporting
> problems.
Thanks, I'll try to debug-on-quit as soon as I find some time to stop my
daemon and testing this issue.
>> is there a way i can reply to the affected email dumping the raw message in
>> a text file and using it with emacs as if it's a "normal message"?
>>
>
> If you can get the text you want, then you can copy and paste it into a
> message composition buffer (e.g. from C-x m). notmuch show --format=text
> may offer your best bet of recovering message text.
Oh yes, you are right... but now I've seen I can start Emacs that way
(isolated container) I have a better workaround :-)
Thank you very much! Gio'
[1] https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-shell.html
--
Giovanni Biscuolo
Xelera IT Infrastructures
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug?] emacs interface - some mark read tag changes may have failed
2022-06-06 13:18 ` Giovanni Biscuolo
@ 2022-06-06 13:57 ` David Bremner
2022-06-06 18:07 ` Giovanni Biscuolo
0 siblings, 1 reply; 7+ messages in thread
From: David Bremner @ 2022-06-06 13:57 UTC (permalink / raw)
To: Giovanni Biscuolo, notmuch
Giovanni Biscuolo <g@xelera.eu> writes:
> Hello David,
>
> thank you for your help!
>
> I found a pettern in how the problems affects me
>
> The message is S/MIME signed:
>
without checking all the details, sounds like you need the hint in
https://nmbug.notmuchmail.org/nmweb/show/87y402yx5d.fsf%40tesseract.cs.unb.ca
Unfortunately gpg upstream disagrees with dkg and I that this behaviour
is a bug.
d
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug?] emacs interface - some mark read tag changes may have failed
2022-06-06 13:57 ` David Bremner
@ 2022-06-06 18:07 ` Giovanni Biscuolo
2022-06-07 9:57 ` David Bremner
0 siblings, 1 reply; 7+ messages in thread
From: Giovanni Biscuolo @ 2022-06-06 18:07 UTC (permalink / raw)
To: David Bremner, notmuch
[-- Attachment #1.1: Type: text/plain, Size: 1402 bytes --]
Hello David,
David Bremner <david@tethera.net> writes:
> Giovanni Biscuolo <g@xelera.eu> writes:
[...]
>> The message is S/MIME signed:
>>
>
> without checking all the details, sounds like you need the hint in
>
> https://nmbug.notmuchmail.org/nmweb/show/87y402yx5d.fsf%40tesseract.cs.unb.ca
it sounds the same issue: I added "disable-crl-checks" to
~/.gnupg/dirmngr.conf, restarted dirmngr with "gpgconf --kill
dirmngr" and "gpgconf --launch dirmngr"... but the issue was the same
Is it possible it war Tor related? I realized that my tor service was
stuck:
--8<---------------cut here---------------start------------->8---
Tried for 125 seconds to get a connection to [scrubbed]:80. Giving up.
--8<---------------cut here---------------end--------------->8---
So I stopped the service and I was able to see the message with a good
signature verification
I tried both with and without "disable-crl-checks" in dirmngr config but
nothing was different AFAIU
The real change was when I stopped the stuck Tor service.
Now I restarted Tor (and it's not stuck anymore) and all is working fine
again.
...guess I should check why (apparently) my gpg is using Tor :-)
Maybe gnupg/dirmngr uses Tor by default if it finds a Tor service on the
machine?
Any idea?
[...]
Thanks! Gio'
--
Giovanni Biscuolo
Xelera IT Infrastructures
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug?] emacs interface - some mark read tag changes may have failed
2022-06-06 18:07 ` Giovanni Biscuolo
@ 2022-06-07 9:57 ` David Bremner
2022-06-07 13:13 ` Giovanni Biscuolo
0 siblings, 1 reply; 7+ messages in thread
From: David Bremner @ 2022-06-07 9:57 UTC (permalink / raw)
To: Giovanni Biscuolo, notmuch
Giovanni Biscuolo <g@xelera.eu> writes:
> Now I restarted Tor (and it's not stuck anymore) and all is working fine
> again.
>
> ...guess I should check why (apparently) my gpg is using Tor :-)
>
> Maybe gnupg/dirmngr uses Tor by default if it finds a Tor service on the
> machine?
There is some discussion about tor in the related gnupg issue
https://dev.gnupg.org/T3348
The documentation says
The default is to use Tor if it is available on startup or after
reloading dirmngr
There is also "no-use-tor", but like disable-crl-checks there are
security/privacy implications to using that.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bug?] emacs interface - some mark read tag changes may have failed
2022-06-07 9:57 ` David Bremner
@ 2022-06-07 13:13 ` Giovanni Biscuolo
0 siblings, 0 replies; 7+ messages in thread
From: Giovanni Biscuolo @ 2022-06-07 13:13 UTC (permalink / raw)
To: David Bremner, notmuch
[-- Attachment #1.1: Type: text/plain, Size: 835 bytes --]
Hi,
David Bremner <david@tethera.net> writes:
[...]
>> Maybe gnupg/dirmngr uses Tor by default if it finds a Tor service on the
>> machine?
>
> There is some discussion about tor in the related gnupg issue
>
> https://dev.gnupg.org/T3348
thank you for the bug reference
> The documentation says
>
> The default is to use Tor if it is available on startup or after
> reloading dirmngr
>
> There is also "no-use-tor", but like disable-crl-checks there are
> security/privacy implications to using that.
i should have read the documentation before, now I understand: thanks!
in my case, there is no doubt the S/MIME signature verification was
stuck because Tor was stuck, when I restarted Tor all was fine again
Happy hacking! Gio'
--
Giovanni Biscuolo
Xelera IT Infrastructures
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 849 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-06-07 13:13 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-06 11:01 [bug?] emacs interface - some mark read tag changes may have failed Giovanni Biscuolo
2022-06-06 12:12 ` David Bremner
2022-06-06 13:18 ` Giovanni Biscuolo
2022-06-06 13:57 ` David Bremner
2022-06-06 18:07 ` Giovanni Biscuolo
2022-06-07 9:57 ` David Bremner
2022-06-07 13:13 ` Giovanni Biscuolo
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).