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

2019-04-21 Thread David Bremner
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@fifthhorseman.net.
>
> The configuration succeeds, but now these tests fail:
>
> 0 dkg@alice:~/src/notmuch/notmuch$ make check NOTMUCH_TESTS=T010-help-test.sh 
> V=1
> Missing sphinx or makeinfo, not building info pages
> INFO: using 2 minute timeout for tests
>
> T010-help-test: Testing online help
>  PASS   notmuch --help
>  PASS   notmuch help
>  PASS   notmuch --version
>  FAIL   notmuch --help tag (man pages not available)
>   test_must_fail notmuch --help tag >/dev/null
>  FAIL   notmuch help tag (man pages not available)
>   test_must_fail notmuch help tag >/dev/null
>

Are you sure you ran "make clean" after reconfiguring? I had the same
result as you because doc/_build/man was lying around from a previous
build.

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


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

2019-04-21 Thread David Bremner
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-saving:
> emacs/notmuch-maildir-fcc.el:172:31:Warning: ‘message-default-charset’ is an
> obsolete variable (as of 26.1); The default charset comes from the
> language environment
>
> I'm not enough of an emacs guru to know the right way to avoid this
> warning, but i'm hoping that someonen else can take a stab at it, since
> extraneous warnings make it easier to ignore real problems.

Good question. I looked at message.el in emacs master and it

 1) Obsoletes message-default-charset as in 26.1
 2) Still uses it in exactly the construction we do.

I'm not sure if it's exactly a reportable bug in emacs, but it is a bit
annoying.

There is a variable byte-compile-not-obsolete-vars that (probably) can
be used to suppress that warning, but it's not clear that's a good
idea (we currently do something similar for Xapian obsolescence warnings
that we can't fix).

d

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


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

2019-04-21 Thread David Bremner
Daniel Kahn Gillmor  writes:

> but it's not just texinfo, right?  it starts with the html build
> itself.  can we at least diagnose why that's happening?
>

Yes, although the html rebuild is much faster than the texinfo + info rebuilds.

>> This Makefile is generated by "ruby extconf.rb --vendor". It includes a
>> dependency on itself, so it always fires after running "ruby
>> extconf.rb". It might be only running "ruby extconf.rb" if
>> bindings/ruby/Makefile does not exist would fix this particular
>> issue. That sounds more gnu make specific than ruby specific.

> I'd be happy to test any proposed patches.  I don't really understand
> this toolchain, or why anyone would build a makefile that rewrites
> itself :/

I've posted some patches for the sphinx-doc issues a couple of hours ago
(id:20190421171245.19729-1-da...@tethera.net). 

Currently the ruby rebuild doesn't seem to be slowing things down much
for me.

╭─ convex:~/software/upstream/notmuch 
╰─ (git)-[wip/make-docs]-% /usr/bin/time make ruby-bindings 1>/dev/null
0.13user 0.02system 0:00.15elapsed 101%CPU (0avgtext+0avgdata 11504maxresident)k
0inputs+208outputs (0major+6523minor)pagefaults 0swaps

That's with an SSD, so maybe there's more of hit for other environments.

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


[PATCH 2/4] doc: use stamp file to control rebuilding texi

2019-04-21 Thread David Bremner
Apparently the sphinx-doc texinfo builder is not smart enough to only
rebuild those files where the source has changed.
---
 doc/Makefile.local | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/doc/Makefile.local b/doc/Makefile.local
index c148d74a..2a701646 100644
--- a/doc/Makefile.local
+++ b/doc/Makefile.local
@@ -16,6 +16,7 @@ MAN1_RST := $(wildcard $(srcdir)/doc/man1/*.rst)
 MAN5_RST := $(wildcard $(srcdir)/doc/man5/*.rst)
 MAN7_RST := $(wildcard $(srcdir)/doc/man7/*.rst)
 MAN_RST_FILES := $(MAN1_RST) $(MAN5_RST) $(MAN7_RST)
+ALL_RST_FILES := $(MAN_RST_FILES) $(srcdir)/doc/notmuch-emacs.rst
 
 MAN1_ROFF := $(patsubst 
$(srcdir)/doc/%,$(DOCBUILDDIR)/man/%,$(MAN1_RST:.rst=.1))
 MAN5_ROFF := $(patsubst 
$(srcdir)/doc/%,$(DOCBUILDDIR)/man/%,$(MAN5_RST:.rst=.5))
@@ -52,8 +53,11 @@ sphinx-info: | sphinx-texinfo
 sphinx-html:
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(DOCBUILDDIR)/html
 
-sphinx-texinfo:
+sphinx-texinfo: .texi.stamp
+
+$(DOCBUILDDIR)/.texi.stamp: $(ALL_RST_FILES)
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(DOCBUILDDIR)/texinfo
+   touch $@
 
 sphinx-info: sphinx-texinfo
$(MAKE) -C $(DOCBUILDDIR)/texinfo info
@@ -137,5 +141,5 @@ $(dir)/config.dox: version.stamp
echo "PROJECT_NAME = \"Notmuch $(VERSION)\"" > $@
echo "INPUT=${srcdir}/lib/notmuch.h" >> $@
 
-CLEAN := $(CLEAN) $(DOCBUILDDIR) $(DOCBUILDDIR)/.roff.stamp
+CLEAN := $(CLEAN) $(DOCBUILDDIR) $(DOCBUILDDIR)/.roff.stamp 
$(DOCBUILDDIR)/.texi.stamp
 CLEAN := $(CLEAN) $(MAN_GZIP_FILES) $(MAN_ROFF_FILES) $(dir)/conf.pyc 
$(dir)/config.dox
-- 
2.20.1

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


[PATCH 1/4] doc: don't attempt to build info pages if Emacs is missing.

2019-04-21 Thread David Bremner
This is a sledgehammer approach to conditionally (not) build the
notmuch-emacs documentation, since it is currently the only thing that
needs Emacs to build.  Hopefully in the future we can come up with a
cleaner way of disabling building the notmuch-emacs docs when emacs is
missing.
---
 doc/Makefile.local | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/Makefile.local b/doc/Makefile.local
index dfe62295..c148d74a 100644
--- a/doc/Makefile.local
+++ b/doc/Makefile.local
@@ -116,14 +116,14 @@ install-man: ${MAN_GZIP_FILES}
cd $(DESTDIR)/$(mandir)/man1 && ln -sf notmuch.1.gz notmuch-setup.1.gz
 endif
 
-ifneq ($(HAVE_SPHINX)$(HAVE_MAKEINFO),11)
+ifneq ($(HAVE_SPHINX)$(HAVE_MAKEINFO)$(HAVE_EMACS),111)
 build-info:
-   @echo "Missing sphinx or makeinfo, not building info pages"
+   @echo "Missing prerequisites, not building info pages"
 else
 build-info: sphinx-info
 endif
 
-ifneq ($(HAVE_SPHINX)$(HAVE_MAKEINFO)$(HAVE_INSTALL_INFO),111)
+ifneq ($(HAVE_SPHINX)$(HAVE_MAKEINFO)$(HAVE_INSTALL_INFO)$(HAVE_EMACS),)
 install-info:
@echo "Missing prerequisites, not installing info pages"
 else
-- 
2.20.1

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


[PATCH 4/4] build: ignore *.stamp

2019-04-21 Thread David Bremner
The current case is docstring.stamp, but it's likely that others will
arise.
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index e06101ce..468b660a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,3 +15,4 @@ tags
 .*.swp
 /releases
 /.stamps
+*.stamp
-- 
2.20.1

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


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

2019-04-21 Thread David Bremner
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(-)

diff --git a/doc/Makefile.local b/doc/Makefile.local
index 2a701646..a8fee537 100644
--- a/doc/Makefile.local
+++ b/doc/Makefile.local
@@ -50,10 +50,13 @@ sphinx-html: | $(DOCBUILDDIR)/.roff.stamp
 sphinx-texinfo: | sphinx-html
 sphinx-info: | sphinx-texinfo
 
-sphinx-html:
+sphinx-html: $(DOCBUILDDIR)/.html.stamp
+
+$(DOCBUILDDIR)/.html.stamp: $(ALL_RST_FILES)
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(DOCBUILDDIR)/html
+   touch $@
 
-sphinx-texinfo: .texi.stamp
+sphinx-texinfo: $(DOCBUILDDIR)/.texi.stamp
 
 $(DOCBUILDDIR)/.texi.stamp: $(ALL_RST_FILES)
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(DOCBUILDDIR)/texinfo
@@ -142,4 +145,5 @@ $(dir)/config.dox: version.stamp
echo "INPUT=${srcdir}/lib/notmuch.h" >> $@
 
 CLEAN := $(CLEAN) $(DOCBUILDDIR) $(DOCBUILDDIR)/.roff.stamp 
$(DOCBUILDDIR)/.texi.stamp
+CLEAN := $(CLEAN) $(DOCBUILDDIR)/.html.stamp
 CLEAN := $(CLEAN) $(MAN_GZIP_FILES) $(MAN_ROFF_FILES) $(dir)/conf.pyc 
$(dir)/config.dox
-- 
2.20.1

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Drop support for pre-1.4 Xapian, prepare for 1.5.x

2019-04-21 Thread David Bremner
David Bremner  writes:

> David Bremner  writes:
>
>> The current development release of Xapian drops several deprecated
>> APIs. This hampers testing of notmuch against Xapian master (i.e. to
>> see if a problem has been fixed). This series fixes most of the
>> incompatibilities.
>>
>> The one thing this series doesn't handle is test/T530-upgrade.sh,
>> which mostly fails because Xapian 1.5 / master drops support for
>> Chert. I think that we should probably deprecate support for notmuch
>> v1 databases. These were replaced by version 2 in 2010. I think more
>> thought is probably needed for this migration so I left those failing
>> tests for now.  This isn't quite as scary as it sounds, because we
>> really only support stable releases of Xapian, so the chert removal
>> effectively won't happen until 1.6.
>>
>
> I forgot, there's one other failing test with xapian 1.5
>
> T650-regexp-query: Testing regular expression searches
>  FAIL   null from: search
>   --- T650-regexp-query.7.EXPECTED2019-04-15 11:03:10.128070898 
> +
>   +++ T650-regexp-query.7.OUTPUT  2019-04-15 11:03:10.128070898 +
>   @@ -1 +0,0 @@
>   -thread:XXX   2001-01-05 [1/1] -; empty from (inbox unread)

I'm continuing to investigate this. The following program finds one
result (in tmp.T650-regexp-query) in 1.4 and 0 results in Xapian
master. I'd give about 50% odds that I'm just doing something silly.

#include 
#include 

int main(int argc, char **argv) {

Xapian::Database db("mail/.notmuch/xapian");
Xapian::Query query(Xapian::Query::OP_AND_NOT,
Xapian::Query("Tmail"),
Xapian::Query(Xapian::Query::OP_WILDCARD, "XFROM", 0,
 Xapian::Query::WILDCARD_LIMIT_ERROR, 
Xapian::Query::OP_SYNONYM));

Xapian::Enquire enquire(db);

enquire.set_query(query);

Xapian::MSet mset = enquire.get_mset(0,100);

std::cout << "mset " << mset.get_description() << std::endl;

for (auto i = mset.begin(); i != mset.end(); ++i) {
std::cout << (*i) << std::endl;
}
}
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


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

2019-04-21 Thread Daniel Kahn Gillmor
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-saving:
>> emacs/notmuch-maildir-fcc.el:172:31:Warning: ‘message-default-charset’ is an
>> obsolete variable (as of 26.1); The default charset comes from the
>> language environment
>>
>> I'm not enough of an emacs guru to know the right way to avoid this
>> warning, but i'm hoping that someonen else can take a stab at it, since
>> extraneous warnings make it easier to ignore real problems.
>
> Good question. I looked at message.el in emacs master and it
>
>  1) Obsoletes message-default-charset as in 26.1
>  2) Still uses it in exactly the construction we do.

interesting, thanks for digging that up.

> I'm not sure if it's exactly a reportable bug in emacs, but it is a bit
> annoying.

seems reportable, if not exactly high-severity.  what does upstream
expect downstream users of message-default-charset to do?  I'm
(trying to) forward this to the emacs upstream bugtracker; maybe we can
get guidance from them on what to do.

> There is a variable byte-compile-not-obsolete-vars that (probably) can
> be used to suppress that warning, but it's not clear that's a good
> idea (we currently do something similar for Xapian obsolescence warnings
> that we can't fix).

I would generally try to avoid that kind of a bypass, because i tend to
think that warnings are reasonable to look out for and try to fix before
they become real problems.

  --dkg


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


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

2019-04-21 Thread Daniel Kahn Gillmor
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@fifthhorseman.net.
>>
>> The configuration succeeds, but now these tests fail:
>>
>> 0 dkg@alice:~/src/notmuch/notmuch$ make check 
>> NOTMUCH_TESTS=T010-help-test.sh V=1
>> Missing sphinx or makeinfo, not building info pages
>> INFO: using 2 minute timeout for tests
>>
>> T010-help-test: Testing online help
>>  PASS   notmuch --help
>>  PASS   notmuch help
>>  PASS   notmuch --version
>>  FAIL   notmuch --help tag (man pages not available)
>>  test_must_fail notmuch --help tag >/dev/null
>>  FAIL   notmuch help tag (man pages not available)
>>  test_must_fail notmuch help tag >/dev/null
>
> Are you sure you ran "make clean" after reconfiguring? I had the same
> result as you because doc/_build/man was lying around from a previous
> build.

Thanks, Bremner!  Turns out that was exactly what i was running into.
"make clean" and then rebuilding does indeed solve the problem for me.
this was a bug in my workflow, not a bug in notmuch itself.

 --dkg


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


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

2019-04-21 Thread Daniel Kahn Gillmor
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 have any recommendation for how an external emacs module (which
aims to work with at emacs 25 as well at least) should handle this?

 --dkg


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 1/4] doc: don't attempt to build info pages if Emacs is missing.

2019-04-21 Thread David Bremner
David Bremner  writes:

> This is a sledgehammer approach to conditionally (not) build the
> notmuch-emacs documentation, since it is currently the only thing that
> needs Emacs to build.  Hopefully in the future we can come up with a
> cleaner way of disabling building the notmuch-emacs docs when emacs is
> missing.

This is not enough, but itself, as docstrings.stamp also needs to be
special cased. And that still leaves a bunch of ugly warnings and errors
when building the man pages. So I probably need to rething this patch.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


[PATCH 2/2] doc: exclude notmuch-emacs.rst if emacs is not present.

2019-04-21 Thread David Bremner
This will still generate a warning about an excluded document in the
toctree, but it cuts down on the noise quite a lot.
---
 doc/Makefile.local | 2 +-
 doc/conf.py| 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/doc/Makefile.local b/doc/Makefile.local
index 57104dae..651168f4 100644
--- a/doc/Makefile.local
+++ b/doc/Makefile.local
@@ -4,7 +4,7 @@ dir := doc
 
 # You can set these variables from the command line.
 SPHINXOPTS:= -q
-SPHINXBUILD   = sphinx-build
+SPHINXBUILD   = HAVE_EMACS=${HAVE_EMACS} sphinx-build
 DOCBUILDDIR  := $(dir)/_build
 
 # Internal variables.
diff --git a/doc/conf.py b/doc/conf.py
index 0ef72327..5f8c9f1c 100644
--- a/doc/conf.py
+++ b/doc/conf.py
@@ -29,6 +29,11 @@ release = version
 # directories to ignore when looking for source files.
 exclude_patterns = ['_build']
 
+# If we don't have emacs, don't build the notmuch-emacs docs, as they need
+# emacs to generate the docstring include files
+if os.environ.get('HAVE_EMACS') != '1':
+exclude_patterns.append('notmuch-emacs.rst')
+
 # The name of the Pygments (syntax highlighting) style to use.
 pygments_style = 'sphinx'
 
-- 
2.20.1

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


[PATCH 1/2] build: only try to build .rsti files if we have emacs and sphinx

2019-04-21 Thread David Bremner
Emacs is needed to build them, and sphinx is needed to use them
---
 emacs/Makefile.local | 5 +
 1 file changed, 5 insertions(+)

diff --git a/emacs/Makefile.local b/emacs/Makefile.local
index 04913a06..40b7c14f 100644
--- a/emacs/Makefile.local
+++ b/emacs/Makefile.local
@@ -47,8 +47,13 @@ emacs_images := \
 emacs_bytecode = $(emacs_sources:.el=.elc)
 emacs_docstrings = $(emacs_sources:.el=.rsti)
 
+ifneq ($(HAVE_SPHINX)$(HAVE_EMACS),11)
+docstring.stamp:
+   @echo "Missing prerequisites, not collecting docstrings"
+else
 docstring.stamp: ${emacs_docstrings}
touch $@
+endif
 
 # Because of defmacro's and defsubst's, we have to account for load
 # dependencies between Elisp files when byte compiling.  Otherwise,
-- 
2.20.1

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


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

2019-04-21 Thread Daniel Kahn Gillmor
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'
>> 0 dkg@alice:~/src/notmuch/notmuch$ make --trace
>> doc/Makefile.local:53: update target 'sphinx-html' due to: docstring.stamp
>> sphinx-build -b html -d doc/_build/doctrees -q ./doc doc/_build/html
>> doc/Makefile.local:56: update target 'sphinx-texinfo' due to: docstring.stamp
>> sphinx-build -b texinfo -d doc/_build/doctrees -q ./doc doc/_build/texinfo
>> doc/Makefile.local:59: update target 'sphinx-info' due to: sphinx-texinfo
>> make -C doc/_build/texinfo info
>> make[1]: Entering directory 
>> '/home/dkg/src/notmuch/notmuch/doc/_build/texinfo'
>> Makefile:32: update target 'notmuch-search-terms.info' due to: 
>> notmuch-search-terms.texi
>
> This is not our Makefile, but something generated by sphinx; it would
> not be that hard to replace if the problem was there. Alas I think the
> underlying problem seems to be that "sphinx-build -b texinfo" is
> regenerating (or at least touching) all of the texi files. I suspect
> that's a limitation of sphinx-builder texinfo output.

but it's not just texinfo, right?  it starts with the html build
itself.  can we at least diagnose why that's happening?

>> cd bindings/ruby && \
>>  EXTRA_LDFLAGS="-Wl,--no-undefined" \
>>  LIBNOTMUCH="../../lib/libnotmuch.so" \
>>  NOTMUCH_SRCDIR='/home/dkg/src/notmuch/notmuch' \
>>  ruby extconf.rb --vendor
>> creating Makefile
>> make -C bindings/ruby
>> make[1]: Entering directory '/home/dkg/src/notmuch/notmuch/bindings/ruby'
>> Makefile:258: update target 'notmuch.so' due to: Makefile
>> echo linking shared-object notmuch.so
>> linking shared-object notmuch.so
>> rm -f notmuch.so
>> gcc -shared -o notmuch.so database.o directory.o filenames.o init.o 
>> message.o messages.o query.o status.o tags.o thread.o threads.o -L. 
>> -L/usr/lib/x86_64-linux-gnu -L. -Wl,-z,relro -Wl,-z,now -fstack-protector 
>> -rdynamic -Wl,-export-dynamic -Wl,--no-undefined -Wl,-z,relro -Wl,-z,now 
>> -Wl,--compress-debug-sections=zlib   ../../lib/libnotmuch.so -lruby-2.5  
>> -lpthread -lgmp -ldl -lcrypt -lm   -lc
>> make[1]: Leaving directory '/home/dkg/src/notmuch/notmuch/bindings/ruby'
>> 0 dkg@alice:~/src/notmuch/notmuch$
>
> This Makefile is generated by "ruby extconf.rb --vendor". It includes a
> dependency on itself, so it always fires after running "ruby
> extconf.rb". It might be only running "ruby extconf.rb" if
> bindings/ruby/Makefile does not exist would fix this particular
> issue. That sounds more gnu make specific than ruby specific.

I'd be happy to test any proposed patches.  I don't really understand
this toolchain, or why anyone would build a makefile that rewrites
itself :/

   --dkg


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch