Originally the intent was to make the test more robust against changing
test keys. It turns out that (unscientifically) gpg --with-colons output
changes more often than our test key. Rather than making the script more
complex, just hard code the fingerprint.
This fixes Debian bug #847013; I expect similar test failures as other
distros adopt gnupg 2.1.15
gdb sometimes writes warnings to stdout, which we don't need/want, and
for some reason --batch-silent isn't enough to hide. So in this commit
we write them to a log file, which is probably better for debugging
anyway. To see an illustrative test failure before this change, run
% make
% touch notmuch-count.c
% cd test && ./T060-count.sh
(cherry picked from commit f45fa5bdd3)
Note: this patch drops -w from the shebang line, but we still have
"use warnings" in the script, which is superior anyhow.
Thanks Andreas Tolfsen for the suggestion.
Fix bug reported in id:20160606124522.g2y2eazhhrwjsa4h@flatcap.org
Although the C99 standard 6.10 is a little non-obvious on this point,
the docs for e.g. gcc are unambiguous. And indeed in practice with the
extra space, this code fails
#include <stdio.h>
#define foo (x) (x+1)
int main(int argc, char **argv){
printf("%d\n",foo(1));
}
This has been wrong since bbbdf0478e, but the race condition was not
previously been (often?) triggered in the tests. With the DB_RETRY_LOCK
patches, it manifests itself as a deadlock.
When composing messages (including replies, etc.), indicate to
`message-mode' definitively that the message is email (as opposed to
Usenet news) rather than having it attempt to determine this for itself.
This causes `message-mode' to observe such variables as
`message-default-mail-headers', which previously happened haphazardly.
`notmuch--get-bodypart-raw' previously assumed that all non-binary MIME
parts could be successfully read by assuming that they were UTF-8
encoded. This was demonstrated to be wrong, specifically when a part was
marked as ISO8859-1 and included accented characters (which were
incorrectly rendered as a result).
Rather than assuming UTF-8, attempt to use the part's declared charset
when reading it, falling back to US-ASCII if the declared charset is
unknown, unsupported or invalid.
A non-technical introduction for users who read NEWS to have better
chance to find ./devel/notmuch-emacs-mua when they test or experiment
with notmuch emacs MUA next time.
The usual make message on everything being up to date is:
make: Nothing to be done for 'all'.
However, since
commit d038b93209
Author: David Bremner <david@tethera.net>
Date: Mon Jun 1 09:08:59 2015 +0200
build: integrate building ruby bindings into notmuch build process
if one doesn't have the ruby dependencies installed, the message has
been:
Missing dependency, skipping ruby bindings
Restore the usual behaviour by dropping the message. It's redundant
during build anyway, since the configure script already outputs:
Checking for ruby development files... No (skipping ruby bindings)
To fully complete the ghost-on-removal-when-shared-thread-exists
proposal, we need to clear all ghost messages when the last active
message is removed from a thread.
Amended by db: Remove the last test of T530, as it no longer makes sense
if we are garbage collecting ghost messages.
There is no need to add a ghost message upon deletion if there are no
other active messages in the thread.
Also, if the message being deleted was a ghost already, we can just go
ahead and delete it.
Publicly we are only exposing the non-ghost documents (of "type"
"mail"). But internally we might want to inspect the ghost messages
as well.
This changeset adds two new private interfaces to queries to recover
information about alternate document types.
implement ghost-on-removal, the solution to T590-thread-breakage.sh
that just adds a ghost message after removing each message.
It leaks information about whether we've ever seen a given message id,
but it's a fairly simple implementation.
Note that _resolve_message_id_to_thread_id already introduces new
message_ids to the database, so i think just searching for a given
message ID may introduce the same metadata leakage.
This test (T590-thread-breakage.sh) has known-broken subtests.
If you have a two-message thread where message "B" is in-reply-to "A",
notmuch rightly sees this as a single thread.
But if you:
* remove "A" from the message store
* run "notmuch new"
* add "A" back into the message store
* re-run "notmuch new"
Then notmuch sees the messages as distinct threads.
This happens because if you insert "B" initially (before anything is
known about "A"), then a "ghost message" gets added to the database in
reference to "A" that is in the same thread, which "A" takes over when
it appears.
But if "A" is subsequently removed, no ghost message is retained, so
when "A" appears, it is treated as a new thread.
I see a few options to fix this:
ghost-on-removal
----------------
We could unilaterally add a ghost upon message removal. This has a
few disadvantages: the message index would leak information about what
messages the user has ever been exposed to, and we also create a
perpetually-growing dataset -- the ghosts can never be removed.
ghost-on-removal-when-shared-thread-exists
------------------------------------------
We could add a ghost upon message removal iff there are other
non-ghost messages with the same thread ID.
We'd also need to remove all ghost messages that share a thread when
the last non-ghost message in that thread is removed.
This still has a bit of information leakage, though: the message index
would reveal that i've seen a newer message in a thread, even if i had
deleted it from my message store
track-dependencies
------------------
rather than a simple "ghost-message" we could store all the (A,B)
message-reference pairs internally, showing which messages A reference
which other messages B.
Then removal of message X would require deleting all message-reference
pairs (X,B), and only deleting a ghost message if no (A,X) reference
pair exists.
This requires modifying the database by adding a new and fairly weird
table that would need to be indexed by both columns. I don't know
whether xapian has nice ways to do that.
scan-dependencies
-----------------
Without modifying the database, we could do something less efficient.
Upon removal of message X, we could scan the headers of all non-ghost
messages that share a thread with X. If any of those messages refers
to X, we would add a ghost message. If none of them do, then we would
just drop X entirely from the table.
---------------------
One risk of attempted fixes to this problem is that we could fail to
remove the search term indexes entirely. This test contains
additional subtests to guard against that.
This test also ensures that the right number of ghost messages exist
in each situation; this will help us ensure we don't accumulate ghosts
indefinitely or leak too much information about what messages we've
seen or not seen, while still making it easy to reassemble threads
when messages come in out-of-order.
The code to skip multiple slashes in _notmuch_database_split_path()
skips back one character too much. This is compensated by a +1 in the
length parameter to the strndup() call. Mostly this works fine, but if
the path is to a file under a top level directory with one character
long name, the directory part is mistaken to be part of the file name
(slash == path in code). The returned directory name will be the empty
string and the basename will be the full path, breaking the indexing
logic in notmuch new.
Fix the multiple slash skipping to keep the slash variable pointing at
the last slash, and adjust strndup() accordingly.
The bug was introduced in
commit e890b0cf40
Author: Carl Worth <cworth@cworth.org>
Date: Sat Dec 19 13:20:26 2009 -0800
database: Store the parent ID for each directory document.
just a little over two months after the initial commit in the Notmuch
code history, making this the longest living bug in Notmuch to date.
In several places in the test suite we intentionally corrupt the Xapian
database in order to test error handling. This corruption is specific to
the on-disk organization of the database, and that changed with the
glass backend. We use the previously computed default backend to make
the tests adapt to changing names.
This is mainly for the test suite. We already expect the tests to be
run in the same environment as configure was run, at least to get the
name of the python interpreter. So we are not really imposing a new
restriction.
This should potentially be updated to have an equivalent optimization
for the glass backend, but it in my unscientific tests, the glass backend
without the optimization is faster then the chert backend with.
