Re: [PATCH] add NEWS for 0.30

2020-06-01 Thread David Bremner
Daniel Kahn Gillmor writes: > Signed-off-by: Daniel Kahn Gillmor > --- Thanks! merged to master and release, d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch

Re: Feature freeze for notmuch 0.30: June 1

2020-06-01 Thread David Bremner
David Bremner writes: > I plan to tag the first release candidate for notmuch 0.30 on June > 1. It's long past time we had a release, and the new python bindings in > particular need a wider audience. Per usual, I'll accept (some) bug > fixes and NEWS updates after that date. >

Re: [PATCH] doc: fix for out-of-tree builds of notmuch-emacs docs

2020-06-01 Thread David Bremner
Tomi Ollila writes: > On Sun, May 31 2020, David Bremner wrote: > >> The sphinx-doc include directive does not have the ability to include >> files from the build tree, so we replace the include with reading the >> files in conf.py. The non-trivial downside o

Re: [PATCH] configure: check existence of python3 setuptools and dev package

2020-06-01 Thread David Bremner
Tomi Ollila writes: > The notmuch2 CFFI-based Python interface is not buildable unless > python3 dev package and python3 setuptools are installed. > > Check that these exist in configure (and disable notmuch2 bindings > build if not) so that build of these bindings don't fail when make(1) > is

Re: [PATCH] emacs: Respect `load-prefer-newer` when loading `notmuch-init-file'

2020-06-01 Thread David Bremner
David Edmondson writes: > On Sunday, 2020-05-31 at 23:17:04 -07, Sean Whitton wrote: > >> Before this change, `load-prefer-newer' was ignored. >> >> Set NOERROR and MUST-SUFFIX arguments of `load' to t, and NOSUFFIX >> argument to nil, to preserve the behaviour of the deleted `let' form. > >

Re: [PATCH] tests/ruby: Ensure that test works for out-of-tree builds

2020-05-31 Thread David Bremner
Daniel Kahn Gillmor writes: > --- > test/test-lib.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/test/test-lib.sh b/test/test-lib.sh > index 792b1cb9..78a90862 100644 > --- a/test/test-lib.sh > +++ b/test/test-lib.sh > @@ -1081,7 +1081,7 @@ test_python() { > } >

[PATCH] doc: fix for out-of-tree builds of notmuch-emacs docs

2020-05-31 Thread David Bremner
The sphinx-doc include directive does not have the ability to include files from the build tree, so we replace the include with reading the files in conf.py. The non-trivial downside of this is that the emacs docstrings are now defined for every rst source file. They are namespaced with

Re: doc build warnings when building out-of-tree

2020-05-31 Thread David Bremner
David Bremner writes: > Daniel Kahn Gillmor writes: > > I can't duplicate these errors with sphinx-doc 2.4.3-3 on Debian. > > Are the rsti files actually being built before calling sphinx-build? > > d OK, I understand now. The case I thought was working was actually usin

Re: [PATCH v2 3/3] emacs: Process format=flowed text

2020-05-31 Thread David Bremner
Jed Brown writes: > Was this proposal dropped or did it just get lost? > The latter, I think. Thanks for pinging. It looks like that last discussion was my comment about breaking the API. Any feedback on that, either of you? d ___ notmuch mailing

Re: doc build warnings when building out-of-tree

2020-05-30 Thread David Bremner
Daniel Kahn Gillmor writes: > When building out-of-tree, the documentation (both manpages and info > files) are incomplete, but they do not explicitly fail. build logs > follow from doing "mkdir build && ../configure && make". > > If there's a way to make these warnings into hard failures, i

Re: python-cffi and ruby test suites fail in out-of-tree builds

2020-05-30 Thread David Bremner
Floris Bruynooghe writes: > > I checked out the python one, and maybe that's not too hard. The > following patch made this work for both in tree and out of tree (on top > of your other patch): > > modified test/T391-python-cffi.sh > @@ -8,7 +8,7 @@ fi > > > test_begin_subtest "python cffi

Re: [PATCH] test/test-lib.sh: fix two out of tree test issues

2020-05-30 Thread David Bremner
Tomi Ollila writes: > json_check_nodes.py exists in source tree, not in out of tree > build tree. Added -B to the execution so source tree is not > "polluted" by a .pyc file when json_check_nodes.py is executed. > pushed to master ___ notmuch mailing

Re: wish: notmuch-emacs: notmuch-poll-and-refresh-this-buffer should use progress-reporter

2020-05-28 Thread David Bremner
Alexander Adolf writes: > Dear notmuch developers, > > when notmuch-poll-and-refresh-this-buffer is invoked (e.g. by hitting > "G"), the triggered operations may take some time (e.g. due to accessing > multiple IMAP accounts with mbsync). During this time, the Emacs UI is > essentially frozen. >

Re: [PATCH v3 3/3] emacs: Use `dolist' instead of `mapcar' for side-effects

2020-05-26 Thread David Bremner
Jonas Bernoulli writes: > As recommended by the byte-compiler. pushed to master. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch

Feature freeze for notmuch 0.30: June 1

2020-05-24 Thread David Bremner
I plan to tag the first release candidate for notmuch 0.30 on June 1. It's long past time we had a release, and the new python bindings in particular need a wider audience. Per usual, I'll accept (some) bug fixes and NEWS updates after that date. d signature.asc Description: PGP signature

Re: [PATCH v3 2/3] emacs: Add simple make target to compile emacs lisp tests

2020-05-24 Thread David Bremner
Jonas Bernoulli writes: > > +compile-elisp-tests: > + $(EMACS) --batch -L emacs -L test -l notmuch.el -l test-lib.el -f \ > + batch-byte-compile test/*.el > + Can you explain a bit (perhaps in an updated commit message) why we need this target? thanks! David

Re: Python 3.x bindings support which versions, exactly?

2020-05-24 Thread David Bremner
Ralph Seichter writes: > * David Bremner: > >> The new bindings (modulename= notmuch2) should work with any python >> recent 3.x. They still have a few rough edges afaiu, but definitely >> new projects should target the new bindings. > > Alas, there are no releas

Re: Python 3.x bindings support which versions, exactly?

2020-05-24 Thread David Bremner
Ralph Seichter writes: > Hello, > > having examined the source code, I assume that Notmuch's Python bindings > should support Python 3.x for any given 'x'. However, reading the Travis > logs at https://travis-ci.org/notmuch/notmuch and .travis.yml, the CI > tests apparently run on Ubuntu 18.04

Re: [PATCH] configure: report GMime minimum version in ./configure output

2020-05-23 Thread David Bremner
Daniel Kahn Gillmor writes: > We already report the minimum version for Glib, zlib, and Xapian > development libraries. For consistency, report it for GMime as well. > pushed, d ___ notmuch mailing list notmuch@notmuchmail.org

Re: [PATCH 2/2 v3] smime: tests of X.509 certificate validity are known-broken on GMime < 3.2.7

2020-05-23 Thread David Bremner
Daniel Kahn Gillmor writes: > > We adapt to this by marking tests of reported User IDs for > S/MIME-signed messages as known-broken if GMime is older than 3.2.7 > and has not been patched. pushed d ___ notmuch mailing list notmuch@notmuchmail.org

Re: [PATCH v2 1/9] lib: index PKCS7 SignedData parts

2020-05-23 Thread David Bremner
Daniel Kahn Gillmor writes: > When we are indexing, we should treat SignedData parts the same way > that we treat a multipart object, indexing the wrapped part as a > distinct MIME object. > series pushed d ___ notmuch mailing list

Re: [PATCH 2/2 v2] smime: tests of X.509 certificate validity are known-broken on GMime < 3.2.7

2020-05-21 Thread David Bremner
Daniel Kahn Gillmor writes: > When checking cryptographic signatures, Notmuch relies on GMime to > tell it whether the certificate that signs a message has a valid User > ID or not. > > If the User ID is not valid, then notmuch does not report the signer's > User ID to the user. This means that

Re: [PATCH 1/2] python/notmuch2: do not destroy messages owned by a query

2020-05-21 Thread David Bremner
Anton Khirnov writes: > ping I'm hoping Floris will find a chance to review your patches. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch

Re: test suite: FIXED messages are misordered with tests

2020-05-12 Thread David Bremner
Daniel Kahn Gillmor writes: > > Clearly, that FIXED should come *after* the "T356-protected-headers:" > separator. > Can you reproduce this without running the tests in parallel? d ___ notmuch mailing list notmuch@notmuchmail.org

Re: feature request: parameters for reply templates

2020-05-12 Thread David Bremner
Emmanuel Beffara writes: > > I use `notmuch reply` with the default format indirectly, because I use > bower an it delegates the task of preparing replies to this command. I > feel it would make sense to define new settings to handle all this, but > maybe there are good reasons not to? > My gut

Re: [PATCH 1/2 v2] test-lib: mark function variables as local

2020-05-10 Thread David Bremner
Daniel Kahn Gillmor writes: > > yes, that's right. For certain GMime versions, there's an intermediate > breakage. I think you're saying you want me to rerun the series, with > these things split out so that even on systems with older GMime, tests > pass at every commit. I'll try to get that

Re: [PATCH 1/2 v2] test-lib: mark function variables as local

2020-05-09 Thread David Bremner
Daniel Kahn Gillmor writes: > Several functions in test/test-lib.sh used variable names that are > also used outside of those functions (e.g. $output and $expected are > used in many of the test scripts), but they are not expected to > communicate via those variables. > > We mark those variables

Re: [PATCH] notmuch(1): clarify documentation about --option/value separators

2020-05-08 Thread David Bremner
Carl Worth writes: > On Thu, May 07 2020, Daniel Kahn Gillmor wrote: >> +separator. Except for boolean options (wihch would be ambiguous), a > > Misspelling of "which". And while I'm here, strictly speaking Boolean is > generally capitalized in English, (being one of those adjectives that is >

Re: Handle PKCS#7 S/MIME messages

2020-05-05 Thread David Bremner
Tomi Ollila writes: > Reproducer in case gmime version is less than 3.2.7 -- with newer > gmimes that has to work so if that ever broke in newer gmimes we'd > notice (reproducer could hide that). > >> >> Any other suggestions? >> I guess it depends how many distros you think will patch this.

Re: [PATCH 1/2] test: known broken test for reindex tag preservation

2020-05-04 Thread David Bremner
Tomi Ollila writes: > On Mon, May 04 2020, David Bremner wrote: > >> In id:1588595993-ner-8.651@TPL520 Franz Fellner reported that tags >> starting with 'attachment' are removed by 'notmuch reindex'. This is >> probably related to the use of STRNCMP_LITERAL in > &

[PATCH 1/2] test: known broken test for reindex tag preservation

2020-05-04 Thread David Bremner
In id:1588595993-ner-8.651@TPL520 Franz Fellner reported that tags starting with 'attachment' are removed by 'notmuch reindex'. This is probably related to the use of STRNCMP_LITERAL in _notmuch_message_remove_indexed_terms. --- test/T700-reindex.sh | 9 + 1 file changed, 9 insertions(+)

[PATCH 2/2] lib: replace STRNCMP_LITERAL in __message_remove_indexed_terms

2020-05-04 Thread David Bremner
strncmp looks for a prefix that matches, which is very much not what we want here. This fixes the bug reported by Franz Fellner in id:1588595993-ner-8.651@TPL520 --- lib/message.cc | 6 +++--- test/T700-reindex.sh | 1 - 2 files changed, 3 insertions(+), 4 deletions(-) diff --git

Re: notmuch reindex wipes existing tags

2020-05-04 Thread David Bremner
Franz Fellner writes: > > And it fails. The tag "attachments-extracted" got removed. > Got curious, it seems as soon as the additional tag starts with "attachment" > "notmuch reindex" removes it. > With "extracted-attachments" everything is fine. > Thought it might clash with preserved tags. >

Re: notmuch reindex wipes existing tags

2020-05-04 Thread David Bremner
Franz Fellner writes: > Ran notmuch reindex. > And now all custom tags were wiped, especially attachments-extracted. > I now can't see if the pdf of a certain message was already saved. > This is 3 years of 5 newspapers a weak. I must delete the files > and re-extract them. > > I did not expect

Re: [PATCH] emacs: split-window-sensibly in tree mode with open message

2020-05-03 Thread David Bremner
Radu Butoi writes: > Also, should I update the NEWS file? I see its latest changes are in > November and there's been user-visible changes since. We seem to have got into the habit of updating the NEWS file right before release. This seems to work OK, and avoids some conflicts between patch

Re: Add support for `thread` field in `notmuch show`

2020-05-01 Thread David Bremner
David Bremner writes: > Offhand I have no strong objection to someone (who is not me) adding > this. I think it's important to be aware that thread id's are ephemeral, > and subject to change e.g. if the database is re-built from > scratch. I guess a more common/interesting case

Re: Add support for `thread` field in `notmuch show`

2020-05-01 Thread David Bremner
Ciprian Dorin Craciun writes: > I know that one can use `thread:{id:MESSAGE_ID}` to achieve the same > result, however: > * it is somewhat cumbersome for the integrator; Out of curiousity, what is harder about it? In both cases you have to extra one value from the JSON. > * having the thread

Re: Any updates on the `List-Id` indexing feature?

2020-05-01 Thread David Bremner
Ciprian Dorin Craciun writes: > On Wed, Apr 29, 2020 at 8:08 PM David Bremner wrote: >> > I've also read the FAQ: >> > * https://notmuchmail.org/faq/#index8h2 >> >> Oops, that needs to be updated. >> >> It is implemented. See notmuch-config(

Re: [PATCH 01/15] tests: move add_gpgsm_home to test-lib.sh

2020-04-30 Thread David Bremner
Daniel Kahn Gillmor writes: > This allows us to test S/MIME messages in other tests. > pushed the revised series. Actually I had to cherry-pick the last patch from the gitlab branch for some reason (probably lack of rebasing after earlier patches were changed). d

Re: Any updates on the `List-Id` indexing feature?

2020-04-29 Thread David Bremner
Ciprian Dorin Craciun writes: > I've searched the mailing list archives about the `List-Id` feature: > * https://www.mail-archive.com/notmuch@notmuchmail.org/msg43214.html > * https://www.mail-archive.com/notmuch@notmuchmail.org/msg22092.html > *

Re: Inconsistencies in handling command flags: `--flag=value` different than `--flag value`

2020-04-29 Thread David Bremner
Jameson Graef Rollins writes: > On Wed, Apr 29 2020, David Bremner wrote: >> I guess I'm a bit leery of removing UI features that presumably at least >> some people rely on. It's pretty upsetting to have sofware break one's >> muscle memory. > > I dare say there are

Re: Inconsistencies in handling command flags: `--flag=value` different than `--flag value`

2020-04-29 Thread David Bremner
Tomi Ollila writes: > On Tue, Apr 28 2020, Daniel Kahn Gillmor wrote: > >> >> One final way we could normalize everything and make it less >> idiosyncratic, with shorter, simpler man pages: deprecate and then drop >> the --booloption/--no-booloption mechanisms, requiring --booloption=true >> or

Re: [PATCH 03/15] tests/smime: Include the Sample LAMPS Certificate Authority

2020-04-28 Thread David Bremner
Daniel Kahn Gillmor writes: > This CA is useful for test suites and the like, but is not an > actually-secure CA, because its secret key material is also published. > > I plan to use it for its intended purpose in the notmuch test suite. > > It was copied from this Internet Draft: > >

Re: [PATCH] util/zlib-extra: de-inline gzerror_str

2020-04-28 Thread David Bremner
David Bremner writes: > It turns out the behaviour of inline functions in C header files is > not a good idea, and can cause linking problems if the compiler > decides not to inline them. In principle this is solvable by using a > "static inline" declaration, but this po

Re: Inconsistencies in handling command flags: `--flag=value` different than `--flag value`

2020-04-27 Thread David Bremner
Ciprian Dorin Craciun writes: > [Again sorry for double reporting. BTW, where should I search for > previous bugs? I've currently tried the mailing list archive.] Another option is https://nmbug.notmuchmail.org/status This is just pointers into the mailing archive, but triaged. > >

Re: performance problems with notmuch new

2020-04-27 Thread David Bremner
Don Zickus writes: > On Fri, Apr 24, 2020 at 08:07:27PM -0300, David Bremner wrote: >> Don Zickus writes: >> >> > >> > Of course I am using this in a strange context. I am deleting emails >> > locally and then running 'notmuch new' to clean up the dat

[PATCH] util/zlib-extra: de-inline gzerror_str

2020-04-27 Thread David Bremner
It turns out the behaviour of inline functions in C header files is not a good idea, and can cause linking problems if the compiler decides not to inline them. In principle this is solvable by using a "static inline" declaration, but this potentially makes a copy in every compilation unit. Since

Re: [PATCH] emacs: Use `cl-lib' instead of deprecated `cl'

2020-04-27 Thread David Bremner
Jonas Bernoulli writes: > I have fixed the remaining issues and added two small commits. > See v3. > Great, thanks. I've pushed the main one, and tagged the other two for review. d ___ notmuch mailing list notmuch@notmuchmail.org

Re: performance problems with notmuch new

2020-04-24 Thread David Bremner
Franz Fellner writes: > > On Thu Apr 23 00:21:30 2020, Olly Betts wrote: >> Then I'd try compacting the database (I think there's a "notmuch >> compact" subcommand to do this). > And there we go. Cured the issues. Dropped the very first indexing > from several minutes to 1.5 seconds on the

Re: performance problems with notmuch new

2020-04-24 Thread David Bremner
Don Zickus writes: > > Of course I am using this in a strange context. I am deleting emails > locally and then running 'notmuch new' to clean up the database. > [snip] > So maybe my use case is unusual and the slowness is expected. I'd say it's a known performance bug in notmuch that it

Re: Strip spaces in `tags` in `~/.notmuch-config` (and other fields)

2020-04-24 Thread David Bremner
Ciprian Dorin Craciun writes: > > I've tried to manually edit my `~/.notmuch-config`, and I've seen that > the field `tags` was written as `tags=unread;inbox;`. In order to > increase readability I've decided to update my configuration file by > adding spaces around `=` and `;` as in `tags =

Re: performance problems with notmuch new

2020-04-24 Thread David Bremner
Don Zickus writes: > > The only thing I can think of is my fstrim service runs 1x / week on Monday > at midnight and maybe that helped clean things up?? Perhaps I should > increase that frequency or run it manually when things go bad. > Is notmuch new still slow on your mail store, or did that

Re: test_emacs_expect_t does ignore Emacs as prerequisite

2020-04-24 Thread David Bremner
Milton Vandersloot writes: > > [PATCH] Let test_emacs_expect_t respect missing external prerequisites > > test_emacs_expect_t did not test for missing prerequisites (even though > it called test_emacs which does it). Fix that by testing for missing > prerequisites. > I agree there's a bug here,

Re: [PATCH] test: sort the output of the "prefix" test in T610-message-property

2020-04-23 Thread David Bremner
Olivier Taïbi writes: > This test extracts values from a (key,value) map where multiple entries > can have the same key, and the entries are sorted by key, but not by > value. The test incorrectly assumes that the values will be sorted as > well, so sort the output. pushed. d

Re: [PATCH v2] build: drop support for xapian versions less than 1.4

2020-04-23 Thread David Bremner
Tomi Ollila writes: > Xapian 1.4 is over 3 years old now (1.4.0 released 2016-06-24), > and 1.2 has been deprecated in Notmuch version 0.27 (2018-06-13). > > Xapian 1.4 supports compaction, field processors and retry locking; > conditionals checking compaction and field processors were removed >

Re: [PATCH] emacs: Use `cl-lib' instead of deprecated `cl'

2020-04-21 Thread David Bremner
Jonas Bernoulli writes: > David Bremner writes: > >> A quick git grep suggests there are still cl-isms in the test-harness. > > I've fixed that now, see v2. > >> I get 3 test failures > > I am having issues running the tests. Currently > notmuch-mua-send-an

Re: performance problems with notmuch new

2020-04-20 Thread David Bremner
Franz Fellner writes: > I also suffer from bad performance of notmuch new. I used notmuch > some years ago and notmuch new always felt instantanious. Had to stop > using it because internet was too slow to sync my mails :/ Now (with > better internet and a completely new setup using mbsync)

Re: performance problems with notmuch new

2020-04-20 Thread David Bremner
Don Zickus writes: > > Hmm, for me --small was 35s and --medium was 32 minutes. This is on a > i7-9750H / nvme. I would expect numbers similar to yours. > In addition to the breakdown of numbers that I posted, it would be potentially useful to know if it is I/O bound or CPU bound, and what

Re: [PATCH] emacs: Use `cl-lib' instead of deprecated `cl'

2020-04-17 Thread David Bremner
William Casarin writes: > From: Jonas Bernoulli > > Starting with Emacs 27 the old `cl' implementation is finally > considered obsolete. Previously its use was strongly discouraged > at run-time but one was still allowed to use it at compile-time. > > For the most part the transition is very

Re: [PATCH] emacs: introduce notmuch-search-by-tag

2020-04-16 Thread David Bremner
Keegan Carruthers-Smith writes: > This is like notmuch-search-filter-by-tag, but creates a new search > rather than filtering the current search. We add this to > notmuch-common-keymap since this can be used by many contexts. We bind > to the key "t", which is the same key used by >

Re: [PATCH] gzerror() after gzclose_r() is a use after free

2020-04-16 Thread David Bremner
Olivier Taïbi writes: > As suggested by David Bremner in > https://notmuchmail.org/pipermail/notmuch/2020/029288.html > here is a separate patch for bug #2: calling gzerror() (indirectly via > gzerror_str()) after gzclose_r is a use after free, according to zlib's >

Re: [PATCH] emacs: use def instead of initial-input for notmuch-show-browse-urls

2020-04-16 Thread David Bremner
Keegan Carruthers-Smith writes: > This is the non-deprecated way to use completing-read. Additionally > the old use was broken when using ivy for completing-read. For user's > using completing-read-default they won't see the default URL now, but > if they hit enter it will be visited.

Re: [PATCH] after gzgets(), Z_STREAM_END means EOF, not error

2020-04-16 Thread David Bremner
Olivier Taïbi writes: > As suggested by David Bremner in > https://notmuchmail.org/pipermail/notmuch/2020/029288.html > here is the patch for bug #3: after gzgets() returns NULL (meaning EOF > or error), the error code Z_STREAM_END means EOF and not error. pushed, with revised co

Re: [PATCH 2/4] emacs: Declare function notmuch-show-get-message-id

2020-04-16 Thread David Bremner
Jonas Bernoulli writes: pushed the first 3. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch

Re: performance problems with notmuch new

2020-04-15 Thread David Bremner
Don Zickus writes: >> runs in about 30s here (i7 4770 / SSD). Replacing --small with --medium >> takes about 10M (so a superlinear slowdown in wall clock time, since >> that represents a 10x scale-up in the corpus size.). > > Hmm, for me --small was 35s and --medium was 32 minutes. This is on

Re: easy (?) elisp project for notmuch [it's mostly DONE]

2020-04-15 Thread David Bremner
Jonas Bernoulli writes: > > One related use case for "notmuch insert" that I had in mind is the > import of debbugs threads. It someone is aware of an existing solution > then please let me know. Kyle, have you considered mirroring > emacs-devel and the Emacs debbugs as well? Sean Whitton (in

Re: performance problems with notmuch new

2020-04-15 Thread David Bremner
Don Zickus writes: > > Tips for debugging this? > > I ran the notmuch performance/time-test, but after 15 minutes of waiting for > the initial notmuch new to finish, I gave up and aborted. You can try one of the smaller corpus sizes $ make OPTIONS=--small time-test runs in about 30s here (i7

Re: timezone in notmuch

2020-04-14 Thread David Bremner
David Bremner writes: > > There's no user customizable variable for this. The code in this part of > notmuch show is fairly simple, so someone could probably figure out how > to pass (notmuch-show-get-timestamp) to the appropriate emacs function > to format the date in the loc

Re: timezone in notmuch

2020-04-14 Thread David Bremner
di...@santanas.co.za writes: > Greetings :) > > In notmuch-show-mode, some emails have a date like this: Date: Thu, 09 > Apr 2020 14:34:42 + while others like this Date: Sun, 12 Apr 2020 > 21:04:01 +0200 > > Is this something I can change in notmuch to always show the date/time > in my local

Re: [PATCH] gzerror() after gzclose_r() is a use after free

2020-04-14 Thread David Bremner
Olivier Taïbi writes: > As suggested by David Bremner in > https://notmuchmail.org/pipermail/notmuch/2020/029288.html > here is a separate patch for bug #2: calling gzerror() (indirectly via > gzerror_str()) after gzclose_r is a use after free, according to zlib's > manu

Re: [PATCH] after gzgets(), Z_STREAM_END means EOF, not error

2020-04-14 Thread David Bremner
Olivier Taïbi writes: > As suggested by David Bremner in > https://notmuchmail.org/pipermail/notmuch/2020/029288.html > here is the patch for bug #3: after gzgets() returns NULL (meaning EOF > or error), the error code Z_STREAM_END means EOF and not error. > PS: out of curios

Re: easy (?) elisp project for notmuch [it's mostly DONE]

2020-04-14 Thread David Bremner
Jonas Bernoulli writes: > I have already done this (and then some) a while ago. I want to have > another look before I submit it, but will try to get that done today. > > (I cannot actually reply to "easy (?) elisp project for notmuch" > because I wasn't subscribed yet when that was send.) >

easy (?) elisp project for notmuch

2020-04-14 Thread David Bremner
As of Emacs 27, Emacs will start issuing deprecation warnings for packages that load cl.el. I _think_ it's just a matter of replacing functions and macros from cl.el with cl- prefixed ones, but I haven't really investigated. If someone is looking for an easy way to contribute, this cleanup

Re: [PATCH 1/6] test: add known_broken test for dumping large stored queries

2020-04-13 Thread David Bremner
David Bremner writes: > 'qsx' reported a bug on #notmuch with notmuch-dump and large stored > queries. This test will pass (on my machine) if the value of `repeat' > is made smaller. > > Reported-By: Thomas Schneider series pushed, with one space deleted to pl

Re: [PATCH] zlib-related bugs

2020-04-13 Thread David Bremner
Olivier Taïbi writes: Thanks for the mail. In general we need each change in a separate patch for review. Being zlib related is not really close enough for us. > the following diff addresses 3 zlib-related bugs in notmuch. > 1) the second argument of gzerror() cannot be NULL, so replace it by a

[PATCH 3/6] status: add print_status_gzbytes

2020-04-13 Thread David Bremner
This is in the client code, rather than libnotmuch_util, because it prints to stderr. Also it in pretends to generate notmuch status codes. --- notmuch-client.h | 8 +++- status.c | 14 ++ 2 files changed, 21 insertions(+), 1 deletion(-) diff --git a/notmuch-client.h

[PATCH 1/6] test: add known_broken test for dumping large stored queries

2020-04-13 Thread David Bremner
'qsx' reported a bug on #notmuch with notmuch-dump and large stored queries. This test will pass (on my machine) if the value of `repeat' is made smaller. Reported-By: Thomas Schneider --- test/T600-named-queries.sh | 16 1 file changed, 16 insertions(+) diff --git

[PATCH 4/6] cli/dump: define GZPRINTF macro and use it in place of gzprintf

2020-04-13 Thread David Bremner
This will at least catch errors, and can be replaced with more sophisticated error handling where appropriate. --- notmuch-client.h | 4 notmuch-dump.c | 24 2 files changed, 16 insertions(+), 12 deletions(-) diff --git a/notmuch-client.h b/notmuch-client.h index

[PATCH 5/6] cli/dump: define GZPUTS and use it in notmuch-dump

2020-04-13 Thread David Bremner
Similarly to GZPRINTF, this is a drop in replacement that can be improved where needd. --- notmuch-client.h | 1 + notmuch-dump.c | 10 +- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/notmuch-client.h b/notmuch-client.h index 01f5101a..b59f3c81 100644 ---

[PATCH 2/6] util/zlib-extra.c: don't pass NULL to gzerror.

2020-04-13 Thread David Bremner
Although (as of 1.2.11) zlib checks this parameter before writing to it, the docs don't promise to keep doing so, so be safe. --- notmuch-dump.c| 6 +++--- notmuch-restore.c | 2 +- util/zlib-extra.c | 2 +- util/zlib-extra.h | 5 + 4 files changed, 10 insertions(+), 5 deletions(-) diff

[PATCH 6/6] cli/dump: replace use of gzprintf with gzputs for config values

2020-04-13 Thread David Bremner
These can be large, and hit buffer limitations of gzprintf. --- notmuch-dump.c | 4 +++- test/T600-named-queries.sh | 1 - 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/notmuch-dump.c b/notmuch-dump.c index 52a88283..887ef7f0 100644 --- a/notmuch-dump.c +++

Re: [PATCH 3/5] cli/dump: define GZPRINTF macro and use it in place of gzprintf

2020-04-13 Thread David Bremner
David Bremner writes: > Tomi Ollila writes: > >> __location__ ?? never seen such a (preprocessor?) definition. could not >> find any reference by search... > > I have to admit, it's just cargo culted from util/error_util.h > OIC, it's defined in talloc.h. Proba

Re: [PATCH 3/5] cli/dump: define GZPRINTF macro and use it in place of gzprintf

2020-04-13 Thread David Bremner
Tomi Ollila writes: > __location__ ?? never seen such a (preprocessor?) definition. could not > find any reference by search... I have to admit, it's just cargo culted from util/error_util.h > > there are also some suspiciously looking like inconsistent spaces in that > macro above OK, I'll

[PATCH 4/5] cli/dump: define GZPUTS and use it in notmuch-dump

2020-04-12 Thread David Bremner
Similarly to GZPRINTF, this is a drop in replacement that can be improved where needd. --- notmuch-client.h | 1 + notmuch-dump.c | 10 +- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/notmuch-client.h b/notmuch-client.h index 55d4d526..7efcb06f 100644 ---

[PATCH 5/5] cli/dump: replace use of gzprintf with gzputs for config values

2020-04-12 Thread David Bremner
These can be large, and hit buffer limitations of gzprintf. --- notmuch-dump.c| 4 +++- test/T240-dump-restore.sh | 1 - 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/notmuch-dump.c b/notmuch-dump.c index fb322237..23d7d20a 100644 --- a/notmuch-dump.c +++

[no subject]

2020-04-12 Thread David Bremner
Here's a not too ambitious attempt to clean up the error handling on zlib output. It's bit gross to treat any error reported by zlib as fatal, but it's a step up from ignoring them, and it's in the client code, not in the library. The first patch splits out the first fix of

[PATCH 1/5] util/zlib-extra.c: don't pass NULL to gzerror.

2020-04-12 Thread David Bremner
Although (as of 1.2.11) zlib checks this parameter before writing to it, the docs don't promise to keep doing so, so be safe. --- util/zlib-extra.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/util/zlib-extra.c b/util/zlib-extra.c index f691cccf..e17a9731 100644 ---

[PATCH 3/5] cli/dump: define GZPRINTF macro and use it in place of gzprintf

2020-04-12 Thread David Bremner
This will at least catch errors, and can be replaced with more sophisticated error handling where appropriate. --- notmuch-client.h | 3 +++ notmuch-dump.c | 24 2 files changed, 15 insertions(+), 12 deletions(-) diff --git a/notmuch-client.h b/notmuch-client.h index

[PATCH 2/5] status: add print_status_gzbytes

2020-04-12 Thread David Bremner
This is in the client code, rather than libnotmuch_util, because it prints to stderr. Also it in pretends to generate notmuch status codes. --- notmuch-client.h | 8 +++- status.c | 14 ++ 2 files changed, 21 insertions(+), 1 deletion(-) diff --git a/notmuch-client.h

Re: [PATCH] test: add known_broken test for dumping large stored queries

2020-04-12 Thread David Bremner
David Bremner writes: > 'qsx' reported a bug on #notmuch with notmuch-dump and large stored > queries. This test will pass (on my machine) if the value of `repeat' > is made smaller. I believe the underlying problem is explained by this comment in zlib.h The number of uncompres

[PATCH] test: add known_broken test for dumping large stored queries

2020-04-12 Thread David Bremner
'qsx' reported a bug on #notmuch with notmuch-dump and large stored queries. This test will pass (on my machine) if the value of `repeat' is made smaller. --- test/T240-dump-restore.sh | 13 + 1 file changed, 13 insertions(+) diff --git a/test/T240-dump-restore.sh

Re: crash after running notmuch new

2020-04-07 Thread David Bremner
Matt writes: > thanks didn't know about xapian-check ! > the output > === > docdata: > blocksize=8K items=70 firstunused=3 revision=421 levels=0 root=2 > B-tree checked okay > docdata table structure checked OK > > termlist: > blocksize=8K items=186136 firstunused=62058 revision=421 levels=2

Re: one specific Mail not found by notmuch

2020-04-07 Thread David Bremner
Gregor Zattler writes: > > I did a test with a modified .notmuch-config, provided a database > path /tmp/Mail, did mkdir -p /tmp/Mail/inbox{cur,new,tmp}, copied > this file into /tmp/Mail/inbox/cur, did a > NOTMUCH_CONFIG=/tmp/.notmuch-config notmuch new, and then notmuch > find this very email

Re: crash after running notmuch new

2020-04-07 Thread David Bremner
Matt writes: > hi, > > I have a script that runs mbsync followed by notmuch new. > It ends with `terminate called after throwing an instance of > 'Xapian::DatabaseCorruptError`. > Have you tried running xapian-check? d ___ notmuch mailing list

Re: notmuch-mode: Emails with PDF attachments incorrectly tagged as text/plain expose a few issues

2020-04-06 Thread David Bremner
Tomi Ollila writes: > On Mon, Apr 06 2020, David Bremner wrote: > >> Leo Gaspard writes: >> >>> David Bremner writes: >>> >>>> Leo Gaspard writes: >>>> >>>>> Hello, >>>>> >>>>> I have r

Re: notmuch-mode: Emails with PDF attachments incorrectly tagged as text/plain expose a few issues

2020-04-06 Thread David Bremner
Leo Gaspard writes: > David Bremner writes: > >> Leo Gaspard writes: >> >>> Hello, >>> >>> I have recently started conversing with someone whose email client >>> incorrectly tags PDF attachments as text/plain. >>> >> >

Re: [PATCH 1/7] emacs/tree: return true if a thread was found in next-thread

2020-04-06 Thread David Bremner
William Casarin writes: > William Casarin writes: > >> This will allow us to pop back to parent buffers when there are no >> more threads to jump to. >> >> Signed-off-by: William Casarin >> --- >> >> This is as rebased version of id:20191228150124.20630-1-j...@jb55.com >> as requested in

Re: notmuch-mode: Emails with PDF attachments incorrectly tagged as text/plain expose a few issues

2020-04-06 Thread David Bremner
Leo Gaspard writes: > Hello, > > I have recently started conversing with someone whose email client > incorrectly tags PDF attachments as text/plain. > Hi Leo; As I mentioned on IRC, we most likely need a reproducer message before making any progress on this. Maybe you can ask your

Re: Mark tests which require debug symbols

2020-04-05 Thread David Bremner
Milton Vandersloot writes: > Dear notmuch Developers > > The test suite fails some tests when the executable is not build with > debug symbols (-g). To run the test suite completely notmuch has to > be (re)compiled with debug symbols. However, in this scenario the > tested code/library (with

Re: [PATCH] nmbug: explicitly prefer python3

2020-04-03 Thread David Bremner
Daniel Kahn Gillmor writes: > nmbug and notmuch-report are developer tools. It's 2018, and all > developers should have python3 available. > Pushed. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch

  1   2   3   4   5   6   7   8   9   10   >