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.
Since message is owned by messages, it was held for the entire run of
the program. This in turn means that the Xapian::Document objects are
not freed, and thus one ends up with (effectively) a copy of one's
entire mailstore in memory when running
notmuch reindex '*'
Thanks to Olly Betts for the patient help debugging, and the
suggestion of a fix.
The new `body:` field (in Xapian terms) or prefix (in slightly
sloppier notmuch) terms allows matching terms that occur only in the
body.
Unprefixed query terms should continue to match anywhere (header or
body) in the message.
This follows a suggestion of Olly Betts to use the facility (since
Xapian 1.0.4) to add the same field with multiple prefixes. The double
indexing of previous versions is thus replaced with a query time
expension of unprefixed query terms to the various prefixed
equivalent.
Reindexing will be needed for 'body:' searches to work correctly;
otherwise they will also match messages where the term occur in
headers (demonstrated by the new tests in T530-upgrade.sh)
Add test of forwarding messages from within emacs.
The first test checks that a references header is properly
added to the new message. The second test checks that the
send-hook of the forwarding message adds a forwarded-tag
to the original message.
Instead of relying on the "In-Reply-To" header, use a buffer-local variable,
notmuch-message-queued-tag-changes, to add and remove tags to affected
messages when the message-send-hook is triggered.
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.
Several people have observed that this is surprisingly slow, and we
have a proposal to add tagging into this code path, so we want to make
sure it doesn't imply too much of a performance hit.
Fix notmuch-describe-key crashing for the following two cases
1. format-kbd-macro cannot deal with keys like [(32 . 126)], switch to
use key-description instead.
2. if a function in the current keymap is not bounded, it will crash
the whole process. We check if it is bounded and silently skip it to
avoid crashing.
Query the user if the message text indicates that an attachment is
expected but no MML referencing an attachment is found.
This is not enabled by default - see the documentation for
`notmuch-mua-attachment-check'.
Thanks to plujon for pointing out this problem on IRC. The underlying
issue is that the quotes are stripped before the field processors get
the query string, and the heuristic for putting them back is not quite
right.
Add a new binding when looking at messages, B, that prompts with a
list of URLs found in the current message, if any. Open the one that
is selected in a browser.
amended by db: s/--browse-urls/-browse-urls/
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-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Distribute clearsigned sha256sum file in addition to the detached
signature.
Verifies that use the sha256sum ensure that the thing signed includes
the name of the tarball. This defends the verifier by default against
a freeze, rollback, or project substitution attack.
A verifier can use something like the following (as expressed in
bash):
set -o pipefail
wget https://notmuchmail.org/releases/notmuch-$VERSION.tar.gz{,.sha256.asc}
gpgv --keyring ./notmuch-signers.pgp --output - notmuch-$VERSION.tar.gz.sha256.asc | sha256sum -c -
See id:87r2b8w956.fsf@fifthhorseman.net and other messages in that
thread for discussion.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
The SHA256_FILE used to be built automatically because of the makefile
dependencies.
Since b8a8dbed91, it isn't getting made
properly, so the release target would fail.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Without this change, we see this during the build:
sphinx-build -b html -d doc/_build/doctrees -q ./doc doc/_build/html
…/doc/notmuch-emacs.rst:67: WARNING: Unexpected indentation.
…/doc/notmuch-emacs.rst:165: WARNING: Unexpected indentation.
…/doc/notmuch-emacs.rst:306: WARNING: Unexpected indentation.
This source change doesn't seem to have any effect on the generated
HTML, at least.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This should silence some warnings about the jobserver, but also make
it easier to build the docs where GNU make is called something other
than make.
Based on a patch from aidecoe.
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 anyway).
[1] mid:b3fd556d-c346-7af9-a7a2-13b0f3235071@suse.de
libnotmuch_util.a is supposed to be usable from the library and the
CLI, but much the library is compiled as C++. Add in appropriate
wrapping to prevent symbol mangling. These wrappers already existed in
string-util.h; it seems better to be consistent.
The exact error messages returned by regerror() aren't standardized;
relying on them isn't portable. Thus, add a a prefix to make clear that
the subsequent message is a regexp parsing error, and only look for this
prefix in the test suite, ignoring the rest of the message.
POSIX doesn't specify the flushing behaviour of the STDOUT stream, so
it's invalid to assume a particular order between the stdout and stderr
output. The current test breaks on musl due to this.
In certain conditions the parallel calls to sphinx-build could
collide, yielding a crash like
Exception occurred:
File "/usr/lib/python3/dist-packages/sphinx/environment.py", line 1261, in get_doctree
doctree = pickle.load(f)
EOFError: Ran out of input
I can't figure out how checking the sign of a bool ever worked. The
following program demonstrates the problem (i.e. for me it prints 1).
#include <stdio.h>
#include <stdbool.h>
int main(int argc, char **argv) {
bool x;
x = -1;
printf("x = %d\n", x);
}
This seems to be mandated by the C99 standard 6.3.1.2.
