[PATCH 2/2] remove Xapian exceptions symbols from libnotmuch1.symbols

[da...@tethera.net]

From: David Bremner 

These were never intended to be public, since the library exports only
a C API.
---
 debian/libnotmuch1.symbols |   14 --
 1 files changed, 0 insertions(+), 14 deletions(-)

diff --git a/debian/libnotmuch1.symbols b/debian/libnotmuch1.symbols
index f50d168..8df6fec 100644
--- a/debian/libnotmuch1.symbols
+++ b/debian/libnotmuch1.symbols
@@ -1,18 +1,4 @@
 libnotmuch.so.1 libnotmuch1 #MINVER#
- _Z32_notmuch_message_ensure_metadataP16_notmuch_message at Base 0.6~171
- _ZN6Xapian20InvalidArgumentErrorC1ERKS0_ at Base 0.6~171
- _ZN6Xapian20InvalidArgumentErrorC2ERKS0_ at Base 0.6~171
-#MISSING: 0.6~180# _ZN6Xapian20InvalidArgumentErrorD1Ev at Base 0.6~171
- _ZTIN6Xapian10LogicErrorE at Base 0.3
- _ZTIN6Xapian12RuntimeErrorE at Base 0.3
- _ZTIN6Xapian16DocNotFoundErrorE at Base 0.3
- _ZTIN6Xapian20InvalidArgumentErrorE at Base 0.3
- _ZTIN6Xapian5ErrorE at Base 0.3
- _ZTSN6Xapian10LogicErrorE at Base 0.3
- _ZTSN6Xapian12RuntimeErrorE at Base 0.3
- _ZTSN6Xapian16DocNotFoundErrorE at Base 0.3
- _ZTSN6Xapian20InvalidArgumentErrorE at Base 0.3
- _ZTSN6Xapian5ErrorE at Base 0.3
  notmuch_database_add_message at Base 0.3
  notmuch_database_close at Base 0.3
  notmuch_database_create at Base 0.3
-- 
1.7.5.3

[PATCH 1/2] libnotmuch: add linker script to declare only notmuch_* symbols as global.

[da...@tethera.net]

From: David Bremner 

This is closely tied to gcc and particularly gnu ld, but I guess the
shared library linking code would need to be adjusted to work on a
non-gnu linker anyay.

I had to make a few not-obviously related changes to the
lib/Makefile.local to make this work: libnotmuch_modules is defined
with := and used in place of $^
---
 lib/Makefile.local |   17 -
 1 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/lib/Makefile.local b/lib/Makefile.local
index 4319023..4676504 100644
--- a/lib/Makefile.local
+++ b/lib/Makefile.local
@@ -36,7 +36,7 @@ LIBRARY_SUFFIX = so
 LINKER_NAME = libnotmuch.$(LIBRARY_SUFFIX)
 SONAME = $(LINKER_NAME).$(LIBNOTMUCH_VERSION_MAJOR)
 LIBNAME = $(SONAME).$(LIBNOTMUCH_VERSION_MINOR).$(LIBNOTMUCH_VERSION_RELEASE)
-LIBRARY_LINK_FLAG = -shared -Wl,-soname=$(SONAME)
+LIBRARY_LINK_FLAG = -shared -Wl,--version-script=notmuch.sym,-soname=$(SONAME)
 ifeq ($(LIBDIR_IN_LDCONFIG),1)
 ifeq ($(DESTDIR),)
 LIBRARY_INSTALL_POST_COMMAND=ldconfig
@@ -66,13 +66,20 @@ libnotmuch_cxx_srcs =   \
$(dir)/query.cc \
$(dir)/thread.cc

-libnotmuch_modules = $(libnotmuch_c_srcs:.c=.o) $(libnotmuch_cxx_srcs:.cc=.o)
+libnotmuch_modules := $(libnotmuch_c_srcs:.c=.o) $(libnotmuch_cxx_srcs:.cc=.o)

 $(dir)/libnotmuch.a: $(libnotmuch_modules)
$(call quiet,AR) rcs $@ $^

-$(dir)/$(LIBNAME): $(libnotmuch_modules)
-   $(call quiet,CXX $(CXXFLAGS)) $^ $(FINAL_LIBNOTMUCH_LDFLAGS) 
$(LIBRARY_LINK_FLAG) -o $@
+$(dir)/$(LIBNAME): $(libnotmuch_modules) notmuch.sym
+   echo $(libnotmuch_modules)
+   $(call quiet,CXX $(CXXFLAGS)) $(libnotmuch_modules) 
$(FINAL_LIBNOTMUCH_LDFLAGS) $(LIBRARY_LINK_FLAG) -o $@
+
+notmuch.sym: lib/notmuch.h
+   gcc -aux-info notmuch.aux $<
+   printf "{\nglobal:\n" > notmuch.sym
+   sed  -n 's/.*\(notmuch_[a-z_]*\) (.*/\t\1;/p' notmuch.aux >> notmuch.sym
+   printf "local: *;\n};\n" >> notmuch.sym

 $(dir)/$(SONAME): $(dir)/$(LIBNAME)
ln -sf $(LIBNAME) $@
@@ -96,4 +103,4 @@ install-$(dir): $(dir)/$(LIBNAME)
$(LIBRARY_INSTALL_POST_COMMAND)

 SRCS  := $(SRCS) $(libnotmuch_c_srcs) $(libnotmuch_cxx_srcs)
-CLEAN := $(CLEAN) $(libnotmuch_modules) $(dir)/$(SONAME) $(dir)/$(LINKER_NAME) 
$(dir)$(LIBNAME) libnotmuch.a
+CLEAN := $(CLEAN) $(libnotmuch_modules) $(dir)/$(SONAME) $(dir)/$(LINKER_NAME) 
$(dir)$(LIBNAME) libnotmuch.a notmuch.aux notmuch.sym
-- 
1.7.5.3

No subject

[da...@tethera.net]

Here is my proposal, based on Clint's suggestion on IRC, and on the
sed hack from librhash, to hide all symbols that are not explicitly
part of the notmuch API. In particular it hides the various symbols
related to Xapian exceptions.

hiding xapian symbols

[Daniel Kahn Gillmor]

On 06/21/2011 09:08 PM, david at tethera.net wrote:
> Here is my proposal, based on Clint's suggestion on IRC, and on the
> sed hack from librhash, to hide all symbols that are not explicitly
> part of the notmuch API. In particular it hides the various symbols
> related to Xapian exceptions.

I like this proposal -- i would be really glad to not see the mangled
Xapian symbols in libnotmuch.so.

However, i'm concerned that the act of hiding these symbols will make it
so that any program that tries to link both libnotmuch and libxapian
will be unable to use these symbols.

Consider the visiblity rules [0]:

>> Symbol visibility is "default" by default but if the linker encounters 
>> just one definition with it hidden - just one - that typeinfo symbol 
>> becomes permanently hidden (remember the C++ standard's ODR - one 
>> definition rule). 


This makes me think that a program that links against libnotmuch and
libxapian, but actually tries to *use* libxapian's exception handling
may have a problem.

This is probably best resolved by writing such an executable and seeing
if it behaves, but alas, i haven't done that work.   Any takers?
Perhaps this could be a test in the notmuch test suite?

--dkg


[0]
http://gcc.gnu.org/wiki/Visibility#Problems_with_C.2B-.2B-_exceptions_.28please_read.21.29


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110621/1c5acead/attachment.pgp>

bug in emacs-ui ?

[Sebastien Binet]

hi,

On Mon, 20 Jun 2011 22:41:18 -0700, Jameson Graef Rollins  wrote:
Non-text part: multipart/signed
> On Tue, 21 Jun 2011 02:01:17 +0200, Sebastien Binet  
> wrote:
> > and I checked there were no lingering .el files...
> > 
> > so...
> >  any way to tell which notmuch-emacs-ui I am actually using ? (I am a newbie
> > when comes to hacking lisp)
> 
> Hey, Sebastien.  You can determine the loaded version of a library from
> within emacs with the follow command:
> 
> M-x locate-library notmuch
> 
> It's also good to know how many notmuch instances are installed on your
> system.  For instance, I have a system-wide installation, a "personal"
> installation, the build currently in the source tree, etc.  Depending on
> the options I supply to emacs at startup, I could run a variety of
> versions.

so, it seems the problem comes from:

(defun notmuch-show-advance-and-archive ()
  "Advance through thread and archive."
  (interactive)
  (let ((end-of-this-message (notmuch-show-message-bottom)))
(cond
 ;; Ideally we would test `end-of-this-message' against the result
 ;; of `window-end', but that doesn't account for the fact that
 ;; the end of the message might be hidden, so we have to actually
 ;; go to the end, walk back over invisible text and then see if
 ;; point is visible.
 ((save-excursion
(message "pt00: %s" (point))
(goto-char (- end-of-this-message 1))
(message "pt01: %s" (point))
(notmuch-show-move-past-invisible-backward)
(message "msg-end: %s" end-of-this-message)
(message "pt11: %s" (point))
;;(goto-char (- (point) 400))
(message "pt12: %s" (point))
(> (point) (window-end)))
  (message "point: %s" (point))
  (message "window-end: %s" (window-end))
  ;; The bottom of this message is not visible - scroll.
  (scroll-up nil))
 ((not (= end-of-this-message (point-max)))
  ;; This is not the last message - move to the next visible one.
  (notmuch-show-next-open-message))

where I've added some good ol' print "foo" debugging.

using the message from the openmpi mailing list I sent earlier and
pressing tab, I get in the *Messages* buffer:

For information about GNU Emacs and the GNU system, type C-h C-a.
pt00: 1
pt01: 1392
msg-end: #
pt11: 1392
pt12: 1392
point: 1
window-end: 1113
notmuch-show-advance-and-archive: End of buffer 

   
ie: it would seem the notmuch-show-move-past-invisible-backward does
*not* move the point up to just before the hidden signature (and does
not move it at all.)

if I uncomment the goto-char to -400 line, everything's fine. (400 is
roughly the length of the hidden signature)

well, this is just an educated guess from an emacs-lisp programmer
complete newbie.

fyi: I am using emacs-23.3
no patch were applied on top of the vanilla sources:
http://projects.archlinux.org/svntogit/packages.git/tree/emacs/repos/extra-x86_64/PKGBUILD

-s
-- 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/20110621/e5903cf2/attachment.pgp>

Turn Turnsole into a generic mail client

[William Morgan]

Reformatted excerpts from Vivien Didelot's message of 2011-06-21:
> I'm suggesting the make the Turnsole interface modulable to several
> mail sources.

Oh, I see. Yes, to the extent that you can mimic what's in
Turnsole::Client, it will be possible. But that class is a pretty thin
wrapper around the Heliotrope protocol, so mimicking it will feel a lot
like writing a Heliotrope compatibility layer.

I'm not personally interested in doing this, since Heliotrope is the One
True Mailstore as far as I'm concerned, but I'll try to be helpful if
you attempt it.
-- 
William 

bug in emacs-ui ?

[Carl Worth]

On Tue, 21 Jun 2011 21:26:25 +0200, Sebastien Binet  
wrote:
> fyi: I am using emacs-23.3

Perhaps this is an emacs bug?

I'm using Debian's emacs 23.3.1 and have not encountered the problem
described.

-Carl

-- 
carl.d.worth at intel.com
-- 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/20110621/e9c9e55d/attachment.pgp>

bug in emacs-ui ?

[Sebastien Binet]

On Mon, 20 Jun 2011 22:41:18 -0700, Jameson Graef Rollins  wrote:
Non-text part: multipart/signed
> On Tue, 21 Jun 2011 02:01:17 +0200, Sebastien Binet  
> wrote:
> > and I checked there were no lingering .el files...
> > 
> > so...
> >  any way to tell which notmuch-emacs-ui I am actually using ? (I am a newbie
> > when comes to hacking lisp)
> 
> Hey, Sebastien.  You can determine the loaded version of a library from
> within emacs with the follow command:
> 
> M-x locate-library notmuch
which points to the system-wide one.

> 
> It's also good to know how many notmuch instances are installed on your
> system.  For instance, I have a system-wide installation, a "personal"
> installation, the build currently in the source tree, etc.  Depending on
> the options I supply to emacs at startup, I could run a variety of
> versions.
being root and having this great ArchLinux package manager system at my
finger tips, I only have one installation of notmuch :)

playing a bit more, I cloned your 0.6 branch, cloned the official one,
slammed the 0.6/emacs directory on top of the official one, built the
official one, installed it and everything worked.

I am trying to see which changeset is the source of my problem...

-s
-- 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/20110621/481666a3/attachment.pgp>

[PATCH] Fix compilation warnings in test/smtp-dummy.c.

[Carl Worth]

On Thu, 16 Jun 2011 14:32:08 +0400, Dmitry Kurochkin  wrote:
> * Remove unused variables in main(): buf, bytes and greeting.
> * Replace return with no value in main() with exit(3).

Thanks. I'd notice these occasionally when running the test suite and
had meant for some time to fix them. But when doing my typical
compilation within emacs, (with just "make"), I wouldn't get these
warnings so I wasn't cleaning these in my typical work to make the
compilation error/warning-free.

I did follow up with a commit to prefer return (with a value) over
exit(), which I applied throughout the main() function:

commit b1aa676cca01ce0d907d220dc3c3a5142991c1cf
Author: Carl Worth 
Date:   Tue Jun 21 14:54:10 2011 -0700

smtp-dummy: Prefer return rather than exit() in main.

The main() function should be written as just another function with a
return value. This allows for more reliable code reuse. Imagine that
main() grows too large and needs to be factored into multiple
functions. At that point, exit() is probably the wrong thing, yet can
also be hard to notice as it's in less-frequently-tested exceptional
cases.


-Carl

-- 
carl.d.worth at intel.com
-- 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/20110621/c7fb749b/attachment.pgp>

[PATCH] notmuch-new.c infinite recursion symlink bug

[Carl Worth]

On Tue, 21 Jun 2011 12:01:17 -0400, Austin Clements  wrote:
> Alternatively, because of folder search, it might be better to keep a
> stack of inode numbers to eliminate loops while retaining notmuch's
> current approach of repeatedly indexing mail that's symlinked in
> multiple folders.

Yes, that sounds like the right approach.

-Carl

-- 
carl.d.worth at intel.com
-- 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/20110621/3092590d/attachment.pgp>

Python updates

[Carl Worth]

On Thu, 16 Jun 2011 15:58:39 +0200, Sebastian Spaeth  
wrote:
> P.S. Once I get started I was teased on IRC, so I also implemented:
> 
> Message().maildir_flags_to_tags and tags_to_maildir_flags, which are now
> by default invoked on Database().add_message and on any operation that
> modifies notmuch tags. See the updated API docs at:

I'm not a fan of the above.

I would greatly prefer that any language bindings for notmuch implement
the same semantics as the underlying functions.

If we should fix Database().add_message to automatically call
maildir_flags_to_tags, then we should also fix
notmuch_database_add_message to do the same thing.

I can't see any good justification for behavior like this to be
different depending on the language being used to access the library.

Please consider changing things to match the semantics of the underlying
library.

Thanks,

-Carl

-- 
carl.d.worth at intel.com
-- 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/20110621/cd4ba03f/attachment.pgp>

Turn Turnsole into a generic mail client

[Vivien Didelot]

Hi William,

I'm not suggesting to make Heliotrope supports several clients (what it
already does via  provinding JSON),
I'm suggesting the make the Turnsole interface modulable to several mail
sources.
And its default and official one will be the Heliotrope client for sure.

I hope it is clearer.

On Sun, Jun 19, 2011 at 6:01 PM, William Morgan wrote:

> Hi Vivien,
>
> Reformatted excerpts from Vivien Didelot's message of 2011-06-19:
> > As Turnsole is a great mail interface, I was thinking about having it
> > generic to multiple servers or mail sources, to fit many use cases.
> >
> > Explicitely, the Turnsole::Client class (
> > https://github.com/wmorgan/turnsole/blob/master/lib/turnsole/client.rb)
> > could be turned into a Turnsole::Client module instead,
>
> The server portion of turnsole, heliotrope, is explicitly designed to
> support multiple clients and provides a JSON-over-HTTP interface for
> that purpose.
>
> The specifics of the protocol are still subject to change, but see e.g.
> https://github.com/wmorgan/heliotrope/blob/master/lib/heliotrope-client.rb
> for the ruby client that turnsole uses to communicate with the server.
> --
> William 
>



-- 
Vivien Didelot,
vivien.didelot.org
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110621/097f71d3/attachment.html>

[PATCH] notmuch-new.c infinite recursion symlink bug

[Austin Clements]

On Tue, Jun 21, 2011 at 8:42 AM, Daniel Kahn Gillmor
 wrote:
> My point is: there are lots of ways to get infinite recursions via
> symlinks; ?hard-coding a check for one specific way seems like a
> sub-optimal approach, because it leaves the other paths still present,
> and introduces an unexpected/surprising asymmetry.
>
> I'm not sure what the specific right way is to solve the problem you
> identified, though.

A simple solution to this problem would be to record the inode numbers
of each visited directory, probably in a hash table in
add_files_state_t.  At the beginning of add_files_recursive, right
after it stat's the directory, check if st.st_ino is in this hash
table; if it is, return immediately, otherwise add it to the hash
table and proceed as usual.

Alternatively, because of folder search, it might be better to keep a
stack of inode numbers to eliminate loops while retaining notmuch's
current approach of repeatedly indexing mail that's symlinked in
multiple folders.

[PATCH 2/2] debian: break up Build-Depends on separate lines

[Jameson Graef Rollins]

---
 debian/control |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 90bd0ee..3289282 100644
--- a/debian/control
+++ b/debian/control
@@ -6,9 +6,15 @@ Uploaders:
  martin f. krafft ,
  Jameson Graef Rollins ,
  David Bremner ,
-Build-Depends: debhelper (>= 7.0.50~), pkg-config, libxapian-dev, 
- libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
- python-all (>= 2.6.6-3~)
+Build-Depends:
+ debhelper (>= 7.0.50~),
+ pkg-config,
+ libxapian-dev,
+ libgmime-2.4-dev,
+ libtalloc-dev,
+ libz-dev,
+ emacs23-nox,
+ python-all (>= 2.6.6-3~),
 Standards-Version: 3.9.1.0
 Homepage: http://notmuchmail.org/
 Vcs-Git: git://notmuchmail.org/git/notmuch
-- 
1.7.5.3

[PATCH 1/2] debian: break up uploaders on separate lines

[Jameson Graef Rollins]

---
 debian/control |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 4b60af0..90bd0ee 100644
--- a/debian/control
+++ b/debian/control
@@ -2,9 +2,10 @@ Source: notmuch
 Section: mail
 Priority: extra
 Maintainer: Carl Worth 
-Uploaders: martin f. krafft , 
-  Jameson Graef Rollins ,
-  David Bremner 
+Uploaders:
+ martin f. krafft ,
+ Jameson Graef Rollins ,
+ David Bremner ,
 Build-Depends: debhelper (>= 7.0.50~), pkg-config, libxapian-dev, 
  libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
  python-all (>= 2.6.6-3~)
-- 
1.7.5.3

No subject

[Jameson Graef Rollins]

hrm, sorry.  Looks like those last two patches got a little messed up.
These two patches replace the previous two.

jamie.

[PATCH 4/4] debian: bump standards version to 3.9.2

[Jameson Graef Rollins]

---
 debian/control |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/debian/control b/debian/control
index 49f6961..52c2e5a 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends:
  libz-dev,
  emacs23 | emacs23-nox,
  python-all (>= 2.6.6-3~),
-Standards-Version: 3.9.1.0
+Standards-Version: 3.9.2
 Homepage: http://notmuchmail.org/
 Vcs-Git: git://notmuchmail.org/git/notmuch
 Vcs-Browser: http://git.notmuchmail.org/git/notmuch
-- 
1.7.5.3

[PATCH 3/4] debian: build depend on emacs23 or emacs23-nox

[Jameson Graef Rollins]

---
 debian/control |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/debian/control b/debian/control
index 0c998df..49f6961 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Build-Depends:
  libgmime-2.4-dev,
  libtalloc-dev,
  libz-dev,
- emacs23-nox,
+ emacs23 | emacs23-nox,
  python-all (>= 2.6.6-3~),
 Standards-Version: 3.9.1.0
 Homepage: http://notmuchmail.org/
-- 
1.7.5.3

[PATCH 2/4] debian: break up Build-Depends on separate lines

[Jameson Graef Rollins]

---
 debian/control |   14 ++
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/debian/control b/debian/control
index 51353de..0c998df 100644
--- a/debian/control
+++ b/debian/control
@@ -3,12 +3,18 @@ Section: mail
 Priority: extra
 Maintainer: Carl Worth 
 Uploaders:
- martin f. krafft , 
+ martin f. krafft ,
  Jameson Graef Rollins ,
  David Bremner ,
-Build-Depends: debhelper (>= 7.0.50~), pkg-config, libxapian-dev, 
- libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
- python-all (>= 2.6.6-3~)
+Build-Depends:
+ debhelper (>= 7.0.50~),
+ pkg-config,
+ libxapian-dev, 
+ libgmime-2.4-dev,
+ libtalloc-dev,
+ libz-dev,
+ emacs23-nox,
+ python-all (>= 2.6.6-3~),
 Standards-Version: 3.9.1.0
 Homepage: http://notmuchmail.org/
 Vcs-Git: git://notmuchmail.org/git/notmuch
-- 
1.7.5.3

[PATCH 1/4] debian: break up uploaders on separate lines

[Jameson Graef Rollins]

---
 debian/control |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 4b60af0..51353de 100644
--- a/debian/control
+++ b/debian/control
@@ -2,9 +2,10 @@ Source: notmuch
 Section: mail
 Priority: extra
 Maintainer: Carl Worth 
-Uploaders: martin f. krafft , 
-  Jameson Graef Rollins ,
-  David Bremner 
+Uploaders:
+ martin f. krafft , 
+ Jameson Graef Rollins ,
+ David Bremner ,
 Build-Depends: debhelper (>= 7.0.50~), pkg-config, libxapian-dev, 
  libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
  python-all (>= 2.6.6-3~)
-- 
1.7.5.3

Debian packaging changes

[David Bremner]

As of the latest snapshot for debian experimental, I create seperate
binary packages for python bindings and for the emacs-interface. Since
the plan is to merge these changes back to master fairly soon, I'd
appreciate any feedback on these or any other patches in the series.

git://pivot.cs.unb.ca/notmuch.git 
branch: experimental





-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 315 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110621/85c042d6/attachment.pgp>

[PATCH] notmuch-new.c infinite recursion symlink bug

[Daniel Kahn Gillmor]

On 06/10/2011 03:32 AM, Taylor Carpenter wrote:
> If a symlink points to . then there will be an infinite recursion.  The 
> included patch fixes that.

what about a sub-directory that contains a symlink to ".." ?

or a directory that contains both:

 ./a/foo ? ../b
 ./b/foo ? ../a

or ...

My point is: there are lots of ways to get infinite recursions via
symlinks;  hard-coding a check for one specific way seems like a
sub-optimal approach, because it leaves the other paths still present,
and introduces an unexpected/surprising asymmetry.

I'm not sure what the specific right way is to solve the problem you
identified, though.

--dkg

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110621/bf085dc0/attachment.pgp>

bug in emacs-ui ?

[Sebastien Binet]

hi,

On Mon, Jun 20, 2011 at 9:53 PM, Jameson Graef Rollins <
jrollins at finestructure.net> wrote:

> On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet 
> wrote:
> > > You didn't try forwarding the email to the list ;)
> > ah! that easy, heh ?
> >
> Attachment:
> 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S
> (application/octet-stream)
>
> Hi, Sebastien.  I don't seem to have any problems viewing this message
> with notmuch emacs.  Is it possible that the notmuch emacs code you're
> running is out-of-sync with your notmuch binary?  I think that's a
> common source of problems like this.  Make sure that you're pointed to
> the version of the notmuch emacs libraries that corresponds to your
> notmuch binary, and that you've restarted your emacs session.  Hopefully
> that will fix things.
>

no joy:
$ `which notmuch` --version
notmuch 0.5-238-gc39b492

$ pacman -Ql notmuch-git
notmuch-git /etc/
notmuch-git /etc/bash_completion.d/
notmuch-git /etc/bash_completion.d/notmuch
notmuch-git /usr/
notmuch-git /usr/bin/
notmuch-git /usr/bin/notmuch
notmuch-git /usr/include/
notmuch-git /usr/include/notmuch.h
notmuch-git /usr/lib/
notmuch-git /usr/lib/libnotmuch.so
notmuch-git /usr/lib/libnotmuch.so.1
notmuch-git /usr/lib/libnotmuch.so.1.3.0
notmuch-git /usr/lib/python2.7/
 [other python files elided]
notmuch-git /usr/share/
notmuch-git /usr/share/emacs/
notmuch-git /usr/share/emacs/site-lisp/
notmuch-git /usr/share/emacs/site-lisp/coolj.el
notmuch-git /usr/share/emacs/site-lisp/coolj.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-address.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-address.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-crypto.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-crypto.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-hello.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-hello.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-lib.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-lib.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-logo.png
notmuch-git /usr/share/emacs/site-lisp/notmuch-maildir-fcc.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-maildir-fcc.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-message.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-message.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-mua.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-mua.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-query.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-query.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-show.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-show.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch-wash.el
notmuch-git /usr/share/emacs/site-lisp/notmuch-wash.elc
notmuch-git /usr/share/emacs/site-lisp/notmuch.el
notmuch-git /usr/share/emacs/site-lisp/notmuch.elc
notmuch-git /usr/share/man/
notmuch-git /usr/share/man/man1/
notmuch-git /usr/share/man/man1/notmuch.1.gz
notmuch-git /usr/share/vim/
notmuch-git /usr/share/vim/vimfiles/
notmuch-git /usr/share/vim/vimfiles/plugin/
notmuch-git /usr/share/vim/vimfiles/plugin/notmuch.vim
notmuch-git /usr/share/vim/vimfiles/syntax/
notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-compose.vim
notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-folders.vim
notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-git-diff.vim
notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-search.vim
notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-show.vim
notmuch-git /usr/share/zsh/
notmuch-git /usr/share/zsh/functions/
notmuch-git /usr/share/zsh/functions/Completion/
notmuch-git /usr/share/zsh/functions/Completion/Unix/
notmuch-git /usr/share/zsh/functions/Completion/Unix/_notmuch

and I checked there were no lingering .el files...

so...
 any way to tell which notmuch-emacs-ui I am actually using ? (I am a newbie
when comes to hacking lisp)

-s
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20110621/21078348/attachment.html>

Re: bug in emacs-ui ?

[Sebastien Binet]

On Mon, 20 Jun 2011 22:41:18 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
Non-text part: multipart/signed
 On Tue, 21 Jun 2011 02:01:17 +0200, Sebastien Binet seb.bi...@gmail.com 
 wrote:
  and I checked there were no lingering .el files...
  
  so...
   any way to tell which notmuch-emacs-ui I am actually using ? (I am a newbie
  when comes to hacking lisp)
 
 Hey, Sebastien.  You can determine the loaded version of a library from
 within emacs with the follow command:
 
 M-x locate-library notmuch
which points to the system-wide one.

 
 It's also good to know how many notmuch instances are installed on your
 system.  For instance, I have a system-wide installation, a personal
 installation, the build currently in the source tree, etc.  Depending on
 the options I supply to emacs at startup, I could run a variety of
 versions.
being root and having this great ArchLinux package manager system at my
finger tips, I only have one installation of notmuch :)

playing a bit more, I cloned your 0.6 branch, cloned the official one,
slammed the 0.6/emacs directory on top of the official one, built the
official one, installed it and everything worked.

I am trying to see which changeset is the source of my problem...

-s


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

Debian packaging changes

[David Bremner]

As of the latest snapshot for debian experimental, I create seperate
binary packages for python bindings and for the emacs-interface. Since
the plan is to merge these changes back to master fairly soon, I'd
appreciate any feedback on these or any other patches in the series.

git://pivot.cs.unb.ca/notmuch.git 
branch: experimental







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

Re: [PATCH] notmuch-new.c infinite recursion symlink bug

[Austin Clements]

On Tue, Jun 21, 2011 at 8:42 AM, Daniel Kahn Gillmor
d...@fifthhorseman.net wrote:
 My point is: there are lots of ways to get infinite recursions via
 symlinks;  hard-coding a check for one specific way seems like a
 sub-optimal approach, because it leaves the other paths still present,
 and introduces an unexpected/surprising asymmetry.

 I'm not sure what the specific right way is to solve the problem you
 identified, though.

A simple solution to this problem would be to record the inode numbers
of each visited directory, probably in a hash table in
add_files_state_t.  At the beginning of add_files_recursive, right
after it stat's the directory, check if st.st_ino is in this hash
table; if it is, return immediately, otherwise add it to the hash
table and proceed as usual.

Alternatively, because of folder search, it might be better to keep a
stack of inode numbers to eliminate loops while retaining notmuch's
current approach of repeatedly indexing mail that's symlinked in
multiple folders.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Turn Turnsole into a generic mail client

[Vivien Didelot]

Hi William,

I'm not suggesting to make Heliotrope supports several clients (what it
already does via  provinding JSON),
I'm suggesting the make the Turnsole interface modulable to several mail
sources.
And its default and official one will be the Heliotrope client for sure.

I hope it is clearer.

On Sun, Jun 19, 2011 at 6:01 PM, William Morgan wmorgan-...@masanjin.netwrote:

 Hi Vivien,

 Reformatted excerpts from Vivien Didelot's message of 2011-06-19:
  As Turnsole is a great mail interface, I was thinking about having it
  generic to multiple servers or mail sources, to fit many use cases.
 
  Explicitely, the Turnsole::Client class (
  https://github.com/wmorgan/turnsole/blob/master/lib/turnsole/client.rb)
  could be turned into a Turnsole::Client module instead,

 The server portion of turnsole, heliotrope, is explicitly designed to
 support multiple clients and provides a JSON-over-HTTP interface for
 that purpose.

 The specifics of the protocol are still subject to change, but see e.g.
 https://github.com/wmorgan/heliotrope/blob/master/lib/heliotrope-client.rb
 for the ruby client that turnsole uses to communicate with the server.
 --
 William wmorgan-...@masanjin.net




-- 
Vivien Didelot,
vivien.didelot.org
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 4/4] debian: bump standards version to 3.9.2

[Jameson Graef Rollins]

---
 debian/control |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/debian/control b/debian/control
index 49f6961..52c2e5a 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Build-Depends:
  libz-dev,
  emacs23 | emacs23-nox,
  python-all (= 2.6.6-3~),
-Standards-Version: 3.9.1.0
+Standards-Version: 3.9.2
 Homepage: http://notmuchmail.org/
 Vcs-Git: git://notmuchmail.org/git/notmuch
 Vcs-Browser: http://git.notmuchmail.org/git/notmuch
-- 
1.7.5.3

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

[PATCH 2/4] debian: break up Build-Depends on separate lines

[Jameson Graef Rollins]

---
 debian/control |   14 ++
 1 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/debian/control b/debian/control
index 51353de..0c998df 100644
--- a/debian/control
+++ b/debian/control
@@ -3,12 +3,18 @@ Section: mail
 Priority: extra
 Maintainer: Carl Worth cwo...@debian.org
 Uploaders:
- martin f. krafft madd...@debian.org, 
+ martin f. krafft madd...@debian.org,
  Jameson Graef Rollins jroll...@finestructure.net,
  David Bremner brem...@debian.org,
-Build-Depends: debhelper (= 7.0.50~), pkg-config, libxapian-dev, 
- libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
- python-all (= 2.6.6-3~)
+Build-Depends:
+ debhelper (= 7.0.50~),
+ pkg-config,
+ libxapian-dev, 
+ libgmime-2.4-dev,
+ libtalloc-dev,
+ libz-dev,
+ emacs23-nox,
+ python-all (= 2.6.6-3~),
 Standards-Version: 3.9.1.0
 Homepage: http://notmuchmail.org/
 Vcs-Git: git://notmuchmail.org/git/notmuch
-- 
1.7.5.3

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

[PATCH 1/4] debian: break up uploaders on separate lines

[Jameson Graef Rollins]

---
 debian/control |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 4b60af0..51353de 100644
--- a/debian/control
+++ b/debian/control
@@ -2,9 +2,10 @@ Source: notmuch
 Section: mail
 Priority: extra
 Maintainer: Carl Worth cwo...@debian.org
-Uploaders: martin f. krafft madd...@debian.org, 
-  Jameson Graef Rollins jroll...@finestructure.net,
-  David Bremner brem...@debian.org
+Uploaders:
+ martin f. krafft madd...@debian.org, 
+ Jameson Graef Rollins jroll...@finestructure.net,
+ David Bremner brem...@debian.org,
 Build-Depends: debhelper (= 7.0.50~), pkg-config, libxapian-dev, 
  libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
  python-all (= 2.6.6-3~)
-- 
1.7.5.3

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

[PATCH 3/4] debian: build depend on emacs23 or emacs23-nox

[Jameson Graef Rollins]

---
 debian/control |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/debian/control b/debian/control
index 0c998df..49f6961 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Build-Depends:
  libgmime-2.4-dev,
  libtalloc-dev,
  libz-dev,
- emacs23-nox,
+ emacs23 | emacs23-nox,
  python-all (= 2.6.6-3~),
 Standards-Version: 3.9.1.0
 Homepage: http://notmuchmail.org/
-- 
1.7.5.3

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

[no subject]

[Jameson Graef Rollins]

hrm, sorry.  Looks like those last two patches got a little messed up.
These two patches replace the previous two.

jamie.

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

[PATCH 1/2] debian: break up uploaders on separate lines

[Jameson Graef Rollins]

---
 debian/control |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 4b60af0..90bd0ee 100644
--- a/debian/control
+++ b/debian/control
@@ -2,9 +2,10 @@ Source: notmuch
 Section: mail
 Priority: extra
 Maintainer: Carl Worth cwo...@debian.org
-Uploaders: martin f. krafft madd...@debian.org, 
-  Jameson Graef Rollins jroll...@finestructure.net,
-  David Bremner brem...@debian.org
+Uploaders:
+ martin f. krafft madd...@debian.org,
+ Jameson Graef Rollins jroll...@finestructure.net,
+ David Bremner brem...@debian.org,
 Build-Depends: debhelper (= 7.0.50~), pkg-config, libxapian-dev, 
  libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
  python-all (= 2.6.6-3~)
-- 
1.7.5.3

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

[PATCH 2/2] debian: break up Build-Depends on separate lines

[Jameson Graef Rollins]

---
 debian/control |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 90bd0ee..3289282 100644
--- a/debian/control
+++ b/debian/control
@@ -6,9 +6,15 @@ Uploaders:
  martin f. krafft madd...@debian.org,
  Jameson Graef Rollins jroll...@finestructure.net,
  David Bremner brem...@debian.org,
-Build-Depends: debhelper (= 7.0.50~), pkg-config, libxapian-dev, 
- libgmime-2.4-dev, libtalloc-dev, libz-dev, emacs23-nox,
- python-all (= 2.6.6-3~)
+Build-Depends:
+ debhelper (= 7.0.50~),
+ pkg-config,
+ libxapian-dev,
+ libgmime-2.4-dev,
+ libtalloc-dev,
+ libz-dev,
+ emacs23-nox,
+ python-all (= 2.6.6-3~),
 Standards-Version: 3.9.1.0
 Homepage: http://notmuchmail.org/
 Vcs-Git: git://notmuchmail.org/git/notmuch
-- 
1.7.5.3

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

Re: bug in emacs-ui ?

[Sebastien Binet]

hi,

On Mon, 20 Jun 2011 22:41:18 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
Non-text part: multipart/signed
 On Tue, 21 Jun 2011 02:01:17 +0200, Sebastien Binet seb.bi...@gmail.com 
 wrote:
  and I checked there were no lingering .el files...
  
  so...
   any way to tell which notmuch-emacs-ui I am actually using ? (I am a newbie
  when comes to hacking lisp)
 
 Hey, Sebastien.  You can determine the loaded version of a library from
 within emacs with the follow command:
 
 M-x locate-library notmuch
 
 It's also good to know how many notmuch instances are installed on your
 system.  For instance, I have a system-wide installation, a personal
 installation, the build currently in the source tree, etc.  Depending on
 the options I supply to emacs at startup, I could run a variety of
 versions.

so, it seems the problem comes from:

