thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=nmweb 2023-09-02T10:45:30Z 2023-09-02T10:45:30Z Kevin Boulain kevin@boula.in 2023-08-30T12:52:55Z urn:sha1:c1a23a64ae06decdffea6caeaba5270854fa0ddd On ppc64el, races are detected by TSan: WARNING: ThreadSanitizer: data race (pid=4520) Read of size 8 at 0x7ffff20016c0 by thread T1: #0 strlen ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:386 (libtsan.so.2+0x77c0c) #1 strlen ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:378 (libtsan.so.2+0x77c0c) #2 g_strdup ../../../glib/gstrfuncs.c:362 (libglib-2.0.so.0+0xa4ac4) Previous write of size 8 at 0x7ffff20016c0 by thread T2: #0 malloc ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:647 (libtsan.so.2+0x471f0) #1 g_malloc ../../../glib/gmem.c:130 (libglib-2.0.so.0+0x7bb68) Location is heap block of size 20 at 0x7ffff20016c0 allocated by thread T2: #0 malloc ../../../../src/libsanitizer/tsan/tsan_interceptors_posix.cpp:647 (libtsan.so.2+0x471f0) #1 g_malloc ../../../glib/gmem.c:130 (libglib-2.0.so.0+0x7bb68) This appears to be a false positive in GLib, as explained at https://gitlab.gnome.org/GNOME/glib/-/issues/1672#note_1831968 In short, a call to fstat fails under TSan and GLib's g_sterror will intern the error message, which will be reused by other threads. Since upstream appears to be aware that GLib doesn't play nicely with TSan, suppress everything coming from the library instead of maintaining a fine grained list. Reported at https://buildd.debian.org/status/fetch.php?pkg=notmuch&arch=ppc64el&ver=0.38%7Erc0-1&stamp=1692959868&raw=0 2023-08-26T10:45:36Z David Bremner david@tethera.net 2023-08-26T10:45:36Z urn:sha1:115d4d69ebbab213baae672ac4e81947877f364b Native compilation is kindof useless in the test suite because we throw away the cache after every subtest. The test suite could in principle share an eln cache within a given test file; for now try to minimize the amount of native-compilation. There is an intermittent bug where emacs loses track of its default-directory; I suspect (but have no proof) that bug is related to native compilation and/or race conditions. This patch seems to prevent that bug (or at least reduce its frequency). 2023-08-21T22:30:54Z David Bremner david@tethera.net 2023-08-20T15:23:19Z urn:sha1:368e0f61d5498ceae180e8349e848a4904008b0b The presense of the blank lines between sections depends on the version of glib. Strip them before comparison. 2023-08-20T17:32:02Z David Bremner david@tethera.net 2023-08-20T17:32:02Z urn:sha1:1719b9e568fb944ffb91126b164a18a30a415d0a As of Emacs 29.1, In-Reply-To is in the default value for message-hidden-headers. We actually want to see that in the test suite, so remove it again. To future proof the tests, fix a default value for message-hidden-headers specifically for the test suite. 2023-07-21T10:41:50Z David Bremner david@tethera.net 2023-04-09T14:26:26Z urn:sha1:ec26eeaeec87781dee7dbf720103a5bc9b6bba5d We put some effort into testing the built copy rather than some installed copy. On the other hand for people like packagers, testing the installed copy is also of interest. When NOTMUCH_TEST_INSTALLED is set to a nonempty value, tests do not require a built notmuch tree or running configure. Some of the tests marked as broken when running against installed notmuch are probably fixable. 2023-07-21T10:07:43Z David Bremner david@tethera.net 2023-04-09T14:26:25Z urn:sha1:73f3081160fb80345f3953cbdeba340975375325 python3 will work for many people, and reduce the friction to running the tests without running configure first. 2023-07-21T10:07:43Z David Bremner david@tethera.net 2023-04-09T14:26:24Z urn:sha1:f6fcdf12da455d82a9ed0a0a33eddac60253a6e8 Messages can have empty bodies, but empty files are not messages. 2023-07-21T09:58:16Z David Bremner david@tethera.net 2023-04-09T14:26:23Z urn:sha1:dfa43a19218ed46f677034ab7bf8b8907a327935 When running the test suite without building first, it is desirable to have the tests consider these variables being undefined as equivalent to the feature not being present, and in particular for the tests not to generate errors. 2023-07-09T14:59:43Z David Bremner david@tethera.net 2023-05-27T17:20:51Z urn:sha1:808fd6f258e6f74f4cdb5b6f61fe102bdba59e6e According to my reading of RFC5322, there is an obsolete syntax for Message-Id which permits folding whitespace (i.e. to be removed / ignored by parsers). In [1] Paul Wise observed that notmuch removed whitespace on indexing, but does not do any corresponding normalization of queries. Mark the latter as a bug by adding a failing test. [1]: id:20230409044143.4041560-1-pabs3@bonedaddy.net 2023-04-02T22:24:43Z David Bremner david@tethera.net 2023-01-06T00:02:06Z urn:sha1:a554690d6af0ac8cb55166a20efd0f449abde389 Instead of skipping indexing all attachments, we check of a (user configured) mime type that is indexable as text.