Re: [PATCH 1/2] configure: detect 64 bit time_t
On Wed, Jun 24 2020, David Bremner wrote:
> Certain tests involving timestamps > 32bits cannot pass with the
> current libnotmuch API. We will avoid this isssue for now by disabling
s/isssue/issue/
> those tests on "old" architectures with 32bit time_t.
> ---
> configure | 33 -
> 1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 05ade05b..ecb0bdb7 100755
> --- a/configure
> +++ b/configure
> @@ -1045,6 +1045,34 @@ else
> fi
> rm -f compat/have_timegm
>
> +cat < _time_t.c
> +#include
> +#include
> +int main(int argc, char**argv) {
> + printf("%d\n",sizeof(time_t) >= 8);
Since notmuch now (since fall 2018) requires c11 compiler, static_assert
would be simpler alternative:
#include
#include
static_assert(sizeof(time_t) >= 8, "sizeof(time_t) < 8");
and
if ${CC} -c _time_t.c -o /dev/null > /dev/null 2>&1
then
printf "Yes.\n"
have_64bit_time_t=1
else
printf "No.\n"
have_64bit_time_t=0
fi
but if not...
> +}
> +EOF
> +
> +printf "Checking for 64 bit time_t... "
> +if ${CC} _time_t.c -o _time_t > /dev/null 2>&1;
> +then
> +have_64bit_time_t=$(./_time_t)
anyway would be better for _time_t just exit 0 or 1 and
set have_64bit_time_t as (inverse =D) of that (like above),
... but still, static_assert FTW \0/ ;)
> +if [ $have_64bit_time_t -eq 1 ]
> +then
> +printf "Yes.\n"
> +else
> +printf "No.\n"
> +fi
> +else
> +cat < +
> +*** Error: compilation failed. Please try running configure again in
> +a clean environment, and if the problem persists, report a bug.
> +EOF
> +rm -f _time_t _time_t.c exit 1
> +fi
> +
> +
> printf "Checking for dirent.d_type... "
> if ${CC} -o compat/have_d_type "$srcdir"/compat/have_d_type.c > /dev/null
> 2>&1
> then
> @@ -1128,7 +1156,7 @@ for flag in -Wmissing-declarations; do
> done
> printf "\n\t%s\n" "${WARN_CFLAGS}"
>
> -rm -f minimal minimal.c _libversion.c _libversion _libversion.sh
> _check_session_keys.c _check_session_keys _check_x509_validity.c
> _check_x509_validity
> +rm -f minimal minimal.c _time_t _time_t.c _libversion.c _libversion
> _libversion.sh _check_session_keys.c _check_session_keys
> _check_x509_validity.c _check_x509_validity
>
> # construct the Makefile.config
> cat > Makefile.config < @@ -1429,6 +1457,9 @@ NOTMUCH_HAVE_MAN=$((have_sphinx))
> NOTMUCH_HAVE_BASH=${have_bash}
> NOTMUCH_BASH_ABSOLUTE=${bash_absolute}
>
> +# Whether time_t is 64 bits (or more)
> +NOTMUCH_HAVE_64BIT_TIME_T=${have_64bit_time_t}
> +
> # Whether perl exists, and if so where
> NOTMUCH_HAVE_PERL=${have_perl}
> NOTMUCH_PERL_ABSOLUTE=${perl_absolute}
> --
> 2.27.0
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] completion: remove "setup" from the list of possible completions
On Sat, Jun 20 2020, Ralph Seichter wrote: > * Tomi Ollila: > >> imo.the completions should primarily provide convenience to the >> interactive user, to see all possible options (also those >> seldomly.used) one can use help and namual pages... > > "Can use" being the operative term, not "should have to use". I would > not want completion to omit certain commands, based on somebody else's > notion of what is convenient, which in turn forces me to use other means > of figuring out a seldom-used command I may or may not be aware of. > > If this means entering three characters instead of two, then three > characters it is. Alternatively, make it a configurable option, with > "convenient=false" being the default. I vote against the change. > > First world problems... ;-) Indeed! You're wrong and I am right... ;) unfortunately the margin is too small and status quo (i.e. what we have now) may prevail. (well, I haven't even installed the completions -- perhaps I write my own zsh completions which will expand 'notmuch s' -> 'notmuch search' ;D) -- note that I also have no notmuch-* commands in my PATH, so 'notm' expands to 'notmuch ' ! \o/ FTW ;) > > -Ralph Tomi (one random user like all of us) ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] completion: remove "setup" from the list of possible completions
On Sat, Jun 20 2020, reto@labrat.space wrote: > On Fri, Jun 19, 2020 at 12:40:49PM +0200, Łukasz Stelmach wrote: >> Having "setup" in the set requires entering three instad of two characters >> for "search". Since "setup" is rearly used it makes little sense to have >> it in the set and cripple UX for much more frequently used "search". > > I very much disagree with this patch. > The completions should contain all possible values, saving a single keystroke > is > certainly not a valid reason to remove a valid option from the completions. I disagree your disagreement, and would.be very much favorable to this change. imo.the completions should primarily provide convenience to the interactive user, to see all possible options (also those seldomly.used) one can use help and namual pages... Tomi > > Writeuu an alias into your bashrc if that bothers you so much... Then you > can save > much more keystrokes. > ___ > notmuch mailing list > notmuch@notmuchmail.org > https://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Feature freeze for notmuch 0.30: June 1
On Wed, Jun 17 2020, Tomi Ollila wrote:
> On Wed, Jun 17 2020, Dan Čermák wrote:
>
>>
>> I have tried updating the package in openSUSE Tumbleweed to 0.30~rc2 but
>> running the tests results in the following failures:
>> --8<---cut here---start->8---
>> T357-index-decryption: Testing indexing decrypted mail
>> FAIL verify signature with stashed session key
>> good_sig: value not equal:
>> data[0][0][0]["crypto"]["signed"]["status"][0]["status"] = 'error' != 'good'
>
> FYI: On Fedora 32 I (also) get:
>
> T357-index-decryption: Testing indexing decrypted mail
>FAIL verify signature with stashed session key
> good_sig: value not equal:
> data[0][0][0]["crypto"]["signed"]["status"][0]["status"] = 'error' != 'good'
>
> (i.e exactly the same)
>
> I've not bothered to care ;/
However, more detail:
executed
notmuch show --format=json id:encrypted-sig...@crypto.notmuchmail.org | jq .
before that failing test -- this is the related data:
"crypto": {
"signed": {
"status": [
{
"status": "error",
"keyid": "6D92612D94E46381",
"errors": {
"key-missing": true
}
}
],
"encrypted": true
},
>
> The BROKEN failures are expected failures...
>
> Tomi
>
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Feature freeze for notmuch 0.30: June 1
On Wed, Jun 17 2020, Dan Čermák wrote: > > I have tried updating the package in openSUSE Tumbleweed to 0.30~rc2 but > running the tests results in the following failures: > --8<---cut here---start->8--- > T357-index-decryption: Testing indexing decrypted mail > FAIL verify signature with stashed session key > good_sig: value not equal: > data[0][0][0]["crypto"]["signed"]["status"][0]["status"] = 'error' != 'good' FYI: On Fedora 32 I (also) get: T357-index-decryption: Testing indexing decrypted mail FAIL verify signature with stashed session key good_sig: value not equal: data[0][0][0]["crypto"]["signed"]["status"][0]["status"] = 'error' != 'good' (i.e exactly the same) I've not bothered to care ;/ The BROKEN failures are expected failures... Tomi > > T590-thread-breakage: Testing thread breakage during reindexing > BROKEN No ghosts should remain after deletion of second message > > T670-duplicate-mid: Testing duplicate message ids > BROKEN First subject preserved in notmuch-show (json) > BROKEN Regexp search for second subject > > Notmuch test suite complete. > 1152/1156 tests passed. > 3 broken tests failed as expected. > 1 test failed. > All tests in 1 file skipped. > ERROR: parallel test suite returned error code 1 > make: *** [test/Makefile.local:69: test] Error 1 > --8<---cut here---end--->8--- > > I can reproduce these failures on my local machine as well as in the > openSUSE build environment (the Open Build Service). As I am a bit > reluctant to skip even more tests: could someone who is more familiar > with notmuch maybe take a look at this or guide me through this? > > > Thanks in advance, > > Dan ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Update tox.ini for python3.8 and fix pypy3.6
On Mon, Jun 15 2020, David Bremner wrote:
> Floris Bruynooghe writes:
>
>> [testenv]
>> deps =
>> @@ -14,3 +14,6 @@ commands = pytest --cov={envsitepackagesdir}/notmuch2
>> {posargs}
>>
>> [testenv:pypy35]
>> basepython = pypy3.5
>> +
>> +[testenv:pypy36]
>> +basepython = pypy3.6
>
> I'm not an expert, but should python 3.7 and python 3.8 have similar
> clauses? Or do they work by default?
"Python 3.6 compatible PyPy3.6 v7.3.1" in https://www.pypy.org/download.html
hints there are not (yet) pypy3.7 nor pypy3.8
>
> d
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] python/notmuch2: do not destroy messages owned by a query
Hi Anton, On Thu, May 21 2020, Anton Khirnov wrote: > ping Great (an important) stuff in this series ! ...just that... Floris did good review on your changes the next day. What I remember was there (looked 30 mins ago) - style: somewhat important (I press more there). Easy to get better, good and consistent style makes it better - docs in code: like Floris mentioned, the docs in commit messages are are not seen by user. The relevant documentation is to be with the code. commit message tells what was done and why - tests: since pytest is used to test the current notmuch2 cffi python tests, all new code that can be tested pytest code to do so is to be added And these have to be done now -- postponing such a things into future will just mean that it never happens, and the messines and entropy of the notmuch code gets even greater in such a case... > > -- > Anton Khirnov Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2] 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. --- diff to v1: > +rm -rf __pycache__ # cffi.FFI().verify() uses this space fits pretty well w/ pytest $conf removal few lines below configure | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/configure b/configure index f4b3c61a..05ade05b 100755 --- a/configure +++ b/configure @@ -711,14 +711,12 @@ if [ $have_python -eq 0 ]; then errors=$((errors + 1)) fi -have_python3_dev=0 +have_python3=0 if [ $have_python -eq 1 ]; then -printf "Checking for python3 dev (>= 3.5)..." -if "$python" -c 'import os, sys, sysconfig; -assert sys.version_info >= (3,5) -assert os.path.isfile(sysconfig.get_config_h_filename())' >/dev/null 2>&1; then +printf "Checking for python3 (>= 3.5)..." +if "$python" -c 'import sys, sysconfig; assert sys.version_info >= (3,5)'; >/dev/null 2>&1; then printf "Yes.\n" -have_python3_dev=1 +have_python3=1 else printf "No (will not install CFFI-based python bindings).\n" fi @@ -726,14 +724,15 @@ fi have_python3_cffi=0 have_python3_pytest=0 -if [ $have_python3_dev -eq 1 ]; then +if [ $have_python3 -eq 1 ]; then printf "Checking for python3 cffi and setuptools... " -if "$python" -c 'import cffi; import setuptools' >/dev/null 2>&1; then +if "$python" -c 'import cffi,setuptools; cffi.FFI().verify()' >/dev/null 2>&1; then printf "Yes.\n" have_python3_cffi=1 else printf "No (will not install CFFI-based python bindings).\n" fi +rm -rf __pycache__ # cffi.FFI().verify() uses this space printf "Checking for python3 pytest (>= 3.0)... " conf=$(mktemp) -- 2.25.1 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] NEWS: The minimum supported version of Xapian is now 1.4.0
On Sun, Jun 07 2020, David Bremner wrote: > Tomi Ollila writes: >> >> +Dependencies >> + >> + >> +Support for Xapian 1.2 is removed. The minimum supported version of >> +Xapian is now 1.4.0. >> + >> Notmuch 0.29.3 (2019-11-27) >> === > > These are not the diffs you are looking for (already in release and > master). Yes, I attempted to send id:20200609053446.11478-1-tomi.oll...@iki.fi I forgot the final step to `notmuch new` the mail sent and reread it. Now I saw straight from subject list that it did not look right ;/ Applied patch (as usual) from mail and tested (once again) it worked (Ubuntu 20.04 this time). Sorry for the noise =D Tomi > > d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] 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. --- I just could not get this right last time. Probably I concentrated on testing in debian 10 container so much, that the small differences in other systems went unnoticed (had that fedora 32 host polluted by installed python3-devel when doing final tests on that system)... configure | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/configure b/configure index f4b3c61a..d85fe5d2 100755 --- a/configure +++ b/configure @@ -711,14 +711,12 @@ if [ $have_python -eq 0 ]; then errors=$((errors + 1)) fi -have_python3_dev=0 +have_python3=0 if [ $have_python -eq 1 ]; then -printf "Checking for python3 dev (>= 3.5)..." -if "$python" -c 'import os, sys, sysconfig; -assert sys.version_info >= (3,5) -assert os.path.isfile(sysconfig.get_config_h_filename())' >/dev/null 2>&1; then +printf "Checking for python3 (>= 3.5)..." +if "$python" -c 'import sys, sysconfig; assert sys.version_info >= (3,5)'; >/dev/null 2>&1; then printf "Yes.\n" -have_python3_dev=1 +have_python3=1 else printf "No (will not install CFFI-based python bindings).\n" fi @@ -726,9 +724,9 @@ fi have_python3_cffi=0 have_python3_pytest=0 -if [ $have_python3_dev -eq 1 ]; then +if [ $have_python3 -eq 1 ]; then printf "Checking for python3 cffi and setuptools... " -if "$python" -c 'import cffi; import setuptools' >/dev/null 2>&1; then +if "$python" -c 'import cffi,setuptools; cffi.FFI().verify()' >/dev/null 2>&1; then printf "Yes.\n" have_python3_cffi=1 else -- 2.26.2 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] NEWS: The minimum supported version of Xapian is now 1.4.0
--- NEWS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/NEWS b/NEWS index 1921127fe02c..a16689cae04a 100644 --- a/NEWS +++ b/NEWS @@ -36,6 +36,12 @@ Introduce new CFFI-based python bindings in the python module named "notmuch2". Officially deprecate (but still support) the older "notmuch" module. +Dependencies + + +Support for Xapian 1.2 is removed. The minimum supported version of +Xapian is now 1.4.0. + Notmuch 0.29.3 (2019-11-27) === -- 2.13.3 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] 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. --- configure | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/configure b/configure index e4c738e5..f4b3c61a 100755 --- a/configure +++ b/configure @@ -713,14 +713,14 @@ fi have_python3_dev=0 if [ $have_python -eq 1 ]; then -printf "Checking for python3 dev..." +printf "Checking for python3 dev (>= 3.5)..." if "$python" -c 'import os, sys, sysconfig; -assert sys.version_info >= (3,0) +assert sys.version_info >= (3,5) assert os.path.isfile(sysconfig.get_config_h_filename())' >/dev/null 2>&1; then printf "Yes.\n" have_python3_dev=1 else -printf "No.\n" +printf "No (will not install CFFI-based python bindings).\n" fi fi @@ -732,7 +732,7 @@ if [ $have_python3_dev -eq 1 ]; then printf "Yes.\n" have_python3_cffi=1 else -printf "No.\n" +printf "No (will not install CFFI-based python bindings).\n" fi printf "Checking for python3 pytest (>= 3.0)... " @@ -742,7 +742,7 @@ if [ $have_python3_dev -eq 1 ]; then printf "Yes.\n" have_python3_pytest=1 else -printf "No.\n" +printf "No (will not test CFFI-based python bindings).\n" fi rm -f $conf fi -- 2.26.2 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] devel: script to calculate a list of authors.
On Fri, Jun 05 2020, David Bremner wrote: > 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. > --- > devel/author-scan.sh | 11 +++ > 1 file changed, 11 insertions(+) > create mode 100644 devel/author-scan.sh > > diff --git a/devel/author-scan.sh b/devel/author-scan.sh > new file mode 100644 > index ..2d9c4af8 > --- /dev/null > +++ b/devel/author-scan.sh > @@ -0,0 +1,11 @@ > +#!/bin/sh > + > +FILE_EXCLUDE='corpora' > +AUTHOR_EXCLUDE='uncrustify' > +# based on the FSF guideline, for want of a better idea. > +THRESHOLD=15 > + > +git ls-files | grep -v -e "$FILE_EXCLUDE" | xargs -n 1 -d \\n \ > + git blame -w > --line-porcelain -- | \ It worked !? =D -- good -- this indentation in line above is interesting... Tomi > +sed -n "/$AUTHOR_EXCLUDE/d; s/^[aA][uU][tT][hH][Oo][rR] //p" | \ > +sort -fd | uniq -ic | awk "\$1 >= $THRESHOLD" | sort -nr > -- > 2.26.2 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] tweaks to NEWS suggest by Tomi
On Fri, Jun 05 2020, David Bremner wrote: > See id:m27dwp40sx@guru.guru-group.fi LGTM. Tomi > --- > this is on top of Tomi's NEWS patch re Xapian > NEWS | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/NEWS b/NEWS > index a16689ca..556172bb 100644 > --- a/NEWS > +++ b/NEWS > @@ -5,8 +5,8 @@ S/MIME > -- > > Handle S/MIME (PKCS#7) messages -- one-part signed messages, encrypted > -messages, and multilayer messages. Treat them symmetrically to > -OpenPGP messages. This includes handling protected headers > +messages, and multilayer messages. Treat them symmetrically to > +OpenPGP messages. This includes handling protected headers > gracefully. > > If you're using Notmuch with S/MIME, you currently need to configure > @@ -16,21 +16,21 @@ Mixed-up MIME Repair > > > Detect and automatically repair a common form of message mangling > -created by Microsoft Exchange. (see index.repaired=mixedup in > -notmuch-properties(7). > +created by Microsoft Exchange (see index.repaired=mixedup in > +notmuch-properties(7)). > > Protected Headers > - > > Avoid indexing the legacy-display part of an encrypted message that > -has protected headers. (see > +has protected headers (see > index.repaired=skip-protected-headers-legacy-display in > -notmuch-properties(7). > +notmuch-properties(7)). > > Python > -- > > -Drop compatibility with python2, focus on python3. > +Drop support for python2, focus on python3. > > Introduce new CFFI-based python bindings in the python module named > "notmuch2". Officially deprecate (but still support) the older > -- > 2.26.2 > > ___ > notmuch mailing list > notmuch@notmuchmail.org > https://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] NEWS: The minimum supported version of Xapian is now 1.4.0
--- NEWS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/NEWS b/NEWS index 1921127fe02c..a16689cae04a 100644 --- a/NEWS +++ b/NEWS @@ -36,6 +36,12 @@ Introduce new CFFI-based python bindings in the python module named "notmuch2". Officially deprecate (but still support) the older "notmuch" module. +Dependencies + + +Support for Xapian 1.2 is removed. The minimum supported version of +Xapian is now 1.4.0. + Notmuch 0.29.3 (2019-11-27) === -- 2.13.3 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC] devel: script to calculate a list of authors.
On Wed, Jun 03 2020, David Bremner wrote: > 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. > --- > > I realized both AUTHORS and debian/copyright are woefully out of > date. I think it makes sense to keep something like this in the repo, > both to ease updates and to document a policy. Presuambly 'author ' > should be removed from the output, but I'm guessing Tomi will tear > this apart anyway ;). Hi David, I started doing that before even reading your commit (used less(1) to look the email from bottom... ;) I got some idea, but then decided there is no point spending too many minutes (what was that one 'time management' xkcd again... =D) anyway, some fun editing the nifty pipeline you write git ls-files | grep -v -e "$FILE_EXCLUDE" | xargs -n 1 -d \\n | \ git blame -w --line-porcelain -- | \ sed -n "/$AUTHOR_EXCLUDE/d; s/^[aA][uU][tT][hH][Oo][rR] //p" | \ sort -fd | uniq -ic | awk "\$1 >= $THRESHOLD" | sort -nr If there are more authors or files to exclude, then it is easiest to just write those out in pipeline, e.g. grep -v -e 'file-one' -e 'file 2 with spaces' ... and sed -n '/author1_ex1/d; /author2_ex1/d; s/^[aA][uU][tT][hH][Oo][rR] //p' (and, as usual, I always recommend 'set -euf' in shell scripts) Tomi > devel/author-scan.sh | 11 +++ > 1 file changed, 11 insertions(+) > create mode 100644 devel/author-scan.sh > > diff --git a/devel/author-scan.sh b/devel/author-scan.sh > new file mode 100644 > index ..b7b46a33 > --- /dev/null > +++ b/devel/author-scan.sh > @@ -0,0 +1,11 @@ > +#!/bin/sh > + > +FILE_EXCLUDE='corpora' > +AUTHOR_EXCLUDE='uncrustify' > +# based on the FSF guideline, for want of a better idea. > +THRESHOLD=15 > + > +git ls-files | grep -v "$FILE_EXCLUDE" | > +while read f; do > +git blame -w --line-porcelain -- "$f" | grep -I '^author ' | grep -v > "$AUTHOR_EXCLUDE" > +done | sort -fd | uniq -ic | awk "\$1 >= $THRESHOLD" | sort -nr > -- > 2.26.2 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] add NEWS for 0.30
post-push comments =D On Mon, Jun 01 2020, Daniel Kahn Gillmor wrote: > Signed-off-by: Daniel Kahn Gillmor > --- > NEWS | 35 +++ > 1 file changed, 35 insertions(+) > > diff --git a/NEWS b/NEWS > index 14db7f6f..1921127f 100644 > --- a/NEWS > +++ b/NEWS > @@ -1,6 +1,41 @@ > Notmuch 0.30 (2020-06-01) > = > > +S/MIME > +-- > + > +Handle S/MIME (PKCS#7) messages -- one-part signed messages, encrypted > +messages, and multilayer messages. Treat them symmetrically to > +OpenPGP messages. This includes handling protected headers > +gracefully. 2 spaces after period (.) ending sentence. I've been told that thiis is (official) style somewhere (which I personally dislike, but...) -- anyway that style is inconsistent with NEWS entries done previously (possibly not all of the NEWS entries I quickly looked but). > + > +If you're using Notmuch with S/MIME, you currently need to configure > +gpgsm appropriately. > + > +Mixed-up MIME Repair > + > + > +Detect and automatically repair a common form of message mangling > +created by Microsoft Exchange. (see index.repaired=mixedup in > +notmuch-properties(7). No closing paren for (see... What about period (.) after Exchange. > + > +Protected Headers > +- > + > +Avoid indexing the legacy-display part of an encrypted message that > +has protected headers. (see > +index.repaired=skip-protected-headers-legacy-display in > +notmuch-properties(7). ditto ((see ...) ditto (period (.) after headers.) > + > +Python > +-- > + > +Drop compatibility with python2, focus on python3. Was 'compatibility' completely dropped. Doesn't old bindings still work with python2 ? > +Introduce new CFFI-based python bindings in the python module named > +"notmuch2". Officially deprecate (but still support) the older > +"notmuch" module. > + > Notmuch 0.29.3 (2019-11-27) > === > > -- > 2.26.2 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] 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.
---
doc/man1/notmuch-config.rst | 5 +--
doc/man7/notmuch-search-terms.rst | 54 +--
2 files changed, 18 insertions(+), 41 deletions(-)
diff --git a/doc/man1/notmuch-config.rst b/doc/man1/notmuch-config.rst
index 323a8b65..769f336a 100644
--- a/doc/man1/notmuch-config.rst
+++ b/doc/man1/notmuch-config.rst
@@ -198,8 +198,9 @@ The available configuration items are described below.
**built_with.**
Compile time feature . Current possibilities include
-"compact" (see **notmuch-compact(1)**) and "field_processor" (see
-**notmuch-search-terms(7)**).
+"retry_lock" (configure option, included by default).
+(since notmuch 0.30, "compact" and "field_processor" are
+always included.)
**query.** **[STORED IN DATABASE]**
Expansion for named query called . See
diff --git a/doc/man7/notmuch-search-terms.rst
b/doc/man7/notmuch-search-terms.rst
index 1dd2dc58..28fca737 100644
--- a/doc/man7/notmuch-search-terms.rst
+++ b/doc/man7/notmuch-search-terms.rst
@@ -37,9 +37,8 @@ In addition to free text, the following prefixes can be used
to force
terms to match against specific portions of an email, (where
indicate user-supplied values).
-If notmuch is built with **Xapian Field Processors** (see below) some
-of the prefixes with forms can be also used to restrict the
-results to those whose value matches a regular expression (see
+Some of the prefixes with forms can be also used to restrict
+the results to those whose value matches a regular expression (see
**regex(7)**) delimited with //, for example::
notmuch search 'from:"/bob@.*[.]example[.]com/"'
@@ -87,8 +86,7 @@ thread:
of output from **notmuch search**
thread:{}
-If notmuch is built with **Xapian Field Processors** (see below),
-threads may be searched for indirectly by providing an arbitrary
+Threads may be searched for indirectly by providing an arbitrary
notmuch query in **{}**. For example, the following returns
threads containing a message from mallory and one (not necessarily
the same message) with Subject containing the word "crypto".
@@ -158,9 +156,7 @@ lastmod:..
query:
The **query:** prefix allows queries to refer to previously saved
-queries added with **notmuch-config(1)**. Named queries are only
-available if notmuch is built with **Xapian Field Processors**
-(see below).
+queries added with **notmuch-config(1)**.
property:=
The **property:** prefix searches for messages with a particular
@@ -353,23 +349,21 @@ since 1970-01-01 00:00:00 UTC. For example:
date:@..@
-date:..! can be used as a shorthand for date:... The
-expansion takes place before interpretation, and thus, for example,
-date:monday..! matches from the beginning of Monday until the end of
-Monday.
-With **Xapian Field Processor** support (see below), non-range
-date queries such as date:yesterday will work, but otherwise
-will give unexpected results; if in doubt use date:yesterday..!
-
-Currently, we do not support spaces in range expressions. You can
+Currently, spaces in range expressions are not supported. You can
replace the spaces with '\_', or (in most cases) '-', or (in some cases)
leave the spaces out altogether. Examples in this man page use spaces
for clarity.
-Open-ended ranges are supported (since Xapian 1.2.1), i.e. it's possible
-to specify date:.. or date:.. to not limit the start or
-end time, respectively. Pre-1.2.1 Xapian does not report an error on
-open ended ranges, but it does not work as expected either.
+Open-ended ranges are supported. I.e. it's possible to specify
+date:.. or date:.. to not limit the start or
+end time, respectively.
+
+Single expression
+-
+
+date: works as a shorthand for date:...
+For example, date:monday matches from the beginning of Monday until
+the end of Monday.
Relative date and time
--
@@ -446,24 +440,6 @@ Time zones
Some time zone codes, e.g. UTC, EET.
-XAPIAN FIELD PROCESSORS
-===
-
-Certain optional features of the notmuch query processor rely on the
-presence of the Xapian field processor API. You can determine if your
-notmuch was built against a sufficiently recent version of Xapian by running
-
-::
-
- % notmuch config get built_with.field_processor
-
-Currently the following features require field processor support:
-
-- non-r
[PATCH] configure: check existence of python3 setuptools and dev package
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 executed. --- configure | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/configure b/configure index 32a836bb..e4c738e5 100755 --- a/configure +++ b/configure @@ -711,12 +711,14 @@ if [ $have_python -eq 0 ]; then errors=$((errors + 1)) fi -have_python3=0 +have_python3_dev=0 if [ $have_python -eq 1 ]; then -printf "Checking for python3..." -if "$python" -c 'import sys; assert sys.version_info >= (3,0)' > /dev/null 2>&1; then +printf "Checking for python3 dev..." +if "$python" -c 'import os, sys, sysconfig; +assert sys.version_info >= (3,0) +assert os.path.isfile(sysconfig.get_config_h_filename())' >/dev/null 2>&1; then printf "Yes.\n" -have_python3=1 +have_python3_dev=1 else printf "No.\n" fi @@ -724,9 +726,9 @@ fi have_python3_cffi=0 have_python3_pytest=0 -if [ $have_python3 -eq 1 ]; then -printf "Checking for python3 cffi... " -if "$python" -c 'import cffi' >/dev/null 2>&1; then +if [ $have_python3_dev -eq 1 ]; then +printf "Checking for python3 cffi and setuptools... " +if "$python" -c 'import cffi; import setuptools' >/dev/null 2>&1; then printf "Yes.\n" have_python3_cffi=1 else -- 2.25.1 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs/tree: add notmuch-tree-filter
On Sat, Apr 25 2020, William Casarin wrote: > This implements the notmuch-tree version of notmuch-show-filter-thread > and binds it to the L key. No reasoning in commit message why 'L' is chosen... Tomi > > Signed-off-by: William Casarin > --- > emacs/notmuch-tree.el | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el > index e5c23de2..8f7738d7 100644 > --- a/emacs/notmuch-tree.el > +++ b/emacs/notmuch-tree.el > @@ -328,6 +328,7 @@ FUNC." > (define-key map "p" 'notmuch-tree-prev-matching-message) > (define-key map "N" 'notmuch-tree-next-message) > (define-key map "P" 'notmuch-tree-prev-message) > +(define-key map "L" 'notmuch-tree-filter) > (define-key map (kbd "M-p") 'notmuch-tree-prev-thread) > (define-key map (kbd "M-n") 'notmuch-tree-next-thread) > (define-key map "k" 'notmuch-tag-jump) > @@ -965,6 +966,14 @@ Complete list of currently available key bindings: > (insert (format " (process returned %d)" exit-status))) > (insert "\n") > > +(defun notmuch-tree-filter (query) > + "Filter or LIMIT the current tree based on a new query string. > + > +Reshows the current tree with matches defined by the new query-string." > + (interactive (list (notmuch-read-query "Filter tree: "))) > + (setq notmuch-tree-query-context (if (string= query "") nil query)) > + (notmuch-tree-refresh-view t)) > + > (defun notmuch-tree-process-filter (proc string) >"Process and filter the output of \"notmuch show\" for tree view" >(let ((results-buf (process-buffer proc)) > -- > 2.25.1 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] doc: fix for out-of-tree builds of notmuch-emacs docs
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 of this is that the emacs
> docstrings are now defined for every rst source file. They are
> namespaced with docstring::, so hopefully there will not be any
> surprises. One thing that is noticable is a small (absolute) time
> penalty in running sphinx-doc.
IMO good enough tolerable hack to get this done for no (read: I don't
know alternatives).
Some comments below...
> ---
> doc/Makefile.local| 2 +-
> doc/conf.py | 19 +++
> doc/notmuch-emacs.rst | 10 --
> 3 files changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/doc/Makefile.local b/doc/Makefile.local
> index b4e0c955..769438ed 100644
> --- a/doc/Makefile.local
> +++ b/doc/Makefile.local
> @@ -4,7 +4,7 @@ dir := doc
>
> # You can set these variables from the command line.
> SPHINXOPTS:= -q
> -SPHINXBUILD = WITH_EMACS=${WITH_EMACS} sphinx-build
> +SPHINXBUILD = WITH_EMACS=${WITH_EMACS} RSTI_DIR=$(realpath emacs)
> sphinx-build
I was about to comment the above, before realized $(realpath ...) executes
GNU Make function instead of system command :) ...
> DOCBUILDDIR := $(dir)/_build
>
> # Internal variables.
> diff --git a/doc/conf.py b/doc/conf.py
> index fc9738ff..d8841d99 100644
> --- a/doc/conf.py
> +++ b/doc/conf.py
> @@ -29,10 +29,21 @@ release = version
> # directories to ignore when looking for source files.
> exclude_patterns = ['_build']
>
> -# If we don't have emacs (or the user configured --without-emacs),
> -# don't build the notmuch-emacs docs, as they need emacs to generate
> -# the docstring include files
> -if os.environ.get('WITH_EMACS') != '1':
> +if os.environ.get('WITH_EMACS') == '1':
> +# Hacky reimplementation of include to workaround limitations of
> +# sphinx-doc
> +accumulator='.. include:: /../emacs/rstdoc.rsti\n\n' # in the source tree
accumulator=['.. include:: /../emacs/rstdoc.rsti\n\n' # in the source tree]
(in list, see below)
> +rsti_dir=os.environ.get('RSTI_DIR')
spaces around '='
> +# the other files are from the build tree
> +for file in ['notmuch.rsti', 'notmuch-lib.rsti', 'notmuch-show.rsti',
> 'notmuch-tag.rsti']:
tuple ('notmuch.rsti', 'notmuch-lib.rsti', ...) could have been used
> +with open(rsti_dir+'/'+file) as f:
> +for line in f:
> +accumulator += line
> +rst_epilog=accumulator
accumulator.append(open(rsti_dir + '/' + file).read())
accumulator = ''.join(accumulator)
rst_epilog = accumulator
alternative last 2 lines
rst_epilog = ''.join(accumulator)
del accumulator
(I personally would have left 'accumulator' away and used 'rst_epilog'
directly (and perhaps commented its use as temporary list type).)
> +else:
> +# If we don't have emacs (or the user configured --without-emacs),
> +# don't build the notmuch-emacs docs, as they need emacs to generate
> +# the docstring include files
> exclude_patterns.append('notmuch-emacs.rst')
>
> # The name of the Pygments (syntax highlighting) style to use.
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Python 3.x bindings support which versions, exactly?
On Mon, May 25 2020, Floris Bruynooghe wrote: > In tox.ini the earliest version is 3.5 and if memory serves me right > there's a reasonably good reason for that. I think the notmuch2 > bindings use some features not yet present in 3.4. But anything >= 3.5 > should be supported and if not a bug. I guess tox.ini should be updated > with 3.8 sometime :) I've been long thinking whether our current python3 check is "strict" enough, as it, in configure, is: if "$python" -c 'import sys; assert sys.version_info >= (3,0)' > /dev/null 2>&1 Perhaps that should be updated to (3,5) ? > > Cheers, > Floris Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v3 3/3] emacs: Use `dolist' instead of `mapcar' for side-effects
On Sat, Apr 25 2020, Jonas Bernoulli wrote: > As recommended by the byte-compiler. I don't know about v3 2/3, but this, v3 3/3 looks good to me. Tomi > --- > test/emacs-attachment-warnings.el | 23 +++ > 1 file changed, 11 insertions(+), 12 deletions(-) > > diff --git a/test/emacs-attachment-warnings.el > b/test/emacs-attachment-warnings.el > index a23692d7..8f4918ef 100644 > --- a/test/emacs-attachment-warnings.el > +++ b/test/emacs-attachment-warnings.el > @@ -67,16 +67,15 @@ (defvar attachment-check-tests > > (defun notmuch-test-attachment-warning-1 () >(let (output expected) > -(mapcar (lambda (test) > - (let* ((expect (car test)) > - (body (cdr test)) > - (result (attachment-check-test body))) > - (push expect expected) > - (push (if (eq result expect) > - result > - ;; In the case of a failure, include the test > - ;; details to make it simpler to debug. > - (format "%S <-- %S" result body)) > - output))) > - attachment-check-tests) > +(dolist (test attachment-check-tests) > + (let* ((expect (car test)) > + (body (cdr test)) > + (result (attachment-check-test body))) > + (push expect expected) > + (push (if (eq result expect) > + result > + ;; In the case of a failure, include the test > + ;; details to make it simpler to debug. > + (format "%S <-- %S" result body)) > + output))) > (notmuch-test-expect-equal output expected))) > -- > 2.26.0 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs docstrings: consistent indentation, newlines, periods
Fixed emacs docstrings to be consistent. No functional change. - removed some (accidental) indentation - removed some trailing newlines - added trailing periods where missing (some exclusions) --- V2 of id:"20200503212136.11070-1-tomi.oll...@iki.fi" changes to v1: - trailing periods removed when example code in comments - re-indented (setq's after For example: .. - all 'tree view' consistently uncapitalized now emacs/notmuch-address.el | 21 - emacs/notmuch-draft.el | 6 +-- emacs/notmuch-hello.el | 11 ++--- emacs/notmuch-jump.el| 3 +- emacs/notmuch-lib.el | 8 ++-- emacs/notmuch-maildir-fcc.el | 4 +- emacs/notmuch-mua.el | 2 +- emacs/notmuch-query.el | 13 +++--- emacs/notmuch-show.el| 22 - emacs/notmuch-tag.el | 8 ++-- emacs/notmuch-tree.el| 90 ++-- emacs/notmuch-wash.el| 2 +- emacs/notmuch.el | 34 +++--- 13 files changed, 110 insertions(+), 114 deletions(-) diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el index 64887a43..0d56fba7 100644 --- a/emacs/notmuch-address.el +++ b/emacs/notmuch-address.el @@ -29,11 +29,11 @@ (declare-function company-manual-begin "company") (defvar notmuch-address-last-harvest 0 - "Time of last address harvest") + "Time of last address harvest.") (defvar notmuch-address-completions (make-hash-table :test 'equal) "Hash of email addresses for completion during email composition. - This variable is set by calling `notmuch-address-harvest'.") +This variable is set by calling `notmuch-address-harvest'.") (defvar notmuch-address-full-harvest-finished nil "t indicates that full completion address harvesting has been @@ -73,11 +73,11 @@ (defcustom notmuch-address-internal-completion '(sent nil) "Determines how internal address completion generates candidates. This should be a list of the form '(DIRECTION FILTER), where - DIRECTION is either sent or received and specifies whether the - candidates are searched in messages sent by the user or received - by the user (note received by is much faster), and FILTER is - either nil or a filter-string, such as \"date:1y..\" to append - to the query." +DIRECTION is either sent or received and specifies whether the +candidates are searched in messages sent by the user or received +by the user (note received by is much faster), and FILTER is +either nil or a filter-string, such as \"date:1y..\" to append +to the query." :type '(list :tag "Use internal address completion" (radio :tag "Base completion on messages you have" @@ -126,8 +126,7 @@ (defcustom notmuch-address-post-completion-functions nil The completed address is passed as an argument to each function. Note that this hook will be invoked for completion in headers -matching `notmuch-address-completion-headers-regexp'. -" +matching `notmuch-address-completion-headers-regexp'." :type 'hook :group 'notmuch-address :group 'notmuch-hooks) @@ -147,7 +146,7 @@ (defun notmuch-address-message-insinuate () (message "calling notmuch-address-message-insinuate is no longer needed")) (defcustom notmuch-address-use-company t - "If available, use company mode for address completion" + "If available, use company mode for address completion." :type 'boolean :group 'notmuch-send :group 'notmuch-address) @@ -285,7 +284,7 @@ (defun notmuch-address-harvest-filter (proc string) (defvar notmuch-address-harvest-procs '(nil . nil) "The currently running harvests. -The car is a partial harvest, and the cdr is a full harvest") +The car is a partial harvest, and the cdr is a full harvest.") (defun notmuch-address-harvest (&optional addr-prefix synchronous callback) "Collect addresses completion candidates. diff --git a/emacs/notmuch-draft.el b/emacs/notmuch-draft.el index 504b33be..27abc7d9 100644 --- a/emacs/notmuch-draft.el +++ b/emacs/notmuch-draft.el @@ -76,7 +76,7 @@ (defcustom notmuch-draft-quoted-tags '() (defcustom notmuch-draft-save-plaintext 'ask "Should notmuch save/postpone in plaintext messages that seem - like they are intended to be sent encrypted +like they are intended to be sent encrypted (i.e with an mml encryption tag in it)." :type '(radio (const :tag "Never" nil) @@ -87,10 +87,10 @@ (defcustom notmuch-draft-save-plaintext 'ask (defvar notmuch-draft-encryption-tag-regex "<#\\(part encrypt\\|secure.*mode=.*encrypt>\\)" - "Regular expression matching mml tags indicating encryption of part or message") + "Regular expression matching mml tags indicating encryption of part or message.") (defvar notmuch-draft-id nil - "Message-id of the most recent saved draft of this message") + "Message-id of the most recent saved draft of this message.") (make-variable-buffer-local 'notmuch-draft-id) (defun notmuch-draft--mark-deleted () diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el i
Re: [PATCH] tests: fix test_json_nodes() in out-of-tree builds
On Thu, May 21 2020, Daniel Kahn Gillmor wrote:
> In out-of-tree builds, $TEST_DIRECTORY doesn't contain
> json_check_nodes.py. This caused 27 tests to fail in such an
> environment.
are you shure the run_emacs.sh change in
id:"20200423212643.864-1-tomi.oll...@iki.fi"
is not needed ? =D
Tomi
>
> Signed-off-by: Daniel Kahn Gillmor
> ---
> 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 58972339..792b1cb9 100644
> --- a/test/test-lib.sh
> +++ b/test/test-lib.sh
> @@ -556,7 +556,7 @@ test_json_nodes () {
>
> if ! test_skip "$test_subtest_name"
> then
> - output=$(PYTHONIOENCODING=utf-8 $NOTMUCH_PYTHON
> "$TEST_DIRECTORY"/json_check_nodes.py "$@")
> + output=$(PYTHONIOENCODING=utf-8 $NOTMUCH_PYTHON
> "$NOTMUCH_SRCDIR"/test/json_check_nodes.py "$@")
> if [ "$?" = 0 ]
> then
> test_ok_
> --
> 2.26.2
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs docstrings: consistent indentation, newlines, periods
On Thu, May 21 2020, Daniel Kahn Gillmor wrote:
> On Mon 2020-05-04 00:21:36 +0300, Tomi Ollila wrote:
>> Fixed emacs docstrings to be consistent. No functional change.
>>
>> - removed some (accidental) indentation
>> - removed some trailing newlines
>> - added trailing periods where missing (some exclusions)
>
> This all looks good to me, except for the following changes.
>
> I think if the last line of the docstring is an example, deliberately
> indented to indicate that it is verbatim code, adding a trailing period
> is a mistake, because it encourages naive users to make the obvious
> error of including the period in their text.
>
> These were the examples i noticed in a skim of the changeset:
>
>> --- a/emacs/notmuch-draft.el
>> +++ b/emacs/notmuch-draft.el
>> @@ -45,7 +45,7 @@ (defcustom notmuch-draft-tags '("+draft")
>> For example, if you wanted to give the message a \"draft\" tag
>> but not the (normally added by default) \"inbox\" tag, you would
>> set:
>> -(\"+draft\" \"-inbox\")"
>> +(\"+draft\" \"-inbox\")."
>>:type '(repeat string)
>>:group 'notmuch-draft)
>>
>
>
>> --- a/emacs/notmuch-lib.el
>> +++ b/emacs/notmuch-lib.el
>> @@ -145,7 +145,7 @@ (defcustom notmuch-archive-tags '("-inbox")
>>
>> For example, if you wanted to remove an \"inbox\" tag and add an
>> \"archived\" tag, you would set:
>> -(\"-inbox\" \"+archived\")"
>> +(\"-inbox\" \"+archived\")."
>>:type '(repeat string)
>>:group 'notmuch-search
>>:group 'notmuch-show)
>
>
>> --- a/emacs/notmuch-message.el
>> +++ b/emacs/notmuch-message.el
>> @@ -33,7 +33,7 @@ (defcustom notmuch-message-replied-tags '("+replied")
>>
>> For example, if you wanted to add a \"replied\" tag and remove
>> the \"inbox\" and \"todo\" tags, you would set:
>> -(\"+replied\" \"-inbox\" \"-todo\")"
>> +(\"+replied\" \"-inbox\" \"-todo\")."
>>:type '(repeat string)
>>:group 'notmuch-send)
>>
>> @@ -46,7 +46,7 @@ (defcustom notmuch-message-forwarded-tags '("+forwarded")
>>
>> For example, if you wanted to add a \"forwarded\" tag and remove
>> the \"inbox\" tag, you would set:
>> -(\"+forwarded\" \"-inbox\")"
>> +(\"+forwarded\" \"-inbox\")."
>>:type '(repeat string)
>>:group 'notmuch-send)
>
>
>> --- a/emacs/notmuch-show.el
>> +++ b/emacs/notmuch-show.el
>> @@ -237,7 +237,7 @@ (defcustom notmuch-show-mark-read-tags '("-unread")
>>
>> For example, if you wanted to remove an \"unread\" tag and add a
>> \"read\" tag (which would make little sense), you would set:
>> -(\"-unread\" \"+read\")"
>> +(\"-unread\" \"+read\")."
>>:type '(repeat string)
>>:group 'notmuch-show)
>
>
> I'd prefer this changeset to not have trailing periods when the
> docstring ends in an example. (and maybe also to clean up any trailing
> periods that might already be in such a docstring, if they exist)
>
> I recognize this is something of an aesthetic position with no
> objectively correct answer, but so is the question of trailing periods,
> i suppose. I'm not going to die on this hill, though.
I agree with your point. Like I mentioned I excluded trailing period at
least in one case where missing, probably similar to this. I have to
reconsider also to re-indent some content after For example:
How I did the changeset I used David's rstdoc.el to get long list of all
docstrings and then looked through that and went editing original .el
files -- monotonic changes makes one blind of all kinds of considerations.
>
> Regards,
>
> --dkg
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: test suite: FIXED messages are misordered with tests
On Thu, May 21 2020, Daniel Kahn Gillmor wrote: > On Thu 2020-05-21 00:16:48 +0300, Tomi Ollila wrote: >> (just tested this latest works) > > Thanks for looking into this, Tomi! > > Do you have a patch to propose? Looked a bit (now). Somewhat complicated to make perfect (enemy of good) change. print_test_description could be added as first line in test_known_broken_ok_ (then inconsistent with test_known_broken_failure_) or in test_ok_ just before calling test_known_broken_ok_ (test_known_broken_ok_ is called only once in test-lib.sh) but it looks like test_check_missing_external_prereqs_ and test_report_skip_ may be called before print_test_description is called (and there may be more...) We've accumulated quite a bit of mess during these years to the test system, which makes it harder to do larger adjustments (and not (yet) mentioning even larger refactorings...). > >--dkg Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: test suite: FIXED messages are misordered with tests
On Thu, May 21 2020, Tomi Ollila wrote:
>
> the message that prints FIXED, does not execute print_test_description
> but the ones that do BROKEN or FAIL does (did not fully check but yes).
>
> And:
>
> print_test_description ()
> {
> test -z "$test_description_printed" || return 0
> echo
> echo $this_test: "Testing ${test_description}"
> test_description_printed=1
> }
btw: I would rewrite this function as:
print_test_description ()
{
echo
echo $this_test: "Testing ${test_description}"
print_test_description () { :; }
}
If I wanted to reduce XTRACE noise (even further), even further:
_print_test_description ()
{
echo
echo $this_test: "Testing ${test_description}"
print_test_description=
}
print_test_description=_print_test_description
(and then use $print_test_description in "calls")
or even
alias print_test_description='
echo
echo echo $this_test: "Testing ${test_description}"
alias print_test_description='
(just tested this latest works)
Note on aliases: bash namual states:
For almost every purpose, aliases are superseded by shell functions.
One notable exception is XTRACE noise reduction. In our case best
candidate would be prerequisite work -- but SMOP..
Tomi
> if [ -z "$NOTMUCH_TEST_QUIET" ]
> then
> print_test_description
> fi
>
> Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: test suite: FIXED messages are misordered with tests
On Tue, May 12 2020, Daniel Kahn Gillmor wrote:
> I'm debugging/diagnosing/trying to clean up some "FIXED" known-broken
> tests right now.
>
> Sometimes, depending on circumstances i can't predict (race
> conditions?), I see funny output like:
>
> ~~~
> Use "make V=1" to see the details for passing and known broken tests.
> INFO: using 2m timeout for tests
> INFO: running tests with moreutils parallel
> FIXED verify signed PKCS#7 subject (onepart-signed) signer User ID
>
> T356-protected-headers: Testing Message decryption with protected headers
> BROKEN confirm signed and encrypted PKCS#7 subject (sign+enc)
> BROKEN confirm signed and encrypted PKCS#7 subject (sign+enc) signer User ID
> BROKEN confirm signed and encrypted PKCS#7 subject (sign+enc+legacy-disp)
> BROKEN confirm signed and encrypted PKCS#7 subject (sign+enc+legacy-disp)
> signer User ID
> BROKEN confirm encryption-protected PKCS#7 subject (enc+legacy-disp)
> ~~~
>
> Clearly, that FIXED should come *after* the "T356-protected-headers:"
> separator.
After your second mail I tried to reproduce by taking a test file,
marking one known_broken, even it is not to get FIXED, and then broke
next one.
And I got it reproduced.
the message that prints FIXED, does not execute print_test_description
but the ones that do BROKEN or FAIL does (did not fully check but yes).
And:
print_test_description ()
{
test -z "$test_description_printed" || return 0
echo
echo $this_test: "Testing ${test_description}"
test_description_printed=1
}
if [ -z "$NOTMUCH_TEST_QUIET" ]
then
print_test_description
fi
Tomi
>
> This is a minor bug, i suppose, but i confess i don't understand the
> maze of shell functions in test-lib.sh well enough to see why this is
> happening, let alone to fix it.
>
> Anyone interested in fixing it should be able to do so by marking a good
> test "known broken" and then re-running the test suite. The above
> output is taken from:
>
> make -j4 check NOTMUCH_TESTS=T356-protected-headers.sh
>
> Sorry to send a bug report with no fixes!
>
>--dkg
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: feature request: parameters for reply templates
On Wed, May 13 2020, Jörg Volbers wrote: > OK, seems there is something I do not understand. What do you mean > with "spec in mind"? In this particular case the implementation is probably pretty easy (still SMOP, though), just what exactly should be done is the hard part, to get nice, clean, useable and maintainable solution. Tomi > > JV > > > Tomi Ollila writes: > >> >> Did you have spec in mind ? =D >> ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: feature request: parameters for reply templates
On Tue, May 12 2020, Jörg Volbers wrote: >> My gut reaction is that doing more formatting in notmuch reply >> is probably a mistake; it's hard enough to get two users to >> agree on these kind of customizations, never mind two different >> MUAs. Probably what we need to do is make sure the structured >> (json/s-expr) output has enough information for clients to do >> what they need/want to do. > > I agree, but why not add some switches which allow to turn some > aspects of the reply output on or off? I am thinking here in > particular of the parts which are not plain text. Since not every > mail has an attachment, it makes perfect sense to let the user > decide whether a reply includes a text reference to the > attachment. A simple on-off-switch would be enough. Did you have spec in mind ? =D > > JV > Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2 v2] test-lib: mark function variables as local
On Fri, May 08 2020, Daniel Kahn Gillmor wrote:
> 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 "local" within test-lib.sh so that they do not
> get clobbered when used outside test-lib.
>
> We also move the local variable declarations to beginning of each
> function, to avoid weird gotchas with local variable declarations as
> described in https://tldp.org/LDP/abs/html/localvar.html.
LGTM. I have to tolerate 'we' (passive) as I seem to use those myself, too
(although communicating a bit different thing...) =D
Tomi
> Signed-off-by: Daniel Kahn Gillmor
> ---
> test/test-lib.sh | 31 ++-
> 1 file changed, 22 insertions(+), 9 deletions(-)
>
> diff --git a/test/test-lib.sh b/test/test-lib.sh
> index 5c8eab7c..58972339 100644
> --- a/test/test-lib.sh
> +++ b/test/test-lib.sh
> @@ -109,7 +109,6 @@ unset ALTERNATE_EDITOR
>
> add_gnupg_home ()
> {
> -local output
> [ -e "${GNUPGHOME}/gpg.conf" ] && return
> _gnupg_exit () { gpgconf --kill all 2>/dev/null || true; }
> at_exit_function _gnupg_exit
> @@ -345,13 +344,14 @@ trap 'trap_signal' HUP INT TERM
> # to the message and encrypting/signing.
> emacs_deliver_message ()
> {
> -local subject="$1"
> -local body="$2"
> +local subject body smtp_dummy_pid smtp_dummy_port
> +subject="$1"
> +body="$2"
> shift 2
> # before we can send a message, we have to prepare the FCC maildir
> mkdir -p "$MAIL_DIR"/sent/{cur,new,tmp}
> # eval'ing smtp-dummy --background will set smtp_dummy_pid and -_port
> -local smtp_dummy_pid= smtp_dummy_port=
> +smtp_dummy_pid= smtp_dummy_port=
> eval `$TEST_DIRECTORY/smtp-dummy --background sent_message`
> test -n "$smtp_dummy_pid" || return 1
> test -n "$smtp_dummy_port" || return 1
> @@ -391,13 +391,14 @@ emacs_deliver_message ()
> # new" after message delivery
> emacs_fcc_message ()
> {
> -local nmn_args=''
> +local nmn_args subject body
> +nmn_args=''
> while [[ "$1" =~ ^-- ]]; do
> nmn_args="$nmn_args $1"
> shift
> done
> -local subject="$1"
> -local body="$2"
> +subject="$1"
> +body="$2"
> shift 2
> # before we can send a message, we have to prepare the FCC maildir
> mkdir -p "$MAIL_DIR"/sent/{cur,new,tmp}
> @@ -427,6 +428,7 @@ emacs_fcc_message ()
> # number of messages.
> add_email_corpus ()
> {
> +local corpus
> corpus=${1:-default}
>
> rm -rf ${MAIL_DIR}
> @@ -457,6 +459,7 @@ test_begin_subtest ()
> # name.
> test_expect_equal ()
> {
> + local output expected testname
> exec 1>&6 2>&7 # Restore stdout and stderr
> if [ -z "$inside_subtest" ]; then
> error "bug in the test script: test_expect_equal without
> test_begin_subtest"
> @@ -483,6 +486,7 @@ test_expect_equal ()
> # Like test_expect_equal, but takes two filenames.
> test_expect_equal_file ()
> {
> + local file1 file2 testname basename1 basename2
> exec 1>&6 2>&7 # Restore stdout and stderr
> if [ -z "$inside_subtest" ]; then
> error "bug in the test script: test_expect_equal_file without
> test_begin_subtest"
> @@ -512,10 +516,11 @@ test_expect_equal_file ()
> # canonicalized before diff'ing. If an argument cannot be parsed, it
> # is used unchanged so that there's something to diff against.
> test_expect_equal_json () {
> +local script output expected
> # The test suite forces LC_ALL=C, but this causes Python 3 to
> # decode stdin as ASCII. We need to read JSON in UTF-8, so
> # override Python's stdio encoding defaults.
> -local script='import json, sys; json.dump(json.load(sys.stdin),
> sys.stdout, sort_keys=True, indent=4)'
> +script='import json, sys; json.dump(json.load(sys.stdin), sys.stdout,
> sort_keys=True, indent=4)'
> output=$(echo "$1" | PYTHONIOENCODING=utf-8 $NOTMUCH_PYTHON -c "$script"
> \
> || echo "$1")
> expected=$(echo "$2" | PYTHONIOENCODING=utf-8 $NOTMUCH_PYTHON -c
> "$script" \
> @@ -540,6 +545,7 @@ test_sort_json () {
> # read the source of test/json_check_nodes.py (or the output when
> # invoking it without arguments) for an explanation of the syntax.
> test_json_nodes () {
> +local output
> exec 1>&6 2>&7 # Restore stdout and stderr
> if [ -z "$inside_subtest" ]; then
> error "bug in the test script: test_json_eval without
> test_begin_subtest"
> @@ -561,6 +567,7 @@ test_json_nodes () {
> }
>
> test_emacs_expect_t () {
> + local result
> test "$#" = 1 ||
> error "bug in the test script: not 1 parameter to test_emacs_expect_t"
> if [ -z "$inside_subtest" ]; then
> @@ -653,7 +660,8 @@ notmuch_json_show_sanitize (
Re: [PATCH 2/2] smime: tests of X.509 certificate validity are known-broken on GMime < 3.2.7
On Wed, May 06 2020, Daniel Kahn Gillmor wrote:
> 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 the consumer of notmuch's
> cryptographic summary of a message (or of its protected headers) can
> be confident in relaying the reported identity to the user.
>
> However, some versions of GMime before 3.2.7 cannot report Certificate
> validity for X.509 certificates. This is resolved upstream in GMime
> at https://github.com/jstedfast/gmime/pull/90.
>
> 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.
>
> If GMime >= 3.2.7 and certificate validity still doesn't work for
> X.509 certs, then there has likely been a regression in GMime and we
> should fail early, during ./configure.
>
> To break out these specific User ID checks from other checks, i had to
> split some tests into two parts, and reuse $output across the two
> subtests.
This works, on top of the previous series -- I skipped git am:ing 1/2,
so thos works without it -- it is good stuff just IMO requires some changes)
Tomi
>
> Signed-off-by: Daniel Kahn Gillmor
> ---
> configure | 79 ++
> test/T355-smime.sh | 19 +---
> test/T356-protected-headers.sh | 15 ++-
> 3 files changed, 104 insertions(+), 9 deletions(-)
>
> diff --git a/configure b/configure
> index 0cfdaa6f..92e5bd1b 100755
> --- a/configure
> +++ b/configure
> @@ -536,6 +536,82 @@ EOF
> if [ -n "$TEMP_GPG" -a -d "$TEMP_GPG" ]; then
> rm -rf "$TEMP_GPG"
> fi
> +
> +# see https://github.com/jstedfast/gmime/pull/90
> +# should be fixed in GMime in 3.2.7, but some distros might patch
> +printf "Checking for GMime X.509 certificate validity... "
> +
> +cat > _check_x509_validity.c < +#include
> +#include
> +
> +int main () {
> +GError *error = NULL;
> +GMimeParser *parser = NULL;
> +GMimeApplicationPkcs7Mime *body = NULL;
> +GMimeSignatureList *sig_list = NULL;
> +GMimeSignature *sig = NULL;
> +GMimeCertificate *cert = NULL;
> +GMimeObject *output = NULL;
> +GMimeValidity validity = GMIME_VALIDITY_UNKNOWN;
> +int len;
> +
> +g_mime_init ();
> +parser = g_mime_parser_new ();
> +g_mime_parser_init_with_stream (parser,
> g_mime_stream_file_open("test/corpora/pkcs7/smime-onepart-signed.eml", "r",
> &error));
> +if (error) return !! fprintf (stderr, "failed to instantiate parser with
> test/corpora/pkcs7/smime-onepart-signed.eml\n");
> +
> +body = GMIME_APPLICATION_PKCS7_MIME(g_mime_message_get_mime_part
> (g_mime_parser_construct_message (parser, NULL)));
> +if (body == NULL) return !! fprintf (stderr, "did not find a
> application/pkcs7 message\n");
> +
> +sig_list = g_mime_application_pkcs7_mime_verify (body,
> GMIME_VERIFY_NONE, &output, &error);
> +if (error || output == NULL) return !! fprintf (stderr, "verify
> failed\n");
> +
> +if (sig_list == NULL) return !! fprintf (stderr, "no GMimeSignatureList
> found\n");
> +len = g_mime_signature_list_length (sig_list);
> +if (len != 1) return !! fprintf (stderr, "expected 1 signature, got
> %d\n", len);
> +sig = g_mime_signature_list_get_signature (sig_list, 0);
> +if (sig == NULL) return !! fprintf (stderr, "no GMimeSignature found at
> position 0\n");
> +cert = g_mime_signature_get_certificate (sig);
> +if (cert == NULL) return !! fprintf (stderr, "no GMimeCertificate
> found\n");
> +validity = g_mime_certificate_get_id_validity (cert);
> +if (validity != GMIME_VALIDITY_FULL) return !! fprintf (stderr, "Got
> validity %d, expected %d\n", validity, GMIME_VALIDITY_FULL);
> +
> +return 0;
> +}
> +EOF
> +if ! TEMP_GPG=$(mktemp -d "${TMPDIR:-/tmp}/notmuch.XX"); then
> +printf 'No.\nCould not make tempdir for testing X.509 certificate
> validity support.\n'
> +errors=$((errors + 1))
> +elif ${CC} ${CFLAGS} ${gmime_cflags} _check_x509_validity.c
> ${gmime_ldflags} -o _check_x509_validity \
> +&& echo disable-crl-checks > "$TEMP_GPG/gpgsm.conf" \
> +&& echo
> "4D:E0:FF:63:C0:E9:EC:01:29:11:C8:7A:EE:DA:3A:9A:7F:6E:C1:0D S" >>
> "$TEMP_GPG/trustlist.txt" \
> +&& GNUPGHOME=${TEMP_GPG} gpgsm --batch --quiet --import <
> "$srcdir"/test/smime/ca.crt
> +then
> +if GNUPGHOME=${TEMP_GPG} ./_check_x509_validity; then
> +gmime_x509_cert_validity=1
> +printf "Yes.\n"
> +else
> +gmime_x509_cert_validity=0
> +printf "No.\n"
> +if pkg-config --exists "gmime-3.0 >= 3.2.7"; then
> +cat < +*** Error: GMime fails to calculate X.509 certificate validity,
Re: [PATCH 1/2] test-lib: mark function variables as local
On Wed, May 06 2020, Daniel Kahn Gillmor wrote:
> 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 "local" within test-lib.sh so that they do not
> get clobbered when used outside test-lib.
Good stuff
robustness comment IMO:
There is slight difference when writing
local foo=`false`
and
local foo; foo=`false`
former does not "fail"; latter does,
Although there is (currently!) no difference in our test code
(we don't have `set -e` there, IMO the former serves as a bad
example for anyone looking the code.
(same applies to export foo=`bar`, readonly foo=`bar` and so
on, for anyone curious...)
IMO better declare all local variables in one line separately,
e.g.
local output expected
and then either
output=$1
expected=$2
or
output=$1 expected=$2
( FYI: exection latter in shell differs in a way one could do
output=$expected expected=$output ) (IIRC, did not test >;)
(add double quotes around $1 and $2 if you desire =D)
well, when doing change just add the `local` line, smaller diff :)
Tomi
>
> Signed-off-by: Daniel Kahn Gillmor
> ---
> test/test-lib.sh | 44 ++--
> 1 file changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/test/test-lib.sh b/test/test-lib.sh
> index 5c8eab7c..e8feab3b 100644
> --- a/test/test-lib.sh
> +++ b/test/test-lib.sh
> @@ -109,7 +109,6 @@ unset ALTERNATE_EDITOR
>
> add_gnupg_home ()
> {
> -local output
> [ -e "${GNUPGHOME}/gpg.conf" ] && return
> _gnupg_exit () { gpgconf --kill all 2>/dev/null || true; }
> at_exit_function _gnupg_exit
> @@ -427,7 +426,7 @@ emacs_fcc_message ()
> # number of messages.
> add_email_corpus ()
> {
> -corpus=${1:-default}
> +local corpus=${1:-default}
>
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Handle PKCS#7 S/MIME messages
On Mon, May 04 2020, Daniel Kahn Gillmor wrote:
> Hi Tomi--
>
> On Sat 2020-05-02 00:15:57 +0300, Tomi Ollila wrote:
>> I did not see anything suspicious in code, but
>>
>> I got these test failures:
>>
>> in ubuntu 19.10 native environment, and
>>
>> in debian 10 (podman) container running in fedora 31 system
>>
>>
>> T355-smime: Testing S/MIME signature verification and decryption
>> FAIL Verify signature on PKCS#7 SignedData message
>> crypto: value not equal: data[0][0][0]["crypto"]["signed"]["status"][0] =
>> {'status': 'good',
>> 'fingerprint': '702BA4B157F1E2B7D16B0C6A5FFC8A7DE2057DEB',
>> 'created': 1574813489,
>> 'expires': 2611032858} !=
>> {'created': 1574813489,
>> 'expires': 2611032858,
>> 'fingerprint': '702BA4B157F1E2B7D16B0C6A5FFC8A7DE2057DEB',
>> 'userid': 'CN=Alice Lovelace',
>> 'status': 'good'}
>>
>> T356-protected-headers: Testing Message decryption with protected headers
>> FAIL verify signed PKCS#7 subject (multipart-signed)
>> sig_uid: object not found:
>> data[0][0][0]["crypto"]["signed"]["status"][0]["userid"]
>> FAIL verify signed PKCS#7 subject (onepart-signed)
>> sig_uid: object not found:
>> data[0][0][0]["crypto"]["signed"]["status"][0]["userid"]
>> FAIL confirm signed and encrypted PKCS#7 subject (sign+enc)
>> sig_uid: object not found:
>> data[0][0][0]["crypto"]["signed"]["status"][0]["userid"]
>> FAIL confirm signed and encrypted PKCS#7 subject (sign+enc+legacy-disp)
>> sig_uid: object not found:
>> data[0][0][0]["crypto"]["signed"]["status"][0]["userid"]
>
> Thanks for identifying these. These are problems related to a bug in
> the released version of GMime on those platforms. Unfixed versions of
> gmime cannot report *any* certificate validity for X.509 certificates:
>
>https://github.com/jstedfast/gmime/pull/90
>
> The fix for gmime is pretty simple, but it's not something we can
> address directly in notmuch.
>
> The fix was first released in GMime version 3.2.7, but it was first in
> debian in gmime 3.2.6-2, and should be relatively easy to backport for
> any distro that wants it (i suppose i could probably get it into the
> next point release for debian 10 as well, since it is a bugfix for an
> already-exposed API).
>
> So, how should we deal with this in notmuch? It seems a bit silly to
> bump our required version of gmime to the (relatively new) version
> 3.2.7, for a fix for a cornercase of a novel use case.
>
> Maybe the test suite should change based on version of GMime? That
> would cause problems for distros that backport the GMime fix, though.
>
> I guess i could write a reproducer for the gmime issue and we could
> include it in ./configure, and modify the test suite on that basis.
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?
>
> --dkg
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] test: known broken test for reindex tag preservation
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 Haa, I looked this briefly but failed to see it is STRNCMP_LITERAL, not STRCMP_LITERAL (the latter could be optimized strcmp using memcmp w/ constant len) Series LGTM (I'm trying to look away that 'we' passive ;) Tomi > _notmuch_message_remove_indexed_terms. > --- > test/T700-reindex.sh | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/test/T700-reindex.sh b/test/T700-reindex.sh > index 9e795896..7b7e52de 100755 > --- a/test/T700-reindex.sh > +++ b/test/T700-reindex.sh > @@ -33,6 +33,15 @@ notmuch reindex '*' > notmuch dump > OUTPUT > test_expect_equal_file initial-dump OUTPUT > > +test_begin_subtest 'reindex preserves tags with special prefixes' > +test_subtest_known_broken > +notmuch tag +attachment2 +encrypted2 +signed2 '*' > +notmuch dump > EXPECTED > +notmuch reindex '*' > +notmuch dump > OUTPUT > +notmuch tag -attachment2 -encrypted2 -signed2 '*' > +test_expect_equal_file EXPECTED OUTPUT > + > test_begin_subtest 'reindex moves a message between threads' > notmuch search --output=threads id:87iqd9rn3l.fsf@vertex.dottedmag > EXPECTED > # re-parent > -- > 2.26.2 > > ___ > notmuch mailing list > notmuch@notmuchmail.org > https://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs docstrings: consistent indentation, newlines, periods
Fixed emacs docstrings to be consistent. No functional change.
- removed some (accidental) indentation
- removed some trailing newlines
- added trailing periods where missing (some exclusions)
---
emacs/notmuch-address.el | 21 -
emacs/notmuch-draft.el | 8 ++--
emacs/notmuch-hello.el | 11 ++---
emacs/notmuch-jump.el| 3 +-
emacs/notmuch-lib.el | 10 ++--
emacs/notmuch-maildir-fcc.el | 4 +-
emacs/notmuch-message.el | 4 +-
emacs/notmuch-mua.el | 2 +-
emacs/notmuch-query.el | 13 +++---
emacs/notmuch-show.el| 24 +-
emacs/notmuch-tag.el | 8 ++--
emacs/notmuch-tree.el| 88 ++--
emacs/notmuch-wash.el| 2 +-
emacs/notmuch.el | 34 +++---
14 files changed, 114 insertions(+), 118 deletions(-)
diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
index 64887a43..0d56fba7 100644
--- a/emacs/notmuch-address.el
+++ b/emacs/notmuch-address.el
@@ -29,11 +29,11 @@
(declare-function company-manual-begin "company")
(defvar notmuch-address-last-harvest 0
- "Time of last address harvest")
+ "Time of last address harvest.")
(defvar notmuch-address-completions (make-hash-table :test 'equal)
"Hash of email addresses for completion during email composition.
- This variable is set by calling `notmuch-address-harvest'.")
+This variable is set by calling `notmuch-address-harvest'.")
(defvar notmuch-address-full-harvest-finished nil
"t indicates that full completion address harvesting has been
@@ -73,11 +73,11 @@ (defcustom notmuch-address-internal-completion '(sent nil)
"Determines how internal address completion generates candidates.
This should be a list of the form '(DIRECTION FILTER), where
- DIRECTION is either sent or received and specifies whether the
- candidates are searched in messages sent by the user or received
- by the user (note received by is much faster), and FILTER is
- either nil or a filter-string, such as \"date:1y..\" to append
- to the query."
+DIRECTION is either sent or received and specifies whether the
+candidates are searched in messages sent by the user or received
+by the user (note received by is much faster), and FILTER is
+either nil or a filter-string, such as \"date:1y..\" to append
+to the query."
:type '(list :tag "Use internal address completion"
(radio
:tag "Base completion on messages you have"
@@ -126,8 +126,7 @@ (defcustom notmuch-address-post-completion-functions nil
The completed address is passed as an argument to each function.
Note that this hook will be invoked for completion in headers
-matching `notmuch-address-completion-headers-regexp'.
-"
+matching `notmuch-address-completion-headers-regexp'."
:type 'hook
:group 'notmuch-address
:group 'notmuch-hooks)
@@ -147,7 +146,7 @@ (defun notmuch-address-message-insinuate ()
(message "calling notmuch-address-message-insinuate is no longer needed"))
(defcustom notmuch-address-use-company t
- "If available, use company mode for address completion"
+ "If available, use company mode for address completion."
:type 'boolean
:group 'notmuch-send
:group 'notmuch-address)
@@ -285,7 +284,7 @@ (defun notmuch-address-harvest-filter (proc string)
(defvar notmuch-address-harvest-procs '(nil . nil)
"The currently running harvests.
-The car is a partial harvest, and the cdr is a full harvest")
+The car is a partial harvest, and the cdr is a full harvest.")
(defun notmuch-address-harvest (&optional addr-prefix synchronous callback)
"Collect addresses completion candidates.
diff --git a/emacs/notmuch-draft.el b/emacs/notmuch-draft.el
index 504b33be..531666d0 100644
--- a/emacs/notmuch-draft.el
+++ b/emacs/notmuch-draft.el
@@ -45,7 +45,7 @@ (defcustom notmuch-draft-tags '("+draft")
For example, if you wanted to give the message a \"draft\" tag
but not the (normally added by default) \"inbox\" tag, you would
set:
-(\"+draft\" \"-inbox\")"
+(\"+draft\" \"-inbox\")."
:type '(repeat string)
:group 'notmuch-draft)
@@ -76,7 +76,7 @@ (defcustom notmuch-draft-quoted-tags '()
(defcustom notmuch-draft-save-plaintext 'ask
"Should notmuch save/postpone in plaintext messages that seem
- like they are intended to be sent encrypted
+like they are intended to be sent encrypted
(i.e with an mml encryption tag in it)."
:type '(radio
(const :tag "Never" nil)
@@ -87,10 +87,10 @@ (defcustom notmuch-draft-save-plaintext 'ask
(defvar notmuch-draft-encryption-tag-regex
"<#\\(part encrypt\\|secure.*mode=.*encrypt>\\)"
- "Regular expression matching mml tags indicating encryption of part or
message")
+ "Regular expression matching mml tags indicating encryption of part or
message.")
(defvar notmuch-draft-id nil
- "Message-id of the most recent saved draft of this message")
+ "Message-id of the most recent saved draft of this message.")
(make-variable-buffer
Re: Handle PKCS#7 S/MIME messages
On Thu, Apr 30 2020, Daniel Kahn Gillmor wrote:
> This series applies after the "Add tests for S/MIME PKCS#7 messages"
> series, which was introduced in
> id:20200428185723.660184-1-...@fifthhorseman.net
>
> With this series applied, notmuch handles standard PKCS#7 S/MIME
> messages (using GnuPG's gpgsm as a backend, as mediated by GMime's use
> of GPGME) as well as it handles PGP/MIME messages.
>
> In addition to showing and replying to these messages, the series
> covers indexing the cleartext of encrypted messages, and understanding
> protected headers.
I did not see anything suspicious in code, but
I got these test failures:
in ubuntu 19.10 native environment, and
in debian 10 (podman) container running in fedora 31 system
T355-smime: Testing S/MIME signature verification and decryption
FAIL Verify signature on PKCS#7 SignedData message
crypto: value not equal: data[0][0][0]["crypto"]["signed"]["status"][0] =
{'status': 'good',
'fingerprint': '702BA4B157F1E2B7D16B0C6A5FFC8A7DE2057DEB',
'created': 1574813489,
'expires': 2611032858} !=
{'created': 1574813489,
'expires': 2611032858,
'fingerprint': '702BA4B157F1E2B7D16B0C6A5FFC8A7DE2057DEB',
'userid': 'CN=Alice Lovelace',
'status': 'good'}
T356-protected-headers: Testing Message decryption with protected headers
FAIL verify signed PKCS#7 subject (multipart-signed)
sig_uid: object not found:
data[0][0][0]["crypto"]["signed"]["status"][0]["userid"]
FAIL verify signed PKCS#7 subject (onepart-signed)
sig_uid: object not found:
data[0][0][0]["crypto"]["signed"]["status"][0]["userid"]
FAIL confirm signed and encrypted PKCS#7 subject (sign+enc)
sig_uid: object not found:
data[0][0][0]["crypto"]["signed"]["status"][0]["userid"]
FAIL confirm signed and encrypted PKCS#7 subject (sign+enc+legacy-disp)
sig_uid: object not found:
data[0][0][0]["crypto"]["signed"]["status"][0]["userid"]
>
> --dkg
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 15/15] tests: disable CRL checks from gpgsm
On Tue, Apr 28 2020, Daniel Kahn Gillmor wrote: > GPGME has a strange failure mode when it is in offline mode, and/or > when certificates don't have any CRLs: in particular, it refuses to > accept the validity of any certificate other than a "root" cert. > > This can be worked around by setting the `disable-crl-checks` > configuration variable for gpgsm. > > I've reported this to the GPGME upstream at > https://dev.gnupg.org/T4883, but I have no idea how it will be > resolved. In the meantime, we'll just work around it. > > Note that this fixes the test for verification of > id:smime-multipart-signed@protected-headers.example, because > multipart/signed messages are already handled correctly (one-part > PKCS#7 messages will get fixed later). > > Signed-off-by: Daniel Kahn Gillmor Rest of the series look tolerable to me. That one missing "inconsistent quotes" is inconsistent with added quotes in one of the changes in previous email (which just did that) Otherwise OK (provided that tests pass) (except that https://www.ietf.org/id/draft-dkg-lamps-samples-01.html if not found (by me either, like David) Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 08/15] tests/smime: include secret key material for Bob
On Tue, Apr 28 2020, Daniel Kahn Gillmor wrote: > This is taken from the same Internet Draft that test/smime/ca.crt > comes from. See that draft for more details. > https://www.ietf.org/id/draft-dkg-lamps-samples-02.html#name-pkcs12-object-for-bob > > We don't use it yet, but it will be used to decrypt other messages in > the test suite. > > Note that we include it here with an empty passphrase, rather than > with the passphrase "bob" that it is supplied with in the I-D. The > underlying cryptographic material is the same, but this way we can > import cleanly into gpgsm without having a passphrase set on it (gpgsm > converts an empty-string passphrase into no passphrase at all on > import). > > Signed-off-by: Daniel Kahn Gillmor > --- // stuff deleted // > diff --git a/test/test-lib.sh b/test/test-lib.sh > index d9997b27..dd7fdfaa 100644 > --- a/test/test-lib.sh > +++ b/test/test-lib.sh > @@ -145,6 +145,8 @@ add_gpgsm_home () > gpgsm --quiet --batch --no-tty --no-common-certs-import > --disable-dirmngr --import < $NOTMUCH_SRCDIR/test/smime/ca.crt > echo "4D:E0:FF:63:C0:E9:EC:01:29:11:C8:7A:EE:DA:3A:9A:7F:6E:C1:0D S" >> > "$GNUPGHOME/trustlist.txt" > echo include-certs::1 | gpgconf --output /dev/null --change-options gpgsm > +gpgsm --batch --no-tty --no-common-certs-import --pinentry-mode=loopback > --passphrase-fd 3 \ > + --disable-dirmngr --import $NOTMUCH_SRCDIR/test/smime/bob.p12 > >>"$GNUPGHOME"/import.log 2>&1 3<<<'' Now that I started w/ consistenly quotes -- "$NOTMUCH_SRCDIR/..." Or maybe not, is this variable consistently unquoted -- or something ;) Tomi > test_debug "cat $GNUPGHOME/import.log" > } > > -- > 2.26.2 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 07/15] test: Allow tests to have both gpg and gpgsm active at once
On Tue, Apr 28 2020, Daniel Kahn Gillmor wrote:
> Without this fix, we couldn't run both add_gnupg_home and
> add_gpgsm_home in the same test script.
>
> Signed-off-by: Daniel Kahn Gillmor
> ---
> test/test-lib.sh | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/test/test-lib.sh b/test/test-lib.sh
> index ac1b9315..d9997b27 100644
> --- a/test/test-lib.sh
> +++ b/test/test-lib.sh
> @@ -110,10 +110,10 @@ unset ALTERNATE_EDITOR
> add_gnupg_home ()
> {
> local output
> -[ -d ${GNUPGHOME} ] && return
> +[ -e ${GNUPGHOME}/gpg.conf ] && return
So far so good (except perhaps David's comment not "url" not found)
But here this change could include "consistently quoted" variable
(or/and have it done in that one commit earlier...)
So LGTM 1-7, provided that tests pass...
Tomi
> _gnupg_exit () { gpgconf --kill all 2>/dev/null || true; }
> at_exit_function _gnupg_exit
> -mkdir -m 0700 "$GNUPGHOME"
> +mkdir -p -m 0700 "$GNUPGHOME"
> gpg --no-tty --import <$NOTMUCH_SRCDIR/test/gnupg-secret-key.asc
> >"$GNUPGHOME"/import.log 2>&1
> test_debug "cat $GNUPGHOME/import.log"
> if (gpg --quick-random --version >/dev/null 2>&1) ; then
> @@ -132,10 +132,10 @@ add_gnupg_home ()
> add_gpgsm_home ()
> {
> local fpr
> -[ -d "$GNUPGHOME" ] && return
> +[ -e "$GNUPGHOME/gpgsm.conf" ] && return
> _gnupg_exit () { gpgconf --kill all 2>/dev/null || true; }
> at_exit_function _gnupg_exit
> -mkdir -m 0700 "$GNUPGHOME"
> +mkdir -p -m 0700 "$GNUPGHOME"
> openssl pkcs12 -export -passout pass: -inkey
> "$NOTMUCH_SRCDIR/test/smime/key+cert.pem" \
> < "$NOTMUCH_SRCDIR/test/smime/test.crt" | \
> gpgsm --batch --no-tty --no-common-certs-import
> --pinentry-mode=loopback --passphrase-fd 3 \
> --
> 2.26.2
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Inconsistencies in handling command flags: `--flag=value` different than `--flag value`
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 --booloption=false instead. Once they're dropped, allow whitespace > between "--booloption true" and "--booloption false" just like every > other type of option. I must say, being it perhaps slightly inconvenient to the user, that this is IMO the best option, and just allowing 'true' and 'false' (case-sensitively). Least chance to work how used did not expected... > in case it's not clear: I believe that "we have succinct and yet > complete man pages" is a convenient shorthand for "have we made this > command-line program behave in an understandable/usable way?" Sounds/looks like reasonable expectation... > >--dkg Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Inconsistencies in handling command flags: `--flag=value` different than `--flag value`
On Mon, Apr 27 2020, Daniel Kahn Gillmor wrote: > On Mon 2020-04-27 14:53:07 -0300, David Bremner wrote: >> Quoting notmuch(1) >> >>OPTION SYNTAX >>All options accepting an argument can be used with '=' >>or ':' as a separator. For the cases where it's not ambiguous >>(in particular excluding boolean options), a space can also be >>used. > > This is a pretty twisty way to say what we mean. Are there other cases > besides boolean options? If there are, perhaps it'd be clearer to say > something like this for the last sentence: > > Except for boolean options and other potential ambiguous cases, a > space can also be used as a separator. > > If there aren't, we could say: > > Except for boolean options (which would be ambiguous), a space can > also be used as a separator. > > Alternately, we could deprecate using whitespace for all options, > produce explicit warnings to stderr when whitespace appears on the next was it so, that originally we did not support whitespace, but David added that in some commit... > release, remove the suggestion to use a whitespace separator from the > documentation, and eventually phase it out entirely in some future > release. Alternatively we could check that next arg is (case-insensitively) (subset of) 'true', 'false', 'yes', 'no', '0', '1', 't', 'nil' (but not tpyoes of these ;) and in that case have that as an option value... ... would that work better for human user who just wants to be fluent on command line -- frontends can then always use = and option values... > --dkg Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] util/zlib-extra: de-inline gzerror_str
On Mon, Apr 27 2020, David Bremner wrote:
> 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 we don't actually care about the
> performance of this function, just use a non-inline function.
LGTM.
Tomi
> ---
> util/zlib-extra.c | 7 +++
> util/zlib-extra.h | 4 ++--
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/util/zlib-extra.c b/util/zlib-extra.c
> index 2d2d2414..3a75e504 100644
> --- a/util/zlib-extra.c
> +++ b/util/zlib-extra.c
> @@ -85,3 +85,10 @@ gz_error_string (util_status_t status, gzFile file)
> else
> return util_error_string (status);
> }
> +
> +const char *
> +gzerror_str(gzFile file)
> +{
> +int dummy;
> +return gzerror (file, &dummy);
> +}
> diff --git a/util/zlib-extra.h b/util/zlib-extra.h
> index 296dc914..e9925c98 100644
> --- a/util/zlib-extra.h
> +++ b/util/zlib-extra.h
> @@ -29,8 +29,8 @@ gz_error_string (util_status_t status, gzFile stream);
>
> /* Call gzerror with a dummy errno argument, the docs don't promise to
> * support the NULL case */
> -inline const char *
> -gzerror_str(gzFile file) { int dummy; return gzerror (file, &dummy); }
> +const char *
> +gzerror_str(gzFile file);
>
> #ifdef __cplusplus
> }
> --
> 2.26.2
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: test_emacs_expect_t does ignore Emacs as prerequisite
On Fri, Apr 24 2020, David Bremner wrote:
> 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, but I'm not sure this is the best/cleanest
> fix. Maybe Tomi (in Cc) can comment. The logic for prerequisite checking
> is already opaque. For example test_skip is already calling
> test_check_missing_external_prereqs_ as a side effect. For starters I
> wonder if test_emacs should use a return value to indicate failure,
> along the lines of the patch at the end of the message.
I'd like David's approach, but in that case we don't get the
"missing prerequisities" messages. Milton's solution looks like
something that works =D.
Just that the content inside {} needs to be indented, and opening
brace ({) should be after || in same line...
In case of test_skip it doesn't know about missing emacs prerequisities
as the "subtest prerequisities" infomation is cleaned before every
test and the information is regained in test_emacs...
Tomi
> BTW, it will make our life easier if you follow
> https://notmuchmail.org/contributing/#index5h2; in particular using
> git-send-email and keeping the discussion/notes after ---.
>
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] test/test-lib.sh: fix two out of tree test issues
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.
When creating run_emacs.sh make it load .elc files from out of
tree build tree, not from source tree if such files existed.
If existed, those may be outdated, or even created by some other
emacs than the one that was used to build .elc files in out of
tree build dir.
---
Noticed latter when did in-tree build on Fedora 31 host, then
out-of-tree build running Ubuntu 18.04 in (podman) container;
Fedora had Emacs 26, and ubuntu emacs 25 -- got bytecode
errors...
test/test-lib.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 7f8a3a4d..f9b7d866 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -523,7 +523,7 @@ test_json_nodes () {
if ! test_skip "$test_subtest_name"
then
- output=$(PYTHONIOENCODING=utf-8 $NOTMUCH_PYTHON
"$TEST_DIRECTORY"/json_check_nodes.py "$@")
+ output=$(PYTHONIOENCODING=utf-8 $NOTMUCH_PYTHON -B
"$NOTMUCH_SRCDIR"/test/json_check_nodes.py "$@")
if [ "$?" = 0 ]
then
test_ok_
@@ -984,7 +984,7 @@ export NOTMUCH_CONFIG=$NOTMUCH_CONFIG
# --load Force loading of notmuch.el and test-lib.el
exec ${TEST_EMACS} --quick \
- --directory "$NOTMUCH_SRCDIR/emacs" --load notmuch.el \
+ --directory "$NOTMUCH_BUILDDIR/emacs" --load notmuch.el \
--directory "$NOTMUCH_SRCDIR/test" --load test-lib.el \
"\$@"
EOF
--
2.25.3
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] configure: disable features that do not work out of tree
When doing out of tree build,
- sphinx-build cannot collect source files from source code
directory and generated files from build directory.
- python3-cffi did not work, did not investigate further.
In order to get at least something done out of tree, these
features are disabled when doing out of tree builds. The output
is still useful if these features are not needed, and helps with
e.g. test output comparisons.
---
configure | 9 +
1 file changed, 9 insertions(+)
diff --git a/configure b/configure
index 70031d14..8c2c9b72 100755
--- a/configure
+++ b/configure
@@ -70,6 +70,10 @@ if [ "$srcdir" != "." ]; then
mkdir bindings/ruby
cp -a "$srcdir"/bindings/ruby/*.[ch] bindings/ruby
cp -a "$srcdir"/bindings/ruby/extconf.rb bindings/ruby
+
+out_of_tree_build=1
+else
+out_of_tree_build=0
fi
# Set several defaults (optionally specified by the user in
@@ -1089,6 +1093,11 @@ printf "\n\t%s\n" "${WARN_CFLAGS}"
rm -f minimal minimal.c _libversion.c _libversion _libversion.sh
_check_session_keys.c _check_session_keys
+if [ "$out_of_tree_build" = 1 ]; then
+ printf '\n*** Out of tree build: disabling sphinx docs, python3-cffi ***\n'
+ have_sphinx=0 have_python3_cffi=0
+fi
+
# construct the Makefile.config
cat > Makefile.config
Re: Database path discovery in bindings
On Sun, Apr 19 2020, Kirill Elagin wrote: > Hello, > > Notmuch contains a bit of logic for “normalising” the database path: it can > be relative to $HOME and fallsback to $MAILDIR or $HOME/mail. However, this > logic is implemented in `notmuch_config_open` and is not available through > bindings. So if a third-party tool wants to discover the database, it will > either do this incorrectly ([alot]) or will have to roll its own > implementation ([afew]). Neither option is good. > > [alot]: https://github.com/pazz/alot/issues/1396 > [afew]: https://github.com/afewmail/afew/pull/233 > > Rather than reimplementing it in bindings, I see two possible solutions: > > 1. Move the logic to `notmuch_database_open` itself. > 2. Extract into a separate C function, use it in `notmuch_config_open`, and > expose through bindings. > > What do you think? There has been thoughts to dump the configuration file, and put the configuration to the database -- so then the bindings can just open the database to find the configuration oh wait... In this case we'd find the database in $NOTMUCH_DATABASE_DIR[ECTORY?] or in $HOME/mail/.notmuch/... if that env var did not exist. There are at least 2 issues to solve with this approach: 1: SMOP 2: how to edit the configuration using text editor (preserving comments), i.e. export and import functionality 3. review latency (especially w/ large patches...) ;/ > > Cheers, > Kirill Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2] build: drop support for xapian versions less than 1.4
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
but user may want to disable retry locking at configure time so it
is kept.
---
This is v2 of id:2020022955.6795-1-tomi.oll...@iki.fi
Change to v1: restored known_broken indication of that one test which
*is* known broken when tried with xapian 1.4...
doc/man7/notmuch-search-terms.rst was not changed in this commit --
I did not fully understand what was it saying...
configure| 101 +++
lib/built-with.c | 4 +-
lib/database.cc | 10
lib/parse-time-vrp.cc| 2 -
lib/parse-time-vrp.h | 3 +-
lib/query-fp.cc | 3 --
lib/query-fp.h | 3 +-
lib/regexp-fields.cc | 2 -
lib/regexp-fields.h | 4 +-
lib/thread-fp.cc | 3 --
lib/thread-fp.h | 3 +-
test/T020-compact.sh | 12 -
test/T500-search-date.sh | 3 --
test/T585-thread-subquery.sh | 12 -
test/T600-named-queries.sh | 6 ---
test/T650-regexp-query.sh| 4 --
test/T670-duplicate-mid.sh | 6 +--
17 files changed, 28 insertions(+), 153 deletions(-)
diff --git a/configure b/configure
index 70031d14..0cfdaa6f 100755
--- a/configure
+++ b/configure
@@ -422,15 +422,22 @@ else
have_pkg_config=0
fi
-printf "Checking for Xapian development files... "
+
+
+printf "Checking for Xapian development files (>= 1.4.0)... "
have_xapian=0
-for xapian_config in ${XAPIAN_CONFIG} xapian-config xapian-config-1.3; do
+for xapian_config in ${XAPIAN_CONFIG} xapian-config; do
if ${xapian_config} --version > /dev/null 2>&1; then
xapian_version=$(${xapian_config} --version | sed -e 's/.* //')
- printf "Yes (%s).\n" ${xapian_version}
- have_xapian=1
- xapian_cxxflags=$(${xapian_config} --cxxflags)
- xapian_ldflags=$(${xapian_config} --libs)
+ case $xapian_version in
+ 1.[4-9]* | 1.[1-9][0-9]* | [2-9]* | [1-9][0-9]*)
+ printf "Yes (%s).\n" ${xapian_version}
+ have_xapian=1
+ xapian_cxxflags=$(${xapian_config} --cxxflags)
+ xapian_ldflags=$(${xapian_config} --libs)
+ ;;
+ *) printf "Xapian $xapian_version not supported... "
+ esac
break
fi
done
@@ -439,59 +446,8 @@ if [ ${have_xapian} = "0" ]; then
errors=$((errors + 1))
fi
-have_xapian_compact=0
-have_xapian_field_processor=0
if [ ${have_xapian} = "1" ]; then
-printf "Checking for Xapian compaction support... "
-cat>_compact.cc<
-class TestCompactor : public Xapian::Compactor { };
-EOF
-if ${CXX} ${CXXFLAGS_for_sh} ${xapian_cxxflags} -c _compact.cc -o
_compact.o > /dev/null 2>&1
-then
- have_xapian_compact=1
- printf "Yes.\n"
-else
- printf "No.\n"
- errors=$((errors + 1))
-fi
-
-rm -f _compact.o _compact.cc
-
-printf "Checking for Xapian FieldProcessor API... "
-cat>_field_processor.cc<
-class TitleFieldProcessor : public Xapian::FieldProcessor { };
-EOF
-if ${CXX} ${CXXFLAGS_for_sh} ${xapian_cxxflags} -c _field_processor.cc -o
_field_processor.o > /dev/null 2>&1
-then
- have_xapian_field_processor=1
- printf "Yes.\n"
-else
- printf "No. (optional)\n"
-fi
-
-rm -f _field_processor.o _field_processor.cc
-
default_xapian_backend=""
-# DB_RETRY_LOCK is only supported on Xapian > 1.3.2
-have_xapian_db_retry_lock=0
-if [ $WITH_RETRY_LOCK = "1" ]; then
- printf "Checking for Xapian lock retry support... "
- cat>_retry.cc<
-int flag = Xapian::DB_RETRY_LOCK;
-EOF
- if ${CXX} ${CXXFLAGS_for_sh} ${xapian_cxxflags} -c _retry.cc -o
_retry.o > /dev/null 2>&1
- then
- have_xapian_db_retry_lock=1
- printf "Yes.\n"
- else
- printf "No. (optional)\n"
- fi
- rm -f _retry.o _retry.cc
-fi
-
printf "Testing default Xapian backend... "
cat >_default_backend.cc <
@@ -879,8 +835,8 @@ EOF
if [ $have_python -eq 0 ]; then
echo " python interpreter"
fi
-if [ $have_xapian -eq 0 -o $have_xapian_compact -eq 0 ]; then
- echo " Xapian library (>= version 1.2.6, including development files
such as headers)"
+if [ $have_xapian -eq 0 ]; then
+ echo " Xapian library (>= version 1.4.0, including development files
such as headers)"
echo " https://xapian.org/";
fi
if [ $have_zlib -eq 0 ]; then
@@ -1278,14 +1234,8 @@ HAVE_TIMEGM = ${have_timegm}
# Whether struct dirent has d_type (if not, then notmuch will use stat)
HAVE_D_TYPE = ${have_d_type}
-# Whether the Xapian version in use supports compaction
-HAVE_XAPIAN
Re: [PATCH] test: sort the output of the "prefix" test in T610-message-property
On Sun, Apr 19 2020, Olivier Taïbi wrote:
> 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.
This sure looks good to me.
Tomi
> ---
> test/T610-message-property.sh | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/test/T610-message-property.sh b/test/T610-message-property.sh
> index 53a0be3b..b8774230 100755
> --- a/test/T610-message-property.sh
> +++ b/test/T610-message-property.sh
> @@ -186,6 +186,18 @@ EXPECT0(notmuch_message_add_property (message,
> "testkey3", "testvalue3"));
> EXPECT0(notmuch_message_add_property (message, "testkey3", "alice3"));
> print_properties (message, "testkey", FALSE);
> EOF
> +# expected: 4 values for testkey1, 3 values for testkey3
> +# they are not guaranteed to be sorted, so sort them, leaving the first
> +# line '== stdout ==' and the end ('== stderr ==' and whatever error
> +# may have been printed) alone
> +mv OUTPUT unsorted_OUTPUT
> +awk ' NR == 1 { print; next } \
> + NR < 6 { print | "sort"; next } \
> + NR == 6 { close("sort") } \
> + NR < 9 { print | "sort"; next } \
> + NR == 9 { close("sort") } \
> + { print }' unsorted_OUTPUT > OUTPUT
> +rm unsorted_OUTPUT
> cat <<'EOF' >EXPECTED
> == stdout ==
> alice
> --
> 2.26.1
> ---
> a better version of the previous patch I sent with head/tail replaced by an
> awk
> script by Tomi Ollila which is clearer, and comments added in the test for
> clarity.
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: sort the output of the "prefix" test in T610-message-property as needed
On Fri, Apr 17 2020, Olivier Taïbi wrote:
> the "prefix" test in T610-message-property 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 correct this by
> splitting the output using head and tail and sorting each chunk using
> sort.
> NB: the relevant key/values are as follows.
> testkey1: alice, testvalue1, testvalue2, bob
> testkey3: alice3, bob3, testvalue3
> ---
> test/T610-message-property.sh | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/test/T610-message-property.sh b/test/T610-message-property.sh
> index 53a0be3b..e1be2fc3 100755
> --- a/test/T610-message-property.sh
> +++ b/test/T610-message-property.sh
> @@ -186,6 +186,11 @@ EXPECT0(notmuch_message_add_property (message,
> "testkey3", "testvalue3"));
> EXPECT0(notmuch_message_add_property (message, "testkey3", "alice3"));
> print_properties (message, "testkey", FALSE);
> EOF
Whichever way done, this should be commented here, not (just) in git
history, that information is not readily available (one has to know
git blame and then go to see to the commit message :)
> +mv OUTPUT unsorted_OUTPUT
> +head -n 5 unsorted_OUTPUT | sort >OUTPUT
Relying that '== stdout ==' sorts first is kinda ugly, as it does not
be part of the sorting range,
> +tail -n +6 unsorted_OUTPUT | head -n 3 | sort >>OUTPUT
if there were more content in file i would have suggested `sed -n 6,9p`
> +tail -n +9 unsorted_OUTPUT >>OUTPUT
> +rm unsorted_OUTPUT
due to the '== stdout ==' I'd suggest:
awk ' NR == 1 { print; next }
NR < 6 { print | "sort"; next }
NR == 6 { close("sort") }
NR < 9 { print | "sort"; next }
NR == 9 { close("sort") }
{ print }' unsorted_OUTPUT > OUTPUT
(works w/ gawk and mawk), with some explanation why.
(perhaps how the sorting is done does not need to be explained in commit
message =D
> cat <<'EOF' >EXPECTED
> == stdout ==
> alice
> --
> 2.26.0
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: timezone in notmuch
On Tue, Apr 14 2020, di...@santanas.co.za wrote: > 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 timezone (SAST/+0200)? I use this: https://github.com/domo141/nottoomuch/blob/master/build/01-date-local.patch I've been thinking if some hook could be added to notmuch-emacs so that such a custom date mangling can be done outside of the notmuch-emacs source... Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs doc: replace `...' with `...` in emacs docstrings for rst
On Mon, Apr 13 2020, Tomi Ollila wrote:
> Previously ' without preceding \ was replaced with `, to make emacs
> document content structure `...' to work with reStructuredText.
The change is good, but comment message crap.
While trying to make rstdoc.el to load elisp code so that in docstrings
single quotes (') were not changed to their better-looking unicode
counterparts I notices that in `...' the ' in that is not converted
(since it is syntax-highlighted internally by emacs).
Since that the original version where 's not preceded by \ are converted.
(as rest are already changed) -- ¡¡¡unless the locale is C!!!.
So we really are better just converting `...' to `...` (If we had `:s
w/o ...' then those should be escaped -- but (so far) we don't --
doing those is not trivial, but possible).
I'll resend this w/ different commit message later.
(but please review and comment if there is anything wrong before that =)
Tomi
>
> But there are also single uses of ' in parts of the extracted
> docstrings, so better "restrict" the matching content to `[^']+'.
>
> Dropped checking preceding \ before ' -- it is not needed anymore;
> there is now one \' in the docstrings, but outside `...'.
>
> Note: In UTF-8 locales ` and ' may be replaced by some (arguably)
> better looking unicode counterparts (by emacs).
> ---
>
> This also "avoids" the bug building emacs/notmuch-parser.rsti in
> Debian 10. The doc content with "... SP's ..." no longer matches
> the re which caused emacs to barf then in (replace-match) (*)
> there. The bug is still a mystery (and may stay so).
>
> (* used (setq debug-on-error t) to dig a bit of the problem)
>
> emacs/rstdoc.el | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/emacs/rstdoc.el b/emacs/rstdoc.el
> index 2225aefc..94596061 100644
> --- a/emacs/rstdoc.el
> +++ b/emacs/rstdoc.el
> @@ -68,7 +68,7 @@ (defun rstdoc--insert-docstring (symbol docstring)
>
> (defvar rst--escape-alist
>'( ("='" . "'")
> - ("\\([^\\]\\)'" . "\\1`")
> + ("`\\([^']+\\)'" . "`\\1`")
> ("^[[:space:]\t]*$" . "|br|")
> ("^[[:space:]\t]" . "|indent| "))
> "list of (regex . replacement) pairs")
> --
> 2.25.2
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] zlib-related bugs
On Fri, Apr 10 2020, Olivier Taïbi wrote: > the following diff addresses 3 zlib-related bugs in notmuch. > 3) in gz_getline(), if gz_error sets its second argument to Z_STREAM_END >then there was no error (only EOF). Unfortunately the zlib manual is >not very clear on the meaning of Z_STREAM_END, but I don't see how it >could be an error. I found this issue by using notmuch on OpenBSD, >which has an old zlib. I encountered other issues with notmuch on >OpenBSD (e.g. there is no transparency mode in this older zlib, so >notmuch dump output is always gzipped), but they do not seem to be >bugs in notmuch. Interesting. What versions of gmime and xapian are you using with notmuch on OpenBSD? IIRC(*) xapian 1.4 also wants zlib (but I am not sure how new one). Tomi (*) I am building notmuch for centos 6 using this script: https://github.com/domo141/nottoomuch/blob/master/build/podman-notmuch-build-on-centos6.sh and I've configured xapian to use self-built zlib -- perhans not since xapian required, but that the same is used what notmuch(1) uses. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 4/6] cli/dump: define GZPRINTF macro and use it in place of gzprintf
On Mon, Apr 13 2020, David Bremner wrote: > 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 467e1d84..01f5101a 100644 > --- a/notmuch-client.h > +++ b/notmuch-client.h > @@ -497,6 +497,10 @@ print_status_gzbytes (const char *loc, > gzFile file, > int bytes); > > +/* the __location__ macro is defined in talloc.h */ > +#define ASSERT_GZBYTES(file, bytes) ((print_status_gzbytes (__location__, > file, bytes)) ? exit (1) : 0) The 2 spaces before exit (1) I tried to communicate ;) well, perhaps the __location__ thing broke the flow... can be amended if no other comments to be seen Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs doc: replace `...' with `...` in emacs docstrings for rst
Previously ' without preceding \ was replaced with `, to make emacs
document content structure `...' to work with reStructuredText.
But there are also single uses of ' in parts of the extracted
docstrings, so better "restrict" the matching content to `[^']+'.
Dropped checking preceding \ before ' -- it is not needed anymore;
there is now one \' in the docstrings, but outside `...'.
Note: In UTF-8 locales ` and ' may be replaced by some (arguably)
better looking unicode counterparts (by emacs).
---
This also "avoids" the bug building emacs/notmuch-parser.rsti in
Debian 10. The doc content with "... SP's ..." no longer matches
the re which caused emacs to barf then in (replace-match) (*)
there. The bug is still a mystery (and may stay so).
(* used (setq debug-on-error t) to dig a bit of the problem)
emacs/rstdoc.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/emacs/rstdoc.el b/emacs/rstdoc.el
index 2225aefc..94596061 100644
--- a/emacs/rstdoc.el
+++ b/emacs/rstdoc.el
@@ -68,7 +68,7 @@ (defun rstdoc--insert-docstring (symbol docstring)
(defvar rst--escape-alist
'( ("='" . "'")
- ("\\([^\\]\\)'" . "\\1`")
+ ("`\\([^']+\\)'" . "`\\1`")
("^[[:space:]\t]*$" . "|br|")
("^[[:space:]\t]" . "|indent| "))
"list of (regex . replacement) pairs")
--
2.25.2
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 3/5] cli/dump: define GZPRINTF macro and use it in place of gzprintf
On Sun, Apr 12 2020, David Bremner wrote: > 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 467e1d84..55d4d526 100644 > --- a/notmuch-client.h > +++ b/notmuch-client.h > @@ -497,6 +497,9 @@ print_status_gzbytes (const char *loc, > gzFile file, > int bytes); > > +#define ASSERT_GZBYTES(file, bytes) ( (print_status_gzbytes(__location__, > file, bytes)) ? exit(1) : 0 ) __location__ ?? never seen such a (preprocessor?) definition. could not find any reference by search... there are also some suspiciously looking like inconsistent spaces in that macro above rest of the series (before and after) look good Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: add known_broken test for dumping large stored queries
On Sun, Apr 12 2020, David Bremner wrote:
> '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 b/test/T240-dump-restore.sh
> index 0870ff92..374db5c2 100755
> --- a/test/T240-dump-restore.sh
> +++ b/test/T240-dump-restore.sh
> @@ -322,6 +322,19 @@ EOF
>
> test_expect_equal_file EXPECTED OUTPUT
>
> +test_begin_subtest 'dumping large queries'
> +test_subtest_known_broken
> +# This value repeat was found experimentally by binary search. The
> +# config value after URL encoding is exactly 4096 bytes, which
> +# suggests a buffer size bug.
> +repeat=1329
> +notmuch config set query.big "$(seq -s' ' $repeat)"
> +notmuch dump --include=config > OUTPUT
> +notmuch config set query.big ''
> +printf "#notmuch-dump batch-tag:3 config\n#@ query.big " > EXPECTED
> +seq -s'%20' $repeat >> EXPECTED
Extra space, otherwise tolerable =D
Tomi
> +test_expect_equal_file EXPECTED OUTPUT
> +
> test_begin_subtest 'roundtripping random message-ids and tags'
>
> ${TEST_DIRECTORY}/random-corpus --config-path=${NOTMUCH_CONFIG} \
> --
> 2.25.1
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-mode: Emails with PDF attachments incorrectly tagged as text/plain expose a few issues
On Mon, Apr 06 2020, David Bremner wrote: > 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. >>> >>> 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 correspondent to >>> send you a shareable message, then sanitize the addesses in the headers. >> >> So, I've just been able to re-create at least the “freeze on reply” isue >> with the email attached. The image doesn't get corrupted when saving, >> though, so I'm not sure it'll be enough to fix both issues, but >> hopefully fixing this one would fix the other one too. >> >> If you try to notmuch-show on the attached email, then hit `r`, you >> should notice the image being included verbatim in the text/plain >> output, and when hitting C-c C-c it should start freezing emacs. >> >> Hope that helps! >> Leo > > Probably the rest of the list hasn't seen the message yet, but I did try > it out. ... Rest of the list hasn't seen the message (yet?) as the body is 440805 bytes in size (and there is limit in the mailing list) and it is hanging in moderator queue. I am not too enthusiastic to bloat the mailing list archive with just a large test message (but am not against is there more people who do think that it is a good idea). Tomi > ... It doesn't actually hang emacs for me (C-g enough times gets me > back). I agree that inserting binary data into the buffer is probably > not a great idea. I'm not sure offhand how notmuch should detect > mislabeled parts. Perhaps it should just refuse to insert large parts as > reply text. > > d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] mime-node: Clean up unwrapped MIME parts correctly.
On Thu, Mar 19 2020, Daniel Kahn Gillmor wrote:
> Avoid a memory leak in the notmuch command line.
>
> gmime_multipart_encrypted_decrypt returns a GMimeObject marked by
> GMime as "transfer full", so we are supposed to clean up after it.
>
> When parsing a message, notmuch would leak one GMimeObject part per
> multipart/encrypted MIME layer. We clean it up by analogy with
> cleaning up the signature list associated with a MIME node.
>
> Signed-off-by: Daniel Kahn Gillmor
Looks good to me.
Tomi
> ---
> mime-node.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/mime-node.c b/mime-node.c
> index 2a823dfd..ff6805bf 100644
> --- a/mime-node.c
> +++ b/mime-node.c
> @@ -192,6 +192,26 @@ set_signature_list_destructor (mime_node_t *node)
> }
> }
>
> +/* Unwrapped MIME part destructor */
> +static int
> +_unwrapped_child_free (GMimeObject **proxy)
> +{
> +g_object_unref (*proxy);
> +return 0;
> +}
> +
> +/* Set up unwrapped MIME part destructor */
> +static void
> +set_unwrapped_child_destructor (mime_node_t *node)
> +{
> +GMimeObject **proxy = talloc (node, GMimeObject *);
> +
> +if (proxy) {
> + *proxy = node->unwrapped_child;
> + talloc_set_destructor (proxy, _unwrapped_child_free);
> +}
> +}
> +
> /* Verify a signed mime node */
> static void
> node_verify (mime_node_t *node, GMimeObject *part)
> @@ -238,6 +258,8 @@ node_decrypt_and_verify (mime_node_t *node, GMimeObject
> *part)
>
> node->ctx->crypto->decrypt,
>message,
>encrypteddata,
> &decrypt_result, &err);
> + if (node->unwrapped_child)
> + set_unwrapped_child_destructor (node);
> }
> if (! node->unwrapped_child) {
> fprintf (stderr, "Failed to decrypt part: %s\n",
> --
> 2.25.1
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] mime-node: Pass the correct flags to g_mime_multipart_signed_verify
On Wed, Mar 18 2020, Daniel Kahn Gillmor wrote: > GMIME_ENCRYPT_NONE and GMIME_VERIFY_NONE have the same value, but they > are different enumerated types. So in C, this is a cosmetic change, > but it is technically correct if we only had stricter typing. Change consistent with '@@ node_verify', LGTM. Tomi > > Signed-off-by: Daniel Kahn Gillmor > --- > mime-node.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mime-node.c b/mime-node.c > index d4996a33..e531078c 100644 > --- a/mime-node.c > +++ b/mime-node.c > @@ -201,7 +201,7 @@ node_verify (mime_node_t *node, GMimeObject *part) > > node->verify_attempted = true; > node->sig_list = g_mime_multipart_signed_verify ( > - GMIME_MULTIPART_SIGNED (part), GMIME_ENCRYPT_NONE, &err); > + GMIME_MULTIPART_SIGNED (part), GMIME_VERIFY_NONE, &err); > > if (node->sig_list) > set_signature_list_destructor (node); > -- > 2.25.1 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Make notmuch-mutt script more portable
On Mon, Mar 16 2020, Greg Anders wrote:
> The -D flag to install (used in the Makefile) is GNU-specific and does
> not work on BSD distributions (i.e. macOS). Likewise with the xargs -r
> flag. These changes use portable alternatives to these flags while
> preserving the exact behavior.
Looks more portable to me. +1.
The system and shell pipeline in the search() function has always irritated
me when I've looked it (a bit). At the end of this email is model of
potential replacement code which I just cooked up, which SomeOne(TM)
may implement =D
> ---
> contrib/notmuch-mutt/Makefile | 6 +++---
> contrib/notmuch-mutt/notmuch-mutt | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/contrib/notmuch-mutt/Makefile b/contrib/notmuch-mutt/Makefile
> index 855438be..de933eaa 100644
> --- a/contrib/notmuch-mutt/Makefile
> +++ b/contrib/notmuch-mutt/Makefile
> @@ -15,11 +15,11 @@ README.html: README
> markdown $< > $@
>
> install: all
> - mkdir -p $(DESTDIR)$(prefix)/bin
> + mkdir -p $(DESTDIR)$(prefix)/bin $(DESTDIR)$(mandir)/man1
> $(DESTDIR)$(sysconfdir)/Muttrc.d
> sed "1s|^#!.*|#! $(PERL_ABSOLUTE)|" < $(NAME) >
> $(DESTDIR)$(prefix)/bin/$(NAME)
> chmod 755 $(DESTDIR)$(prefix)/bin/$(NAME)
> - install -D -m 644 $(NAME).1 $(DESTDIR)$(mandir)/man1/$(NAME).1
> - install -D -m 644 $(NAME).rc $(DESTDIR)$(sysconfdir)/Muttrc.d/$(NAME).rc
> + install -m 644 $(NAME).1 $(DESTDIR)$(mandir)/man1/
> + install -m 644 $(NAME).rc $(DESTDIR)$(sysconfdir)/Muttrc.d/
>
> clean:
> rm -f notmuch-mutt.1 README.html
> diff --git a/contrib/notmuch-mutt/notmuch-mutt
> b/contrib/notmuch-mutt/notmuch-mutt
> index 0e46a8c1..d33223bd 100755
> --- a/contrib/notmuch-mutt/notmuch-mutt
> +++ b/contrib/notmuch-mutt/notmuch-mutt
> @@ -50,7 +50,7 @@ sub search($$$) {
> empty_maildir($maildir);
> system("notmuch search --output=files $dup_option $query"
> . " | sed -e 's: : :g'"
> -. " | xargs -r -I searchoutput ln -s searchoutput $maildir/cur/");
> +. " | while IFS= read -r searchoutput; do ln -s \$searchoutput
> $maildir/cur/; done");
> }
>
> sub prompt($$) {
> --
> 2.25.1
--8<8<8<8<8<8<8<8<8<8<8<8<--
safe to run; "write" code outcommented, example print added.
--8<8<8<8<8<8<8<8<8<8<8<8<--
#!/usr/bin/perl
# -*- mode: cperl; cperl-indent-level: 4 -*-
# $ test-search-code.pl $
use 5.8.1;
use strict;
use warnings;
#$ENV{'PATH'} = '/sbin:/usr/sbin:/bin:/usr/bin';
sub search($$$) {
my ($maildir, $remove_dups, $query) = @_;
my @opts;
push @opts, '--duplicate=1' if $remove_dups;
push @opts, $query;
#empty_maildir($maildir);
open P, '-|', qw/notmuch search --output=files/, @opts or die $!;
while () {
chomp;
my $f = $_;
s|.*/||;
print qq'$f "$maildir/$_" or die \$!;\n';
#symlink $f "$maildir/$_" or die $!;
}
close P;
}
search 'maildir', 0, 'date:1d..';
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] nmbug: explicitly prefer python3
On Thu, Mar 12 2020, Daniel Kahn Gillmor wrote: > Two years later, I'd like to re-propose this patch that moves nmbug to > python3. > > I have read what PEP 394 says (thanks for the pointer, Trevor!) but in > practice (a) i do not see debian pointing /usr/bin/python to python3 any > time in the near future, (b) python2 is officially EOL, and (c) i don't > have a "python" binary in my $PATH at all any more on the machines where > i do most of my development work. > > Can we please just be done with requiring people who actively develop > notmuch to keep python 2 installed, or to point some other element named > python maintained in their path ? I've been running nmbug with a wrapper that runs python 2.7 (since default python in that particular machine is python 2.6 -- which doesn't work with nmbug (or it may but that is complicated, i'm not sure...). So, to me just doing 1,s/python/python3/ does not affect me in any way for the time being -- and anyone else who is stuck w/ python 2.7 (i doubt there are any) could still use python 2.7 the same way... So, IMO let's get it done =D > >--dkg Tomi > > On Thu 2018-02-08 23:32:11 -0500, Daniel Kahn Gillmor wrote: >> nmbug and notmuch-report are developer tools. It's 2018, and all >> developers should have python3 available. >> >> Signed-off-by: Daniel Kahn Gillmor >> --- >> devel/nmbug/nmbug | 2 +- >> devel/nmbug/notmuch-report | 5 ++--- >> 2 files changed, 3 insertions(+), 4 deletions(-) >> >> diff --git a/devel/nmbug/nmbug b/devel/nmbug/nmbug >> index c35dd75d..043c1863 100755 >> --- a/devel/nmbug/nmbug >> +++ b/devel/nmbug/nmbug >> @@ -1,4 +1,4 @@ >> -#!/usr/bin/env python >> +#!/usr/bin/env python3 >> # >> # Copyright (c) 2011-2014 David Bremner >> # W. Trevor King >> diff --git a/devel/nmbug/notmuch-report b/devel/nmbug/notmuch-report >> index a9c2a6ec..a4c13939 100755 >> --- a/devel/nmbug/notmuch-report >> +++ b/devel/nmbug/notmuch-report >> @@ -1,10 +1,9 @@ >> -#!/usr/bin/python >> +#!/usr/bin/env python3 >> # >> # Copyright (c) 2011-2012 David Bremner >> # >> # dependencies >> -# - python 2.6 for json >> -# - argparse; either python 2.7, or install separately >> +# - python3 or python2.7 >> # >> # This program is free software: you can redistribute it and/or modify >> # it under the terms of the GNU General Public License as published by >> -- >> 2.15.1 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: T050-new and T060-count fail if gdb prints a warning
On Tue, Mar 10 2020, Dan Čermák wrote: > Hi list, > > I have encountered a test failure caused by the T050-new and T060-count > tests in the latest openSUSE-Tumbleweed rebuild with Python 3.8 instead > of Python 3.7. Both tests die with: > > --8<---cut here---start->8--- > T050-new: Testing "notmuch new" in several variations > FAIL Handle files vanishing between scandir and add_file >--- T050-new.36.EXPECTED2020-03-10 12:49:34.388407058 + >+++ T050-new.36.OUTPUT 2020-03-10 12:49:34.388407058 + >@@ -1,3 +1,7 @@ >+/usr/share/gdb/python/gdb/command/prompt.py:48: SyntaxWarning: "is > not" with a literal. Did you mean "!="? >+ if self.value is not '': >+/usr/share/gdb/python/gdb/command/prompt.py:60: SyntaxWarning: "is > not" with a literal. Did you mean "!="? >+ if self.value is not '': > Unexpected error with file > /home/abuild/rpmbuild/BUILD/notmuch-0.29.3/test/tmp.T050-new/mail/vanish > add_file: Something went wrong trying to read or write a file > Error opening > /home/abuild/rpmbuild/BUILD/notmuch-0.29.3/test/tmp.T050-new/mail/vanish: No > such file or directory > --8<---cut here---end--->8--- > > which I think is caused by gdb 8 using some odd Python syntax and is > completely unrelated to notmuch. > > The solution is of course to fix this in gdb (e.g. by updating to gdb > 9), but the more general question is: can notmuch's testsuite do > something to avoid issues like this altogether? setting PYTHONWARNINGS environment variable could probably do it. IIRC the -count test is something that is harder to replace with LD_PRELOAD shim... (btw: thanks for this report -- i learned python3 -bb option (been hit comparing strings and bytes with == ...) > > > Cheers, > > Dan Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 6/6] notmuch-hello/jump: allow saved searches to specify unthreaded mode
On Thu, Feb 27 2020, Mark Walters wrote: > Saved searches in notmuch-hello and notmuch-jump can specify whether > to use search mode or tree mode. This adds an option for them to > specify unthreaded mode. LGTM. Tomi > --- > emacs/notmuch-hello.el | 29 +++-- > emacs/notmuch-jump.el | 10 +++--- > 2 files changed, 26 insertions(+), 13 deletions(-) > ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 5/6] Add a U binding to switch to unthreaded from other views
On Thu, Feb 27 2020, Mark Walters wrote: > We have shortcuts S and Z to let the user switch to Search view and > Tree view with the current search. Add U to let the user switch to > unthreaded view from the current search, and ensure that S and Z > switch from unthreaded to search and tree veiew respectively. LGTM. Tomi > --- > emacs/notmuch-show.el | 10 ++ > emacs/notmuch-tree.el | 23 +-- > emacs/notmuch.el | 6 ++ > 3 files changed, 37 insertions(+), 2 deletions(-) > ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 4/6] Unthreaded mode: allow user to choose different `show out' than tree
On Thu, Feb 27 2020, Mark Walters wrote:
> Tree mode allows the user to choose whether to use the split screen
> displaying just the current message or a full screen displaying the
> entire thread. As unthreaded mode is quite different in use the user
> may want a different customisation for this mode.
LGTM.
Tomi
> ---
> emacs/notmuch-tree.el | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
> index 760eaaec..895c05f4 100644
> --- a/emacs/notmuch-tree.el
> +++ b/emacs/notmuch-tree.el
> @@ -56,6 +56,16 @@
>:type 'boolean
>:group 'notmuch-tree)
>
> +(defcustom notmuch-unthreaded-show-out t
> + "View selected messages in new window rather than split-pane."
> + :type 'boolean
> + :group 'notmuch-tree)
> +
> +(defun notmuch-tree-show-out ()
> + (if notmuch-tree-unthreaded
> + notmuch-unthreaded-show-out
> +notmuch-tree-show-out))
> +
> (defcustom notmuch-tree-result-format
>`(("date" . "%12s ")
> ("authors" . "%-20s")
> @@ -531,8 +541,8 @@ NOT change the database."
> Shows in split pane or whole window according to value of
> `notmuch-tree-show-out'. A prefix argument reverses the choice."
>(interactive "P")
> - (if (or (and notmuch-tree-show-out (not arg))
> - (and (not notmuch-tree-show-out) arg))
> + (if (or (and (notmuch-tree-show-out) (not arg))
> + (and (not (notmuch-tree-show-out)) arg))
>(notmuch-tree-show-message-out)
> (notmuch-tree-show-message-in)))
>
> --
> 2.11.0
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 3/6] Unthreaded mode: allow different result format
On Thu, Feb 27 2020, Mark Walters wrote:
> It is likely that the user will want a different line format for
> unthreaded mode from tree mode; in particular the thread structure
> graphics are unnecessary in unthreaded mode.
>
> Add a new customisable variable and set it to something sensible.
Looks good to me (I trust Mark the result format is good)
Tomi
> ---
> emacs/notmuch-tree.el | 27 ++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
> index 80b830dd..760eaaec 100644
> --- a/emacs/notmuch-tree.el
> +++ b/emacs/notmuch-tree.el
> @@ -76,6 +76,31 @@ Note the author string should not contain
>:type '(alist :key-type (string) :value-type (string))
>:group 'notmuch-tree)
>
> +(defcustom notmuch-unthreaded-result-format
> + `(("date" . "%12s ")
> +("authors" . "%-20s")
> +((("subject" . "%s")) ." %-54s ")
> +("tags" . "(%s)"))
> + "Result formatting for unthreaded Tree view. Supported fields are: date,
> +authors, subject, tree, tags. Tree means the thread tree
> +box graphics. The field may also be a list in which case
> +the formatting rules are applied recursively and then the
> +output of all the fields in the list is inserted
> +according to format-string.
> +
> +Note the author string should not contain
> +whitespace (put it in the neighbouring fields instead).
> +For example:
> +(setq notmuch-tree-result-format \(\(\"authors\" . \"%-40s\"\)
> + \(\"subject\" . \"%s\"\)\)\)"
> + :type '(alist :key-type (string) :value-type (string))
> + :group 'notmuch-tree)
> +
> +(defun notmuch-tree-result-format ()
> + (if notmuch-tree-unthreaded
> + notmuch-unthreaded-result-format
> +notmuch-tree-result-format))
> +
> ;; Faces for messages that match the query.
> (defface notmuch-tree-match-face
>'((t :inherit default))
> @@ -759,7 +784,7 @@ unchanged ADDRESS if parsing fails."
>;; We need to save the previous subject as it will get overwritten
>;; by the insert-field calls.
>(let ((previous-subject notmuch-tree-previous-subject))
> -(insert (notmuch-tree-format-field-list notmuch-tree-result-format msg))
> +(insert (notmuch-tree-format-field-list (notmuch-tree-result-format)
> msg))
> (notmuch-tree-set-message-properties msg)
> (notmuch-tree-set-prop :previous-subject previous-subject)
> (insert "\n")))
> --
> 2.11.0
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/6] Introduce unthreaded mode
On Thu, Feb 27 2020, Mark Walters wrote:
> This commit introduces a new 'unthreaded' search mode where each
> matching message is shown on a separate line. It shares almost all of
> its code with tree view. Subsequent commits will allow it to diverge
> slightly in appearance.
Could have just written, "Introdude a new 'unthreaded' ..." but LGTM =D
(at least there is no 'seperate' here >;)
Tomi
> ---
> emacs/notmuch-hello.el | 2 +-
> emacs/notmuch-lib.el | 1 +
> emacs/notmuch-show.el | 2 +-
> emacs/notmuch-tree.el | 28 +---
> 4 files changed, 24 insertions(+), 9 deletions(-)
>
> diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
> index aff8beb5..858446df 100644
> --- a/emacs/notmuch-hello.el
> +++ b/emacs/notmuch-hello.el
> @@ -31,7 +31,7 @@
> (declare-function notmuch-search "notmuch" (&optional query oldest-first
> target-thread target-line continuation))
> (declare-function notmuch-poll "notmuch" ())
> (declare-function notmuch-tree "notmuch-tree"
> - (&optional query query-context target buffer-name
> open-target))
> + (&optional query query-context target buffer-name open-target
> unthreaded))
>
> (defun notmuch-saved-search-get (saved-search field)
>"Get FIELD from SAVED-SEARCH.
> diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
> index 8acad267..73b165e4 100644
> --- a/emacs/notmuch-lib.el
> +++ b/emacs/notmuch-lib.el
> @@ -154,6 +154,7 @@ For example, if you wanted to remove an \"inbox\" tag and
> add an
> (define-key map "q" 'notmuch-bury-or-kill-this-buffer)
> (define-key map "s" 'notmuch-search)
> (define-key map "z" 'notmuch-tree)
> +(define-key map "u" 'notmuch-unthreaded)
> (define-key map "m" 'notmuch-mua-new-mail)
> (define-key map "g" 'notmuch-refresh-this-buffer)
> (define-key map "=" 'notmuch-refresh-this-buffer)
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index ef2bf1e0..d4a1389b 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -48,7 +48,7 @@
> (declare-function notmuch-count-attachments "notmuch" (mm-handle))
> (declare-function notmuch-save-attachments "notmuch" (mm-handle &optional
> queryp))
> (declare-function notmuch-tree "notmuch-tree"
> - (&optional query query-context target buffer-name
> open-target))
> + (&optional query query-context target buffer-name open-target
> unthreaded))
> (declare-function notmuch-tree-get-message-properties "notmuch-tree" nil)
> (declare-function notmuch-read-query "notmuch" (prompt))
> (declare-function notmuch-draft-resume "notmuch-draft" (id))
> diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
> index c00315e8..80b830dd 100644
> --- a/emacs/notmuch-tree.el
> +++ b/emacs/notmuch-tree.el
> @@ -42,6 +42,11 @@
> ;; the following variable is defined in notmuch.el
> (defvar notmuch-search-query-string)
>
> +;; this variable distinguishes the unthreaded display from the normal tree
> display
> +(defvar notmuch-tree-unthreaded nil
> + "A buffer local copy of argument unthreaded to the function notmuch-tree")
> +(make-variable-buffer-local 'notmuch-tree-unthreaded)
> +
> (defgroup notmuch-tree nil
>"Showing message and thread structure."
>:group 'notmuch)
> @@ -890,7 +895,7 @@ Complete list of currently available key bindings:
> (notmuch-sexp-parse-partial-list 'notmuch-tree-insert-forest-thread
>results-buf)
>
> -(defun notmuch-tree-worker (basic-query &optional query-context target
> open-target)
> +(defun notmuch-tree-worker (basic-query &optional query-context target
> open-target unthreaded)
>"Insert the tree view of the search in the current buffer.
>
> This is is a helper function for notmuch-tree. The arguments are
> @@ -898,6 +903,7 @@ the same as for the function notmuch-tree."
>(interactive)
>(notmuch-tree-mode)
>(add-hook 'post-command-hook #'notmuch-tree-command-hook t t)
> + (setq notmuch-tree-unthreaded unthreaded)
>(setq notmuch-tree-basic-query basic-query)
>(setq notmuch-tree-query-context (if (or (string= query-context "")
> (string= query-context "*"))
> @@ -915,7 +921,7 @@ the same as for the function notmuch-tree."
>(let* ((search-args (concat basic-query
> (if query-context (concat " and (" query-context ")"))
> ))
> - (message-arg "--entire-thread"))
> + (message-arg (if unthreaded "--unthreaded" "--entire-thread")))
> (if (equal (car (process-lines notmuch-command "count" search-args)) "0")
> (setq search-args basic-query))
> (notmuch-tag-clear-cache)
> @@ -940,7 +946,7 @@ the same as for the function notmuch-tree."
> ")")
> notmuch-tree-basic-query))
>
> -(defun notmuch-tree (&optional query query-context target buffer-name
> open-target)
> +(defun notmuch-tree (&optional query que
Re: [PATCH 1/6] notmuch-show.c: add an option for messages to be returned unthreaded
On Thu, Feb 27 2020, Mark Walters wrote: > This adds a --unthreaded option to notmuch show to tell it to return > the matching messages in an unthreaded order (so just by date). > > To make it easier for users, in particular for notmuch-tree.el, we > output each message with the same "nesting" as if it were an entire > thread in its own right. Some spacing in this commit, but LGTM =D Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] build: drop support for xapian versions less than 1.4
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
but user may want to disable retry locking at configure time so it
is kept.
---
doc/man7/notmuch-search-terms.rst was not changed in this commit --
I did not fully understand what was it saying...
configure| 101 +++
lib/built-with.c | 4 +-
lib/database.cc | 10
lib/parse-time-vrp.cc| 2 -
lib/parse-time-vrp.h | 3 +-
lib/query-fp.cc | 3 --
lib/query-fp.h | 3 +-
lib/regexp-fields.cc | 2 -
lib/regexp-fields.h | 4 +-
lib/thread-fp.cc | 3 --
lib/thread-fp.h | 3 +-
test/T020-compact.sh | 12 -
test/T500-search-date.sh | 3 --
test/T585-thread-subquery.sh | 12 -
test/T600-named-queries.sh | 6 ---
test/T650-regexp-query.sh| 4 --
test/T670-duplicate-mid.sh | 5 --
17 files changed, 27 insertions(+), 153 deletions(-)
diff --git a/configure b/configure
index c16d18dc..c8d4d529 100755
--- a/configure
+++ b/configure
@@ -422,15 +422,22 @@ else
have_pkg_config=0
fi
-printf "Checking for Xapian development files... "
+
+
+printf "Checking for Xapian development files (>= 1.4.0)... "
have_xapian=0
-for xapian_config in ${XAPIAN_CONFIG} xapian-config xapian-config-1.3; do
+for xapian_config in ${XAPIAN_CONFIG} xapian-config; do
if ${xapian_config} --version > /dev/null 2>&1; then
xapian_version=$(${xapian_config} --version | sed -e 's/.* //')
- printf "Yes (%s).\n" ${xapian_version}
- have_xapian=1
- xapian_cxxflags=$(${xapian_config} --cxxflags)
- xapian_ldflags=$(${xapian_config} --libs)
+ case $xapian_version in
+ 1.[4-9]* | 1.[1-9][0-9]* | [2-9]* | [1-9][0-9]*)
+ printf "Yes (%s).\n" ${xapian_version}
+ have_xapian=1
+ xapian_cxxflags=$(${xapian_config} --cxxflags)
+ xapian_ldflags=$(${xapian_config} --libs)
+ ;;
+ *) printf "Xapian $xapian_version not supported... "
+ esac
break
fi
done
@@ -439,59 +446,8 @@ if [ ${have_xapian} = "0" ]; then
errors=$((errors + 1))
fi
-have_xapian_compact=0
-have_xapian_field_processor=0
if [ ${have_xapian} = "1" ]; then
-printf "Checking for Xapian compaction support... "
-cat>_compact.cc<
-class TestCompactor : public Xapian::Compactor { };
-EOF
-if ${CXX} ${CXXFLAGS_for_sh} ${xapian_cxxflags} -c _compact.cc -o
_compact.o > /dev/null 2>&1
-then
- have_xapian_compact=1
- printf "Yes.\n"
-else
- printf "No.\n"
- errors=$((errors + 1))
-fi
-
-rm -f _compact.o _compact.cc
-
-printf "Checking for Xapian FieldProcessor API... "
-cat>_field_processor.cc<
-class TitleFieldProcessor : public Xapian::FieldProcessor { };
-EOF
-if ${CXX} ${CXXFLAGS_for_sh} ${xapian_cxxflags} -c _field_processor.cc -o
_field_processor.o > /dev/null 2>&1
-then
- have_xapian_field_processor=1
- printf "Yes.\n"
-else
- printf "No. (optional)\n"
-fi
-
-rm -f _field_processor.o _field_processor.cc
-
default_xapian_backend=""
-# DB_RETRY_LOCK is only supported on Xapian > 1.3.2
-have_xapian_db_retry_lock=0
-if [ $WITH_RETRY_LOCK = "1" ]; then
- printf "Checking for Xapian lock retry support... "
- cat>_retry.cc<
-int flag = Xapian::DB_RETRY_LOCK;
-EOF
- if ${CXX} ${CXXFLAGS_for_sh} ${xapian_cxxflags} -c _retry.cc -o
_retry.o > /dev/null 2>&1
- then
- have_xapian_db_retry_lock=1
- printf "Yes.\n"
- else
- printf "No. (optional)\n"
- fi
- rm -f _retry.o _retry.cc
-fi
-
printf "Testing default Xapian backend... "
cat >_default_backend.cc <
@@ -879,8 +835,8 @@ EOF
if [ $have_python -eq 0 ]; then
echo " python interpreter"
fi
-if [ $have_xapian -eq 0 -o $have_xapian_compact -eq 0 ]; then
- echo " Xapian library (>= version 1.2.6, including development files
such as headers)"
+if [ $have_xapian -eq 0 ]; then
+ echo " Xapian library (>= version 1.4.0, including development files
such as headers)"
echo " https://xapian.org/";
fi
if [ $have_zlib -eq 0 ]; then
@@ -1278,14 +1234,8 @@ HAVE_TIMEGM = ${have_timegm}
# Whether struct dirent has d_type (if not, then notmuch will use stat)
HAVE_D_TYPE = ${have_d_type}
-# Whether the Xapian version in use supports compaction
-HAVE_XAPIAN_COMPACT = ${have_xapian_compact}
-
-# Whether the Xapian version in use supports field processors
-HAVE_XAPIAN_FIELD_PROCESSOR = ${have_xapian_field_processor}
-
-# Whether the
Re: [PATCH] Drop deprecated/unused crypto.gpg_path
On Tue, Feb 18 2020, Daniel Kahn Gillmor wrote: > crypto.gpg_path was only used when we built against gmime versions > before 3.0. Since we now depend on gmime 3.0.3 or later, it is > meaningless. > > The removal of the field from the _notmuch_config struct would be an > ABI change if that struct were externally exposed, but it is not, so > it's safe to unilaterally remove it. > > Signed-off-by: Daniel Kahn Gillmor > --- > bindings/python-cffi/tests/conftest.py | 2 -- > doc/man1/notmuch-config.rst| 8 > notmuch-config.c | 1 - > 3 files changed, 11 deletions(-) All code removal \o/ ! LGTM. Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] doc: add a hint about field processor support availability
On Sat, Jan 11 2020, Jani Nikula wrote: > In most cases the documentation and the notmuch binary will be built > on the same machine and the same dependencies. Hint at the field > processor support availability in the man page based on the > documentation build host. I have to still grasp the TAGOPTS line in previous and this message =D But, if we already made Xapian 1.4 minimun requirement in the next notmuch release, there XAPIAN_FIELD_PROCESSOR is always supported and all these conditionals could be removed (before even adding new)... Tomi > --- > doc/Makefile.local| 2 +- > doc/man7/notmuch-search-terms.rst | 8 > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/doc/Makefile.local b/doc/Makefile.local > index c78aea49a108..cb01306c0b7c 100644 > --- a/doc/Makefile.local > +++ b/doc/Makefile.local > @@ -9,7 +9,7 @@ DOCBUILDDIR := $(dir)/_build > > # Configure options to be added as Sphinx tags. > # Add "-t " for each make variable in TAGS that equals 1. > -TAGS := WITH_EMACS > +TAGS := WITH_EMACS HAVE_XAPIAN_FIELD_PROCESSOR > TAGOPTS := $(patsubst %=1,-t %,$(filter %=1,$(foreach > tag,$(TAGS),$(tag)=$(value $(tag) > > # Internal variables. > diff --git a/doc/man7/notmuch-search-terms.rst > b/doc/man7/notmuch-search-terms.rst > index 1dd2dc5813f5..9e3b9398c58d 100644 > --- a/doc/man7/notmuch-search-terms.rst > +++ b/doc/man7/notmuch-search-terms.rst > @@ -457,6 +457,14 @@ notmuch was built against a sufficiently recent version > of Xapian by running > >% notmuch config get built_with.field_processor > > +.. only:: HAVE_XAPIAN_FIELD_PROCESSOR > + > + The documentation was built on a host with field processor support. > + > +.. only:: not HAVE_XAPIAN_FIELD_PROCESSOR > + > + The documentation was built on a host without field processor support. > + > Currently the following features require field processor support: > > - non-range date queries, e.g. "date:today" > -- > 2.20.1 > > ___ > notmuch mailing list > notmuch@notmuchmail.org > https://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC PATCH] build: add meson build system
On Sun, Jan 12 2020, Jani Nikula wrote: > On Sun, 12 Jan 2020, David Bremner wrote: >> Jani Nikula writes: >> >>> This is a draft patch adding basic configure, build and test support >>> for the binaries. Everything else is left out for now. It would be a >>> considerable amount of work to convert everything, and I don't expect >>> it to be possible in one go anyway. If there's interest in adding >>> meson support, it would have to happen gradually, side-by-side with >>> the current system, with a reasonably long transition period. But >>> there's no point in going beyond the patch at hand if folks decide the >>> focus should remain on the current system. >> >> Personally I think the idea is worth pursuing, but I admit I don't have >> much experience with meson/ninja. How much churn can we expect from >> meson changes? It seems there is something like one meson point release >> per month. > > I build projects with meson regularly, but I don't develop the build > files on a regular basis. So take this with a grain of salt. But I think > overall the experience has been pleasant. They do keep adding features > all the time, but AFAIK the version currently in e.g. Debian stable is > usable, and the new features don't break existing stuff. > > If you want to hold back to an older version, you might have to put more > effort to things that are easier in newer versions - but the solution > should work in all versions. Any churn would be caused by taking > advantage of the new features. > >> Are the tests supposed to be working fully in this version? When I run >> >> % meson && cd build && ninja && ninja test >> >> I get failures in T010, T351, T356, T357, T391, T395, and T710. At a >> glance it looks like mainly out-of-tree related problems to finding >> e.g. json_check_nodes.py and message-id-parse. It also looks like a few >> variables like TEST_RUBY and NOTMUCH_HAVE_PYTHON3_CFFI are not being >> set. > > I get those failures too, as I haven't bothered with debugging in more > detail yet. I just brought this to a point that mostly works. > > If we decide we can start merging meson support, it's going to be > experimental and not fully featured initially. I think we'd have to > decide what's "good enough". Obviously I think the tests must all pass, > either by fixing the issues or gracefully disabling features. For > example, I don't currently build any of notmuch-emacs or documentation - > they will require custom build rules, while all the C and C++ work out > of the box. > > I think mostly meson support can be added in parallel to the existing > system. Some things might have to be fixed for both, e.g. meson only > works with out-of-tree builds. The annoying part will be the transition > period, where you have to maintain both. And if we decide we'll want > both ad infinitum, it'll be an annoyance ad infinitum... ;) I think there are 2 options 1) make meson build system good enough we can just drop the old system (I can test how well this works on older systems out of the box -- and on my current containerized centos 6 notmuch build system =D) 2) an experimental version is merged, but no-one sending patches is expected to test that it works and someone(tm) can then update it while evolving it to fully supported system... perhaps the version tarballs would not have these so users there don't get confused 3) (the off-by-one-option) everyone is expected to keep the experimental version working while sending patches -- which would jut be painful :/ I personally like (1), but if it is not good enough (2) -- my reason for having (at least) 2 is that it provides me better opportunity to learn meson system =D > BR, > Jani. Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] legacy-display: drop tests that try to match headers in a Legacy Display part
On Mon, Dec 23 2019, Daniel Kahn Gillmor wrote:
> These tests were an attempt to establish that the content of the
> "Legacy Display" part is the same as the actual protected headers of
> the message. But this is more conservative than we need to be.
>
> https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.html
> section 5.3 makes clear that the Legacy Display part is purely
> decorative, and section 5.2.1 clarifies that the detection can be done
> purely by MIME structure and Content-Type alone.
>
> Furthermore, now that we're accepting text/plain Legacy Display parts,
> it's not clear the lines in the Legacy Display part should be
> interpreted as needing an exact string match (e.g. "real" headers are
> likely to be RFC 2047 encoded, but the text/plain Legacy Display part
> probably should not be).
>
> The concerns that motivated this test in the past were twofold: that
> we might accidentally hide some information from the reader of the
> message that they should have available to them, or that we could
> introduce a covert channel that would be invisible to other clients.
>
> I no longer think these are significant concerns:
>
> a) There will be no accidental misidentification of a Legacy Display
> part. The identification of the Legacy Display part is
> unambiguous due to MIME structure and Content-Type. MIME
> structure MUST be the first child part of a two-part
> multipart/mixed Cryptographic Payload. And the
> protected-headers=v1 content-type parameter must be present on
> both the cryptographic payload and the legacy display part, so no
> one would accidentally generate this structure and have it be
> accidentally matched.
>
> b) As for creating a covert channel, many such channels already
> exist. For example, non-standard e-mail headers, custom MIME
> types, unusual MIME structures, etc, all make it possible to ship
> some content in a message that will be visible in some MUAs but
> not in others. This doesn't make the situation demonstrably
> worse.
Looks good to me, and removal of 58 (56) lines of code looks good too...
Tomi
>
> Signed-off-by: Daniel Kahn Gillmor
> ---
> util/repair.c | 60 ++-
> 1 file changed, 2 insertions(+), 58 deletions(-)
>
> diff --git a/util/repair.c b/util/repair.c
> index 4385d16f..6c13601d 100644
> --- a/util/repair.c
> +++ b/util/repair.c
> @@ -27,13 +27,7 @@ _notmuch_crypto_payload_has_legacy_display (GMimeObject
> *payload)
> {
> GMimeMultipart *mpayload;
> const char *protected_header_parameter;
> -GMimeTextPart *legacy_display;
> -char *legacy_display_header_text = NULL;
> -GMimeStream *stream = NULL;
> -GMimeParser *parser = NULL;
> -GMimeObject *legacy_header_object = NULL, *first;
> -GMimeHeaderList *legacy_display_headers = NULL, *protected_headers =
> NULL;
> -bool ret = false;
> +GMimeObject *first;
>
> if (! g_mime_content_type_is_type (g_mime_object_get_content_type
> (payload),
> "multipart", "mixed"))
> @@ -60,57 +54,7 @@ _notmuch_crypto_payload_has_legacy_display (GMimeObject
> *payload)
> if (! GMIME_IS_TEXT_PART (first))
> return false;
>
> -/* ensure that the headers in the first part all match the values
> - * found in the payload's own protected headers! if they don't,
> - * we should not treat this as a valid "legacy-display" part.
> - *
> - * Crafting a GMimeHeaderList object from the content of the
> - * text/rfc822-headers part is pretty clumsy; we should probably
> - * push something into GMime that makes this a one-shot
> - * operation. */
> -if ((protected_headers = g_mime_object_get_header_list (payload),
> protected_headers) &&
> - (legacy_display = GMIME_TEXT_PART (first), legacy_display) &&
> - (legacy_display_header_text = g_mime_text_part_get_text
> (legacy_display), legacy_display_header_text) &&
> - (stream = g_mime_stream_mem_new_with_buffer
> (legacy_display_header_text, strlen (legacy_display_header_text)), stream) &&
> - (g_mime_stream_write (stream, "\r\n\r\n", 4) == 4) &&
> - (g_mime_stream_seek (stream, 0, GMIME_STREAM_SEEK_SET) == 0) &&
> - (parser = g_mime_parser_new_with_stream (stream), parser) &&
> - (legacy_header_object = g_mime_parser_construct_part (parser, NULL),
> legacy_header_object) &&
> - (legacy_display_headers = g_mime_object_get_header_list
> (legacy_header_object), legacy_display_headers)) {
> - /* walk through legacy_display_headers, comparing them against
> - * their values in the protected_headers: */
> - ret = true;
> - for (int i = 0; i < g_mime_header_list_get_count
> (legacy_display_headers); i++) {
> - GMimeHeader *dh = g_mime_header_list_get_header_at
> (legacy_display_headers, i);
> - if (dh == NULL) {
> - ret = false;
> - goto DONE;
> -
Re: message.el and browse-url.el interaction [was: Re: BUG: notmuch-emacs-mua wrong signing MML placement]
On Fri, Dec 13 2019, Tomi Ollila wrote: > On Thu, Dec 12 2019, David Edmondson wrote: > >> On Wednesday, 2019-12-11 at 13:55:16 -05, Robbie Harwood wrote: >> >>> My emacs config contains `(add-hook 'message-setup-hook >>> 'mml-secure-sign-pgpmime)` as recommended in the emacstips >>> https://notmuchmail.org/emacstips/#index14h2 >>> >>> However, when I run (something like): >>> >>> notmuch-emacs-mua 'mailto:testto?body=testbody' >>> >>> I get an email in which the requested body contents appear *before* the >>> signing MML. If I understand correctly how this all fits together, that >>> won't do the right thing - but at any rate, it's unexpected. >> >> This is an unfortunate interaction between message.el and browse-url.el >> and isn't specific to notmuch or notmuch-emacs-mua. >> >> You can see the same behaviour in “emacs -Q -q” if you execute: >> >> (progn >> (add-hook 'message-setup-hook 'mml-secure-sign-pgpmime) >> (browse-url-mail "mailto:fred?body=testbody";)) >> >> Given that, it's not something that we should be fixing in notmuch >> itself, as it's an emacs bug. >> >> The problem is that `browse-url-mail' always inserts the body after the >> header separator, which in this case happens after >> `mml-secure-sign-pgpmime' has already inserted the MML header. >> >> Having `browse-url-mail' insert the body at the end of the message would >> work for this case, but would presumably make a mess of situations where >> someone inserts their signature block via `message-setup-hook'. >> >> Perhaps `browse-url-mail' should skip past any MML headers before >> inserting the body? That's a bit messy, as browse-url.el currently >> doesn't know anything about MML. > > I've never found `browse-url-mail' adequate for handling mailto: links, > so couple of years ago I wrote mailto: "wrapper" of my own (*). It, > among other things, spits the following elisp for emacs to swallow: > > (with-demoted-errors > (require 'notmuch) > (notmuch-mua-mail "fred" nil nil nil > (notmuch-mua-get-switch-function)) > (cd "/home/too/vc/projects/nottoomuch") > (message-goto-body) (insert "testbody") > (goto-char (point-max)) > (if (/= (point) (line-beginning-position)) > (newline)) > (set-buffer-modified-p nil) (message-goto-to)) Small update from my front -- looked message.el and (message-setup-1) there in particular, and then tested the following code: (with-demoted-errors (require 'notmuch) (let ((message-signature-setup-hook message-signature-setup-hook)) (add-hook 'message-signature-setup-hook (lambda () (message-goto-body) (insert "testbody") (if (/= (point) (line-beginning-position)) (newline (notmuch-mua-mail "fred" nil nil nil (notmuch-mua-get-switch-function)) )) This has moderate chance of working, so I'll have to think it a bit further (and clean up the code =D)... > > Surprise! this has exactly the same problems as David explains above; I > could add code to check for this [#part sign=pgpmime] (**) and skip it if > it exists (and, as first step, not look for anything else to skip). That > is just so hacky and error prone I would not like to do so (at least as > a general solution)... > >> >> The nicest fix would perhaps be to have `compose-mail' accept the >> initial body as a parameter, which would eventually flow into the >> relevant code in message.el which could do the right thing (which I >> think would just be to skip past MML headers before inserting the body). > > This suggestion of an optional parameter to take initial body sounds > very good solution (as first sight =D), so if I don't come up with > any other suggestions +1 for that.. > >> >> Any advice from emacs-devel on how to move forward? I'm happy to produce >> a patch for whatever solution is considered most appropriate. >> >> dme. >> -- >> If the girls start moving the boys will start moving. > > Tomi > > (*) > https://github.com/domo141/nottoomuch/blob/master/nottoomuch-emacs-mailto.rst > > (**) replace [...] with <...> ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: compacting the notmuch database through systemd
On Sun, Dec 08 2019, David Bremner wrote: > Jorge P. de Morais Neto writes: > >> Em [2019-12-06 sex 14:41:22-0500], Daniel Kahn Gillmor escreveu: >> >>> As for the variations, i'm kind of of a mind that people who deviate >>> from the defaults should need to maintain their own deviance explicitly, >>> rather than trying to accomodate a non-default path in shipped config >>> files. For example, "systemctl --user edit notmuch-compact.timer" helps >>> you drop in the appropriate override/modification. >> >> But ~/.config is the XDG standard, so maybe it deserves special >> consideration. >> > > It would make more sense to have notmuch actually support > XDG_CONFIG_DIR. Alas, config changes seems to be hard / not rewarding. This has been tried quite a few times (also) in notmuch mailing list so far; search 'config and notmuch and xdg' in my active mailstorage shows: first mentioned 2011-06-24 first RFC suggestion: 2011-12-21 so far last WIP patch (from bremner): 2017-12-30 "simplest" would be just get rid of the config file and use only database... Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: message.el and browse-url.el interaction [was: Re: BUG: notmuch-emacs-mua wrong signing MML placement]
On Thu, Dec 12 2019, David Edmondson wrote: > On Wednesday, 2019-12-11 at 13:55:16 -05, Robbie Harwood wrote: > >> My emacs config contains `(add-hook 'message-setup-hook >> 'mml-secure-sign-pgpmime)` as recommended in the emacstips >> https://notmuchmail.org/emacstips/#index14h2 >> >> However, when I run (something like): >> >> notmuch-emacs-mua 'mailto:testto?body=testbody' >> >> I get an email in which the requested body contents appear *before* the >> signing MML. If I understand correctly how this all fits together, that >> won't do the right thing - but at any rate, it's unexpected. > > This is an unfortunate interaction between message.el and browse-url.el > and isn't specific to notmuch or notmuch-emacs-mua. > > You can see the same behaviour in “emacs -Q -q” if you execute: > > (progn > (add-hook 'message-setup-hook 'mml-secure-sign-pgpmime) > (browse-url-mail "mailto:fred?body=testbody";)) > > Given that, it's not something that we should be fixing in notmuch > itself, as it's an emacs bug. > > The problem is that `browse-url-mail' always inserts the body after the > header separator, which in this case happens after > `mml-secure-sign-pgpmime' has already inserted the MML header. > > Having `browse-url-mail' insert the body at the end of the message would > work for this case, but would presumably make a mess of situations where > someone inserts their signature block via `message-setup-hook'. > > Perhaps `browse-url-mail' should skip past any MML headers before > inserting the body? That's a bit messy, as browse-url.el currently > doesn't know anything about MML. I've never found `browse-url-mail' adequate for handling mailto: links, so couple of years ago I wrote mailto: "wrapper" of my own (*). It, among other things, spits the following elisp for emacs to swallow: (with-demoted-errors (require 'notmuch) (notmuch-mua-mail "fred" nil nil nil (notmuch-mua-get-switch-function)) (cd "/home/too/vc/projects/nottoomuch") (message-goto-body) (insert "testbody") (goto-char (point-max)) (if (/= (point) (line-beginning-position)) (newline)) (set-buffer-modified-p nil) (message-goto-to)) Surprise! this has exactly the same problems as David explains above; I could add code to check for this [#part sign=pgpmime] (**) and skip it if it exists (and, as first step, not look for anything else to skip). That is just so hacky and error prone I would not like to do so (at least as a general solution)... > > The nicest fix would perhaps be to have `compose-mail' accept the > initial body as a parameter, which would eventually flow into the > relevant code in message.el which could do the right thing (which I > think would just be to skip past MML headers before inserting the body). This suggestion of an optional parameter to take initial body sounds very good solution (as first sight =D), so if I don't come up with any other suggestions +1 for that.. > > Any advice from emacs-devel on how to move forward? I'm happy to produce > a patch for whatever solution is considered most appropriate. > > dme. > -- > If the girls start moving the boys will start moving. Tomi (*) https://github.com/domo141/nottoomuch/blob/master/nottoomuch-emacs-mailto.rst (**) replace [...] with <...> ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Add notmuch-wash-citation-lines-elided-min and use it
On Thu, Dec 12 2019, David Edmondson wrote: > When collapsing citations, if the collapsed region is less than > `notmuch-wash-citation-lines-elided-min' lines long, don't bother > collapsing it and simply show all of the lines. LGTM. Tomi > --- > emacs/notmuch-wash.el | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el > index 54108d93..556fd2ab 100644 > --- a/emacs/notmuch-wash.el > +++ b/emacs/notmuch-wash.el > @@ -117,6 +117,13 @@ collapse the remaining lines into a button." >:type 'integer >:group 'notmuch-wash) > > +(defcustom notmuch-wash-citation-lines-elided-min 1 > + "When collapsing a citation would remove less than > +`notmuch-wash-citation-lines-elided-min' lines, no collapsing > +takes place." > + :type 'integer > + :group 'notmuch-wash) > + > (defcustom notmuch-wash-wrap-lines-length nil >"Wrap line after at most this many characters. > > @@ -241,7 +248,7 @@ that PREFIX should not include a newline." >(overlay-put (make-overlay cite-start cite-end) 'face > 'notmuch-wash-cited-text) >(when (> cite-lines (+ notmuch-wash-citation-lines-prefix >notmuch-wash-citation-lines-suffix > - 1)) > + notmuch-wash-citation-lines-elided-min)) > (goto-char cite-start) > (forward-line notmuch-wash-citation-lines-prefix) > (let ((hidden-start (point-marker))) > -- > 2.24.0 > > ___ > notmuch mailing list > notmuch@notmuchmail.org > https://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: More debian packaging cleanup
On Wed, Dec 04 2019, Daniel Kahn Gillmor wrote: > This series should apply after "wrap-and-sort -ast" v2 is applied > (id:20191110173748.25792-5-...@fifthhorseman.net). > > In this series, i clean up a few things that i noticed from applying > dh_missing to the debian packaging. In particular, we were failing to > ship notmuch(3) (programmer's manual for libnotmuch) and > notmuch-setup(1) (a symlink or copy of notmuch(1) that is referenced > in notmuch-config(1)). > > This doesn't get us to the point of enabling dh 12 cleanly yet (more > elpa-notmuch cleanup might be blocked on #946142 and answers to the > questions i raised in id:87a7887akl@fifthhorseman.net), but it's > a lot of the way there. > > Comments and feedback welcome! As far as I understand this series looks good to me. Tomi > > --dkg > ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Python3 cffi bindings
On Sat, Nov 16 2019, David Bremner wrote: > Gaute Hope writes: > >> >> By the way, it does not seem that the API is very far from the >> previous python API. If it is close enough, perhaps it is possible to >> get away with a bug version bump in the bindings rather than creating >> a new package. I understand the need for a new package, but it would >> be nice if we could avoid the future confusion of two python binding >> packages (if at all possible). >> > > I'm not in a good position to judge how similar the APIs are. It does > seem like there are at least some breaking changes, and we usually try > to make things smooth for people upgrading by deprecating interfaces > before removing them completely. On the other hand our previous concern > for supporting python pre 3.6 (I think. Maybe 3.5?) seems less and less > worrying (except maybe for people using old CentOS like things). Currently such a recent Linux distribution as Ubuntu 16.04 LTS is not new enough to be used as is when compiling latest notmuch from git (or 0.29), as GMIME 3.0 is required (Ubuntu 16.04 ships GMIME 2.6 and Python 3.5). GMIME 2.6 was pretty easy to compile, GMIME 3 is a bit harder... Ubuntu 16.04 LTS ships python 3.5 -- and compiling later Pythons is easier than GMIME 3 (done both, GMIME 3 on CentOS 6, Python 3.7 on CentOS 7). So, IMO not supporting python pre 3.6 is fine, as we already reguire gmime 3 and probably soon xapian 1.4 -- distros that ship gmime3 most probably already ship python 3.6... Tomi > > d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] lib: fix memory error in notmuch_config_list_value
On Sun, Nov 24 2019, David Bremner wrote:
> The documentation for notmuch_config_list_key warns that that the
> returned value will be destroyed by the next call to
> notmuch_config_list_key, but it neglected to mention that calling
> notmuch_config_list_value would also destroy it (by calling
> notmuch_config_list_key). This is surprising, and caused a use after
> free bug in _setup_user_query_fields (first noticed by an OpenBSD
> porter, so kudos to the OpenBSD malloc implementation). This change
> fixes that use-after-free bug.
> ---
> lib/config.cc | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/lib/config.cc b/lib/config.cc
> index da71c16e..2cd8a0b6 100644
> --- a/lib/config.cc
> +++ b/lib/config.cc
> @@ -150,13 +150,17 @@ notmuch_config_list_valid (notmuch_config_list_t
> *metadata)
> return true;
> }
>
> +static inline char * _key_from_iterator (notmuch_config_list_t *list) {
> +return talloc_strdup (list, (*list->iterator).c_str () +
> CONFIG_PREFIX.length ());
> +}
> +
> const char *
> notmuch_config_list_key (notmuch_config_list_t *list)
> {
> if (list->current_key)
> talloc_free (list->current_key);
>
> -list->current_key = talloc_strdup (list, (*list->iterator).c_str () +
> CONFIG_PREFIX.length ());
> +list->current_key = _key_from_iterator (list);
>
> return list->current_key;
> }
> @@ -166,7 +170,7 @@ notmuch_config_list_value (notmuch_config_list_t *list)
> {
> std::string strval;
> notmuch_status_t status;
> -const char *key = notmuch_config_list_key (list);
> +char *key = _key_from_iterator (list);
2 spaces, otherwise looks good (on paper)
Tomi
>
> /* TODO: better error reporting?? */
> status = _metadata_value (list->notmuch, key, strval);
> @@ -177,6 +181,7 @@ notmuch_config_list_value (notmuch_config_list_t *list)
> talloc_free (list->current_val);
>
> list->current_val = talloc_strdup (list, strval.c_str ());
> +talloc_free (key);
> return list->current_val;
> }
>
> --
> 2.24.0
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Tests failing on master
On Sun, Nov 17 2019, David Bremner wrote: > Yes, being root would break some of the tests, e.g. those that rely on > removing permissions to generate an error. Probably we should just > document that running the test suite as root is not supported? If > someone can explain a good reason to run as root (maybe some odd > auto-builder, the tests in question could probably be modified to do > something more extreme (e.g. delete a file) rather than chmod. Yes, rootless podman containers! if I run e.g $ podman run --rm -it -v $HOME:$HOME -w $HOME/vc/ext/notmuch \ notmuch-buildenv-debian10: /bin/zsh [root@e489c80816a9 notmuch]# id uid=0(root) gid=0(root) groups=0(root) [root@e489c80816a9 notmuch]# pwd /home/too/vc/ext/notmuch [root@e489c80816a9 build]# ls -l configure -rwxr-xr-x. 1 root root 41920 Nov 17 21:00 configure [root@e489c80816a9 build]# exit $ ls -l $HOME/vc/ext/notmuch/configure -rwxr-xr-x. 1 too too 41920 Nov 17 23:00 /home/too/vc/ext/notmuch/configure $ podman unshare cat /proc/self/uid_map 0 1000 1 1 10 65536 The last line, would have had same results if run inside container, tells that uid 0 (root) inside container was mapped to uid 1000 (too) outside, on "host" side, and 1 uid was mapped, from uid 1 onwards in container, uids are mapped starting from 10 outside. All that means, that I can do, without sudo, all kinds of things when using this container technology. Files owned by my uid outside container are seen as owned by root inside container. Since last spring, I've been gradually moving all things I used docker to podman. And everything has (in my use cases) worked better. In Fedora it just works (already). In Ubuntu 16.04 and RHEL 7.7 it also worked when I tried, but lack of fuse-overlayfs makes it slow (to start) in these systems. I hope every system in 2020 has good podman support... All that long text written, I can take care notmuch tests can be run on podman containers... > > cheers, > > d YEA, Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Display extra headers for emacs-mua - db config option
On Fri, Nov 22 2019, Daniel Kahn Gillmor wrote: > On Thu 2019-11-21 08:27:04 -0400, David Bremner wrote: >> Apologies for being late to the discussion of where to store the >> configuration. So far we have only stored configuration in the database >> where it affected the behaviour of the library API. > > While i'm being ambitious, i'd like also to eventually consider moving > more of the existing CLI functionality into being accessible from the > library. I think this would help downstream MUAs that use notmuch who > currently can't (or don't want to, for whatever reason) take advantage > of the existing CLI, but can use the library. > > If we stuff more config in the config file, then the behavior of any > future move to the library will have to grapple with the config move > (currently the library never reads the config file, it just opens the > database). How can library open the database if it doesn't read the config file -- the config file defines where database is located =D >> I know some people (e.g. dkg) have suggested it would be better to >> store all of the configuration in the database for consistency, while >> others are disgruntled that some of the configuration is not editable >> with text editor. > > It would still editable with a text editor -- you just need to edit the > output of "notmuch dump --include config" and feed the result back into > "notmuch restore" :) If the library can somehow guess the location of the database without reading the config file ;D I think dumping -- editing -- restoring the database is tolerable solution -- provided it is clearly documented for people like me who wants to edit configuration files w/ text editor(*), for forgets these instructions easily. If, in the future, we still have configuration file(+), notmuch could also write such instructions to the config file. > > --dkg Tomi (*) like someone may know I'm not too fond of editing configuration files when there are alternatives available (like in this case) -- however is someone else(tm) takes the time to create this solution and it uses configuration files, I'll use it... (+) if we dropped the configuration file, then notmuch, and library could open database from ~/mail/notmuch/ by default, or from location pointed by e.g. NOTMUCH_DATABASE_DIR -- as an additional benefit(?) notmuch would pollute user's $HOME by one file less -- the `.notmuch-config`. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] configure: fix reference to possibly undefined $PKG_CONFIG_PATH
In case zlib not found by pkg-config(1) the pkg-config information
is resolved by attempting to print ZLIB_VERSION from from zlib
installation if it exists anyway.
If above done successfully compat/zlib.pc is written for forthcoming
pkg-config execution.
Since `set -u` is in effect (since 124a67e96, 2016-05-06),
expanding unset $PKG_CONFIG_PATH (would have) failed whenever tried.
Now it is changed to set as "$PKG_CONFIG_PATH:compat" if PKG_CONFIG_PATH
is set and is non-empty string, plain "compat" otherwise.
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 2160be37..00a9d03d 100755
--- a/configure
+++ b/configure
@@ -606,7 +606,7 @@ fi
if ! pkg-config --exists zlib; then
${CC} -o compat/gen_zlib_pc "$srcdir"/compat/gen_zlib_pc.c >/dev/null 2>&1 &&
compat/gen_zlib_pc > compat/zlib.pc &&
- PKG_CONFIG_PATH="$PKG_CONFIG_PATH":compat &&
+ PKG_CONFIG_PATH=${PKG_CONFIG_PATH:+$PKG_CONFIG_PATH:}compat &&
export PKG_CONFIG_PATH
rm -f compat/gen_zlib_pc
fi
--
2.23.0
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Display extra headers for emacs-mua - db config option
On Sat, Nov 16 2019, Johan Parin wrote:
> Modify format_headers_sprinter so that it returns some additional headers
> in the
> sexp, instead of a small fixed set of headers.
>
> The extra header list is configured by the database config option
> `show.extra_headers'.
>
> This is required in order for the elisp variable
> `notmuch-message-headers' to work.
I did not look the patch, but if there is going to be configuration option
(either in config file, or in database), this way is (IMO) the most
sensible alternative (add to the default options) -- no "full list" or
"suppress header" options.
Tomi
>
> See this bug report:
>
> https://notmuchmail.org/pipermail/notmuch/2017/026069.html
> ---
> doc/man1/notmuch-config.rst | 6 ++
> notmuch-config.c| 7 ---
> notmuch-show.c | 41 -
> 3 files changed, 50 insertions(+), 4 deletions(-)
>
> diff --git a/doc/man1/notmuch-config.rst b/doc/man1/notmuch-config.rst
> index 28487079..0eb59883 100644
> --- a/doc/man1/notmuch-config.rst
> +++ b/doc/man1/notmuch-config.rst
> @@ -204,6 +204,12 @@ The available configuration items are described below.
> supported. See **notmuch-search-terms(7)** for a list of existing
> prefixes, and an explanation of probabilistic prefixes.
>
> +**show.extra_headers**
> +A list of extra headers that will be output by **notmuch show**
> +with ``--format=sexp``, if present in the message.
> +
> +Default: empty list.
> +
> **built_with.**
> Compile time feature . Current possibilities include
> "compact" (see **notmuch-compact(1)**) and "field_processor" (see
> diff --git a/notmuch-config.c b/notmuch-config.c
> index 1b079e85..6554ad9b 100644
> --- a/notmuch-config.c
> +++ b/notmuch-config.c
> @@ -841,9 +841,10 @@ typedef struct config_key {
>
> static struct config_key
> config_key_table[] = {
> -{ "index.decrypt", true, false, NULL },
> -{ "index.header.", true, true, validate_field_name },
> -{ "query.", true, true, NULL },
> +{ "index.decrypt", true, false, NULL },
> +{ "index.header.", true, true, validate_field_name },
> +{ "query.", true, true, NULL },
> +{ "show.extra_headers", true, false, NULL }
> };
>
> static config_key_info_t *
> diff --git a/notmuch-show.c b/notmuch-show.c
> index 21792a57..4c77468f 100644
> --- a/notmuch-show.c
> +++ b/notmuch-show.c
> @@ -18,11 +18,16 @@
> * Author: Carl Worth
> */
>
> +#include
> +
> #include "notmuch-client.h"
> #include "gmime-filter-reply.h"
> #include "sprinter.h"
> #include "zlib-extra.h"
>
> +static notmuch_database_t *notmuch = NULL;
> +
> +
> static const char *
> _get_tags_as_string (const void *ctx, notmuch_message_t *message)
> {
> @@ -195,6 +200,38 @@ _is_from_line (const char *line)
> return 0;
> }
>
> +/* Output extra headers if configured with the `show.extra_headers'
> + * database configuration option
> + */
> +void
> +format_extra_headers_sprinter (sprinter_t *sp, GMimeMessage *message)
> +{
> +GMimeHeaderList *header_list;
> +GMimeHeader *header;
> +char *extra_headers, *tofree, *header_name;
> +
> +if (notmuch == NULL)
> + return;
> +
> +if (notmuch_database_get_config (notmuch, "show.extra_headers",
> + &extra_headers) != NOTMUCH_STATUS_SUCCESS)
> + return;
> +
> +header_list = g_mime_object_get_header_list (GMIME_OBJECT(message));
> +
> +tofree = extra_headers;
> +while ( (header_name = strsep(&extra_headers, ";")) != NULL) {
> +
> + header = g_mime_header_list_get_header (header_list, header_name);
> + if (header == NULL)
> + continue;
> +
> + sp->map_key (sp, g_mime_header_get_name(header));
> + sp->string (sp, g_mime_header_get_value(header));
> +}
> +free (tofree);
> +}
> +
> void
> format_headers_sprinter (sprinter_t *sp, GMimeMessage *message,
>bool reply, const _notmuch_message_crypto_t
> *msg_crypto)
> @@ -253,6 +290,9 @@ format_headers_sprinter (sprinter_t *sp, GMimeMessage
> *message,
> } else {
> sp->map_key (sp, "Date");
> sp->string (sp, g_mime_message_get_date_string (sp, message));
> +
> + /* Output extra headers the user has configured in the database, if any
> */
> + format_extra_headers_sprinter (sp, message);
> }
>
> sp->end (sp);
> @@ -1152,7 +1192,6 @@ static const notmuch_show_format_t *formatters[] = {
> int
> notmuch_show_command (notmuch_config_t *config, int argc, char *argv[])
> {
> -notmuch_database_t *notmuch;
> notmuch_query_t *query;
> char *query_string;
> int opt_index, ret;
> --
> 2.21.0 (Apple Git-122)
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mai
Re: [PATCH] Add --message-headers flag to notmuch-show
On Thu, Nov 14 2019, Daniel Kahn Gillmor wrote:
> On Wed 2019-11-13 01:30:50 +0200, Tomi Ollila wrote:
>> On Tue, Nov 12 2019, Daniel Kahn Gillmor wrote:
>>
>>> And, I still haven't heard any clear arguments for choosing between
>>> configurability as an absolute thing or a differential thing. They have
>>> significantly different impact on adopters over time, as the default
>>> configuration changes.
>>
>> I don't understand your question,
>
> configurability as an absolute thing:
>
> --message-headers=foo,bar,baz
>
> configurability as a differential thing:
>
> --add-message-header=foo --suppress-message-header=qux
Ahh...
Osmo A. Wiio was a smart man when he stated: "Communication usually fails,
except by accident" ( http://jkorpela.fi/wiio.html - read it now, I'll wait ).
I understand 'configurability' a bit different way -- store something
somewhere which is fetched in the future and alters behaviuor in that
way.
In above options, --message-headers and so on, I'd just "state" or "demand"
the program in question to give me this information, and don't think there
was any configurability in question ('configuration', in "broader" sense,
is there, just hiding somewhere in background =D)
>
>> but I think that configuration option
>> for choosing what message headers to return is far worst of the options,
>> mostly because configuration and what frontend may desire goes easily
>> out if sync (and when managed manually that is what inevitably will
>> happen).
>
> totally agreed, but this is very different from what you said next:
>
>> The option (b) is kinda my favorite, code could be pretty simple, ordering
>> (sprinted in order listed), duplicates (rescan request list so far and drop
>> if header found) might be the harders questions (and seemed not ;/).
>>
>> If option (b) were taken, status quo -- no change in returned headers
>> should be maintained -- separate patch series w/ devel/schemata and test
>> changes can be sent is there desire for changing that.
>
> afaict, option (b) seems to contemplate configurability, which you say
> above you don't want. Maybe we need a clearer list of options, because
> this is getting confusing :P
Perhaps my explanation above cleared at least a bit of confusion.
W/ all this information, somewhat exhaustive (not by options, but by
resources I put making it) list of thougts.
1a by default behave as it is behaving now
1b alternative, in json and sexp, include *all* headers for the use of
frontends (in many other email systems frontends parse full email
messages and see all headers, in notmuch case frontends don't have
to do so since notmuch did the parsing and provides structured data
of (currently subset) that information
2a have option --message-headers= -- when used just those headers requested
is returned (I'd personally prefer this over the "differential" options,
frontends get exactly what it wants and does not need to consider any
default where to add of suppress from)
2b have --add-message-header=foo --suppress-message-header=qux -- to modify
the defult list...
2c have named stored configurations, which can be retrieved with yet another
command line option, since naming is hard, quick potenttially dumb
example could be like: --custom-message-headers=my-cli-headers-set-3
I personally would first go with 1a and 2a. 2c sounds interesting but
requires more work (and I could personally use wrapper instead =D)
Anyway, if someone(tm) implements any of these, speed is not a problem, and
code is reasonably maintainable happy to see notmuch improved this way...
>
> --dkg
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: python CFFI bindings integration into notmuch build/test
On Thu, Nov 14 2019, Floris Bruynooghe wrote:
> Hi,
>
> Thanks for carrying on with this!
>
> I'm a little confused with how to follow this, is the current state of
> the code somewhere in a repo/branch where I can try things out and make
> changes from?
In git://notmuchmail.org/git/notmuch David has ref origin/wip/cffi
which contains related changes -- You can fetch the code while waiting
for more collaboration instructions from David.
> On Tue 05 Nov 2019 at 22:22 -0400, David Bremner wrote:
>
>> Tomi Ollila writes:
>>
>>
>>> alternative:
>>>
>>>...
>>>print('Invoking: {}'.format(' '.join(cmd)))
>>>
>>>def preexec_fn(): os.environ['NOTMUCH_CONFIG'] = str(cfg_fname)
>>>
>>>proc = subprocess.run(cmd, timeout=5, preexec_fn=preexec_fn)
>>>...
>>>
>>> The unix fork ... (here preexec_fn called in child) ... exec model is
>>> superior to any other alternative ! =D
>>
>> I don't consider myself a good judge of python style, so I'll defer to
>> Floris on that one.
>
> I'd have gone with what David wrote to be fair, mostly because it's
> pretty simple to see what's going on where for the preexec_fn I'd have
> to look at the docs. Not sure if this has much to do with Python style
> though, more with how much you like Unix tricks.
Yes, the simple approach taken (by env copy) is fine. It is also good to
know these powerful alternatives that may be useful elsewhere =D
>
>
> Cheers,
> Floris
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add --message-headers flag to notmuch-show
On Tue, Nov 12 2019, Daniel Kahn Gillmor wrote: > > And, I still haven't heard any clear arguments for choosing between > configurability as an absolute thing or a differential thing. They have > significantly different impact on adopters over time, as the default > configuration changes. I don't understand your question, but I think that configuration option for choosing what message headers to return is far worst of the options, mostly because configuration and what frontend may desire goes easily out if sync (and when managed manually that is what inevitably will happen). > So, of the three options you list, i far prefer (a) because it doesn't > introduce any of the configurability maintenance or API complexity > costs. > If the main objection to (a) is performance regression, i'd like to see > some profiling of that performance cost, so we can better understand it. > Perhaps there's a different way to mitigate a performance regression. I'd guess it depends how frontends spend time parsing json/sexp output. I would not expect raw C code to be bottleneck, don't know how gmime spends time fetching header data on user request... The option (b) is kinda my favorite, code could be pretty simple, ordering (sprinted in order listed), duplicates (rescan request list so far and drop if header found) might be the harders questions (and seemed not ;/). If option (b) were taken, status quo -- no change in returned headers should be maintained -- separate patch series w/ devel/schemata and test changes can be sent is there desire for changing that. > > --dkg Tomi ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Fix format_headers_sprinter to return all headers (v2)
On Sun, Nov 10 2019, David Edmondson wrote:
> On Saturday, 2019-11-09 at 23:13:58 +01, Johan Parin wrote:
>
>> +const char* interesting_headers[] = { + "Maildir",
>> "Mailing-list", "Tags", "Attachments", "Signature", +
>> "Decryption", "User-agent", "X-Mailer"};
>
> It would be convenient to specify these in ~/.notmuch-config
> rather than hard-coding them (or specifying them as command line
> arguments).
If we take the command line option approach, then the frontend can
request the headers, and have it configured in one location
(setting notmuch-message-headers in emacs affects how emacs mua
calls notmuch-show)...
Also, different frontends may have different usable headers, for
example `X-Face:` probably only works w/ emacs mua =D
Tomi
>
> dme.
> --
> And you can't hold me down, 'cause I belong to the hurricane.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Fix format_headers_sprinter to return all headers (v2)
Subject line not updated
On Sat, Nov 09 2019, Johan Parin wrote:
> So this version only returns a fixed limited set of extra
> headers. Hopefully this eliminates any concern for a performance
> penalty. Of course it limits the usefulness of the
> notmuch-message-headers variable.
headers to request based on command line parameter (and default to current
set) could be an option (kinda Jani already suggested). Quick (not perhaps
well thought) one could be:
--message-headers=To,Cc,X-Face
and in the other mail -- mostly style comments (for future reference)
On Sat, Nov 09 2019, Johan Parin wrote:
> Modify format_headers_sprinter so that it returns some additional headers in
> the
> sexp, instead of a small fixed set of headers.
>
> This version includes the following headers:
>
> - Maildir
> - Mailing-list
> - Tags
> - Attachments
> - Signature
> - Decryption
> - User-agent
> - X-Mailer
>
> This is required in order for the elisp variable
> `notmuch-message-headers' to work to some extent.
>
> See this bug report:
>
> https://notmuchmail.org/pipermail/notmuch/2017/026069.html
> ---
> notmuch-show.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/notmuch-show.c b/notmuch-show.c
> index 21792a57..86ddb491 100644
> --- a/notmuch-show.c
> +++ b/notmuch-show.c
> @@ -205,6 +205,12 @@ format_headers_sprinter (sprinter_t *sp, GMimeMessage
> *message,
> char *recipients_string;
> const char *reply_to_string;
> void *local = talloc_new (sp);
> +GMimeHeaderList *header_list;
> +GMimeHeader *header;
could be dropped here and had only in scope where it is used below...
> +const char* interesting_headers[] = {
> + "Maildir", "Mailing-list", "Tags", "Attachments", "Signature",
> + "Decryption", "User-agent", "X-Mailer"};
> +const int interesting_header_count = sizeof(interesting_headers) /
> sizeof(char *);
more "idiomatic" could be ... sizeof (interesting_headers) / sizeof
(interesting_headers[0]);
> sp->begin_map (sp);
>
> @@ -255,6 +261,19 @@ format_headers_sprinter (sprinter_t *sp, GMimeMessage
> *message,
> sp->string (sp, g_mime_message_get_date_string (sp, message));
> }
>
> +header_list = g_mime_object_get_header_list (GMIME_OBJECT(message));
two (2) spaces, then no space after GMIME_OBJECT
> +
> +for (int i = 0; i < interesting_header_count; i++) {
> +
... here GMimeHeader *header; is only used
> + header = g_mime_header_list_get_header(
> + header_list, interesting_headers[i]);
> + if (header == NULL)
> + continue;
> +
> + sp->map_key (sp, g_mime_header_get_name(header));
> + sp->string (sp, g_mime_header_get_value(header));
spaces before '('
> +}
> +
> sp->end (sp);
> talloc_free (local);
> }
> --
> 2.21.0 (Apple Git-122)
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 4/5] tests: run python-cffi tests
On Fri, Nov 08 2019, David Bremner wrote:
> Tomi Ollila writes:
>
>>
>> Right -- just that pytest-3 may not be available -- to iterate (tested)...
>>
>> if ${NOTMUCH_PYTHON} -m pytest -c $conf --version >/dev/null 2>&1; then
>>
>
> The problem with this is that it might pass if pytest is only installed
> for python2.
What is the minimum python3 version supported -- In the previous email thread
all
references show python 3.7
Anyway, in that wip/cffi "branch" commit 97caf16c15d (check for python cffi
module)
could also include check for minimum python version, e.g.
+printf "Checking for python 3 cffi... "
+if "${NOTMUCH_PYTHON}" -c 'import sys,cffi; assert sys.version_info >= (3,7)'
2>/dev/null; then
+printf "Yes.\n"
+have_python3_cffi=1
+else
+printf "No.\n"
+have_python3_cffi=0
+fi
(adjust (3,7) above to any suitable smaller value =D)
Tomi
>
>> (in this particular case redirecting both stdout and stderr is needed
>> to silence noise in all 'ordinary' cases, being
>>1) pytest module not available -- silence stderr
>>2) pytest version not new enough -- silence stderr
>>3) pytest exists and is new enought -- silence stdout )
>
> agreed
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 4/5] tests: run python-cffi tests
On Tue, Nov 05 2019, David Bremner wrote:
> Tomi Ollila writes:
>
>
>>
>> probably
>>
>> test_expect_success "${NOTMUCH_PYTHON} -m pytest \
>> --log-file=$TMP_DIRECTORY/test.output \
>> $NOTMUCH_SRCDIR/bindings/python-cffi/build/stage"
>>
>> worked (which reminds me out-of-tree... ;)
>>
>
> despite looking prettier this does not work because it looks for the
> "notdb" module in the current directory. It could work (maybe) if we set
> PYTHONPATH. Would that be better than the 'cd'?
So that would basically be:
test_expect_success "PYTHONPATH=$PWD${PYTHONPATH:+:$PYTHONPATH} \
${NOTMUCH_PYTHON} -m pytest \
--log-file=$TMP_DIRECTORY/test.output \
$NOTMUCH_SRCDIR/bindings/python-cffi/build/stage"
(if it worked)
perhaps 'cd' in subshell is clearer
(i also wonder what --rootdir= does (and how new pytest is needed for that)
>> It prints the version, then exists. Could not figure out how to request
>> specific version in quick look (10 min search/trial/error session),
>> parsing version output is so... :/
>
> I think something like
>
> conf=$(mktemp)
> printf "[pytest]\nminversion=3.0\n" > $conf
> if pytest-3 -c $conf --version >/dev/null; then
>have_pytest=1
> else
>have_pytest=0
> fi
> rm -f $(conf)
>
> should work.
Right -- just that pytest-3 may not be available -- to iterate (tested)...
if ${NOTMUCH_PYTHON} -m pytest -c $conf --version >/dev/null 2>&1; then
(in this particular case redirecting both stdout and stderr is needed
to silence noise in all 'ordinary' cases, being
1) pytest module not available -- silence stderr
2) pytest version not new enough -- silence stderr
3) pytest exists and is new enought -- silence stdout )
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: python CFFI bindings integration into notmuch build/test
On Sun, Nov 03 2019, David Bremner wrote:
>
> @@ -32,10 +33,11 @@ def notmuch(maildir):
> """
> cfg_fname = maildir.path / 'notmuch-config'
> cmd = ['notmuch'] + list(args)
> -print('Invoking: {}'.format(' '.join(cmd)))
> +env = os.environ.copy()
> +env['NOTMUCH_CONFIG'] = str(cfg_fname)
> proc = subprocess.run(cmd,
>timeout=5,
> - env={'NOTMUCH_CONFIG': str(cfg_fname)})
> + env=env)
Tried lambda (to have preexe_fn have cfg_fname in context), did not work,
nested function also seems to hold context:
alternative:
...
print('Invoking: {}'.format(' '.join(cmd)))
def preexec_fn(): os.environ['NOTMUCH_CONFIG'] = str(cfg_fname)
proc = subprocess.run(cmd, timeout=5, preexec_fn=preexec_fn)
...
The unix fork ... (here preexec_fn called in child) ... exec model is
superior to any other alternative ! =D
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 4/5] tests: run python-cffi tests
On Mon, Nov 04 2019, Tomi Ollila wrote: > > as for checking pytest existence, the following works somewhat: > >~/test-venv/bin/python3 -m pytest --version > > It prints the version, then exists. Could not figure out how to request > specific version in quick look (10 min search/trial/error session), > parsing version output is so... :/ Hah, dumped ~/test-venv/. so retry... $ python3 -m venv ~/test-venv $ ~/test-venv/bin/pip3 install pytest $ ~/test-venv/bin/python3 >>> import pytest >>> dir(pytest) >>> pytest.__version__ prints out '5.2.2'. argh, string again (in addition to resorting to __...__ names/attributes of whatever these are called in python ;). anyway, even parsing this version string in python than doing it in shell script would be better...(*) anything better ? Tomi (*) got exhausted when looking through this: https://stackoverflow.com/questions/11887762/how-do-i-compare-version-numbers-in-python ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 4/5] tests: run python-cffi tests
On Sun, Nov 03 2019, David Bremner wrote:
> The entire python-cffi test suite is considered as a single test at
> the level of the notmuch test suite. This might or might not be ideal,
> but it gets them run.
> ---
> test/T391-python-cffi.sh | 12
> 1 file changed, 12 insertions(+)
> create mode 100755 test/T391-python-cffi.sh
>
> diff --git a/test/T391-python-cffi.sh b/test/T391-python-cffi.sh
> new file mode 100755
> index ..a03f9e0e
> --- /dev/null
> +++ b/test/T391-python-cffi.sh
> @@ -0,0 +1,12 @@
> +#!/usr/bin/env bash
> +test_description="python bindings (pytest)"
> +. $(dirname "$0")/test-lib.sh || exit 1
> +
> +if [ $NOTMUCH_HAVE_PYTHON_CFFI -eq 0 ]; then
> +test_done
> +fi
> +
> +
> +test_begin_subtest "python cffi tests"
> +test_expect_success "(cd $NOTMUCH_SRCDIR/bindings/python-cffi/build/stage &&
> ${NOTMUCH_PYTHON} -m pytest --log-file=$TMP_DIRECTORY/test.output)"
probably
test_expect_success "${NOTMUCH_PYTHON} -m pytest \
--log-file=$TMP_DIRECTORY/test.output \
$NOTMUCH_SRCDIR/bindings/python-cffi/build/stage"
worked (which reminds me out-of-tree... ;)
as for checking pytest existence, the following works somewhat:
~/test-venv/bin/python3 -m pytest --version
It prints the version, then exists. Could not figure out how to request
specific version in quick look (10 min search/trial/error session),
parsing version output is so... :/
> +test_done
> --
> 2.24.0.rc1
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 3/5] build: optionally build python-cffi bindings
On Sun, Nov 03 2019, David Bremner wrote:
> Put the build product (and tests) in a well known location so that we
> can find them e.g. from the tests.
> ---
> Makefile.local | 2 +-
> bindings/Makefile.local | 9 +
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile.local b/Makefile.local
> index 3c6dacbc..7c12612d 100644
> --- a/Makefile.local
> +++ b/Makefile.local
> @@ -1,7 +1,7 @@
> # -*- makefile -*-
>
> .PHONY: all
> -all: notmuch notmuch-shared build-man build-info ruby-bindings
> +all: notmuch notmuch-shared build-man build-info ruby-bindings
> python-cffi-bindings
> ifeq ($(MAKECMDGOALS),)
> ifeq ($(shell cat .first-build-message 2>/dev/null),)
> @NOTMUCH_FIRST_BUILD=1 $(MAKE) --no-print-directory all
> diff --git a/bindings/Makefile.local b/bindings/Makefile.local
> index 18f95835..b8e18c92 100644
> --- a/bindings/Makefile.local
> +++ b/bindings/Makefile.local
> @@ -13,6 +13,13 @@ ifeq ($(HAVE_RUBY_DEV),1)
> $(MAKE) -C $(dir)/ruby
> endif
>
> +python-cffi-bindings: lib/$(LINKER_NAME)
> +ifeq ($(HAVE_PYTHON_CFFI),1)
> + cd $(dir)/python-cffi && \
how bad does out-of-tree build break with this -- do we need to do
the same as with ruby bindings (copy sources -- do we still do so)? or does
python provide better alternative..?
> + ${PYTHON} setup.py build --build-lib build/stage && \
> + mkdir -p build/stage/tests && cp tests/*.py build/stage/tests
> +endif
> +
> CLEAN += $(patsubst %,$(dir)/ruby/%, \
> .RUBYARCHDIR.time \
> Makefile database.o directory.o filenames.o\
> @@ -20,3 +27,5 @@ CLEAN += $(patsubst %,$(dir)/ruby/%, \
> status.o tags.o thread.o threads.o)
>
> CLEAN += bindings/ruby/.vendorarchdir.time
> +
> +CLEAN += bindings/python-cffi/build
> --
> 2.24.0.rc1
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/5] configure: check for python cffi module
On Sun, Nov 03 2019, David Bremner wrote:
> This is needed to build the new python bindings
> ---
> configure | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/configure b/configure
> index 3c148e12..300591fe 100755
> --- a/configure
> +++ b/configure
> @@ -671,6 +671,15 @@ if [ $have_python -eq 0 ]; then
> errors=$((errors + 1))
> fi
>
> +printf "Checking for python cffi... "
> +if "$python" -c 'import cffi' >/dev/null 2>&1; then
> +printf "Yes.\n"
> +have_python_cffi=1;
trailing ;
> +else
> +printf "No.\n"
> +have_python_cffi=0;
ditto :)
otherwise tolerable =D
> +fi
> +
> printf "Checking for valgrind development files... "
> if pkg-config --exists valgrind; then
> printf "Yes.\n"
> @@ -1223,6 +1232,9 @@ HAVE_GETLINE = ${have_getline}
> # building/testing ruby bindings.
> HAVE_RUBY_DEV = ${have_ruby_dev}
>
> +# Is the python cffi package available?
> +HAVE_PYTHON_CFFI = ${have_python_cffi}
> +
> # Whether the strcasestr function is available (if not, then notmuch will
> # build its own version)
> HAVE_STRCASESTR = ${have_strcasestr}
> @@ -1376,6 +1388,9 @@ NOTMUCH_RUBY=${RUBY}
> # building/testing ruby bindings.
> NOTMUCH_HAVE_RUBY_DEV=${have_ruby_dev}
>
> +# Is the python cffi package available?
> +NOTMUCH_HAVE_PYTHON_CFFI=${have_python_cffi}
> +
> # Platform we are run on
> PLATFORM=${platform}
> EOF
> --
> 2.24.0.rc1
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 4/5] tests: run python-cffi tests
On Sun, Nov 03 2019, David Bremner wrote:
> The entire python-cffi test suite is considered as a single test at
> the level of the notmuch test suite. This might or might not be ideal,
> but it gets them run.
IMO this is good enough approach -- provided that pytest is prereq
for this test to be run =D
(i.e. one may have cffi but decided not to install pytest)
Tomi
> ---
> test/T391-python-cffi.sh | 12
> 1 file changed, 12 insertions(+)
> create mode 100755 test/T391-python-cffi.sh
>
> diff --git a/test/T391-python-cffi.sh b/test/T391-python-cffi.sh
> new file mode 100755
> index ..a03f9e0e
> --- /dev/null
> +++ b/test/T391-python-cffi.sh
> @@ -0,0 +1,12 @@
> +#!/usr/bin/env bash
> +test_description="python bindings (pytest)"
> +. $(dirname "$0")/test-lib.sh || exit 1
> +
> +if [ $NOTMUCH_HAVE_PYTHON_CFFI -eq 0 ]; then
> +test_done
> +fi
> +
> +
> +test_begin_subtest "python cffi tests"
> +test_expect_success "(cd $NOTMUCH_SRCDIR/bindings/python-cffi/build/stage &&
> ${NOTMUCH_PYTHON} -m pytest --log-file=$TMP_DIRECTORY/test.output)"
> +test_done
> --
> 2.24.0.rc1
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-mua-send + msmtp IS sending perfectly... but Emacs says it failed! Why?!
On Fri, Oct 25 2019, Aren Tyr wrote: > Hello all > > I have setup mbsync to receive my e-mail, msmtp to send my mail, and use > notmuch + emacs to read/compose my mail. I have the msmtp-mta package also > installed, so that msmtp acts as a sendmail replacement. I have a bizarre > problem, however, which despite my searching I cannot find an answer to. > > Every time I send a message (via notmuch-mua-send) from within Emacs, the > message apparently 'fails', and I get this error message: > > -- > > Mark set [5 times] > Sending... > Mark set [2 times] > Sending via mail... > message-send-mail-with-sendmail: Sending...failed to gpg: Signature made > Wed 09 Oct 2019 12:50:15 BST; gpg:using RSA key > C58AF6323354659D571F1DCA4AF54DEEDEA8938D; gpg:issuer " > f...@foo.com"; gpg: Good signature from "Aren Tyr (Key for encrypting mail > password files) " [ultimate]; > > > > > I say 'fails', because in fact it DOES SEND, and it sends perfectly! I've > tested it with lots of e-mails, tested it with attachments, everything is > sending and working as it should be. > > It is Emacs that is thinking it has failed, for whatever reason. > > I've tried twiddling with every variable I can think of in Emacs to no > avail. Here are my relevant emacs settings: > > (setq mail-specify-envelope-from 't) > (setq message-sendmail-envelope-from 'header) > (setq mail-envelope-from 'header) What are the values of send-mail-function and message-send-mail-function... If something like `message-smtpmail-send-it` then you could tru (setq smtpmail-debug-info t smtpmail-debug-verb t) and see what appeears in some new log buffers...) > > My notmuch-config database path is set to: > > path=/home/aren/.mail > > I've set the emacs 'message-directory' variable to the same path, i.e. > ~/.mail/. I've also tried manually creating 'sent' folders in the mail > store, just in case this was an issue, to no avail. (When I compose mail, > header has Fcc: sent ). notmuch-maildir-use-notmuch-insert is set to true. > notmuch-fcc-dirs is set to "sent". So everything should be set... > > > As a result, the buffer does not get closed/saved into the relevant sent > file, and it stays open as an "unsent" buffer, even though the message has > been sent fine. It is very irritating. To be clear, it is sending properly, > so it is correctly decrypting the password via gpg, so I don't know why it > is complaining and thinks there is a problem, when there isn't. Simply > sending an e-mail on the command line via mstmp also works perfectly > without any error, further verifying there is no configuration issue on the > actual mail transport side of things. > > Any ideas? Why does emacs/notmuch think there is a problem sending, when > there isn't? What setting do I need to put into emacs to get it to shut-up > and accept that the mail has actually been sent, because it has in fact > been? :-D > > In all other respects the mail setup is working perfectly, and I can > browse/search/read/view my e-mail just fine. It's a terrific program, thank > you! > > Well almost. One other slight nuisance. Whenever I close a message search > buffer, or a message reading buffer, instead of returning me to the > *notmuch hello* main buffer, it ALWAYS sends me to another buffer, usually > *scratch*. Never *notmuch hello*. It doesn't seem to matter what 'order' > the buffer is. I was expecting that after having started notmuch (M-x > notmuch), which brings up notmuch-hello, then immediately going into my > inbox (which opens a new buffer), opening an email (another new buffer), > closing it by pressing 'q', that I'd be returned back to my search list > since that is the immediately prior buffer. But no. It doesn't even return > me to notmuch-hello, which is the next one down. Instead it returns me to > another buffer, or *scratch*, or whatever. This is werid. It is like it is > ignoring the buffer list order. It means I have to manually switch buffers > back to the search list (or notmuch-hello). Emacs/notmuch seems to be > ignoring the buffer stack order, which is presumably not the intended > default operation. I don't understand enough about Emacs to know which > setting to tweak this. This is a minor distraction though, compared to the > sending issue I have described above. I used to have similar problem, and already wrote some elisp code to "fix" that (i.e. find suitable "parent" buffer and then switch there). Then I realized (i think someone(tm) commented on my suggestion) that there were problem in my emacs configuration -- and after I fixed that the buffer switching when closing search buffer worked basically as expected... i.e. when closing message buffer (and I have not one any other buffer manipulation) I ended back to search buffer, and from there back to hello buffer. If you have notmuch source code around you could try to run `devel/try-emacs-mua` and see whether you get diffe
