[PATCH] Allow selecting which version of gmime is used to build notmuch.

This allows for testing against both versions of gmime on a single machine, without having to mess with pkg-config paths. --- configure |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/configure b/configure index 8b85b9d..630d647 100755 --- a/configure +++

a DoS vulnerability associated with conflated Message-IDs?

On Thu, 8 Mar 2012 10:38:32 -0700, Jeremy Nickurak wrote: > On Thu, Mar 8, 2012 at 10:16, Daniel Kahn Gillmor > wrote: > > Any other suggestions or ideas? > > What about representing the contents from both message in one apparent > message? > - ... > - If the bodies disagree, display both.

Re: a DoS vulnerability associated with conflated Message-IDs?

On Thu, 8 Mar 2012 10:38:32 -0700, Jeremy Nickurak not-m...@trk.nickurak.ca wrote: On Thu, Mar 8, 2012 at 10:16, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: Any other suggestions or ideas? What about representing the contents from both message in one apparent message? - ... - If

[PATCH] Allow selecting which version of gmime is used to build notmuch.

This allows for testing against both versions of gmime on a single machine, without having to mess with pkg-config paths. --- configure |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/configure b/configure index 8b85b9d..630d647 100755 --- a/configure +++

Replacing my name/email with "me" (or similar) in author lists

On Sun, 26 Feb 2012 12:51:49 -0400, David Bremner wrote: > I have sometimes wondered about having another library layer making some > of the current CLI functionality accessible to bindings. I'm not really > sure of the pro's and con's of such approach. It would certainly be > overkill for this

Re: Replacing my name/email with me (or similar) in author lists

On Sun, 26 Feb 2012 12:51:49 -0400, David Bremner da...@tethera.net wrote: I have sometimes wondered about having another library layer making some of the current CLI functionality accessible to bindings. I'm not really sure of the pro's and con's of such approach. It would certainly be

[RFC PATCH 1/3] emacs: selection-menu.el

On Fri, 24 Feb 2012 23:36:23 +, Mark Walters wrote: > I have played with this and I like the feel of it: it is much more > informative than completing-read and much less cluttered than > ido-completing-read. I wonder if the completion method should be customizable, rather than forcing a

[PATCH v2 2/2] Add pseudo-compatibility with gmime 2.6

On Tue, 17 Jan 2012 11:50:53 +0100, Thomas Jost wrote: > This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the > crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test > fails (signature verification with signer key unavailable) but this will be > hard

Re: [PATCH v2 2/2] Add pseudo-compatibility with gmime 2.6

On Tue, 17 Jan 2012 11:50:53 +0100, Thomas Jost schno...@schnouki.net wrote: This was tested against both gmime 2.6.4 and 2.4.31. With gmime 2.4.31, the crypto tests all work fine (as expected). With gmime 2.6.4, one crypto test fails (signature verification with signer key unavailable) but

[PATCH] notmuch: Quiet buildbot warnings.

On Wed, 21 Dec 2011 23:06:50 +0100, Thomas Jost wrote: Non-text part: multipart/mixed Non-text part: multipart/signed > On Tue, 20 Dec 2011 15:20:04 +, David Edmondson wrote: > > Cast away the result of various *write functions. Provide a default > > value for some variables to avoid "use

Re: [PATCH] notmuch: Quiet buildbot warnings.

On Wed, 21 Dec 2011 23:06:50 +0100, Thomas Jost schno...@schnouki.net wrote: Non-text part: multipart/mixed Non-text part: multipart/signed On Tue, 20 Dec 2011 15:20:04 +, David Edmondson d...@dme.org wrote: Cast away the result of various *write functions. Provide a default value for

Re: More ideas about logging.

On Sun, 18 Dec 2011 14:34:00 -0400, David Bremner brem...@debian.org wrote: The more worrying part is disk usage; the tag tree for 200k messages uses 400k inodes, and 836M of apparent disk usage (according to du) the same tags in sup format take 11M. Maybe this could be usefull if combined

