[PATCH v2 06/15] gmime-cleanup: tests should only care about gmime 3

note that "notmuch-show for message with invalid From" is still broken in T310-emacs.sh. It would be good to debug what's going on there and try to get it fixed! signed-off-by: Daniel Kahn Gillmor --- test/T190-multipart.sh | 2 -- test/T310-emacs.sh | 2 +- test/T350-cr

[PATCH v2 11/15] gmime-cleanup: use GMime 3.0 data types

Signed-off-by: Daniel Kahn Gillmor --- notmuch-reply.c| 4 ++-- notmuch-show.c | 8 util/gmime-extra.h | 11 +++ 3 files changed, 9 insertions(+), 14 deletions(-) diff --git a/notmuch-reply.c b/notmuch-reply.c index fa91c5de..48fdbc92 100644 --- a/notmuch-reply.c

[PATCH v2 08/15] gmime-cleanup: drop g_mime_2_6_unref

signed-off-by: Daniel Kahn Gillmor --- lib/index.cc | 1 - notmuch-reply.c| 2 -- util/gmime-extra.h | 1 - 3 files changed, 4 deletions(-) diff --git a/lib/index.cc b/lib/index.cc index 6b6fbb8f..76830921 100644 --- a/lib/index.cc +++ b/lib/index.cc @@ -591,7 +591,6

[PATCH v2 05/15] gmime-cleanup: always support session keys

Our minimum version of GMime 3.0 always supports good session key handling. signed-off-by: Daniel Kahn Gillmor --- configure | 9 - lib/built-with.c | 2 +- lib/index.cc | 4 +--- mime-node.c | 2 -- notmuch-show.c

[PATCH v2 14/15] gmime-cleanup: pass NULL as default GMimeParserOptions

eam commit d0ebdd2ea3e6fa635a2a551c846e9bc8b6040353 (which itself precedes GMime 3.0). Signed-off-by: Daniel Kahn Gillmor --- lib/message-file.c | 2 +- mime-node.c| 2 +- util/gmime-extra.h | 2 -- 3 files changed, 2 insertions(+), 4 deletions(-) diff --git a/lib/message-file.c b/lib/message-file.c inde

[PATCH v2 09/15] gmime-cleanup: drop all arguments unused in GMime 3

This means dropping GMimeCryptoContext and notmuch_config arguments. All the argument changes are to internal functions, so this is not an API or ABI break. We also get to drop the #define for g_mime_3_unused. signed-off-by: Daniel Kahn Gillmor --- lib/index.cc | 3 +-- mime-node.c

[PATCH v2 10/15] gmime-cleanup: drop unused gmime #defines and simplify g_mime_init ()

Several of these #defines were not actually used in the notmuch codebase any longer. And as of GMime 3.0, g_mime_init takes no arguments, so we can also drop the bogus RFC2047 argument that we were passing and then #defining away. signed-off-by: Daniel Kahn Gillmor --- lib/database.cc| 2

[PATCH v2 15/15] gmime-cleanup: no longer need to use GMime major version during build

Signed-off-by: Daniel Kahn Gillmor --- configure | 4 1 file changed, 4 deletions(-) diff --git a/configure b/configure index 16bb0863..9140026a 100755 --- a/configure +++ b/configure @@ -497,7 +497,6 @@ if pkg-config --exists "gmime-3.0 > $GMIME_MINVER"; then

Re: [PATCH 03/16] gmime-cleanup: remove obsolete gpg_path configuration option and crypto contexts

On Thu 2019-05-02 06:50:41 -0300, David Bremner wrote: > Daniel Kahn Gillmor writes: > >> Note that we do keep ignoring the gpg_path configuration option, >> though, to avoid breakage of existing installations. > > This remark confused me a bit, since it doesn't se

Re: [PATCH 14/16] gmime-cleanup: no longer need to use GMime major version during build

On Thu 2019-05-02 07:10:10 -0300, David Bremner wrote: > Daniel Kahn Gillmor writes: > >> Signed-off-by: Daniel Kahn Gillmor >> --- >> configure | 4 >> 1 file changed, 4 deletions(-) > > I think I'll squash this, and probably the next tw

[PATCH 03/16] gmime-cleanup: remove obsolete gpg_path configuration option and crypto contexts

Note that we do keep ignoring the gpg_path configuration option, though, to avoid breakage of existing installations. signed-off-by: Daniel Kahn Gillmor --- mime-node.c | 16 -- notmuch-client.h| 9 notmuch-config.c| 29 --- notmuch-reply.c | 4

[PATCH 06/16] gmime-cleanup: simplify T355-smime.sh

GMime 3.0 and later can handle User ID as expected. signed-off-by: Daniel Kahn Gillmor --- test/T355-smime.sh | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/test/T355-smime.sh b/test/T355-smime.sh index be45e3b1..e410286b 100755 --- a/test/T355-smime.sh +++ b/test

[PATCH 14/16] gmime-cleanup: no longer need to use GMime major version during build

Signed-off-by: Daniel Kahn Gillmor --- configure | 4 1 file changed, 4 deletions(-) diff --git a/configure b/configure index 8775f6a7..0b65630e 100755 --- a/configure +++ b/configure @@ -497,7 +497,6 @@ if pkg-config --exists "gmime-3.0 > $GMIME3_MINVER"; then

[PATCH 04/16] gmime-cleanup: always support session keys

Our minimum version of GMime 3.0 always supports good session key handling. signed-off-by: Daniel Kahn Gillmor --- configure | 9 - lib/built-with.c | 2 +- lib/index.cc | 4 +--- mime-node.c | 2 -- notmuch-show.c

[PATCH 11/16] gmime-cleanup: use GMime 3.0 function names

Signed-off-by: Daniel Kahn Gillmor --- lib/index.cc | 4 ++-- notmuch-reply.c| 8 notmuch-show.c | 16 util/gmime-extra.h | 4 4 files changed, 14 insertions(+), 18 deletions(-) diff --git a/lib/index.cc b/lib/index.cc index f21761d0..41822488

[PATCH 15/16] gmime-cleanup: use GMIME_MINVER instead of GMIME3_MINVER

This looks cleaner and simpler, but has no functional change. Signed-off-by: Daniel Kahn Gillmor --- configure | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/configure b/configure index 0b65630e..9140026a 100755 --- a/configure +++ b/configure @@ -489,11 +489,11

[PATCH 05/16] gmime-cleanup: tests should only care about gmime 3

note that "notmuch-show for message with invalid From" is still broken in T310-emacs.sh. It would be good to debug what's going on there and try to get it fixed! signed-off-by: Daniel Kahn Gillmor --- test/T190-multipart.sh | 2 -- test/T310-emacs.sh | 2 +- test/T350-cr

[PATCH 02/16] gmime-cleanup: remove GMime 2.6 variant codeblocks

signed-off-by: Daniel Kahn Gillmor --- lib/message-file.c | 42 - notmuch-show.c | 21 --- util/gmime-extra.c | 93 -- util/gmime-extra.h | 12 -- 4 files changed, 168 deletions(-) diff --git a/lib/message-file.c b

[PATCH 08/16] gmime-cleanup: drop all unused GMimeCryptoContext arguments

signed-off-by: Daniel Kahn Gillmor --- lib/index.cc | 3 +-- mime-node.c| 13 + notmuch-client.h | 2 +- notmuch-insert.c | 2 +- notmuch-new.c | 2 +- notmuch-reindex.c | 2 +- notmuch.c | 2 +- util/crypto.c | 1 - util/crypto.h

[PATCH 07/16] gmime-cleanup: drop g_mime_2_6_unref

signed-off-by: Daniel Kahn Gillmor --- lib/index.cc | 1 - notmuch-reply.c| 2 -- util/gmime-extra.h | 1 - 3 files changed, 4 deletions(-) diff --git a/lib/index.cc b/lib/index.cc index 6b6fbb8f..76830921 100644 --- a/lib/index.cc +++ b/lib/index.cc @@ -591,7 +591,6

[PATCH 16/16] gmime-cleanup: strip remaining references to GMime 2.6

Comments and documentation no longer need to refer to GMime 2.6, so clean them all up. Signed-off-by: Daniel Kahn Gillmor --- INSTALL | 2 +- debian/control | 2 +- mime-node.c | 8 notmuch-reply.c | 6 -- notmuch-show.c | 2 +- 5 files changed, 7 insertions(+), 13

[PATCH 01/16] gmime-cleanup: drop unused gmime 2.6 content_type from _index_encrypted_mime_part

Signed-off-by: Daniel Kahn Gillmor --- lib/index.cc | 22 +- 1 file changed, 1 insertion(+), 21 deletions(-) diff --git a/lib/index.cc b/lib/index.cc index efd9da4c..0e98984c 100644 --- a/lib/index.cc +++ b/lib/index.cc @@ -367,7 +367,6 @@ _index_content_type

[PATCH 10/16] gmime-cleanup: use GMime 3.0 data types

Signed-off-by: Daniel Kahn Gillmor --- notmuch-reply.c| 4 ++-- notmuch-show.c | 8 util/gmime-extra.h | 11 +++ 3 files changed, 9 insertions(+), 14 deletions(-) diff --git a/notmuch-reply.c b/notmuch-reply.c index f6ec3c07..35b6645b 100644 --- a/notmuch-reply.c

[PATCH 12/16] gmime-cleanup: pass NULL arguments explicitly where GMime 3.0 expects it

Signed-off-by: Daniel Kahn Gillmor --- lib/message-file.c | 4 ++-- lib/thread.cc | 2 +- mime-node.c| 2 +- notmuch-reply.c| 10 +- notmuch-search.c | 4 ++-- notmuch-show.c | 4 ++-- util/gmime-extra.h | 7 --- 7 files changed, 13 insertions(+), 20

[PATCH 09/16] gmime-cleanup: drop unused gmime #defines and simplify g_mime_init ()

signed-off-by: Daniel Kahn Gillmor --- lib/database.cc| 2 +- lib/message-file.c | 2 +- notmuch.c | 2 +- util/gmime-extra.h | 7 --- 4 files changed, 3 insertions(+), 10 deletions(-) diff --git a/lib/database.cc b/lib/database.cc index d2732f5e..1753117f 100644 --- a/lib

[PATCH 13/16] gmime-cleanup: pass NULL as default GMimeParserOptions

eam commit d0ebdd2ea3e6fa635a2a551c846e9bc8b6040353 (which itself precedes GMime 3.0). Signed-off-by: Daniel Kahn Gillmor --- lib/message-file.c | 2 +- mime-node.c| 2 +- util/gmime-extra.h | 2 -- 3 files changed, 2 insertions(+), 4 deletions(-) diff --git a/lib/message-file.c b/lib/message-file.c inde

Dropping GMime 2.6 compatibility layer

This series follows David Bremner's id:20190501104643.5836-1-da...@tethera.net removal of gmime 2.6. It adopts GMime 3.0's API and idiom throughout, removing any attempt to paper over the differences between GMime 2.6 and 3.0. All tests pass. This is a nice simplification, dropping about 500 lin

Re: [PATCH] build: drop support for gmime-2.6

On Wed 2019-05-01 07:46:43 -0300, David Bremner wrote: > GMime 3.0 is over 2 years old now, and 2.6 has been deprecated in > notmuch for about 1.5 years. I was just looking at this change myself. As a gmime maintainer in debian, I'd love to see it happen, but i think the right way to do that is t

[PATCH v3] test: add_gnupg_home should have ultimate trust on "its own" key

The typical use case for gpg is that if you control a secret key, you mark it with "ultimate" ownertrust. This bizarrely opaque --import-ownertrust mechanism is GnuPG's standard mechanism to set up ultimate ownertrust (the ":6" means "ultimate", for whatever reason). --- test/test-lib.sh | 1 + 1

[PATCH v2] test: add_gnupg_home should have ultimate trust on "its own" key

The typical use case for gpg is that if you control a secret key, you mark it with "ultimate" ownertrust. This bizarrely opaque --import-ownertrust mechanism is GnuPG's standard mechanism to set up ultimate ownertrust (the ":6" means "ultimate", for whatever reason). --- test/test-lib.sh | 1 + 1

Re: [PATCH] test: add_gnupg_home should have ultimate trust on "its own" key

On Wed 2019-04-24 18:06:44 -0400, Daniel Kahn Gillmor wrote: > The typical use case for gpg is that if you control a secret key, you > mark it with "ultimate" ownertrust. > > This bizarrely opaque --import-ownertrust mechanism is GnuPG's > standard mechanism to set u

[PATCH] test: add_gnupg_home should have ultimate trust on "its own" key

The typical use case for gpg is that if you control a secret key, you mark it with "ultimate" ownertrust. This bizarrely opaque --import-ownertrust mechanism is GnuPG's standard mechanism to set up ultimate ownertrust (the ":6" means "ultimate", for whatever reason). --- test/test-lib.sh | 1 + 1

Easing access to the cryptographic envelope

E-mail structures are potentially arbitrarily complicated. Cryptographic protection standards like S/MIME and OpenPGP or PGP/MIME are often applicable to some elements of some messages. Last year's "E-Fail" attacks made it clear that trying to provide normal users with cryptographic protections on

[PATCH 3/4] mime-node: track whole-message crypto state while walking the tree

Deliberately populate the message's cryptographic status while walking the MIME tree from the CLI. Note that the additional numchild argument added to _mime_node_create is a passthrough needed to be able to adequately populate the crypto state object. --- mime-node.c | 24 +---

[PATCH 1/4] util/crypto: _notmuch_message_crypto: tracks message-wide crypto state

E-mail encryption and signatures reported by notmuch are at the MIME part level. This makes sense in the dirty details, but for users we need to have a per-message conception of the cryptographic state of the e-mail. (see https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html for more discus

[PATCH 4/4] cli/show: emit new whole-message crypto status output

This allows MUAs that don't want to think about per-mime-part cryptographic status to have a simple high-level overview of the message's cryptographic state. Sensibly structured encrypted and/or signed messages will work fine with this. The only requirement for the simplest encryption + signing i

[PATCH 2/4] cli: expose message-wide crypto status from mime-node

The mime node context (a per-message context) gains a cryptographic status object, and the mime_node_t object itself can return a view on that status to an interested party. The status is not yet populated, and for now we can keep that view read-only, so that it can only be populated/modified duri

Re: [PATCH] crypto: Avoid pretending to verify signatures on unsigned encrypted mail

On Sat 2019-04-20 13:02:57 -0400, Daniel Kahn Gillmor wrote: > Unsigned encrypted mail shows up with a weird empty signature list. > If we successfully decrypted and there was no signature in it, we > should just not show a sigstatus at all. Just a ping on this -- i don't thin

Re: [PATCH] emacs: hint that notmuch-mua-attachment-regexp is a regular expression

On Mon 2019-04-22 11:33:34 +0200, Örjan Ekeberg wrote: > This addresses the same issue, and therefore overlaps with the patch > I submitted a week ago. > (id:20190415133519.4532-1-ekeb...@kth.se) sorry, i'd missed your earlier patch! i agree that your patch is obviously better than mine, thanks f

Re: [PATCH] emacs: Add missing type and group to defcustom variable

On Mon 2019-04-15 15:35:19 +0200, Örjan Ekeberg wrote: > Added the type 'regexp and group 'notmuch-send as properties to the > customizable variable notmuch-mua-attachment-regexp. This is clearly a good patch, and better than id:20190420195359.23399-1-...@fifthhorseman.net which i'd sent to try to

Re: subsequent rebuilds of notmuch always re-build sphinx and ruby

On Tue 2019-04-23 22:09:23 -0300, David Bremner wrote: > [dkg wrote:] >> I do note that (independent of this series), if i run the following >> loop: >> >> >> while make -j4 --trace; do >> python3 -c 'print("="*100)' >> touch doc/man1/notmuch-reply.rst >> done >> >> then o

Re: subsequent rebuilds of notmuch always re-build sphinx and ruby

On Mon 2019-04-22 21:03:05 -0300, David Bremner wrote: > There was a problem with the first patch, which I replaced with two more. thanks. i've reviewed and published my review on that series. I think it should probably be merged. > I'm open to ideas, but keep in mind we want to support paralle

Re: [PATCH 3/4] doc: use stamp file for html docs

On Sun 2019-04-21 14:12:44 -0300, David Bremner wrote: > These are less time consuming than the texi docs to rebuild (because > the texi rebuild triggers info rebuild), but still take noticable time. > --- > doc/Makefile.local | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > dif

Re: [PATCH 3/3] emacs: Drop content-free "Unknown signature status" button

On Mon 2019-04-22 13:26:05 -0400, Daniel Kahn Gillmor wrote: > On Mon 2019-04-22 13:18:14 -0400, Daniel Kahn Gillmor wrote: >> When we have not been able to evaluate the signature status of a given >> MIME part, showing a content-free (and interaction-free) "[ Unknown >>

Re: subsequent rebuilds of notmuch always re-build sphinx and ruby

On Sun 2019-04-21 16:29:02 -0300, David Bremner wrote: > the html rebuild is much faster than the texinfo + info rebuilds. agreed, in the runs that i've been doing as well. I was concerned that the html rebuild itself may have been *triggering* the rebuild of the texinfo stuff, though. Sounds li

[PATCH v2 1/3] emacs: test notmuch-show during message decryption

show.expected-output/notmuch-show-undecryptable-message new file mode 100644 index ..530ff286 --- /dev/null +++ b/test/emacs-show.expected-output/notmuch-show-undecryptable-message @@ -0,0 +1,10 @@ +Daniel Kahn Gillmor (2016-12-22) (encrypted inbox) +Subject: encrypted message +To: d...@fifthho

[PATCH] emacs: drop use of message-default-charset

Apparently, message-default-charset is deprecated, which causes the following warning messages during the build: In notmuch-maildir-setup-message-for-saving: emacs/notmuch-maildir-fcc.el:172:31:Warning: ‘message-default-charset’ is an obsolete variable (as of 26.1); The default charset c

Re: [PATCH 3/3] emacs: Drop content-free "Unknown signature status" button

The first two patches in this series should be uncontroversial (they're just establishing a baseline), and i'd appreciate it if they could be considered for merging regardless of whether anyone raises an objection to this last patch of the series. On Mon 2019-04-22 13:18:14 -0400, D

[PATCH 3/3] emacs: Drop content-free "Unknown signature status" button

When we have not been able to evaluate the signature status of a given MIME part, showing a content-free (and interaction-free) "[ Unknown signature status ]" button doesn't really help the user at all, and takes up valuable screen real-estate. A visual reminder that a given message is *not* signe

[PATCH 1/3] emacs: test notmuch-show during message decryption

sage new file mode 100644 index ..530ff286 --- /dev/null +++ b/test/emacs-show.expected-output/notmuch-show-undecryptable-message @@ -0,0 +1,10 @@ +Daniel Kahn Gillmor (2016-12-22) (encrypted inbox) +Subject: encrypted message +To: d...@fifthhorseman.net +Date: Thu, 22 Dec 2016 08:34:5

[PATCH 2/3] test: show what emacs sees of an encrypted message when crypto is disabled

Some users may set notmuch-crypto-process-mime to nil, disabling all crypto use. We should have a baseline for what that looks like. --- test/T450-emacs-show.sh| 6 ++ .../notmuch-show-decrypted-message-no-crypto | 10 ++ 2 files changed, 16

Re: bug#35370: notmuch-emacs: avoiding deprecated message-default-charset

Hi Eli-- Thanks for the prompt followup! On Mon 2019-04-22 09:33:26 +0300, Eli Zaretskii wrote: > [dkg wrote:] >> Do you have any recommendation for how an external emacs module (which >> aims to work with at emacs 25 as well at least) should handle this? > > Just remove any uses of it. Why are

Re: bug#35370: notmuch-emacs: avoiding deprecated message-default-charset

On Sun 2019-04-21 18:05:19 -0400, Noam Postavsky wrote: > The commit which marks this variable as obsolete, has a couple hunks > that just remove uses of it. Not clear why other uses were left in. > Oversight? Thanks, Noam! If that's the right thing for emacs itself, that's good to know. Do you

Re: notmuch-emacs: avoiding deprecated message-default-charset

On Sun 2019-04-21 11:41:22 -0300, David Bremner wrote: > Daniel Kahn Gillmor writes: > >> When i'm building notmuch in a debian environment with emacs >> 1:26.1+1-3.2, i notice the following deprecation warnings: >> >> In notmuch-maildir-setup-message-for-savi

Re: test/T010-help-test.sh fails after ./configure --without-docs

On Sun 2019-04-21 09:49:50 -0300, David Bremner wrote: > Daniel Kahn Gillmor writes: > >> On a system where man and notmuch are both already installed, i tried to >> ./configure --without-docs to avoid the delays during development >> associated with id:87r29wwgq2@fift

Re: subsequent rebuilds of notmuch always re-build sphinx and ruby

thanks for the review, Bremner! On Sat 2019-04-20 21:12:07 -0300, David Bremner wrote: > Daniel Kahn Gillmor writes: >> 0 dkg@alice:~/src/notmuch/notmuch$ ./configure && make >> […] >> make[1]: Leaving directory '/home/dkg/src/notmuch/notmuch/bindings/ruby

test/T010-help-test.sh fails after ./configure --without-docs

On a system where man and notmuch are both already installed, i tried to ./configure --without-docs to avoid the delays during development associated with id:87r29wwgq2@fifthhorseman.net. The configuration succeeds, but now these tests fail: 0 dkg@alice:~/src/notmuch/notmuch$ make check NOTMU

subsequent rebuilds of notmuch always re-build sphinx and ruby

Hi folks-- when i run "make" from my source tree, and it succeeds, i typically expect that running "make" again will show that nothing needs to be done. but that's not the case. Both the sphinx-based documentation and the ruby notmuch.so are always rebuilt, i think due to some sort of dependency

notmuch-emacs: avoiding deprecated message-default-charset

When i'm building notmuch in a debian environment with emacs 1:26.1+1-3.2, i notice the following deprecation warnings: In notmuch-maildir-setup-message-for-saving: emacs/notmuch-maildir-fcc.el:172:31:Warning: ‘message-default-charset’ is an obsolete variable (as of 26.1); The default charset

[PATCH] emacs: hint that notmuch-mua-attachment-regexp is a regular expression

Without this change, we see the following warnings during the build: ``` In toplevel form: emacs/notmuch-mua.el:119:1:Warning: defcustom for ‘notmuch-mua-attachment-regexp’ fails to specify type emacs/notmuch-mua.el:119:1:Warning: defcustom for ‘notmuch-mua-attachment-regexp’ fails to spec

[PATCH] cli/show: pass the siglist directly to the sigstatus sprinter

This makes it easier to reuse format_part_sigstatus_sprinter() when we have other places that we want to display a signature status. --- notmuch-show.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/notmuch-show.c b/notmuch-show.c index 07e9a5db..88699e90 100644 --- a/no

[PATCH] tests: move FINGERPRINT definition to add_gnupg_home

If a test has added a GnuPG homedir, it may well want to know the fingerprint. This saves us from having to redefine this magic string in multiple places when more tests evenutally use the GnuPG homedir. --- test/T350-crypto.sh | 2 -- test/test-lib.sh| 3 +++ 2 files changed, 3 insertions(+)

[PATCH] crypto: Avoid pretending to verify signatures on unsigned encrypted mail

Unsigned encrypted mail shows up with a weird empty signature list. If we successfully decrypted and there was no signature in it, we should just not show a sigstatus at all. The documentation for g_mime_decrypt_result_get_signatures says: a GMimeSignatureList or NULL if the stream was not si

Re: Unexpected output of "notmuch new --quiet"

On Fri 2019-04-19 15:55:27 +0200, Ralph Seichter wrote: > * Daniel Kahn Gillmor: > >> Why is "non-mail file found" in my maildir such a low priority? > > Because I do not agree with Notmuch's notion of what a non-mail file > is. All files the Dovecot server

Re: Unexpected output of "notmuch new --quiet"

On Thu 2019-04-18 15:52:19 +0200, Ralph Seichter wrote: > Personally, I'd go with these decreasing levels of severity: > > Fatal: Execution must stop immediately to prevent damage, error > message may or may not be displayed before exiting the process. > > Error: Serious trouble, program may

Re: Autocrypt support

On Thu 2019-04-11 16:01:43 +0200, Ralph Seichter wrote: > I'm not quite sure if this is a question of Notmuch's Emacs client or of > Emacs in general, but I am trying to find information on Autocrypt > support (see https://autocrypt.org/). > > The Enigmail addon for Thunderbird supports Autocrypt,

Re: [PATCH] emacs: Add References header to forwarded messages

On Fri 2019-03-29 13:01:09 +0100, Örjan Ekeberg wrote: > Include the message-id of forwarded messages in the new message. > This ensures that the new (forwarding) message is linked to the > same thread as the message being forwarded. This seems reasonable to me. I'd personally like forwarded m

message forwarding features: challenges and open questions

over in the series introduced with id:20190330214821.4150-1-ekeb...@kth.se, Örjan Ekeberg proposed tagging messages when we've forwarded them. These changes got me thinking more generally about what capabilities a good MUA should offer related to message forwarding, and how to get notmuch-emacs cl

Re: [PATCH 0/2] Updating tags when replying or forwarding via a buffer-local variable

On Sat 2019-03-30 22:48:19 +0100, Örjan Ekeberg wrote: > These patches implement a message-send-hook which uses a buffer-local variable > to tag replied and forwarded messages. > > The first patch replaces the current heuristic hook for detecting reply > messages with an explicit setting when the r

Re: [PATCH 2/2] release: use xz compression

On Tue 2019-03-19 07:08:19 -0300, David Bremner wrote: > This produces tarballs that are roughly 30% smaller. LGTM. I can confirm that i'm seeing tarball sizes go from 924543 bytes (or 917179 bytes with gzip -9) to 644892 bytes with this xz approach. I think the ecosystem that notmuch targets *c

Re: [PATCH 1/2] release: provide clearsigned sha256sum

On Tue 2019-03-19 07:08:18 -0300, David Bremner wrote: > To quote id:87ftrpgjdb@fifthhorseman.net > > if the thing verified is the output of sha256sum, then the > *filename* of the tarball itself is included, then the standard > verification step will is sufficient to ensure that

[PATCH] doc: Clean up warnings when building notmuch-emacs docs

: Unexpected indentation. This source change doesn't seem to have any effect on the generated HTML, at least. Signed-off-by: Daniel Kahn Gillmor --- doc/notmuch-emacs.rst | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/doc/notmuch-emacs.rst b/doc/notmuch-emac

[PATCH v2 1/3] build: ensure that SHA256_FILE is built

The SHA256_FILE used to be built automatically because of the makefile dependencies. Since b8a8dbed91d16299a8768646fb6f18181f31ec40, it isn't getting made properly, so the release target would fail. Signed-off-by: Daniel Kahn Gillmor --- Makefile.local | 2 +- 1 file changed, 1 insertion(

[PATCH v2 2/3] build: distribute signed sha256sums

and other messages in that thread for discussion. Signed-off-by: Daniel Kahn Gillmor --- Makefile.global | 2 +- Makefile.local | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile.global b/Makefile.global index 6e17494a..27c82433 100644 --- a/Makefile.global +++ b

[PATCH v2 3/3] build: Rename GPG_FILE to DETACHED_SIG_FILE

This is just a semantic cleanup -- we have multiple files that are OpenPGP signatures. And while we're probably making signatures with GnuPG, they can be verified with any OpenPGP implementation, so "GPG_" is arguably both not specific enough, and overly-specific. Signed-off-

[PATCH] build: distribute signed sha256sums

thread for discussion. Signed-off-by: Daniel Kahn Gillmor --- Makefile.global | 3 +-- Makefile.local | 13 + 2 files changed, 6 insertions(+), 10 deletions(-) diff --git a/Makefile.global b/Makefile.global index 6e17494a..11fd0cee 100644 --- a/Makefile.global +++ b/Makefile.global

Re: [PATCH] build: sign tarball instead of sha256sum

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri 2019-03-15 15:30:56 +0100, Adam Majer wrote: > The .spec file has (I added some comments here) > > Name: nodejs10 > Version:10.15.3 > Source: https://nodejs.org/dist/v%{version}/node-v%{version}.tar.xz > Source1:

Re: [PATCH] build: sign tarball instead of sha256sum

On Fri 2019-03-15 10:50:34 -0300, David Bremner wrote: > Adam Majer writes: > >> The (my?) expectation is that a *.asc file is a detached signature. >> That's why GPG is warning when it is not a detached signature. But I can >> live with .sha256.asc if there is no .sha256 ;) > > Right, aren't de

Re: [PATCH] build: sign tarball instead of sha256sum

On Fri 2019-03-15 10:56:58 -0300, David Bremner wrote: > Daniel Kahn Gillmor writes: > >> sure, though i'd change the .sha256.asc to be a clearsigned file instead >> of the current ASCII-armored OpenPGP message that it currently is (as >> Adam suggested elsewhere

Re: [PATCH] build: sign tarball instead of sha256sum

On Fri 2019-03-15 07:49:16 -0300, David Bremner wrote: > BTW2: In a sense everyone has other defences since the tar ball contains a > file "version" with the version in it. Right, if there was a standard/conventional way to indicate the package name and version information *within* any source tarb

Re: [PATCH] build: sign tarball instead of sha256sum

On Fri 2019-03-15 12:35:55 +0100, Adam Majer wrote: > # osc chroot > running: sudo chroot /var/tmp/build-root/openSUSE_Tumbleweed-x86_64 su - > abuild > # gpgv > -bash: gpgv: command not found That's surprising to me, but i'm ignorant about SUSE so you shouldn't be surprised at my surprise :P Ho

Re: [PATCH] build: sign tarball instead of sha256sum

On Fri 2019-03-15 02:53:28 +0100, Adam Majer wrote: > adding explicit checks would add an extra BuildRequires in the build > process to pull in gpg, which is excessive. It shouldn't require gpg; it should only pull in gpgv, which is already on the base system, no? And once the "small file" is che

Re: [PATCH] build: sign tarball instead of sha256sum

On Thu 2019-03-14 22:49:44 -0300, David Bremner wrote: > OK, so apparently this is a problem for almost every project, including > GnuPG? That's mildly terrifying... sigh, i know :( > I don't mind either way, but it does seem like there is a tradeoff, > since with the previous version I suspect m

Re: [PATCH] build: sign tarball instead of sha256sum

On Tue 2019-03-12 07:55:19 -0300, David Bremner wrote: > David Bremner writes: > >> Adam Majer pointed out in [1] the way were signing releases was >> unusual. Neither Carl nor I could think of a good reason for >> explicitely signing the checksum (internally of course that's what GPG >> is going

Re: non-ascii email forwarding failures

On Tue 2019-02-26 00:33:33 -0500, Antoine Beaupré wrote: > Message contains characters with unknown encoding. Really send? (y or n) y > Use ASCII as charset? (y or n) y The right answer in 2019 is to use UTF-8 as a charset, everywhere. How to convince message mode to do that, i don't know. Pres

Re: [RFC] writing HTML email with notmuch

On Mon 2019-02-25 18:01:55 -0500, Antoine Beaupré wrote: > I seem to have forgotten to CC the list in my reply, sorry for the > noise. > > I elided the attachment here because I sent a newer version in > 87r2bvjx02@curie.anarc.at. thanks! > On 2019-02-25 17:11:26, Antoine Beaupr wrote: Inter

Re: [RFC] writing HTML email with notmuch

Hi Antoine-- thanks for an entertaining and thoughtful read. Your elisp rendered really strangely for me in notmuch mode in emacs: (widen) (save-excursion (set-buffer output-buffer-name) (markdown-add-xhtml-header-and-footer "")) (insert " [ multipart/alternative ]

emacs tree view usability improvement: notmuch-tree should indicate which message is being shown

hi all-- TIL about tree-view -- pressing 'Z' from a "notmuch-show" buffer is very nice, thanks to all who worked on this feature. I have a small usability improvement to ask for, sorry that my elisp is too weak to propose a patch. when i've hit Z, i get a split emacs view with two buffers -- one

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? from gpg(1): --no-tty Make sure that the TTY (terminal) is never used for any output. This option is

[PATCH] emacs: Invoke gpg with --batch and --no-tty

s one. Ensuring that notmuch-emacs always invokes gpg as a background process should avoid some of these unnecessary failure. Thanks to Justus Winter for finding this problem. Signed-off-by: Daniel Kahn Gillmor --- emacs/notmuch-crypto.el | 6 +++--- 1 file changed, 3 insertions(+), 3 dele

Re: merge broken mail threads

On Thu 2019-01-24 07:05:13 -0400, David Bremner wrote: > Daniel Kahn Gillmor writes: > >> See also the thread on this maiing list with Subject "thread merge/split >> proposal" from back in 2016, starting at >> id:87mvp9uwi4@alice.fifthhorseman.net though i d

Re: merge broken mail threads

On Wed 2019-01-23 08:29:05 -0700, Nicolas Bock wrote: > Sometimes during a lengthy discussion someone inadvertently breaks > the email thread because their mail client doesn't get it. Is > there a way to merge the two fragmented threads again with > notmuch? there's a manual way to do it as a

Re: segfault using python bindings

On Fri 2018-11-16 06:27:12 -0400, David Bremner wrote: > Floris Bruynooghe writes: > >> These are at https://github.com/flub/notmuch/tree/cffi/bindings/python-cffi >> >> I'm not really convinced of the way forward last time it was discussed >> on how to get them merged into notmuch itself so have

Re: Notmuch is working too well for me

On Thu 2018-10-11 12:42:35 +0100, Ben Oliver wrote: > On 18-10-11 14:11:54, Vika Shleina wrote: >>I think notmuch started to work too well for me. The constant feeling of >>having not much mail in the box starts to make me worried. >> >>How do you feel when using notmuch? > > I have to give a shout

Re: tell me how to do this right (mail sent to lists)

Hi Jeff-- On Tue 2018-10-09 17:02:05 +0200, Jeff Templon wrote: > I can see via another imap client (in this case MailMate / OS X) that > there are two messages in imap, both with the same messageid. One > example right now (printing the Subject header below): > > in my sent mail folder: > > [Phy

Re: [PATCH] Avoid spurious gcc warning in debugger.c

On Mon 2018-10-08 16:47:08 +0100, David Edmondson wrote: > On Monday, 2018-10-08 at 12:42:18 -03, David Bremner wrote: > >> Daniel Kahn Gillmor writes: >> >>> Without this patch, gcc 8.2.0-7 complains: >>> >>> debugger.c: In function ‘debugger_is_ac

Re: [PATCH] devel: add new tool to draw thread structure

On Mon 2018-04-09 22:45:39 -0300, David Bremner wrote: > This is useful for understanding the case where different > message-files with the same message-id have distinct reference > headers. > --- > devel/draw-thread | 35 +++ > 1 file changed, 35 insertions(+) > c

[PATCH] test: git should ignore message-id-parse

b31e44c678bf3bfe81bcc5f159e627551f12700f introduced message-id-parse as a new binary created by the test suite. It shows up as sometihng additional to git, but git ought to know to ignore it. --- test/.gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/test/.gitignore b/test/.gitignore

[PATCH] index: explicitly follow GObject conventions

Use explicit labels for GTypeInfo member initializers, rather than relying on comments and ordering. This is both easier to read, and harder to screw up. This also makes it clear that we're mis-casting GObject class initializers for gcc. Without this patch, g++ 8.2.0-7 produces this warning: CX

[PATCH] Avoid spurious gcc warning in debugger.c

Without this patch, gcc 8.2.0-7 complains: debugger.c: In function ‘debugger_is_active’: debugger.c:40:24: warning: passing argument 2 to restrict-qualified parameter aliases with argument 1 [-Wrestrict] if (readlink (buf, buf, sizeof (buf)) != -1 && ~~~ ^~~ This is pret

<    1   2   3   4   5   6   7   8   9   10   >