[PATCH] traditional post-release doc text and release-check.sh updates

[David Bremner]

Tomi Ollila  writes:

> - added period to the end of the only 0.20.1 news item so that news2wiki
>   will not make it a header line

This part is trivial and fine.

>
> - changed copyright year to 2015 in doc/conf.py
>
> - made release-checks.sh to check copyright year in doc/conf.py

This part is less trivial, and should maybe be a patch by itself.

Is it just me or do we generally prefer $(foo bar fubz) to `foo bar
fubz`

>
> - made release-check.sh to execute python3 compatible version check code

It would be nice to say that the only change here is adding parens to
the print.

[PATCH] Fix documentation for notmuch--tag-hook functions

[David Bremner]

Daniel Schoepe  writes:

> The second argument to notmuch-tag is now called tag-changes, but the
> documentation for notmuch-before-tag-hook and notmuch-after-tag-hook
> still used the old argument name `tags'. This resulted in broken hooks
> when following the documentation.

pushed, thanks.

d

notmuch release 0.20.2 now available

[David Bremner]

Suvayu Ali  writes:

>
> Yes, I have looked at what the official packages[1] do, I do exactly the
> same[2].  Essentially the spec file does the following:
>
>   pushd bindings/ruby
>   ruby extconf.rb --vendor --with-cflags="%{optflags}"
>   make %{?_smp_mflags}
>   popd

I think the problem is contained in the original message. Since we want
to create a shared library "notmuch.so" for ruby to import, we need to
compile the C files in bindings/ruby with -fPIC.

I don't know if this is Debian specific, or ruby version specific, but
on my Debian Jessie machine with ruby 2.1, the generated Makefile
bindings/ruby/Makefile has

CFLAGS   = $(CCDLFLAGS) -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -fPIC $(ARCH_FLAG)

in it

even when invoked outside the notmuch build system; e.g.

% cd bindings/ruby && ruby extconf.rb

I guess the first step is to see if the -fPIC flag is also there on
Fedora, and if not, why not. If I look at the builds for 0.19 [1]
it seems it is. But notice there it is not required to pass it in to 
"--with-cflags"

d

[1] 
https://kojipkgs.fedoraproject.org/packages/notmuch/0.19/1.fc21/data/logs/x86_64/build.log
- I couldn't find x86_64 build logs for 0.20  

[PATCH] build: Support Mac OS X 10.6.8

[Nate Eagleson]

OS X 10.6.8 has a built-in library named libutil.dylib and a version
of ld that picks that up instead of util/libutil.a.

We now use an absolute path to util/libutil.a, so that notmuch can be
built successfully on 10.6.8.
---
 Makefile.local | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Makefile.local b/Makefile.local
index 61a9c4c..c82b43a 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -43,10 +43,16 @@ GPG_FILE=$(SHA1_FILE).asc

 PV_FILE=bindings/python/notmuch/version.py

+# Mac OS X 10.6 has a built-in libutil.dylib that prevents ld from
+# picking up notmuch's libutil.a. The best way to prefer our local
+# libutil.a is to specify it via absolute path, which should work on
+# all supported OSes.
+LIBUTIL_PATH=${srcdir}/util/libutil.a
+
 # Smash together user's values with our extra values
 FINAL_CFLAGS = -DNOTMUCH_VERSION=$(VERSION) $(CPPFLAGS) $(CFLAGS) 
$(WARN_CFLAGS) $(extra_cflags) $(CONFIGURE_CFLAGS)
 FINAL_CXXFLAGS = $(CPPFLAGS) $(CXXFLAGS) $(WARN_CXXFLAGS) $(extra_cflags) 
$(extra_cxxflags) $(CONFIGURE_CXXFLAGS)
-FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Lutil -lutil -Llib -lnotmuch
+FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) $(LIBUTIL_PATH) -Llib -lnotmuch -Wl,-t
 ifeq ($(LIBDIR_IN_LDCONFIG),0)
 FINAL_NOTMUCH_LDFLAGS += $(RPATH_LDFLAGS)
 endif
-- 
1.8.1.3

[PATCH] Fix compilation on Mac OS X 10.6.8

[Nate Eagleson]

Here's a fix for compilation failures on Mac OS X 10.6.8.

As a newbie to the codebase, and one with not much Makefile experience in 
general,
I'm more than happy to make any requested changes, or to take an entirely
different approach if necessary.

See previous discussion for more context:
http://notmuchmail.org/pipermail/notmuch/2015/020601.html

Nate Eagleson (1):
  build: Support Mac OS X 10.6.8

 Makefile.local | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

-- 
1.8.1.3

notmuch release 0.20.2 now available

[Suvayu Ali]

Hi David,

On Tue, Jun 30, 2015 at 09:34:36AM +0200, David Bremner wrote:
> Suvayu Ali  writes:
> > On Tue, Jun 30, 2015 at 07:24:28AM +0200, David Bremner wrote:
> >> 
> >> Where to obtain notmuch 0.20.2
> >> ===
> >>   http://notmuchmail.org/releases/notmuch-0.20.2.tar.gz
> >
> > I took a quick pass at building the release for Fedora.  The ruby
> > bindings seem to fail to build (actually linking fails).
> >
> 
> The ruby bindings are not built automatically by 0.20.2.  You seem to be
> building a snapshot of master. If you want to build the release from
> git, use the signed tag.

Yes, I was aware.  I tried again with proper 0.20.2.  And everything
succeeds.  So I guess something with master.  I usually build master in
that repo, I guess I'll stick to the release for now.

> The question of why master won't build for you is also interesting, but
> a different question. A quick search reveals packages of notmuch 0.19
> ruby bindings seemingly for fc22
> 
>  https://apps.fedoraproject.org/packages/ruby-notmuch/contents
> 
> So I guess have a look and see what existing fedora packaging does.

Yes, I have looked at what the official packages[1] do, I do exactly the
same[2].  Essentially the spec file does the following:

  pushd bindings/ruby
  ruby extconf.rb --vendor --with-cflags="%{optflags}"
  make %{?_smp_mflags}
  popd

where, _smp_mflags is -jN, and optflags is options for gcc.  If you need
the specific flags, I can try to look it up.

> At the moment the only way to disable the ruby bindings (other than
> hacking the build system) is not to have the ruby development files in
> the build env. This may change by the time this is part of a release.

Since everything is built in a chroot, I have control over the build
environment via the spec file.  If need be, I can disable it.  However
it would be interesting to know why master fails.

Thanks for your comments.

Cheers,

Footnotes:

[1] http://pkgs.fedoraproject.org/cgit/notmuch.git/tree/notmuch.spec#n137
[2] https://github.com/suvayu/notmuch-spec/blob/master/notmuch.spec#L139

-- 
Suvayu

Open source is the future. It sets us free.

notmuch release 0.20.2 now available

[David Bremner]

Suvayu Ali <fatkasuvayu+linux at gmail.com> writes:

> Hi David,
>
> On Tue, Jun 30, 2015 at 07:24:28AM +0200, David Bremner wrote:
>> 
>> Where to obtain notmuch 0.20.2
>> ===
>>   http://notmuchmail.org/releases/notmuch-0.20.2.tar.gz
>
> I took a quick pass at building the release for Fedora.  The ruby
> bindings seem to fail to build (actually linking fails).
>

The ruby bindings are not built automatically by 0.20.2.  You seem to be
building a snapshot of master. If you want to build the release from
git, use the signed tag.

The question of why master won't build for you is also interesting, but
a different question. A quick search reveals packages of notmuch 0.19
ruby bindings seemingly for fc22

 https://apps.fedoraproject.org/packages/ruby-notmuch/contents

So I guess have a look and see what existing fedora packaging does.

At the moment the only way to disable the ruby bindings (other than
hacking the build system) is not to have the ruby development files in
the build env. This may change by the time this is part of a release.

d
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 647 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20150630/ada18400/attachment.sig>

notmuch release 0.20.2 now available

[Suvayu Ali]

Hi David,

On Tue, Jun 30, 2015 at 07:24:28AM +0200, David Bremner wrote:
> 
> Where to obtain notmuch 0.20.2
> ===
>   http://notmuchmail.org/releases/notmuch-0.20.2.tar.gz

I took a quick pass at building the release for Fedora.  The ruby
bindings seem to fail to build (actually linking fails).

https://copr-be.cloud.fedoraproject.org/results/fatka/notmuch/fedora-22-x86_64/notmuch-0.20.2-1.20150627.git.8cca886b.fc22/build.log.gz

See to the end of the log, search for "make -C bindings/ruby", then you
can see the link failure a few lines down.

Any thoughts?

-- 
Suvayu

Open source is the future. It sets us free.

notmuch release 0.20.2 now available

[David Bremner]

Where to obtain notmuch 0.20.2
===
  http://notmuchmail.org/releases/notmuch-0.20.2.tar.gz

Which can be verified with:

  http://notmuchmail.org/releases/notmuch-0.20.2.tar.gz.sha1
  1aba10c86af29cc5b372b81f1780290bebff7f26  notmuch-0.20.2.tar.gz

  http://notmuchmail.org/releases/notmuch-0.20.2.tar.gz.sha1.asc
  (signed by David Bremner)

What's new in notmuch 0.20.2
=

Emacs Interface
---

Bug fix for marking messages read in `notmuch-tree` mode.

What is notmuch
===
Notmuch is a system for indexing, searching, reading, and tagging
large collections of email messages in maildir or mh format. It uses
the Xapian library to provide fast, full-text search with a convenient
search syntax.

For more about notmuch, see http://notmuchmail.org

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 647 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20150630/53adda3c/attachment.sig>

Re: notmuch release 0.20.2 now available

[Suvayu Ali]

Hi David,

On Tue, Jun 30, 2015 at 09:34:36AM +0200, David Bremner wrote:
 Suvayu Ali fatkasuvayu+li...@gmail.com writes:
  On Tue, Jun 30, 2015 at 07:24:28AM +0200, David Bremner wrote:
  
  Where to obtain notmuch 0.20.2
  ===
http://notmuchmail.org/releases/notmuch-0.20.2.tar.gz
 
  I took a quick pass at building the release for Fedora.  The ruby
  bindings seem to fail to build (actually linking fails).
 
 
 The ruby bindings are not built automatically by 0.20.2.  You seem to be
 building a snapshot of master. If you want to build the release from
 git, use the signed tag.

Yes, I was aware.  I tried again with proper 0.20.2.  And everything
succeeds.  So I guess something with master.  I usually build master in
that repo, I guess I'll stick to the release for now.

 The question of why master won't build for you is also interesting, but
 a different question. A quick search reveals packages of notmuch 0.19
 ruby bindings seemingly for fc22
 
  https://apps.fedoraproject.org/packages/ruby-notmuch/contents
 
 So I guess have a look and see what existing fedora packaging does.

Yes, I have looked at what the official packages[1] do, I do exactly the
same[2].  Essentially the spec file does the following:

  pushd bindings/ruby
  ruby extconf.rb --vendor --with-cflags=%{optflags}
  make %{?_smp_mflags}
  popd

where, _smp_mflags is -jN, and optflags is options for gcc.  If you need
the specific flags, I can try to look it up.

 At the moment the only way to disable the ruby bindings (other than
 hacking the build system) is not to have the ruby development files in
 the build env. This may change by the time this is part of a release.

Since everything is built in a chroot, I have control over the build
environment via the spec file.  If need be, I can disable it.  However
it would be interesting to know why master fails.

Thanks for your comments.

Cheers,

Footnotes:

[1] http://pkgs.fedoraproject.org/cgit/notmuch.git/tree/notmuch.spec#n137
[2] https://github.com/suvayu/notmuch-spec/blob/master/notmuch.spec#L139

-- 
Suvayu

Open source is the future. It sets us free.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch release 0.20.2 now available

[David Bremner]

Suvayu Ali fatkasuvayu+li...@gmail.com writes:

 Hi David,

 On Tue, Jun 30, 2015 at 07:24:28AM +0200, David Bremner wrote:
 
 Where to obtain notmuch 0.20.2
 ===
   http://notmuchmail.org/releases/notmuch-0.20.2.tar.gz

 I took a quick pass at building the release for Fedora.  The ruby
 bindings seem to fail to build (actually linking fails).


The ruby bindings are not built automatically by 0.20.2.  You seem to be
building a snapshot of master. If you want to build the release from
git, use the signed tag.

The question of why master won't build for you is also interesting, but
a different question. A quick search reveals packages of notmuch 0.19
ruby bindings seemingly for fc22

 https://apps.fedoraproject.org/packages/ruby-notmuch/contents

So I guess have a look and see what existing fedora packaging does.

At the moment the only way to disable the ruby bindings (other than
hacking the build system) is not to have the ruby development files in
the build env. This may change by the time this is part of a release.

d


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch release 0.20.2 now available

[David Bremner]

Suvayu Ali fatkasuvayu+li...@gmail.com writes:


 Yes, I have looked at what the official packages[1] do, I do exactly the
 same[2].  Essentially the spec file does the following:

   pushd bindings/ruby
   ruby extconf.rb --vendor --with-cflags=%{optflags}
   make %{?_smp_mflags}
   popd

I think the problem is contained in the original message. Since we want
to create a shared library notmuch.so for ruby to import, we need to
compile the C files in bindings/ruby with -fPIC.

I don't know if this is Debian specific, or ruby version specific, but
on my Debian Jessie machine with ruby 2.1, the generated Makefile
bindings/ruby/Makefile has

CFLAGS   = $(CCDLFLAGS) -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -fPIC $(ARCH_FLAG)

in it

even when invoked outside the notmuch build system; e.g.

% cd bindings/ruby  ruby extconf.rb

I guess the first step is to see if the -fPIC flag is also there on
Fedora, and if not, why not. If I look at the builds for 0.19 [1]
it seems it is. But notice there it is not required to pass it in to 
--with-cflags

d

[1] 
https://kojipkgs.fedoraproject.org/packages/notmuch/0.19/1.fc21/data/logs/x86_64/build.log
- I couldn't find x86_64 build logs for 0.20  
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] traditional post-release doc text and release-check.sh updates

[David Bremner]

Tomi Ollila tomi.oll...@iki.fi writes:

 - added period to the end of the only 0.20.1 news item so that news2wiki
   will not make it a header line

This part is trivial and fine.


 - changed copyright year to 2015 in doc/conf.py

 - made release-checks.sh to check copyright year in doc/conf.py

This part is less trivial, and should maybe be a patch by itself.

Is it just me or do we generally prefer $(foo bar fubz) to `foo bar
fubz`


 - made release-check.sh to execute python3 compatible version check code

It would be nice to say that the only change here is adding parens to
the print.


___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] Fix documentation for notmuch--tag-hook functions

[David Bremner]

Daniel Schoepe dan...@schoepe.org writes:

 The second argument to notmuch-tag is now called tag-changes, but the
 documentation for notmuch-before-tag-hook and notmuch-after-tag-hook
 still used the old argument name `tags'. This resulted in broken hooks
 when following the documentation.

