Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
Hi.. 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: > unlock(connect_lock) > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1105209680 (LWP 11659)] > 0x003dd0a795c0 in strlen () from /lib64/libc.so.6 > (gdb) > > 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 ? -Suman ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
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. -Suman ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] cleaning up the timezone handling mess
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] :-( -Suman [1] http://blogs.msdn.com/stephen_griffin/archive/2006/12/06/outlook-2007-timezone-structures.aspx [2] http://msdn2.microsoft.com/en-us/library/ms912053.aspx [3] http://technet2.microsoft.com/WindowsVista/en/library/31f49a21-cfed-4b63-b420-58a9eabbb04e1033.mspx?mfr=true ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] mapi progress
Hi.. On Thu, May 29, 2008 at 1:34 PM, William John Murray <[EMAIL PROTECTED]> wrote: > > Hello all, > I have noticed new libmapi builds on jjohnny's repo > getting pulled by my Fedora recently, so I try them again > on Exchange 2003. Unfortunately no luck yet - it still reads > the folder structure and then crashes, ending with: > > 0 Total : 1 >OpenFolder : MAPI_E_NOT_FOUND (0x8004010F) > |---+ Tasks : (Container class: IPF.Task 8BD1C1010010) > UnRead : 0 Total : 7 > |---+ Trash : (Container class: IPF.Note 69BDFF0E) > UnRead : 6 Total : 25 > libexchangemapi-Message: exchange-mapi-connection.c(1952): > exchange_mapi_get_folders_list: unlock(connect_lock) > exchange-mapi-connection.c(1954): Leaving > exchange_mapi_get_folders_list > ./evolution-start.sh: line 8: 9389 Segmentation fault evolution can you run it under gdb and send me/jony a backtrace? here's what-to-do: $ gdb evolution $ (in the gdb console) r -c mail $ (when the crash occurs) thread apply all bt > anyway, my question was, is there any discussion group or anything > where I can see what is supposed to change with these releases? well.. one notable feature-add was delta fetching in calendars/tasks/memos. although, there have been lots of fixes.. :) [off-topic] The build service project now hosts opensuse-10.3/factory and fedora 8/9. -Suman ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI branch status?
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]. regards, -Suman [1] see http://mailman.openchange.org/pipermail/devel/2008-April/000619.html ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI backend
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. -Suman ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [ANN] Evolution-mapi moved to new SVN repository
On Wed, Nov 19, 2008 at 11:18, Johnny Jacob <[EMAIL PROTECTED]> wrote: > We will be creating a new bugzilla component in bugzilla.gnome.org for > evolution-mapi. This is done! Please report bugs under the product name: evolution-mapi -Suman ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] concurrent modifications of items in GUI and EDS database
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 >items > * 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 > occur: > * 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 [1] http://tools.ietf.org/html/rfc2445 [2] http://tools.ietf.org/html/rfc2445#section-4.8.7.4 [3] ht
Re: [Evolution-hackers] concurrent modifications of items in GUI and EDS database
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" = > https://bugzilla.novell.com/show_bug.cgi?id=184554 ? Yep.. it is this ^^ bug. And I agree with Chen that it needs a fix at the backend. -Suman ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Evolution] Evolution 2.24.3 and beyond
On Mon, Jan 12, 2009 at 18:09, Alpár Jüttner wrote: > Hi, > > What are the actual changes compared to 2.24.2? > Is a release note available somewhere? Always. Go ftp://ftp.gnome.org/pub/GNOME/sources/evolution/2.24/evolution-2.24.3.news -Suman ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] MAPI support of Evo and Windows port
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. -Suman ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] FYI: new iCalendar
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. > > http://www.rfc-editor.org/rfc/rfc5545.txt). 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 similar. -Suman ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Changes from 2.26 to 2.28
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. -Suman ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Anyone doing nightly builds for SUSE?
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)? http://download.opensuse.org/repositories/GNOME://Evolution://snapshots/openSUSE_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 > headache. 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 > dependencies. 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. HTH -Suman ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Openchange website/svn/etc. down?
On Mon, 2009-12-07 at 10:30 -0500, Paul Smith wrote: > Anyone know what's going on with Openchange? I can't reach their > website, their SVN repository, etc...? Attached is the last mail I received from their devel list (12/05/2009). They were scheduled for a maintenance downtime. Don't know the status since then. -Suman [openchange][devel]_Server_maintenance Description: application/mbox ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Anyone doing nightly builds for SUSE?
On Fri, 2009-12-04 at 17:00 -0500, Suman Manjunath wrote: > 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)? > > http://download.opensuse.org/repositories/GNOME://Evolution://snapshots/openSUSE_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 > > headache. > > 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. The snapshots repository is now building git master. It may take a while before all the mirrors show the updates. Also the MAPI repository: http://download.opensuse.org/repositories/GNOME://Evolution://mapi/ is building Samba 4 alpha 10, (soon to be) libmapi 0.9 and evolution-mapi 0.29.3. However, evolution-mapi 0.29.3 is not available for the 11.2 repository without the snapshots (evolution-mapi has a dependency on e-d-s 2.29.1) > HTH > > -Suman > ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Anyone doing nightly builds for SUSE?
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 > libgtkimageview.so.0 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. -Suman ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Build failures with latest git in evolution-mapi
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. -Suman ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Merging the collaboration providers in a single package
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 >> <1287408711.3126.11.ca...@localhost.localdomain>, 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 >> > alone. >> > >> > 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: >> > http://mail.gnome.org/archives/desktop-devel-list/2010-October/msg00049.html > 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 >> benefits. 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 ;-) -Suman ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
