On 2012-01-21T11:25:39, David Bremner wrote:
>On Fri, 30 Dec 2011 19:58:09 -0200, Kazuo Teramoto
>wrote:
>> g_mime_init already check for multiple initializations.
>> ---
>> lib/index.cc |4
>> lib/message-file.c |4
>
>I'm going
On 2012-01-21T11:25:39, David Bremner wrote:
>On Fri, 30 Dec 2011 19:58:09 -0200, Kazuo Teramoto wrote:
>> g_mime_init already check for multiple initializations.
>> ---
>> lib/index.cc |4
>> lib/message-file.c |4
>
>I'm going to
On Fri, Jan 20, 2012 at 12:26:05PM +0100, Justus Winter wrote:
> Quoting Patrick Totzke (2012-01-20 11:40:41)
> >I suspect you don't split the config value and thus afew ended up
> >with a false tag "new;". its just cosmetics but nevertheless..
>
> Hm, actually it does exactly that:
>
> def get_n
On Fri, Jan 20, 2012 at 12:26:05PM +0100, Justus Winter wrote:
> Quoting Patrick Totzke (2012-01-20 11:40:41)
> >I suspect you don't split the config value and thus afew ended up
> >with a false tag "new;". its just cosmetics but nevertheless..
>
> Hm, actually it does exactly that:
>
> def get_n
On Tue, Jan 17, 2012 at 12:56:39AM +0100, Thomas Jost wrote:
> There are lots of API changes in gmime 2.6 crypto handling. By adding
> preprocessor directives, it is however possible to add gmime 2.6 compatibility
> while preserving compatibility with gmime 2.4 too.
I tested this with gmime 2.4.31
On Tue, Jan 17, 2012 at 12:56:39AM +0100, Thomas Jost wrote:
> There are lots of API changes in gmime 2.6 crypto handling. By adding
> preprocessor directives, it is however possible to add gmime 2.6 compatibility
> while preserving compatibility with gmime 2.4 too.
I tested this with gmime 2.4.31
On 2011-12-31T00:55:59, David Bremner wrote:
>On Fri, 30 Dec 2011 19:58:09 -0200, Kazuo Teramoto
>wrote:
>> g_mime_init already check for multiple initializations.
>> ---
>> lib/index.cc |4
>> lib/message-file.c |4
>> 2 files c
As reported in
id:"CAEbOPGyuHnz4BPtDutnTPUHcP3eYcRCRkXhYoJR43RUMw671+g at mail.gmail.com"
sometimes gmime try to access a NULL pointer, e.g. g_mime_iconv_open()
try to access iconv_cache that is NULL if g_mime_init() is not called.
This cause notmuch to segfault when calling gmime functions.
Calli
I'm resending the PATCH 2/2 as a standalone, leaving the matter of
removing the checks for the future. I added a more detailed commit too.
This is the only patch needed to fix the segfault I reported.
Kazuo Teramoto (1):
lib: call g_mime_init() from notmuch_database_open()
lib/databa
On 2011-12-30T23:16:47, Patrick Totzke wrote:
>It seeminly doesn't break things either and I'm all in favour of doing
>things right?.
And talking about doing things right, we probably need to call
g_mime_shutdown() too, one for every time we call g_mime_init(). I will
send a patch after I do some
As reported in
id:"caebopgyuhnz4bptdutntpuhcp3eycrcrkxhyojr43rumw67...@mail.gmail.com"
sometimes gmime try to access a NULL pointer, e.g. g_mime_iconv_open()
try to access iconv_cache that is NULL if g_mime_init() is not called.
This cause notmuch to segfault when calling gmime functions.
Calling
I'm resending the PATCH 2/2 as a standalone, leaving the matter of
removing the checks for the future. I added a more detailed commit too.
This is the only patch needed to fix the segfault I reported.
Kazuo Teramoto (1):
lib: call g_mime_init() from notmuch_database_open()
lib/databa
We need to call g_mime_init to correct initialize the structures needed
by gmime before using it.
---
lib/database.cc |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index d11dfaf..07ca3fd 100644
--- a/lib/database.cc
+++ b/lib/databas
g_mime_init already check for multiple initializations.
---
lib/index.cc |4
lib/message-file.c |4
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/lib/index.cc b/lib/index.cc
index d8f8b2b..6764929 100644
--- a/lib/index.cc
+++ b/lib/index.cc
@@ -419,12 +419
tmuch don't need to explicit
check for an already initialized gmime.
This make possible to call g_mime_init again in lib/database.cc and this
call really solve the OP segmentation fault in python bindings.
Kazuo Teramoto (2):
lib: Remove unnecessary checks when calling g_mime_init
lib: call g
On 2011-12-31T00:55:59, David Bremner wrote:
>On Fri, 30 Dec 2011 19:58:09 -0200, Kazuo Teramoto wrote:
>> g_mime_init already check for multiple initializations.
>> ---
>> lib/index.cc |4
>> lib/message-file.c |4
>> 2 files chan
On 2011-12-30T23:16:47, Patrick Totzke wrote:
>It seeminly doesn't break things either and I'm all in favour of doing
>things right™.
And talking about doing things right, we probably need to call
g_mime_shutdown() too, one for every time we call g_mime_init(). I will
send a patch after I do some
We need to call g_mime_init to correct initialize the structures needed
by gmime before using it.
---
lib/database.cc |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index d11dfaf..07ca3fd 100644
--- a/lib/database.cc
+++ b/lib/databas
g_mime_init already check for multiple initializations.
---
lib/index.cc |4
lib/message-file.c |4
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/lib/index.cc b/lib/index.cc
index d8f8b2b..6764929 100644
--- a/lib/index.cc
+++ b/lib/index.cc
@@ -419,12 +419
tmuch don't need to explicit
check for an already initialized gmime.
This make possible to call g_mime_init again in lib/database.cc and this
call really solve the OP segmentation fault in python bindings.
Kazuo Teramoto (2):
lib: Remove unnecessary checks when calling g_mime_init
lib: call g
notmuch code, but can this be the case of the python bindings not
calling g_mime_init() correctly?
Regards,
Kazuo Teramoto
#!/usr/bin/env python2
import notmuch
db = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE)
q_new = notmuch.Query(db, 'id:"4efc743a.3060...@april.org&q
ch code, but can this be the case of the python bindings not
calling g_mime_init() correctly?
Regards,
Kazuo Teramoto
#!/usr/bin/env python2
import notmuch
db = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE)
q_new = notmuch.Query(db, 'id:"4efc743a.3060...@april.org"')
or
notmuch code, but can this be the case of the python bindings not
calling g_mime_init() correctly?
Regards,
Kazuo Teramoto
#!/usr/bin/env python2
import notmuch
db = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE)
q_new = notmuch.Query(db, 'id:"4efc743a.3060...@april.org&q
ch code, but can this be the case of the python bindings not
calling g_mime_init() correctly?
Regards,
Kazuo Teramoto
-- next part --
A non-text attachment was scrubbed...
Name: test.py
Type: text/x-python
Size: 201 bytes
Desc: not available
URL:
<http://notmuchma
notmuch code, but can this be the case of the python bindings not
calling g_mime_init() correctly?
Regards,
Kazuo Teramoto
-- next part --
A non-text attachment was scrubbed...
Name: test.py
Type: text/x-python
Size: 202 bytes
Desc: not available
URL:
<http://notmuchma
or
notmuch code, but can this be the case of the python bindings not
calling g_mime_init() correctly?
Regards,
Kazuo Teramoto
-- next part --
#!/usr/bin/env python2
import notmuch
db = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE)
q_new = notmuch.Query(db, 'id
On 2011-12-16T14:01:42, David Bremner wrote:
>Also, there is the question of common text like search-terms, which
>could be included in every page, or maybe contained in man notmuch.
>
What about continuing the git-foo analogy and creating a notmuch search
terms page. Like how git-log page referen
On 2011-12-16T08:28:37, Patrick Totzke wrote:
>
>Hmm.. Is anybody using Arch willing to look into this? Or can anybody
>suggest a painless and quick way for me to set up an Arch installation
>in a Virtualbox or so to be able to reproduce this?
>
I'm using Arch and I have debugging log. I'm using
On 2011-12-16T14:01:42, David Bremner wrote:
>Also, there is the question of common text like search-terms, which
>could be included in every page, or maybe contained in man notmuch.
>
What about continuing the git-foo analogy and creating a notmuch search
terms page. Like how git-log page referen
On 2011-12-16T08:28:37, Patrick Totzke wrote:
>
>Hmm.. Is anybody using Arch willing to look into this? Or can anybody
>suggest a painless and quick way for me to set up an Arch installation
>in a Virtualbox or so to be able to reproduce this?
>
I'm using Arch and I have debugging log. I'm using
an universal tagging solution with some fancy features
From: Kazuo Teramoto
In-Reply-To:
On 2011-12-14T08:42:36, Justus Winter wrote:
>I'd like to introduce my initial tagging approach, afew tags:
>
>https://github.com/teythoon/afew
>
Very good! Thanks for it. I'
an universal tagging solution with some fancy features
From: Kazuo Teramoto
In-Reply-To:
On 2011-12-14T08:42:36, Justus Winter wrote:
>I'd like to introduce my initial tagging approach, afew tags:
>
>https://github.com/teythoon/afew
>
Very good! Thanks for it. I'
Hi!
Following an alot bug report [1] I created a small python script that
causes a segmentation fault in notmuch:
#!/usr/bin/env python2
import notmuch
db = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE)
q_new = notm
Hi!
Following an alot bug report [1] I created a small python script that
causes a segmentation fault in notmuch:
#!/usr/bin/env python2
import notmuch
db = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE)
q_new = notm
34 matches
Mail list logo