pushed, thanks.

d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch release 0.20.2 now available

[Suvayu Ali]

Hi David,

On Tue, Jun 30, 2015 at 07:24:28AM +0200, David Bremner wrote:
 
 Where to obtain notmuch 0.20.2
 ===
   http://notmuchmail.org/releases/notmuch-0.20.2.tar.gz

I took a quick pass at building the release for Fedora.  The ruby
bindings seem to fail to build (actually linking fails).

https://copr-be.cloud.fedoraproject.org/results/fatka/notmuch/fedora-22-x86_64/notmuch-0.20.2-1.20150627.git.8cca886b.fc22/build.log.gz

See to the end of the log, search for make -C bindings/ruby, then you
can see the link failure a few lines down.

Any thoughts?

-- 
Suvayu

Open source is the future. It sets us free.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] build: Support Mac OS X 10.6.8

[Nate Eagleson]

OS X 10.6.8 has a built-in library named libutil.dylib and a version
of ld that picks that up instead of util/libutil.a.

We now use an absolute path to util/libutil.a, so that notmuch can be
built successfully on 10.6.8.
---
 Makefile.local | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Makefile.local b/Makefile.local
index 61a9c4c..c82b43a 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -43,10 +43,16 @@ GPG_FILE=$(SHA1_FILE).asc
 
 PV_FILE=bindings/python/notmuch/version.py
 