(defun notmuch-show-advance-and-archive ()
  Advance through thread and archive.
  (interactive)
  (let ((end-of-this-message (notmuch-show-message-bottom)))
(cond
 ;; Ideally we would test `end-of-this-message' against the result
 ;; of `window-end', but that doesn't account for the fact that
 ;; the end of the message might be hidden, so we have to actually
 ;; go to the end, walk back over invisible text and then see if
 ;; point is visible.
 ((save-excursion
(message pt00: %s (point))
(goto-char (- end-of-this-message 1))
(message pt01: %s (point))
(notmuch-show-move-past-invisible-backward)
(message msg-end: %s end-of-this-message)
(message pt11: %s (point))
;;(goto-char (- (point) 400))
(message pt12: %s (point))
( (point) (window-end)))
  (message point: %s (point))
  (message window-end: %s (window-end))
  ;; The bottom of this message is not visible - scroll.
  (scroll-up nil))
 ((not (= end-of-this-message (point-max)))
  ;; This is not the last message - move to the next visible one.
  (notmuch-show-next-open-message))

where I've added some good ol' print foo debugging.

using the message from the openmpi mailing list I sent earlier and
pressing tab, I get in the *Messages* buffer:

For information about GNU Emacs and the GNU system, type C-h C-a.
pt00: 1
pt01: 1392
msg-end: #marker at 1393 in *[Open MPI Announce] Open MPI...
pt11: 1392
pt12: 1392
point: 1
window-end: 1113
notmuch-show-advance-and-archive: End of buffer 

   
ie: it would seem the notmuch-show-move-past-invisible-backward does
*not* move the point up to just before the hidden signature (and does
not move it at all.)

if I uncomment the goto-char to -400 line, everything's fine. (400 is
roughly the length of the hidden signature)

well, this is just an educated guess from an emacs-lisp programmer
complete newbie.

fyi: I am using emacs-23.3
no patch were applied on top of the vanilla sources:
http://projects.archlinux.org/svntogit/packages.git/tree/emacs/repos/extra-x86_64/PKGBUILD

-s


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

Re: Turn Turnsole into a generic mail client

[William Morgan]

Reformatted excerpts from Vivien Didelot's message of 2011-06-21:
 I'm suggesting the make the Turnsole interface modulable to several
 mail sources.

Oh, I see. Yes, to the extent that you can mimic what's in
Turnsole::Client, it will be possible. But that class is a pretty thin
wrapper around the Heliotrope protocol, so mimicking it will feel a lot
like writing a Heliotrope compatibility layer.

I'm not personally interested in doing this, since Heliotrope is the One
True Mailstore as far as I'm concerned, but I'll try to be helpful if
you attempt it.
-- 
William wmorgan-...@masanjin.net
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: Python updates

[Carl Worth]

On Thu, 16 Jun 2011 15:58:39 +0200, Sebastian Spaeth sebast...@sspaeth.de 
wrote:
 P.S. Once I get started I was teased on IRC, so I also implemented:
 
 Message().maildir_flags_to_tags and tags_to_maildir_flags, which are now
 by default invoked on Database().add_message and on any operation that
 modifies notmuch tags. See the updated API docs at:

I'm not a fan of the above.

I would greatly prefer that any language bindings for notmuch implement
the same semantics as the underlying functions.

If we should fix Database().add_message to automatically call
maildir_flags_to_tags, then we should also fix
notmuch_database_add_message to do the same thing.

I can't see any good justification for behavior like this to be
different depending on the language being used to access the library.

Please consider changing things to match the semantics of the underlying
library.

Thanks,

-Carl

-- 
carl.d.wo...@intel.com


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

Re: [PATCH] notmuch-new.c infinite recursion symlink bug

[Carl Worth]

On Tue, 21 Jun 2011 12:01:17 -0400, Austin Clements amdra...@mit.edu wrote:
 Alternatively, because of folder search, it might be better to keep a
 stack of inode numbers to eliminate loops while retaining notmuch's
 current approach of repeatedly indexing mail that's symlinked in
 multiple folders.

Yes, that sounds like the right approach.

-Carl

-- 
carl.d.wo...@intel.com


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

Re: [PATCH] Fix compilation warnings in test/smtp-dummy.c.

[Carl Worth]

On Thu, 16 Jun 2011 14:32:08 +0400, Dmitry Kurochkin 
dmitry.kuroch...@gmail.com wrote:
 * Remove unused variables in main(): buf, bytes and greeting.
 * Replace return with no value in main() with exit(3).

Thanks. I'd notice these occasionally when running the test suite and
had meant for some time to fix them. But when doing my typical
compilation within emacs, (with just make), I wouldn't get these
warnings so I wasn't cleaning these in my typical work to make the
compilation error/warning-free.

I did follow up with a commit to prefer return (with a value) over
exit(), which I applied throughout the main() function:

commit b1aa676cca01ce0d907d220dc3c3a5142991c1cf
Author: Carl Worth cwo...@cworth.org
Date:   Tue Jun 21 14:54:10 2011 -0700

smtp-dummy: Prefer return rather than exit() in main.

The main() function should be written as just another function with a
return value. This allows for more reliable code reuse. Imagine that
main() grows too large and needs to be factored into multiple
functions. At that point, exit() is probably the wrong thing, yet can
also be hard to notice as it's in less-frequently-tested exceptional
cases.


-Carl

-- 
carl.d.wo...@intel.com


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

Re: bug in emacs-ui ?

[Carl Worth]

On Tue, 21 Jun 2011 21:26:25 +0200, Sebastien Binet seb.bi...@gmail.com wrote:
 fyi: I am using emacs-23.3

Perhaps this is an emacs bug?

I'm using Debian's emacs 23.3.1 and have not encountered the problem
described.

-Carl

-- 
carl.d.wo...@intel.com


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

[no subject]

[david]

Here is my proposal, based on Clint's suggestion on IRC, and on the
sed hack from librhash, to hide all symbols that are not explicitly
part of the notmuch API. In particular it hides the various symbols
related to Xapian exceptions.

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

[PATCH 1/2] libnotmuch: add linker script to declare only notmuch_* symbols as global.

[david]

From: David Bremner brem...@debian.org

This is closely tied to gcc and particularly gnu ld, but I guess the
shared library linking code would need to be adjusted to work on a
non-gnu linker anyay.

I had to make a few not-obviously related changes to the
lib/Makefile.local to make this work: libnotmuch_modules is defined
with := and used in place of $^
---
 lib/Makefile.local |   17 -
 1 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/lib/Makefile.local b/lib/Makefile.local
index 4319023..4676504 100644
--- a/lib/Makefile.local
+++ b/lib/Makefile.local
@@ -36,7 +36,7 @@ LIBRARY_SUFFIX = so
 LINKER_NAME = libnotmuch.$(LIBRARY_SUFFIX)
 SONAME = $(LINKER_NAME).$(LIBNOTMUCH_VERSION_MAJOR)
 LIBNAME = $(SONAME).$(LIBNOTMUCH_VERSION_MINOR).$(LIBNOTMUCH_VERSION_RELEASE)
-LIBRARY_LINK_FLAG = -shared -Wl,-soname=$(SONAME)
+LIBRARY_LINK_FLAG = -shared -Wl,--version-script=notmuch.sym,-soname=$(SONAME)
 ifeq ($(LIBDIR_IN_LDCONFIG),1)
 ifeq ($(DESTDIR),)
 LIBRARY_INSTALL_POST_COMMAND=ldconfig
@@ -66,13 +66,20 @@ libnotmuch_cxx_srcs =   \
$(dir)/query.cc \
$(dir)/thread.cc
 
-libnotmuch_modules = $(libnotmuch_c_srcs:.c=.o) $(libnotmuch_cxx_srcs:.cc=.o)
+libnotmuch_modules := $(libnotmuch_c_srcs:.c=.o) $(libnotmuch_cxx_srcs:.cc=.o)
 
 $(dir)/libnotmuch.a: $(libnotmuch_modules)
$(call quiet,AR) rcs $@ $^
 
-$(dir)/$(LIBNAME): $(libnotmuch_modules)
-   $(call quiet,CXX $(CXXFLAGS)) $^ $(FINAL_LIBNOTMUCH_LDFLAGS) 
$(LIBRARY_LINK_FLAG) -o $@
+$(dir)/$(LIBNAME): $(libnotmuch_modules) notmuch.sym
+   echo $(libnotmuch_modules)
+   $(call quiet,CXX $(CXXFLAGS)) $(libnotmuch_modules) 
$(FINAL_LIBNOTMUCH_LDFLAGS) $(LIBRARY_LINK_FLAG) -o $@
+
+notmuch.sym: lib/notmuch.h
+   gcc -aux-info notmuch.aux $
+   printf {\nglobal:\n  notmuch.sym
+   sed  -n 's/.*\(notmuch_[a-z_]*\) (.*/\t\1;/p' notmuch.aux  notmuch.sym
+   printf local: *;\n};\n  notmuch.sym
 
 $(dir)/$(SONAME): $(dir)/$(LIBNAME)
ln -sf $(LIBNAME) $@
@@ -96,4 +103,4 @@ install-$(dir): $(dir)/$(LIBNAME)
$(LIBRARY_INSTALL_POST_COMMAND)
 
 SRCS  := $(SRCS) $(libnotmuch_c_srcs) $(libnotmuch_cxx_srcs)
-CLEAN := $(CLEAN) $(libnotmuch_modules) $(dir)/$(SONAME) $(dir)/$(LINKER_NAME) 
$(dir)$(LIBNAME) libnotmuch.a
+CLEAN := $(CLEAN) $(libnotmuch_modules) $(dir)/$(SONAME) $(dir)/$(LINKER_NAME) 
$(dir)$(LIBNAME) libnotmuch.a notmuch.aux notmuch.sym
-- 
1.7.5.3

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

[PATCH 2/2] remove Xapian exceptions symbols from libnotmuch1.symbols

[david]

From: David Bremner brem...@debian.org

These were never intended to be public, since the library exports only
a C API.
---
 debian/libnotmuch1.symbols |   14 --
 1 files changed, 0 insertions(+), 14 deletions(-)

diff --git a/debian/libnotmuch1.symbols b/debian/libnotmuch1.symbols
index f50d168..8df6fec 100644
--- a/debian/libnotmuch1.symbols
+++ b/debian/libnotmuch1.symbols
@@ -1,18 +1,4 @@
 libnotmuch.so.1 libnotmuch1 #MINVER#
- _Z32_notmuch_message_ensure_metadataP16_notmuch_message@Base 0.6~171
- _ZN6Xapian20InvalidArgumentErrorC1ERKS0_@Base 0.6~171
- _ZN6Xapian20InvalidArgumentErrorC2ERKS0_@Base 0.6~171
-#MISSING: 0.6~180# _ZN6Xapian20InvalidArgumentErrorD1Ev@Base 0.6~171
- _ZTIN6Xapian10LogicErrorE@Base 0.3
- _ZTIN6Xapian12RuntimeErrorE@Base 0.3
- _ZTIN6Xapian16DocNotFoundErrorE@Base 0.3
- _ZTIN6Xapian20InvalidArgumentErrorE@Base 0.3
- _ZTIN6Xapian5ErrorE@Base 0.3
- _ZTSN6Xapian10LogicErrorE@Base 0.3
- _ZTSN6Xapian12RuntimeErrorE@Base 0.3
- _ZTSN6Xapian16DocNotFoundErrorE@Base 0.3
- _ZTSN6Xapian20InvalidArgumentErrorE@Base 0.3
- _ZTSN6Xapian5ErrorE@Base 0.3
  notmuch_database_add_message@Base 0.3
  notmuch_database_close@Base 0.3
  notmuch_database_create@Base 0.3
-- 
1.7.5.3

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

Re: hiding xapian symbols

[Daniel Kahn Gillmor]

On 06/21/2011 09:08 PM, da...@tethera.net wrote:
 Here is my proposal, based on Clint's suggestion on IRC, and on the
 sed hack from librhash, to hide all symbols that are not explicitly
 part of the notmuch API. In particular it hides the various symbols
 related to Xapian exceptions.

I like this proposal -- i would be really glad to not see the mangled
Xapian symbols in libnotmuch.so.

However, i'm concerned that the act of hiding these symbols will make it
so that any program that tries to link both libnotmuch and libxapian
will be unable to use these symbols.

Consider the visiblity rules [0]:

 Symbol visibility is default by default but if the linker encounters 
 just one definition with it hidden - just one - that typeinfo symbol 
 becomes permanently hidden (remember the C++ standard's ODR - one 
 definition rule). 


This makes me think that a program that links against libnotmuch and
libxapian, but actually tries to *use* libxapian's exception handling
may have a problem.

This is probably best resolved by writing such an executable and seeing
if it behaves, but alas, i haven't done that work.   Any takers?
Perhaps this could be a test in the notmuch test suite?

--dkg


[0]
http://gcc.gnu.org/wiki/Visibility#Problems_with_C.2B-.2B-_exceptions_.28please_read.21.29




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

Re: hiding xapian symbols

[David Bremner]

On Tue, 21 Jun 2011 22:05:15 -0400, Daniel Kahn Gillmor 
d...@fifthhorseman.net wrote:
 However, i'm concerned that the act of hiding these symbols will make it
 so that any program that tries to link both libnotmuch and libxapian
 will be unable to use these symbols.
 
 This makes me think that a program that links against libnotmuch and
 libxapian, but actually tries to *use* libxapian's exception handling
 may have a problem.
 

This seems to work, when compiled g++ foo.c -lnotmuch -lxapian

I get 

,
| Error opening database at /nonexistant/.notmuch: No such file or directory
| caught Cannot create directory `/nonexistant'
`

don't run it as root ;)

#include stdio.h
#include xapian.h
#include notmuch.h
main (int argc, char **argv){

notmuch_database_t *notmuch
  = notmuch_database_open (/nonexistant,
 NOTMUCH_DATABASE_MODE_READ_ONLY);

  try{
(void)new Xapian::WritableDatabase (/nonexistant,
Xapian::DB_CREATE_OR_OPEN);
  } catch (const Xapian::Error error) {
printf(caught %s\n,error.get_msg().c_str());
  }
}
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch