[notmuch] pull request
On Thu, 01 Apr 2010 14:09:57 -0700, Carl Worth wrote: > More significantly, this level of documentation needs to be put into the > "notmuch help" output (instead of the placeholder that's there in the > current patch). It also needs to be added to the man page in notmuch.1. Allow me to shamelessly plug my podification of notmuch docs :) id:1262281169-24909-1-git-send-email-david at tethera.net This would allow only maintaining the docs in one place. David
[notmuch] notmuch vs gmail filters
Hey *,
I'm currently using gmail for my mail and trying to port its behaviour
to notmuch. I had a go at writing a python script to convert my gmails
to notmuch tag commands along the lines of Carl's post [0]. It uses
the Gmail labs feature to export filters (to an XML file), and then
goes from XML stanzas like:
Mail Filter
tag:mail.google.com,2008:filter:1270085835242
2010-04-01T05:33:40Z
(which says to tag messages from updates at linked.com with "flyers" and
skip the inbox) into a notmuch command like:
notmuch tag -inbox +flyers -- from:updates at linkedin.com '(' not
tag:flyers or tag:inbox ')'
The bit in brackets makes sure it doesn't tag messages that already
have exactly the right tags -- this coule probably be implied in any
invocation of notmuch tag really...
Anyway, attached. It converts gmail's list: match to a notmuch to:
match, and just gives up on deliveredto: matches. But maybe someone
else finds it useful/interesting too :)
Cheers,
aj
[0] id:87r5o8stbj.fsf at yoom.home.cworth.org
--
Anthony Towns
-- next part --
A non-text attachment was scrubbed...
Name: gmail2notmuch.py
Type: text/x-python
Size: 1980 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100401/63950a4b/attachment.py>
[notmuch] [PATCH] Setup the GMimeStream only when needed
On Thu, 01 Apr 2010, nstraz at redhat.com wrote:
> I ran into this while looking at the vim plugin. Vim's system() call
> redirects output to a file and it was missing many of the part{ lines.
>
> If stream_stdout is setup too early, it will overwrite the part start
> when notmuch is redirected to a file.
Hi,
thanks for the patch. After some investigation, it seems that you are
right. What I missed in your commit message is the reason for such
behaviour i.e. GMimeStream fseek()s in its write method to the position
recorded when the stream was created, so that in case there is somebody
else writing to the stream, the writes may overlap.
-Michal
Re: [notmuch] pull request
On Thu, 01 Apr 2010 14:09:57 -0700, Carl Worth wrote: > More significantly, this level of documentation needs to be put into the > "notmuch help" output (instead of the placeholder that's there in the > current patch). It also needs to be added to the man page in notmuch.1. Allow me to shamelessly plug my podification of notmuch docs :) id:1262281169-24909-1-git-send-email-da...@tethera.net This would allow only maintaining the docs in one place. David ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] pull request
Carl, a couple of patches that I'd like you to consider. They are the first two on the `dme' branch of git://github.com/dme/notmuch.git. http://github.com/dme/notmuch/commit/f86254e4509ed02731aa3eaa8541df1f2d11e400 > notmuch-show: Add unix and pretty dates to the JSON output > > Include a 'date_unix' and 'date_pretty' field in the JSON output for > each message. 'date_pretty' can be used by a UI implementation, > whereas 'date_unix' is useful when scripting. http://github.com/dme/notmuch/commit/dfd99e186ffc6b759c4e09a990c43bb6b8743ef2 > notmuch: Add a 'part' subcommand > > A new 'part' subcommand allows the user to extract a single part from a > MIME message. Usage: > > notmuch part --part= > > The search terms should match only a single message > (e.g. id:foo at bar.com). The part number specified refers to the part > identifiers output by `notmuch show'. The content of the part is written > the stdout with no formatting or identification marks. It is not JSON > formatted. The second of these (part) has been the topic of some discussion. There's a suggestion that a 'cat' subcommand or '--format=raw' option to the 'show' subcommand would be better. I'm not particular preference - I just wanted the functionality to use in the Emacs UI. (URLs included as the github frontend is quite nice for perusing the changes.) dme. -- David Edmondson, http://dme.org
Re: [notmuch] Notmuch shared library
On Thu, 01 Apr 2010 14:44:36 +0200, Michal Sojka wrote: > On Thu, 01 Apr 2010, Carl Worth wrote: > > 1. Use rpath for the local notmuch, (and use chrpath to remove it at the > >time of "make install"). > > > > 3. Create a static program locally, but install a shared version. > > > > 4. Create a static program by default, and make distributions pass a > >--shared option to get the shared version that they want. > > I'd like to be able to run gdb easily on non-installed notmuch, so I'm > fine with 1, 3 and 4. I really like the idea of (1) but it might cause a dependency on chrpath, which would be obnoxious. Otherwise, it would require linking the final application twice. But if we're going to link twice, we might as well just do that (3). I now don't see any advantage of (4) over (3). It's easy to compile both static and shared, so there's not much reason to be able to disable one or the other. So I've now made the default "make" create a static "notmuch" binary and a shared "notmuch-shared" binary. Then, "make install" installs "notmuch-shared" but renames it to "notmuch". The other reason I really wanted something like this is to be able to ensure that the test suite tests the locally-compiled library, (and not some installed version that the dynamic linker finds). -Carl (happy to stay away from the pain of wrapper scripts) pgpeo8OEpElXY.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Notmuch shared library
On Thu, 01 Apr 2010 14:44:36 +0200, Michal Sojka wrote: > On Thu, 01 Apr 2010, Carl Worth wrote: > > 1. Use rpath for the local notmuch, (and use chrpath to remove it at the > >time of "make install"). > > > > 3. Create a static program locally, but install a shared version. > > > > 4. Create a static program by default, and make distributions pass a > >--shared option to get the shared version that they want. > > I'd like to be able to run gdb easily on non-installed notmuch, so I'm > fine with 1, 3 and 4. I really like the idea of (1) but it might cause a dependency on chrpath, which would be obnoxious. Otherwise, it would require linking the final application twice. But if we're going to link twice, we might as well just do that (3). I now don't see any advantage of (4) over (3). It's easy to compile both static and shared, so there's not much reason to be able to disable one or the other. So I've now made the default "make" create a static "notmuch" binary and a shared "notmuch-shared" binary. Then, "make install" installs "notmuch-shared" but renames it to "notmuch". The other reason I really wanted something like this is to be able to ensure that the test suite tests the locally-compiled library, (and not some installed version that the dynamic linker finds). -Carl (happy to stay away from the pain of wrapper scripts) -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100401/a69ae2e5/attachment.pgp>
[notmuch] Notmuch shared library
On Thu, 01 Apr 2010, Carl Worth wrote: > On Thu, 1 Apr 2010 13:24:22 +0200, martin f krafft > wrote: > > also sprach Michal Sojka [2010.04.01.1310 +0200]: > > > this can be solved by the following patch, but I don't know how portable > > > it is. You can see the efect of this by > > > > Please avoid rpath. The better solution is probably to create > > a wrapper for notmuch, which prepends to LD_LIBRARY_PATH. > > So now should actually list some of the ideas I had: > > 1. Use rpath for the local notmuch, (and use chrpath to remove it at the >time of "make install"). > > 2. Create a little shell script that calls LD_LIBRARY_PATH locally, but >then install the real program, (not very unlike what libtool does). > > 3. Create a static program locally, but install a shared version. > > 4. Create a static program by default, and make distributions pass a >--shared option to get the shared version that they want. I'd like to be able to run gdb easily on non-installed notmuch, so I'm fine with 1, 3 and 4. -Michal
Re: [notmuch] [PATCH] Setup the GMimeStream only when needed
On Thu, 1 Apr 2010 10:31:13 -0400, nst...@redhat.com wrote: > On Apr 1 16:21, Michal Sojka wrote: > > On Thu, 01 Apr 2010, nst...@redhat.com wrote: > > thanks for the patch. After some investigation, it seems that you are > > right. What I missed in your commit message is the reason for such > > behaviour i.e. GMimeStream fseek()s in its write method to the position > > recorded when the stream was created, so that in case there is somebody > > else writing to the stream, the writes may overlap. > > Right, and in the case of writing to a pipe, the seek fails and the > file position doesn't change. I found it comparing strace output of > `notmuch show ... > file` and `notmuch show ... | cat > file.` Ah, so the trigger of the bug is that we are currently interleaving calls to printf with GMime writes to a stdout stream. I'm happy to apply this patch to workaround the problem, (and I just did push it with some of my own comments added to the commit message). But isn't this a bug in GMime really? What possible use can it have for doing an fseek on every stream write? That seems broken, and we should report that to the GMime folks. -Carl pgpaqnAYKdkF6.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] Setup the GMimeStream only when needed
On Thu, 1 Apr 2010 10:31:13 -0400, nstraz at redhat.com wrote: > On Apr 1 16:21, Michal Sojka wrote: > > On Thu, 01 Apr 2010, nstraz at redhat.com wrote: > > thanks for the patch. After some investigation, it seems that you are > > right. What I missed in your commit message is the reason for such > > behaviour i.e. GMimeStream fseek()s in its write method to the position > > recorded when the stream was created, so that in case there is somebody > > else writing to the stream, the writes may overlap. > > Right, and in the case of writing to a pipe, the seek fails and the > file position doesn't change. I found it comparing strace output of > `notmuch show ... > file` and `notmuch show ... | cat > file.` Ah, so the trigger of the bug is that we are currently interleaving calls to printf with GMime writes to a stdout stream. I'm happy to apply this patch to workaround the problem, (and I just did push it with some of my own comments added to the commit message). But isn't this a bug in GMime really? What possible use can it have for doing an fseek on every stream write? That seems broken, and we should report that to the GMime folks. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100401/480574fe/attachment.pgp>
Re: [notmuch] pull request
On Thu, 01 Apr 2010 15:41:03 +0100, David Edmondson wrote: > Carl, a couple of patches that I'd like you to consider. They are the > first two on the `dme' branch of git://github.com/dme/notmuch.git. Thanks, David! I've got your branch fetched here and I plan to start playing with it. The feature-set of the branch sounds extremely compelling, so I'm looking forward to usability improvements from this. Thanks so much. > http://github.com/dme/notmuch/commit/f86254e4509ed02731aa3eaa8541df1f2d11e400 > > notmuch-show: Add unix and pretty dates to the JSON output > > > > Include a 'date_unix' and 'date_pretty' field in the JSON output for > > each message. 'date_pretty' can be used by a UI implementation, > > whereas 'date_unix' is useful when scripting. With "date_unix" it's easy enough to guess what the value is. But "date_pretty" is much more ambiguous. I assumed that this would be an RFC 822 date string, (but then found that it's the relative date that "notmuch show" is using currently). I think I'd rather see that named "date_relative", (or dropped with the expectation that callers can decide how to format dates on their own). > > A new 'part' subcommand allows the user to extract a single part from a > > MIME message. Usage: > > > > notmuch part --part= This sounds like great functionality, and is something I had intended to do very early after starting notmuch.el but never got around to. > > The search terms should match only a single message > > (e.g. id:f...@bar.com). The part number specified refers to the part > > identifiers output by `notmuch show'. The content of the part is written > > the stdout with no formatting or identification marks. It is not JSON > > formatted. The above documentation isn't quite complete to me. Is MIME decoding handled by this or not? Also, the documentation says the search terms "should match" only one message, but what does the implementation do if more than one message is matched? It would be good to document that as well. More significantly, this level of documentation needs to be put into the "notmuch help" output (instead of the placeholder that's there in the current patch). It also needs to be added to the man page in notmuch.1. > The second of these (part) has been the topic of some > discussion. There's a suggestion that a 'cat' subcommand or > '--format=raw' option to the 'show' subcommand would be better. I'm not > particular preference - I just wanted the functionality to use in the > Emacs UI. One other approach that I imagined with the json output would be to simply include all of the MIME parts of all messages directly in the json-format output from "notmuch show". Does json have any particular way of encodign a binary blob? If not, should we just have one single encoding here? (Such as BASE64 within a json string?) Looking forward to more, -Carl pgpLCqGXd6YLr.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] pull request
On Thu, 01 Apr 2010 15:41:03 +0100, David Edmondson wrote: > Carl, a couple of patches that I'd like you to consider. They are the > first two on the `dme' branch of git://github.com/dme/notmuch.git. Thanks, David! I've got your branch fetched here and I plan to start playing with it. The feature-set of the branch sounds extremely compelling, so I'm looking forward to usability improvements from this. Thanks so much. > http://github.com/dme/notmuch/commit/f86254e4509ed02731aa3eaa8541df1f2d11e400 > > notmuch-show: Add unix and pretty dates to the JSON output > > > > Include a 'date_unix' and 'date_pretty' field in the JSON output for > > each message. 'date_pretty' can be used by a UI implementation, > > whereas 'date_unix' is useful when scripting. With "date_unix" it's easy enough to guess what the value is. But "date_pretty" is much more ambiguous. I assumed that this would be an RFC 822 date string, (but then found that it's the relative date that "notmuch show" is using currently). I think I'd rather see that named "date_relative", (or dropped with the expectation that callers can decide how to format dates on their own). > > A new 'part' subcommand allows the user to extract a single part from a > > MIME message. Usage: > > > > notmuch part --part= This sounds like great functionality, and is something I had intended to do very early after starting notmuch.el but never got around to. > > The search terms should match only a single message > > (e.g. id:foo at bar.com). The part number specified refers to the part > > identifiers output by `notmuch show'. The content of the part is written > > the stdout with no formatting or identification marks. It is not JSON > > formatted. The above documentation isn't quite complete to me. Is MIME decoding handled by this or not? Also, the documentation says the search terms "should match" only one message, but what does the implementation do if more than one message is matched? It would be good to document that as well. More significantly, this level of documentation needs to be put into the "notmuch help" output (instead of the placeholder that's there in the current patch). It also needs to be added to the man page in notmuch.1. > The second of these (part) has been the topic of some > discussion. There's a suggestion that a 'cat' subcommand or > '--format=raw' option to the 'show' subcommand would be better. I'm not > particular preference - I just wanted the functionality to use in the > Emacs UI. One other approach that I imagined with the json output would be to simply include all of the MIME parts of all messages directly in the json-format output from "notmuch show". Does json have any particular way of encodign a binary blob? If not, should we just have one single encoding here? (Such as BASE64 within a json string?) Looking forward to more, -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100401/74bae8f6/attachment.pgp>
[notmuch] [PATCH] format_part_json: part_content->data is not null terminated
Both of you Davids are indeed completely right. Even more since the next command in the patch after memcpy zeroes that byte. This is how it's meant to be: +content_data = talloc_size (ctx, part_content->len+1); +memcpy (content_data, (char *)part_content->data, part_content->len); +content_data[part_content->len] = 0; Should I submit a fixed patch? Mea culpa, Gregor * David Edmondson [Do Apr 01 13:50:54 +0200 2010] > On Thu, 01 Apr 2010 08:40:37 -0300, David Bremner > wrote: > > On Thu, 04 Mar 2010 11:49:48 +0100, Gregor Hoffleit > > wrote: > > > In format_part_json, part_content->data is not a null terminated > > > string. > > > > I'd like to see this bug fixed, > > +1. > > > and the patch is pretty small, but... > > > > > Instead, we have to use part_content->len. > > > +content_data = talloc_size (ctx, part_content->len+1); > > > +memcpy (content_data, (char *)part_content->data, > > > part_content->len+1); > > > > Can anyone explain why we copy (what seems to me to be) one extra byte > > here? In principle reading outside our allocated memory could cause > > problems; at minimum it makes a false positive for a memory checker like > > valgrind. > > Agreed. It looks as though this should copy only part_content->len bytes. > > dme. -- Gregor Hoffleit Media Supervision Software Consulting GmbH Georg-Friedrich-Haendel-Str. 13, 69214 Eppelheim/Heidelberg Tel: +49 6221 705079-22 / Fax: +49 6221 705079-80 Amtsgericht Mannheim, HRB 336821, Gesch?ftsf?hrer Reinhard Kratzke http://www.mediasupervision.de/
[notmuch] [PATCH] format_part_json: part_content->data is not null terminated
On Thu, 04 Mar 2010, Gregor Hoffleit wrote:
> - printf (", \"content\": %s", json_quote_str (ctx, (char *)
> part_content->data));
> + content_data = talloc_size (ctx, part_content->len+1);
> + memcpy (content_data, (char *)part_content->data, part_content->len+1);
> + content_data[part_content->len] = 0;
> + printf (", \"content\": %s", json_quote_str (ctx, content_data));
What about modifying json_quote_str() to accept additional parameter
len? If I have 10MB attachment to the email, this unnecessary copy is
quite expensive, isn't it?
--Michal
[notmuch] [PATCH] Makefile: Create include directory when installing headers
When I wanted to create a debian package from the current master, make install failed because of non-existent include directory. This patch fixes this minor issue. --- lib/Makefile.local |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/lib/Makefile.local b/lib/Makefile.local index 0fd843a..85b010e 100644 --- a/lib/Makefile.local +++ b/lib/Makefile.local @@ -54,6 +54,7 @@ install-$(dir): $(call quiet_install_data, $(dir)/$(LIBNAME) $(DESTDIR)$(libdir)/) $(call quiet_symlink, $(LIBNAME) $(DESTDIR)$(libdir)/$(SONAME)) $(call quiet_symlink, $(LIBNAME) $(DESTDIR)$(libdir)/$(LINKER_NAME)) + $(call quiet_mkdir, $(DESTDIR)$(prefix)/include/) $(call quiet_install_data, $(dir)/notmuch.h $(DESTDIR)$(prefix)/include/) SRCS := $(SRCS) $(libnotmuch_c_srcs) $(libnotmuch_cxx_srcs) -- 1.7.0.2
[notmuch] Notmuch shared library
also sprach martin f krafft [2010.04.01.1324 +0200]: > Please avoid rpath. The better solution is probably to create > a wrapper for notmuch, which prepends to LD_LIBRARY_PATH. E.g. http://wiki.debian.org/RpathIssue -- martin | http://madduck.net/ | http://two.sentenc.es/ a common mistake that people make when trying to design something completely foolproof was to underestimate the ingenuity of complete fools. -- douglas adams, "mostly harmless" spamtraps: madduck.bogus at madduck.net -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature (see http://martin-krafft.net/gpg/) URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100401/bc9ae064/attachment-0001.pgp>
[notmuch] Notmuch shared library
also sprach Michal Sojka [2010.04.01.1310 +0200]: > this can be solved by the following patch, but I don't know how portable > it is. You can see the efect of this by Please avoid rpath. The better solution is probably to create a wrapper for notmuch, which prepends to LD_LIBRARY_PATH. -- martin | http://madduck.net/ | http://two.sentenc.es/ when everything is coming your way, you're in the wrong lane. spamtraps: madduck.bogus at madduck.net -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature (see http://martin-krafft.net/gpg/) URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100401/ada2fe5b/attachment.pgp>
[notmuch] Notmuch shared library
On Thu, 01 Apr 2010, Carl Worth wrote: > Finally, I'm a tiny bit annoyed that now after a fresh checkout of > notmuch and "make" that one can't easily run ./notmuch without either > installing the library (or fiddling with LD_LIBRARY_PATH). I've got some > ideas on how to simplify that, but I'm not sure if any are good or worth > it. Hi, this can be solved by the following patch, but I don't know how portable it is. You can see the efect of this by $ objdump -x notmuch|grep RPATH diff --git a/Makefile.local b/Makefile.local index 32b8f4a..2a1b55d 100644 --- a/Makefile.local +++ b/Makefile.local @@ -20,7 +20,7 @@ extra_cxxflags := # Smash together user's values with our extra values FINAL_CFLAGS = $(CFLAGS) $(WARN_CFLAGS) $(CONFIGURE_CFLAGS) $(extra_cflags) FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS) $(extra_cflags) $(extra_cxxflags) -FINAL_LDFLAGS = $(LDFLAGS) $(CONFIGURE_LDFLAGS) +FINAL_LDFLAGS = $(LDFLAGS) $(CONFIGURE_LDFLAGS) -Wl,-rpath,\$$ORIGIN/lib -z origin --enable-new-dtags all: notmuch notmuch.1.gz ifeq ($(MAKECMDGOALS),) --Michal
[notmuch] [PATCH] format_part_json: part_content->data is not null terminated
On Thu, 01 Apr 2010 08:40:37 -0300, David Bremner wrote: > On Thu, 04 Mar 2010 11:49:48 +0100, Gregor Hoffleit > wrote: > > In format_part_json, part_content->data is not a null terminated > > string. > > I'd like to see this bug fixed, +1. > and the patch is pretty small, but... > > > Instead, we have to use part_content->len. > > + content_data = talloc_size (ctx, part_content->len+1); > > + memcpy (content_data, (char *)part_content->data, part_content->len+1); > > Can anyone explain why we copy (what seems to me to be) one extra byte > here? In principle reading outside our allocated memory could cause > problems; at minimum it makes a false positive for a memory checker like > valgrind. Agreed. It looks as though this should copy only part_content->len bytes. dme. -- David Edmondson, http://dme.org
[notmuch] Notmuch shared library
On Thu, 01 Apr 2010 00:54:16 -0700, Carl Worth wrote: > Finally, I'm a tiny bit annoyed that now after a fresh checkout of > notmuch and "make" that one can't easily run ./notmuch without either > installing the library (or fiddling with LD_LIBRARY_PATH). I've got some > ideas on how to simplify that, but I'm not sure if any are good or worth > it. That was admittedly a very nice feature. And as I have proposed (but not send any patch :-)). I would argue that a --shared and a --static option (or whatever configure standard policy is for that) would make sense that links notmuch either dynamically or statically. But thanks for doing this work. Much appreciated Sebastian
[notmuch] [PATCH] Setup the GMimeStream only when needed
On Apr 1 16:21, Michal Sojka wrote:
> On Thu, 01 Apr 2010, nstraz at redhat.com wrote:
> > I ran into this while looking at the vim plugin. Vim's system() call
> > redirects output to a file and it was missing many of the part{ lines.
> >
> > If stream_stdout is setup too early, it will overwrite the part start
> > when notmuch is redirected to a file.
>
> thanks for the patch. After some investigation, it seems that you are
> right. What I missed in your commit message is the reason for such
> behaviour i.e. GMimeStream fseek()s in its write method to the position
> recorded when the stream was created, so that in case there is somebody
> else writing to the stream, the writes may overlap.
Right, and in the case of writing to a pipe, the seek fails and the
file position doesn't change. I found it comparing strace output of
`notmuch show ... > file` and `notmuch show ... | cat > file.`
Nate
[notmuch] [PATCH] Setup the GMimeStream only when needed
I ran into this while looking at the vim plugin. Vim's system() call
redirects output to a file and it was missing many of the part{ lines.
If stream_stdout is setup too early, it will overwrite the part start
when notmuch is redirected to a file.
---
notmuch-show.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index ff1fecb..96647c1 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -236,9 +236,6 @@ format_part_text (GMimeObject *part, int *part_count)
{
GMimeContentDisposition *disposition;
GMimeContentType *content_type;
-GMimeStream *stream_stdout = g_mime_stream_file_new (stdout);
-
-g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout), FALSE);
disposition = g_mime_object_get_content_disposition (part);
if (disposition &&
@@ -256,14 +253,14 @@ format_part_text (GMimeObject *part, int *part_count)
if (g_mime_content_type_is_type (content_type, "text", "*") &&
!g_mime_content_type_is_type (content_type, "text", "html"))
{
+ GMimeStream *stream_stdout = g_mime_stream_file_new (stdout);
+ g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout),
FALSE);
show_part_content (part, stream_stdout);
+ g_object_unref(stream_stdout);
}
printf ("\fattachment}\n");
- if (stream_stdout)
- g_object_unref(stream_stdout);
-
return;
}
@@ -276,7 +273,10 @@ format_part_text (GMimeObject *part, int *part_count)
if (g_mime_content_type_is_type (content_type, "text", "*") &&
!g_mime_content_type_is_type (content_type, "text", "html"))
{
+ GMimeStream *stream_stdout = g_mime_stream_file_new (stdout);
+ g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout), FALSE);
show_part_content (part, stream_stdout);
+ g_object_unref(stream_stdout);
}
else
{
@@ -285,9 +285,6 @@ format_part_text (GMimeObject *part, int *part_count)
}
printf ("\fpart}\n");
-
-if (stream_stdout)
- g_object_unref(stream_stdout);
}
static void
--
1.6.6.1
[notmuch] [PATCH] format_part_json: part_content->data is not null terminated
On Thu, 04 Mar 2010 11:49:48 +0100, Gregor Hoffleit wrote: > In format_part_json, part_content->data is not a null terminated > string. I'd like to see this bug fixed, and the patch is pretty small, but... > Instead, we have to use part_content->len. > + content_data = talloc_size (ctx, part_content->len+1); > + memcpy (content_data, (char *)part_content->data, part_content->len+1); Can anyone explain why we copy (what seems to me to be) one extra byte here? In principle reading outside our allocated memory could cause problems; at minimum it makes a false positive for a memory checker like valgrind. David
[notmuch] pull request
Carl, a couple of patches that I'd like you to consider. They are the first two on the `dme' branch of git://github.com/dme/notmuch.git. http://github.com/dme/notmuch/commit/f86254e4509ed02731aa3eaa8541df1f2d11e400 > notmuch-show: Add unix and pretty dates to the JSON output > > Include a 'date_unix' and 'date_pretty' field in the JSON output for > each message. 'date_pretty' can be used by a UI implementation, > whereas 'date_unix' is useful when scripting. http://github.com/dme/notmuch/commit/dfd99e186ffc6b759c4e09a990c43bb6b8743ef2 > notmuch: Add a 'part' subcommand > > A new 'part' subcommand allows the user to extract a single part from a > MIME message. Usage: > > notmuch part --part= > > The search terms should match only a single message > (e.g. id:f...@bar.com). The part number specified refers to the part > identifiers output by `notmuch show'. The content of the part is written > the stdout with no formatting or identification marks. It is not JSON > formatted. The second of these (part) has been the topic of some discussion. There's a suggestion that a 'cat' subcommand or '--format=raw' option to the 'show' subcommand would be better. I'm not particular preference - I just wanted the functionality to use in the Emacs UI. (URLs included as the github frontend is quite nice for perusing the changes.) dme. -- David Edmondson, http://dme.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Setup the GMimeStream only when needed
On Apr 1 16:21, Michal Sojka wrote:
> On Thu, 01 Apr 2010, nst...@redhat.com wrote:
> > I ran into this while looking at the vim plugin. Vim's system() call
> > redirects output to a file and it was missing many of the part{ lines.
> >
> > If stream_stdout is setup too early, it will overwrite the part start
> > when notmuch is redirected to a file.
>
> thanks for the patch. After some investigation, it seems that you are
> right. What I missed in your commit message is the reason for such
> behaviour i.e. GMimeStream fseek()s in its write method to the position
> recorded when the stream was created, so that in case there is somebody
> else writing to the stream, the writes may overlap.
Right, and in the case of writing to a pipe, the seek fails and the
file position doesn't change. I found it comparing strace output of
`notmuch show ... > file` and `notmuch show ... | cat > file.`
Nate
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Setup the GMimeStream only when needed
On Thu, 01 Apr 2010, nst...@redhat.com wrote:
> I ran into this while looking at the vim plugin. Vim's system() call
> redirects output to a file and it was missing many of the part{ lines.
>
> If stream_stdout is setup too early, it will overwrite the part start
> when notmuch is redirected to a file.
Hi,
thanks for the patch. After some investigation, it seems that you are
right. What I missed in your commit message is the reason for such
behaviour i.e. GMimeStream fseek()s in its write method to the position
recorded when the stream was created, so that in case there is somebody
else writing to the stream, the writes may overlap.
-Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] Setup the GMimeStream only when needed
I ran into this while looking at the vim plugin. Vim's system() call
redirects output to a file and it was missing many of the part{ lines.
If stream_stdout is setup too early, it will overwrite the part start
when notmuch is redirected to a file.
---
notmuch-show.c | 15 ++-
1 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index ff1fecb..96647c1 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -236,9 +236,6 @@ format_part_text (GMimeObject *part, int *part_count)
{
GMimeContentDisposition *disposition;
GMimeContentType *content_type;
-GMimeStream *stream_stdout = g_mime_stream_file_new (stdout);
-
-g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout), FALSE);
disposition = g_mime_object_get_content_disposition (part);
if (disposition &&
@@ -256,14 +253,14 @@ format_part_text (GMimeObject *part, int *part_count)
if (g_mime_content_type_is_type (content_type, "text", "*") &&
!g_mime_content_type_is_type (content_type, "text", "html"))
{
+ GMimeStream *stream_stdout = g_mime_stream_file_new (stdout);
+ g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout),
FALSE);
show_part_content (part, stream_stdout);
+ g_object_unref(stream_stdout);
}
printf ("\fattachment}\n");
- if (stream_stdout)
- g_object_unref(stream_stdout);
-
return;
}
@@ -276,7 +273,10 @@ format_part_text (GMimeObject *part, int *part_count)
if (g_mime_content_type_is_type (content_type, "text", "*") &&
!g_mime_content_type_is_type (content_type, "text", "html"))
{
+ GMimeStream *stream_stdout = g_mime_stream_file_new (stdout);
+ g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout), FALSE);
show_part_content (part, stream_stdout);
+ g_object_unref(stream_stdout);
}
else
{
@@ -285,9 +285,6 @@ format_part_text (GMimeObject *part, int *part_count)
}
printf ("\fpart}\n");
-
-if (stream_stdout)
- g_object_unref(stream_stdout);
}
static void
--
1.6.6.1
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Notmuch shared library
On Thu, 01 Apr 2010, Carl Worth wrote: > On Thu, 1 Apr 2010 13:24:22 +0200, martin f krafft > wrote: > > also sprach Michal Sojka [2010.04.01.1310 +0200]: > > > this can be solved by the following patch, but I don't know how portable > > > it is. You can see the efect of this by > > > > Please avoid rpath. The better solution is probably to create > > a wrapper for notmuch, which prepends to LD_LIBRARY_PATH. > > So now should actually list some of the ideas I had: > > 1. Use rpath for the local notmuch, (and use chrpath to remove it at the >time of "make install"). > > 2. Create a little shell script that calls LD_LIBRARY_PATH locally, but >then install the real program, (not very unlike what libtool does). > > 3. Create a static program locally, but install a shared version. > > 4. Create a static program by default, and make distributions pass a >--shared option to get the shared version that they want. I'd like to be able to run gdb easily on non-installed notmuch, so I'm fine with 1, 3 and 4. -Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Makefile: Create include directory when installing headers
On Thu, 1 Apr 2010 13:47:45 +0200, Michal Sojka wrote: > When I wanted to create a debian package from the current master, make > install failed because of non-existent include directory. This patch > fixes this minor issue. Thanks. This is merged now. -Carl pgpfOxRgc30OY.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] Makefile: Create include directory when installing headers
On Thu, 1 Apr 2010 13:47:45 +0200, Michal Sojka wrote: > When I wanted to create a debian package from the current master, make > install failed because of non-existent include directory. This patch > fixes this minor issue. Thanks. This is merged now. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100401/11f564f2/attachment.pgp>
Re: [notmuch] Notmuch shared library
On Thu, 1 Apr 2010 13:24:22 +0200, martin f krafft wrote: > also sprach Michal Sojka [2010.04.01.1310 +0200]: > > this can be solved by the following patch, but I don't know how portable > > it is. You can see the efect of this by > > Please avoid rpath. The better solution is probably to create > a wrapper for notmuch, which prepends to LD_LIBRARY_PATH. So now should actually list some of the ideas I had: 1. Use rpath for the local notmuch, (and use chrpath to remove it at the time of "make install"). 2. Create a little shell script that calls LD_LIBRARY_PATH locally, but then install the real program, (not very unlike what libtool does). 3. Create a static program locally, but install a shared version. 4. Create a static program by default, and make distributions pass a --shared option to get the shared version that they want. I can see advantages and disadvantages to each approach. -Carl pgpthvMYttzPV.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Notmuch shared library
On Thu, 1 Apr 2010 13:24:22 +0200, martin f krafft wrote: > also sprach Michal Sojka [2010.04.01.1310 +0200]: > > this can be solved by the following patch, but I don't know how portable > > it is. You can see the efect of this by > > Please avoid rpath. The better solution is probably to create > a wrapper for notmuch, which prepends to LD_LIBRARY_PATH. So now should actually list some of the ideas I had: 1. Use rpath for the local notmuch, (and use chrpath to remove it at the time of "make install"). 2. Create a little shell script that calls LD_LIBRARY_PATH locally, but then install the real program, (not very unlike what libtool does). 3. Create a static program locally, but install a shared version. 4. Create a static program by default, and make distributions pass a --shared option to get the shared version that they want. I can see advantages and disadvantages to each approach. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100401/1c7bedaf/attachment.pgp>
Re: [notmuch] [PATCH] format_part_json: part_content->data is not null terminated
Both of you Davids are indeed completely right. Even more since the next command in the patch after memcpy zeroes that byte. This is how it's meant to be: +content_data = talloc_size (ctx, part_content->len+1); +memcpy (content_data, (char *)part_content->data, part_content->len); +content_data[part_content->len] = 0; Should I submit a fixed patch? Mea culpa, Gregor * David Edmondson [Do Apr 01 13:50:54 +0200 2010] > On Thu, 01 Apr 2010 08:40:37 -0300, David Bremner wrote: > > On Thu, 04 Mar 2010 11:49:48 +0100, Gregor Hoffleit > > wrote: > > > In format_part_json, part_content->data is not a null terminated > > > string. > > > > I'd like to see this bug fixed, > > +1. > > > and the patch is pretty small, but... > > > > > Instead, we have to use part_content->len. > > > +content_data = talloc_size (ctx, part_content->len+1); > > > +memcpy (content_data, (char *)part_content->data, > > > part_content->len+1); > > > > Can anyone explain why we copy (what seems to me to be) one extra byte > > here? In principle reading outside our allocated memory could cause > > problems; at minimum it makes a false positive for a memory checker like > > valgrind. > > Agreed. It looks as though this should copy only part_content->len bytes. > > dme. -- Gregor Hoffleit Media Supervision Software Consulting GmbH Georg-Friedrich-Haendel-Str. 13, 69214 Eppelheim/Heidelberg Tel: +49 6221 705079-22 / Fax: +49 6221 705079-80 Amtsgericht Mannheim, HRB 336821, Geschäftsführer Reinhard Kratzke http://www.mediasupervision.de/ ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] format_part_json: part_content->data is not null terminated
On Thu, 04 Mar 2010, Gregor Hoffleit wrote:
> - printf (", \"content\": %s", json_quote_str (ctx, (char *)
> part_content->data));
> + content_data = talloc_size (ctx, part_content->len+1);
> + memcpy (content_data, (char *)part_content->data, part_content->len+1);
> + content_data[part_content->len] = 0;
> + printf (", \"content\": %s", json_quote_str (ctx, content_data));
What about modifying json_quote_str() to accept additional parameter
len? If I have 10MB attachment to the email, this unnecessary copy is
quite expensive, isn't it?
--Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] format_part_json: part_content->data is not null terminated
On Thu, 01 Apr 2010 08:40:37 -0300, David Bremner wrote: > On Thu, 04 Mar 2010 11:49:48 +0100, Gregor Hoffleit > wrote: > > In format_part_json, part_content->data is not a null terminated > > string. > > I'd like to see this bug fixed, +1. > and the patch is pretty small, but... > > > Instead, we have to use part_content->len. > > + content_data = talloc_size (ctx, part_content->len+1); > > + memcpy (content_data, (char *)part_content->data, part_content->len+1); > > Can anyone explain why we copy (what seems to me to be) one extra byte > here? In principle reading outside our allocated memory could cause > problems; at minimum it makes a false positive for a memory checker like > valgrind. Agreed. It looks as though this should copy only part_content->len bytes. dme. -- David Edmondson, http://dme.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] Makefile: Create include directory when installing headers
When I wanted to create a debian package from the current master, make install failed because of non-existent include directory. This patch fixes this minor issue. --- lib/Makefile.local |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/lib/Makefile.local b/lib/Makefile.local index 0fd843a..85b010e 100644 --- a/lib/Makefile.local +++ b/lib/Makefile.local @@ -54,6 +54,7 @@ install-$(dir): $(call quiet_install_data, $(dir)/$(LIBNAME) $(DESTDIR)$(libdir)/) $(call quiet_symlink, $(LIBNAME) $(DESTDIR)$(libdir)/$(SONAME)) $(call quiet_symlink, $(LIBNAME) $(DESTDIR)$(libdir)/$(LINKER_NAME)) + $(call quiet_mkdir, $(DESTDIR)$(prefix)/include/) $(call quiet_install_data, $(dir)/notmuch.h $(DESTDIR)$(prefix)/include/) SRCS := $(SRCS) $(libnotmuch_c_srcs) $(libnotmuch_cxx_srcs) -- 1.7.0.2 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Notmuch shared library
also sprach martin f krafft [2010.04.01.1324 +0200]: > Please avoid rpath. The better solution is probably to create > a wrapper for notmuch, which prepends to LD_LIBRARY_PATH. E.g. http://wiki.debian.org/RpathIssue -- martin | http://madduck.net/ | http://two.sentenc.es/ a common mistake that people make when trying to design something completely foolproof was to underestimate the ingenuity of complete fools. -- douglas adams, "mostly harmless" spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] format_part_json: part_content->data is not null terminated
On Thu, 04 Mar 2010 11:49:48 +0100, Gregor Hoffleit wrote: > In format_part_json, part_content->data is not a null terminated > string. I'd like to see this bug fixed, and the patch is pretty small, but... > Instead, we have to use part_content->len. > + content_data = talloc_size (ctx, part_content->len+1); > + memcpy (content_data, (char *)part_content->data, part_content->len+1); Can anyone explain why we copy (what seems to me to be) one extra byte here? In principle reading outside our allocated memory could cause problems; at minimum it makes a false positive for a memory checker like valgrind. David ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Notmuch shared library
also sprach Michal Sojka [2010.04.01.1310 +0200]: > this can be solved by the following patch, but I don't know how portable > it is. You can see the efect of this by Please avoid rpath. The better solution is probably to create a wrapper for notmuch, which prepends to LD_LIBRARY_PATH. -- martin | http://madduck.net/ | http://two.sentenc.es/ when everything is coming your way, you're in the wrong lane. spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Notmuch shared library
On Thu, 01 Apr 2010, Carl Worth wrote: > Finally, I'm a tiny bit annoyed that now after a fresh checkout of > notmuch and "make" that one can't easily run ./notmuch without either > installing the library (or fiddling with LD_LIBRARY_PATH). I've got some > ideas on how to simplify that, but I'm not sure if any are good or worth > it. Hi, this can be solved by the following patch, but I don't know how portable it is. You can see the efect of this by $ objdump -x notmuch|grep RPATH diff --git a/Makefile.local b/Makefile.local index 32b8f4a..2a1b55d 100644 --- a/Makefile.local +++ b/Makefile.local @@ -20,7 +20,7 @@ extra_cxxflags := # Smash together user's values with our extra values FINAL_CFLAGS = $(CFLAGS) $(WARN_CFLAGS) $(CONFIGURE_CFLAGS) $(extra_cflags) FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS) $(extra_cflags) $(extra_cxxflags) -FINAL_LDFLAGS = $(LDFLAGS) $(CONFIGURE_LDFLAGS) +FINAL_LDFLAGS = $(LDFLAGS) $(CONFIGURE_LDFLAGS) -Wl,-rpath,\$$ORIGIN/lib -z origin --enable-new-dtags all: notmuch notmuch.1.gz ifeq ($(MAKECMDGOALS),) --Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Notmuch shared library
On Thu, 01 Apr 2010 00:54:16 -0700, Carl Worth wrote: > Finally, I'm a tiny bit annoyed that now after a fresh checkout of > notmuch and "make" that one can't easily run ./notmuch without either > installing the library (or fiddling with LD_LIBRARY_PATH). I've got some > ideas on how to simplify that, but I'm not sure if any are good or worth > it. That was admittedly a very nice feature. And as I have proposed (but not send any patch :-)). I would argue that a --shared and a --static option (or whatever configure standard policy is for that) would make sense that links notmuch either dynamically or statically. But thanks for doing this work. Much appreciated Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] notmuch vs gmail filters
Hey *,
I'm currently using gmail for my mail and trying to port its behaviour
to notmuch. I had a go at writing a python script to convert my gmails
to notmuch tag commands along the lines of Carl's post [0]. It uses
the Gmail labs feature to export filters (to an XML file), and then
goes from XML stanzas like:
Mail Filter
tag:mail.google.com,2008:filter:1270085835242
2010-04-01T05:33:40Z
(which says to tag messages from upda...@linked.com with "flyers" and
skip the inbox) into a notmuch command like:
notmuch tag -inbox +flyers -- from:upda...@linkedin.com '(' not
tag:flyers or tag:inbox ')'
The bit in brackets makes sure it doesn't tag messages that already
have exactly the right tags -- this coule probably be implied in any
invocation of notmuch tag really...
Anyway, attached. It converts gmail's list: match to a notmuch to:
match, and just gives up on deliveredto: matches. But maybe someone
else finds it useful/interesting too :)
Cheers,
aj
[0] id:87r5o8stbj@yoom.home.cworth.org
--
Anthony Towns
#!/usr/bin/env python
# Copyright 2010 Anthony Towns
# GPLv2+
from xml.dom import minidom
import pipes
mf = minidom.parse(open("mailFilters.xml"))
def goog2notmuch(term, value):
if term == "list":
if value[0]+value[-1] in ['()', '""']:
value = value[1:-1]
return "to:" + value
return "tag:omg-i-got-confused"
for e in mf.childNodes[0].getElementsByTagName("entry"):
addtags = []
deltags = []
search = []
for a in e.getElementsByTagName("apps:property"):
n,v = a.getAttribute("name"), a.getAttribute("value")
if n == "label":
addtags.append(v)
elif n == "shouldArchive" and v == "true":
deltags.append("inbox")
elif n == "shouldTrash" and v == "true":
addtags.append("deleted")
elif n == "shouldMarkAsRead" and v == "true":
deltags.append("unread")
elif n == "from":
search.append("from:%s" % v)
elif n == "subject":
search.append("subject:%s" % v)
elif n == "doesNotHaveTheWord" and ':' in v:
search.append("not")
search.append(goog2notmuch(*v.split(':',1)))
elif n == "hasTheWord" and ':' in v:
search.append(goog2notmuch(*v.split(':',1)))
elif n == "hasTheWord":
search.append(v)
elif n == "doesNotHaveTheWord":
search.append("not")
search.append(v)
else:
print "XXX %s : %s" % (n,v)
tags = ["-"+x for x in deltags] + ["+"+x for x in addtags]
if tags == []:
print "WTF?? NO TAGS"
continue
tagsearch = sum([ ["not", "tag:"+x, "or"] for x in addtags ], [])
tagsearch += sum([ ["tag:"+x, "or"] for x in deltags ], [])
tagsearch = tagsearch[:-1]
if len(tags) > 1:
tagsearch = ["("] + tagsearch + [")"]
search += tagsearch
print "notmuch tag %s -- %s" % (
" ".join(pipes.quote(x) for x in tags),
" ".join(pipes.quote(x) for x in search))
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Notmuch shared library
On Fri, 12 Mar 2010 14:47:33 +0100, Ingmar Vanhassel wrote: > I'd very much like to see this upstream. Me too. ;-) Sorry for the long delay. > I amended your first patch to make it install the notmuch.h header > too. A very nice addition. > The second patch fixed some parallel make issue I had while testing > your series. As is this. I ran into this problem immediately when testing the first patch. > The third patch adds a configure switch to configure where to install > libraries. It has one issue I'm aware off. Setting --prefix=/usr > without setting --libdir does the wrong thing. This should probably be > fixed, but I don't have any immediate ideas how to do this. This configure option is nice too, but the problem you pointed out was serious, (so, thanks for noting it). I went ahead and fixed this. I also spent some time making sure I (think I) understand how library sonames and library versions work. I did several investigations with libtool that convinced me it adds problems without any tangible benefit, (at least for the target platforms I'm aware of people using with notmuch). I finished this by establishing a 3-part library interface version, (initially 1.0.0), along with careful documentation in the Makefile on how to increment it. And of course, I ended up touching up about a half-dozen issues in the Makefiles along the way. We'll still want to add functions/macros to the library to make the library version available to the user. And I do want to still add some symbol hiding and potentially some symbol versioning to the library. But I'm not making the patch series block on that. Finally, I'm a tiny bit annoyed that now after a fresh checkout of notmuch and "make" that one can't easily run ./notmuch without either installing the library (or fiddling with LD_LIBRARY_PATH). I've got some ideas on how to simplify that, but I'm not sure if any are good or worth it. Anyway, this patch series is now pushed with my changes on top. Thanks, Ben and Ingmar! -Carl pgpycothoiRjz.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Notmuch shared library
On Fri, 12 Mar 2010 14:47:33 +0100, Ingmar Vanhassel wrote: > I'd very much like to see this upstream. Me too. ;-) Sorry for the long delay. > I amended your first patch to make it install the notmuch.h header > too. A very nice addition. > The second patch fixed some parallel make issue I had while testing > your series. As is this. I ran into this problem immediately when testing the first patch. > The third patch adds a configure switch to configure where to install > libraries. It has one issue I'm aware off. Setting --prefix=/usr > without setting --libdir does the wrong thing. This should probably be > fixed, but I don't have any immediate ideas how to do this. This configure option is nice too, but the problem you pointed out was serious, (so, thanks for noting it). I went ahead and fixed this. I also spent some time making sure I (think I) understand how library sonames and library versions work. I did several investigations with libtool that convinced me it adds problems without any tangible benefit, (at least for the target platforms I'm aware of people using with notmuch). I finished this by establishing a 3-part library interface version, (initially 1.0.0), along with careful documentation in the Makefile on how to increment it. And of course, I ended up touching up about a half-dozen issues in the Makefiles along the way. We'll still want to add functions/macros to the library to make the library version available to the user. And I do want to still add some symbol hiding and potentially some symbol versioning to the library. But I'm not making the patch series block on that. Finally, I'm a tiny bit annoyed that now after a fresh checkout of notmuch and "make" that one can't easily run ./notmuch without either installing the library (or fiddling with LD_LIBRARY_PATH). I've got some ideas on how to simplify that, but I'm not sure if any are good or worth it. Anyway, this patch series is now pushed with my changes on top. Thanks, Ben and Ingmar! -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100401/3d8c50ba/attachment.pgp>
