Re: [PATCH v2 06/21] crypto: Test restore of cleartext index from stashed session keys

2017-12-04 Thread David Bremner 

Pushed patches 1 to 6. I seem to recall 7 and 8 basically adressed
concerns/suggestions Jamie had, so I'm hoping he can have a quick look
at those.

d



___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v2 04/21] crypto: use stashed session-key properties for decryption, if available

2017-12-04 Thread David Bremner 
Daniel Kahn Gillmor  writes:

> On Thu 2017-11-30 03:59:29 -0500, Daniel Kahn Gillmor wrote:
>> +hexidecimal representation of the algorithm-specific key.  For
>
> ugh, this should be hexadecimal, not hexidecimal.
>
> This is fixed in my gitlab session-keys branch [0], but doesn't seem
> worth re-posting the entire series for. :)
>

I've amended it by hand, but for future reference the usual convention
is to post an amended patch as a reply, and to mark the original as
obsolete in nmbug

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 4/5] debian: bump Standards-Version to 4.1.1

2017-12-04 Thread David Bremner 
Daniel Kahn Gillmor  writes:

> No minor changes were necessary to become compliant with Debian policy
> version 4.1.1, so this is basically a freebie.

pushed 2,3,4. Waiting for you and Tomi to reach a fixed point on
1. Skeptical of 5; I tend to think lintian is wrong here. Not sure if I
care enough to override it.

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] test: unbreak performance tests

2017-12-04 Thread David Bremner 
David Bremner  writes:

> In 8e7fb88237aedea22 Jani replaced the use of $(pwd -P) to find the
> TEST_DIRECTORY in order to better support out of tree
> builds. Unfortunately the performance-tests need a different value for
> the variable and were thus broken.
>
> This commit splits out the setting of this variable for the two sets
> of tests.  Performance tests still don't work out of tree, because
> the handling of the downloaded corpus needs to be updated.

pushed,

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 1/5] debian/control: build-depend on python3-sphinx instead of python-sphinx

2017-12-04 Thread Tomi Ollila 
On Mon, Dec 04 2017, Tomi Ollila wrote:

> On Mon, Dec 04 2017, Daniel Kahn Gillmor wrote:
>
>> On Sun 2017-12-03 15:35:04 +0200, Tomi Ollila wrote:
>>> On Thu, Nov 30 2017, Daniel Kahn Gillmor wrote:
>>>

 hm, on further reflection, this one is specifically problematic because
 of the use of:

 ${python} -m sphinx.writers.manpage

 in ./configure, used to test for the presence of the sphinx module.

 This can be fixed by preferring python3 here:

 --- a/configure
 +++ b/configure
 @@ -557,7 +557,7 @@ fi
  printf "Checking for python... "
  have_python=0
  
 -for name in ${PYTHON} python python2 python3; do
 +for name in ${PYTHON} python3 python python2; do
>>>
  if command -v $name > /dev/null; then
 have_python=1
 python=$name

 any thoughts or preferences on this?
>>>
>>> I'd like this change. I was going to suggest "${PYTHON}" there
>>> but perhaps if one sets e.g.
>>>
>>> PYTHON='/usr/local/bin/python3 -B -E -u'
>>>
>>> The above would still work (I'd say this is potentially more useful
>>> than supporting whitespace in paths).
>>
>> does it work?  i think the -B -E -u will all be tried as possible python
>> implementations separately, no?  and $python itself will just get set to
>> /usr/local/bin/python3 with the arguments dropped :(
>
> Ahh, you're right. Alternative would be to check whether "${PYTHON-}" is
> a nonempty string and use that...

Now that I said it, I'm compelled to write an example. Simpler
alternative is to just have what you Daniel first wrote...

.. so I'm, fine with original  for name in ${PYTHON} python3 python python2; do


have_python=0

if test "${PYTHON-}"; then
name=${PYTHON%%[$IFS]*}
if command -v $name > /dev/null; then
have_python=1
python=$name
fi
fi
if [ $have_python -eq 0 ]; then
for name in python3 python python2; do
if command -v $name > /dev/null; then
have_python=1
python=$name
fi
done
fi

>
> Tomi
>
>>
>> 0 dkg@alice:~$ x="a b c"
>> 0 dkg@alice:~$ for y in ${x} d e; do printf ':%s\n' "$y"; done
>> :a
>> :b
>> :c
>> :d
>> :e
>> 0 dkg@alice:~$ 
>>
>> While i think this doesn't support Tomi's extended use case, i still
>> think it's the right direction to move in.
>>
>> Does anyone have any objection to the preference order change above?  Is
>> there any reason we should be preferring python 2 to python3 as we move
>> forward?
>>
>> --dkg
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 1/5] debian/control: build-depend on python3-sphinx instead of python-sphinx

2017-12-04 Thread Tomi Ollila 
On Mon, Dec 04 2017, Daniel Kahn Gillmor wrote:

> On Sun 2017-12-03 15:35:04 +0200, Tomi Ollila wrote:
>> On Thu, Nov 30 2017, Daniel Kahn Gillmor wrote:
>>
>>> On Thu 2017-11-30 04:40:39 -0500, Daniel Kahn Gillmor wrote:
 python2 is going to be deprecated, and python3-sphinx is available all
 the way back to oldoldstable.  let's use the more modern version.
 ---
  debian/control | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/debian/control b/debian/control
 index 20b8a2db..3a624fdc 100644
 --- a/debian/control
 +++ b/debian/control
 @@ -18,7 +18,7 @@ Build-Depends:
   python3-all (>= 3.1.2-7~),
   dh-python,
   dh-elpa (>= 1.3),
 - python-sphinx (>= 1.0),
 + python3-sphinx,
   ruby, ruby-dev (>>1:1.9.3~),
   emacs25-nox | emacs25 (>=25~) | emacs25-lucid (>=25~) |
   emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~) |
>>>
>>> hm, on further reflection, this one is specifically problematic because
>>> of the use of:
>>>
>>> ${python} -m sphinx.writers.manpage
>>>
>>> in ./configure, used to test for the presence of the sphinx module.
>>>
>>> This can be fixed by preferring python3 here:
>>>
>>> --- a/configure
>>> +++ b/configure
>>> @@ -557,7 +557,7 @@ fi
>>>  printf "Checking for python... "
>>>  have_python=0
>>>  
>>> -for name in ${PYTHON} python python2 python3; do
>>> +for name in ${PYTHON} python3 python python2; do
>>
>>>  if command -v $name > /dev/null; then
>>> have_python=1
>>> python=$name
>>>
>>> any thoughts or preferences on this?
>>
>> I'd like this change. I was going to suggest "${PYTHON}" there
>> but perhaps if one sets e.g.
>>
>> PYTHON='/usr/local/bin/python3 -B -E -u'
>>
>> The above would still work (I'd say this is potentially more useful
>> than supporting whitespace in paths).
>
> does it work?  i think the -B -E -u will all be tried as possible python
> implementations separately, no?  and $python itself will just get set to
> /usr/local/bin/python3 with the arguments dropped :(

Ahh, you're right. Alternative would be to check whether "${PYTHON-}" is
a nonempty string and use that...

Tomi

>
> 0 dkg@alice:~$ x="a b c"
> 0 dkg@alice:~$ for y in ${x} d e; do printf ':%s\n' "$y"; done
> :a
> :b
> :c
> :d
> :e
> 0 dkg@alice:~$ 
>
> While i think this doesn't support Tomi's extended use case, i still
> think it's the right direction to move in.
>
> Does anyone have any objection to the preference order change above?  Is
> there any reason we should be preferring python 2 to python3 as we move
> forward?
>
> --dkg
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v2] cli/help: give a hint about notmuch-emacs-mua

2017-12-04 Thread Tomi Ollila 
On Mon, Dec 04 2017, Daniel Kahn Gillmor wrote:

> "notmuch help" doesn't mention "notmuch-emacs-mua" even though we
> support it through the try_external_command() mechanism.
>
> In addition, "notmuch help emacs-mua" doesn't work, even though we
> ship the appropriate manpage.
>
> This changeset fixes both of these problems.

+1

Tomi


> ---
>  configure | 1 +
>  notmuch.c | 7 ++-
>  2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index bd034f91..f1974520 100755
> --- a/configure
> +++ b/configure
> @@ -1185,6 +1185,7 @@ COMMON_CONFIGURE_CFLAGS = \\
>   \$(GMIME_CFLAGS) \$(TALLOC_CFLAGS) \$(ZLIB_CFLAGS)  \\
>   -DHAVE_VALGRIND=\$(HAVE_VALGRIND) \$(VALGRIND_CFLAGS)   \\
>   -DHAVE_GETLINE=\$(HAVE_GETLINE) \\
> + -DWITH_EMACS=\$(WITH_EMACS) \\
>   -DHAVE_CANONICALIZE_FILE_NAME=\$(HAVE_CANONICALIZE_FILE_NAME) \\
>   -DHAVE_STRCASESTR=\$(HAVE_STRCASESTR)   \\
>   -DHAVE_STRSEP=\$(HAVE_STRSEP)   \\
> diff --git a/notmuch.c b/notmuch.c
> index d5bf7902..2d193aa8 100644
> --- a/notmuch.c
> +++ b/notmuch.c
> @@ -172,6 +172,10 @@ static command_t commands[] = {
>"Re-index all messages matching the search terms." },
>  { "config", notmuch_config_command, NOTMUCH_CONFIG_OPEN,
>"Get or set settings in the notmuch configuration file." },
> +#if WITH_EMACS
> +{ "emacs-mua", NULL, 0,
> +  "send mail with notmuch and emacs." },
> +#endif
>  { "help", notmuch_help_command, NOTMUCH_CONFIG_CREATE, /* create but 
> don't save config */
>"This message, or more detailed help for the named command." }
>  };
> @@ -487,7 +491,8 @@ main (int argc, char *argv[])
>  notmuch_process_shared_options (command_name);
>  
>  command = find_command (command_name);
> -if (!command) {
> +/* if command->function is NULL, try external command */
> +if (!command || !command->function) {
>   /* This won't return if the external command is found. */
>   if (try_external_command(argv + opt_index))
>   fprintf (stderr, "Error: Unknown command '%s' (see \"notmuch 
> help\")\n",
> -- 
> 2.15.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] cli/help: give a hint about notmuch-emacs-mua

2017-12-04 Thread Daniel Kahn Gillmor 
On Mon 2017-12-04 10:44:40 -0500, Daniel Kahn Gillmor wrote:
> But maybe you'll find my revised version
> (id:20171204154333.27505-1-...@fifthhorseman.net) mitigates the error
> you're pointing out?

sorry, that should be id:20171204184310.17125-1-...@fifthhorseman.net --
the previous message-id was never sent.

--dkg
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v2] cli/help: give a hint about notmuch-emacs-mua

2017-12-04 Thread Daniel Kahn Gillmor 
"notmuch help" doesn't mention "notmuch-emacs-mua" even though we
support it through the try_external_command() mechanism.

In addition, "notmuch help emacs-mua" doesn't work, even though we
ship the appropriate manpage.

This changeset fixes both of these problems.
---
 configure | 1 +
 notmuch.c | 7 ++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index bd034f91..f1974520 100755
--- a/configure
+++ b/configure
@@ -1185,6 +1185,7 @@ COMMON_CONFIGURE_CFLAGS = \\
\$(GMIME_CFLAGS) \$(TALLOC_CFLAGS) \$(ZLIB_CFLAGS)  \\
-DHAVE_VALGRIND=\$(HAVE_VALGRIND) \$(VALGRIND_CFLAGS)   \\
-DHAVE_GETLINE=\$(HAVE_GETLINE) \\
+   -DWITH_EMACS=\$(WITH_EMACS) \\
-DHAVE_CANONICALIZE_FILE_NAME=\$(HAVE_CANONICALIZE_FILE_NAME) \\
-DHAVE_STRCASESTR=\$(HAVE_STRCASESTR)   \\
-DHAVE_STRSEP=\$(HAVE_STRSEP)   \\
diff --git a/notmuch.c b/notmuch.c
index d5bf7902..2d193aa8 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -172,6 +172,10 @@ static command_t commands[] = {
   "Re-index all messages matching the search terms." },
 { "config", notmuch_config_command, NOTMUCH_CONFIG_OPEN,
   "Get or set settings in the notmuch configuration file." },
+#if WITH_EMACS
+{ "emacs-mua", NULL, 0,
+  "send mail with notmuch and emacs." },
+#endif
 { "help", notmuch_help_command, NOTMUCH_CONFIG_CREATE, /* create but don't 
save config */
   "This message, or more detailed help for the named command." }
 };
@@ -487,7 +491,8 @@ main (int argc, char *argv[])
 notmuch_process_shared_options (command_name);
 
 command = find_command (command_name);
-if (!command) {
+/* if command->function is NULL, try external command */
+if (!command || !command->function) {
/* This won't return if the external command is found. */
if (try_external_command(argv + opt_index))
fprintf (stderr, "Error: Unknown command '%s' (see \"notmuch 
help\")\n",
-- 
2.15.0

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] cli/help: give a hint about notmuch-emacs-mua

2017-12-04 Thread Daniel Kahn Gillmor 
On Sun 2017-12-03 15:26:32 +0200, Tomi Ollila wrote:
> My thought was that even though user may compile notmuch without emacs
> support (and notmuch-emacs-mua not installed) we would be hinting 
> `notmuch emacs-mua` command to exist.

Currently, if the user *does* compile with emacs support, and installs
it, we are hinting that "notmuch emacs-mua" *doesn't* exist.

Given that "notmuch emacs-mua" does exist somewhere (even if it's not in
the local installation), i prefer the error in the direction of
inclusion.

But maybe you'll find my revised version
(id:20171204154333.27505-1-...@fifthhorseman.net) mitigates the error
you're pointing out?

   --dkg
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 1/5] debian/control: build-depend on python3-sphinx instead of python-sphinx

2017-12-04 Thread Daniel Kahn Gillmor 
On Sun 2017-12-03 15:35:04 +0200, Tomi Ollila wrote:
> On Thu, Nov 30 2017, Daniel Kahn Gillmor wrote:
>
>> On Thu 2017-11-30 04:40:39 -0500, Daniel Kahn Gillmor wrote:
>>> python2 is going to be deprecated, and python3-sphinx is available all
>>> the way back to oldoldstable.  let's use the more modern version.
>>> ---
>>>  debian/control | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/debian/control b/debian/control
>>> index 20b8a2db..3a624fdc 100644
>>> --- a/debian/control
>>> +++ b/debian/control
>>> @@ -18,7 +18,7 @@ Build-Depends:
>>>   python3-all (>= 3.1.2-7~),
>>>   dh-python,
>>>   dh-elpa (>= 1.3),
>>> - python-sphinx (>= 1.0),
>>> + python3-sphinx,
>>>   ruby, ruby-dev (>>1:1.9.3~),
>>>   emacs25-nox | emacs25 (>=25~) | emacs25-lucid (>=25~) |
>>>   emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~) |
>>
>> hm, on further reflection, this one is specifically problematic because
>> of the use of:
>>
>> ${python} -m sphinx.writers.manpage
>>
>> in ./configure, used to test for the presence of the sphinx module.
>>
>> This can be fixed by preferring python3 here:
>>
>> --- a/configure
>> +++ b/configure
>> @@ -557,7 +557,7 @@ fi
>>  printf "Checking for python... "
>>  have_python=0
>>  
>> -for name in ${PYTHON} python python2 python3; do
>> +for name in ${PYTHON} python3 python python2; do
>
>>  if command -v $name > /dev/null; then
>> have_python=1
>> python=$name
>>
>> any thoughts or preferences on this?
>
> I'd like this change. I was going to suggest "${PYTHON}" there
> but perhaps if one sets e.g.
>
> PYTHON='/usr/local/bin/python3 -B -E -u'
>
> The above would still work (I'd say this is potentially more useful
> than supporting whitespace in paths).

does it work?  i think the -B -E -u will all be tried as possible python
implementations separately, no?  and $python itself will just get set to
/usr/local/bin/python3 with the arguments dropped :(

0 dkg@alice:~$ x="a b c"
0 dkg@alice:~$ for y in ${x} d e; do printf ':%s\n' "$y"; done
:a
:b
:c
:d
:e
0 dkg@alice:~$ 

While i think this doesn't support Tomi's extended use case, i still
think it's the right direction to move in.

Does anyone have any objection to the preference order change above?  Is
there any reason we should be preferring python 2 to python3 as we move
forward?

--dkg


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch