To aid in diagnosing test suite tooling that interacts poorly with
coreutils' timeout, it's handy to be able to bypass it entirely.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This should not change the indexing process yet as nothing calls
_notmuch_message_gen_terms with a user prefix name. On the other hand,
it should not break anything either.
_notmuch_database_prefix does a linear walk of the list of (built-in)
prefixes, followed by a logarithmic time search of the list of user
prefixes. The latter is probably not really noticable.
This will be used to avoid needing a database access to resolve a db
prefix from the corresponding UI prefix (e.g. when indexing). Arguably
the setup of the separate header map does not belong here, since it is
about indexing rather than querying, but we currently don't have any
other indexing setup to do.
These restrictions are meant to prevent incompatibilities with the
Xapian query parser (which will split at non-word characters) and
clashes with future notmuch builtin fields.
We don't do anything with this configuration information information
yet, but nonetheless add a couple of regression tests to make sure we
don't break standard functionality when we do use the configuration
information.
This will make it easier to add other prefixes that are stored in the
database, compared to special casing each one as "query." was. This
commit also adds the ability to validate keys with a given
prefix. This ability will be used in a future commit.
This originally use Xapian::Unicode::is_wordchar, but that forces
clients to link directly to libxapian, which seems like it might be
busywork if nothing else.
`notmuch-search-interactive-region' was moved to notmuch-lib.el in
f3cba19f88 and renamed to
`notmuch-interactive-region' without making the old function
obsolete, thereby breaking user-commands which made use of it.
This commit marks the function as obsolete and makes it an alias for
the new function.
Previously this functioned scanned every term attached to a given
Xapian document. It turns out we know how to read only the terms we
need to preserve (and we might have already done so). This commit
replaces many calls to Xapian::Document::remove_term with one call to
::clear_terms, and a (typically much smaller) number of calls to
::add_term. Roughly speaking this is based on the assumption that most
messages have more text than they have tags.
According to the performance test suite, this yields a roughly 40%
speedup on "notmuch reindex '*'"
Done via $COLORS_WITHOUT_TTY environment variable as passing options
to commands through parallel(1) does not look trivial.
Reorganized color checking in test-lib.sh a bit for this (perhaps
were not fully necessary but rest still an improvement):
- color checking commands in subshell are not run before arg parsing
(args may disable colors with --no-color)
- [ -t 1 ] is checked before forking subshell
Added initialization and checking of smtp_dummy_port
like it was done with smtp_dummy_pid.
Made those function-local variables.
One 8 spaces to tab consistency conversion.
And last, but definitely not least; while doing above
noticed that there were quite a few double-quoted strings
where $@ was in the middle of it -- replaced those with $*
for robustness ("...$@..." expands params to separate words,
"...$*..." params expands to single word).
Without this stdin may be anything that parent process provided for it.
Test processes might have tried to read something from it, which would
have caused undeterministic behavior.
E.g. gdb(1) tries to do tty related ioctls on fd 0 (and fd 1 and fd 2,
but those are redirected to 'test.output' before test runs).
When using a promiscuous linker, _check_session_keys was working fine.
But some OSes (including some versions of Ubuntu) have set their
linker to always link in "--as-needed" mode, which means that the
order of the objects linked is relevant. If a library is loaded
before it is needed, that library will no longer be linked in the
final outcome. _check_session_keys.c was failing on those systems.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
We never want ./configure to try to do something with an unassigned
variable. So, make the directory $TEMP_GPG at the start of the
testing of session-key handling, and clean it up afterwards as long as
the directory exists.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
There are a few changes bundled here:
* say "No." explicitly if there's a failure.
* try to avoid implying that gpgme-config is necessary to build
notmuch itself (it's not, though it may be useful if you need to
rebuild gmime).
* leave _check_session_keys and _check_session_keys.c around if
./configure fails, so that the user can play with it more easily
for debugging.
* let error messages show when _check_session_keys.c is built.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Amended by DB: use command -v instead of which.
To the best of my understanding, this original behaviour was what
Carl's homebrew parser produced. With commit 86f89385 Austin switched
to using GMime (2.6). This produced arguably worse results, but since
the input was bad, we could live with it. Now with GMime 3.0 we are
getting the original results again, and there is no reason to consider
this test broken.
GMime 3.0 and higher can extract session keys, but it will *not*
extract session keys if it was built with --disable-crypto, or if it
was built against GPGME version < 1.8.0.
Notmuch currently expects to be able to extract session keys, and
tests will fail if it is not possible, so we ensure that this is the
case during ./configure time.
Part of this feels awkward because notmuch doesn't directly depend on
gpg at all. Rather, it depends on GMime, and the current
implementation of GMime depends on GPGME for its crypto, and GPGME in
turn depends on gpg.
So the use of gpg in ./configure isn't actually introducing a new
dependency, though if a future version of GMime were ever to move away
from GnuPG, we might need to reconsider.
Note that this changeset depends on
id:20190506174327.13457-1-dkg@fifthhorseman.net , which supplies the
rfc822 message test/corpora/crypto/basic-encrypted.eml used in it.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
When a parallel build fails (or when it times out, if timeout is
present), the test suite should not blithely succeed. Catch these
failures and at least report them.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
The current 2 minute timeout is reasonable, but to exercise the test
suite or induce timeout failures, we might want to make it shorter.
This makes it configurable so you can run (for example):
make check NOTMUCH_TEST_TIMEOUT=10s
We stick with the default of 2m.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Without this,
$ make time-test OPTIONS=--small
leads to fatal errors from too many open files.
Thanks to st-gourichon-fid for bringing this problem to my attention in IRC.
FINGERPRINT is already exported by add_gnupg_home, so this is
unnecessary. This change also happens to get rid of the superfluous
check-trustdb spew from the test suite that looked like this:
gpg: checking the trustdb
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
We did not have a test showing what message decryption looks like
within notmuch-emacs. This change gives us a baseline for future work
on the notmuch-emacs interface.
This differs from previous revisions of this patch in that it should
be insensitive to the order in which the local filesystem readdir()s
the underlying maildir.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
If either the moreutils or GNU parallel utility are available, run all
tests in parallel. On my eight core machine this makes for a ~x7
speed-up in the full test suite (1m24s -> 12s).
The design of the test suite makes this parallelization trivial.
The add_email_corpus test utility includes logic that tries to re-use
an index of the corpus if available. This was seemingly done as an
optimization, so that every test that uses the corpus didn't have to
create it's own index of the corpus. However, this has the perverse
side effect of entangling tests together, and breaks parallelization.
Forcing each test to do it's own index does increase the overall time
of the test slightly (~6%), but this will be more than made up for in
the next patch that introduces paraellization.
The typical use case for gpg is that if you control a secret key, you
mark it with "ultimate" ownertrust.
The opaque --import-ownertrust mechanism is GnuPG's standard mechanism
to set up ultimate ownertrust (the ":6:" means "ultimate", for
whatever reason).
We adjust the test suite to match this change, inverting the sense of
one test: since the default is now that the user ID of the suite's own
key is valid, we change the test to make sure that the user ID is not
emitted when it is *not* valid.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
The user ID on the self-test is a little bit clunky-looking. It also
may end up showing up elsewhere in the test suite. Centralizing the
user ID in one place should make it easier to handle if it ever
changes, and should make tests easier to read.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
This is a subtle difference, but the output of notmuch shouldn't ever
change based on ownertrust itself -- notmuch is intended to show valid
User IDs, and to avoid showing invalid User IDs.
It so happens that setting ownertrust of a key to ultimate sets all
associated user IDs to "full" validity, so the test is correct, but
just misnamed.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
The comment line here lingers from when we were using some fancy
version checking about session keys. Correct it to match the current
state.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
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 comes from the
language environment
In discussion with emacs upstream over on
https://debbugs.gnu.org/35370, it appears that we can just drop this
entirely and things should still work with emacs 25.
https://launchpad.net/~notmuch/+archive/ubuntu/notmuch/+packages
contains backports of gmime and gpgme and related cryptographic tools
to ubuntu xenial.
I tried to do a simple backport of gmime alone, and it failed due to
the older gpgme in xenial, so this setup resolves those problems.
This should allow us to continue to use the Travis continuous
integration build.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Previously if the input was exactly a multiple of the internal buffer
size, notmuch would attempt to fwrite nothing to stdout, but still
expected fwrite to return 1, causing a failure that looked like this:
$ notmuch show --format=raw id:87o96f1cya.fsf@codeaurora.org
...entire message shown as expected..
Error: Write failed
$ echo $?
1
To fix the problem don't call fwrite at all when there's nothing to
write.
Amended by db: add some tests of message sizes likely to cause this
problem.
This drops "file" from mime_node_context and just uses a local
variable. It also uses the new gzip aware utility routines recently
added to util/gmime-extra.c. The use of gzopen / gzfile in addition is
a bit icky, but the choice is between that, and providing yet another
readline implimentation that understands GMime streams.
Rather than storing the lower level stdio FILE object, we store a
GMime stream. This allows both transparent decompression, and passing
the stream into GMime for parsing. As a side effect, we can let GMime
close the underlying OS stream (indeed, that stream isn't visible here
anymore).
This change is enough to get notmuch-{new,search} working, but there is still
some work required for notmuch-show, to be done in a following commit.
This is a functional change, not a straight translation, because we
are no longer directly invoking g_mime_parser_options_get_default(),
but the GMime source has indicated that the options parameter for
g_mime_parser_construct_message() is "nullable" since upstream commit
d0ebdd2ea3e6fa635a2a551c846e9bc8b6040353 (which itself precedes GMime
3.0).
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Several GMime 2.6 functions sprouted a change in the argument order in
GMime 3.0. We had a compatibility layer here to be able to handle
compiling against both GMime 2.6 and 3.0. Now that we're using 3.0
only, rip out the compatibility layer for those functions with changed
argument lists, and explicitly use the 3.0 argument lists.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
