Hi there,
So - I was pleased to see that the libebook .so remains unchanged from
evo 2.4 to 2.6 - and I just did a little review to try to ensure that
this indeed reflects an unchanged ABI ;-)
It seems that is the case - which is great thanks - I need only to
update a comment in
So,
At the risk of offending the gender-confused; it would be -extremely-
useful to have a Gender boolean in the evolution addresbook [ of course,
perhaps there is I'm just missing it but I dug into the code ].
The reason is OO.o will vary it's salutation on gender; ie.
On Mon, 2006-06-19 at 00:18 +0300, Tor Lillqvist wrote:
I think I have a good guess now: The problem is that all sockets by
default are inherited by child processes in Windows. (Like file
descriptors in Unix.)
Ah - we had some wonderful b-a-s bugs for the few sockets we didn't
CLOEXEC
Hi Ross,
On Fri, 2006-08-11 at 17:32 +0100, Ross Burton wrote:
The change was required for the 770 as ferrying the photos over the bus
Sure - I like the core change, but not the API/ABI detail :-)
If it's required it might be possible to revert that change and
introduce an
Hi Matthew,
On Thu, 2007-10-04 at 10:00 +0530, Srinivasa Ragavan wrote:
And while we're at it, can we please drop the meaningless -1.2 suffix
from the library names (e.g. libedataserver-1.2.so)? As far as I can
tell this is just an artifact from an age before the EDS sonames were
Hi dudie,
So - I started to look at the e-d-s memory explosion situation quickly,
took a nice dump from gdb, ran strings on it and the heap has a ton of
strings around the place (as you would expect) - [ currently running at
only ~60Mb
strings /tmp/eds-heap | sort | uniq -c | sort -n
Hi Paul,
On Fri, 2008-07-11 at 15:30 +0200, Paul Bolle wrote:
* Move Evolution licensing to LGPL v2 and LGPL v3 to let us re-use
the code more easily around the platform.
Did you mean LGPLv2 _or_ LGPLv3 here?
Yes; it's dual licensed - which gives people rather a choice of
On Sat, 2008-07-12 at 13:56 +0300, Felipe Contreras wrote:
Could you consider talking with the samba guys to make libmapi LGPLv3?
That would make things much easier, right?
Yep - would make life easier; OTOH I've spoken to them in the past
along these lines - but though they were
On Sat, 2008-09-20 at 00:47 -0500, Hans Petter Jansson wrote:
Wouldn't it be possible to use a different directory, e.g.
mail/local-index/folders.db? That would avoid both problems.
That seems like a great idea to me; at least - if the 'hot' data set of
evolution is normally just the
On Mon, 2008-10-06 at 18:35 +0100, Rob Bradford wrote:
Okay. Have you got these details? It would be good to see which of those
still apply, etc..
Sure - the original rational here (AFAIR) is quite simple.
If you share the same .evolution across multiple machines, and the
Hi Rob,
On Tue, 2008-10-07 at 16:49 +0100, Rob Bradford wrote:
Hhh. But. The use case you outlined directly above about where this goes
wrong also applies here: Oh. You ran e-d-s on a machine with a version
that migrates it to Some Other Format (tm). You then add some contacts
which go into
Hi Philip,
On Wed, 2008-12-10 at 12:49 +0100, Philip Van Hoof wrote:
What does the lifecycle for the data in that Unset store look like ?
I think the LifeCycle is best described by this document:
http://live.gnome.org/MetadataOnRemovableDevices
It specifies a metadata cache format
Hi Mikkel,
On Sat, 2008-12-13 at 00:18 +0100, Mikkel Kamstrup Erlandsen wrote:
Is it that big a problem? I mean if you store 100,000 uris of avg.
length 50 chars you will have a file about 5mb... One needs only keep
an absolute minimum amount of metadata around.
Well, true - it's
Hi guys,
I was just trying to reproduce some migration performance tests with my
mbox and summary data rsync'd from a 32bit machine to a 64bit machine.
Surprisingly this appears to crash immediately. Looking at the
camel-file-utils.c code I was surprised to see simultaneously an
On Tue, 2009-01-13 at 17:36 +, Chenthill wrote:
On Tue, 2009-01-13 at 14:50 +, Ross Burton wrote:
At present it contains a minimal port of the addressbook part of
eds-dbus to a fairly current (~1 week old) EDS tree. This mostly works
and after a little cleanup should be ready for
Hi Matthew,
On Wed, 2009-11-18 at 14:07 -0500, Matthew Barnes wrote:
With work on Bonobo removal wrapping up, I've finally started taking a
closer look at Camel (Evolution's mail storage and networking library)
Ah - another life-time of cleaning up, and polishing code: the goal
sounds
Hi Matthew,
On Fri, 2009-11-27 at 11:58 -0500, Matthew Barnes wrote:
In fact the mail-to-eds effort is part of what's motivating all this.
Ah ! - ok :-) sounds good.
To make the discussion more concrete, these are my current plans for
Camel's extreme makeover. The final API will
On Wed, 2009-12-16 at 01:16 +0530, Chenthill wrote:
One advantage which I see with #1 is that its a standard way.
One thing about both approaches, is that they will consume more space;
eg. on my 'Sent' folder with 21k messages - on average (on ext3) we will
chew ~2k of space for each of
Hi guys,
I just hit a nasty in camel-folder-summary; suggested patch attached,
seemingly a simple problem of a re-enterancy hazard in the same thread
with a ghashtable:
Thread 121 (Thread 0xa7f37b70 (LWP 23631)):
#0 0xb68c13ef in g_hash_table_resize (hash_table=value optimized out) at
Hi guys,
I have a new fun branch (to review for merging)
mmeeks-gdbus-import
So I am wickedly piling up other misc. fixes in there (so they don't
mask other issues) - but I have the edbus code imported, and running -
and, indeed, it seems to block rather less nastily
On Fri, 2010-02-26 at 22:20 +, Michael Meeks wrote:
I just hit a nasty in camel-folder-summary; suggested patch attached,
seemingly a simple problem of a re-enterancy hazard in the same thread
with a ghashtable:
Ok; this was fixed by Chen's reversion of freeing the uid
Hi guys,
I just got an, oh - several second blocking of the UI of Evolution
inside:
Thread 1 (Thread 0xb5c1a740 (LWP 775)):
#0 0xe424 in __kernel_vsyscall ()
#1 0xb6d56aef in fsync () from /lib/libpthread.so.0
#2 0xb5fc0cbc in write_to_temp_file (err=value optimized out,
On Sat, 2010-02-27 at 09:37 +, Ross Burton wrote:
On Fri, 2010-02-26 at 22:31 +, Michael Meeks wrote:
Thoughts / flameage ? :-)
My thoughts are woohoo and great work. If I'm feeling brave on
Sunday I'll start a clean build of eds and evo-edbus and dogfood it.
Sooo
Hi guys,
I was reading calendar/gui/alarm-dialog/alarm-notify.c - trying (of
course) to work out why alarm delivery is apparently not working at all.
I just committed some code enabling dbus threading - without which you
can quite happily use dbus from multiple threads, only it
Hi Christian,
You write-up sounds really exciting :-)
On Thu, 2010-07-08 at 10:28 +0200, Christian Hilberg wrote:
We will try to map as much of Kolab's functionality as possible onto
Evolution whithout changing Evolution itself (other than providing a plugin,
that is). Especially,
On Mon, 2010-08-23 at 16:32 +0200, Milan Crha wrote:
On Mon, 2010-08-23 at 13:10 +0100, David Woodhouse wrote:
The fixes I mentioned are sitting in my working tree, and I'll commit
and push them today.
This is awesome work - thanks ! :-)
If they're referenced by a global
Hi there,
I have (perhaps) an unusal setup - I get mail to an IMAP inbox, and
then filter much of it off to local storage, and move the rest manually
as I need to.
I have around 1000 mostly short, text only messages in my IMAP inbox;
and yet:
du -m
27 matches
Mail list logo
