Re: [PATCH 1/2] cli: S/MIME verification/decryption support

On Tue, Jul 01 2014, David Bremner wrote: > Jameson Graef Rollins writes: > >> The notmuch-show flags --decrypt and --verify will now also process >> S/MIME multiparts if encountered. Requires gmime-2.6 and gpgsm. > > I was trying to figure out how to test this. I tried a few couple signed > mes

[Patch v3 3/3] doc: postprocess notmuch.3

Remove excess italics from doxygen output. It seems to make no sense (and is certainly ugly) to italicize the first argument to the .RI macro. --- doc/Makefile.local | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/Makefile.local b/doc/Makefile.local index 618b840..dea20a2 100644 --- a/doc/

[Patch v3 2/3] doc: quiet doxygen warnings

remove some obsolete tags for XML output (which we don't currently generate in any case) --- doc/doxygen.cfg | 2 -- 1 file changed, 2 deletions(-) diff --git a/doc/doxygen.cfg b/doc/doxygen.cfg index 68e8969..0f48ddb 100644 --- a/doc/doxygen.cfg +++ b/doc/doxygen.cfg @@ -228,8 +228,6 @@ MAN_LINK

[Patch v3 1/3] doc: build and install doxygen api docs

In order to support out of tree builds, generate `doc/config.dox` from configure. In order to avoid hardcoding version in doxygen.cfg, generate doc/version.dox at build time. --- configure | 18 ++ doc/Makefile.local | 26 -- doc/doxygen.cfg|

build and install api docs with doxygen

In my testing this version works ok with and without doxygen, and in and out of tree. But I only tested in Debian jessie (testing), so other tests would be welcome. It's a bit lame that we have to generate doxygen config file snippet on the fly just to support out of tree builds, but doxygen seem

Re: [PATCH 1/2] cli: S/MIME verification/decryption support

Jameson Graef Rollins writes: >> >> Are we missing the signature between bad and untrusted signatures, or >> does that distinction not exist for S/MIME? > > Hey, David. How did you generate the signatures? I would love to see a > script that generates a signature on a test message. I just grep

Re: [PATCH] build: check .git directory existence in srcdir (for out-of-tree builds)

On Sat, Jul 05 2014, David Bremner wrote: > Tomi Ollila writes: > >> So that $(VERSION) and version.stamp uses the git-describe -based >> version data instead of the content of `version' file. >> >> For consistency also the git commands in Makefile[.local] target >> `verify-no-dirty-code' uses t

Re: [PATCH] emacs: add missing paren to fix defun in notmuch-address.el.

Karl Fogel writes: > Sebastian Lipp writes: >>diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el >>index fa65cd5..ee7b169 100644 >>--- a/emacs/notmuch-address.el >>+++ b/emacs/notmuch-address.el >>@@ -113,6 +113,59 @@ to know how address selection is made by default." >> (when (notm

[PATCH 1/4] nmbug: Add a git_with_status helper function

Sometimes we want to catch Git errors and handle them, instead of dying with an error message. This lower-level version of git() allows us to get the error status when we want it. --- devel/nmbug/nmbug | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/devel/nmbug/

[PATCH 0/4] nmbug without an upstream repository (and init)

Currently 'nmbug status' errors out if there is no @{upstream} branch. To support folks who are just using nmbug locally, add exit code checking and stderr catching to handle this case appropriately. The final commit isn't closely related, but it allows folks to easily initialize nmbug repositorie

[PATCH 2/4] nmbug: Handle missing @upstream in is_unmerged

If we don't have an upstream, there is nothing to merge, so nothing is unmerged. This avoids errors like: $ nmbug status error: No upstream configured for branch 'master' error: No upstream configured for branch 'master' fatal: ambiguous argument '@{upstream}': unknown revision or path no

[PATCH 3/4] nmbug: Catch stderr in is_unmerged

Add a '-2|' dir for "execute the command and pipe both stdout and stderr to us". Use this to catch stderr from the rev-parse call in is_unmerged. We already check the status, so we don't want to confuse users with stuff like: error: No upstream configured for branch 'master' on nmbug's stderr

Re: [PATCH] emacs: add missing paren to fix defun in notmuch-address.el.

Karl Fogel > In general, supplying a log message with the patch with avoid such > confusion. If there is some prose expressing what the change is > supposed to to, and giving any historical context (such as the mailing > list thread starting from last year), then it will be easy for any > reviewe

[PATCH 4/4] nmbug: Add an 'init' command

For folks that want to start versioning a new tag-space, instead of cloning one that someone else has already started. The empty-blob hash-object call avoids errors like: $ nmbug commit error: invalid object 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 for 'tags/...' fatal: git-write-tr

[PATCH v2 06/10] cli: refactor insert

crubbed... Name: 0001-goto-fail.patch Type: text/x-diff Size: 1806 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140706/5cdb4025/attachment.patch>

[PATCH 1/2] cli: S/MIME verification/decryption support

-signature Size: 818 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140706/ea5d8223/attachment.pgp>

[Patch v3 3/3] doc: postprocess notmuch.3

Remove excess italics from doxygen output. It seems to make no sense (and is certainly ugly) to italicize the first argument to the .RI macro. --- doc/Makefile.local | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/Makefile.local b/doc/Makefile.local index 618b840..dea20a2 100644 --- a/doc/

[Patch v3 2/3] doc: quiet doxygen warnings

remove some obsolete tags for XML output (which we don't currently generate in any case) --- doc/doxygen.cfg | 2 -- 1 file changed, 2 deletions(-) diff --git a/doc/doxygen.cfg b/doc/doxygen.cfg index 68e8969..0f48ddb 100644 --- a/doc/doxygen.cfg +++ b/doc/doxygen.cfg @@ -228,8 +228,6 @@ MAN_LINK

[Patch v3 1/3] doc: build and install doxygen api docs

In order to support out of tree builds, generate `doc/config.dox` from configure. In order to avoid hardcoding version in doxygen.cfg, generate doc/version.dox at build time. --- configure | 18 ++ doc/Makefile.local | 26 -- doc/doxygen.cfg|

build and install api docs with doxygen

In my testing this version works ok with and without doxygen, and in and out of tree. But I only tested in Debian jessie (testing), so other tests would be welcome. It's a bit lame that we have to generate doxygen config file snippet on the fly just to support out of tree builds, but doxygen seem

[PATCH 1/2] cli: S/MIME verification/decryption support

Jameson Graef Rollins writes: >> >> Are we missing the signature between bad and untrusted signatures, or >> does that distinction not exist for S/MIME? > > Hey, David. How did you generate the signatures? I would love to see a > script that generates a signature on a test message. I just grep

[PATCH] build: check .git directory existence in srcdir (for out-of-tree builds)

On Sat, Jul 05 2014, David Bremner wrote: > Tomi Ollila writes: > >> So that $(VERSION) and version.stamp uses the git-describe -based >> version data instead of the content of `version' file. >> >> For consistency also the git commands in Makefile[.local] target >> `verify-no-dirty-code' uses t

[PATCH] emacs: add missing paren to fix defun in notmuch-address.el.

Karl Fogel writes: > Sebastian Lipp writes: >>diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el >>index fa65cd5..ee7b169 100644 >>--- a/emacs/notmuch-address.el >>+++ b/emacs/notmuch-address.el >>@@ -113,6 +113,59 @@ to know how address selection is made by default." >> (when (notm

[PATCH 1/4] nmbug: Add a git_with_status helper function

Sometimes we want to catch Git errors and handle them, instead of dying with an error message. This lower-level version of git() allows us to get the error status when we want it. --- devel/nmbug/nmbug | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/devel/nmbug/

[PATCH 0/4] nmbug without an upstream repository (and init)

Currently 'nmbug status' errors out if there is no @{upstream} branch. To support folks who are just using nmbug locally, add exit code checking and stderr catching to handle this case appropriately. The final commit isn't closely related, but it allows folks to easily initialize nmbug repositorie

[PATCH 3/4] nmbug: Catch stderr in is_unmerged

Add a '-2|' dir for "execute the command and pipe both stdout and stderr to us". Use this to catch stderr from the rev-parse call in is_unmerged. We already check the status, so we don't want to confuse users with stuff like: error: No upstream configured for branch 'master' on nmbug's stderr

[PATCH 2/4] nmbug: Handle missing @upstream in is_unmerged

If we don't have an upstream, there is nothing to merge, so nothing is unmerged. This avoids errors like: $ nmbug status error: No upstream configured for branch 'master' error: No upstream configured for branch 'master' fatal: ambiguous argument '@{upstream}': unknown revision or path no

[PATCH] emacs: add missing paren to fix defun in notmuch-address.el.

Karl Fogel > In general, supplying a log message with the patch with avoid such > confusion. If there is some prose expressing what the change is > supposed to to, and giving any historical context (such as the mailing > list thread starting from last year), then it will be easy for any > reviewe

[PATCH 4/4] nmbug: Add an 'init' command

For folks that want to start versioning a new tag-space, instead of cloning one that someone else has already started. The empty-blob hash-object call avoids errors like: $ nmbug commit error: invalid object 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 for 'tags/...' fatal: git-write-tr