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
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/
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
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|
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
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
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
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
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/
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
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
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
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
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
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>
-signature
Size: 818 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20140706/ea5d8223/attachment.pgp>
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/
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
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|
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
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
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
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
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/
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
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
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
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
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
29 matches
Mail list logo