Re: [Evolution-hackers] Merging the collaboration providers in a single package

2010-10-19 Thread Suman Manjunath
On Tue, Oct 19, 2010 at 04:31, chen wrote:
 On Mon, 2010-10-18 at 09:21 -0600, Sankar P wrote:
  On 10/18/2010 at 07:01 PM, in message, Matthew Barnes wrote:
  On Mon, 2010-10-18 at 12:10 +0530, chen wrote:
   The other solution was to maintain all exchange providers in a single
   package, merging evolution-exchange, evolution-ews and evolution-mapi
   into a single package. Other collaboration providers like
   evolution-groupwise and evolution-kolab (yet to be upstreamed) will
   remain as separate packages.
  If we -have- to glob providers together I would prefer the alternate
  solution: merge all the Exchange providers into one git module, break
  GroupWise out from E-D-S into it's own git module, and leave the rest
  This is not unlike the recent gnome-games debate on desktop-devel-list,
  except that we already have shared libraries for the common parts with
  fairly stable APIs (libebook, libecal, etc.).
  Jon's comments on the gnome-games issue reflect my own for this one:
 The control/ownership of the code can be made clear using provider-level
 maintainer-ship (like groupwise, exchange, kolab2 maintainers etc.)
 inside a single package. Of-course package is one, but with independent
 sub-modules and owners.

 Is there any other disadvantage or point of concern ?

I somewhat agree with Matthew on this one. If we glob all the
providers together:

a) Distro A doesn't want to support Provider X. You'd say we'll have a
compiler option to not compile X. Why does Distro A even need the
sources for X (and eventually ship it too)?

b) If we put all the providers together, and this is from what I've
seen happening, there is this tendency for code to get duplicated.
Along with good designs, sometimes bad designs also get duplicated.

 I prefer not to have every provider in its own module.  If we make changes 
 in the baseclass, it will be ignored and won't go into unmaintained 
 providers. More providers translates to more work for packagers downstream 
 and also during the release time for maintainers as well, with not much 

If a module has an owner, how is it unmaintained?

As a packager, if we do glob the modules together, the first thing
that would happen is a split-up of the built files into their own
sub-packages in the spec. How is this any different from having two
separate packages?

 Just my 2 cents.
 I agree. I would not term as un-maintained providers. If they are really
 un-maintained, which means many bugs exist and people are not able to
 use it, it has to be pruned at some point.

 But certainly I see advantages to have the providers in a single package
 which would help us adapt to the API changes well, translations could be
 shared, packagers can look for updates for one package and maintainers
 would have less burden in releasing many packages.

Turning it around the other way, if a change in the globbed package
means nothing to the provider I'm using or interested in, what's in it
for me to update the package? :-)

If a module is maintained, the API changes will eventually get there.
Besides, you shouldn't be changing the base API that often anyway ;-)

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Re: [Evolution-hackers] Build failures with latest git in evolution-mapi

