David Bremner [Thu, 16 Jul 2020 22:48:19 +0000 (19:48 -0300)]
test: add regression test for n_d_{begin,end}_atomic
Xapian currently succeeds to begin/end a transaction on a closed database,
or at least does not throw an exception. Make the test robust against
this changing.
David Bremner [Tue, 14 Jul 2020 11:25:28 +0000 (08:25 -0300)]
lib: move deallocation of memory from n_d_close to n_d_destroy
In order to mimic the "best effort" API of Xapian to provide
information from a closed database when possible, do not
destroy the Xapian database object too early.
Because the pointer to a Xapian database is no longer nulled on close,
introduce a flag to track whether the notmuch database is open or not.
David Bremner [Wed, 22 Jul 2020 11:19:28 +0000 (08:19 -0300)]
lib: fix exception messages for n_m_message_*
The original generic handler had an extra '%s' in the format
string. Update tests that failed to catch this because the template to
print status strings checked 'stat', which was not set.
David Bremner [Thu, 9 Jul 2020 00:17:07 +0000 (21:17 -0300)]
test: regression for retrieving closed db from message
This is actually one of the few potentially useful things you can do
with a message belonging to a closed database, since in principle you
could re-open the database.
Boolean return values have no out-of-band-values to signal errors. The
change here is that a (somewhat unlikely) fatal error after indexing
will now be caught.
David Bremner [Sat, 11 Jul 2020 18:30:06 +0000 (15:30 -0300)]
lib/add-message: drop use of deprecated notmuch_message_get_flag.
As a side effect, we revert the switch from notmuch_bool_t to bool
here. This is because those two types are not actually compatible when
passing by reference.
David Bremner [Sun, 5 Jul 2020 13:00:26 +0000 (10:00 -0300)]
lib: use COERCE_STATUS in n_m_{add,remove}_tag
Currently I don't know of a good way of testing this, but at least in
principle a Xapian exception in _notmuch_message_{add,remove}_term
would cause an abort in the library.
David Bremner [Sun, 5 Jul 2020 13:00:17 +0000 (10:00 -0300)]
lib: use LOG_XAPIAN_EXCEPTION in n_m_get_date
This should not change functionality, but does slightly reduce code
duplication. Perhaps more importantly it allows consistent changes to
all of the similar exception handling in message.cc.
David Bremner [Sat, 4 Jul 2020 12:29:41 +0000 (09:29 -0300)]
test: drop use of assert in closed db tests
Instead of printing the same static string for each test, can replace
the assert with something simpler (or at least easier to integrate
into the test suite).
David Bremner [Tue, 7 Jul 2020 10:56:47 +0000 (07:56 -0300)]
test: drop upgrade from v1 tests
These are less crucial since we stopped generating new database
versions and relied primarily on features. They also rely on a
pre-generated v1 database which happens to be chert format. This
backend is not supported by Xapian 1.5.
Also drop the tool gen-testdb.sh, which is currently broken, due to
changes in the testing infrastructure.
David Bremner [Tue, 7 Jul 2020 10:56:46 +0000 (07:56 -0300)]
lib: migrate from Xapian ValueRangeProcessor to RangeProcessor
This will be mandatory as of Xapian 1.5. The API is also more
consistent with the FieldProcessor API, which helps code re-use a bit.
Note that this switches to using the built-in Xapian support for
prefixes on ranges (i.e. deleted code at beginning of
ParseTimeRangeProcessor::operator(), added prefix to constructor).
Another side effect of the migration is that we are generating smaller
queries, using one OP_VALUE_RANGE instead of an AND of two OP_VALUE_*
queries.
Jonas Witschel [Sat, 11 Jul 2020 16:04:35 +0000 (18:04 +0200)]
doc: make gzipped man pages reproducible
gzip includes the name of the uncompressed file and its modification
timestamp into the compressed archive. The latter makes it hard to
reproduce the generated files bit for bit at a later time, so omit this
information from the archive using the "--no-name" option. This is a
reproducibility best practice, see
https://wiki.debian.org/ReproducibleBuilds/TimestampsInGzipHeaders
David Bremner [Tue, 16 Jun 2020 14:17:55 +0000 (11:17 -0300)]
build: produce signatures for release candidate tarballs.
Today Defalos on #notmuch asked for a signed tarball for
0.30~rc2. This is a minimal change to support this in the future. The
question of automagically uploading will need more thought; currently
I like the fact that tags from pre-releases are only pushed manually.
configure: can gpgme can verify signatures when decrypting with a session key?
If https://dev.gnupg.org/T3464 is unresolved in the version of gpgme
we are testing against, then we should know about it, because it
affects the behavior of notmuch.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
David Bremner [Wed, 24 Jun 2020 14:32:34 +0000 (11:32 -0300)]
test: mark two tests broken on machines with 32 bit time_t
I haven't traced the code path as exhaustively for the SMIME test, but
the expiry date in question is larger then representable in a signed
32 bit integer.
David Bremner [Wed, 24 Jun 2020 14:32:33 +0000 (11:32 -0300)]
configure: detect 64 bit time_t
Certain tests involving timestamps > 32 bits cannot pass with the
current libnotmuch API. We will avoid this issue for now by disabling
those tests on "old" architectures with 32 bit time_t.
Tomi Ollila [Wed, 24 Jun 2020 20:11:20 +0000 (23:11 +0300)]
Makefile.global: drop -std=gnu99. C11 (or later) compiler required
Since October 2018 building notmuch has actually required compiler
that knows C11.
Also this -std=gnu99 was not used in code compiled by configure,
so in theory this could have caused problems...
...but no related reports have been sent, perhaps ever.
Both gcc and clang has been shipping compilers supporting C11
(or later) by default for more than four years now.
Therefore, just dropping -std=gnu99 (and not checking C11
compatibility for now, for simplicity) is easiest to do,
and removes inconsistency between configure and build time
compilations.
Since it is possible to use an atomic context to abort a number of
changes support this usage. Because the only way to actually abort
the transaction is to close the database this must also do so.
Amended by db: Note the limitation requiring close is a limitation of
the underlying notmuch API, which should be fixed in a future notmuch
release.
This reverses the logic of StandaloneMessage to instead create a
OwnedMessage. Only the Thread class allows retrieving messages more
then once so it can explicitly create such messages.
The added test fails with SIGABRT without the fix for the message
re-use in threads being present.
Anton Khirnov [Mon, 15 Jun 2020 20:58:49 +0000 (22:58 +0200)]
python/notmuch2: do not destroy messages owned by a query
Any messages retrieved from a query - either directly via
search_messages() or indirectly via thread objects - are owned by that
query. Retrieving the same message (i.e. corresponding to the same
message ID / database object) several times will always yield the same
C object.
The caller is allowed to destroy message objects owned by a query before
the query itself - which can save memory for long-lived queries.
However, that message must then never be retrieved again from that
query.
The python-notmuch2 bindings will currently destroy every message object
in Message._destroy(), which will lead to an invalid free if the same
message is then retrieved again. E.g. the following python program leads
to libtalloc abort()ing:
import notmuch2
db = notmuch2.Database(mode = notmuch2.Database.MODE.READ_ONLY)
t = next(db.threads('*'))
msgs = list(zip(t.toplevel(), t.toplevel()))
msgs = list(zip(t.toplevel(), t.toplevel()))
Fix this issue by creating a subclass of Message, which is used for
"standalone" message which have to be freed by the caller. Message class
is then used only for messages descended from a query, which do not need
to be freed by the caller.
Even though we use collections.abc.Set which implements all these
methods under their operator names, the actual named variations of
these methods are shockingly missing. So let's add them manually.
Tomi Ollila [Tue, 9 Jun 2020 12:32:27 +0000 (15:32 +0300)]
configure: use cffi.FFI().verify() to test buildability of CFFI bindings
Checking existence of pyconfig.h to determine whether CFFI-based
notmuch bindings are buildable is not enough; for example Fedora 32
ships pyconfig.h in python3-libs package, but python3-devel is required
to be installed for the bindings to build.
Executing cffi.FFI().verify() is pretty close to what is done in
bindings/python-cffi/notmuch2/_build.py to get the c code part of the
bindings built.
Tomi Ollila [Tue, 2 Jun 2020 20:21:59 +0000 (23:21 +0300)]
doc: field processor support now always included, adjust manual pages
The features that require field processor support, are now just
documented w/o mentioning **Xapian Field Processors**' is needed
for those.
Replaced "compact" and "field_processor" with "retry_lock" in
build_with config option, as it is currently the only one that
is optionally excluded. The former 2 are now documented as
features always included.
Dropped one 'we' "passive" in notmuch-search-terms.rst. It was the
only one, and inconsistent with rest of the documentation in that
file.
Dropped message about conditional open-ended ranges support, as
those are now always supported.
Tomi Ollila [Fri, 5 Jun 2020 21:57:55 +0000 (00:57 +0300)]
configure: require python 3.5 for CFFI-based notmuch bindings
Also tell users what the consequences of a "No" answer is when
python version is less than 3.5, cffi or setuptools is missing,
or no pytest >= 3.0 is available.
David Bremner [Wed, 3 Jun 2020 16:05:12 +0000 (13:05 -0300)]
devel: script to calculate a list of authors.
As an initial heuristic, report anyone with at least 15 lines of code
in the current source tree. Test corpora are excluded, although
probabably this doesn't change much about the list of authors
produced.