Re: [alot] Introducing myself, asking various questions

On Sun, 18 Dec 2011 19:59:28 +0100, Krzysztof Ilowiecki k...@ilowiecki.com wrote: I understand synchronisation across machines and with IMAP is something of an issue so far. How bad would it be to use git for that - and for 'undo'? It would appear some people use git+maildir even instead of

Re: [PATCH 0/5] Store message modification times in the DB

On Mon, 19 Dec 2011 14:48:21 -0500, Austin Clements amdra...@mit.edu wrote: This protocol requires significantly more state, but can also reconstruct per-tag changes. Conflict resolution is equivalent to what git would do and is based solely on the current local and remote state and the

[PATCH 0/5] Store message modification times in the DB

On Mon, 19 Dec 2011 14:48:21 -0500, Austin Clements wrote: > This protocol requires significantly more state, but can also > reconstruct per-tag changes. Conflict resolution is equivalent to > what git would do and is based solely on the current local and remote > state and the common ancestor

More ideas about logging.

On Sun, 18 Dec 2011 14:34:00 -0400, David Bremner wrote: > The more worrying part is disk usage; the tag tree for 200k messages > uses 400k inodes, and 836M of apparent disk usage (according to du) the > same tags in "sup" format take 11M. Maybe this could be usefull if > combined with some

[alot] Introducing myself, asking various questions

On Sun, 18 Dec 2011 19:59:28 +0100, Krzysztof Ilowiecki wrote: > I understand synchronisation across machines and with IMAP is something > of an issue so far. How bad would it be to use git for that - and for > 'undo'? It would appear some people use git+maildir even instead of > IMAP, but I

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

On Fri, 16 Dec 2011 21:19:37 -0400, David Bremner wrote: > On Fri, 16 Dec 2011 15:45:26 -0800, Jameson Graef Rollins finestructure.net> wrote: > > > Hey, David. What exactly is the problem here? These seems like it's > > actually reasonable behavior when you're using emacs in daemon mode, > >

Re: [PATCH 3/3] test: add emacs test for hiding a message following an HTML part

On Thu, 15 Dec 2011 08:14:08 -0400, David Bremner da...@tethera.net wrote: On Mon, 4 Jul 2011 05:59:03 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: Result: nothing happens except for No URL at point message Expected result: the second message is shown/hidden

[PATCH 3/3] test: add emacs test for hiding a message following an HTML part

On Thu, 15 Dec 2011 08:14:08 -0400, David Bremner wrote: > On Mon, 4 Jul 2011 05:59:03 +0400, Dmitry Kurochkin gmail.com> wrote: > > Result: nothing happens except for "No URL at point" message > > > > Expected result: the second message is shown/hidden > > Unfortunately this patch is

[PATCH 0/3] Configuration file option to exclude files/directories

On Wed, 07 Dec 2011 19:51:32 -0400, David Bremner wrote: > I could see idea of excluding spam and trash folders from indexing being > useful, but this has been sitting in the list for a few months without > comment. Does that mean no-one but Tomi thinks the functionality is > interesting? Or it

Re: [PATCH 0/3] Configuration file option to exclude files/directories

On Wed, 07 Dec 2011 19:51:32 -0400, David Bremner da...@tethera.net wrote: I could see idea of excluding spam and trash folders from indexing being useful, but this has been sitting in the list for a few months without comment. Does that mean no-one but Tomi thinks the functionality is

[PATCH v3 0/2] notmuch hooks

On Tue, 06 Dec 2011 18:47:01 -0800, Jameson Graef Rollins wrote: > Also, what if we make it so that the post-new hook script only runs if > notmuch new processes new messages? All of my post-new functions don't > need to be run at all if there is no new mail. Or would it make sense to pass this

Re: [PATCH v3 0/2] notmuch hooks

On Tue, 06 Dec 2011 18:47:01 -0800, Jameson Graef Rollins jroll...@finestructure.net wrote: Also, what if we make it so that the post-new hook script only runs if notmuch new processes new messages? All of my post-new functions don't need to be run at all if there is no new mail. Or would it

[PATCH v2 2/2] cli: add support for pre and post notmuch new hooks

On Sun, 04 Dec 2011 21:36:21 +0200, Jani Nikula wrote: > > > +if (run_hooks && !ret && !interrupted) > > > + ret = notmuch_run_hook (db_path, "post-new"); > > > > Does it matter at this point if the hook fails? I'm not sure. > > I wasn't sure either, but I ended up thinking that the hooks

Re: [PATCH v2 2/2] cli: add support for pre and post notmuch new hooks

On Sun, 4 Dec 2011 01:16:49 +0200, Jani Nikula j...@nikula.org wrote: Run notmuch new pre and post hooks, named pre-new and post-new, if present in the notmuch hooks directory. The hooks will be run before and after incorporating new messages to the database. Typical use cases for pre-new

Re: [PATCH v2 2/2] cli: add support for pre and post notmuch new hooks

On Sun, 04 Dec 2011 21:36:21 +0200, Jani Nikula j...@nikula.org wrote: +if (run_hooks !ret !interrupted) + ret = notmuch_run_hook (db_path, post-new); Does it matter at this point if the hook fails? I'm not sure. I wasn't sure either, but I ended up thinking that the hooks

[PATCH] dump: Don't sort the output by message id.

From: Thomas Schwinge Asking xapian to sort the messages for us causes suboptimal IO patterns. This would be useful, if we only wanted the first few results, but since we want everything anyway, this is pessimization. On 2011-10-29, a measurement on a 372981 messages

[PATCH] dump: Don't sort the output by message id.

From: Thomas Schwinge tho...@schwinge.name Asking xapian to sort the messages for us causes suboptimal IO patterns. This would be useful, if we only wanted the first few results, but since we want everything anyway, this is pessimization. On 2011-10-29, a measurement on a 372981 messages

[PATCH] Link libutil using filenmae, rather than using -l.

glibc includes a libutil, so if the wrong -L options get passed, we will pick up glibc's version, rather than our own. --- lib/Makefile.local |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/Makefile.local b/lib/Makefile.local index cb53781..54c4dea 100644 ---

[PATCH] Don't link libnotmuch if libutil isn't linked in properly.

For some reason, on my machine, the link is picking up /usr/lib/libutil.so instead of util/libutil.a. This causes there to be undefined symbols in libnotmuch, making it unuseable. This patch causes the link to fail instead. --- lib/Makefile.local |2 +- 1 files changed, 1 insertions(+), 1

[PATCH] Don't link libnotmuch if libutil isn't linked in properly.

For some reason, on my machine, the link is picking up /usr/lib/libutil.so instead of util/libutil.a. This causes there to be undefined symbols in libnotmuch, making it unuseable. This patch causes the link to fail instead. --- lib/Makefile.local |2 +- 1 files changed, 1 insertions(+), 1

[PATCH] Link libutil using filenmae, rather than using -l.

glibc includes a libutil, so if the wrong -L options get passed, we will pick up glibc's version, rather than our own. --- lib/Makefile.local |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/Makefile.local b/lib/Makefile.local index cb53781..54c4dea 100644 ---

Re: [PATCH] Don't link libnotmuch if libutil isn't linked in properly.

Perhaps the g++ step in symbol-hiding should in fact be a test. Right now, that step failing isn't captured by the test-suite. Tom ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch

output file argument to notmuch dump.

On Thu, 06 Oct 2011 21:53:57 -0300, David Bremner wrote: > On Fri, 07 Oct 2011 04:37:56 +0400, Dmitry Kurochkin gmail.com> wrote: > > On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner wrote: > > > IMHO 1[+2] is the way. It breaks the dump command interface, but would > > make it consistent

notmuch and git

