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 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 Notmuch test suite complete. 3/5 tests passed. 2 tests failed. make: *** [test/Makefile.local:75: test] Error 1 [1]+ Donegitk --all 2 dkg@alice:~/src/notmuch/notmuch$ It seems likely that they're "failing to fail" because the main system i'm building on has both notmuch and man installed -- so maybe the locally-built notmuch is successfully opening the manual pages from the system instead of the development manpages. I did a bit of digging to try to understand the issue, and noticed that the comments about test_must_fail in test/test-lib.sh seem out of date (they assume two arguments instead of one, and they refer to their earlier provenance in git, rather than notmuch). But i think the problem isn't with test_must_fail itself, even though the function's documentation appears to be out of date. --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: subsequent rebuilds of notmuch always re-build sphinx and ruby
Daniel Kahn Gillmor writes: > 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 loop. > > But i don't really understand the dependencies there. Maybe someone who > understands either ruby or sphinx better than i do can clean it up? > Having clean dependency tracking and quick rebuilds makes a project a > lot more fun to hack on. > > Here's a trace of the rebuild process: > > 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. > 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. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
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 loop. But i don't really understand the dependencies there. Maybe someone who understands either ruby or sphinx better than i do can clean it up? Having clean dependency tracking and quick rebuilds makes a project a lot more fun to hack on. Here's a trace of the rebuild process: 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 makeinfo --no-split -o 'notmuch-search-terms.info' 'notmuch-search-terms.texi' Makefile:32: update target 'notmuch-compact.info' due to: notmuch-compact.texi makeinfo --no-split -o 'notmuch-compact.info' 'notmuch-compact.texi' Makefile:32: update target 'notmuch-show.info' due to: notmuch-show.texi makeinfo --no-split -o 'notmuch-show.info' 'notmuch-show.texi' Makefile:32: update target 'notmuch-reply.info' due to: notmuch-reply.texi makeinfo --no-split -o 'notmuch-reply.info' 'notmuch-reply.texi' Makefile:32: update target 'notmuch-hooks.info' due to: notmuch-hooks.texi makeinfo --no-split -o 'notmuch-hooks.info' 'notmuch-hooks.texi' Makefile:32: update target 'notmuch-config.info' due to: notmuch-config.texi makeinfo --no-split -o 'notmuch-config.info' 'notmuch-config.texi' Makefile:32: update target 'notmuch-reindex.info' due to: notmuch-reindex.texi makeinfo --no-split -o 'notmuch-reindex.info' 'notmuch-reindex.texi' Makefile:32: update target 'notmuch-restore.info' due to: notmuch-restore.texi makeinfo --no-split -o 'notmuch-restore.info' 'notmuch-restore.texi' Makefile:32: update target 'notmuch-new.info' due to: notmuch-new.texi makeinfo --no-split -o 'notmuch-new.info' 'notmuch-new.texi' Makefile:32: update target 'notmuch-dump.info' due to: notmuch-dump.texi makeinfo --no-split -o 'notmuch-dump.info' 'notmuch-dump.texi' Makefile:32: update target 'notmuch-address.info' due to: notmuch-address.texi makeinfo --no-split -o 'notmuch-address.info' 'notmuch-address.texi' Makefile:32: update target 'notmuch-tag.info' due to: notmuch-tag.texi makeinfo --no-split -o 'notmuch-tag.info' 'notmuch-tag.texi' Makefile:32: update target 'notmuch-count.info' due to: notmuch-count.texi makeinfo --no-split -o 'notmuch-count.info' 'notmuch-count.texi' Makefile:32: update target 'notmuch-search.info' due to: notmuch-search.texi makeinfo --no-split -o 'notmuch-search.info' 'notmuch-search.texi' Makefile:32: update target 'notmuch-emacs-mua.info' due to: notmuch-emacs-mua.texi makeinfo --no-split -o 'notmuch-emacs-mua.info' 'notmuch-emacs-mua.texi' Makefile:32: update target 'notmuch-emacs.info' due to: notmuch-emacs.texi makeinfo --no-split -o 'notmuch-emacs.info' 'notmuch-emacs.texi' Makefile:32: update target 'notmuch-properties.info' due to: notmuch-properties.texi makeinfo --no-split -o 'notmuch-properties.info' 'notmuch-properties.texi' Makefile:32: update target 'notmuch-insert.info' due to: notmuch-insert.texi makeinfo --no-split -o 'notmuch-insert.info' 'notmuch-insert.texi' Makefile:32: update target 'notmuch.info' due to: notmuch.texi makeinfo --no-split -o 'notmuch.info' 'notmuch.texi' make[1]: Leaving directory '/home/dkg/src/notmuch/notmuch/doc/_build/texinfo' bindings/Makefile.local:8: update target 'ruby-bindings' due to: lib/libnotmuch.so 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
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 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. Sorry to provide a bug report with no proposed patch :/ --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[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 specify type EMACS emacs/notmuch-show.elc ``` --- emacs/notmuch-mua.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el index 94fa19d7..b1a31034 100644 --- a/emacs/notmuch-mua.el +++ b/emacs/notmuch-mua.el @@ -121,7 +121,8 @@ multiple parts get a header." "Message body text indicating that an attachment is expected. This is not used unless `notmuch-mua-attachment-check' is added -to `notmuch-mua-send-hook'.") +to `notmuch-mua-send-hook'." + :type '(regexp)) ;; -- 2.20.1 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[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/notmuch-show.c
+++ b/notmuch-show.c
@@ -429,13 +429,11 @@ format_signature_errors (sprinter_t *sp, GMimeSignature
*signature)
/* Signature status sprinter (GMime 2.6) */
static void
-format_part_sigstatus_sprinter (sprinter_t *sp, mime_node_t *node)
+format_part_sigstatus_sprinter (sprinter_t *sp, GMimeSignatureList *siglist)
{
/* Any changes to the JSON or S-Expression format should be
* reflected in the file devel/schemata. */
-GMimeSignatureList *siglist = node->sig_list;
-
sp->begin_list (sp);
if (!siglist) {
@@ -684,7 +682,7 @@ format_part_sprinter (const void *ctx, sprinter_t *sp,
mime_node_t *node,
if (node->verify_attempted) {
sp->map_key (sp, "sigstatus");
- format_part_sigstatus_sprinter (sp, node);
+ format_part_sigstatus_sprinter (sp, node->sig_list);
}
sp->map_key (sp, "content-type");
--
2.20.1
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
[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(+), 2 deletions(-) diff --git a/test/T350-crypto.sh b/test/T350-crypto.sh index 73aa58de..7b10f434 100755 --- a/test/T350-crypto.sh +++ b/test/T350-crypto.sh @@ -10,8 +10,6 @@ test_description='PGP/MIME signature verification and decryption' ## add_gnupg_home -# Change this if we ship a new test key -FINGERPRINT="5AEAB11F5E33DCE875DDB75B6D92612D94E46381" test_begin_subtest "emacs delivery of signed message" test_expect_success \ diff --git a/test/test-lib.sh b/test/test-lib.sh index fca5277d..58909ee7 100644 --- a/test/test-lib.sh +++ b/test/test-lib.sh @@ -117,6 +117,9 @@ add_gnupg_home () echo debug-quick-random >> "$GNUPGHOME"/gpg.conf fi echo no-emit-version >> "$GNUPGHOME"/gpg.conf + +# Change this if we ship a new test key +FINGERPRINT="5AEAB11F5E33DCE875DDB75B6D92612D94E46381" } # Each test should start with something like this, after copyright notices: -- 2.20.1 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[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 signed.
---
mime-node.c | 2 +-
test/T350-crypto.sh | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
This was originally sent to the list as part of a longer patch series
in id:20180511055544.13676-3-...@fifthhorseman.net but i think it
stands alone, and it would help me to reduce the size of the
outstanding patch series to get it applied to master :)
diff --git a/mime-node.c b/mime-node.c
index 2a24e537..1bfb479b 100644
--- a/mime-node.c
+++ b/mime-node.c
@@ -218,12 +218,12 @@ node_decrypt_and_verify (mime_node_t *node, GMimeObject
*part,
}
node->decrypt_success = true;
-node->verify_attempted = true;
if (decrypt_result) {
/* This may be NULL if the part is not signed. */
node->sig_list = g_mime_decrypt_result_get_signatures (decrypt_result);
if (node->sig_list) {
+ node->verify_attempted = true;
g_object_ref (node->sig_list);
set_signature_list_destructor (node);
}
diff --git a/test/T350-crypto.sh b/test/T350-crypto.sh
index 73aa58de..80d57847 100755
--- a/test/T350-crypto.sh
+++ b/test/T350-crypto.sh
@@ -271,7 +271,6 @@ expected='[[[{"id": "X",
"Date": "Sat, 01 Jan 2000 12:00:00 +"},
"body": [{"id": 1,
"encstatus": [{"status": "good"}],
- "sigstatus": [],
"content-type": "multipart/encrypted",
"content": [{"id": 2,
"content-type": "application/pgp-encrypted",
--
2.20.1
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected output of "notmuch new --quiet"
* David Bremner: > Right, I think that point is clear now, that we're just talking about > changing the warning messages. Indeed. I am actually quite surprised how many reactions there were about this minor issue. I'm using the new.ignore settings you suggested, and I can live with that. The warning messages surprised me, is all. > I'm not saying I'm going to work on it, but I think I understand the > feature-request. I'd appreciate a change at some point in the future, time permitting, but I would not begrudge you spending your energy on more important issues. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected output of "notmuch new --quiet"
Ralph Seichter writes: > * Eric: > >> I think that there will be lots of people (and organisations) who get >> collections of email from elsewhere and want to add them all to their >> own single collection for reference, archival, and research purposes. > > And how would dropping individual mail files into "cur" instead of any > old folder limit that? The issue is more that people have existing mail setups that work, and we don't want to break them without a good reason; on the other hand changing the default messages would probably not really count as breakage. > My point is: Maildir has a defined structure. I'm not against Notmuch > supporting a wider range of layouts, but I think Notmuch should not > complain about perfectly legitimate non-mail files found outside the > Maildir scope. Right, I think that point is clear now, that we're just talking about changing the warning messages. I'm not saying I'm going to work on it, but I think I understand the feature-request. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected output of "notmuch new --quiet"
* Eric: > I think that there will be lots of people (and organisations) who get > collections of email from elsewhere and want to add them all to their > own single collection for reference, archival, and research purposes. And how would dropping individual mail files into "cur" instead of any old folder limit that? > So that those emails would be forced into the IMAP folder structure, > making them visible (and possible distracting) there when viewed with > a traditional mail client? I don't know why you talk about "forced", and it is not an IMAP folder structure anyway. I have configured Dovecot to use a Maildir store specifically to allow Notmuch as a client in addition to IMAP. Other storage types like Multi-dbox would be more efficient for IMAP users. In my setup, I could circumvent Dovecot's LDA and have Postfix drop off mail directly in that same Maildir structure, but I want to enable users to use Sieve scripts. This works because Dovecot and Postfix have very similar ideas about how a Maildir store should look like. My point is: Maildir has a defined structure. I'm not against Notmuch supporting a wider range of layouts, but I think Notmuch should not complain about perfectly legitimate non-mail files found outside the Maildir scope. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] python: support relative path in default database
Looks good. Sorry for missing this.
On Friday, 2019-04-19 at 10:56:59 +07, Doan Tran Cong Danh wrote:
> From notmuch 0.28, notmuch support relative database path in
> notmuch-config(1), but python binding haven't taught this yet.
>
> afew denied to work with a perfectly fine notmuch-config due to this.
> ---
> bindings/python/notmuch/database.py | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/bindings/python/notmuch/database.py
> b/bindings/python/notmuch/database.py
> index 342d665a..88ca836e 100644
> --- a/bindings/python/notmuch/database.py
> +++ b/bindings/python/notmuch/database.py
> @@ -675,7 +675,10 @@ class Database(object):
> if not config.has_option('database', 'path'):
> raise NotmuchError(message="No DB path specified"
> " and no user default found")
> -return config.get('database', 'path')
> +db_path = config.get('database', 'path')
> +if not os.path.isabs(db_path):
> +db_path = os.path.expanduser(os.path.join("~", db_path))
> +return db_path
>
> """notmuch_database_get_config"""
> _get_config = nmlib.notmuch_database_get_config
> --
> 2.21.0
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
dme.
--
But are you safe Miss Gradenko?
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected output of "notmuch new --quiet"
On Sat, 20 Apr 2019 01:46:30 +0200, Ralph Seichter wrote: > * Daniel Kahn Gillmor: > > > as far as maildir goes, i think notmuch probably *shouldn't* be > > looking at stuff in â¦/tmp/ -- right? > > You're right, I don't see why Notmuch would peek into "tmp". > > > I'd be sad if those files went away, but perhaps you're right that > > we should only be looking at are things within any cur/ and new/ > > subfolders within the message archive. > > I don't mean to reduce Notmuch usability to get rid of a few unwanted > messages on stderr. What I suggest is to consider all files outside of > "cur" and "new" to be legitimate non-mail files by default. If Notmuch > chooses to inspect them and detects valid messages, then fine, but the > default assumption should be non-mail. I suppose that having a configuration item to make notmuch do what it does now if the default behaviour is changed isn't an enormous usability reduction, but I still don't like it, and I would be very wary of assuming that the necessary changes to the code will be as simple as it sounds. > Think about how the files get there. You manually dumping some *.eml > files in a directory is not exactly typical, IMO. ;-) I think that there will be lots of people (and organisations) who get collections of email from elsewhere and want to add them all to their own single collection for reference, archival, and research purposes. > I expect that in the majority of cases there is some MTA or fetchmail-like > process storing mail files in a Maildir structure (flat, tree, or mixed > like Dovecot does). So that those emails would be forced into the IMAP folder structure, making them visible (and possible distracting) there when viewed with a traditional mail client? > I think that altering Notmuch's expectations about files outside of > well-known subdirectories should be possible without sacrificing its > flexibility. No, because that is part of its flexibility. Removing, or degrading, notmuch's ability to access such files will mean that I may be looking for a different solution to managing my email. That, of course, amy not matter much to anyone else, but how many others will there be? Eric -- ms fnd in a lbry ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
