Re: [Evolution-hackers] Move IMAPX back to a module library for 3.12
On Mon, Aug 19, 2013 at 9:03 PM, Matthew Barnes mbar...@redhat.com wrote: The IMAPX classes were moved into Camel's public API to serve as base classes for evolution-kolab. But since Christian has parted ways with us it would appear the evolution-kolab project is no longer active. I'm planning a good deal of API changes to IMAPX over the next few months as I work toward completing IMAP NOTIFY support, and I would prefer these changes not be seen as breaking Camel's public API so I have sufficient freedom to change what needs changed. Therefore I plan to move the IMAPX classes back to a runtime-loadable module library after the 3.10 release. If the evolution-kolab project is resurrected at some point in the future then we can renegotiate this. Any objections? I still dont accept it under Camel. Since we are fixing it, Im fine. -Srini. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
Hi Fabiano, On Wed, Jul 24, 2013 at 6:29 AM, Fabiano Fidêncio fabi...@fidencio.org wrote: Srini, I really wouldn't want EDS to be part of this, if we ever want it to be a proper platform/core material. Just Evolution would be better fit for this model IMHO. Could I ask you why? If you check our git's activity you will see that the most part of bugs we are fixing are touching both in Evolution as in EDS. I really cannot imagine these two parts not walking together. I know how tight the development is. Infact, in my watch, we added a configure check that mandates same minor micro version. But IMHO this model should change for good. It kind of brought lot of flexibility for introducing breakages because we know Evolution would work with only the right version of EDS well but we kind get into a model of ignoring the apps that would depend on EDS. All along we (Evolution/EDS hackers) were blamed for breaking API/ABI. Im not support this following statement, but there was a time, when you can just build evolution and not use latest EDS/Gtk/other platform bits on atleast 2 older GNOME releases. I may not ask for this, but atleast we should have EDS decoupled from Evolution releases to let it survive/develop as a platform on its own. Some might argue that having a yearly releases will give longer API/ABI stability, but again coupling EDS Evolution will let us into more breakages. My point for this was not about the duration, but about decoupling the EDS Evolution releases to plan/avoid any API/ABI (re)designs for EDS. This is my thought, and some may support it but a lot might oppose it ;-). Thanks, -Srini. Best Regards, -- Fabiano Fidêncio ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Wed, Jul 24, 2013 at 3:28 PM, David Woodhouse dw...@infradead.org wrote: I don't think that makes sense. As Fabiano points out, Evo and EDS are *very* closely tied. Even in the *stable* branch in 3.8.4 there are fixes for EDS/EWS which require corresponding fixes in Evo. Breaking the close version ties with the rest of GNOME makes sense, but not between Evo and EDS. It is my wish, we could decouple EDS Evolution releases to start building API/ABI stability into EDS. I don't have strong objects to EDS having yearly releases. Im not saying that we wont/cant' to backporting fixes and re-releasing for minor/micro releases. We should be able to go back at least 2 GNOME releases. This is required kind of required if you want to avoid 'adapting to 3.6 EDS' like commits in EWS/LibreOffice/SyncEvolution/* -Srini ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
On Tue, Jul 23, 2013 at 7:40 PM, Matthew Barnes mbar...@redhat.com wrote: I've been kicking around this idea for awhile now, but haven't said anything until now. I'm putting it out there as food for thought. Increasingly I'm feeling like the traditional 6-month release cycle is just too short for Evolution. In terms of development, we have a pretty short window for landing major changes and allowing adequate time for testing before development freezes set in. I like the idea very much and had similar plans before, but never went forward with it before. But more importantly, our users seem to be constantly playing catch-up in terms of supported releases. Because of the delay between upstream releases and distro releases, by the time users finally upgrade to a newer Evolution, more often than not they're upgrading to a version that's either nearing the tail end of its 6-month support window or is already unsupported. That's frustrating, both for users and for me as a developer, but we just don't have the manpower to support multiple stable releases and still get any kind of significant development work done. I'd like us to consider moving to a 12-month release cycle, which would sync up with GNOME's release schedule annually instead of semi-annually. Here's my initial proposal, if you guys are open to this: * Continue with the 6-month releases through the end of the year, just because I think we need more lead time for such a major policy change. * Bump Evolution's major version number to split away from GNOME's semi-annual release numbering. Call the upcoming March 2014 release Evolution 4.0 (or perhaps even Evolution 2014... I'm open to ideas). * We would follow GNOME's string change announcement and freeze schedule in the months leading up to each March release. * We would continue releasing stable updates and development snapshots at a steady pace. Our release schedule could even be more predictable than it is now. We could do, for example, stable releases on the 1st Monday of each month and development snapshots on the 3rd Monday. The challenge will be to sync properly with the GNOME freezes during the second half of the cycle. It will be good to sync with that, so that when the product releases with GNOME release, there is doc / translation all ready. I really wouldn't want EDS to be part of this, if we ever want it to be a proper platform/core material. Just Evolution would be better fit for this model IMHO. -Srini ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] What happened to email-factory?
[Sorry, I was away on a family emergengy and just back to work] On Sat, Jan 5, 2013 at 6:28 PM, Matthew Barnes mbar...@redhat.com wrote: On Fri, 2013-01-04 at 20:58 +0200, Mehmet Giritli wrote: I was looking forward to have the email backend moved into EDS so that I can write a proper mail notification UI for gnome. But I noticed that the branch here https://github.com/sragavan/e-mail-factory was never merged and I can no longer see it among the future plans. So I am a little curious what happened to this project? Has it been dropped entirely? Good question. I'd still like to see it happen, but I haven't heard from Srini in several months and our architecture has changed greatly since the last commit on that repo. If I end up having to carry it the rest of the way then it then it's at least a year out yet since I have other priorities. This is a nice-to-have, not a must-have feature. I haven't ported it beyond 3.4. But I always see a week or two effort to update to the latest branch. Evolution project exports the libemail-engine and libemail-utils (which is gone now) to e-mail-factory daemon[1]. I just keeping porting it when I get sometime. Its definitely not dead and I wouldn't leave it atleast. The daemon code[1] is maintained here for the time being once we do all great, this the library should be in EDS. It has a complete dbus api but the ideal design would be to get a eclient based one. It needs about 4-6man months to complete this and let evolution use this. -Srini [1] - https://github.com/sragavan/e-mail-factory ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
On Thu, Mar 1, 2012 at 8:13 PM, Matthew Barnes mbar...@redhat.com wrote: I added a page to our wiki about the upcoming file format for account data. It focuses more on the nuts and bolts of the file format itself rather than the APIs used to access the data. In particular, I wanted to get the mail account format written down somewhere since it's a bit more complex than the rest. This is good to have. Lemme go through them to see if I see any issues there -Srini. http://live.gnome.org/Evolution/ESourceFileFormat Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Compile Evolution Mail as .so file with API for other GUI on ARM device
Hi Michal, On Thu, Feb 9, 2012 at 2:27 PM, Michal G. guziemic.s...@gmail.com wrote: Hi, If you are looking to get eds/evo rid of gtk, you are proned to be lost. Instead, use the dbus api and write a email client in qt. You can glance it https://meego.gitorious.org/meego-ux/meego-app-email. I worked on a qt/qml based email client which spoke to the email daemon over dbus. It is obsolete atm. Thanks for help. I look at this code and it is very interesting from my point of view. It is very close to this what I am trying to achieve. I am not going to use Qml, but I can take it as an example My purpose for showing the code is to look at it as an example :) and develop my own app. As I saw Qml is related with Qt QMF component. From Qt Labs description it sounds like very useful framework. Does it means that this application is using Evolution only to store mails and all connection with mail servers (POP, IMAP, SMTP) is handled by QMF? The code I showed you, uses e-mail-factory for everything. It replaced QMF. Could you tell me if meego-app-calendar is done in similar way? http://meego.gitorious.org/meego-ux/meego-app-calendar As I saw both projects do not have any activity in last days. Do you know if those projects are still alive or maybe developed as closed-code? The code is dead, I dont have any closed source on them. I have no idea on the calendar stuff. Sorry. -Srini ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Compile Evolution Mail as .so file with API for other GUI on ARM device
On Mon, Feb 6, 2012 at 8:18 PM, Michal G. guziemic.s...@gmail.com wrote: Hi, I need more support as Evolution is huge project and I feel that I am lost. Last days, I just went through code and I compiled EDS but on X86 without Gtk+. Thus, I modified some configuration files and main makefile to be able to compile. Next, I tried to compile Evolution. But there is a lot of dependencies to UI (gtk), which I would like to remove. I would like to replace it for instance with GUI written in Qt. If you are looking to get eds/evo rid of gtk, you are proned to be lost. Instead, use the dbus api and write a email client in qt. You can glance it https://meego.gitorious.org/meego-ux/meego-app-email. I worked on a qt/qml based email client which spoke to the email daemon over dbus. It is obsolete atm. I have question regarding functionality and place where should I look for source code. I think that main components on which I should focus are following folders - libemail-utils - libemail-engine - mail (I am not sure if I should consider this folder) and there is folder modules/mail - what kind of functionality is kept there? Its for the UI of evolution its logics. -Srini Is there other place where code related to email is located? And does Evolution uses system settings for network configuration as default or it must be configured somehow? Michal ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Compile Evolution Mail as .so file with API for other GUI on ARM device
On Thu, Feb 2, 2012 at 2:49 PM, Michal G. guziemic.s...@gmail.com wrote: Hi Srini, I will go in direction of modifying build process to be able to remove all dependencies to libraries that are not available on my SDK. I think it should be possible, but still I am not sure. My aim is to compile EDS (only mails) with Evolution (only libemail-engine + ??) and your e-mail-factory. Then I'm going to provide some GUI. Communication between those components should be done via DBUS. I am still no aware how content of mail will be visible for user. Or in other words, who will render its content. Evolution uses gtkhtml for rendering mails. Anjal used webkit. You can also use MozEmbed. In addition, I need to estimate how big package (backend) I will have after successful compilation. Could you help me in estimation? Big in the sense size? I have no idea tbh. -Srini Thanks in advance for advices. Michal On Tue, Jan 31, 2012 at 3:06 PM, Michal G. guziemic.s...@gmail.com wrote: Hi, I tried to compile EDS with my SDK and unfortunately I did not success. I run autogen.sh --host=arm-oe-linux-gnueabi --enable-gtk-doc-html=no --enable-goa=no --enable-nntp=no --disable-glibtest --disable-weather and during checking of configuration following errors about missing libraries occurs - gtk+-3.0 - gmodule-2.0 - gconf-2.0 - libxml 2.0 - libsoup-2.4 - libgdata - gio - libdb - and some other stuff related to NSS and NSPR. I removed all those checking from configuration.ac to be able to generate Makefile. Some of those libraries could be added to my system, but not all (for instance gtk+). Do you think that I will be able to compile EDS without gtk+? BTW, does 3.6 cycle should be release around September of 2012 or later? Michal On Tue, Jan 31, 2012 at 10:46 AM, Srinivasa Ragavan sraga...@gnome.org wrote: On Tue, Jan 31, 2012 at 3:00 PM, Michal G. guziemic.s...@gmail.com wrote: Hi, Nice to meet the author of Anjal :) I went through code and Wiki yesterday and I am starting to understand just a little piece of very high architecture. I will try to compile EDS with my SDK for my ARM device. But first I need to familiarize with build process. As I understand within EDS there is mail engine - this Camel library which I could use and link dynamically with my GUI. Do you know if there is simple example that shows how to send email message? Camel is just the mail access/storage library. I meant libemail-engine.so in evolution/ project, which runs mails accounts, checks for mails etc. Probably better way will be to use your e-mail-factory. Then I will be able to split GUI and Mail engine on two different processes. Will your e-mail factory be an official part of Evolution soon? e-mail-factory should be in eds in 3.6 cycle, but that depends on how much effort I get to merge evolution to use the mail daemon. I do not understand why you advice me to checkout branch of evolution. I thought that all data engines (mail and calendar) are covered by EDS. e-mail-factory needs libemail-engine, which is in evolution. Evolution needs EDS. And when I compile it I will be able to connect it with my GUI. It could be done over DBUS if I have two processes or just dynamic linking to GUI. Do I think correctly? You GUI should speak over dbus to the daemon (which is a process by itself) to fetch/access mails. Could you say, point me a document that describe how EDS store mails and calendar data. Is it some own database in file or some other mechanism? I don't remember any doc for this, what ever you find could be obsolete in some form I fear. -Srini ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Compile Evolution Mail as .so file with API for other GUI on ARM device
On Thu, Feb 2, 2012 at 4:11 PM, Michal G. guziemic.s...@gmail.com wrote: Then I will use Webkit. It is available and I was doing simple browser with it. For now, I have Qt port of Webkit and Cairo graphic. Regarding size, I wonder about footprint of Evolution. I checked on my Ubuntu and it is about 12 MB. Hopefully it will required less space after removing of some parts. I found also some interesting post about EDS. http://mail.gnome.org/archives/evolution-hackers/2011-June/msg00028.html As I understand there is some work done to make EDS more UI independent. Do you know if this was done, or work is in progress and in which release it will be? CamelSettings is done. But Im not sure of what you mean by UI independence. And as release 3.4 is planned for March 2012. Does it means that 3.6 should be available after six months, so around September 2012. Does evolution follows GNOME schedules (new stable version every six months)? Yes. Evo follows GNOME schedules. -Srini Michal On Thu, Feb 2, 2012 at 10:21 AM, Srinivasa Ragavan sraga...@gnome.org wrote: On Thu, Feb 2, 2012 at 2:49 PM, Michal G. guziemic.s...@gmail.com wrote: Hi Srini, I will go in direction of modifying build process to be able to remove all dependencies to libraries that are not available on my SDK. I think it should be possible, but still I am not sure. My aim is to compile EDS (only mails) with Evolution (only libemail-engine + ??) and your e-mail-factory. Then I'm going to provide some GUI. Communication between those components should be done via DBUS. I am still no aware how content of mail will be visible for user. Or in other words, who will render its content. Evolution uses gtkhtml for rendering mails. Anjal used webkit. You can also use MozEmbed. In addition, I need to estimate how big package (backend) I will have after successful compilation. Could you help me in estimation? Big in the sense size? I have no idea tbh. -Srini ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Compile Evolution Mail as .so file with API for other GUI on ARM device
On Tue, Jan 31, 2012 at 3:00 PM, Michal G. guziemic.s...@gmail.com wrote: Hi, Nice to meet the author of Anjal :) I went through code and Wiki yesterday and I am starting to understand just a little piece of very high architecture. I will try to compile EDS with my SDK for my ARM device. But first I need to familiarize with build process. As I understand within EDS there is mail engine - this Camel library which I could use and link dynamically with my GUI. Do you know if there is simple example that shows how to send email message? Camel is just the mail access/storage library. I meant libemail-engine.so in evolution/ project, which runs mails accounts, checks for mails etc. Probably better way will be to use your e-mail-factory. Then I will be able to split GUI and Mail engine on two different processes. Will your e-mail factory be an official part of Evolution soon? e-mail-factory should be in eds in 3.6 cycle, but that depends on how much effort I get to merge evolution to use the mail daemon. I do not understand why you advice me to checkout branch of evolution. I thought that all data engines (mail and calendar) are covered by EDS. e-mail-factory needs libemail-engine, which is in evolution. Evolution needs EDS. And when I compile it I will be able to connect it with my GUI. It could be done over DBUS if I have two processes or just dynamic linking to GUI. Do I think correctly? You GUI should speak over dbus to the daemon (which is a process by itself) to fetch/access mails. Could you say, point me a document that describe how EDS store mails and calendar data. Is it some own database in file or some other mechanism? I don't remember any doc for this, what ever you find could be obsolete in some form I fear. -Srini Michal On Mon, Jan 30, 2012 at 3:37 PM, Srinivasa Ragavan sraga...@gnome.org wrote: Hi On Mon, Jan 30, 2012 at 6:27 PM, Michal G. guziemic.s...@gmail.com wrote: Hi, Thank you for answer. Yes. I'm looking for mail engine that will be able to communicate for instance over DBUS which some UI. My device does not uses X.org, GTK and Cairo. It future, I would also append my software with Calendar functionality. Calendar is already in EDS available over DBUS. I choosed to work with Evolution because I saw similar email client called Anjal that utilize Evolution but has own UI. I was the author of Anjal. It was build with Gtk/Cairo on top of libevolution-mail. Now after mbarnes's awesome library breaks, I broke mail engine to a independent library that can reside in EDS (in the future) which I currently server over DBUS. You must checkout master branch of eds and evolution. https://github.com/sragavan/e-mail-factory is the dbus engine that Im working on, which is still under development. Some apis are fun and still not up to the mark. But you can use them and it works fine. -Srini. Could you tell me from which git should I clone - http://git.gnome.org/browse/evolution-data-server - http://git.gnome.org/browse/evolution And could you tell where to start, or what should I read some to - build mail engine library (http://mad-scientist.us/evolution.html - should I follow this process) - API of DBUS Michal On Sat, Jan 28, 2012 at 7:35 AM, Srinivasa Ragavan sraga...@gnome.org wrote: Hi Michal, On Fri, Jan 27, 2012 at 5:27 PM, Michal G. guziemic.s...@gmail.com wrote: Hi, I've been investigating a possibility of Evolution Mail cross-compilation for Linux X-less device (ARM) and use it as dynamic library that will provide me possibility to expose API that could be utilize by HMI layer. 1) Is it possible to compile Evolution Mail without any user interface (pure –headless)? Or how much work would that require? 2) Does Evolution architecture allows doing such split – mail supporting functionality and GUI? 3) Is it possible to eliminate all unnecessary libs and resources? They’re using valuable device resources and may cause compilation problems. 4) If I’m about hacking the build process to my needs (removing dependencies) where should I start? IIUC you want to use the engine of evolution, but not the UI. If so, I've been working on a mail daemon which has all the mail logic built in and exposes mail (basic) interface over dbus. If you aren't interested in that, you can look at libemail-engine.so which is a new library that I added a week ago in master which provides most of what you are looking at except the UI. -Srini Best regards, Michal Guzieniuk ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution
Re: [Evolution-hackers] Compile Evolution Mail as .so file with API for other GUI on ARM device
Hi On Mon, Jan 30, 2012 at 6:27 PM, Michal G. guziemic.s...@gmail.com wrote: Hi, Thank you for answer. Yes. I'm looking for mail engine that will be able to communicate for instance over DBUS which some UI. My device does not uses X.org, GTK and Cairo. It future, I would also append my software with Calendar functionality. Calendar is already in EDS available over DBUS. I choosed to work with Evolution because I saw similar email client called Anjal that utilize Evolution but has own UI. I was the author of Anjal. It was build with Gtk/Cairo on top of libevolution-mail. Now after mbarnes's awesome library breaks, I broke mail engine to a independent library that can reside in EDS (in the future) which I currently server over DBUS. You must checkout master branch of eds and evolution. https://github.com/sragavan/e-mail-factory is the dbus engine that Im working on, which is still under development. Some apis are fun and still not up to the mark. But you can use them and it works fine. -Srini. Could you tell me from which git should I clone - http://git.gnome.org/browse/evolution-data-server - http://git.gnome.org/browse/evolution And could you tell where to start, or what should I read some to - build mail engine library (http://mad-scientist.us/evolution.html - should I follow this process) - API of DBUS Michal On Sat, Jan 28, 2012 at 7:35 AM, Srinivasa Ragavan sraga...@gnome.org wrote: Hi Michal, On Fri, Jan 27, 2012 at 5:27 PM, Michal G. guziemic.s...@gmail.com wrote: Hi, I've been investigating a possibility of Evolution Mail cross-compilation for Linux X-less device (ARM) and use it as dynamic library that will provide me possibility to expose API that could be utilize by HMI layer. 1) Is it possible to compile Evolution Mail without any user interface (pure –headless)? Or how much work would that require? 2) Does Evolution architecture allows doing such split – mail supporting functionality and GUI? 3) Is it possible to eliminate all unnecessary libs and resources? They’re using valuable device resources and may cause compilation problems. 4) If I’m about hacking the build process to my needs (removing dependencies) where should I start? IIUC you want to use the engine of evolution, but not the UI. If so, I've been working on a mail daemon which has all the mail logic built in and exposes mail (basic) interface over dbus. If you aren't interested in that, you can look at libemail-engine.so which is a new library that I added a week ago in master which provides most of what you are looking at except the UI. -Srini Best regards, Michal Guzieniuk ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Compile Evolution Mail as .so file with API for other GUI on ARM device
Hi Michal, On Fri, Jan 27, 2012 at 5:27 PM, Michal G. guziemic.s...@gmail.com wrote: Hi, I've been investigating a possibility of Evolution Mail cross-compilation for Linux X-less device (ARM) and use it as dynamic library that will provide me possibility to expose API that could be utilize by HMI layer. 1) Is it possible to compile Evolution Mail without any user interface (pure –headless)? Or how much work would that require? 2) Does Evolution architecture allows doing such split – mail supporting functionality and GUI? 3) Is it possible to eliminate all unnecessary libs and resources? They’re using valuable device resources and may cause compilation problems. 4) If I’m about hacking the build process to my needs (removing dependencies) where should I start? IIUC you want to use the engine of evolution, but not the UI. If so, I've been working on a mail daemon which has all the mail logic built in and exposes mail (basic) interface over dbus. If you aren't interested in that, you can look at libemail-engine.so which is a new library that I added a week ago in master which provides most of what you are looking at except the UI. -Srini Best regards, Michal Guzieniuk ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] wip/settings branch is merged
On Wed, Nov 23, 2011 at 7:44 PM, Matthew Barnes mbar...@redhat.com wrote: On Wed, 2011-11-23 at 16:05 +0530, Srinivasa Ragavan wrote: I rebased email-factory-3-4 branch of evolution on top of gsettings merge. I'm away for a week in Finland, hopefully you get time to merge this around :-) Okay, thanks. I'll be traveling too for the next couple weeks. Working off and on, won't be on IRC much. But I'll try to look at this next. Thanks, I probably want to get to the API in C and then start with evolution migration. This merge will help me let go of the engine and focus on further things. Thanks, -Srini ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Move evolution-alarm-notify to E-D-S?
On Tue, Oct 18, 2011 at 10:22 PM, Matthew Barnes mbar...@redhat.com wrote: Here's a crazy idea... What do you guys think about moving evolution-alarm-notify to E-D-S as a simple D-Bus service? It could live in the new services directory: evolution-data-server/services/evolution-alarm-notify/ evolution-alarm-notify is already an autostart program, launched when you start your desktop session, well before you ever launch Evolution. Problem is if it dies for some reason it has to be manually restarted, otherwise you'll miss appointment reminders. My thought was if it also claimed a well-known session bus name then it could easily be activated by evolution-calendar-factory on start up, and (most importantly) RE-activated if the calendar factory detects that the bus name lost its owner. I like the idea. It might also be great, if it can notify across the bus for alarms so that any third party program can listen and operate upon. -Srini ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] WebKit port progress update
On Sat, Aug 27, 2011 at 11:38 PM, Matthew Barnes mbar...@redhat.com wrote: On Sat, 2011-08-27 at 09:26 +0530, Srinivasa Ragavan wrote: One thing I can say is that, this will be faster than the earlier method, for reason that even when we expand one attachment/mail, we rerender the entire mail and remember their previous states etc which is sort-a ugly. This approach only deals with the MIME part that you expand/hide and very simple and fast. Well the current approach of making the attachment button and the attachment itself two separate embedded widgets is suboptimal. I know GtkHtml doesn't handle resizing embedded widgets very well so maybe it was done that way as a workaround? Assuming WebKit is better at resizing embedded widgets, an easier approach is to pack each button/attachment pair into a vbox and bind the button's expanded state to the lower widget's visible state. Then you just have to embed one vbox per attachment, which should hopefully avoid having to redraw the whole email when expanding an attachment. Right, but I doubt it. When I did for anjal, I had to make webkit expand every time. It otherwise draws a scrollbar around it even when you have space to expand. Not sure if things have improved lately. You need to write some test code to confirm before you start up the design. -Srini. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] WebKit port progress update
On Fri, Aug 26, 2011 at 10:02 PM, Matthew Barnes mbar...@redhat.com wrote: On Fri, 2011-08-26 at 17:20 +0200, Dan Vratil wrote: as I already mentioned on the IRC meeting, embedding widgets into WebKit is broken and I was told that WebKit-Gtk developers intend to drop this functionality sooner or later. Citation needed. Xan Lopez said he wasn't aware of any problems or plans to drop the API when I asked him about this after the IRC meeting, and the bug you opened includes a comment with a possible solution: https://bugs.webkit.org/show_bug.cgi?id=63451 So I decided to go similar way Anjal does, splitting the email display into multiple webviews. To be able to do so, I also decided to change the way EMFormat works as well. IIRC, Srini told me told me at the Boston Summit last year that this approach for Anjal was fine for display but derailed when it came time to print. Maybe Srini can comment further? (CC'ing him) It isn't simple for printing. But you can work it around by supporting only the needed file types. In any case see if we can get a top window cairo handle and print it to a printable surface. It should be much easier and match what the user sees. If we can do anjal like webkit rendering, it is very simple to get a conversation view into evolution. I could pull pieces from anjal and build it for evolution. [...] Don't get me wrong, the design you're proposing sounds sensible _if_ you can overcome the printing issue. I'm just pointing out the known speed bumps on this road. This is the most appropriate approach I felt for anjal, since Webkit then didn't have embedded gtk objects. IIRC newer webkit supports it. Worth a try to see if it is feasible to consider that. One thing I can say is that, this will be faster than the earlier method, for reason that even when we expand one attachment/mail, we rerender the entire mail and remember their previous states etc which is sort-a ugly. This approach only deals with the MIME part that you expand/hide and very simple and fast. -Srini ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] CamelService changes
On Fri, Apr 22, 2011 at 5:54 PM, Matthew Barnes mbar...@redhat.com wrote: On Fri, 2011-04-22 at 11:02 +0530, Srinivasa Ragavan wrote: Mostly sounds fine to me as a complete picture, but do remember of the email-factory branch that I'm working on to run mail on EDS. I now expose an API (and some custom bits) over dbus that corresponds to camel's session/store/folder. http://git.gnome.org/browse/evolution-data-server/tree/mail/daemon/e-mail-data-session.xml?h=email-factory http://git.gnome.org/browse/evolution-data-server/tree/mail/daemon/e-mail-data-store.xml?h=email-factory http://git.gnome.org/browse/evolution-data-server/tree/mail/daemon/e-mail-data-folder.xml?h=email-factory It'd be great if you can finalize on the API soon, which can help me move things from 2.32 to master. But for now, I'm mainly on the 2.32 branch to get a stable state of the engine. Can you please provide some kind of summary of the design you have, either here on the mailing list or on a wiki page, since as far as I know no one else has a good idea of what you're doing or how it works. I've been trying to get everyone to do this when making large changes, so that no one is working away in secret and suddenly shows up with what they think is a finished product. Oh sure, http://wiki.meego.com/Architecture/planning/evolution-data-server/email-design has some high level design/architecture of the daemon. It also has details on the way MeeGo app uses it and some task list. But The high level design/architecture of the daemon is up there. -Srini. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Fwd: [MeeGo-dev] migration (back) to EDS]
On Tue, Mar 22, 2011 at 2:14 AM, Matthew Barnes mbar...@redhat.com wrote: On Mon, 2011-03-21 at 15:50 +0100, Patrick Ohly wrote: If you see some increased interest in EDS soon, then it might be because MeeGo is currently investigating how to use EDS as the main PIM and email system again. Attached a rough outline of the current ideas. My expectation is that we will start sharing more thoughts and questions here as we proceed. Note that this work probably has to be delivered to MeeGo as part of an Evolution 2.32 based solution, because I don't see us moving to 3.0 soon enough. Hey Patrick, thanks for the info. I meant to ask you when last we spoke on IRC, to what extent are you involved with MeeGo right now, and is there anyone else specifically on the MeeGo team that we should be reaching out to? I'm trying to get a feel for who all is or is going to be involved. Hey Matt, I'm part of the team that is working on it. I'll catch you on IRC asap to discuss very specific details. -Srini. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - July 18 - 3:30 PM UTC
On Mon, Aug 16, 2010 at 6:00 PM, chen pchenth...@novell.com wrote: Hi, This is first meeting after our GUADEC 2010! There would be some interesting updates during meeting. The meeting goes as follows, It probably should be Aug 18 :-) -Srini. * Project updates * Discussion on queries/decisions * Individual updates - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - Aug 18 - 3:30 PM UTC
On Mon, Aug 16, 2010 at 6:54 PM, chen pchenth...@novell.com wrote: On Mon, 2010-08-16 at 18:20 +0530, Srinivasa Ragavan wrote: On Mon, Aug 16, 2010 at 6:00 PM, chen pchenth...@novell.com wrote: Hi, This is first meeting after our GUADEC 2010! There would be some interesting updates during meeting. The meeting goes as follows, It probably should be Aug 18 :-) Thanks for correcting. /me tells to himself - either dont copy paste or make the template dynamic :) Time to use the 'Templates' evolution plugin ;-) -Srini. - Chenthill. -Srini. * Project updates * Discussion on queries/decisions * Individual updates - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Moving from the single mbox file format for the local folders
Hello everyone, On Wed, Dec 16, 2009 at 1:16 AM, Chenthill pchenth...@novell.com wrote: Hi fellow hackers!! I have been working for a while during last week on one the blockers in evolution - https://bugzilla.gnome.org/show_bug.cgi?id=550414 - 'Folder and summary mismatch error'(old one - https://bugzilla.gnome.org/show_bug.cgi?id=213072). As a matter of fact we have been working as a team to get the blockers down. I have not been able to reproduce the issue or yet find the exact problematic area. The mismatch in the frompos index in the folder summary may be caused by either a threading issue or a crash while storing the indexes. I am still investigating it to find the real cause. Looking at other issues such as, https://bugzilla.gnome.org/show_bug.cgi?id=522433 - 'Fails opening mbox 2GB', just got a thought if we could solve both the issues by, Approach #1, migrating local storage from mbox to maildir format. With maildir I have heard about two issues, * Not able to create subfolders under INBOX - https://bugzilla.gnome.org/show_bug.cgi?id=536240 . Approach #2, Migrate from a single mbox file per folder to mbox per email. Srini mentioned an advantage that this would avoid the file renames that maildir does. I think this is much like how other remote providers in evo store the email. It should be rocket fast!. Expunge is just unlink one file. Change of flags etc rewrites just that file when upsync happens. No rewrite 2gb of a file, to expunge 10 mails. Startup/shutdown faster etc etc. I'm a fan of this, what so ever! To overcome 100K mbox files in one folder, distribute under multi-level subdirs and let summary know that. I thought of bring this in this list to gather more opinions to choose the right one. The approach #2 seems a better one as we are choosing a way for storing the messages internally in evo. Are we missing to see anything while we choose the second one ? One advantage which I see with #1 is that its a standard way. You store everything as mbox only still. But one mbox file per mail, distributed in multiple subdirs. Ofcourse you dont want 100K files in one folder, which could move the bottleneck to a different place. Distribute under multi-level subfolders or something like that. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Filtering and mail split
On Thu, Dec 3, 2009 at 3:48 AM, Jonathon Jongsma jonathon.jong...@collabora.co.uk wrote: As some of you may know, I've been looking into moving mail down to the e-d-s level. As a first step, I'm figuring out where to draw the line between the front end and backend. At the moment, I'm focusing on filtering. I think that the filtering functionality clearly belongs in the backend (we want to filter emails as they come in regardless of whether the UI is running or not). The thing I'm trying to figure out right now is what that means for the filter-related classes within evolution (i.e. the stuff in the filter/ directory). My first instinct was that these classes belonged in the backend since that is the part that should be doing the filtering. However, as I looked at it more, I wasn't so sure, and I'd really appreciate insight from people who might have a longer history with this code than I do. (FYI, while I was getting more familiar with the filter code, I wrote up some documentation that you might find helpful: http://live.gnome.org/Evolution/Filters) Excellent job in documenting it. Even more great, because you kept it at lgo. I'm not gonna suggest one of the below but I'm going to think aloud, shut me if its crap. Why should the UI be from the frontend, the Evolution ? If my mail runs in EDS, which reads filters from a xml file, may be as a small capplet/lib/bin with the backend with the UI to launch the filter manager. Independent of Evolution, may be Anjal directly can launch it. Or if we have account setup from Control center as a capplet, then we could launch the filter/rule manager independent of Evolution itself. Is that too much to ask for? It could simplyfy everything? Do we have a tight need of any Evolution components for Filters? I just don't remember, but even if there is, we should try to have it like this IMO -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Where in the code is the autocompletion for To: field done?
On Fri, Oct 23, 2009 at 10:15 AM, Florian K florian_kirchh...@yahoo.com wrote: Hello Evolution developers, first of all thank you for making such a great tool! I have built Evolution 2.26.1 from source on Ubuntu 9.04. I would like to explore the code that handles the autocompletion of email addresses in receipient fields. In particular I would like to see if the it's feasible to make the number of characters to be typed before the search for matches occurs to be configurable (I would like it to be one char, but I understand that more are necessary if the search goes against LDAP). Look at e-d-s/libedataserverui/e-name-selector-entry.c -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Branching for Evolution 2.28 on Aug 11
On Tue, 2009-08-04 at 10:17 -0400, Matthew Barnes wrote: I would also like to ask the Evolution -and- Anjal developers to be very conservative about committing to the Evolution and Evolution-Data-Server 'master' branch after we create the 'gnome-2-28' branch. I wouldn't commit to mail/ any more for anjal (beyond branching ?), till you merge back. If I want to, I will do to master first, if I have to and backport. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution maintainership
Hello guys, This mail is to announce some of the role changes in the Evolution project. I have been thinking about this for a long time, and I feel that this is the best time to implement them. I am proud to announce Chenthill P (chen) as the new Evolution maintainer. He is a long time contributor to the Evolution project and has been working in the project for over 5 years. He is well known in the community for his expertise in Calendar component and has been its maintainer for the last 4 years. He has been one of the prime contributors for the Groupwise provider and Microsoft Exchange Calendar. A few of his notable contributions include libical integration with System timezone for better Daylight savings support, single-model-view design of Calendar MVC and removal of libical fork. He has mentored interns and GSOC students on Calendar search improvements, Microsoft Exchange Delegation support, Google Calendar integration etc. I am also proud to announce that Matthew Barnes (mbarnes) is joining Chenthill and support him as the Evolution co-maintainer. He has been contributing towards Evolution for over 3 years and is the Mail maintainer for the last 2 years. He has made significant contributions towards obsoleting several libraries, and helping to migrate to newer technologies. He has been working on Kill-Bonobo which is a major revamp of Evolution Shell. This involves rewriting Evolution components and UI which is a focus area for Evolution 3.0. Going forward, I will be focusing on improving evolution infrastructure for netbooks and other devices; chen and mbarnes would be driving the Evolution project direction and releases. Please join me in congratulating chen and mbarnes, and in wishing them good luck in their new roles. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] GNOME 3.0 - Evolution plans IRC team meeting
Guys, We have made some proposals to the release-team on GNOME 3.0 plans for Evolution. Specially release/scheduling specifics. Read through the thread. http://mail.gnome.org/archives/release-team/2009-June/msg00018.html We'll probably workout the exact schedule/decision. I wanted to discuss this in tomorrow irc team meeting. But due to my busy schedule and tight meetings tomorrow, I won't be able to make it, and I want to post-pone the team meeting to thursday (UTC 10:00) just this time. Sorry, if this is a late notice. Try to make it or keep me informed if you have some suggestions/thoughts. TIA. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Own project / idea for Google summer of code 2009
On Fri, 2009-03-27 at 12:32 +0100, Pavol Srna wrote: Hello, I would like to discuss my own project / idea for Google summer of code 2009 and if you are interested in, then I would like to find a potential mentor for this project. I am a daily user of GNOME desktop environment and I am missing useful, user-friendly synchronization support with the possibility of broader settings between Evolution (Calendar, phonebook etc.) and mobile devices (Nokia hand phones and so on) via bluetooth. I will introduce a plug-in for Evolution which can easily prepare the mobile device for synchronization, and which let the user set up a variety of synchronization settings and in really user-friendly way synchronizes all the required data in both directions. There have been multiple solutions for this already. OpenSync, SyncEvolution, GNOMEPilot, Conduits, [etc]. Part of these arent fully there. Your project looks to me like an another new project in that direction. New project is good, but its better to look at existing frameworks and see how you can fill the gaps to make it the best. I would suggest to read about these, ping those individual maintainers on the details and propose a solution, that would be widely accepted. HTH -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] EPlugin events
Nick, IIRC, there was a plugin for the same. Don't remember the name. But it wasn't approved to be in upstream. -Srini. On Thu, 2009-03-26 at 08:14 +1100, Nick Cronin wrote: Hi, I was thinking I'd have a go at writing a very small plugin for evolution and I thought a good place to start was a simple minimise to tray plugin. I downloaded the plugin manual and the source code. From what I can gather there is no event that I can hook onto that states if the program is going to be or is currently minimized. Is there a way I can hook directly onto the gtk events via EPlugin or would I need to insert my own EPlugin event (which would wrap the gtk event) to do this? Thanks, Nick Cronin ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Evolution] Evolution 2.26 released
On Wed, 2009-03-18 at 16:42 +0800, Daniel.Li wrote: Excellent work!!! But I have a simple question here.As u know, I have lots of e-mails. And it takes a lot of time compiling the souce code, maybe there will be some configuration issues. So, is there any simple way to upgrade 2.24.3 (ubuntu 8.10) to 2.26.0? Maybe there is a repository that can be added to apt source-list and simply use sudo apt-get update. Sorry, you probably need to ask ubuntu packagers/mailing list. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Interface Spec for PIM component interoperability
Sorry for a late reply - busy on lots of things around. Sure, looks like great idea. Count me in. -Srini. On Mon, 2009-02-16 at 13:35 +0100, Till Adam wrote: Srini, Berndt, I know this thread is very old (hopefully Evo sorts by newest mail in thread, not olders, like KMail did, until recently ;), but I thought I'd hijack it anyhow, for a proposal: What do you guys think of a PIM BOF at the Gran Canaria desktop summit this year? I'd try to get any interested Mozillistas and Maemo-ites involved as well, if you agree that this is a good idea. Hopefully there'll be some around. Would give us all a chance to discuss the state of things and how we can best interoperate and cooperate, in the future. Game? Till On Thursday 21 August 2008 11:24:57 Srinivasa Ragavan wrote: On Wed, 2008-08-20 at 14:14 +0200, Holger Berndt wrote: Hello Evolution hackers, I just subscribed to the list, and browsing the archives this message may or may not have an overlap with the recent thread about EDS D-Bus interface in Future of eds bindings. I am a supporter of the desktop independant, GTK+ based MUA Claws Mail. Its (few) developers are pretty evenly split between between being KDE, GNOME, and XFCE users. I've thought many times that it would be great to have a (maybe freedesktop.org) standard for PIM component access and interaction. Ideally, this would allow for all PIM components implementing this spec to be interchangable without loosing integration, so the user could choose calendar, addressbook, mailer etc independantly, and still have a nicely integrated PIM suite. This could be achieved by defining a common language for popular PIM tasks involving multiple components (by PIM component, I mean MUA, calendar, addressbook, notes application etc). Sure, a valid requirement. Evolution gets used by quite a few KDE users, I have received feedbacks from such users on the similar lines. Let me give a few examples of such tasks: What a MUA could request: - dear addressbook, whoever you might be, please add the following contact: John Doe john@tld.org - dear addressbook, please give me a list of all contacts - dear addressbook, please open up contact xy for editing. Or just show me your main window. - dear calendar, whoever you might be, I just received a meeting invitation via email. Please insert that event into my calendar Basically, it would be necessary to define a set of interfaces (possibly D-Bus services) along the lines of org.freedesktop.pim.addressbook.storage org.freedesktop.pim.addressbook.ui org.freedesktop.pim.calendar.storage org.freedesktop.pim.calendar.ui org.freedesktop.pim.mua.storage org.freedesktop.pim.mua.ui etc, where in the case of GNOME Evolution could provide the *.ui interfaces and EDS could provide the *.storage interfaces. Infact, I'm open to have some defined common interfaces that multiple apps (Mail, Calendar) can interface with the PIM daemons (EDS, Akonadi, etc). Infact, starting next week (planning bits atm), I'm gonna work on moving mail to e-d-s to make EDS complete. Then defining common standards/interfaces (across Mail, Contacts Calendars) would help apps to operate transparently, independent of the desktops. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers -- Till Adam KDAB - platform independent software services ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution 2.24.3 and beyond
Hello guys, Today I released Evolution (and friends) 2.24.3. This is the last stable release in the GNOME stable cycle. But given the issues that 2.24.x series introduced, we would be releasing Evolution 2.24.4 and 2.24.5 and there will be full support till the release of Evolution 2.26.0 [March 16]. I haven't worked out the dates exactly, but plan to have one release later in January and another in mid/late February. This would one of the agenda in this week's team meeting. Thanks a lot for all your support. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] A Camel API to get the filename of the cache, also a proposal to have one format to rule them all
The Exchange patch looks fine to me. -Srini. On Mon, 2009-01-05 at 12:28 +0100, Philip Van Hoof wrote: On Mon, 2009-01-05 at 00:42 +0530, Srinivasa Ragavan wrote: On Fri, 2009-01-02 at 13:25 +0100, Philip Van Hoof wrote: Hi there evos, For an EPlugin that I'm working on I will need a Camel API to get the filename of the cache. Sure and the patch seems fine to me, but the Exchange portion of the patch is missing. It should be similar/simple. Attached. Let me know when it's all reviewed and/if I can commit it. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] A Camel API to get the filename of the cache, also a proposal to have one format to rule them all
Hey Philip, [Im lagging in my mail-replies, still a lot to go, due to my 3 week vacation.] On Fri, 2009-01-02 at 13:25 +0100, Philip Van Hoof wrote: Hi there evos, For an EPlugin that I'm working on I will need a Camel API to get the filename of the cache. Sure and the patch seems fine to me, but the Exchange portion of the patch is missing. It should be similar/simple. I will attach a patch that adds this API. The EPlugin that I'm developing is available at Bug# 565091 and more information about it can be found at http://live.gnome.org/Evolution/Metadata. I added a bug for tracking this request: http://bugzilla.gnome.org/show_bug.cgi?id=566279 I know that for maildir (cur, tmp, new) and mbox (seek position) it's a little bit controversial to return a filename. For maildir I always use the cur-file one and for mbox I added /!seek_pos to the end of the returned filename. The reason why I need this is that for indexing already cached E-mails, Tracker will MIME parse what we can MIME parse. For example filenames and Exif data of attached images is stolen out of the cached items, to be made searchable. We don't want to require Evolution to eat all the code involved in indexing massive amounts of file formats. Best thing we can do right now is to simply pass the filenames over IPC. We STRONGLY recommend to the Evolution team to: a) migrate away the IMAP specific data cache (see c to store separate parts) I thought we already store parts separate. Is is just about the encoding or more than that? I seriously don't have an idea on this. May be Fejj, Sankar, Matt can add on it. b) migrate away the mbox data cache (the all-in-one file crap) I'm all for it. Once I thought of doing this, but the options were like Maildir or a format of one mbox file per mail in a distributed folder [CamelDataCache sort of format, like imap4/GW/Exchange]. But IIRC Fejj, had some concern like, Local still might be good to be held in a 'standards' way. I know it hurts us on expunge/mailbox rewrite etc. And to c) invent a better storage format that doesn't store the attachments in server's (usually) Base64 encoding. The one format to rule them all. Instead store the encoded attachments in decoded format (original file format). This will reduce diskspace (encoding increases diskspace usage) and will make it more easy to scan the original file for XMP and Exif information. Don't try to gzip or whatever anything. None of that makes any sense (original files are usually compressed ideally already). For example: devices that want to compress have filesystems that do this for you. Don't be silly trying to do this yourself. By storing the encoded version the only thing you currently gain is that the feature view E-mail source doesn't need to recode the attachments. This ain't a much-used feature. It doesn't have to be fast, at all. No it doesn't. Really it doesn't. Is thatz it? I need some other opinions, I don't have much thoughts here. Sankar, Matt, Fejj? For Maildir I recommend wasting diskspace by storing both the original Maildir format and in parallel store the attachments separately. Maildir ain't accessible by current Evolution's UI, by the way. For MBox I recommend TO STOP USING THIS BROKEN FORMAT. It's insane with today's mailboxes that easily grow to 3 gigabytes in size per user. I second your thoughts for MBox stuff. Once all start using the CamelDataCache API, implementing that new format and implementing converters wont be very hard. For existing CamelDataCache users it's just one format to convert. For IMAP, mbox, Maildir and mh it's indeed a few extra formats to handle using a conversion. Wont kill you to implement that, and, I'll help. Thatz so nice of you to help us :-) -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] State of the Bonobo removal effort for Evolution
On Mon, 2008-11-17 at 01:36 -0500, Matthew Barnes wrote: Hi folks, One of the goals for Evolution 2.26 is to finally remove the use of Bonobo and BonoboUI from Evolution [1] in favor of equivalent functionality now provided by the GTK+ stack. This is happening in parallel with Ross Burton's effort to port Evolution-Data-Server from using Bonobo to D-Bus as the communication medium. The two efforts are, at this point, still progressing independently. I've been working on removing Bonobo from Evolution since late August and have been publishing my source code changes to a Subversion branch named kill-bonobo [2]. I've also been maintaining a wiki page by the same name [3] with screen shots and somewhat regular updates, though the updates tend not to go into much technical detail. With the U.S. on daylight savings time now, our weekly IRC meetings are at 05:00 EST and, not being much of a morning person, I've been waking up in time even less frequently than I did when they were at 06:00 EST. So I feel like I've been a little incommunicado lately about how things are progressing. I hope to correct that with this, the first of a series of postings about where things stand and also some technical details about the direction I've taken with the newly-rewritten EShell. The wiki page [3] already has a brief overview of the new shell design, along with a link to some incomplete and slightly out-of-date API docs for it [4]. I'll try to improve the completeness and quality of the documentation over the next week. So, for the remainder of this first post I'll cover schedule. Is this going to make it in time for 2.26? Short answer is: I still don't know. Red Hat was gracious enough to allocate two months for me to work on this full time. In that time I managed to complete the new EShell, more or less finish the Contacts, Tasks and Memos modules, and get a good start on the Calendars and Mail modules. But with November already here I'm obligated to focus on other issues of interest to Red Hat during business hours, which leaves evenings and weekends (when I can find time) to work on this. Suffice it to say, progress has slowed. Unfortunately, no matter how much I test the kill-bonobo branch beforehand, the truth is when we finally do merge it to trunk there _will_ be regressions. Lots of 'em. Hopefully no major show-stoppers but lots of little things I missed. The scope of the changes here is simply too massive for me to catch everything. Heck, I'm still fixing little bugs I missed in the composer rewrite from earlier this year and that was of much smaller scope than this. We'll need a few months of heavy testing and bug reporting from developers and interested members of the community after the merge and before the stable release date. So, I've drawn a line in the sand: 2.25.3. If the merge doesn't happen in time for that release, which is scheduled for mid-December, I'm inclined to re-target the feature to 2.27.1. As I said, at this point I don't know if I'm going to make it in time. There's still a lot of work left. Finish the Mailer and Calendar for starters, and then go through and rework most of the plugins (EMenu and EPopup are going bye-bye). Plus I have a TODO list a mile long of loose ends I have to go back and address. Evolution-Exchange will likely need some rework, though to what degree I'm not yet sure. And I also don't know what impact all this will have on the MAPI work. It's getting there. Just not as fast as I would've liked. In the next posting I'll talk about the new shell design and touch on some of the things it now handles for you that the current shell does not. If you have questions, suggestions or concerns, please don't hesitate to shoot me or the list an email. After all, I'm writing this in hopes of getting some feedback. Thanks for the great update on this Matt. Its going to be a tough time for many of us for the next couple of months. That's one reason, I asked you to look at Camel/Gobject stuff for 2.27.x. May be, we have too many things to do, which would take more than a 6-month cycle? May be a bigger GNOME 3.0 schedule might fit us well to revamp most of Evolution [Split it, Kill bonobo, Write Accounts well etc]. Anyways, just some thoughts. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GObject-based Camel
Hey Matt, On Sun, 2008-11-09 at 12:52 -0500, Matthew Barnes wrote: Over the weekend I hit a milestone with a science experiment I started earlier in the year to turn Camel into a GObject-based library with minimal API breakage. The short-term goal of this effort is to make it easier to generate language and D-Bus bindings for Camel. This is awesome news :-). I now have running code which I've posted to a new evolution-data-server branch called camel-gobject [1]. The branch contains a couple very small patches (evolution.patch and evolution-exchange.patch) that must be applied before building Evolution against the GObject-based Camel library. Evolution seems to be working just fine with my standard setup, but I haven't tested all the built-in Camel providers and various third-party extensions. If others want to chip in with the testing I'd be grateful. Techie Details -- My approach was basically to pull off the same stunt that was done to GtkObject when GObject was introduced: turn the base CamelObject class into a GObject subclass, and convert the CamelObject API into a set of thin wrappers for equivalent operations in GObject. For example: camel_object_ref() now calls g_object_ref() camel_object_unref()now calls g_object_unref() camel_type_register() now calls g_type_register_static() ...etc... Obviously this breaks Camel's ABI. There's no way around that. I think, you are correct. This needs to happen at some time. The (intentional) API breakage is very minimal: CamelType is now an alias for GType. It is no longer a pointer to the class structure. That was supposed to be an implementation detail anyway, but Camel (and Evo, and Evo-Exchange) exploits that in a number of places. The class structure can be properly accessed using camel_type_get_global_classfuncs(), which is now an alias for g_type_class_peek(). The corollary to that is when to fetch the parent class structure. Most classes define a static parent_class pointer for chaining up in class methods. The parent_class pointer should be set in the class initialization function, NOT before the type registration in get_type(). Just like you would in normal GObject code. There were LOTS of places in Camel were that needed fixing. Camel interfaces are dead, but they were never really used anyway. The other half of the problem was CamelObjectBag. It formerly shared a mutex with CamelObject's reference counting, I think because CamelObject ref's and unref's were non-atomic. GObject's reference counting is atomic, so with that issue out of the way I gave each CamelObjectBag its own mutex, cleaned up the code a bit, and split it off into a separate source file (camel-object-bag.c). After an evening's worth of debugging it seems to be working fine now. Now What? - So with the interesting part now done, next comes the long and tedious part: rewriting all the internal CamelObject boilerplate into GObject boilerplate and making sure we're not using any newly deprecated API. But that can be done gradually and with help from others. In time I'd also like to explore taking greater advantage of GObject signals and properties in Camel, and also deprecating CamelArgV and CamelArgGetV. Also the Camel Events to GObject signals right, or you meant the same? I haven't discussed this with the other Evolution/Camel developers yet, so there are currently no plans to include it in 2.26. That may change, but for now it remains purely experimental. 2.26 might be a very tough one, with Kill-Bonobo also in, we may have too many things to shape up. Matthew Barnes [1] http://svn.gnome.org/viewvc/evolution-data-server/branches/camel-gobject/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Too many open files for folders.db
Jeff, This should be fixed in stable as of last wednesday or so. -Srini. On Mon, 2008-10-13 at 11:45 +0800, Jeff Cai wrote: Whenever you click a folder, the folders.db will be opened once. So if you run Evolution for a while, you will find dozens of file handles of folders.db. Is this a bug? or is it expected behavior? In Solairs, the default open file limit is 256, while in Linux is 1024, so the error is easily produced in Solaris. Can Evolution share the same file handle to folders.db? or can the handle be closed if you switch to a new folder? Thanks ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
Rob, IIRC, I had replied to Ross on a similar query, start GNOME 2.24. Still OpenSUSE ships with in-built libdb. I'm not aware of any other distro. JPR, who use to maintain Evolution few years back, gave me the notes on why it was decided to go this way (forking libdb). So if we have answers for all those points, I'm fine for that. We don't want to break anything thatz fine otherwise. I'm not tracking libdb at all, if you have the answers, then lets recalculate and plan for it in 2.26. -Srini. On Mon, 2008-10-06 at 14:59 +0100, Rob Bradford wrote: Since we're at the start of the cycle shall we go ahead and drop the included libdb ? and thus add a formal requirement on using the system version. AFAIK all the distributors ship with using the system version... I've updated the bug #410164 with a patch that makes this change. Regards, Rob ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ---BeginMessage--- Ross, I had a chat with JP and He pointed me to a old README. === The issue was around no backwards compatability, from the old README: - Berkeley's libdb - 3.1.17 db3 is available from http://www.sleepycat.com. Make sure to get 3.1.17, it isn't the latest version. --- IMPORTANT WARNING --- The on-disk format of DB files has been changing between versions 2, 3 and 4. Also, because of the libdb API, there is no way to easily handle the different formats from within the application. For this reason, Evolution has chosen to use one specific version of the library (version 3) and stick to it, so that users do not need to convert their addressbook files to use them with different version of Evolution. That's why Evolution REQUIRES libdb 3.1.17, and NO OTHER VERSION. If you force the check to accept a version different from 3.1.17, your binary of Evolution will be using a different format from the chosen one; this means that it will not be able to read addressbook databases created by other versions of Evolution which were compiled in the standard way. Also, we DO NOT GUARRANTEE that Evolution will work with different versions of libdb at all, even if it can be trivially made to compile against them. SPECIAL NOTE FOR BINARY PACKAGERS: If you are making binary packages for end-users (e.g. if you are a distribution vendor), please statically link Evolution to Berkeley DB 3.1.17, as mandated by the configure.in check. DO NOT patch configure.in to work around the check. Forcing the check to link to a different version of the library will only give headaches and pain to your users, who will see their addressbook disappear and will complain to us (the Evolution team) about losing their data. Besides, libdb will be linked statically, which means that your distribution doesn't actually need to ship DB 3.1.17 itself separately. The Evolution team will be infinitely grateful for your co-operation. Thanks. This proved quite painful for distros (hanging on to a specific version) though so we moved it inside e-d-s eventually. That way we always had a known quantity. === Ross, if we have an answer for this, we can close on this immediately. -Srini. On Fri, 2008-04-25 at 08:46 +0530, Srinivasa Ragavan wrote: Ross, IIRC, it was done because, every libdb update broke Evolution or libdb wasn't so stable release over release. Also OpenSUSE uses statically linked libdb. But most of the hackers I know, dynamically link libdb. I'm favor of the change. But lemme ping some old evolution hackers who were part of this change, to understand what they feel about it. -Srini On Thu, 2008-04-24 at 14:42 +0100, Ross Burton wrote: Hi, I think that we should remove the fork of Berkeley DB from the Evolution Data Server source. Debian, Ubuntu, Gentoo and Fedora all use --with-libdb to dynamically link to a system library, so it is known to work. This would involve removing libdb from svn, and always dynamically linking to libdb instead. --with-libdb would still exist for people who want to use a custom libdb, but it would default to /usr. Thoughts? Ross ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ---End Message--- ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] EDS ABI changes in 2.24?!
On Sat, 2008-10-04 at 10:57 +0200, Patrick Ohly wrote: Can such ABI changes please be discussed on this list? I'm interested to hear about them beforehand and won't notice them if they are only discussed on IRC or in a bug tracker entry; there may be others in the same position. Thanks! Sure. I would make sure that such things come up on the list here-on. Infact I'm doing it for Camel for 2.24. In 2006 Michael Meeks wrote on this list that I -thought- we had some agreement written in blood that the e-d-s ABI was now frozen. and in the camel Bugzilla entry #543389 Srinivasa again confirmed that we support libebook/libecal as supported APIs. Does that include libedataserver? That library is necessary when handling more than just the default data sources because it provides the e_source_* calls. Therefore I consider it part of the libebook/libecal API - agreed? I think I agree to that. Just that it wasn't explicit. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution 2.24 released
Hello Everyone, The Evolution Team is pleased to announce the release of * Evolution 2.24.0 * Evolution-Data-Server 2.24.0 * GtkHTML 3.24.0 * Evolution Exchange 2.24.0 * Evolution-sharp 0.18.0 You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.24/gtkhtml-3.24.0.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/2.24/evolution-data-server-2.24.0.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.24/evolution-2.24.0.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.24/evolution-exchange-2.24.0.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-sharp/0.18/evolution-sharp-0.18.0.tar.bz2 What is in 2.24? Message Templates WebDAV Contacts support Google Contacts support Custom header support while sending mails Single Model view for Calendar Sqlite Based message summary (aka Camel On-disk Summary) New Bonobo-less composer for Evolution Quota support to IMAP/POP accounts Gtk+ Recent manager integration in Composer Contact-list for Exchange and 530 bugs and approximately 50 crashers fixed. Thanks to all who contributed to the Evolution 2.24 release. Known Issues The new sqlite based message summary might have some performance/mismatch count issues in 2.24.0. We are working hard to fix all of them in 2.24.1. Please report such issues to bugzilla and add as a dependency to http://bugzilla.gnome.org/show_bug.cgi?id=543389 meta-bug. == Reporting Bugs == If you have problems with 2.24.0, please take the time to submit the bug using Bug Buddy or at http://bugzilla.gnome.org. Try to fill in as much detail as you can regarding the circumstances that lead to the problem. Kindly check if your bug has been reported before by using the search functionality of Bugzilla. More information is available at the project website http://www.gnome.org/projects/evolution and the project wiki : http://go-evolution.org/ -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI Exchange Connector will replace current Exchange connector?
On Wed, 2008-09-24 at 16:26 +0800, Jeff Cai wrote: Hi, I have two questions on MAPI Exchange connector. 1. When will MAPI connector officially become one part of Evolution? By 2.26 it should become official. We are working out the licensing part. 2. If MAPI connector is in, will the current Exchange OWA connector be removed? or they will both exist? I doubt, if OWA will be removed. But atleast won't be the default, given that MAPI connector will work from Exchange 5.5 onwards till Exchange 2007. My strong feeling is that we would still support/ship OWA connector, but may not attract much new features or great attention etc. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [opensuse-gnome] Evolution 2.22 for Factory
HPJ, HPJ, the summary can't be named like this, since, its possible that something like this already exists. .ibex.index has a traditional meaning and would be more of abusing it in the newer versions. Wouldn't it be possible to use a different directory, e.g. mail/local-index/folders.db? That would avoid both problems. You end up seeing a new folder local-index in 2.22/older and a folders.db folder under it. :( FWIW, I did give it a try, during the initial phases, but I abandoned it, since I was short of time. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [opensuse-gnome] Evolution 2.22 for Factory
Hello Guys,
On Fri, 2008-09-19 at 22:14 -0500, Hans Petter Jansson wrote:
[ Adding evolution-hackers to Cc since this contains potentially useful
feedback and some questions ]
On Fri, 2008-09-19 at 18:06 +0100, Michael Meeks wrote:
On Fri, 2008-09-19 at 00:40 -0500, Hans Petter Jansson wrote:
Note 2: If you ran the newer version of Evolution previously, you should
delete the sqlite database it creates before reverting to the old one -
otherwise it will think the sqlite database is an mbox and try to index
it, which will cause errors. Delete ~/.evolution/mail/local/folders.db*.
That - is really bad. Can we not name our db in some way that this
doesn't happen ? is there really no solution here ? if not, why are
these databases in a place where older versions get confused start
doing stupid things ? - can we not put them somewhere else ?
Michael, Its n't possible to keep it there still not findable by the old
version. AFAICS, { .msf, .ev-summary, .ev-summary-meta,
.ibex.index, .ibex.index.data, .cmeta, .lock } are the possible
extensions that the old version of Evolution ignores. But these have
definite meanings and possible they exist as locks, metafiles or
old-type-summaries. Naming the new summary that way would probably erase
the real data.
That's a question for the Evo team, I guess - it looks like it could be
trivially fixed by moving the folder.db somewhere else, or calling it
folder.index or folder.ibex.index or whatever Evolution traditionally
filters out.
HPJ, the summary can't be named like this, since, its possible that
something like this already exists. .ibex.index has a traditional
meaning and would be more of abusing it in the newer versions.
To Evolution's credit, my 500MB folder.db binary blob didn't cause it to
crash - it showed up as a bogus local mail folder after about 15 minutes
of disk churn - but it did throw errors whenever it needed to pull data
for vfolders.
But, the old version shouldn't touch the folders.db automatically,
meaning the new summary would be safe, unless the user manually deletes
or adds mails to it.
Also, it looks like old summary/index files aren't removed - does it
require both the sqlite database and summaries now? It increases disk
space consumption quite a bit.
That is left purposefully. Incase you are a user switching across
versions, probably you would have to recreate summaries every time you
do. But first time, we just migrate and don't care later on. So if you
aren't a user of that category, a rm of it manually should suffice.
[probably some more summaries left on the other accounts]
Switching between versions, should work right ?
Michael, AFAICS, it should work fine, we don't touch old summaries
written by old version. If it happens, file a bug (I dont think it
happens ):-) Just that the old version reports you of a new folder
folders.db.
Should we ship a patch for older Evolution versions to ignore
folders.db? May be worth for power users of SLEs and RHEs, who might
still use older version new version.
-Srini
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] bug fixing in stable 2.22.x branch
On Wed, 2008-09-03 at 09:18 +0200, Frederic Crozat wrote: Le mardi 02 septembre 2008 à 14:43 +0530, Srinivasa Ragavan a écrit : On Tue, 2008-09-02 at 09:23 +0200, Frederic Crozat wrote: Le lundi 01 septembre 2008 à 19:55 +0200, Patrick Ohly a écrit : On Thu, 2008-08-21 at 12:37 +0530, Chenthill wrote: Thanks, I will send out a mail to the list mentioning the critical fixes which have gone in recently in the stable branch which needs to be taken into the distro's. Bug #548268 is in trunk (thanks Chenthill!) and tested automatically now. The test showed that the time zones in South America and Australia were also affected. I think we should send out that bug list to the distributors ASAP. Debian Etch is already frozen. Chenthill, do you have the list ready and can you send it both to this list and the distributor list? My own proposal for inclusion are * 548268: time zone conversion incorrect * 546934: [Exchange Connector] contact change tracking is broken (required by SyncEvolution) * 499932: [Bug 499932] Not deleting from e-mail server after specified time Frankly, I think it would be much better to do a 2.22.x release for the needed fix : you'll get updated translations as a bonus and distributions might be more willing to push it, rather than try to apply a list of patches. I think this should be discussed at d-d-l/release-team than lowering it to Evolution/any-other-project. We currently follow GNOME cycle, as you know. Unless we hit to a serious issue, you will be always be the waiting for a release, where as developers would waiting for a more better time to do it. I was just talking for this particular list of bugs, not in general. Ah ok. Eog or gthumb have been doing additional releases after the .3 release for quite some time. You could also delegate the release process to other people who would be willing to take care of it. Its just not about the the 3 hour release/tarball/sanity. But the amount of extra effort we put to review patches for stable, etc. Anyways, I think if more and more people ask for it, lets see if we can work out a schedule post .3. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI backend
On Tue, 2008-09-02 at 19:47 +0200, Patrick Ohly wrote: On Tue, 2008-08-19 at 20:22 +0200, Patrick Ohly wrote: I don't have root access, therefore I compiled all the required components (Samba, libmapi, EDS, Evolution) from source. I haven't tried to run it yet. I'm on Exchange 2007 now. Setting up the MAPI backend worked, but I had to patch the source to get past a calendar authentication problem [1]. Afterwards I could see some events, but not all. It seems that recurring meetings are not yet supported: these seem to be the ones that I'm missing and creating one anew leads to an unspecific error message. I need the MAPI backend primarily for calendars. As it is now I cannot use it (most of my meetings are recurring), so I'll have to depend on OWA for the time being. FWIW, I also had other problems (I don't plan to file bug reports for those because I assume that it's too early for that): * the character set for emails were detected incorrectly, thus displaying emails with English text with Chinese (?) characters * After fixing the calendar authentication problem, LDAP started to show signs of life on the console: for over an hour before I left I saw log messages about LDAP contacts being downloaded continuously. I considered killing it as it seemed to download all contacts, but I decided to give it a chance - perhaps it'll stop eventually by itself. In the GUI I haven't been able to get any results so far (another important usage for me). Patrick, The current, MAPI branch, has the hacked up GAL implementation from the evolution-exchange project, which uses ldap, but runs standalone in e-d-s, unlike the other one. Ideally, we must be doing GAL based on libmapi's nspi interface to browse/populate GAL. Then we would be able to do faster lookup, better cache resync, delta fetc etc. But, its again huge effort, so just waiting to get the current one out with the old GAL and take this up later. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] bug fixing in stable 2.22.x branch
Patrick Evolution follows GNOME release cycles, which has just three dot releases on the stable branch (2.22.3). And after that only for DoS/Vulnerability fixes there will be dot releases. Distros shipping 2.22.x will pick patches from trunk/2.22.x and apply as and when required. (Atleast for OpenSUSE, I/my team does that). Im sure Ubuntu/Fedora too does the same. If it is a really issue, may be mailing the distributors list on picking some patches for Evo/Eds may help. -Srini. On Tue, 2008-08-19 at 18:41 +0200, Patrick Ohly wrote: Hello, I have a question primarily to the maintainers of the various Linux distributions which include Evolution 2.22.x (Ubuntu 8.04 LTS, Debian Lenny), but also to the Evolution hackers: the latest stable release, 2.22.3.1, still contains bugs. There are different ways to deal with this: 1. Evolution upstream continues to apply bug fixes to the 2.22.x as long as important distributions use that. 2. Maintainers of packages apply patches locally, without or with help by Evolution upstream. Upstream could help with bug tracking. What's the current practice? It seems that upstream has already stopped updating the 2.22 branch and bug fixes are only applied to trunk [1]. I'm bringing this up because at least one of the bugs will become critical in September: as noted this week [2], the conversion of system time zone information into libical time zone information (as used by Evolution) yields an end of summer time which is one week too early for Western Europe. It might also be incorrect for other countries and for the beginning of summer time. That's particularly disappointing because the work on improving time zone support [2] was supposed to solve such issues. Now it looks like Evolution will fail to display events at the right time - once again! In addition to this problem I'm sure there are other bugs which could be included in another 2.22.x release. The broken Exchange Connector contact change tracking [1] is one example. [1] http://bugzilla.gnome.org/show_bug.cgi?id=546934#c2 [2] http://bugzilla.gnome.org/show_bug.cgi?id=548268 [3] http://www.estamos.de/blog/2008/06/22/time-zone-handling-in-evolution/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] make dist error in evolution-data-server
On Wed, 2008-07-30 at 10:49 +0800, Jeff Cai wrote: Gilles Dartiguelongue wrote: Le mardi 29 juillet 2008 à 14:09 +0800, Jeff Cai a écrit : $make dist make: *** No rule to make target `intltool-merge.in', needed by `distdir'. Stop. I'm curious about how you make it work. either it's missing in EXTRA_DIST or you need to run intltoolize --force (or just use autogen.sh, it does all the dirty first run things) intltoolize --force can not produce those files. Srini, how did you produce the tar ball at the release time? I checkout from svn, do a complete autogen.sh, make install and then I do a make dist as everyone. I have never faced it anytime. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] how to send emails from the terminal?
Oh I meant that the current code doesn't support for doing it for contact list. Since the contact lists are loaded on autocompletion only, though expanded during send. -Srini. On Thu, 2008-07-24 at 19:11 -0500, irving vladimir wrote: yes it is possible, for example I have a list called irvings which contain my three email addresses from different accounts, so when I type manually irvings in the 'To' field it appear underlined and with a coma ( , ) in the end, then when I send it arrive to my three accounts, but this not happen when I do it from the command line since the list-name irvings not appear underlined thanks. 2008/7/20 Srinivasa Ragavan [EMAIL PROTECTED]: I dont think it is possible to send it to a evolution specific contact list. The TO/CC/BCC is expected to be exact. -Srini. On Sat, 2008-07-19 at 17:41 -0500, irving vladimir wrote: Hi, when I try to send a message from the comand line I do: evolution mailto:[EMAIL PROTECTED]subject=hibody=something where 'name-list' is the name of a list of contacts that I have created. The problem is that the message never arrive to anybody. I have see that when I type the name of the list manualy the name appears underlined and when I send it the message arrive to everybody. I wish to know how to send the message from the comand line to the list of contacts that I have created withoutd having to write it manualy. thanks. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers -- irving vladimir ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] how to send emails from the terminal?
I dont think it is possible to send it to a evolution specific contact list. The TO/CC/BCC is expected to be exact. -Srini. On Sat, 2008-07-19 at 17:41 -0500, irving vladimir wrote: Hi, when I try to send a message from the comand line I do: evolution mailto:[EMAIL PROTECTED]subject=hibody=something where 'name-list' is the name of a list of contacts that I have created. The problem is that the message never arrive to anybody. I have see that when I type the name of the list manualy the name appears underlined and when I send it the message arrive to everybody. I wish to know how to send the message from the comand line to the list of contacts that I have created withoutd having to write it manualy. thanks. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] camel-db-summary changes merged to Trunk
Jules, We would bump the camel version numbers, not sure why e-d-s. pc. Also, I might take some time to do it, things broken and me/sankar are really busy. -Srini. On Wed, 2008-07-16 at 16:12 +0200, Jules Colding wrote: On 16/07/2008, at 20.33, Sankar wrote: Hi , As many of you know, Srini and I were working on a branch camel-db-summary (codenamed Madagascar). This is now merged with trunk. Please see http://svn.gnome.org/viewvc/evolution-data-server?view=revisionrevision=9125 Will you increment Version: in evolution-data-server-1.2.pc, please? Thanks, jules ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] today's evolution userdocs update.
Updated tarball at http://ftp.gnome.org/pub/GNOME/sources/evolution/2.22/evolution-2.22.3.1.tar.gz Unfortunately, this passed my make distcheck and our QA's build sanity test won't capture this, which sort of made it difficult to catch it before the release. -Srini. On Mon, 2008-06-30 at 15:29 +0200, Andre Klapper wrote: Dear Evolution Team. Thanks for not testing the integrity of the changed userdocs file. Thanks for removing too much markup, though required to compile. Thanks that this means 2.22.3 does not compile out of the box, see http://bugzilla.gnome.org/show_bug.cgi?id=540918 . Thanks for not testing the tarballs you release. It's not the first time. Thanks for getting the docs update committed to svn 5 hours before tarballing, so no translators could update their translations. Again, thanks for not proofreading anything in evolution.xml - thanks for keeping the error rate constant, and people in work. Translators love to update their translations frequently everytime you commit some spelling fixes and introduce some new ones. I'm pretty fed up with wasting my time and repeating the same stuff over and over again, and getting answered that it won't happen again. Now one may come up with other conclusions, but Novell IS capable to handle the user docs. I was told that in http://bugzilla.gnome.org/show_bug.cgi?id=435942#c41 . That is a good feeling that lets me sleep warm and comfortable, without any worries. So long, and thanks for all the fish. Yours sincerely, andre ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI branch status?
On Tue, 2008-06-17 at 08:50 +0530, Suman Manjunath wrote: On Mon, Jun 16, 2008 at 6:26 PM, Srinivasa Ragavan [EMAIL PROTECTED] wrote: Andre, the development is on track and we are moving inline with the libmapi-0.7. Some things are pending/in-progress are snip (*) free busy lookup Oops, Sorry I meant Creating Meetings -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI branch status?
On Mon, 2008-06-16 at 12:45 +0200, Andre Klapper wrote: Hi Evolution team, can somebody please update me/us about the current state and plans for the Evolution MAPI branch? Andre, the development is on track and we are moving inline with the libmapi-0.7. Some things are pending/in-progress are (*) mime parsing (*) free busy lookup (*) Delta fetching for addressbook. So the provider as a whole is sort of ready to use, but lots of minute things like these are really taking time, also due to tight schedule of libmapi also we had to post pone/wait till they get available. Haven't seen a lot about this in the last weeks and would be interested to know about potential problems and whether we can except this to be included in GNOME 2.24 (customer expectations; GNOME release notes; blah). As of now, we know Evolution needs to move to a GPL V3 compatible license and we had made a proposal to the legal team, and it seems to take lot of time due to the effects it can cause. Lots of things like copyrights, etc are being analysed and it is approaching the end point, but not yet there :( I'm not very hopeful for GNOME 2.24, which is just a month or so away from freezes. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] time zone problem: extending API in stable branch?
Patrick, Can you just point us to the right patch, that extends API ? I seem to hit the wrong patch. I dont see any .h changes also. Is there a way, we can work around for stable branch alone? We may need release team approval, if we have to update API (I guess so, though EDS isn't part of platform, we may have to atleast check with them) -Srini. On Thu, 2008-06-12 at 22:25 +0200, Patrick Ohly wrote: Hello, the patch that I am suggesting to fix the time zone issues in Evolution (see http://bugzilla.gnome.org/show_bug.cgi?id=528902) adds new functions to libecal. Note that the extended library is backwards compatible, i.e., this is not an API change which requires recompiling other programs (http://bugzilla.gnome.org/attachment.cgi?id=112638). Is this an acceptable solution for the 2.22.x stable branch? Chentill reviewed the patch and agreed to committing it on trunk after some minor changes (which I have done in the meantime), but he is concerned about the API and rather would like to keep this out of the stable release. I'm writing here to also get the opinion of Evolution packagers who might not monitor the discussion taking place in the bug tracker. Is this issue important enough to extend the API in the next 2.22.x release? If Evolution upstream doesn't include it in 2.22.x, are distributions going to apply the patch (it is written against the stable branch and applies cleanly) anyway? I personally think that this is important because Evolution will continue to use out-dated time zone definitions for new meetings in perpetuity unless people wipe out their old calendars or the patch is applied. Quoting Paul Smith, who missed a meeting this spring due to this bug: I have to add my voice to those saying please, please, PLEASE someone fix this complete and utter disaster! ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution and ldap contacts
On Fri, 2008-06-06 at 11:17 +0200, Thomas Vander Stichele wrote: Hi, I've been trying in my spare time to dip my feet in the LDAP contacts backend because, well, there's lots of stuff that it does wrong for me to the point where it's close to unusable in my real life use. I'm starting small, and I have some questions that I've already asked various people IRL or on IRC, but nobody seems to have a good idea, so I thought I'd join and ask here instead. 1) Does anyone know why the LDAP backend first does an anonymous bind (which my servers for obvious reasons don't allow) to decide if the server is up at all ? I don't see the point of not using the credentials configured here. If the credentials are there already, it may not make sense to do a anon bind. But I donno much history behind the code there. 2) Is there anything in evolution checeking the GNOME_Evolution_Addressbook_CallStatus returned from some of the calls ? It is hugely annoying to not have any clue at all *why* a contact backend fails. It got slightly better in evo 2.22 (which shows Error loading addressbook in the widget you get when you click To/CC/Bcc) but not by much. Where should I go dig in the Evolution code to show some useful error messages because of CallStatus returns ? The best bet is to debug out from EDS. Generic error returns from eds are shown with that message iirc. See where it returns that message and pro'lly you 'll know there. 3) One of the possible reasons of failure for an LDAP backend is not having the certificate installed, which is an especially important part to warn about and provide a solution for. Should I reuse an existing CallStatus (like AuthenticationFailed) or add one for this case ? You can use it. 4) Anyone have an idea why right-clicking on an address in a mail, adding it to addressbook, then selecting an LDAP backend, claims that the backend is readonly, while it works fine when I go to it in the contacts view ? My eds debug console shows no LDAP activity meanwhile, it's not even trying to write to the LDAP server. This is new in 2.22 - I didn't have this behaviour in previous releases. You can look at addressbook/gui/contact-editor/e-contact-quick-add.c:merge_cb that seem to emit the error. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Crasher in evolution-exchange
On Mon, 2008-06-02 at 10:19 -0400, Paul Smith wrote: Hi all; can someone take a look at this bug: http://bugzilla.gnome.org/show_bug.cgi?id=532844 Done. Thanks to Bharath. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] 2.23.3.1 no delete shortcut?
No, It shouldn't. Did I broke something? I definitely hacked some code around delete, but sure that it worked well. -Srini On Mon, 2008-06-02 at 21:56 -0400, Daniel Gryniewicz wrote: Is it my imagination, or does 2.23.3.1 not have any keyboard shortcut for delete? Ctrl-D seems to open a save dialog now, rather than delete. Dan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] 2.23.3.1 no delete shortcut?
But that was added to keybindings section, which was only my commit. -Srini. On Mon, 2008-06-02 at 23:27 -0400, Daniel Gryniewicz wrote: I'm guessing it was revision 35571, which removed accel=*Control*d from ui/evolution-mail-message.xml entirely. This is just a guess, tho. Dan On Tue, 2008-06-03 at 08:32 +0530, Srinivasa Ragavan wrote: No, It shouldn't. Did I broke something? I definitely hacked some code around delete, but sure that it worked well. -Srini On Mon, 2008-06-02 at 21:56 -0400, Daniel Gryniewicz wrote: Is it my imagination, or does 2.23.3.1 not have any keyboard shortcut for delete? Ctrl-D seems to open a save dialog now, rather than delete. Dan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-data-server 2.23.2 build error: e_file_cache_get_type is not defined
http://bugzilla.gnome.org/show_bug.cgi?id=533780 ? -Srini. On Fri, 2008-05-30 at 12:28 +0800, Jeff Cai wrote: evolution-data-server-2.23.2/docs/reference/calendar/libedata-cal cc -i -xO4 -xspace -xstrconst -xpentium -mr -xregs=no%frameptr -i -xO4 -xspace -xstrconst -xpentium -mr -xregs=no%frameptr -I/usr/include/mps -I/usr/include/mps -Wl,-zignore -Wl,-zcombreloc -Wl,-Bdirect -o .libs/libedata-cal-scan .libs/libedata-cal-scan.o -L/usr/lib -L/usr/lib/mps ../../../../calendar/libedata-cal/.libs/libedata-cal-1.2.so /export/home/caiqm/packages/BUILD/SUNWevolution-data-server-2.23.2/evolution-data-server-2.23.2/calendar/libecal/.libs/libecal-1.2.so /export/home/caiqm/packages/BUILD/SUNWevolution-data-server-2.23.2/evolution-data-server-2.23.2/libedataserver/.libs/libedataserver-1.2.so -ldl -lplc4 -lplds4 -lnspr4 -lsoup-2.4 ../../../../libebackend/.libs/libebackend-1.2.so -lxml2 -lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation -lORBit-2 -lgio-2.0 -lgmodule-2.0 -lgobject-2.0 -lgthread-2.0 -lpthread -lthread -lgconf-2 -lglib-2.0 -R/usr/lib -R/usr/lib/mps creating libedata-cal-scan gtk-doc: Running scanner libedata-cal-scan ld.so.1: libedata-cal-scan: fatal: relocation error: file evolution-data-server-2.23.2/calendar/libedata-cal/.libs/libedata-cal-1.2.so.6: symbol e_file_cache_get_type: referenced symbol not found ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Switching the current folder from a plugin
You need to look at em-folder-tree.c. That holds the code. -Srini. On Wed, 2008-05-28 at 14:58 -0700, Paarvai Naai wrote: Hi all, I'm hoping that somebody on this list will have a quick answer to this question. I am currently writing a plugin that manipulates folders in Evolution. I was able to figure out how to move messages between folders, but was not able to find the required API calls to make Evolution switch the current folder view in the GUI. I'd like the behavior to be as if the user clicked on a folder in the tree. If anyone can point me in the right direction, the help would be much appreciated. Thanks, Paarvai ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Query
Amit, Send a mail to [EMAIL PROTECTED] He shares most of the NOSIP load now-a-days. -Srini. On Wed, 2008-05-21 at 18:20 +0200, Rodrigo Moya wrote: Hi Amit Forwarding your mail to the evo-hackers list, where you'll get a better answer cheers On Mon, 2008-05-19 at 15:53 +0530, amit gupta wrote: Sir, I am a student of B-Tech. My branch is Electronics and Comunication. I want to the Project work on Evolution. I had seen your website site in this site i saw these three things: What do you have to bring to Novell? 1. Original Letter from your HOD stating your name and the duration of the projects if this is an academic project. 2. Novell Open Source Internship Program agreement signed by you and your parent / guardian. One per person. 3. Project specific Copyright Agreement form for each project which has to be filled accordingly and signed. One per person. With these three documents, come to Novell, with the project decided tentatively. I want to know that How can i submit the Project-specific Copyright Agreements Form and where will i found this form in your website? I have two letters one is Contributors Acceptance Letter and second is HOD Letter. I can send signed copy of these two letters. Please give the information about Project-specific Copyright Agreement Form. Thanking you Amit Gupta ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution LDAP backend
On Fri, 2008-05-16 at 08:55 +0200, Free Ekanayaka wrote: Evo ldap backend was nothing but, openldap patched ntlm. But there was no update to it, as most distros patch OpenLDAP with ntlm and ship it. Thanks, do you know of any documentation about using evolution with ntlm? What do you mean by that? -Srini. Ciao, Free ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Loading of Icons in Evolution
On Tue, 2008-05-13 at 18:16 +0530, svalbard colaco wrote: Hi all; Can any one tell me where are the various icons (i.e. .png files ) located in the code? i could find some icons in the following path What icons are n't appearing. Name a few, I can tell you where they reside. -Srini $PREFIX/share/icons/hicolor/24x24/stock/net While some icon cannot be found... Is there any way/ location in which the icons are loaded in Evolution? Any links or pointers in this regard will be of great help. Thanks Regards sv. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] HOW TO HANDLE: Glib-GObject-WARNING :Invalid cast from GdkPixmap to GdkWindow.
I think it was due to some code issues and I remember some one else complained it on a normal case also. See if you have the icons loaded at the right place. -Srini. On Mon, 2008-05-12 at 11:01 +0530, svalbard colaco wrote: Hi all, I've ported my application on DirectFb backend ; It gets rendred fine but some menu icons are not displayed It gives an 'X' for some of the icons in the tool bar and the menu bar. Is it anything to do with the following warning?? How to handle such a warning? What colud be the reason for such a warning? ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] default bug handling policy
Hello Patrick, On Mon, 2008-05-05 at 20:25 +0200, Patrick Ohly wrote: Hello, are bugs discovered on the trunk also fixed on the latest maintenance branch by default or only if someone asks for it? Different projects handle this differently. We backport to stable branch, if they don't break any freezes like UI/String/API/ABI. If we find the fixes a bit risky, we dont put them to stable, or atleast wait for a dot release on the unstable trunk. I personally prefer to apply fixes to the maintenance branch, then port them forward to the trunk automatically. In my experience that reduces the risk of forgetting fixes. But there are valid arguments for both positions; I just want to know where Evolution stands, not start a discussion. Most of the hackers work on the trunk and back port the fixes to stable branch. But user/other-hackers who use stable release make patches on stable release and while committing we forward port to trunk also. I (incorrectly?) assumed that for Evolution patches would be manually applied to all affected and maintained branches, but at least in one case that I just ran into ([1], [2]) this wasn't done. Because I didn't check the code on the trunk I needlessly ended up fixing the memory leak on the 2.22.x branch again. [1] http://bugzilla.gnome.org/show_bug.cgi?id=531197 [2] http://bugzilla.gnome.org/show_bug.cgi?id=523541 May be it is missed or kept pending, other wise I dont see any reason why not to. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libdb from EDS source
Ross, I had a chat with JP and He pointed me to a old README. === The issue was around no backwards compatability, from the old README: - Berkeley's libdb - 3.1.17 db3 is available from http://www.sleepycat.com. Make sure to get 3.1.17, it isn't the latest version. --- IMPORTANT WARNING --- The on-disk format of DB files has been changing between versions 2, 3 and 4. Also, because of the libdb API, there is no way to easily handle the different formats from within the application. For this reason, Evolution has chosen to use one specific version of the library (version 3) and stick to it, so that users do not need to convert their addressbook files to use them with different version of Evolution. That's why Evolution REQUIRES libdb 3.1.17, and NO OTHER VERSION. If you force the check to accept a version different from 3.1.17, your binary of Evolution will be using a different format from the chosen one; this means that it will not be able to read addressbook databases created by other versions of Evolution which were compiled in the standard way. Also, we DO NOT GUARRANTEE that Evolution will work with different versions of libdb at all, even if it can be trivially made to compile against them. SPECIAL NOTE FOR BINARY PACKAGERS: If you are making binary packages for end-users (e.g. if you are a distribution vendor), please statically link Evolution to Berkeley DB 3.1.17, as mandated by the configure.in check. DO NOT patch configure.in to work around the check. Forcing the check to link to a different version of the library will only give headaches and pain to your users, who will see their addressbook disappear and will complain to us (the Evolution team) about losing their data. Besides, libdb will be linked statically, which means that your distribution doesn't actually need to ship DB 3.1.17 itself separately. The Evolution team will be infinitely grateful for your co-operation. Thanks. This proved quite painful for distros (hanging on to a specific version) though so we moved it inside e-d-s eventually. That way we always had a known quantity. === Ross, if we have an answer for this, we can close on this immediately. -Srini. On Fri, 2008-04-25 at 08:46 +0530, Srinivasa Ragavan wrote: Ross, IIRC, it was done because, every libdb update broke Evolution or libdb wasn't so stable release over release. Also OpenSUSE uses statically linked libdb. But most of the hackers I know, dynamically link libdb. I'm favor of the change. But lemme ping some old evolution hackers who were part of this change, to understand what they feel about it. -Srini On Thu, 2008-04-24 at 14:42 +0100, Ross Burton wrote: Hi, I think that we should remove the fork of Berkeley DB from the Evolution Data Server source. Debian, Ubuntu, Gentoo and Fedora all use --with-libdb to dynamically link to a system library, so it is known to work. This would involve removing libdb from svn, and always dynamically linking to libdb instead. --with-libdb would still exist for people who want to use a custom libdb, but it would default to /usr. Thoughts? Ross ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Event handling in Evolution.... Need urgent help
On Mon, 2008-04-28 at 18:41 +0530, svalbard colaco wrote: Hi all; Can any one explain to me how events are handled in Evolution? Do they make use of the libbonoboui wrappers to handle the button events? Sort of: yes. We add the menu items through the xml file and attach call backs to the menu commands in the code. Like if i click on the Menu bar -File menu option-New Mail compose option ; What will be the event called...? Rather wer in the code should i look in for this event handling? Look at shell/e-user-creatable-items-handler.c -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libdb from EDS source
Ross, IIRC, it was done because, every libdb update broke Evolution or libdb wasn't so stable release over release. Also OpenSUSE uses statically linked libdb. But most of the hackers I know, dynamically link libdb. I'm favor of the change. But lemme ping some old evolution hackers who were part of this change, to understand what they feel about it. -Srini On Thu, 2008-04-24 at 14:42 +0100, Ross Burton wrote: Hi, I think that we should remove the fork of Berkeley DB from the Evolution Data Server source. Debian, Ubuntu, Gentoo and Fedora all use --with-libdb to dynamically link to a system library, so it is known to work. This would involve removing libdb from svn, and always dynamically linking to libdb instead. --with-libdb would still exist for people who want to use a custom libdb, but it would default to /usr. Thoughts? Ross ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Request for a new EPlugin hook in composer windowI would like to modify the Evolution Composer windo
Gary, As Andre said, you can see the attachment reminder code/eplug.xml file for the right hooks and extraction of the message. Also, I would like that to be a auto-invoked plugin like attachment reminder rather than the spelling checker which the user would force it. -Srini. On Mon, 2008-04-14 at 15:55 -0400, Gary Ilijevich wrote: Hello, I would like to modify the Evolution Composer window. I would like to add a button to the window that, when pressed, checks the entered text for unallowed words (DirtyWords). I would also like to do this check when the user presses the Send button. Would adding an EPlugin hook to the composer Button bar be the best approach? The only hokk that I found in the source code for the Composer window is in the Attachment bar. Any help would be most welcome. Please respond with any questions/comments. Thanks, Gary Ilijevich [EMAIL PROTECTED] __ More immediate than e-mail? Get instant access with Windows Live Messenger. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Largefile support
On Mon, 2008-04-07 at 13:29 -0400, Matthew Barnes wrote: On Mon, 2008-04-07 at 12:43 -0400, Jeffrey Stedfast wrote: The only 'gotcha' I can think of by enabling it by default is that it might break ABI if old builds were 32bit off_t's (the new off_t's would be 64bit). Oh, and fwiw, looking ahead, it may even be worth changing the public API to take goffset's rather than off_t's if breaking API is acceptable since it will prevent future off_t size issues (since I believe that goffset is supposed to be an int64_t) Yeah, and this would be the opportune time to do that if we're going to (early in the development cycle). Sounds like we should wait to enable largefile support by default until we do the goffset replacement, and then ship both changes at once with a soname bump. If we are looking at this for Camel, we can go ahead and do the soname version along with the change. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] WebDAV Addressbook plugin
Hi Matthias, [Sorry for a late reply again. Busy with a few things here] You patch looks awesome. I think it is very much of good quality and Im positive to take it upstream for GNOME 2.24. Few high level comments, - We like the declarations to be the first in the function rather. - The authenticate may be need to be delayed. e_book_backend_webdav_authenticate_user is where you get the password. It is possible that some wont require authentication and you need to find that emit auth_required. You may need to connect to libsoup session at this point rather than load source I haven't tried it and but first glance seems very positive and we can chat on irc and take this forward. Im fine to take it to trunk at this quality (Pretty good IMO ) and you can fix issues there. Great work. -Srini. On Sat, 2008-03-22 at 00:35 +0100, Matthias Braun wrote: Hi, I just decided to release a first beta version of my evolution-data-server extension for addressbooks on webdav servers. The basics are all working now (it runs fully featured and stable connected to a mod_dav apache here). All that is missing is more testing and the GUI part so you can easily create new addressbooks inside evolution. Feedback would be apreciated. http://kreacher.is-a-geek.net/~matze/webdav_ebook.tar.gz Greetings, Matze ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Content-Disposition for images in the signature
Sorry for the noise, I just saw the bug created by you. Just clearing my mails in a jetlag. -Srini. On Wed, 2008-03-26 at 14:22 +0530, Srinivasa Ragavan wrote: I think, it qualifies to be a bug in bugzilla. (donno if one is there already) -Srini. On Sun, 2008-03-16 at 14:38 +0100, Philip Van Hoof wrote: Hi there, When you add an image to your HTML signature, it'll make the content-disposition attachment and it'll set the filename header. Both actions are incorrect: the content-disposition is inline and there's no need to set the filename header. Both will make E-mail clients like Outlook, but also Evolution itself, think that the E-mail contains an attachment (a file attachment). I have seen Evolution do this wrong for all kinds of inline embedded images, whenever you insert this into your HTML document. This is incorrect behaviour and not conform MIME. ps. For a free software E-mail client, I think the better option is to go with the specifications. That Outlook gets things wrong is not a good excuse. Although I think modern E-mail clients like Outlook are getting this right nowadays. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] WebDAV Addressbook plugin
Wow, this sound way cool. Matze, I'm not on work this week. I will be back next week and will look into your code. Keep up your great work. -Srini. Matthias Braun [EMAIL PROTECTED] 03/22/08 5:05 AM Hi, I just decided to release a first beta version of my evolution-data-server extension for addressbooks on webdav servers. The basics are all working now (it runs fully featured and stable connected to a mod_dav apache here). All that is missing is more testing and the GUI part so you can easily create new addressbooks inside evolution. Feedback would be apreciated. http://kreacher.is-a-geek.net/~matze/webdav_ebook.tar.gz Greetings, Matze ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution/EDS/Exchange/GtkHTML branched for GNOME 2.22
Hello guys, I have branched Evolution, Evolution-Data-Server, Evolution Exchange and GtkHTML for stable releases. The new branch name is gnome-2-22. Have a look at http://go-evolution.org/Evo2.24 for more information on Evolution for GNOME 2.24. Evolution 2.24 code named as Baltra. Thanks Srini. PS: I missed to add e-l and e-h in my original mail. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] compiling Evolution from source: incorrectlypicks up system libs (Bugzilla #518728)
On Sun, 2008-03-02 at 23:02 +0100, Patrick Ohly wrote: Hello, I compiled from source on Debian Etch and noticed that some of the recompiled libs (e.g. libecal-1.2.so) referenced old Evolution libs under /usr/lib. The underlying reason was an unfortunate ordering of link flags. Bug report and patch in: http://bugzilla.gnome.org/show_bug.cgi?id=518728 Can someone from the Evolution developers please review and commit? Thanks! Thanks Patrick for the bug and the timely patch and Matt for your review in time :). -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Spam Improvements Default spam filter
Guys, We have done some pretty good improvements to SPAM filter in Evolution 2.24 (*) White list support (*) Header based filtering (You can check for headers set by SpamPal or SpamAssasin or any such server side spam headers hints). It will be a lot faster, as you decide a spam without downloading the message. Currently we are having SpamAssassin as the default junk filter and I remember lots of people having issues with SA (interms of speed, resources it occupies, memory, processes etc). IIRC some distros already use bogofilter as the default junk filter. I'm proposing to make Bogofilter as the default junk filter for Evolution. Any thoughts to it? -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] caldav library
Knut, I'm not sure what you gonna develop. If you cannot use it fully, you can copy the code/concepts and use it. Look into e-d-s/calendar/backends/caldav -Srini. On Tue, 2008-02-26 at 17:30 +0100, Knut Olav Bøhmer wrote: Would it be possible/easy to use evolutions caldav plugin as a library to my own program? If yes, can someone give me some pointers to some documentation on how to use the library, or give me some hints here? ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] caldav library
On Wed, 2008-02-27 at 13:10 +0100, Knut Olav Bøhmer wrote: Hi, Ok, to be a bit more specific. I just want to open the library (from a lisp program using UFFI) , and use it to communicate with a caldav server (I want to make a web-interface for caldav using.) So I wonder if the functions in the library is documented somewhere. I'm not sure if it uses a underlying library. Or if someone can tell me which functions to use to open a connection to the server, and which functions to do queries to the server to use. I have not programmed C in many years, so it is quite hard for me to start reading the source code. Ah, I'm not the author of it and unfortunately the author (gicmo) is pretty busy on gio/gvfs for GNOME 2.22. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] LDAP Address book patching
George, IIUC, you wanted to implement a LDAP addressbook? Am I wrong? If not, Evolution already has LDAP addressbook support. -Srini. On Sun, 2008-02-24 at 18:11 -0800, George Farris wrote: Greetings, I would like to create a patch to browse the LDAP database when one clicks on the view. Can anyone provide pointers to help get me started? I have a number of customers that are using Evolution and not being able to have the LDAP addressbook act like the Personal addressbook makes them crazy. This is for addressbooks of 200 contacts or less but globally shared. Any pointers of where to start looking in the code would be great. I believe this is a fairly simple thing to implement. I could be totally wrong however. Cheers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] nightly builds of Evolution +testing withSyncEvolution
On Tue, 2008-02-12 at 19:55 +0100, Patrick Ohly wrote: On Mon, 2008-02-11 at 15:32 +0530, Srinivasa Ragavan wrote: On Sun, 2008-02-10 at 12:18 +0100, Patrick Ohly wrote: I wonder whether this regular building and testing is of interest to anybody else? The build script sends out a short summary email which links to full logs for each night; I could easily add other recipients. For the Evolution build these include the changes since the last build. I think it may prove very helpful in the long run, where some commits cause some side effects, which we may not easily identify in normal cases. But the test script gotto be foolproof to make this really useful. They have worked fine so far. I'll see how it'll go in the future. Are there other tests of the EDS API which I should run? If Novel already does regular testing this probably isn't needed. AFAIK, we don't have much automated tests except the tests under the respective folders. Akhil, correct me if I'm wrong. Patrick, if your test script could cover some cases from those test files also, it will be really useful. I can run make check after a build. Are all tests going to be run by that? I doubt, if that is kept updated to source. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] nightly builds of Evolution + testing withSyncEvolution
Hey Patrick, On Sun, 2008-02-10 at 12:18 +0100, Patrick Ohly wrote: Hello, I finally got all pieces together (in particular most of the recent GNOME libs which are missing in Debian Etch), so now I'm building Evolution trunk each night using Paul Smith's most excellent Makefile [1]. Cool. After each build I then run SyncEvolution tests against the EDS API. These tests cover the synchronous libebook (contacts) and libecal (calendar, todos, memos). My primary motivation is to catch changes affecting SyncEvolution before the release, not after it ;-} Sounds really nice to me. I wonder whether this regular building and testing is of interest to anybody else? The build script sends out a short summary email which links to full logs for each night; I could easily add other recipients. For the Evolution build these include the changes since the last build. I think it may prove very helpful in the long run, where some commits cause some side effects, which we may not easily identify in normal cases. But the test script gotto be foolproof to make this really useful. I'll probably won't be able to check the logs each day, but if I do and find build problems, how should I report them? As entry in the GNOME Bugzilla or an email to this list? Feel free to file bugs on it. Are there other tests of the EDS API which I should run? If Novel already does regular testing this probably isn't needed. AFAIK, we don't have much automated tests except the tests under the respective folders. Akhil, correct me if I'm wrong. Patrick, if your test script could cover some cases from those test files also, it will be really useful. [1] http://mad-scientist.us/evolution.html This is a very nice initiative IMO. Thanks for the trigger. -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
Paul/Per, IIRC Julien mentioned that to use Exchange 2007 against Outlook 2003, the Public Folder store got to be created. Evolution with libmapi would be like a Outlook 2003, connecting to Exchange 2007. It should be click to activate it on the server. If not for Evolution, then it might be asked for Outlook 2003 client to work with 2007 servers. If it isn't there also, we possibly might get a failure during login. -Srini. On Wed, 2008-02-06 at 12:05 -0800, Per Nystrom wrote: On Wed, 2008-02-06 at 14:31 -0500, Paul Smith wrote: On Thu, 2008-02-07 at 00:47 +0530, Suman Manjunath wrote: to be able to use the MAPI plugin, your Exchange mailbox should be enabled for MAPI. this is a setting on the server. it is a common issue to not have it enabled. Curious. Does that mean that Outlook can talk to an Exchange mailbox WITHOUT having it enabled for MAPI? I would like to know more about this. One putative advantage of using MAPI, to me, would be that the corporate IT department wouldn't even know you're using Evolution. They wouldn't have to make ANY changes specifically for Evo users, not even to enable OWA (if they didn't have it enabled already). So, if there are still Exchange mods that have to be made beyond what's needed for Outlook users we should get in front of that I think. Cheers! Agreed. I thought MAPI is the protocol Outlook uses to communicate with Exchange. If this is not the case and there is some other uber-secret special protocol instead, it would behoove us to figure that one out. I don't expect my Exchange administrator to make any special accommodations for me just because I use a different client than Outlook. Thanks, Per ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
I'm pushing an update for the valgrind logs. But for the crash, I need to debug it a bit more with you. We don't have the crash reproducible here. Can chat if not on irc, anywhere else you say is fine. That way, I can fix it faster. PS: My mails to you always bounce back and only the e-h mail comes: My isp ip seems to be blacklisted by your mail server. -Srini. On Tue, 2008-02-05 at 09:14 +, William John Murray wrote: Oops!!! I just updated, and got 20080118.3-4.1 instead of 20080118.3-2.1 But it doesn't seem to change a thing. Bill On Tue, 2008-02-05 at 14:15 +0530, Srinivasa Ragavan wrote: William, If you are on irc, can you ping me 'srag' at #evolution in GIMPNet irc.gnome.org. -Srini. On Tue, 2008-02-05 at 14:00 +0530, Srinivasa Ragavan wrote: William, I would say that, this is really great and useful. I think we would have some(lot ?) work to do with your valgrind report. -Srini. On Tue, 2008-02-05 at 08:08 +, William John Murray wrote: Hi Srini, 'bt' says: |---+ Web Forms : (Container class: IPF.Note 95604A0E) UnRead : 0 Total : 1411 exchange-mapi-connection.c(1631): exchange_mapi_get_folders_list: unlock(connect_lock) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1094719824 (LWP 31444)] 0x003c6ba795c0 in strlen () from /lib64/libc.so.6 (gdb) bt #0 0x003c6ba795c0 in strlen () from /lib64/libc.so.6 #1 0x003c6ea54323 in g_strdup () from /lib64/libglib-2.0.so.0 #2 0x2aaab7b88002 in mapi_folders_sync (store=0x7cf000, ex=value optimized out) at camel-mapi-store.c:972 #3 0x2aaab7b88361 in mapi_get_folder_info (store=0x7cf000, top=0x0, flags=value optimized out, ex=0xd22da0) at camel-mapi-store.c:1057 #4 0x003c83e3cfe7 in camel_store_get_folder_info () from /usr/lib64/libcamel-provider-1.2.so.10 #5 0x2aaab05753e8 in ?? () from /usr/lib64/evolution/2.12/components/libevolution-mail.so #6 0x2aaab0572cda in ?? () from /usr/lib64/evolution/2.12/components/libevolution-mail.so #7 0x003c6ea5cde9 in ?? () from /lib64/libglib-2.0.so.0 #8 0x003c6ea5b2a4 in ?? () from /lib64/libglib-2.0.so.0 #9 0x003c6c606407 in start_thread () from /lib64/libpthread.so.0 #10 0x003c6bad4b0d in clone () from /lib64/libc.so.6 valgrind was impressive. It got past the bug I reported and downloaded lots of emails or headers or some such. Then it crashed (I did not hit any buttons) Here is the end of the output plus crash report: EcDoRpc: struct EcDoRpc out: struct EcDoRpc handle : * handle: struct policy_handle handle_type : 0x (0) uuid : 9d4d2d6c-c40c-4f27-8f8e-a47c3558ec9e size : 0x7fff (32767) offset : 0x (0) mapi_response: * mapi_response: length=4106 mapi_response: ARRAY(4104) mapi_repl: struct EcDoRpc_MAPI_REPL opnum: 0x2c (44) handle_idx : 0x00 (0) error_code : MAPI_E_SUCCESS (0x0) u: union EcDoRpc_MAPI_REPL_UNION(case 44) mapi_ReadStream: struct ReadStream_repl data : DATA_BLOB length=4096 mapi_response: (handles) number=1 handle id: 0x0c30 (3120) length : * length : 0x100e (4110) result : MAPI_E_SUCCESS (0x0) ==31507== ==31507== Invalid write of size 1 ==31507==at 0x4A07678: memcpy (mc_replace_strmem.c:406) ==31507==by 0x12AB4726: ReadStream (IStream.c:199) ==31507==by 0x1287E00F: exchange_mapi_util_get_attachments (exchange-mapi-connection.c:580) ==31507==by 0x1287F2D5: exchange_mapi_connection_fetch_items (exchange-mapi-connection.c:784) ==31507==by 0x12674731: mapi_refresh_folder (camel-mapi-folder.c:522) ==31507==by 0x12674BBD: mapi_refresh_info (camel-mapi-folder.c:136) ==31507==by 0xA9D4972: (within /usr/lib64/evolution/2.12/components/libevolution-mail.so) ==31507==by 0xA9CFCD9: (within /usr/lib64/evolution/2.12/components/libevolution-mail.so) ==31507==by 0x3C6EA5CDE8: (within /lib64/libglib-2.0.so.0.1504.0) ==31507==by 0x3C6EA5B2A3: (within /lib64/libglib-2.0.so.0.1504.0) ==31507
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
==by 0x38053089: run_a_thread_NORETURN (syswrap-linux.c:87)
==31507==by 0x3805326B: vgModuleLocal_start_thread_NORETURN
(syswrap-linux.c:207)
==31507==by 0x3805519D:
(within /usr/lib64/valgrind/amd64-linux/memcheck)
==31507==by 0x38114724:
(within /usr/lib64/valgrind/amd64-linux/memcheck)
sched status:
running_tid=5
Thread 1: status = VgTs_Runnable
==31507==at 0x3C6BACBD66: poll (in /lib64/libc-2.7.so)
==31507==by 0x3C6EA38232: (within /lib64/libglib-2.0.so.0.1504.0)
==31507==by 0x3C6EA38729: g_main_loop_run
(in /lib64/libglib-2.0.so.0.1504.0)
==31507==by 0x3C7EA2CE75: bonobo_main
(in /usr/lib64/libbonobo-2.so.0.0.0)
==31507==by 0x415CFA: (within /usr/bin/evolution)
==31507==by 0x3C6BA1E073: (below main) (in /lib64/libc-2.7.so)
Thread 2: status = VgTs_WaitSys
==31507==at 0x3C6BACBD66: poll (in /lib64/libc-2.7.so)
==31507==by 0x3C6EA38232: (within /lib64/libglib-2.0.so.0.1504.0)
==31507==by 0x3C6EA38729: g_main_loop_run
(in /lib64/libglib-2.0.so.0.1504.0)
==31507==by 0x3C826068C2: (within /usr/lib64/libnm_glib.so.0.0.0)
==31507==by 0x3C6EA5B2A3: (within /lib64/libglib-2.0.so.0.1504.0)
==31507==by 0x3C6C606406: start_thread (in /lib64/libpthread-2.7.so)
==31507==by 0x3C6BAD4B0C: clone (in /lib64/libc-2.7.so)
Thread 5: status = VgTs_Runnable
==31507==at 0x4A059F6: malloc (vg_replace_malloc.c:149)
==31507==by 0x3C6BA69E8C: vasprintf (in /lib64/libc-2.7.so)
==31507==by 0x1311EA78: ndr_print_debug_helper
(in /opt/samba4/lib/libdcerpc.so.0.0.1)
==31507==by 0x13124419: ndr_print_struct
(in /opt/samba4/lib/libdcerpc.so.0.0.1)
==31507==by 0x12AD2708: ndr_print_EcDoRpc (ndr_exchange.c:21889)
==31507==by 0x1311EE0E: ndr_print_function_debug
(in /opt/samba4/lib/libdcerpc.so.0.0.1)
==31507==by 0x12AFA540: dcerpc_EcDoRpc_send (ndr_exchange_c.c:1551)
==31507==by 0x12AFA58D: dcerpc_EcDoRpc (ndr_exchange_c.c:1562)
==31507==by 0x12ABADA2: emsmdb_transaction (emsmdb.c:208)
==31507==by 0x12AB6ACC: Release (IUnknown.c:143)
==31507==by 0x12AB894D: mapi_object_release (mapi_object.c:93)
==31507==by 0x1287DED5: exchange_mapi_util_get_attachments
(exchange-mapi-connection.c:613)
==31507==by 0x1287F2D5: exchange_mapi_connection_fetch_items
(exchange-mapi-connection.c:784)
==31507==by 0x12674731: mapi_refresh_folder
(camel-mapi-folder.c:522)
==31507==by 0x12674BBD: mapi_refresh_info (camel-mapi-folder.c:136)
==31507==by 0xA9D4972:
(within /usr/lib64/evolution/2.12/components/libevolution-mail.so)
==31507==by 0xA9CFCD9:
(within /usr/lib64/evolution/2.12/components/libevolution-mail.so)
==31507==by 0x3C6EA5CDE8: (within /lib64/libglib-2.0.so.0.1504.0)
==31507==by 0x3C6EA5B2A3: (within /lib64/libglib-2.0.so.0.1504.0)
==31507==by 0x3C6C606406: start_thread (in /lib64/libpthread-2.7.so)
==31507==by 0x3C6BAD4B0C: clone (in /lib64/libc-2.7.so)
On Tue, 2008-02-05 at 09:52 +0530, Srinivasa Ragavan wrote:
Hi William,
The trace looks fine, but I'm not able to find any segv or signal
handler call = Not able to find which thread crashed. Just do a 'bt'
Otherwise, it could be a memory corruption, I think.
Can you run like 'valgrind --tool=memcheck evolution' and paste me the
logs?
Sorry for the multiple iterations.
-Srini.
On Mon, 2008-02-04 at 18:19 +, William John Murray wrote:
Hello Suman,
Here is the log. Thank you for looking at this.
Bill
thread apply all bt full
Thread 8 (Thread 1105209680 (LWP 23478)):
#0 0x003dd0ad50d8 in epoll_wait () from /lib64/libc.so.6
No symbol table info available.
#1 0x2aaab3d305e0 in ?? () from /opt/samba4/lib/libdcerpc.so.0
No symbol table info available.
#2 0x2aaab3d31032 in ?? () from /opt/samba4/lib/libdcerpc.so.0
No symbol table info available.
#3 0x2aaab3d2ff42 in event_loop_once ()
from /opt/samba4/lib/libdcerpc.so.0
No symbol table info available.
#4 0x2aaab39ad2ab in dcerpc_request_recv ()
from /opt/samba4/lib/libdcerpc.so.0
No symbol table info available.
#5 0x2aaab39ade40 in dcerpc_ndr_request_recv ()
from /opt/samba4/lib/libdcerpc.so.0
No symbol table info available.
#6 0x2aaab36e45a0 in dcerpc_EcDoRpc (p=0x2aaabc020bd0,
mem_ctx=value optimized out, r=0x41e01ca0) at
gen_ndr/ndr_exchange_c.c:1565
req = (struct rpc_request *) 0xfffc
#7 0x2aaab36a4da3 in emsmdb_transaction (emsmdb=0x2aaabc020c70,
req=0xe1fe50, repl=0x41e01d40) at libmapi/emsmdb.c:208
r = {in = {mapi_request = 0xe1fe50, max_data = 32767, handle =
0x2aaabc020c78, size = 32767, offset = 0, length = 0xe1fdc0}, out =
{mapi_response = 0xe1ff20, handle = 0x2aaabc020c78, size = 14810816,
offset = 0, length = 0xe1fdc0, result = 3016974192}}
multi_req = value optimized out
i = 0 '\0'
#8
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
William, If you are on irc, can you ping me 'srag' at #evolution in GIMPNet irc.gnome.org. -Srini. On Tue, 2008-02-05 at 14:00 +0530, Srinivasa Ragavan wrote: William, I would say that, this is really great and useful. I think we would have some(lot ?) work to do with your valgrind report. -Srini. On Tue, 2008-02-05 at 08:08 +, William John Murray wrote: Hi Srini, 'bt' says: |---+ Web Forms : (Container class: IPF.Note 95604A0E) UnRead : 0 Total : 1411 exchange-mapi-connection.c(1631): exchange_mapi_get_folders_list: unlock(connect_lock) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1094719824 (LWP 31444)] 0x003c6ba795c0 in strlen () from /lib64/libc.so.6 (gdb) bt #0 0x003c6ba795c0 in strlen () from /lib64/libc.so.6 #1 0x003c6ea54323 in g_strdup () from /lib64/libglib-2.0.so.0 #2 0x2aaab7b88002 in mapi_folders_sync (store=0x7cf000, ex=value optimized out) at camel-mapi-store.c:972 #3 0x2aaab7b88361 in mapi_get_folder_info (store=0x7cf000, top=0x0, flags=value optimized out, ex=0xd22da0) at camel-mapi-store.c:1057 #4 0x003c83e3cfe7 in camel_store_get_folder_info () from /usr/lib64/libcamel-provider-1.2.so.10 #5 0x2aaab05753e8 in ?? () from /usr/lib64/evolution/2.12/components/libevolution-mail.so #6 0x2aaab0572cda in ?? () from /usr/lib64/evolution/2.12/components/libevolution-mail.so #7 0x003c6ea5cde9 in ?? () from /lib64/libglib-2.0.so.0 #8 0x003c6ea5b2a4 in ?? () from /lib64/libglib-2.0.so.0 #9 0x003c6c606407 in start_thread () from /lib64/libpthread.so.0 #10 0x003c6bad4b0d in clone () from /lib64/libc.so.6 valgrind was impressive. It got past the bug I reported and downloaded lots of emails or headers or some such. Then it crashed (I did not hit any buttons) Here is the end of the output plus crash report: EcDoRpc: struct EcDoRpc out: struct EcDoRpc handle : * handle: struct policy_handle handle_type : 0x (0) uuid : 9d4d2d6c-c40c-4f27-8f8e-a47c3558ec9e size : 0x7fff (32767) offset : 0x (0) mapi_response: * mapi_response: length=4106 mapi_response: ARRAY(4104) mapi_repl: struct EcDoRpc_MAPI_REPL opnum: 0x2c (44) handle_idx : 0x00 (0) error_code : MAPI_E_SUCCESS (0x0) u: union EcDoRpc_MAPI_REPL_UNION(case 44) mapi_ReadStream: struct ReadStream_repl data : DATA_BLOB length=4096 mapi_response: (handles) number=1 handle id: 0x0c30 (3120) length : * length : 0x100e (4110) result : MAPI_E_SUCCESS (0x0) ==31507== ==31507== Invalid write of size 1 ==31507==at 0x4A07678: memcpy (mc_replace_strmem.c:406) ==31507==by 0x12AB4726: ReadStream (IStream.c:199) ==31507==by 0x1287E00F: exchange_mapi_util_get_attachments (exchange-mapi-connection.c:580) ==31507==by 0x1287F2D5: exchange_mapi_connection_fetch_items (exchange-mapi-connection.c:784) ==31507==by 0x12674731: mapi_refresh_folder (camel-mapi-folder.c:522) ==31507==by 0x12674BBD: mapi_refresh_info (camel-mapi-folder.c:136) ==31507==by 0xA9D4972: (within /usr/lib64/evolution/2.12/components/libevolution-mail.so) ==31507==by 0xA9CFCD9: (within /usr/lib64/evolution/2.12/components/libevolution-mail.so) ==31507==by 0x3C6EA5CDE8: (within /lib64/libglib-2.0.so.0.1504.0) ==31507==by 0x3C6EA5B2A3: (within /lib64/libglib-2.0.so.0.1504.0) ==31507==by 0x3C6C606406: start_thread (in /lib64/libpthread-2.7.so) ==31507==by 0x3C6BAD4B0C: clone (in /lib64/libc-2.7.so) ==31507== Address 0x1FE927D4 is 0 bytes after a block of size 724 alloc'd ==31507==at 0x4A059F6: malloc (vg_replace_malloc.c:149) ==31507==by 0x13149B75: (within /opt/samba4/lib/libdcerpc.so.0.0.1) ==31507==by 0x13149AE4: (within /opt/samba4/lib/libdcerpc.so.0.0.1) ==31507==by 0x1314AC91: talloc_named_const (in /opt/samba4/lib/libdcerpc.so.0.0.1) ==31507==by 0x1287DFE0: exchange_mapi_util_get_attachments (exchange-mapi-connection.c:574) ==31507==by 0x1287F2D5: exchange_mapi_connection_fetch_items (exchange-mapi-connection.c:784) ==31507==by 0x12674731: mapi_refresh_folder (camel-mapi-folder.c:522) ==31507==by 0x12674BBD
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
Per, You sure you did 'export MAPI_DEBUG=1' on a terminal and from the same terminal, you start evolution? I'm wondering how it works for me then :( -Srini. On Sun, 2008-02-03 at 23:18 -0800, Per Nystrom wrote: Srini, I tried MAPI_DEBUG=1, but I got the same output as I already sent before. BTW, I only munged out the server, domain, username, and password (it shouldn't really show the password in plaintext anyway, but that's minor compared to getting it to work at all). Thanks, Per On Mon, 2008-02-04 at 12:16 +0530, Srinivasa Ragavan wrote: Per, Nice to hear that the crash is gone. You can do export 'MAPI_DEBUG=1' evolution Try authentication and paste me out the logs. It can help be get out of the barrier. Do send me privately if you think it has some sensitive information. -Srini. On Sat, 2008-02-02 at 23:15 -0800, Per Nystrom wrote: Hi, I saw a new update showed up today in the repository so I tried it out. The crash is gone, but I still can't get past the authenticate dialog. Here's the terminal output: [EMAIL PROTECTED] ~]$ LD_LIBRARY_PATH=/opt/samba4/lib evolution CalDAV Eplugin starting up ... Loading Exchange MAPI Plugin listener is constructed evolution-shell-Message: Killing old version of evolution-data-server... ** (evolution:10509): DEBUG: mailto URL command: evolution --component=mail %s ** (evolution:10509): DEBUG: mailto URL program: evolution camel-mapi-store.c(166):camel_mapi_store_get_type:Reached get uuu mapi://[EMAIL PROTECTED]/ Find Items 9 Couldn't Get password 9 Create profile with uuu ppp () yyy.zzz xxx.yyy.zzz profpath /home/test/.evolution/mapi-profiles.ldb [exchange_mapi_plugin] Profile creation Logging into the server Login succeeded: Yeh [exchange_mapi_plugin] : ProcessNetworkProfile: MAPI_E_INVALID_PARAMETER (0x80070057) [exchange_mapi_plugin] ProcessNetworkProfile() : MAPI_E_INVALID_PARAMETER (0x80070057) Get Default 0 Find Items 9 Couldn't clear password I'm happy to help debug, just let me know what you need me to do. Thanks, Per On Mon, 2008-01-28 at 23:45 -0800, Per Nystrom wrote: Excellent, I'll watch for it to show up in the repository and try again. Thanks, Per On Tue, 2008-01-29 at 09:22 +0530, Srinivasa Ragavan wrote: Looks like a double free when the profile creation fails. Per, the main problem here is why the profile creation fails. We will push a debug build asap so that this can be seen. -Srini. On Mon, 2008-01-28 at 11:31 -0800, Per Nystrom wrote: Hello, I installed the RPMs and dependencies from http://download.opensuse.org/repositories/home:/jjohnny:/evolution-exchange-mapi-provider in a Fedora 8 i386 VM, started up Evolution with the required LD_LIBRARY_PATH, tried to configure a MAPI account, and ended up with a crash. I posted details to the bugs wiki here: http://www.go-evolution.org/MAPIProvider/Bugs I'm happy to help get this moving any way I can; I have been without Evolution-Exchange connectivity ever since my company upgraded to Exchange 2007 in December and OWA light is driving me nuts. Thanks, Per ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
William, Looks like you got the MAPI_DEBUG working. Since you quoted that it is a crash, can you attach to gdb or start Evolution in gdb and give me out the traces? William, when you delete the gconf entries, please delete the ~/.evolution/mapi_profiles.ldb also. -Srini. On Mon, 2008-02-04 at 12:42 +, William John Murray wrote: Hi guys, I had similar problems to Per. But I learnt something: When I am in his position I cannot move forward. If I try to change the account username etc it does not work. I get his symptom. But if I delete the gconf entry and restart evo from fresh I get to a different password entry box with a seperate domain entry. If I get my credentials correct here, first time, then I can go forward. Then I get a crash :). There is a log on: http://murray.home.cern.ch/murray/evo.txt I have hidden some personal details, but you can see it does recover all my folder from the (2003) server. Yay! Bill ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
Hi William,
The trace looks fine, but I'm not able to find any segv or signal
handler call = Not able to find which thread crashed. Just do a 'bt'
Otherwise, it could be a memory corruption, I think.
Can you run like 'valgrind --tool=memcheck evolution' and paste me the
logs?
Sorry for the multiple iterations.
-Srini.
On Mon, 2008-02-04 at 18:19 +, William John Murray wrote:
Hello Suman,
Here is the log. Thank you for looking at this.
Bill
thread apply all bt full
Thread 8 (Thread 1105209680 (LWP 23478)):
#0 0x003dd0ad50d8 in epoll_wait () from /lib64/libc.so.6
No symbol table info available.
#1 0x2aaab3d305e0 in ?? () from /opt/samba4/lib/libdcerpc.so.0
No symbol table info available.
#2 0x2aaab3d31032 in ?? () from /opt/samba4/lib/libdcerpc.so.0
No symbol table info available.
#3 0x2aaab3d2ff42 in event_loop_once ()
from /opt/samba4/lib/libdcerpc.so.0
No symbol table info available.
#4 0x2aaab39ad2ab in dcerpc_request_recv ()
from /opt/samba4/lib/libdcerpc.so.0
No symbol table info available.
#5 0x2aaab39ade40 in dcerpc_ndr_request_recv ()
from /opt/samba4/lib/libdcerpc.so.0
No symbol table info available.
#6 0x2aaab36e45a0 in dcerpc_EcDoRpc (p=0x2aaabc020bd0,
mem_ctx=value optimized out, r=0x41e01ca0) at
gen_ndr/ndr_exchange_c.c:1565
req = (struct rpc_request *) 0xfffc
#7 0x2aaab36a4da3 in emsmdb_transaction (emsmdb=0x2aaabc020c70,
req=0xe1fe50, repl=0x41e01d40) at libmapi/emsmdb.c:208
r = {in = {mapi_request = 0xe1fe50, max_data = 32767, handle =
0x2aaabc020c78, size = 32767, offset = 0, length = 0xe1fdc0}, out =
{mapi_response = 0xe1ff20, handle = 0x2aaabc020c78, size = 14810816,
offset = 0, length = 0xe1fdc0, result = 3016974192}}
multi_req = value optimized out
i = 0 '\0'
#8 0x2aaab369db67 in OpenMsgStore (obj_store=0x41e01e70) at
libmapi/IMAPISession.c:192
mapi_request = (struct mapi_request *) 0x41e01a10
mapi_response = value optimized out
retval = value optimized out
size = value optimized out
mem_ctx = (TALLOC_CTX *) 0xe1fc70
mailbox = value optimized out
#9 0x2aaab3468c82 in exchange_mapi_connection_fetch_items
(fid=388610298799456257, GetPropsList=0x2aaab9a43080, cn_props=8,
build_name_id=0, res=0x0, cb=0x2aaab9a3f4e0 fetch_items_cb,
data=0x2aaabc02e100) at exchange-mapi-connection.c:654
retval = value optimized out
mem_ctx = (TALLOC_CTX *) 0xe1fad0
obj_store = {id = 0, handle = 4294967295, handles = 0x0,
private_data = 0x0}
obj_folder = {id = 0, handle = 4294967295, handles = 0x0,
private_data = 0x0}
obj_table = {id = 0, handle = 4294967295, handles = 0x0,
private_data = 0x0}
SPropTagArray = value optimized out
GetPropsTagArray = value optimized out
SRowSet = {cRows = 3007729240, aRow = 0xe09c30}
count = 0
i = value optimized out
result = value optimized out
__PRETTY_FUNCTION__ = exchange_mapi_connection_fetch_items
#10 0x2aaab9a3f732 in mapi_refresh_folder (folder=0x2aaabc02e100,
ex=0x41e01fc0) at camel-mapi-folder.c:522
temp_folder_id = 388610298799456257
mapi_store = (CamelMapiStore *) 0x719530
status = value optimized out
folder_id = (gchar *) 0xe09c30 05649F020001
__PRETTY_FUNCTION__ = mapi_refresh_folder
#11 0x2aaab9a3fbbe in mapi_refresh_info (folder=0x2aaabc02e100,
ex=0x41e01fc0) at camel-mapi-folder.c:136
si = value optimized out
__PRETTY_FUNCTION__ = mapi_refresh_info
#12 0x2aaab0577973 in ?? ()
from /usr/lib64/evolution/2.12/components/libevolution-mail.so
No symbol table info available.
#13 0x2aaab0572cda in ?? ()
from /usr/lib64/evolution/2.12/components/libevolution-mail.so
No symbol table info available.
#14 0x003dd3a5cde9 in ?? () from /lib64/libglib-2.0.so.0
No symbol table info available.
#15 0x003dd3a5b2a4 in ?? () from /lib64/libglib-2.0.so.0
No symbol table info available.
#16 0x003dd1606407 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#17 0x003dd0ad4b0d in clone () from /lib64/libc.so.6
No symbol table info available.
Thread 5 (Thread 1094719824 (LWP 23381)):
#0 0x003dd0a795c0 in strlen () from /lib64/libc.so.6
No symbol table info available.
#1 0x003dd3a54323 in g_strdup () from /lib64/libglib-2.0.so.0
No symbol table info available.
#2 0x2aaab9a41002 in mapi_folders_sync (store=0x719530, ex=value
optimized out) at camel-mapi-store.c:972
name = 0x2aaabc012b10 2006
fid = (gchar *) 0xbc06af90 Address 0xbc06af90
out of bounds
priv = (CamelMapiStorePrivate *) 0x73a380
status = value optimized out
folder_list = (GSList *) 0x7f0c10
temp_list = (GSList *) 0x7f0c20
url = 0x2aaabc076710 mapi://[EMAIL PROTECTED]/
info = value
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
On Mon, 2008-02-04 at 14:31 -0800, Per Nystrom wrote: Srini, I don't know what I'm doing wrong, but here's what I did and the output I got (munged for privacy -- uuu=username ppp=password ddd=domain sss=exchange server): [EMAIL PROTECTED] ~]$ export LD_LIBRARY_PATH=/opt/samba4/lib [EMAIL PROTECTED] ~]$ export MAPI_DEBUG=1 Ah, this sounds challenging. You seem to be doing it right. Sure that you have the new mapi connector installed from the repo? -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
Per, Are you accessible on XChat? I'm 'srag' at #evolution in GimpNet (irc.gnome.org) I think we can resolve this faster over chat than mail :) -Srini. On Mon, 2008-02-04 at 20:30 -0800, Per Nystrom wrote: Srini, I think so. Here's what I've got: [EMAIL PROTECTED] ~]# yum check-update fedora100% |=| 2.1 kB00:00 updates 100% |=| 2.3 kB00:00 home:jjohnny:evolution-ex 100% |=| 951 B00:00 fedora-debuginfo 100% |=| 2.1 kB00:00 [EMAIL PROTECTED] ~]# rpm -qa | grep -i mapi libmapi-0.6_HOLODECK-7.1 evolution-mapi-provider-debuginfo-20080118.3-2.1 evolution-mapi-provider-20080118.3-2.1 On Tue, 2008-02-05 at 09:53 +0530, Srinivasa Ragavan wrote: On Mon, 2008-02-04 at 14:31 -0800, Per Nystrom wrote: Srini, I don't know what I'm doing wrong, but here's what I did and the output I got (munged for privacy -- uuu=username ppp=password ddd=domain sss=exchange server): [EMAIL PROTECTED] ~]$ export LD_LIBRARY_PATH=/opt/samba4/lib [EMAIL PROTECTED] ~]$ export MAPI_DEBUG=1 Ah, this sounds challenging. You seem to be doing it right. Sure that you have the new mapi connector installed from the repo? -Srini. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
Guys, We've just pushed another build with some fixes and made debug possible. export MAPI_DEBUG=1 and start evolution/eds on the console. It might be a bit slow, if you run like this, so do this only for collecting debug information to help us :-) -Srini. On Tue, 2008-01-29 at 13:30 +0530, Srinivasa Ragavan wrote: Per, it will be great, if you can run it with 'valgrind --tool=memcheck evolution' and paste the logs to me. It might help me debug it better. -Srini. On Mon, 2008-01-28 at 23:45 -0800, Per Nystrom wrote: Excellent, I'll watch for it to show up in the repository and try again. Thanks, Per On Tue, 2008-01-29 at 09:22 +0530, Srinivasa Ragavan wrote: Looks like a double free when the profile creation fails. Per, the main problem here is why the profile creation fails. We will push a debug build asap so that this can be seen. -Srini. On Mon, 2008-01-28 at 11:31 -0800, Per Nystrom wrote: Hello, I installed the RPMs and dependencies from http://download.opensuse.org/repositories/home:/jjohnny:/evolution-exchange-mapi-provider in a Fedora 8 i386 VM, started up Evolution with the required LD_LIBRARY_PATH, tried to configure a MAPI account, and ended up with a crash. I posted details to the bugs wiki here: http://www.go-evolution.org/MAPIProvider/Bugs I'm happy to help get this moving any way I can; I have been without Evolution-Exchange connectivity ever since my company upgraded to Exchange 2007 in December and OWA light is driving me nuts. Thanks, Per ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
Per, Nice to hear that the crash is gone. You can do export 'MAPI_DEBUG=1' evolution Try authentication and paste me out the logs. It can help be get out of the barrier. Do send me privately if you think it has some sensitive information. -Srini. On Sat, 2008-02-02 at 23:15 -0800, Per Nystrom wrote: Hi, I saw a new update showed up today in the repository so I tried it out. The crash is gone, but I still can't get past the authenticate dialog. Here's the terminal output: [EMAIL PROTECTED] ~]$ LD_LIBRARY_PATH=/opt/samba4/lib evolution CalDAV Eplugin starting up ... Loading Exchange MAPI Plugin listener is constructed evolution-shell-Message: Killing old version of evolution-data-server... ** (evolution:10509): DEBUG: mailto URL command: evolution --component=mail %s ** (evolution:10509): DEBUG: mailto URL program: evolution camel-mapi-store.c(166):camel_mapi_store_get_type:Reached get uuu mapi://[EMAIL PROTECTED]/ Find Items 9 Couldn't Get password 9 Create profile with uuu ppp () yyy.zzz xxx.yyy.zzz profpath /home/test/.evolution/mapi-profiles.ldb [exchange_mapi_plugin] Profile creation Logging into the server Login succeeded: Yeh [exchange_mapi_plugin] : ProcessNetworkProfile: MAPI_E_INVALID_PARAMETER (0x80070057) [exchange_mapi_plugin] ProcessNetworkProfile() : MAPI_E_INVALID_PARAMETER (0x80070057) Get Default 0 Find Items 9 Couldn't clear password I'm happy to help debug, just let me know what you need me to do. Thanks, Per On Mon, 2008-01-28 at 23:45 -0800, Per Nystrom wrote: Excellent, I'll watch for it to show up in the repository and try again. Thanks, Per On Tue, 2008-01-29 at 09:22 +0530, Srinivasa Ragavan wrote: Looks like a double free when the profile creation fails. Per, the main problem here is why the profile creation fails. We will push a debug build asap so that this can be seen. -Srini. On Mon, 2008-01-28 at 11:31 -0800, Per Nystrom wrote: Hello, I installed the RPMs and dependencies from http://download.opensuse.org/repositories/home:/jjohnny:/evolution-exchange-mapi-provider in a Fedora 8 i386 VM, started up Evolution with the required LD_LIBRARY_PATH, tried to configure a MAPI account, and ended up with a crash. I posted details to the bugs wiki here: http://www.go-evolution.org/MAPIProvider/Bugs I'm happy to help get this moving any way I can; I have been without Evolution-Exchange connectivity ever since my company upgraded to Exchange 2007 in December and OWA light is driving me nuts. Thanks, Per ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution 2.21.90 , Evolution-Data-Server 2.21.90 , GtkHTML3.17.90.1 and Evolution-Exchange 2.21.90 released
Hi All, The Evolution Team is pleased to announce the release of Evolution 2.21.90. You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.17/gtkhtml-3.17.90.1.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/2.21/evolution-data-server-2.21.90.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.21/evolution-2.21.90.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.21/evolution-exchange-2.21.90.tar.bz2 Upgrade Notes : Evolution 2.21.x is the unstable series of 2.22 development. (Note: Evolution/EDS/Exchange versions are synced with the GNOME versions) RELNOTE: If you are using Exchange/Groupwise, we suspect there may be some regressions due to new libsoup integration. In case, you observe any regressions or memory built up or not able to connect to the server in some scenarios, report a bug as soon as possible with all the required information. RELNOTE: If you have created labels/tags using Evolution 2.21.4. You need to delete them and recreate using 2.21.5 or later. We have changes the way labels are stored now. It should be final now. What is New ? = Important Most Wanted Bug fixes: Folder summary Mismatch during sync - (Sankar) VFolders/trash crash on exit or account disable is fixed (Milan Crha) Anchor support for Frame/IFrame in gtkhtml (Milan Crha) Evolution: == New in 2.21.90: Improved spam filtering and spam white list implementation and new preferences UI for configuring spam filtering (Srinivasa Ragavan) Bug Fixes: #324604: Ensure the print of the email is transformed from RFC822 or RFC2047 (Milan Crha) #329712: Add a new state to maintian forced offline (Srinivasa Ragavan) #333695: Print attendee name instead of email address if available (Milan Crha) #337046: Have a ticking filename for attachment, if the mime doesn't carry it (Srinivasa Ragavan) #339156: Translation issues (Andre Klapper) #355864: Critical Crash warning while unchecking web calendar (Milan Crha) #371011: Insert a new paragraph for signature (Johnny Jacob) #391408: Fix contact minicards for RTL languages (Djihed Afifi) #395939: Memory leak fix (Milan Crha) #402487: Memory leak fix (Milan Crha) #405777: Fix a crash when previewing mails (Srinivasa Ragavan) #426159: Allow users to snooze for 1+ hour 0 minutes (Suman Manjunath) #467581: Don't cancel all threads for a vfolder based search (all/account search) (Johnny Jacob) #475781: Fix memory leaks (Milan Crha) #503327,503678: Return GByteArray instead of gchar* (Johnny Jacob) #503551: Fix a crash when trying to delete unselected contact (Milan Crha) #504062: Fix message list sorting (Milan Crha) #507564: Fix contact view for RTL languages. (Djihed Afifi) #509124: Check result of build_message() for NULL before proceeding (Matthew Barnes) #509509: Make the status bar height as large as the task bar to eliminate bouncing when navigating the main menu (Jean-Christophe) #509697: Ensure search folders are running before calling anything from this (Milan Crha) #509741: Fix a crash that occurs when prompted to accept a certificate (Matthew Barnes) #509879: Drop code to clear memo preview every 60 seconds (Milan Crha) #510409: Free memory before assigning NULL (Milan Crha) #511094: Set proper foreground color based on focused/non-focused canvas (Milan Crha) #511105: Free allocated memory properly (Milan Crha) #511232: Fixed typo Uknown - Unknown (Jan Tichavsky) #511488: Ensure vfolder is running (Milan Crha) #512020: Imposible to remove categories of weather (Milan Crha) Other Contributors: Windows build fixes (Tor Lillqvist) Message list cairo drawing (Srinivasa Ragavan) Added localized screenshots (Andre Klapper) libsoup updates (Dan Winship) Updated Translations: Žygimantas Beručka (lt) Jovan Naumovski (mk) Jorge Gonzalez (es) Andre Klapper (de) Kjartan Maraas (nb) Yair Hershkovitz (he) Inaki Larranaga Murgoitio (eu) Sandeep Shedmake (mr) Shankar Prasad (kn) Ignacio Casal Quinteiro (gl) Evolution-data-server: = New in 2.21.90 Speed up spam filtering and spam whitelist implementation (Srinivasa Ragavan) Bug Fixes: #213072: Avoids the infinite loop that might be caused in case of broken mbox files or null From addresses. (Sankar P) #213072: Remove the error condition that inits and persists the infamous folder summary mismatch bug (Sankar P) #300098: Set proper dependencies for stand-alone programs linking against camel. (Øystein Gisnås) #324168: Crash while disabling/Deleting accounts (Milan Crha) #335217
Re: [Evolution-hackers] massive e-d-s memory leak persuit ...
Meeks,
On Mon, 2008-01-28 at 11:27 +, Michael Meeks wrote:
Hi Srini,
On Fri, 2008-01-25 at 00:00 +0530, Srinivasa Ragavan wrote:
Just check
.evolution/addressbook/account/book_name.summary -- Summary which is
in memory for fast autocompletion
and
.evolution/cache/addressbook/account/book_name/cache.db --Acutal
cache of contacts
I have:
[EMAIL PROTECTED]:~/.evolution find -name 'cache.db' -exec ls -lh {} \;
-rw-r--r-- 1 michael users 25M 2007-12-07 06:14 ./cache/addressbook/[EMAIL
PROTECTED]/Novell GroupWise Address Book/cache.db
-rw-r--r-- 1 michael users 12K 2007-04-19 16:32 ./cache/addressbook/[EMAIL
PROTECTED]/Frequent Contacts/cache.db
-rw-r--r-- 1 michael users 12K 2007-04-19 16:32 ./cache/addressbook/[EMAIL
PROTECTED]/Michael Meeks/cache.db
-rw-r--r-- 1 michael users 21M 2007-04-23 09:44 ./cache/addressbook/[EMAIL
PROTECTED]/Novell GroupWise Address Book/cache.db
-rw-r--r-- 1 michael users 12K 2008-01-28 11:19 ./cache/addressbook/[EMAIL
PROTECTED]/Frequent Contacts/cache.db
-rw-r--r-- 1 michael users 22M 2008-01-28 11:19 ./cache/addressbook/[EMAIL
PROTECTED]/Novell GroupWise Address Book/cache.db
-rw-r--r-- 1 michael users 12K 2008-01-28 11:19 ./cache/addressbook/[EMAIL
PROTECTED]/Michael Meeks/cache.db
[EMAIL PROTECTED]:~/.evolution find -name '*.summary' -exec ls -lh {} \;
-rw-r--r-- 1 michael users 2.2M 2007-09-06 22:31 ./addressbook/[EMAIL
PROTECTED]/Novell GroupWise Address Book.summary
-rw-r--r-- 1 michael users 39K 2007-04-19 16:32 ./addressbook/[EMAIL
PROTECTED]/Frequent Contacts.summary
-rw-r--r-- 1 michael users 1.7M 2007-04-23 10:03 ./addressbook/[EMAIL
PROTECTED]/Novell GroupWise Address Book.summary
-rw-r--r-- 1 michael users 1.9K 2008-01-28 10:55 ./addressbook/local/[EMAIL
PROTECTED]/addressbook.db.summary
-rw-r--r-- 1 michael users 120K 2008-01-28 11:04 ./addressbook/local/[EMAIL
PROTECTED]/addressbook.db.summary
-rw-r--r-- 1 michael users 289K 2008-01-28 11:07
./addressbook/local/system/addressbook.db.summary
-rw-r--r-- 1 michael users 39K 2008-01-28 11:19 ./addressbook/[EMAIL
PROTECTED]/Frequent Contacts.summary
-rw-r--r-- 1 michael users 1.7M 2008-01-28 11:17 ./addressbook/[EMAIL
PROTECTED]/Novell GroupWise Address Book.summary
-rw--- 1 michael users 477 2006-07-10 12:29 ./mail/groupwise/[EMAIL
PROTECTED]/.summary
-rw--- 1 michael users 481 2007-01-11 10:03 ./mail/groupwise/[EMAIL
PROTECTED]/.summary
If you see these with groupwise, at times the summary will be more than
the cache. Which is what the revision fixes. Just check and lemme know.
All my summaries are smaller than the caches it seems.
So I think it is all right for you. I think you must have used
10.3/later, which must have cleared the summary's old contacts.
OTOH, several 20+Mb cache file is quite large, what lurks in there ?
[ I guess if it's attachments etc. then fair enough, best to use the
space ].
I guess that it is 6000+ Contacts and their complete addresses/details
like address/phone/etc. It may not have attachments, as the GW didn't
support it iirc.
Novell GroupWise Address Book:
total 24M
-rw-r--r-- 1 sragavan users 24M 2008-01-28 19:16 cache.db
Mine it says 24MB. I doubt, how is that 4MB difference for two people
from the same company. I think mine may have some stale/old contacts.
-Srini
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
Looks like a double free when the profile creation fails. Per, the main problem here is why the profile creation fails. We will push a debug build asap so that this can be seen. -Srini. On Mon, 2008-01-28 at 11:31 -0800, Per Nystrom wrote: Hello, I installed the RPMs and dependencies from http://download.opensuse.org/repositories/home:/jjohnny:/evolution-exchange-mapi-provider in a Fedora 8 i386 VM, started up Evolution with the required LD_LIBRARY_PATH, tried to configure a MAPI account, and ended up with a crash. I posted details to the bugs wiki here: http://www.go-evolution.org/MAPIProvider/Bugs I'm happy to help get this moving any way I can; I have been without Evolution-Exchange connectivity ever since my company upgraded to Exchange 2007 in December and OWA light is driving me nuts. Thanks, Per ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
Per, it will be great, if you can run it with 'valgrind --tool=memcheck evolution' and paste the logs to me. It might help me debug it better. -Srini. On Mon, 2008-01-28 at 23:45 -0800, Per Nystrom wrote: Excellent, I'll watch for it to show up in the repository and try again. Thanks, Per On Tue, 2008-01-29 at 09:22 +0530, Srinivasa Ragavan wrote: Looks like a double free when the profile creation fails. Per, the main problem here is why the profile creation fails. We will push a debug build asap so that this can be seen. -Srini. On Mon, 2008-01-28 at 11:31 -0800, Per Nystrom wrote: Hello, I installed the RPMs and dependencies from http://download.opensuse.org/repositories/home:/jjohnny:/evolution-exchange-mapi-provider in a Fedora 8 i386 VM, started up Evolution with the required LD_LIBRARY_PATH, tried to configure a MAPI account, and ended up with a crash. I posted details to the bugs wiki here: http://www.go-evolution.org/MAPIProvider/Bugs I'm happy to help get this moving any way I can; I have been without Evolution-Exchange connectivity ever since my company upgraded to Exchange 2007 in December and OWA light is driving me nuts. Thanks, Per ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] massive e-d-s memory leak persuit ...
Hey Michael, We are aware of some situations (I did that in addressbook) where the memory built up can happen. They were fixed later to SLED/SP1 release during late 2.12 and aren't in SLED but are part of trunk already. Candidate for the next support pack. Chen is doing a extensive job of profiling EDS currently for SLED/2.22 releases. Once thing is that the Groupwise Addressbook cache, on a update, wouldn't clear the previous one and just appends everything. Which means if you have 100 and you have a update of 10. Next time your cache would have 210 where as ideally it should have just 110. Just to see, if this is a culprit for you. Just move the .evolution/cache/addressbook/account/Novell GroupWise Address Book some where else and make it resync (showdown evo/eds and start evo and go to addressbook). If the sizes vary a lot, they are affected by that syndrome. There were quite a few bits like these they were fixed post SP1 and are in trunk/2.12 already. GQuarks seems to be a nice idea. I will look at it in some time. Thanks Meeks. -Srini. On Thu, 2008-01-24 at 17:46 +, Michael Meeks wrote: 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 gives me: 1666 -CONTACT-UID 1666 -NAME 1736 ION-DEST-NAME 1894 OLUTION-BOOK-URI 2100 -EMAIL 2184 ION-DEST-EMAIL 2318 OLUTION-FILE-AS 2506 OLUTION-LIST 2992 ION-LIST 3058 comp 3321 OLUTION-DEST-EMAIL 3329 OLUTION-DEST-CONTACT-UID 3993 OLUTION-DEST-NAME 4534 pwise://[EMAIL PROTECTED]/;Novell GroupWise Address Book 5343 BEGIN:VCARD 5372 ION-DEST-EMAIL 5504 END:VCARD 5505 VERSION:3.0 6786 ION-DEST-NAME 8606 para 12739 ION-DEST-CONTACT-UID 13642 OLUTION-DEST-CONTACT-UID 18082 OLUTION-DEST-NAME 19252 OLUTION-DEST-EMAIL 21991 prop 32508 ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION; 40253 pA, Where the first column is the count ... 32508 copies of that ATTENDEE string seems a little excessive, as do the (apparently mangled?) OLUTION-DEST-... strings. Does that provide any insight wrt. code to audit for this huge leak ? apparently it afflicts everything from SLED10-SP1 onwards. Also - in general to reduce the (high) e-d-s memory usage, should we be using GQuarks for some of these field names as we store them ? Thanks, Michael. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Diary replaying on IMAP accounts
Philip, On Mon, 2008-01-21 at 17:01 +0100, Philip Van Hoof wrote: On Mon, 2008-01-21 at 10:45 -0500, Jeffrey Stedfast wrote: On Mon, 2008-01-21 at 13:17 +0100, Philip Van Hoof wrote: [CUT] (sounds like severe to me) To be honest, I have no idea what the side effects of changing that code to return TRUE for the RESYNCING state are. That's one of the problems with a tri-state that isn't really a tri-state :\ Agree As you mentioned, having it return FALSE is clearly not correct and returning TRUE may introduce some bugs :\ As far as I know, there are some bugs regarding offline usage not resyncing properly when going back online, so you may have found the cause. Perhaps, yes. I'll let the current maintainers make a judgment call on whether to accept this into mainline Camel or not (looks like either way, there's gonna have to be some attention given to this area of code) So Matthew, the ball is in your camp now :-)! Philip, I wouldn't be favor of taking things late into trunk, with an uncertainty. If you/matt/fejj have confidence on it, I think I'm fine. Hope you got my point. -Srini ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
Holger, The RPM was built for Evolution 2.12/OpenSUSE 10.3. But if you get hold of the source, my guess is that you can use it from Evolution 2.4 onwards ;-) Also, our hands were tied, as the OpenSUSE build service had a bad week and we couldn't do much. We should be able to build binaries for all the OpenSUSE build service supported Distros (OpenSUSE, Fedora, Debian, Ubuntu, Mandriva) and for versions 2.12 and above (current 2.21.x). Of course, we might need a bit of tweaking for debs in the spec files, which aren't yet done and any one is free to do that and help us. -Srini. On Fri, 2008-01-18 at 17:51 +0100, Holger Goetz wrote: Hi Suman, Johnny, 1st: That's great news! Thanks for all your efforts around MAPI and Exchange2007! 2nd: What version of evolution is expected as minimum? Is there any magic beside of installation, exporting the LD_LIBRARY_PATH for samba4 and activating the plugin, to get a MAPI or alike selection the the Server Type drop down? (The plugin is there and can be activated/is activated) BTW: tested on 2 systems: Ubuntu 7.02, Evolution 2.12.1 and plain debian-sid 2.12.2-1+b1 ... Couldn't test w/ 2.21.90 from trunk of svn - as the rpm's install in default libs and not into /opt/evo/ or alike. Thanks, Holger On Fri, 2008-01-18 at 21:32 +0530, Suman wrote: Just to give a heads-up on what WON'T work w.r.t. calendars/tasks/memos: + no meetings/assigned tasks support.. (we're waiting on a few APIs to be made available by libmapi) + no recurring events [1] + freebusy info (the first point would make this irrelavant.. but..) The rest of the basic features would *mostly* work.. Comparing the plugin to the current Exchange connector.. feature-wise... MAPI stilll has a long way to go.. :) Looking forward to a lot of people trying/testing the RPMs and getting back to us with their invaluable feedback.. TIA !! [1] events = appointments/meetings.. unfortunately, Evolution does not support recurring tasks yet.. so.. don't wait on that.. regards, Suman P.S. ohhh... btw.. Outlook notes ~= Evolution memos.. On Jan 18, 2008 7:50 PM, Jacob Johnny [EMAIL PROTECTED] wrote: Hello guys, This is an announce mail for the preview of Evolution MAPI provider. This provider can connect to Exchange 2007 servers and also to Exchange 2003, 2000 and 5.5 (untested). After seeing enormous interest by the users in Exchange 2007 connectivity, we have prepared a preview of the current development code from the branch. The evolution-mapi-provider is a standalone rpm but in future it may be part of the Evolution/EDS rpms. It has a dependency on OpenChange's ( http://openchange.org ) libmapi and Samba4. I'm maintaining the build service project for the provider and I'm planning to give RPMs for OpenSUSE, SLED, Fedora and Ubuntu. We would be doing incremental releases of this periodically and may have nightly builds for this pretty soon (Don't ask me when ;-) The below url should let you access the Samba4, libmapi and Evolution MAPI Provider rpms. http://download.opensuse.org/repositories/home:/jjohnny:/evolution-exchange-mapi-provider Due to the recent outage of OpenSUSE Build Service, we aren't able to get the rpms ready. So I have built RPMs for opensuse 10.3/i586 alone and is available at: http://gnomebangalore.org/~sragavan/exchange-mapi/i586/ . The build for the project is already queued. So it is possible that by the time, you read the mail, the rpms might have been published already. So go check out and give your valuable feedback. ** IMPORTANT - DISCLAIMER *** * The build could be very unstable and may crash frequently. * Don't report these issues on to Evolution bugzilla atm. We will create the components and let you all know it. Mean while, you can write your comments/bugs at http://www.go-evolution.org/MAPIProvider/Bugs and we will migrate them to bugzilla a little later. * It is not yet feature complete. We don't have public folders/GAL yet. EMail subjects appear corrupted and lots of other known issues :) * Most of the features are untested * You need to export the Samba4 LD_LIBRARY_PATH=/opt/samba4/lib * At Last: I'm not responsible for any serious
Re: [Evolution-hackers] Memory leak in camel-imap-message-cache.c
Look at the free_part function being called at g_hash_table_foreach (cache-parts, free_part, cache); It frees the key. -Srini. On Mon, 2008-01-14 at 02:58 +0100, Philip Van Hoof wrote: Hi there, The cache-parts = g_hash_table_new (g_str_hash, g_str_equal); of camel-imap-message-cache.c does not free its keys (it's the default way of creating a hashtable, so there's no freeup function provided for the keys). Yet at (or around) line 118 we see this: g_hash_table_insert (cache-parts, g_strdup (uid), subparts); That uid is string-copied. So either the hashtable needs a freeup function or the string should not be copied or .. this is wrong. Because I don't know how important the string copying is, what do you guys think we should do here? ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
