On Thu 2018-06-28 21:40:04 -0300, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>
>>
>> sp->map_key (sp, "Subject");
>> -sp->string (sp, g_mime_message_get_subject (message));
>> +if (msg_crypto && msg_crypto-
On Sun 2018-06-24 22:31:44 -0300, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>
>> +
>> +# TODO:
>> +# * check S/MIME as well as PGP/MIME
>
> Decrypting S/MIME would be good first step. Or is the feature there
> (with gmime 3.0?) but tests missing? becaus
On Sun 2018-06-24 22:15:46 -0300, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>
>> @@ -270,7 +274,7 @@ _notmuch_message_crypto_potential_payload
>> (_notmuch_message_crypto_t *msg_crypto
>> if (parent && GMIME_IS_MULTIPAR
On Fri 2018-06-15 20:47:59 -0300, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>
>> +
>> +const _notmuch_message_crypto_t *msg_crypto =
>> mime_node_get_message_crypto_status (node);
>> +if (msg_crypto->sig_list ||
>>
On Fri 2018-06-15 07:16:05 -0300, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>
>> +notmuch_status_t
>> +_notmuch_message_crypto_set_sig_list (_notmuch_message_crypto_t
>> *msg_crypto, GMimeSignatureList *sigs)
>> +{
>
> It's a bit confusing that n
Many of the manpages didn't treat literal text as literal text. I've
tried to normalize some of the restructured text to make it a bit more
regular.
several of the synopsis lines are still untouched by this cleanup, but
i'm not sure what the right way to represent those is in .rst,
actually.
In
This is looking good to me, thanks!
two more bits of nit-pickery below:
On Tue 2018-06-19 08:20:12 -0700, Jameson Graef Rollins wrote:
> +(defcustom notmuch-show-stash-session-keys nil
> + "Should session keys be stashed when decrypting messages for display?
> +
> +If this variable is non-nil se
On Mon 2018-06-18 15:49:45 -0700, Jameson Graef Rollins wrote:
> On Mon, Jun 18 2018, Daniel Kahn Gillmor wrote:
>
>> Should its name be notmuch-show-store-session-keys instead?
>
> I feel like it should be under the notmuch-crypto customization group,
> not notmuch-show.
thanks for working on this, Jamie!
On Sun 2018-06-17 17:31:38 -0700, Jameson Graef Rollins wrote:
> Introduce notmuch-crypto-store-session-keys customization variable to
> control stashing of session keys. If non-nil any session keys
> recovered during decryption will be stored in the database.
>
On Wed 2018-06-13 13:25:54 -0300, David Bremner wrote:
> What about using symbols and some kind of case? less efficient but
> better error checking
symbols would also make for a more brittle interaction between future
versions of the notmuch cli and notmuch-emacs, but i agree that the
error checki
On Tue 2018-06-12 23:07:33 -0700, Jameson Graef Rollins wrote:
> What if notmuch-crypto-process-mime just accepted the same values that
> show --decrypt does, with the same meanings, e.g.:
>
> ┌─┬───┬──┬──┬───┐
> │
On Tue 2018-06-12 10:00:18 -0400, Daniel Kahn Gillmor wrote:
> (it'd be nice to be able to use notmuch-emacs to browse a notmuch
> archive without locking the notmuch db or even needing read/write access
> to the database)
to be clear, it's not just about wanting to be able to
Help users find this new indexed-cleartext workflow.
---
NEWS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/NEWS b/NEWS
index d1bc73b8..9c59d989 100644
--- a/NEWS
+++ b/NEWS
@@ -17,6 +17,12 @@ Add the --full-scan option to `notmuch new`
This option disables mtime based optimizatio
On Tue 2018-06-12 09:57:52 -0400, Daniel Kahn Gillmor wrote:
> On Tue 2018-06-12 12:47:58 +0200, Thomas Schneider wrote:
>> Tomi Ollila writes:
>>
>>> On Mon, Jun 11 2018, Daniel Kahn Gillmor wrote:
>>>
>>>> Make printmimestructure work in python3 a
Make printmimestructure work in python3 as well as python2.
PEP 394 suggests that python scripts that work with both python2 and
python3 should have a #!/usr/bin/python command line, so do that too.
---
devel/printmimestructure | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --g
---
devel/nmbug/notmuch-report | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/devel/nmbug/notmuch-report b/devel/nmbug/notmuch-report
index 5789c5f4..eaceb2ce 100755
--- a/devel/nmbug/notmuch-report
+++ b/devel/nmbug/notmuch-report
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bi
From: Jameson Graef Rollins
make the source slightly easier to read. no functional change.
---
devel/printmimestructure | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/devel/printmimestructure b/devel/printmimestructure
index a5fc83e7..70e0a5c0 100755
On Tue 2018-06-12 12:47:58 +0200, Thomas Schneider wrote:
> Tomi Ollila writes:
>
>> On Mon, Jun 11 2018, Daniel Kahn Gillmor wrote:
>>
>>> Make printmimestructure work in python3 as well as python2.
>>>
>>> PEP 394 suggests that python scripts that
On Mon 2018-06-11 16:09:00 -0700, Jameson Graef Rollins wrote:
> This just changes the show --decrypt flag to "stash" in the emacs UI,
> so that session keys will be stashed in the database when viewing
> encrypted messages that have not previously been decrypted. As
> always, this will only happe
--git a/devel/printmimestructure b/devel/printmimestructure
index 34d12930..afa0590e 100755
--- a/devel/printmimestructure
+++ b/devel/printmimestructure
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/python
# -*- coding: utf-8 -*-
# Author: Daniel Kahn Gillmor
@@ -19,6 +19,8 @@
# If you
On Wed 2018-06-06 13:05:15 -0400, Daniel Kahn Gillmor wrote:
> mipsel folks, could you give back the experimental version of notmuch to
> the mipsel buildd network and try to avoid having it land on
> mipsel-manda-03?
Thank you for the giveback! However, it looks like it landed on
mip
On Wed 2018-06-06 13:21:13 -0300, David Bremner wrote:
> Just to be clear, the first problem is (was?) also present with python3
yep, got it :)
--dkg
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
On Wed 2018-06-06 10:30:15 -0400, Daniel Kahn Gillmor wrote:
> Furthermore, i can't replicate the failure from the buildd when building
> on eller either. So neither bremner nor i were able to replicate the
> problem.
>
> mipsel porters, do you have any suggestions for nex
On Tue 2018-06-05 22:06:07 -0300, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>> +
>> +if len(sys.argv) < 2:
>> +sys.exit("""usage: {} EXPR [EXPR]
>> +
>
> the useage message doesn't seem to work? I get
>
> ╭─ zancas
On Mon 2018-06-04 23:44:25 -0300, David Bremner wrote:
> $ make test-binaries && ./T357-index-decryption.sh
>
> That works for me on eller, so there must be some difference between the
> two environments (buildd versus porterbox)
what schroot are you working from on eller? i wonder what the
diffe
On Mon 2018-06-04 17:52:46 -0400, Daniel Kahn Gillmor wrote:
> I've tried to replicate the problem over on eller.debian.org (the mipsel
> porterbox) but when i build 0.27~rc1 over there in an schroot, i don't
> even get to T357 because the emacs_fcc_message() function hangs in t
hey folks--
the notmuch 0.27 release candidates are failing to build on the debian
mipsel build daemons:
https://buildd.debian.org/status/fetch.php?pkg=notmuch&arch=mipsel&ver=0.27%7Erc0-1&stamp=1527466396&raw=0
https://buildd.debian.org/status/fetch.php?pkg=notmuch&arch=mipsel&ver=0.27%7Erc1-1&s
On Sat 2018-06-02 16:20:25 -0300, David Bremner wrote:
> Jameson Graef Rollins writes:
>
>> I've pushed a branch of this series rebased against notmuch/release (for
>> some reason master is currently a couple commits behind) and fixed to
>> reflect the exposure of notmuch_message_get_database:
>>
On Tue 2018-05-22 18:47:49 -0700, David Bremner wrote:
> This recognizes the addition of (at least)
> notmuch_message_get_database to the API.
> ---
> lib/notmuch.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/notmuch.h b/lib/notmuch.h
> index 4db28a05..b1bfcb0f 100
On Thu 2018-05-10 09:39:32 -0300, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>
>> Not sure how to best
>> represent that in nmbug -- but for now i've removed
>> notmuch::needs-review and added notmuch::wip. bremner, let me know if
>> you think i s
On Fri 2018-05-11 07:15:41 -0300, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>
>> 0 dkg@alice:~$ notmuch count 'thread:{date:1month..now tag:dkg}'
>> notmuch count: A Xapian exception occurred
>> A Xapian exception occurred parsing query: missing } in &
On Mon 2018-05-07 09:09:35 -0300, David Bremner wrote:
> David Bremner writes:
>
>> This is the first non-WIP version of this series. It adds a small
>> optimization (something like a 10% speedup on SSD), and some
>> documentation and tests.
>
> pushed to master, with Jani's suggestions.
this is
On Wed 2018-05-09 14:42:35 -0400, Daniel Kahn Gillmor wrote:
> I avoided #if'ing out these sections because i thought the general
> strategy was to avoid preprocessor shenanigans where possible, as it
> makes the code harder to think about given the combinatorial explosion
> o
Add fancy new feature, which makes "notmuch show" capable of actually
indexing messages that it just decrypted.
This enables a workflow where messages can come in in the background
and be indexed using "--decrypt=auto". But when showing an encrypted
message for the first time, it gets automatical
This is an improvement on the series most recently sent in
id:20180110001228.2211-1-...@fifthhorseman.net (with the initial
version in id:20171212025225.11854-1-...@fifthhorseman.net).
The differences between this and v2 of this series are cleanup and
readability improvements suggested by David Br
We've had _notmuch_message_database() internally for a while, and it's
useful. It turns out to be useful on the other side of the library
interface as well (i'll use it later in this series for "notmuch
show"), so we expose it publicly now.
---
lib/index.cc| 10 +-
lib/message
The user can already do this manually, of course, but (a) it's nice to
have a convenience function, and (b) exposing this interface means
that someone more clever with a _notmuch_string_map_t than i am can
write a more efficient version if they like, and it will just
accelerate the users of the con
Thanks to David Bremner for this improved readability!
---
test/T357-index-decryption.sh | 10 +-
test/test-lib.sh | 5 +
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/test/T357-index-decryption.sh b/test/T357-index-decryption.sh
index 2b8e05b8..ad6c3616
This is technically an API change, but it is not an ABI change, and
it's merely a statement that limits what the library can do.
This is in parallel to notmuch_query_get_database(), which also takes
a const pointer.
---
lib/message.cc | 2 +-
lib/notmuch.h | 2 +-
2 files changed, 2 insertions(+
If the decryption policy is NOTMUCH_DECRYPT_TRUE, that means we want
to stash session keys in the database. Note that there is currently
no way from the command line to set it this way, though, so it is not
yet included in the test suite.
---
mime-node.c | 22 ++
1 file change
If the number of session keys for a given message increased after
running "notmuch show" then we just learned something new that might
let us do automatic decryption. We should reindex this message using
our newfound knowledge.
---
notmuch-show.c | 19 +++
1 file changed, 19 inser
This function is a parallel to print_status_query() or
print_status_database(). Thanks to David Bremner for the suggestion!
---
notmuch-client.h | 5 +
status.c | 20
2 files changed, 25 insertions(+)
diff --git a/notmuch-client.h b/notmuch-client.h
index 0985a7
Now that we can decrypt headers, we want to make sure that clients
using "notmuch reply" to prepare a reply don't leak cleartext in their
subject lines. In particular, the ["reply-headers"]["Subject"] should
by default show the external Subject.
---
test/T356-protected-headers.sh | 7 +++
1 f
Rather than passing a boolean to indicate whether this is a reply to
format_headers_sprinter(), we use a flag field. This will be used
shortly to allow clients to indicate that they can responsibly protect
the subject line. This changeset has no functional change itself,
just modifying the types
This allows a clever UI frontend to mark whether a header was
protected (or not), and if it was protected, to show the details to
an interested user.
As before, we only handle Subject for now, but we might be able to
handle other headers in the future.
---
devel/schemata | 6
This flag indicates the intent of the client to protect the subject
line, which allows "notmuch reply" to safely emit the earlier
message's encrypted subject without risking leaking it in the clear in
the reply.
Obviously, it should only be used by a client that *will* protect the
subject line. T
This paves the way for emitting protected headers after verification
and decryption, because it means that the headers will only be emitted
after the body has been parsed.
---
notmuch-show.c| 6 +++---
test/T170-sexp.sh | 8
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git
Deliberately populate the message's cryptographic status while walking
the MIME tree from the CLI.
---
mime-node.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/mime-node.c b/mime-node.c
index cbff95d1..6ecd121d 100644
--- a/mime-node.c
+++ b/mime
This allows MUAs that don't want to think about per-mime-part
cryptographic status to have a simple high-level overview of the
message's cryptographic state.
Sensibly structured encrypted and/or signed messages will work fine
with this. The only requirement for the simplest encryption + signing
i
From: Jameson Graef Rollins
This makes it easier to write fairly compact, readable tests of json
output, without needing to sanitize away parts that we don't care
about.
Signed-off-by: Daniel Kahn Gillmor
---
test/json_check_nodes.py | 112 +++
test
When indexing the cleartext of an encrypted message, record any
protected subject in the database, which should make it findable and
visible in search.
---
lib/index.cc | 42 ++
lib/message.cc | 8 +++
lib/notmuch-private.h
Make sure that we emit the correct cryptographic envelope status for
cleartext signed messages.
---
test/T356-protected-headers.sh| 11 ++-
.../signed-protected-header.eml | 29 +++
.../protected-headers/simple-signed-mail.eml | 28 +++
Up to this point, we've tested protected headers on messages that have
either been encrypted or signed, but not both.
This adds a couple tests of signed+encrypted messages, one where the
subject line is masked (outside subject line is "encrypted message")
and another where it is not (outside Subje
E-mail encryption and signatures reported by notmuch are at the MIME
part level. This makes sense in the dirty details, but for users we
need to have a per-message conception of the cryptographic state of
the e-mail. (see
https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html for more
discus
Adding another test to ensure that we handle it gracefully when no
external subject is present.
---
test/T356-protected-headers.sh| 6
.../subjectless-protected-header.eml | 29 +++
2 files changed, 35 insertions(+)
create mode 100644
test/corpora/p
Unsigned encrypted mail shows up with a weird empty signature list.
If we successfully decrypted and there was no signature in it, we
should just not show a sigstatus at all.
The documentation for g_mime_decrypt_result_get_signatures says:
a GMimeSignatureList or NULL if the stream was not si
Correctly fix the two outstanding tests so that the protected (hidden)
subject is properly reported.
---
notmuch-client.h | 2 +-
notmuch-reply.c| 4 +++-
notmuch-show.c | 11 +++
test/T356-protected-headers.sh | 3 ---
4 files changed, 11 i
Here we add several variant e-mail messages, some of which have
correctly-structured protected headers, and some of which do not. The
goal of the tests is to ensure that the right protected subjects get
reported.
---
test/T356-protected-headers.sh| 69 +++
...le-wr
This test scans for all the possible protected headers (including
bogus/broken ones) that are present in the protected-headers corpus,
trying to make sure that only the ones that are not broken or
malformed show up in a search after re-indexing.
---
test/T356-protected-headers.sh | 9 +
1
This makes it easier to reuse format_part_sigstatus_sprinter() when we
have other places that we want to display a signature status.
---
notmuch-show.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index 9871159d..f0be8060 100644
--- a/no
The mime node context (a per-message context) gains a cryptographic
status object, and the mime_node_t object itself can return a view on
that status to an interested party.
The status is not yet populated, and for now we can keep that view
read-only, so that it can only be populated/modified duri
When walking the MIME tree, if we discover that we are at the
cryptographic payload, then we would like to record at least the
Subject header.
In the future, we might want to record many other headers as well, but
for now we will stick with just the Subject.
See
https://dkg.fifthhorseman.net/blog
Traditionally, encrypted and signed e-mail covers only the body of the
message. New standards are emerging that are capable of protecting
the headers as well. In particular, Enigmail and an upcoming version
of K-9 mail both use the "Memory Hole" approach to encrypt the
Subject: header when sendin
On Tue 2017-12-12 01:15:48 -0500, Daniel Kahn Gillmor wrote:
> Inline PGP encrypted messages are clearly worse than PGP/MIME
> structured encrypted messages. There are no standards for how they
> are formed, and they don't offer any structured metadata about how to
> interpr
On Tue 2018-05-01 22:36:31 -0300, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>
>> +
>> +if (params->crypto.decrypt == NOTMUCH_DECRYPT_TRUE &&
>> session_key_count_error == NOTMUCH_STATUS_SUCCESS) {
>> +unsi
I like the ideas behind this patch. it's labeled WIP, presumably
because it doesn't handle ordering the subject lines, right?
further comments below inline:
On Tue 2017-12-19 09:15:40 -0400, David Bremner wrote:
> +/* Remove all values from a document; currently these are
> + all regenerated d
hey good notmuch people.
I noticed today that "notmuch reply --format=json id:f...@example.net"
emits a json object that contains:
"match": false,
reading devel/schemata, it looks like this is kind of a vestigial thing
from "notmuch show" and it doesn't really belong in "notmuch reply".
brem
On Mon 2018-04-30 08:42:24 -0300, David Bremner wrote:
> David Bremner writes:
>
>> Daniel Kahn Gillmor writes:
>>
>>> We make use here of GMime's optimization function for detecting the
>>> presence of inline PGP encrypted content, which is only
On Tue 2018-01-09 18:12:23 -0500, Daniel Kahn Gillmor wrote:
> This is a revision of the series initially introduced in
> id:20171212025225.11854-1-...@fifthhorseman.net, with minor updates to
> accomodate the recent release of notmuch 0.26 (yay!)
>
> This series allows "notmuc
eral Public License for more details.
*
* You should have received a copy of the GNU General Public License
- * along with this program. If not, see http://www.gnu.org/licenses/ .
+ * along with this program. If not, see https://www.gnu.org/licenses/ .
*
* Author: David Bremner
*/
diff -
On Wed 2018-04-18 20:13:54 -0300, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>> On Fri 2018-04-06 08:43:07 -0300, David Bremner wrote:
>>> At least Fedora28 triggers this Xapian bug due to some toolchain change .
>>>
>>>https://bugzilla.redhat.com
On Fri 2018-04-06 08:43:07 -0300, David Bremner wrote:
> At least Fedora28 triggers this Xapian bug due to some toolchain change .
>
>https://bugzilla.redhat.com/show_bug.cgi?id=1546162
>
> The underlying bug is fixed in xapian commit f92e2a936c1592, and
> should be fixed in Xapian 1.4.6
is th
On Sun 2018-04-15 01:24:03 +0300, Tomi Ollila wrote:
> Instead the huge amount of noise in these messages, I suggest:
I agree with Tomi's suggestion that the simplest possible messages are
the best for testing (i haven't tried either of them yet myself though).
--dkg
_
On Fri 2018-04-13 22:46:08 -0300, David Bremner wrote:
> Other parts of notmuch (e.g. notmuch show) expect each thread to
> contain at least one top level message, and crash if this expectation
> is not met.
> ---
> lib/thread.cc| 8 +++-
> test/T050-new.sh | 1 -
> 2 files changed, 7 inse
On Sat 2018-04-07 19:10:51 -0300, David Bremner wrote:
> I think we've diverged enough from the Xapian query parser
> that we can't rely on that syntax description [1]. As far as I can
> tell, [1] also only discusses quotes in the context of phrases.
>
> [1]: https://xapian.org/docs/queryparser.htm
On Sun 2018-04-08 08:12:20 -0300, David Bremner wrote:
> The extra test_done looks like a typo
> ---
> test/T700-reindex.sh | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/test/T700-reindex.sh b/test/T700-reindex.sh
> index 2b7bc658..9e795896 100755
> --- a/test/T700-reindex.sh
> +++ b/tes
On Mon 2018-04-02 18:58:28 +0200, Varac wrote:
> I'd like to know the state of header encryption support for
> notmuch (aka memoryhole) [1].
"memoryhole" refers to "protected headers", not just encrypted headers.
That is, the headers can be protected both by cryptographic signature
*and* by encry
On Sun 2018-03-18 21:32:35 +0200, Jani Nikula wrote:
> On Sun, 18 Mar 2018, Daniel Kahn Gillmor wrote:
>> * if we know our index expects english, and we have a message part that
>>*is not* english (e.g. Content-Language: es), we could avoid indexing
>>that part.
>
On Sun 2018-03-18 03:30:25 +0100, Georg Faerber wrote:
> Signed-off-by: Georg Faerber
> ---
> NEWS | 4 ++--
> bindings/python/docs/source/filesystem.rst | 2 +-
> contrib/go/src/notmuch/notmuch.go | 2 +-
> debian/changelog
https://tools.ietf.org/html/rfc3282 describes a Content-Language:
header. https://tools.ietf.org/html/rfc8255 describes
a multipart/multilingual Content-Type.
notmuch currently uses xapian with a hard-coded English stemmer which
works great for me as a monolingual American, but limits the
applica
On Sun 2018-03-18 04:30:06 +0100, Georg Faerber wrote:
> I'm using notmuch 0.26-1+b2 out of Debian unstable.
> The files created inside .notmuch/xapian by notmuch are group and world
> readable. Is this on purpose? This seems quite suboptimal, especially
> if one is using the recently introduced
On Fri 2018-03-16 19:30:37 +0100, Floris Bruynooghe wrote:
> If someone can hook pytest runs with various python versions into the
> notmuch test suit I'd be very much obliged and probably have another go
> at this as it's still an interesting problem and gives a nice way
> forward.
I don't really
On Wed 2018-03-14 22:54:06 -0300, David Bremner wrote:
> There doesn't seem to be a good reason to drop ~/.notmuch-config
> completely here. As Tomi notes, that would break notmuch for all current
> users. I suppose I could live with $XDG_CONFIG_HOME/notmuch/config (or
> whatever) taking precedence
Currently, notmuch has the levers needed to set coherent crypto policy
around how cleartext is indexed, which also has an impact on how
messages are rendered. But we don't have a lot of documentation about
how to do sensible things. This is an initial attempt to address
that.
The first example s
On Mon 2018-02-12 09:53:33 -0800, W. Trevor King wrote:
> That Python-2-only tool should be using python2 in its shebang. This
> is exactly the sort of issue that PEP 394 was created to address.
Thanks for the suggestion, i've asked them to do that:
https://bugs.debian.org/890282
> Once you patc
Hi Marko--
On Wed 2018-02-14 14:58:12 -0400, Marko Schuetz-Schmuck wrote:
> I received an email today that appears to have been encrypted by
> flowcrypt. Notmuch did not seem to detect the decryption. It detects
> encryption and decrypts correctly if I send an encrypted email to
> myself...
i don
On Thu 2018-02-15 07:53:11 +0200, Tomi Ollila wrote:
> But to emphasize my desire (where I can contribute to) and something
> Carl was worried at that we'd lose capability to edit configuration
> file with an editor I think we sould have a way to export the configuration
> to easily editable file a
On Thu 2018-02-15 15:47:21 -0500, Brian Sniffen wrote:
> show_thread_nav = True , and take through
> https://github.com/briansniffen/notmuch/commit/021c914fc5cc1029778794cc5630373041066889
ah, i'd missed some of your commits, apparently. thanks for the
pointer. https://notmuchmail.org/btsmail i
On Thu 2018-02-15 10:56:29 -0800, W. Trevor King wrote:
> On Thu, Feb 15, 2018 at 11:01:40AM -0500, Daniel Kahn Gillmor wrote:
>> - "message-url": "http://mid.gmane.org/{message-id}";
>> + "message-url": "https://mid.gmane.org/{message-
On Sun 2018-02-11 15:03:05 -0500, Daniel Kahn Gillmor wrote:
> On Sat 2018-02-10 13:57:34 -0500, Brian Sniffen wrote:
>> It looks like you have thread next/pref turned off. Is there a reason,
>> including the reason that I hadn’t documented it?
>
> nope, i just didn't
this program. If not, see http://www.gnu.org/licenses/ .
+ * along with this program. If not, see https://www.gnu.org/licenses/ .
*
* Author: David Bremner
*/
diff --git a/notmuch-reindex.c b/notmuch-reindex.c
index 5d702510..d8589120 100644
--- a/notmuch-reindex.c
+++ b/notmuch-reindex.c
On Fri 2018-02-09 12:46:24 -0800, W. Trevor King wrote:
> From later on in PEP 394 [1]:
>
> It is anticipated that there will eventually come a time where the
> third party ecosystem surrounding Python 3 is sufficiently mature
> for this recommendation to be updated to suggest that the python
Hi Carl--
On Fri 2018-02-09 19:08:59 -0800, Carl Worth wrote:
> One of the things that has always bugged me about a bunch of that Debian
> build utilities is that they spit out results into the parent directory
> of the current working directory from where they are invoked.
i agree that this is a
On Sat 2018-02-10 13:57:34 -0500, Brian Sniffen wrote:
> It looks like you have thread next/pref turned off. Is there a reason,
> including the reason that I hadn’t documented it?
nope, i just didn't fiddle with it much beyond setting it up and trying
to make sure the system integration didn't see
On Fri 2018-02-09 09:12:57 -0800, W. Trevor King wrote:
> On Thu, Feb 08, 2018 at 11:32:11PM -0500, Daniel Kahn Gillmor wrote:
>> nmbug and notmuch-report are developer tools. It's 2018, and all
>> developers should have python3 available.
>
> From PEP 394 [1]:
>
On Fri 2018-02-09 06:28:04 +, Adam Plaice wrote:
> Thanks very much for the reply. I fully agree that the verifying of
> git tags by MELPA would be valuable (and rather important from a
> security perspective), and will bring it up.
Thanks for doing that! If you need any backup in the discus
On Sun 2018-01-07 20:12:14 -0400, David Bremner wrote:
> Daniel Kahn Gillmor writes:
>
>> On Sun 2018-01-07 17:30:25 -0400, David Bremner wrote:
>>> Although such lines can't occur in notmuch dump output, they might be
>>> useful for clearing config, and
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/
On Sun 2018-02-04 23:09:35 -0500, Daniel Kahn Gillmor wrote:
> I did a bit of experimenting with Brian Sniffen's proposed notmuch-web
> branch, and it's now (temporarily) publishing a view of the notmuch
> mailing list here:
>
> https://nmbug.notmuchmail.org/btsmail/
the user's umask. if the umask is
already set tight, it will not become looser as the result of passing
--world-readable.
Signed-off-by: Daniel Kahn Gillmor
---
doc/man1/notmuch-insert.rst | 6 ++
notmuch-insert.c| 25 ++-
601 - 700 of 1575 matches
Mail list logo
