Re: [Evolution-hackers] Move IMAPX back to a module library for 3.12

2013-08-19 Thread Srinivasa Ragavan
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

2013-07-24 Thread Srinivasa Ragavan
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

2013-07-24 Thread Srinivasa Ragavan
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

2013-07-23 Thread Srinivasa Ragavan
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?

2013-01-09 Thread Srinivasa Ragavan
[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

2012-03-01 Thread Srinivasa Ragavan
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

2012-02-09 Thread Srinivasa Ragavan
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

2012-02-06 Thread Srinivasa Ragavan
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

2012-02-02 Thread Srinivasa Ragavan
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

2012-02-02 Thread Srinivasa Ragavan
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

2012-01-31 Thread Srinivasa Ragavan
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

2012-01-30 Thread Srinivasa Ragavan
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

2012-01-27 Thread Srinivasa Ragavan
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

2011-11-24 Thread Srinivasa Ragavan
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?

2011-10-18 Thread Srinivasa Ragavan
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

2011-08-28 Thread Srinivasa Ragavan
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

2011-08-26 Thread Srinivasa Ragavan
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

2011-04-25 Thread Srinivasa Ragavan
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]

2011-03-21 Thread Srinivasa Ragavan
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

2010-08-16 Thread Srinivasa Ragavan
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

2010-08-16 Thread Srinivasa Ragavan
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

2009-12-15 Thread Srinivasa Ragavan
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

2009-12-03 Thread Srinivasa Ragavan
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?

2009-10-25 Thread Srinivasa Ragavan
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

2009-08-04 Thread Srinivasa Ragavan
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

2009-07-01 Thread Srinivasa Ragavan
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

2009-06-23 Thread Srinivasa Ragavan
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

2009-03-27 Thread Srinivasa Ragavan
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

2009-03-25 Thread Srinivasa Ragavan
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

2009-03-18 Thread Srinivasa Ragavan

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

2009-02-22 Thread Srinivasa Ragavan
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

2009-01-12 Thread Srinivasa Ragavan
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

2009-01-07 Thread Srinivasa Ragavan
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

2009-01-04 Thread Srinivasa Ragavan
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

2008-11-16 Thread Srinivasa Ragavan
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

2008-11-10 Thread Srinivasa Ragavan
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] Does evolution source still contains GPLv2 code?

2008-10-16 Thread Srinivasa Ragavan
Jeff,

The COPYING (GPLv2) old license, COPYING.LGPLv2 COPYING.LGPLv3 are
present in the tarballs. Evolution still has some files left  not moved
to LGPLv2/LGPLv3. NEWs files might have been saying that some license
changes code went in. Sorry for the confusion.

-Srini.

On Fri, 2008-10-17 at 11:01 +0800, Jeff Cai wrote:
 Hi
 
  From the 2.24 tar package and svn trunk, I can still find the COPYING 
 file which says that it is GNU GENERAL PUBLIC LICENSE v2. But from 
 NEWS, it says Evolution source code license changed to LGPLv2  LGPLV3 
 (Sankar P).
 
 Sankar, I'm curious about whether evolution still contains GPLv2 code.
 
 Jeff
 
 ___
 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

2008-10-12 Thread Srinivasa Ragavan
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

2008-10-06 Thread Srinivasa Ragavan
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?!

2008-10-05 Thread Srinivasa Ragavan
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

2008-09-25 Thread Srinivasa Ragavan
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?

2008-09-24 Thread Srinivasa Ragavan
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

2008-09-22 Thread Srinivasa Ragavan
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

2008-09-19 Thread Srinivasa Ragavan
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

2008-09-03 Thread Srinivasa Ragavan
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

2008-09-02 Thread Srinivasa Ragavan
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

2008-08-19 Thread Srinivasa Ragavan
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

2008-07-29 Thread Srinivasa Ragavan
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?

2008-07-24 Thread Srinivasa Ragavan
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


[Evolution-hackers] Evolution 2.23.5 , Evolution-Data-Server 2.23.5 , GtkHTML3.23.5 and Evolution-Exchange 2.23.5 released

2008-07-23 Thread Srinivasa Ragavan
Hi All,

The Evolution Team is pleased to announce the release of Evolution
2.23.5. 

You can download the following :

http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.23/gtkhtml-3.23.5.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/2.23/evolution-data-server-2.23.5.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.23/evolution-2.23.5.tar.bz2
http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.23/evolution-exchange-2.23.5.tar.bz2

Upgrade Notes :
Evolution 2.23.x is the unstable series of 2.24 development.

What is New ?
=

CAUTION: We have merged Camel DB Summary based on sqlite with this
release. It has a migration code for 2.22.x, but for 2.23.4 users, it
wont be invoked, but the code is to auto migrate on demand which might
be a bit slow. It should be fairly stable, with a lot of known issues.
Search is partial atm. VFolders aren't fully functional and the
unread/total counts are messed up a bit and a lot more. Please add all
the bugs you see due to this to the tracker bug
http://bugzilla.gnome.org/show_bug.cgi?id=543389 

Non-default old camel providers may not work with 2.23.5 , like imap4 or
evolution-brutus etc.

Evolution:
==
New in 2.23.5
Camel DB Summary support. (Srinivasa Ragavan  Sankar P)
New EPlugin for message templates. (Bharath Acharya  Diego Escalante 
Urrelo)
Google Contacts support (Jörgen Scheibengruber)

Bug Fixes:
#543753: Addressbook error string fixes (Andre Klapper)
#228725: Contacts view should not say no items in this view until the 
backend is done responding (Milan Crha)
#543134: Mail notification plugin should provide a right-click menu for 
preferences (Milan Crha)
#269152: Work-around for MS Outlook/Lookout that use X-MimeOLE (Milan 
Crha)
#200147: Added basic Template support (Bharath Acharya)
#206592: Action to invoke New Message window from the composer itself 
(Milan Crha)
#207802: Do not allow drop messages to the same message list as is the 
source. (Milan Crha)
#243201: Escape rule title so that can contain also XML entities in the 
file (Milan Crha)
#310988: Don't even show the send-options action unless an Exchange 
or GroupWise account appears in the From combo box (Matthew Barnes)
#318089: Ask for destination source only when have more than one 
writable source defined (Milan Crha)
#329821: Show tooltips over task's table (Milan Crha)
#368038: Ensure only one Birthdays  Anniversaries source (Milan Crha)
#370731: (Novell Bugzilla) Use MAX to determine the minimal size for 
each cell. This prevents the numbers and day-names from getting fuzzy when 
using large font-sizes (Suman Manjunath)
#382783: Grab focus of new rule part on adding and scroll to the bottom 
too (Milan Crha)
#395636: Added accel key Ctrl+Shift+B for collapsing all threads and 
Ctrl+/ for marking all messages as read (Roshan Kumar Singh)
#423395: Put the anchor where the message body begins and let GtkHTML 
know the anchor name to place the cursor there in caret mode on the first focus 
(Milan Crha)
#440818: Convert line to UTF-8 if not a valid one. Pretend it to be an 
ISO-8859-1 line (Rodrigo Castro)
#477082,#438479: Fixed documentation (Andre Klapper)
#478469: Changed the progress dialog to be more HIG compliant (Milan 
Crha)
#519536: Handle freeing of data safely. (Srinivasa Ragavan)
#524130: Pass description text through 'camel_text_to_html' to have 
links clickable in a preview (Milan Crha)
#526262: Handle _title element in analogical way as title (Maciej 
Piechotka)
#530069: Don't show the configuration tab unless the selected plugin 
actually has configuration options (Matthew Barnes)
#532472: Strip the account URL (via CAMEL_URL_HIDE_ALL) before 
comparing it to the already-stripped 'transport_url', to avoid unnecessary 
password prompts (Matthew Barnes)
#532597: Do not leave selected more than one item if somebody else took 
care or reposition of the cursor row before the delete (Milan Crha)
#534039: Track folders even when Search Folders disabled, to have them 
known when enabling Search Folders on demand (Milan Crha)
#536488: Remove '~/.evolution/.running' file before backup/after 
restore, thus Evolution will not claim next start it was closed incorrectly 
(Milan Crha)
#537275: Do not pass data to the child structure if we were canceled 
(Milan Crha)
#537725: Set the autosaved flag so we don't get pestered with a save 
dialog if the user then decides to close the composer window (Matthew Barnes)
#538741: Strip preceding tabs from Date headers too (Paul Bolle)
#538908: Desensitize the send-options action unless we've selected as 
Exchange or GroupWise account. (Paul Bolle)
#539268: Do not use both filename and description if these are 
identical

Re: [Evolution-hackers] how to send emails from the terminal?

2008-07-20 Thread Srinivasa Ragavan
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

2008-07-18 Thread Srinivasa Ragavan
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.

2008-06-30 Thread Srinivasa Ragavan
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?

2008-06-17 Thread Srinivasa Ragavan
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?

2008-06-16 Thread Srinivasa Ragavan
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?

2008-06-12 Thread Srinivasa Ragavan
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

2008-06-09 Thread Srinivasa Ragavan
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

2008-06-03 Thread Srinivasa Ragavan
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?

2008-06-02 Thread Srinivasa Ragavan
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?

2008-06-02 Thread Srinivasa Ragavan
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

2008-05-29 Thread Srinivasa Ragavan
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

2008-05-28 Thread Srinivasa Ragavan
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

2008-05-21 Thread Srinivasa Ragavan
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

2008-05-16 Thread Srinivasa Ragavan
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

2008-05-13 Thread Srinivasa Ragavan
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.

2008-05-12 Thread Srinivasa Ragavan
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

2008-05-06 Thread Srinivasa Ragavan
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

2008-05-04 Thread Srinivasa Ragavan
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

2008-04-29 Thread Srinivasa Ragavan

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

2008-04-24 Thread Srinivasa Ragavan
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

2008-04-15 Thread Srinivasa Ragavan
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

2008-04-07 Thread Srinivasa Ragavan
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

2008-04-04 Thread Srinivasa Ragavan
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] checking Evolution with valgrind

2008-03-26 Thread Srinivasa Ragavan
On Tue, 2008-03-25 at 20:58 +0100, Patrick Ohly wrote:
 Hello,
 
 as part of the nightly testing that I mentioned recently I now also
 started to run evolution-data-server and the test program under
 valgrind, including --leak-check=yes. That covers the file backends for
 calendar and contacts, libical, libecal and libebook. I run with
 GLIBCXX_FORCE_NEW=1 G_SLICE=always-malloc G_DEBUG=gc-friendly

Oh Patrick, you are doing an awesome job for Evolution.

 
 My main motivation is to catch memory leaks inside the client program.
 Because I neither have the time nor the necessary insights to clean up
 Evolution itself, I rather aggressively suppress all valgrind reports
 which don't seem to be caused by my own code. I attach the current
 suppression file, just in case that a) another client developer is in
 the same situation or b) some of the Evolution developers are interested
 in the errors that are found (full stack traces are included as
 comments; there are quite some leaks, but also uninitialized memory
 accesses). All tests were done with a nightly build of Evolution trunk
 on Debian Etch over a period of the last few weeks (I could only work on
 it occasionally).

The best is that if you could track it down to Evolution, file a bug
with the valgrind traces and CC me there.
 
 Some of the leaks could be explained by SyncEvolution not freeing
 resources when it should; unfortunately this does not always show up
 with a backtrace that includes the code in SyncEvolution because the
 background thread allocates the memory. Is the following code the right
 way to free the results of the individual calls? This is what I
 currently use after each and every such call that SyncEvolution makes
 itself, but I still see leaks for memory allocated in
 build_change_list() from libecal.
 

The addressbook code seems right to me. 

-Srini

___
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

2008-03-26 Thread Srinivasa Ragavan
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

2008-03-21 Thread Srinivasa Ragavan
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

2008-03-10 Thread Srinivasa Ragavan
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)

2008-03-02 Thread Srinivasa Ragavan
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

2008-02-28 Thread Srinivasa Ragavan
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

2008-02-27 Thread Srinivasa Ragavan
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

2008-02-27 Thread Srinivasa Ragavan
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

2008-02-24 Thread Srinivasa Ragavan
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

2008-02-12 Thread Srinivasa Ragavan

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

2008-02-11 Thread Srinivasa Ragavan
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

2008-02-06 Thread Srinivasa Ragavan
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

2008-02-05 Thread Srinivasa Ragavan
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

2008-02-05 Thread Srinivasa Ragavan
==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

2008-02-05 Thread Srinivasa Ragavan
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

2008-02-04 Thread Srinivasa Ragavan
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

2008-02-04 Thread Srinivasa Ragavan
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

2008-02-04 Thread Srinivasa Ragavan
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

2008-02-04 Thread Srinivasa Ragavan

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

2008-02-04 Thread Srinivasa Ragavan
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

2008-02-03 Thread Srinivasa Ragavan
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

2008-02-03 Thread Srinivasa Ragavan
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

2008-01-29 Thread Srinivasa Ragavan
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 ...

2008-01-28 Thread Srinivasa Ragavan
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

2008-01-28 Thread Srinivasa Ragavan
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

2008-01-28 Thread Srinivasa Ragavan
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 ...

2008-01-24 Thread Srinivasa Ragavan
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


  1   2   3   >