thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=0.15 2012-12-17T13:11:57Z 2012-12-17T13:11:57Z Peter Wang novalazy@gmail.com 2012-12-15T03:06:45Z urn:sha1:732f50a20aac461101986fafec95771c8a686ebe Update tests to expect content-length and content-transfer-encoding fields in show --format=json output, for leaf parts with omitted body content. 2012-08-03T23:14:47Z Austin Clements amdragon@MIT.EDU 2012-08-03T01:14:47Z urn:sha1:a34bb1f9fad7c547eec5c254ce8274f190491186 Previously, we used a variety of ad-hoc canonicalizations for JSON output in the test suite, but were ultimately very sensitive to JSON irrelevancies such as whitespace. This introduces a new test comparison function, test_expect_equal_json, that first pretty-prints *both* the actual and expected JSON and the compares the result. The current implementation of this simply uses Python's json.tool to perform pretty-printing (with a fallback to the identity function if parsing fails). However, since the interface it introduces is semantically high-level, we could swap in other mechanisms in the future, such as another pretty-printer or something that does not re-order object keys (if we decide that we care about that). In general, this patch does not remove the existing ad-hoc canonicalization because it does no harm. We do have to remove the newline-after-comma rule from notmuch_json_show_sanitize and filter_show_json because it results in invalid JSON that cannot be pretty-printed. Most of this patch simply replaces test_expect_equal and test_expect_equal_file with test_expect_equal_json. It changes the expected JSON in a few places where sanitizers had placed newlines after commas inside strings. 2012-03-14T01:09:56Z David Bremner bremner@debian.org 2012-03-14T01:09:56Z urn:sha1:0c20878ccefec1e6fc472851395a7ee5a0daec4e 2012-03-12T01:13:48Z Thomas Jost schnouki@schnouki.net 2012-02-21T19:35:35Z urn:sha1:f34613ea833196922a38cf04cd2ee766a562a410 gmime-2.6 had a bug [1] which made it impossible to tell why a signature verification failed when the signer key was unavailable (empty "sigstatus" field in the JSON output). Since 00b5623d the corresponding test is marked as broken when using gmime-2.6 (2.4 is fine). This bug has been fixed in gmime 2.6.5, which is now the minimal gmime-2.6 version required for building notmuch (gmime-2.4 is still available). As a consequence the version check in test/crypto can be removed. [Added by db] Although less unambigously a bug, Gmime 2.6 prior to 2.6.7 also was more strict about parsing, and rejected messages with initial "From " headers. This restriction is relaxed in [2]. For reasons explained in [3], we want to keep this more relaxed parsing for now. [1] https://bugzilla.gnome.org/show_bug.cgi?id=668085 [2] http://git.gnome.org/browse/gmime/commit/?id=d311f576baf750476e06e9a1367a2dc1793ea7eb [3] id:"1331385931-1610-1-git-send-email-david@tethera.net" 2012-03-02T12:35:02Z Mark Walters markwalters1009@gmail.com 2012-03-01T22:30:41Z urn:sha1:c8cf9e92d80f960bb8231b518c6967a7aab7f260 notmuch show outputs the exclude flag so many tests using notmuch show failed. This commit adds "excluded:0" or "excluded: false" to the expected outputs. After this commit there should be no failing tests. 2012-03-01T12:28:13Z Austin Clements amdragon@MIT.EDU 2012-02-20T00:26:26Z urn:sha1:86f89385c3bc34cd91002cc057f6a615b6ab76a9 This has three ramifications: - Blank To and Cc headers are no longer output for messages. - Dates are now canonicalized for messages, which means they always have a day of the week and GMT is printed +0000 (never -0000) - Invalid From message headers are handled slightly differently, since they get parsed by GMime now instead of notmuch. 2012-02-12T16:58:20Z Austin Clements amdragon@MIT.EDU 2012-02-04T21:24:26Z urn:sha1:c0cd09041208abb6d641279c9ae453e6f2fdf4db This makes the text formatter take advantage of the new code structure. The previously duplicated header logic is now unified, several things that we used to compute repeatedly across different callbacks are now computed once, and the code is simpler overall and 32% shorter. Unifying the header logic causes this to format some dates slightly differently, so the two affected test cases are updated. 2012-01-21T12:52:34Z Thomas Jost schnouki@schnouki.net 2012-01-20T09:39:24Z urn:sha1:00b5623d1a21d886b564d031e30749e5d02e4ae6 There are lots of API changes in gmime 2.6 crypto handling. By adding preprocessor directives, it is however possible to add gmime 2.6 compatibility while preserving compatibility with gmime 2.4 too. This is mostly based on id:"8762i8hrb9.fsf@bookbinder.fernseed.info". This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test is currently broken (signature verification with signer key unavailable), most likely because of a bug in gmime which will hopefully be fixed in a future version. 2011-10-06T13:13:20Z Jameson Graef Rollins jrollins@finestructure.net 2011-06-08T19:30:08Z urn:sha1:5d21d5ea0c6d2113aab9eb7f29463b09e7eacca5 In reply, the quoted text does not need to mention that the original message had "application/pgp-signed" or "application/pgp-encrypted" parts. 2011-06-29T03:06:20Z Dmitry Kurochkin dmitry.kurochkin@gmail.com 2011-05-28T22:03:48Z urn:sha1:f74c4bc2f3ceedc6b6f3501c552df6c77fce9c00 Adding the filename propery alongside ID and Content-type. This makes the test suite pass again after the recent change.