Hi!
I'm currently starting to try out notmuch-0.16 on NetBSD. It went off
to a rocky start, since it segfaulted in the initial config setup.
Debugging it I found that notmuch uses a glibc extension to realpath,
allowing NULL as second argument.
I've converted it to use a prepared buffer instead;
Hi!
I'm currently starting to try out notmuch-0.16 on NetBSD. It went off
to a rocky start, since it segfaulted in the initial config setup.
Debugging it I found that notmuch uses a glibc extension to realpath,
allowing NULL as second argument.
I've converted it to use a prepared buffer instead;
For the visibility issue please upgrade Notmuch.
BR,
Jani.
On Jan 4, 2014 2:26 PM, "Thomas Klausner" wrote:
>
> Hi!
>
> I'm currently starting to try out notmuch-0.16 on NetBSD. It went off
> to a rocky start, since it segfaulted in the initial config setup.
>
> Debugging it I found that notmuch
I guess we should look at realpath() compatibility, but in fairness passing
NULL for the second parameter is according to POSIX.1-2008, not glibc
extension.
On Jan 4, 2014 2:35 PM, "Jani Nikula" wrote:
>
> For the visibility issue please upgrade Notmuch.
>
> BR,
> Jani.
>
> On Jan 4, 2014 2:26 PM
On Sat, Jan 04, 2014 at 02:35:54PM +0200, Jani Nikula wrote:
> For the visibility issue please upgrade Notmuch.
Thanks. It seems 0.17 came out a short time after I downloaded notmuch :)
I don't need the visibility patch with that version any longer.
Thomas
On Sat, Jan 04, 2014 at 02:46:37PM +0200, Jani Nikula wrote:
> I guess we should look at realpath() compatibility, but in fairness passing
> NULL for the second parameter is according to POSIX.1-2008, not glibc
> extension.
Ah, interesting.
I can file a bug report with NetBSD about that, but in t
On Sat, Jan 04 2014, Thomas Klausner wrote:
> On Sat, Jan 04, 2014 at 02:46:37PM +0200, Jani Nikula wrote:
>> I guess we should look at realpath() compatibility, but in fairness passing
>> NULL for the second parameter is according to POSIX.1-2008, not glibc
>> extension.
>
> Ah, interesting.
>
>
Thomas Klausner writes:
> ^
> ./lib/notmuch-private.h:52:13: note: previous attribute is here
> #pragma GCC visibility push(hidden)
> ^
The clang related issues might be fixed in 0.17; can you try that (or
git master)?
> size_t length;
> -cha
On Sat, Jan 04, 2014 at 03:06:38PM +0200, Tomi Ollila wrote:
> The linux namual page (*) has good explanation of this in the BUGS section
>
> (*) http://man7.org/linux/man-pages/man3/realpath.3.html
>
> After reading that I think fixing that is not as simple as your previous
> patch does it -- so
On Sat, Jan 04, 2014 at 09:18:15AM -0400, David Bremner wrote:
> Thomas Klausner writes:
>
> > ^
> > ./lib/notmuch-private.h:52:13: note: previous attribute is here
> > #pragma GCC visibility push(hidden)
> > ^
>
> The clang related issues might be fix
On Jan 5, 2014 12:38 AM, "Thomas Klausner" wrote:
>
> On Sat, Jan 04, 2014 at 09:18:15AM -0400, David Bremner wrote:
> > I'm not sure what the right answer is here. MATHPATHLEN (and PATH_MAX)
> > are not necessarily defined; in particular this would break
> > compilation on GNU Hurd. Perhaps we sh
Thomas Klausner writes:
>
> Debugging it I found that notmuch uses a glibc extension to realpath,
> allowing NULL as second argument.
>
This should be fixed in commit af5c3af ; I'd appreciate if you can test
it.
d
Thomas Klausner writes:
> Hi David!
>
> On Tue, Apr 08, 2014 at 08:26:25AM -0300, David Bremner wrote:
>> > Debugging it I found that notmuch uses a glibc extension to realpath,
>> > allowing NULL as second argument.
>> >
>>
>> This should be fixed in commit af5c3af ; I'd appreciate if you can t
David Bremner writes:
> Is it correct that the statically linked version (notmuch) worked OK but
> the dynamically linked version (notmuch-shared) failed? That's
> consistent with what I observe on Debian, it's just that here the
> dynamically linked version falls back on the canonicalize_file_na
For the visibility issue please upgrade Notmuch.
BR,
Jani.
On Jan 4, 2014 2:26 PM, "Thomas Klausner" wrote:
>
> Hi!
>
> I'm currently starting to try out notmuch-0.16 on NetBSD. It went off
> to a rocky start, since it segfaulted in the initial config setup.
>
> Debugging it I found that notmuch
I guess we should look at realpath() compatibility, but in fairness passing
NULL for the second parameter is according to POSIX.1-2008, not glibc
extension.
On Jan 4, 2014 2:35 PM, "Jani Nikula" wrote:
>
> For the visibility issue please upgrade Notmuch.
>
> BR,
> Jani.
>
> On Jan 4, 2014 2:26 PM
On Sat, Jan 04, 2014 at 02:46:37PM +0200, Jani Nikula wrote:
> I guess we should look at realpath() compatibility, but in fairness passing
> NULL for the second parameter is according to POSIX.1-2008, not glibc
> extension.
Ah, interesting.
I can file a bug report with NetBSD about that, but in t
On Sat, Jan 04, 2014 at 02:35:54PM +0200, Jani Nikula wrote:
> For the visibility issue please upgrade Notmuch.
Thanks. It seems 0.17 came out a short time after I downloaded notmuch :)
I don't need the visibility patch with that version any longer.
Thomas
On Sat, Jan 04 2014, Thomas Klausner wrote:
> On Sat, Jan 04, 2014 at 02:46:37PM +0200, Jani Nikula wrote:
>> I guess we should look at realpath() compatibility, but in fairness passing
>> NULL for the second parameter is according to POSIX.1-2008, not glibc
>> extension.
>
> Ah, interesting.
>
>
Thomas Klausner writes:
> ^
> ./lib/notmuch-private.h:52:13: note: previous attribute is here
> #pragma GCC visibility push(hidden)
> ^
The clang related issues might be fixed in 0.17; can you try that (or
git master)?
> size_t length;
> -cha
On Sat, Jan 04, 2014 at 03:06:38PM +0200, Tomi Ollila wrote:
> The linux namual page (*) has good explanation of this in the BUGS section
>
> (*) http://man7.org/linux/man-pages/man3/realpath.3.html
>
> After reading that I think fixing that is not as simple as your previous
> patch does it -- so
On Sat, Jan 04, 2014 at 09:18:15AM -0400, David Bremner wrote:
> Thomas Klausner writes:
>
> > ^
> > ./lib/notmuch-private.h:52:13: note: previous attribute is here
> > #pragma GCC visibility push(hidden)
> > ^
>
> The clang related issues might be fix
On Jan 5, 2014 12:38 AM, "Thomas Klausner" wrote:
>
> On Sat, Jan 04, 2014 at 09:18:15AM -0400, David Bremner wrote:
> > I'm not sure what the right answer is here. MATHPATHLEN (and PATH_MAX)
> > are not necessarily defined; in particular this would break
> > compilation on GNU Hurd. Perhaps we sh
Thomas Klausner writes:
>
> Debugging it I found that notmuch uses a glibc extension to realpath,
> allowing NULL as second argument.
>
This should be fixed in commit af5c3af ; I'd appreciate if you can test
it.
d
___
notmuch mailing list
notmuch@notm
Thomas Klausner writes:
> Hi David!
>
> On Tue, Apr 08, 2014 at 08:26:25AM -0300, David Bremner wrote:
>> > Debugging it I found that notmuch uses a glibc extension to realpath,
>> > allowing NULL as second argument.
>> >
>>
>> This should be fixed in commit af5c3af ; I'd appreciate if you can t
David Bremner writes:
> Is it correct that the statically linked version (notmuch) worked OK but
> the dynamically linked version (notmuch-shared) failed? That's
> consistent with what I observe on Debian, it's just that here the
> dynamically linked version falls back on the canonicalize_file_na
Thomas Klausner writes:
> Hi!
>
> I'm currently starting to try out notmuch-0.16 on NetBSD. It went off
> to a rocky start, since it segfaulted in the initial config setup.
>
> Debugging it I found that notmuch uses a glibc extension to realpath,
> allowing NULL as second argument.
This exact bu
Hi David!
Thanks for getting back to me about this.
Currently configure (with some patches) says:
Checking for Xapian development files... Yes (1.2.17).
Checking for Xapian compaction support... Yes.
Checking for GMime development files... Yes (gmime-2.4 ).
Checking for Glib development files (>=
Hi David!
Thanks for getting back to me about this.
Currently configure (with some patches) says:
Checking for Xapian development files... Yes (1.2.17).
Checking for Xapian compaction support... Yes.
Checking for GMime development files... Yes (gmime-2.4 ).
Checking for Glib development files (>=
On Thu, Jun 26 2014, Thomas Klausner wrote:
>
> I had some other issues with 0.18 though.
>
> 1. pkgsrc's copy of rst2man is called "rst2man.py". The configure test
> for this fails, of course, and there is another place where rst2man is
> called directly. I've changed that to rst2man.py locally,
Thomas Klausner writes:
> Hi David!
>
> Thanks for getting back to me about this.
> Currently configure (with some patches) says:
>
> Checking for Xapian development files... Yes (1.2.17).
> Checking for Xapian compaction support... Yes.
> Checking for GMime development files... Yes (gmime-2.4 ).
On Thu, Jun 26 2014, Thomas Klausner wrote:
>
> I had some other issues with 0.18 though.
>
> 1. pkgsrc's copy of rst2man is called "rst2man.py". The configure test
> for this fails, of course, and there is another place where rst2man is
> called directly. I've changed that to rst2man.py locally,
Thomas Klausner writes:
> Hi David!
>
> Thanks for getting back to me about this.
> Currently configure (with some patches) says:
>
> Checking for Xapian development files... Yes (1.2.17).
> Checking for Xapian compaction support... Yes.
> Checking for GMime development files... Yes (gmime-2.4 ).
Thomas Klausner writes:
>
> 1. pkgsrc's copy of rst2man is called "rst2man.py". The configure test
> for this fails, of course, and there is another place where rst2man is
> called directly. I've changed that to rst2man.py locally, but it'd be
> good if configure could test for both names, set a
On Sun, Mar 12 2017, David Bremner wrote:
> Thomas Klausner writes:
>
>>
>> 1. pkgsrc's copy of rst2man is called "rst2man.py". The configure test
>>
>
> Since I see notmuch in pkgsrc for netbsd, I guess things have improved.
> I had a quick look at the pkgsrc patches [1]. I don't think we're
>
On Sun, Mar 12, 2017 at 07:24:53PM +0200, Tomi Ollila wrote:
> On Sun, Mar 12 2017, David Bremner wrote:
>
> > Thomas Klausner writes:
> >
> >>
> >> 1. pkgsrc's copy of rst2man is called "rst2man.py". The configure test
> >>
> >
> > Since I see notmuch in pkgsrc for netbsd, I guess things have i
36 matches
Mail list logo