2010-02-02 Thread Suman Manjunath
On Tue, 2010-02-02 at 16:57 -0500, Paul Smith wrote:
 Hi all;
 Since the openchange project recently added a new feature, I think there
 are compile problems in evolution-mapi.  Doing a full git upgrade (and
 svn upgrade of openchange) an hour or two ago, then a complete clean
 build, I get these warnings (the warnings MIGHT have been there before,
 I can't remember) and then the compile errors, which definitely were not
 there before.

Do you have the right Samba alpha? 

OTOH, you are better of sticking with the released version of openchange
and samba. 0.9 and alpha10 respectively. I don't think evo-mapi uses the
latest svn revision of openchange anymore. Johnny would know better.


Evolution-hackers mailing list

Re: [Evolution-hackers] Anyone doing nightly builds for SUSE?

2010-01-28 Thread Suman Manjunath
On Thu, 2010-01-28 at 09:16 -0600, John Lange wrote:
 On Thu, 2010-01-28 at 15:50 +0530, Bharath Acharya wrote:
  The nightly builds were broken because of some IMAPX issues. They
 are up
  now, but would be updated every week, no nightly builds.
  The nightly builds now have 2.29.6+ running.
 Thanks. I gave it a quick try and it complains that Nothing provides 64 bit. Just thought I'd let you know.

Make sure libgtkimageview0 is installed on your machine. Run: 

$ rpm -qa | grep libgtkimageview 

If it is installed, run /sbin/ldconfig as root. You should no longer see
that issue. If it is not, install libgtkimageview: 

$ zypper in -y libgtkimageview0 

and evolution should no longer complain. 


Evolution-hackers mailing list

Re: [Evolution-hackers] Anyone doing nightly builds for SUSE?

2009-12-04 Thread Suman Manjunath
On Fri, 2009-12-04 at 15:17 -0600, John Lange wrote:
 Just curious if anyone is doing nightly (or frequent) package builds for
 SUSE (11.2)?

 I'd like to test some of the new features and bug fixes but in the past,
 when I've tried to use packages from openSUSE Factory, it also had
 dependencies on newer versions of the entire gnome stack which was a big

The above repository was meant to host daily snapshots of the vanilla
code. Right now though, it is picking up code from the 2.28 branch. I'll
try to get it to compile the 2.29 series over the holidays. 

 Barring that, what would be the best way to test the current unstable
 release of Evolution? Should I just compile it from source and run it
 from my home directory? Again, I fear the list of dev package

AFAIK, you only have to install the -devel packages of all the deps.
Shouldn't be harder than having to compile it :-) 
Also, the GNOME:Factory repo is updated with every unstable GNOME
release. You may want to try that as well. 



Evolution-hackers mailing list

Re: [Evolution-hackers] Changes from 2.26 to 2.28

2009-10-04 Thread Suman Manjunath
On Sat, 2009-10-03 at 21:47 -0400, Rohan Agrawal wrote:

   * The Date column now shows 24-hour times rather than 12 hour
 times, and there doesn't seem to be a way to change it.

Untrue. Go to:
Edit - Preferences - Calendar and Tasks - (under the General tab)
Time format.

A new feature of changing the displayed time format was added in 2.28.
To tweak this, go to: 
Edit - Preferences - Calendar and Tasks - (under the Display tab)
Date/Time format. 


Evolution-hackers mailing list

Re: [Evolution-hackers] FYI: new iCalendar

2009-09-26 Thread Suman Manjunath
On Sat, 2009-09-26 at 11:37 -0400, Matthew Barnes wrote:
 On Sat, 2009-09-26 at 15:21 +0200, Butrus Damaskus wrote:
  New version of iCalendar was accepted as RFC 5545 (see eg. Does this mean something
  for evolution development? :-o
 Looks like it's basically just errata from RFC 2445 (see page 166).  I'm
 sure the corrections can be implemented or verified pretty easily.  The
 burden may fall on the Free Association project as much as if not more
 so than on us.

Wondering why it is an entirely new RFC for a bunch (11 to be precise)
of errata. It could easily have been RFC 2445 spec 2 or something


Evolution-hackers mailing list

Re: [Evolution-hackers] MAPI support of Evo and Windows port

2009-07-15 Thread Suman Manjunath
2009/7/15 Jelmer Vernooij


 Also do you know about ongoing efforts of MAPI port to Windows. We are
 interested in running Evo on Windows with Exchange 2007 server. What is
 the status of the port, and how can we help?

 I wasn't aware there was such a project. Wouldn't this involve porting
 Samba 4 and OpenChange as well?

There is no evolution-mapi port on Windows as of today.

Evolution-hackers mailing list

Re: [Evolution-hackers] [Evolution] Evolution 2.24.3 and beyond

2009-01-12 Thread Suman Manjunath
On Mon, Jan 12, 2009 at 18:09, Alpár Jüttner wrote:

 What are the actual changes compared to 2.24.2?
 Is a release note available somewhere?

Always. Go

Evolution-hackers mailing list

Re: [Evolution-hackers] concurrent modifications of items in GUI and EDS database

2009-01-08 Thread Suman Manjunath
On Thu, Jan 8, 2009 at 15:19, Patrick Ohly wrote:
 The GroupWise server updates the 'modified' property of the item when
 it actually gets modified on the server. For newly created items, it
 also adds the 'created' property at the same time.

 This behavior invalidates all the 'handle-at-backend' approaches to
 fix the apparent bug,

 the apparent bug = ?

Yep.. it is this ^^ bug. And I agree with Chen that it needs a fix at
the backend.

Evolution-hackers mailing list

Re: [Evolution-hackers] concurrent modifications of items in GUI and EDS database

2009-01-07 Thread Suman Manjunath
On Wed, Jan 7, 2009 at 17:15, Patrick Ohly wrote:
 The plan for change tracking is to get rid of the dependency on
 e_book_get_changes(). I already stopped using e_cal_get_changes()
 because it was too inflexible. Instead I'll rely on the REV resp.
 LAST-MODIFIED properties: the backend must update these each time an
 item is modified. This seems to be supported by most backends. Are there
 backends which are known to not support this?

a) Looking at [1], I can't find what a REV property is. Did you mean
to use [2] ?

 The problem with concurrent modifications is two-fold.
 Stale data in UI:
  * user opens an item in Evolution
  * synchronization starts in the background
  * updates the item in EDS
  * = When the user saves his changes, will he overwrite the more
recent data in EDS? Will he be warned? With Evolution the user
is not warned and his changes overwrite the ones in EDS (tested
with contacts). Evolution should listen for change signals and
warn the user as soon as he has stale data in the edit dialog.
The user then can cancel and reopen the item to redo his
changes. This is unlikely to happen often, so more elaborate
solutions (merging changes, additional buttons to copy from EDS)
should not be necessary. Should I file a bug for this? Anyone
able and willing to work on it?

Not so for calendars. When an event is open in the Evolution UI and
the backend modifies it during a refresh/update from server, the user
_is_ warned of an update to the item. If not, the backend is probably
not doing a e_cal_backend_notify_object_modified() which it ought to.
FWIW, see the open bug at [3].

 Stale data in sync:
  * when the sync starts, it builds a list of new/updated/deleted
  * user modifies data in EDS
  * this leads to conflicts, f.i. sync modifies item that was
modified by user

 Both cases need to be handled by the program which wants to make changes
 to EDS data (Evolution, sync engine). To avoid race conditions, support
 by EDS would be needed which currently doesn't exist. As a workaround
 the following method would reduce the time window in which conflicts can
  * get revstring before starting to make modifications (when
opening item in UI; when starting sync)
  * before modifying the item, check the revstring again
  * if the same as before, do the modification
  * if different, handle conflict

The GroupWise server updates the 'modified' property of the item when
it actually gets modified on the server. For newly created items, it
also adds the 'created' property at the same time.

This behavior invalidates all the 'handle-at-backend' approaches to
fix the apparent bug, like:
* Check if the item is newly-created by looking for a 'modified'
property in the cached-object. This approach does not handle modifying
an older (and already cached from server) item.
* Pushing the 'modified' property from the client to the server upon
creation/modification. This does not help, since the server would
modify the property anyway.
* A series of 'if-else' trying to handle various scenarios. It was
observed that the conditions would fail for at-least one use-case,
mainly since we would not have a persistent 'last-modified' time
unless it is obtained from the server.

These drawbacks probably apply to the Exchange backend too.

 A secure solution would have to put the revision check into EDS itself
 to make the check and update atomic. The proposal is to add this check
 to e_book_commit_contact() and e_cal_modify_object():
  * The caller is expected to include REV resp. LAST-MODIFIED as
read from EDS earlier.
  * The EDS backend compares against the current value before
updating the item. If there is a mismatch, the update is
rejected with a suitable error code.
  * If the values are unset, the update is always executed.

A backend may not have a LAST-MODIFIED property for a particular event
in this use case:
a) create a new appointment in the GW calendar (while online)
b) open the same appointment (before the refresh timeout)

Pushing an update in this case is not correct as the event can easily
be modified by another client during that refresh interval.

We should ensure that the cached object in EDS will always have the
same last-modified property as that on the server before opening the
event in the UI [This probably implies an (expensive?) 'live' re-cache
of the object being opened]. We already listen for changes to the
event and so the user automatically knows if anything changed since
opening the event editor.

We don't continuously listen for updates from the server and hence the
problem I mentioned above would still exist, but that is something I
can live with :)

- Suman


Re: [Evolution-hackers] [ANN] Evolution-mapi moved to new SVN repository

2008-11-22 Thread Suman Manjunath
On Wed, Nov 19, 2008 at 11:18, Johnny Jacob [EMAIL PROTECTED] wrote:
 We will be creating a new bugzilla component in for 

This is done! Please report bugs under the product name: evolution-mapi

Evolution-hackers mailing list

Re: [Evolution-hackers] MAPI backend

2008-09-05 Thread Suman Manjunath
On Tue, Sep 2, 2008 at 11:17 PM, Patrick Ohly [EMAIL PROTECTED] wrote:
 On Tue, 2008-08-19 at 20:22 +0200, Patrick Ohly wrote:
 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].

will take a look later today :-)

 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.

Just added recurrence support in r9483 (Note: You need to update to
LibMAPI r710)
Except 'modifying single instances of recurring appointments', all
sorts of recurrence-rules which are supported by evolution are
fetched/can be set.

 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

this might be related to fetching the PR_BODY_HTML property. I've
removed it in my last commit. Lemme know if you still see this issue.

Evolution-hackers mailing list

Re: [Evolution-hackers] MAPI branch status?

2008-06-16 Thread Suman Manjunath
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


  (*) free busy lookup

Nope.. this is not in progress but is on the roadmap. We are
currently using libMAPI-0.7. Free/Busy lookup is something planned for
libMAPI-0.8 [1].


[1] see
Evolution-hackers mailing list

Re: [Evolution-hackers] cleaning up the timezone handling mess

2008-04-16 Thread Suman Manjunath
On Wed, Apr 16, 2008 at 10:00 PM, Patrick Ohly [EMAIL PROTECTED] wrote:
 On Wed, 2008-04-16 at 13:59 +0530, chenthill palanisamy wrote:
I don't get this part. Can you elaborate what you mean? Are you saying
that storing a VTIMEZONE with TZID=FOO as TZID=FOO 2 when it conflicts
with an existing VTIMEZONE should be avoided?
   yes, if  libical is modified to return VTIMEZONE with the history and
   once mapping between foreign timezones to system timezones is done at
   the backend, this is would not be required. All the older events would
   be properly displayed.

  You assume that the mapping works in all cases. I don't think this is
  realistic. There will always be a program FOO somewhere, somewhen using
  a TZID=BAR which is unknown to Evolution and thus cannot be mapped. Even
  getting this right just for Outlook alone will be challenging and
  require permanent maintenance.

Very true.. it was/is a serious PITA while I was figuring out the
details for the MAPI provider.
On the brighter side, Exchange/Outlook 2007 has got this sorted out to
an extent. They now store the historical rules in the timezone blob.
See [1].
(The MAPI provider does not yet makes use of these rules, it only
identifies the timezone - maps it to one of the system timezones -
then uses the system timezone information to generate the start-end
times of the event.. its a todo on my list to make use of the stored
information :-) )

And, like you have mentioned, the mapping needs constant maintenance
despite publications like [2] or [3] :-(


Evolution-hackers mailing list

Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview

2008-02-06 Thread Suman Manjunath
Hello Per, everyone

here's one important FYI from Julien Kerihuel of openchange:

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.

request all of you to ensure that this setting is correct when using the
MAPI plugin. :)
apparently, this bug could sort-of be caught as soon as the profile-creation
happens.. will be looking more into it tomorrow.. although we might end up
getting the same MAPI_E_CALL_FAILED, it could be possible to identify if it
failed because of the above-mentioned reason.

Evolution-hackers mailing list

Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview

2008-02-04 Thread Suman Manjunath

On Feb 4, 2008 9:58 PM, William John Murray [EMAIL PROTECTED] wrote:

  Hi Srinivasa,
Hm, I have the debug rpm,
 evolution-mapi-provider-debuginfo-20080118.3-2.1 but I am not sure how
 to use it! If I run in ddd I see this - is it enough info?


 EcDoRpc_MAPI_REPL_UNION(case 21)
mapi_QueryRows: struct QueryRows_repl
unknown  : 0x02 (2)
results_count: 0x (0)
layout   : 0x00 (0)
mapi_response: (handles) number=1
handle id: 0x0f14 (3860)
length   : *
length   : 0x000f (15)
result   : MAPI_E_SUCCESS (0x0)
 exchange-mapi-connection.c(1631): exchange_mapi_get_folders_list:

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 1105209680 (LWP 11659)]
 0x003dd0a795c0 in strlen () from /lib64/

almost enough :) .. could you just get a backtrace at the SIGSEGV (type
'thread apply all bt full' at the terminal when you get the gdb prompt after
the SIGSEGV) and paste the output here ?

Evolution-hackers mailing list

Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview

2008-01-19 Thread Suman

On Jan 18, 2008 10:21 PM, Holger Goetz [EMAIL PROTECTED] wrote:

Is there any magic beside of

 exporting the LD_LIBRARY_PATH for samba4
 and activating the plugin,

 to get a MAPI or alike selection the the Server Type drop down? (The
 plugin is there and can be activated/is activated)

The name of the plugin is 'Exchange MAPI'. The same name is used in the
Server Type dropdown as well.. If the plugin is activated and you still
can't find the server type in the dropdown - something is wrong. (start Evo
in a terminal and look for a message like 'Unable to load plugin 'XYZ' -
could not find shared object '' etc.,)

 BTW: tested on 2 systems: Ubuntu 7.02, Evolution 2.12.1 and plain
 debian-sid 2.12.2-1+b1 ...
 Couldn't test w/ 2.21.90 from trunk of svn - as the rpm's install in
 default libs and not into /opt/evo/ or alike.

Just to make it crystal clear, you may either:

+ install the RPMs from the URL Johnny mentioned...
+ build from source from the following branches (and not SVN trunk)

I had posted the configure options needed sometime ago here -

Evolution-hackers mailing list

Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview

2008-01-18 Thread Suman
Just to give a heads-up on what WON'T work w.r.t. calendars/tasks/memos:

+ no meetings/assigned tasks support.. (we're waiting on a few APIs to be
made available by libmapi)
+ no recurring events [1]
+ freebusy info (the first point would make this irrelavant.. but..)

The rest of the basic features would *mostly* work..
Comparing the plugin to the current Exchange connector.. feature-wise...
MAPI stilll has a long way to go.. :)

Looking forward to a lot of people trying/testing the RPMs and getting back
to us with their invaluable feedback.. TIA !!

[1] events = appointments/meetings.. unfortunately, Evolution does not
support recurring tasks yet.. so.. don't wait on that..


P.S. ohhh... btw.. Outlook notes ~= Evolution memos..