I know that having an exclude option for notmuch has been discussed a number of times. I have wanted such a feature to be able to ignore the .git directroy, since I keep my mail in a git repository. I recently discovered a workaround. If you make .git a text file containing = .git

notmuch and git

I know that having an exclude option for notmuch has been discussed a number of times. I have wanted such a feature to be able to ignore the .git directroy, since I keep my mail in a git repository. I recently discovered a workaround. If you make .git a text file containing = .git

python(?): process died while iterating over Messages object

On Fri, 30 Sep 2011 12:43:53 +0200, Justus Winter <4winter at informatik.uni-hamburg.de> wrote: > while iterating over a query result set my process died with > > > terminate called after throwing an instance of > > 'Xapian::DatabaseModifiedError' > > Aborted > > I am not sure where this came

Re: python(?): process died while iterating over Messages object

On Fri, 30 Sep 2011 12:43:53 +0200, Justus Winter 4win...@informatik.uni-hamburg.de wrote: while iterating over a query result set my process died with terminate called after throwing an instance of 'Xapian::DatabaseModifiedError' Aborted I am not sure where this came from, grepping

[PATCH] Skip dot files in `notmuch new`

On Tue, 23 Aug 2011 20:11:53 -0400, James Vasile wrote: > No known mail client or fetch tool stores mail in dot files, because > files that start with '.' are usually used to store metadata > (i.e. state or configuration) as opposed to subject-matter data. Dovecot stores folders in directories

Re: [PATCH] Skip dot files in `notmuch new`

On Tue, 23 Aug 2011 20:11:53 -0400, James Vasile ja...@hackervisions.org wrote: No known mail client or fetch tool stores mail in dot files, because files that start with '.' are usually used to store metadata (i.e. state or configuration) as opposed to subject-matter data. Dovecot stores

branchs and tags and merges oh my!

On Sat, 02 Jul 2011 09:44:50 -0300, David Bremner wrote: > This has the advantage that "git describe master" starts to count from > 0.6 instead of 0.5. Currently e.g. "make dist" on master is making > notmuch-0.5-317-gd15faa1.tar.gz. Unless we are going for the > "increasingly innacurately named"

Re: branchs and tags and merges oh my!

On Sat, 02 Jul 2011 09:44:50 -0300, David Bremner da...@tethera.net wrote: This has the advantage that git describe master starts to count from 0.6 instead of 0.5. Currently e.g. make dist on master is making notmuch-0.5-317-gd15faa1.tar.gz. Unless we are going for the increasingly

(auto-)tagging sent messages

On 2011-04-17, Pieter Praet wrote: > On Sat, 16 Apr 2011 15:23:44 -0400, Tom Prince > wrote: > > > > Further, for certain mails I sent (like this one ) I would like a > > > > WAITING tag (or similar) in order to indicate that I am waiting for an > > >

(auto-)tagging sent messages

> > Further, for certain mails I sent (like this one ) I would like a > > WAITING tag (or similar) in order to indicate that I am waiting for an > > answer. Currently I set this manually. Could this be achieved through > > some indicators via message mode or similar means? e.g.: > > > > <#notmuch

Re: (auto-)tagging sent messages

Further, for certain mails I sent (like this one ) I would like a WAITING tag (or similar) in order to indicate that I am waiting for an answer. Currently I set this manually. Could this be achieved through some indicators via message mode or similar means? e.g.: #notmuch tag=WAITING

[PATCH 0/4] Versatile date/time parser

On 2011-01-23, Michal Sojka wrote: > Hi all, > > the following patch series brings into notmuch date/time parser stolen > from GNU coreutils. It can be applied on top of custom query parser > patches from Austin Clements. > > This is RFC and it not meant for merging. Another source for date

Re: [PATCH 0/4] Versatile date/time parser

On 2011-01-23, Michal Sojka wrote: Hi all, the following patch series brings into notmuch date/time parser stolen from GNU coreutils. It can be applied on top of custom query parser patches from Austin Clements. This is RFC and it not meant for merging. Another source for date parsing is