[PATCH 14/25] Fix old style notmuch-fcc-dirs configuration check.
On Sat, 28 May 2011 14:51:49 -0700, Jameson Graef Rollins wrote:
Hi Jamie,
I've pushed the next few patches up to this point, (with only one
functional change---I fixed a new test case to correctly use
notmuch_search_sanitize to avoid spurious failures unmatching thread ID
values).
This patch, however, isn't ready. The big problem is in this commit
message:
> From: Dmitry Kurochkin
>
> In notmuch 0.5 notmuch-fcc-dirs style changed. The previous code
> did not correctly identify an old configuration and, as a
> consequence, broke new configurations.
There are several things there that are too vague, ("previous code",
"old configuration", "new configurations"). What kind of configuration
is broken? How does the change here help?
It would be easier to understand the code if there were a corresponding
test case for it. I'd even be willing to help write a test case, but
there are not enough specifics in that commit message to even tell me
what to test.
> ((and (listp notmuch-fcc-dirs)
> - (= 1 (length (car notmuch-fcc-dirs
> + (stringp (car notmuch-fcc-dirs)))
So the "old configuration" was a single string? And this has been
inadvertently broken since 0.5?
> ;; Old style - no longer works.
> (error "Invalid `notmuch-fcc-dirs' setting (old style)"))
Yikes. That vague phrasing ("old style") is already in the code in error
messages as well.
Dmitry, can you help me know what's going on here? (Preferably by
sending a newer commit with a more thorough commit message.)
Thanks,
-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110601/a964bb01/attachment.pgp>
[PATCH 07/25] test: remove json test for search null result, since it's being more properly tested in search-output
On Sat, 28 May 2011 14:51:42 -0700, Jameson Graef Rollins wrote: > The test in json was inferior to the one in search-output, since it > wasn't properly testing for the presence of a trailing newline. Hi Jamie, I've pushed the series up to this point now, (along with the vim improvements that weren't in your original mailing of the series). I really appreciate the missing-newline bug-fix along with all the improved testing for that. Thanks! I re-ordered that portion of the patch series a tiny bit to put the bug fix immediately after the commit that makes the tests start failing. I also reworded a few commit messages slightly. But I didn't make any code changes so it's trivial enough for me to keep using "git rebase" to keep your series on top of my modified master. I'll keep posting as I'm pushing. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110601/21a185c5/attachment.pgp>
[PATCH 01/25] fix check for libdir in ldconfig paths
On Wed, 01 Jun 2011 16:22:19 -0700, Carl Worth wrote: > Thanks for the patch. I was intrigued about what was actually broken > here, so tracked down the problem and fixed it with an alternate patch > (see below). Cool. Yeah, that issue took a while to track down. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110601/49d13ddc/attachment.pgp>
[PATCH 01/25] fix check for libdir in ldconfig paths
On Sat, 28 May 2011 14:51:36 -0700, Jameson Graef Rollins wrote: > The configure script tries to check that the libdir is included in the > ldconfig paths, and then sets the RPATH compiler flag if it's not. > This check was broken, and was always setting RPATH. This fixes the > path check. Thanks for the patch. I was intrigued about what was actually broken here, so tracked down the problem and fixed it with an alternate patch (see below). -Carl commit 574f408816e636f677b14384c18cc2e388991411 Author: Carl Worth Date: Wed Jun 1 13:02:58 2011 -0700 configure: Fix detection of libdir in ldconfig configuration Ever since commit b4b5e9ce4dac62111ec11da6d22b7e618056801f the detection of libdir in the ldconfig configuration has been broken, resulting in RPATH being set when not needed and not wanted. The cause was a change from an IFS setting of: IFS="$(printf '\n\t')" to a new setting of: IFS="$(printf '\n')" That looks desirable since we want to split the output of ldconfig based on newlines, (and not split on any filename that might have an embedded tab in it). The subtle bug in the above is that the shell trims any trailing newlines when performing command substitution so the final statement above was equivalent to: IFS='' which prevented any splitting of the ldconfig output at all. Fix this by avoiding command substitution and just using a literal newline in the source file for setting this variable. diff --git a/configure b/configure index bbf30cd..cf525c9 100755 --- a/configure +++ b/configure @@ -355,17 +355,30 @@ elif [ $uname = "Linux" ] ; then printf "Linux\n" platform=LINUX linker_resolves_library_dependencies=1 + +printf "Checking for $libdir_expanded in ldconfig... " ldconfig_paths=$(/sbin/ldconfig -N -X -v 2>/dev/null | sed -n -e 's,^\(/.*\):\( (.*)\)\?$,\1,p') # Separate ldconfig_paths only on newline (not on any potential -# embedded space characters in any filenames). +# embedded space characters in any filenames). Note, we use a +# literal newline in the source here rather than something like: +# +# IFS=$(printf '\n') +# +# because the shell's command substitution deletes any trailing newlines. OLD_IFS=$IFS -IFS="$(printf '\n')" +IFS=" +" for path in $ldconfig_paths; do if [ "$path" = "$libdir_expanded" ]; then libdir_in_ldconfig=1 fi done IFS=$OLD_IFS +if [ "$libdir_in_ldconfig" = '0' ]; then + printf "No (will set RPATH)\n" +else + printf "Yes\n" +fi else printf "Unknown.\n" cat <http://notmuchmail.org/pipermail/notmuch/attachments/20110601/49a31951/attachment.pgp>
Multiple sender identities (composing)
On 16 May 2011 19:29, Stewart Smith wrote: > Thought I'd share this bit of my .emacs snippet that may be useful to go > on the emacs tips page. > > This does the following: > - sets up a list of possible identities to have mail From > - on composing mail, it prompts you for who you want to send mail from > - pressing enter will give you the default (first in the list) > - otherwise you have tab completion > Is it possible to have it change the signature per identity also? -- Brian May -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110601/6047500c/attachment.html>
[python] get all messages of a thread
On 28 May 2011 23:18, Patrick Totzke wrote:
>if r: #because we cant iterate on NoneType
>
I don't understand why, but this line sets r._msgs to None. So it crashes,
because it has no message ids to look for.
If you change it to
if r is not None:
... then it works for me.
Oh, I see, for your code, there is a implied call to __len__, and the
__len__ function is completely broken for the reasons described in the
documentation:
.. note:: As this iterates over the messages, we will not be able to=
iterate over them again! So this will fail::
#THIS FAILS
msgs = Database().create_query('').search_message()
if len(msgs) > 0: #this 'exhausts' msgs
# next line raises
NotmuchError(STATUS.NOT_INITIALIZED)!!!
for msg in msgs: print msg
Most of the time, using the
:meth:`Query.count_messages` is therefore more
appropriate (and much faster). While not guaranteeing
that it will return the exact same number than len(),
in my tests it effectively always did so.
--
Brian May
-- next part --
An HTML attachment was scrubbed...
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110601/226b4f92/attachment.html>
compile error of current git on F15
On Wed, 01 Jun 2011 05:35:29 -0700, Dirk Hohndel wrote: > This used to work and used to be supported and was broken in a recent > notmuch patch. Hey, Dirk. I would actually say that support for gmime 2.6 was merely coincidental up until now. For all functionality we had been using, the API in 2.4 and 2.6 was the same (the patch that you point to only modifies the config file, not any of the code itself). But the recent crypto support uses the gmime 2.4 crypto API, which apparently has changed in versions of gmime >2.4. If you don't have access to gmime 2.4, then maybe you could look into providing patches for gmime 2.6 support, or alternately into disabling the notmuch functionality that does not work with gmime 2.6 if only 2.6 is available. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110601/61ca4254/attachment.pgp>
Multiple sender identities (composing)
On Wed, 1 Jun 2011 15:53:18 +1000, Brian May wrote: > On 16 May 2011 19:29, Stewart Smith wrote: > > > Thought I'd share this bit of my .emacs snippet that may be useful to go > > on the emacs tips page. > > > > This does the following: > > - sets up a list of possible identities to have mail From > > - on composing mail, it prompts you for who you want to send mail from > > - pressing enter will give you the default (first in the list) > > - otherwise you have tab completion > > > > Is it possible to have it change the signature per identity also? There's a function that changes the signature according to the From header in the message I sent on this list yesterday (id:"87pqmznczk.fsf at thor.loria.fr", near the end of the message). Regards, -- Thomas/Schnouki -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110601/7d70b203/attachment.pgp>
compile error of current git on F15
On Tue, 31 May 2011 12:29:28 -0400, Daniel Kahn Gillmor wrote: Non-text part: multipart/signed > i'm CC'ing the upstream lead developer of gmime here to see if he has > any thoughts (and can correct any misrepresentations from me) -- Hi Jeffrey! > > On 05/30/2011 02:43 PM, Jameson Graef Rollins wrote: > > On Sun, 29 May 2011 11:44:05 -0700, Dirk Hohndel > > wrote: > >> CC -O2 notmuch-reply.o > >> notmuch-reply.c: In function ?notmuch_reply_command?: > >> notmuch-reply.c:658:3: error: unknown type name ?GMimeSession? > >> notmuch-reply.c:659:3: warning: passing argument 1 of > >> ?g_mime_gpg_context_new? from incompatible pointer type [enabled by > >> default] > >> /usr/include/gmime-2.6/gmime/gmime-gpg-context.h:64:21: note: expected > >> ?GMimePasswordRequestFunc? but argument is of type ?int *? > >> make: *** [notmuch-reply.o] Error 1 > >> > >> This seems to have been introduced in Jameson's crypto patch series... > >> > >> ./configure shows: > >> > >> Checking for Xapian development files... Yes (1.2.4). > >> Checking for GMime development files... Yes (gmime-2.6). > >> Checking for Glib development files (>= 2.14)... Yes. > > > > Hey, Dirk. Looks like you're using gmime-2.6, which is something I've > > never looked at, and it looks like there are API changes. This of > > course doesn't help you, Dirk, but this probably means we should require > > libgmime-2.4, at least until we can figure out how to support both > > versions, which I'm not sure how to handle. > > > > Dirk, just out of curiosity, what system are you running that is > > provides gmime 2.6? > > F15 probably means Fedora 15. Correct > gmime 2.6 has not been released yet; gmime 2.5 is the development > version (which itself has an unstable API); the project uses the > even=stable/odd=unstable version numbering scheme. > > As the dev version, gmime 2.5 identifies itself as 2.6. I'm not sure i > can justify this decision. Jeffrey, can you explain? > > If F15 does not have gmime 2.4 available in it, it's possible that it > may not be able to build notmuch :/ That's where I am right now. But here's the odd thing: gmime-2.6 support was explicitly added to the configure script last year: http://notmuch.198994.n3.nabble.com/PATCH-configure-Add-support-for-GMime-2-6-td722706.html And it's only a recent change to notmuch that broke the build on F15 (it's one of the patches for the crypto support). So in my book this is a regression for notmuch! > I don't think that notmuch should attempt to target a library with an > unstable API. But if anyone is interested in preparing for the gmime > 2.6 release (maybe jeffrey can hint at the timeline for us) may want to > prepare changesets that #ifdef the relevant code depending on the API > version. > > Once gmime 2.6 is released, we'll need to decide if we want to remain > compatible with the old API as well, or just require gmime 2.6; but i > don't think we need to cross that bridge right now. Given what I wrote above you'll be unsurprised that I don't agree with this interpretation of the situation. This used to work and used to be supported and was broken in a recent notmuch patch. /D
Re: compile error of current git on F15
On Tue, 31 May 2011 12:29:28 -0400, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: Non-text part: multipart/signed i'm CC'ing the upstream lead developer of gmime here to see if he has any thoughts (and can correct any misrepresentations from me) -- Hi Jeffrey! On 05/30/2011 02:43 PM, Jameson Graef Rollins wrote: On Sun, 29 May 2011 11:44:05 -0700, Dirk Hohndel hohn...@infradead.org wrote: CC -O2 notmuch-reply.o notmuch-reply.c: In function ‘notmuch_reply_command’: notmuch-reply.c:658:3: error: unknown type name ‘GMimeSession’ notmuch-reply.c:659:3: warning: passing argument 1 of ‘g_mime_gpg_context_new’ from incompatible pointer type [enabled by default] /usr/include/gmime-2.6/gmime/gmime-gpg-context.h:64:21: note: expected ‘GMimePasswordRequestFunc’ but argument is of type ‘int *’ make: *** [notmuch-reply.o] Error 1 This seems to have been introduced in Jameson's crypto patch series... ./configure shows: Checking for Xapian development files... Yes (1.2.4). Checking for GMime development files... Yes (gmime-2.6). Checking for Glib development files (= 2.14)... Yes. Hey, Dirk. Looks like you're using gmime-2.6, which is something I've never looked at, and it looks like there are API changes. This of course doesn't help you, Dirk, but this probably means we should require libgmime-2.4, at least until we can figure out how to support both versions, which I'm not sure how to handle. Dirk, just out of curiosity, what system are you running that is provides gmime 2.6? F15 probably means Fedora 15. Correct gmime 2.6 has not been released yet; gmime 2.5 is the development version (which itself has an unstable API); the project uses the even=stable/odd=unstable version numbering scheme. As the dev version, gmime 2.5 identifies itself as 2.6. I'm not sure i can justify this decision. Jeffrey, can you explain? If F15 does not have gmime 2.4 available in it, it's possible that it may not be able to build notmuch :/ That's where I am right now. But here's the odd thing: gmime-2.6 support was explicitly added to the configure script last year: http://notmuch.198994.n3.nabble.com/PATCH-configure-Add-support-for-GMime-2-6-td722706.html And it's only a recent change to notmuch that broke the build on F15 (it's one of the patches for the crypto support). So in my book this is a regression for notmuch! I don't think that notmuch should attempt to target a library with an unstable API. But if anyone is interested in preparing for the gmime 2.6 release (maybe jeffrey can hint at the timeline for us) may want to prepare changesets that #ifdef the relevant code depending on the API version. Once gmime 2.6 is released, we'll need to decide if we want to remain compatible with the old API as well, or just require gmime 2.6; but i don't think we need to cross that bridge right now. Given what I wrote above you'll be unsurprised that I don't agree with this interpretation of the situation. This used to work and used to be supported and was broken in a recent notmuch patch. /D ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: compile error of current git on F15
On Wed, 01 Jun 2011 05:35:29 -0700, Dirk Hohndel hohn...@infradead.org wrote: This used to work and used to be supported and was broken in a recent notmuch patch. Hey, Dirk. I would actually say that support for gmime 2.6 was merely coincidental up until now. For all functionality we had been using, the API in 2.4 and 2.6 was the same (the patch that you point to only modifies the config file, not any of the code itself). But the recent crypto support uses the gmime 2.4 crypto API, which apparently has changed in versions of gmime 2.4. If you don't have access to gmime 2.4, then maybe you could look into providing patches for gmime 2.6 support, or alternately into disabling the notmuch functionality that does not work with gmime 2.6 if only 2.6 is available. jamie. pgpddGGcq9phQ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 01/25] fix check for libdir in ldconfig paths
On Sat, 28 May 2011 14:51:36 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: The configure script tries to check that the libdir is included in the ldconfig paths, and then sets the RPATH compiler flag if it's not. This check was broken, and was always setting RPATH. This fixes the path check. Thanks for the patch. I was intrigued about what was actually broken here, so tracked down the problem and fixed it with an alternate patch (see below). -Carl commit 574f408816e636f677b14384c18cc2e388991411 Author: Carl Worth cwo...@cworth.org Date: Wed Jun 1 13:02:58 2011 -0700 configure: Fix detection of libdir in ldconfig configuration Ever since commit b4b5e9ce4dac62111ec11da6d22b7e618056801f the detection of libdir in the ldconfig configuration has been broken, resulting in RPATH being set when not needed and not wanted. The cause was a change from an IFS setting of: IFS=$(printf '\n\t') to a new setting of: IFS=$(printf '\n') That looks desirable since we want to split the output of ldconfig based on newlines, (and not split on any filename that might have an embedded tab in it). The subtle bug in the above is that the shell trims any trailing newlines when performing command substitution so the final statement above was equivalent to: IFS='' which prevented any splitting of the ldconfig output at all. Fix this by avoiding command substitution and just using a literal newline in the source file for setting this variable. diff --git a/configure b/configure index bbf30cd..cf525c9 100755 --- a/configure +++ b/configure @@ -355,17 +355,30 @@ elif [ $uname = Linux ] ; then printf Linux\n platform=LINUX linker_resolves_library_dependencies=1 + +printf Checking for $libdir_expanded in ldconfig... ldconfig_paths=$(/sbin/ldconfig -N -X -v 2/dev/null | sed -n -e 's,^\(/.*\):\( (.*)\)\?$,\1,p') # Separate ldconfig_paths only on newline (not on any potential -# embedded space characters in any filenames). +# embedded space characters in any filenames). Note, we use a +# literal newline in the source here rather than something like: +# +# IFS=$(printf '\n') +# +# because the shell's command substitution deletes any trailing newlines. OLD_IFS=$IFS -IFS=$(printf '\n') +IFS= + for path in $ldconfig_paths; do if [ $path = $libdir_expanded ]; then libdir_in_ldconfig=1 fi done IFS=$OLD_IFS +if [ $libdir_in_ldconfig = '0' ]; then + printf No (will set RPATH)\n +else + printf Yes\n +fi else printf Unknown.\n cat EOF pgpRuTR6KWaIN.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 01/25] fix check for libdir in ldconfig paths
On Wed, 01 Jun 2011 16:22:19 -0700, Carl Worth cwo...@cworth.org wrote: Thanks for the patch. I was intrigued about what was actually broken here, so tracked down the problem and fixed it with an alternate patch (see below). Cool. Yeah, that issue took a while to track down. jamie. pgpWidel4eYpy.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 07/25] test: remove json test for search null result, since it's being more properly tested in search-output
On Sat, 28 May 2011 14:51:42 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: The test in json was inferior to the one in search-output, since it wasn't properly testing for the presence of a trailing newline. Hi Jamie, I've pushed the series up to this point now, (along with the vim improvements that weren't in your original mailing of the series). I really appreciate the missing-newline bug-fix along with all the improved testing for that. Thanks! I re-ordered that portion of the patch series a tiny bit to put the bug fix immediately after the commit that makes the tests start failing. I also reworded a few commit messages slightly. But I didn't make any code changes so it's trivial enough for me to keep using git rebase to keep your series on top of my modified master. I'll keep posting as I'm pushing. -Carl pgp1rTVe2unyr.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Multiple sender identities (composing)
On 1 June 2011 16:42, Thomas Jost schno...@schnouki.net wrote: There's a function that changes the signature according to the From header in the message I sent on this list yesterday (id:87pqmznczk@thor.loria.fr, near the end of the message). Thanks for the pointer, it seems to work fine. -- Brian May br...@microcomaustralia.com.au ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 14/25] Fix old style notmuch-fcc-dirs configuration check.
On Sat, 28 May 2011 14:51:49 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: Hi Jamie, I've pushed the next few patches up to this point, (with only one functional change---I fixed a new test case to correctly use notmuch_search_sanitize to avoid spurious failures unmatching thread ID values). This patch, however, isn't ready. The big problem is in this commit message: From: Dmitry Kurochkin dmitry.kuroch...@gmail.com In notmuch 0.5 notmuch-fcc-dirs style changed. The previous code did not correctly identify an old configuration and, as a consequence, broke new configurations. There are several things there that are too vague, (previous code, old configuration, new configurations). What kind of configuration is broken? How does the change here help? It would be easier to understand the code if there were a corresponding test case for it. I'd even be willing to help write a test case, but there are not enough specifics in that commit message to even tell me what to test. ((and (listp notmuch-fcc-dirs) - (= 1 (length (car notmuch-fcc-dirs + (stringp (car notmuch-fcc-dirs))) So the old configuration was a single string? And this has been inadvertently broken since 0.5? ;; Old style - no longer works. (error Invalid `notmuch-fcc-dirs' setting (old style))) Yikes. That vague phrasing (old style) is already in the code in error messages as well. Dmitry, can you help me know what's going on here? (Preferably by sending a newer commit with a more thorough commit message.) Thanks, -Carl pgpkl5FHLvgho.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