On Jan 18, 2008 7:50 PM, Jacob Johnny [EMAIL PROTECTED] wrote:

 Hello guys,

 This is an announce mail for the preview of Evolution MAPI provider.
 This provider can connect to Exchange 2007 servers and also to Exchange
 2003, 2000 and 5.5 (untested).

 After seeing enormous interest by the users in Exchange 2007
 connectivity, we have prepared a preview of the current development code
 from the branch. The evolution-mapi-provider is a standalone rpm but in
 future it may be part of the Evolution/EDS rpms. It has a dependency on
 OpenChange's ( ) libmapi and Samba4.

 I'm maintaining the build service project for the provider and I'm
 planning to give RPMs for OpenSUSE, SLED, Fedora and Ubuntu. We would be
 doing incremental releases of this periodically and may have nightly
 builds for this pretty soon (Don't ask me when ;-)

 The below url should let you access the Samba4, libmapi and Evolution
 MAPI Provider rpms.

 Due to the recent outage of OpenSUSE Build Service, we aren't able to
 get the rpms ready. So I have built RPMs for opensuse 10.3/i586 alone
 and is available at:

 The build for the project is already queued. So it is possible that by
 the time, you read the mail, the rpms might have been published already.
 So go check out and give your valuable feedback.


  * The build could be very unstable and may crash frequently.
  * Don't report these issues on to Evolution bugzilla atm. We will
create the components and let you all know it. Mean while, you
can write your comments/bugs at and we will
migrate them to bugzilla a little later.
  * It is not yet feature complete. We don't have public folders/GAL
yet. EMail subjects appear corrupted and lots of other known
issues :)
  * Most of the features are untested
  * You need to export the Samba4 LD_LIBRARY_PATH=/opt/samba4/lib
  * At Last: I'm not responsible for any serious damage caused due
to the package. So try it at your own risk!!! :)


Evolution-hackers mailing list

Re: [Evolution-hackers] Evolution 2.21.4 , Evolution-Data-Server 2.21.4 , GtkHTML3.17.4 and Evolution-Exchange 2.21.4 released

2007-12-19 Thread Suman
On Dec 19, 2007 10:42 PM, Matthew Barnes [EMAIL PROTECTED] wrote:

 On Wed, 2007-12-19 at 22:14 +0530, Suman wrote:
  EDS/Evolution does not seem to respect the --disable-gtk-doc configure
  option. (not sure if this is a bug in the configure scripts of
  Any thoughts ?

 Works for me with EDS, and Evolution doesn't have that option anymore.

 What do you see in the little summary when configure terminates?

evolution-data-server has been configured as follows:
Gtk Doc: [yes/no]

I see this:'Gtk Doc: no'

 Matthew Barnes

Evolution-hackers mailing list

Re: [Evolution-hackers] [Evolution] Current issues with Evolution 2.12 / Exchange

2007-09-20 Thread Suman
Hi Paul..

On 20/09/2007, Paul Smith [EMAIL PROTECTED] wrote:

  Hi all;

 This seemed useful to some people last time, so I'm doing it again now.
 I've been using Evolution from SVN for a few months now tracking the latest
 changes and overall I've been REALLY happy: so many things are much better,
 especially with Exchange integration, than in 2.10 or any previous
 release.  Applause and cheers for everyone's hard work over the last 6

 However, there are still some issues.  I hope now is a good time to point
 them out so maybe we can concentrate on these for 2.12.1 or 2.12.2.
 Others might have a different list of issues, but these are mine (links to
 bugzilla entries).  I've updated the bugzilla entries with the latest info I

 As I said, I'm building Evo and all components (libsoup, gtkhtml, e-d-s,
 evo, evo-exchange, evo-webcal) locally with debugging enabled and running
 them with full logging, each instance in its own directory.  I stand ready
 and willing to help anyone who wants to, to work on these issues!  I've
 tried to order them in order of precedence (how much I want them fixed),
 most pain to lesser pain.

478090: Tried to create a meeting on the Exchange server, and Evo crashed
 when adding an address

 This is a big one for me, because I need to schedule meetings through this
 mailing list.  Because of this problem I have to create my meetings through
 Exchange webmail rather than Evolution!  Luckily (in all senses of the word)
 I don't have to create meetings very often.

 the link:

478090: Meeting acceptances for attendees who weren't listed are

 This isn't a huge deal, but it's pretty annoying.

 Thanks for the input !!


  Paul D. Smith [EMAIL PROTECTED] 
  Please remain calm--I may be mad, but I am a professional.--Mad Scientist

Evolution-hackers mailing list