+# Mac OS X 10.6 has a built-in libutil.dylib that prevents ld from
+# picking up notmuch's libutil.a. The best way to prefer our local
+# libutil.a is to specify it via absolute path, which should work on
+# all supported OSes.
+LIBUTIL_PATH=${srcdir}/util/libutil.a
+
 # Smash together user's values with our extra values
 FINAL_CFLAGS = -DNOTMUCH_VERSION=$(VERSION) $(CPPFLAGS) $(CFLAGS) 
$(WARN_CFLAGS) $(extra_cflags) $(CONFIGURE_CFLAGS)
 FINAL_CXXFLAGS = $(CPPFLAGS) $(CXXFLAGS) $(WARN_CXXFLAGS) $(extra_cflags) 
$(extra_cxxflags) $(CONFIGURE_CXXFLAGS)
-FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Lutil -lutil -Llib -lnotmuch
+FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) $(LIBUTIL_PATH) -Llib -lnotmuch -Wl,-t
 ifeq ($(LIBDIR_IN_LDCONFIG),0)
 FINAL_NOTMUCH_LDFLAGS += $(RPATH_LDFLAGS)
 endif
-- 
1.8.1.3

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] Fix compilation on Mac OS X 10.6.8

[Nate Eagleson]

Here's a fix for compilation failures on Mac OS X 10.6.8.

As a newbie to the codebase, and one with not much Makefile experience in 
general,
I'm more than happy to make any requested changes, or to take an entirely
different approach if necessary.

See previous discussion for more context:
http://notmuchmail.org/pipermail/notmuch/2015/020601.html

Nate Eagleson (1):
  build: Support Mac OS X 10.6.8

 Makefile.local | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

-- 
1.8.1.3

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] emacs: show: let the user override the mime-type of an attachment

[Mark Walters]

This allows the user to override the mime-type of a part in the show
buffer. This takes the simple option of displaying the part with the
specified mime-type in its own buffer (in view mode). This avoids
further complicating the part handling code.

Bound to . m (i.e., m in the part map). Then the user can either
enter a mime-type or press return for the default choice of
text/plain.
---

Jani and dkg suggested something like this on irc. 

As mentioned in the commit message I have taken the simpler option of
displaying the part in its own buffer: the part handling with lazy
parts and hidden parts etc is really very complicated and fragile so I
do not think it sensible to complicate it further for a relatively
uncommon use case.

It would be nice to have some completions for the mime-type but that
could always be added later.

Best wishes

Mark


 emacs/notmuch-show.el | 35 +--
 1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 2a53461..c674e9c 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1354,6 +1354,7 @@ reset based on the original query.
 (define-key map v 'notmuch-show-view-part)
 (define-key map o 'notmuch-show-interactively-view-part)
 (define-key map | 'notmuch-show-pipe-part)
+(define-key map m 'notmuch-show-choose-mime-of-part)
 (define-key map ? 'notmuch-subkeymap-help)
 map)
   Submap for part commands)
@@ -2243,25 +2244,27 @@ omit --in-reply-to=Message-Id.
   (insert (notmuch-get-bodypart-binary msg part process-crypto)))
 buf))
 
-(defun notmuch-show-current-part-handle ()
+(defun notmuch-show-current-part-handle (optional mime-type)
   Return an mm-handle for the part containing point.
 
 This creates a temporary buffer for the part's content; the
-caller is responsible for killing this buffer as appropriate.
+caller is responsible for killing this buffer as appropriate.  If
+MIME-TYPE is given then set the handle's mime-type to MIME-TYPE.
   (let* ((msg (notmuch-show-get-message-properties))
 (part (notmuch-show-get-part-properties))
 (buf (notmuch-show-generate-part-buffer msg part))
-(computed-type (plist-get part :computed-type))
+(computed-type (or mime-type (plist-get part :computed-type)))
 (filename (plist-get part :filename))
 (disposition (if filename `(attachment (filename . ,filename)
 (mm-make-handle buf (list computed-type) nil nil disposition)))
 
-(defun notmuch-show-apply-to-current-part-handle (fn)
+(defun notmuch-show-apply-to-current-part-handle (fn optional mime-type)
   Apply FN to an mm-handle for the part containing point.
 
 This ensures that the temporary buffer created for the mm-handle
-is destroyed when FN returns.
-  (let ((handle (notmuch-show-current-part-handle)))
+is destroyed when FN returns. If MIME-TYPE is given then force
+part to be treated as if it had that mime-type.
+  (let ((handle (notmuch-show-current-part-handle mime-type)))
 ;; emacs 24.3+ puts stdout/stderr into the calling buffer so we
 ;; call it from a temp-buffer, unless
 ;; notmuch-show-attachment-debug is non-nil in which case we put
@@ -2306,4 +2309,24 @@ is destroyed when FN returns.
   (notmuch-show-apply-to-current-part-handle #'mm-pipe-part))
 
 
+(defun notmuch-show-internal-mm-display-part (handle)
+  Use mm-display-part to display HANDLE in a new buffer.
+
+If the part is displayed in an external application then close
+the new buffer.
+  (let ((buf (get-buffer-create (generate-new-buffer-name
+(concat  *notmuch-internal-part*)
+(switch-to-buffer buf)
+(if (eq (mm-display-part handle) 'external)
+   (kill-buffer buf)
+  (goto-char (point-min))
+  (set-buffer-modified-p nil)
+  (view-buffer buf 'kill-buffer-if-not-modified
+
+(defun notmuch-show-choose-mime-of-part (mime-type)
+  Choose the mime type to use for displaying part
+  (interactive
+   (list (read-string Mime type to use (default text/plain):  nil nil 
text/plain)))
+  (notmuch-show-apply-to-current-part-handle 
#'notmuch-show-internal-mm-display-part mime-type))
+
 (provide 'notmuch-show)
-- 
2.1.4

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch