Re: [Evolution-hackers] Fedora builds with 2.32.2+ patches
Hi David, On Thu, Apr 07, 2011 at 01:07:38PM +0100, David Woodhouse wrote: Personally, no. I'd rather ignore MAPI completely and get on with the implementation of evolution-ews. Understandable, though as we've discussed on IRC we don't really have the option of using that here, at least for another couple quarters. I have quite the patch queue (maybe 10-20 patches) that I'm managing locally for various backported fixes there. Sounds like you would be in a good position to do it though. Because I'm not a gnome dev, I (a) don't have push access, and (b) am a bit hesitant to go against Milan's wishes, since he's the dev who is primarily keeping things up for -mapi and has made his stance pretty clear. I only brought it up because it seemed like there might be a change in that stance, and if so I'd be happy to share my currently unshared fixes in .32. Then again, now that 3.0 is released I may try again to get something rolled together based on that since there are already a number of api breaks making backports difficult for .32, and it seems there are lots more in the pipe for 3.1. sean ___ 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] Calendar PIM objects with inlined attachments
Hi everyone. While working on the evolution-kolab plugin, we found that there is no direct support in ECalComponent for attachments inlined into calendar objects. Thus, so far, we can cope with attachments inlined into Kolab calendar objects by hiding them in private ical fields. That way, we can preserve the attachment when writing back some calendar object to the Kolab server which has one attached. The drawback, however, is that we can access this (ical-private) attachment data via ECalComponent neither for reading nor for writing - it will just be invisible to the evolution-kolab plugin user, and they will get no indication that an object carries attachment data (they might just wonder why it takes much time retrieving and storing the object). We could use Evolution's file-link attachment mechanism by writing into Evos file cache from the backend and placing the file paths into the ECalComponent when reading calendar objects from the Kolab server, and read attachment file data from this same cache when creating a new object with attached files. We found a whole lot of issues with this approach (at least for Evo2.30), which I can detail if anyone is interested. Before trying anything with the at-least-problematic file cache approach, I thought I'll go ahead and see whether there is anything in the plannings regarding supporting inlined file attachments directly with ECalComponent in latest Evo versions. So far, I did not find anything related on the plannings pages. I'm not clear whether this has been discussed before or whether there are any current plans of extending ECalComponent to support inlined attachments directly (in which case a rather simple change to Evo would allow for supporing inlined attachments in a clean way). I'd like to know your opinions / ideas / ... on that matter. Greetings, Christian PS.:For those who followed the short discussion of the issue on #evolution yesterday, I thought it would be better to record the discussion on the list, so please feel free to paste your thoughts here again - just for the record :) -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ 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] Fedora builds with 2.32.2+ patches
On Fri, 2011-04-08 at 09:54 +0200, sean finney wrote: Sounds like you would be in a good position to do it though. Because I'm not a gnome dev, I (a) don't have push access, and (b) am a bit hesitant to go against Milan's wishes, since he's the dev who is primarily keeping things up for -mapi and has made his stance pretty clear. I only brought it up because it seemed like there might be a change in that stance, and if so I'd be happy to share my currently unshared fixes in .32. You're more than welcome to use git.infradead.org if you want. But even if Milan sees the 2.32 branch as being dead and doesn't want to spend any of his own time on it (and nobody can blame him for that), I would hope that he wouldn't try to obstruct *you* if you feel you need to do so. Then again, now that 3.0 is released I may try again to get something rolled together based on that since there are already a number of api breaks making backports difficult for .32, and it seems there are lots more in the pipe for 3.1. Certainly, my point in maintaining fixes for 2.32 was *not* to discourage people from upgrading. So if 3.0 is a viable option for you then please do go ahead. Having said that, the API breaks haven't *yet* reached the point where we can't build evo-ews for 2.32 and 3.x from the *same* code base, albeit with a number of icky ifdefs. -- dwmw2 ___ 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] Fedora builds with 2.32.2+ patches
On Thu, 2011-04-07 at 15:08 +0200, Milan Crha wrote: Hmm, I still do not like the idea of adding things to gnome-2-32 branch, I thought I saw you telling that if anyone will complain then you'll not do that and I thought I complained to it, but I cannot find the email right now, so I cannot point to the logic error I see in such statement. :) Sorry, I do still owe you a reply to that. Shortly... -- dwmw2 ___ 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] Calendar PIM objects with inlined attachments
On Fri, 2011-04-08 at 10:04 +0200, Christian Hilberg wrote: We could use Evolution's file-link attachment mechanism by writing into Evos file cache from the backend and placing the file paths into the ECalComponent when reading calendar objects from the Kolab server, and read attachment file data from this same cache when creating a new object with attached files. We found a whole lot of issues with this approach (at least for Evo2.30), which I can detail if anyone is interested. Hi, CalDAV calendar plugin uses this approach, and it seems to work. It's surely better than passing rather-long attachments over the wire (D-Bus) in both ways. Check the CalDAV sources how it's done there, maybe you would be able to mimic that approach. Hope that helps, Milan ___ 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] Fedora builds with 2.32.2+ patches
Hi David, On Fri, Apr 08, 2011 at 09:08:28AM +0100, David Woodhouse wrote: You're more than welcome to use git.infradead.org if you want. But even if Milan sees the 2.32 branch as being dead and doesn't want to spend any of his own time on it (and nobody can blame him for that), I would hope that he wouldn't try to obstruct *you* if you feel you need to do so. Well it would be nice to get them *somewhere*, anyway, since it does feel silly that there are a number of distro's and organizations in the same situation who are forced to basically do the same work and have no way to cooperate. Maybe we can fix something out-of-band from this discussion then, and leave it as an internal decision for the evo team whether or not to include them. Then again, now that 3.0 is released I may try again to get something rolled together based on that since there are already a number of api breaks making backports difficult for .32, and it seems there are lots more in the pipe for 3.1. Certainly, my point in maintaining fixes for 2.32 was *not* to discourage people from upgrading. So if 3.0 is a viable option for you then please do go ahead. I'd certainly like to upgrade if possible to stay relatively current, but also have implementation constraints about installation size and compatability with being run from older gnome desktops. And last time i tried (about a month pre-release) it didn't pan out so well. Sean -- ___ 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] Maintenance fork for Evolution / EDS 2.32
On Mon, 2011-04-04 at 08:53 +0200, Milan Crha wrote: On Fri, 2011-04-01 at 20:07 +0100, David Woodhouse wrote: That's great; thanks. I'll do a little more testing on the patches I've cherry-picked into my trees, and then unless someone else has objected in the meantime I'll push them. Hi, I objected against this many times, directly to you, on IRC, with no effect, obviously. If I recall correctly, the reason why release-team decreased releases is that distributions were *not* using .2 release. Which is just the opposite you are trying to convince us. If they are not using official releases, why should they use unofficial branch? Fedora does. As Yves-Alexis said, Debian (and thus Ubuntu?) does. And MeeGo does. Even before we start looking at other distributions, that is *enough* duplication of effort that it seems worthwhile to collaborate on a single code base rather than each having their own 'fork' and backporting fixes from HEAD for themselves. By the way, how would you look for a fix user reported to your distribution, as a distribution maintainer? ... Note that I do not expect anyone looking into git branch for a particular fix, ... That's all very true, for a *specific* fix for a bug that a user has managed to report. Having said that, if the distro *were* currently running 2.32.1, I'd hope the 'workflow' you outline would *also* include checking in the gnome-2-32 branch to see if the fix has *already* been backported and tested there? By collecting the backported patches into a central tree, we don't break the workflow you describe — it stills works just as before, with an extra 'shortcut' to a fully-backported-and-tested patch in some cases. But I'm not thinking *just* about specific fixes for bugs that get reported. Part of the benefit of a central tree is that if a bug gets reported in *one* distribution and fixed there, the backported fix can benefit users of *all* distributions. Take the issue with ordering of modified recurrences, for example. How many users would manage to actually track that down and make a coherent bug report, and how many would just be inconvenienced by the fact that changes sometimes don't show up right in Evolution, and put it down to gremlins? I feel sure that the reason that bug went unreported for so long was *not* because nobody actually *saw* it. By putting that fix into a 2.32.3 release, we potentially get that fix out to a large number of users of distributions who are stil on 2.32 (which includes Fedora, for the next 8 months or so). I appreciate that you think I'm wasting my time. Perhaps I am; time will tell. But my time is my own to waste. My main concern is to ensure that I'm not wasting *your* time. And since you can choose to completely ignore what we're doing in the gnome-2-32 branch, I think we're safe on that front. -- dwmw2 ___ 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] Calendar PIM objects with inlined attachments
On Fri, 2011-04-08 at 10:35 +0200, Milan Crha wrote: On Fri, 2011-04-08 at 10:04 +0200, Christian Hilberg wrote: We could use Evolution's file-link attachment mechanism by writing into Evos file cache from the backend and placing the file paths into the ECalComponent when reading calendar objects from the Kolab server, and read attachment file data from this same cache when creating a new object with attached files. We found a whole lot of issues with this approach (at least for Evo2.30), which I can detail if anyone is interested. Hi, CalDAV calendar plugin uses this approach, and it seems to work. It's surely better than passing rather-long attachments over the wire (D-Bus) in both ways. Check the CalDAV sources how it's done there, maybe you would be able to mimic that approach. That's what we're doing in EWS, too. We store the attachments into the backend's cache directory as obtained by e_cal_backend_get_cache_dir(), and we set a file:// URL to point to them there. (If you have the MIME Content-Type: for it, don't forget to put that into a FMTTYPE parameter in the ical ATTACH property.) I'm actually not *entirely* happy with that approach; I didn't really want to fetch all the attachments in advance. I'd prefer to fetch them on demand, instead. I was toying with the idea of adding a new URL scheme to represent the 'location' of such attachments, and working out how to make that work in Evolution. It would presumably need to translate into a DBus call to evolution-data-server, and some method of passing the data back. Perhaps the best option is to have a call to EDS which asks it to 'resolve' the attachment into a local file URL instead of a remote one? For now, I've just stuck with the naïve approach of fetching them all in advance, but I'd like to have a plan for how to fix that, when it bubbles up to the top of my TODO list for EWS. And you may want something similar for kolab? -- dwmw2 ___ 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] Calendar PIM objects with inlined attachments
On Fri, 2011-04-08 at 12:17 +0100, David Woodhouse wrote: Perhaps the best option is to have a call to EDS which asks it to 'resolve' the attachment into a local file URL instead of a remote one? The more I think about this, the more I like it. Add an X-EVOLUTION-UNRESOLVED-ATTACH: property with details like filename, content-type and perhaps size, and sufficient information to actually fetch it on demand. And add a ResolveAttachments() call for the UI to call, which will turn it into a *real* attachment with a local file:// URL. Does that seem reasonable? (For now, though, I'll stick with just fetching the things up front) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ 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] help debugging a disk-space leak ...
Hi there, I have (perhaps) an unusal setup - I get mail to an IMAP inbox, and then filter much of it off to local storage, and move the rest manually as I need to. I have around 1000 mostly short, text only messages in my IMAP inbox; and yet: du -m /home/michael/.local/share/evolution/mail/groupwise/mme...@prv1-3.novell.com/folders/INBOX/cur | tail -n 1 2562 /home/michael/.local/share/evolution/mail/groupwise/mme...@prv1-3.novell.com/folders/INBOX/cur 2.5 Gb is a tad large for that. Interestingly, the side-panel says 760 unread, 876 total, whereas the right-click-properties says: Unread messages 760 Total messages 2711 and of course, I've got synchronise for off-line use set. So ... how should I go about debugging that ? I assume that blowing away the entire folders directory there, and just re-building it from the server is the easy/cheating hack-around the problem but ... Thoughts appreciated. Thanks, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ 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] Calendar PIM objects with inlined attachments
Hi everyone, thanks for the input so far. On Friday 08 April 2011 David Woodhouse wrote: On Fri, 2011-04-08 at 10:35 +0200, Milan Crha wrote: On Fri, 2011-04-08 at 10:04 +0200, Christian Hilberg wrote: We could use Evolution's file-link attachment mechanism by writing into Evos file cache from the backend and placing the file paths into the [...] That's what we're doing in EWS, too. We store the attachments into the backend's cache directory as obtained by e_cal_backend_get_cache_dir(), Just on a very short note: There's no e_cal_backend_get_cache_dir() in Evo2.30 (which is the one we're sitting on presently). That means we cannot maintain a backend-private file cache with this version, since we cannot inform Evo about it ... is that correct? (Bye)^2, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ 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] Fedora builds with 2.32.2+ patches
On Do, 2011-04-07 at 11:33 +0100, David Woodhouse wrote: Once this passes muster, I'll push these patches (probably *without* the NTLM bits, if you're looking closely at what I included) to the gnome-2-32 branches and perhaps start doing a 'final call' for 2.32.3 candidate bugs/patches. Please consider backporting the fixes for e_cal_new_system_*(). They are unusable in 2.32.x but I intended to use them soon in MeeGo. I'm not sure which fixed from the master branch are all needed, I hope Matthew and Milan can provide a list. -- Bye, Patrick Ohly -- patrick.o...@gmx.de http://www.estamos.de/ ___ 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] Calendar PIM objects with inlined attachments
On Fri, 2011-04-08 at 15:06 +0200, Christian Hilberg wrote: There's no e_cal_backend_get_cache_dir() in Evo2.30 (which is the one we're sitting on presently). That means we cannot maintain a backend-private file cache with this version, since we cannot inform Evo about it ... is that correct? Hi, basically correct, unfortunately: http://git.gnome.org/browse/evolution-data-server/tree/calendar/libecal/e-cal.c?h=gnome-2-30#n725 Though you might be able to set full URI in the attachment object and evo should be able to read it, but not write, probably. Maybe the UI will create a store for you when creating a new event with attached files. To be honest, I do not recall details, it's too long time ago with 2.30.x for me. I would suggest you to try and see. With respect of fetch on demand, it'll be tricky to achieve, to make this done right on each operation which deals with the calendar component in a certain way (operations like copy, move, send and so on). But there is some API function, probably meant for something like that, already, the e_cal_backend_get_attachment_list, used by e_cal_get_attachments_for_comp. Bye, Milan ___ 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] Calendar PIM objects with inlined attachments
On Friday 08 April 2011 Milan Crha wrote: [...] With respect of fetch on demand, it'll be tricky to achieve, to make this done right on each operation which deals with the calendar component in a certain way (operations like copy, move, send and so on). But there is some API function, probably meant for something like that, already, the e_cal_backend_get_attachment_list, used by e_cal_get_attachments_for_comp. If at all we can support attachments in some way, and we want to be ready to work offline at any time, we'll have the actual data available as CamelMultipart message mime part anyways, so not much gain in trying the more complex fetch on demand ... as the attachments to Kolab PIM objects reside in the same email the actual PIM entry is in (as email attachments). I don't think 2.30 IMAPX can fetch just some mime part of an email and leave out another (is that even possible with IMAP?), and it is not dictated exactly which of the possibly multiple mime parts will be the Kolab XML file carrying the calendar data. To that end, we presumably cannot take any shortcuts or delay data fetch. (Bye)^2, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ 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] EWS MessageInfo leak wtf
==5510== 41 bytes in 1 blocks are possibly lost in loss record 8,473 of 17,762 ==5510==at 0x4A05E46: malloc (vg_replace_malloc.c:195) ==5510==by 0x3B6A048B52: g_malloc (gmem.c:164) ==5510==by 0x3B6A06101D: g_strdup (gstrfuncs.c:102) ==5510==by 0x1693D7B1: ews_message_info_clone (camel-ews-summary.c:75) ==5510==by 0x1693E4FD: camel_ews_summary_add_message_info (camel-ews-summary.c:417) ==5510==by 0x16940ADD: camel_ews_utils_sync_created_items (camel-ews-utils.c:973) ==5510==by 0x16939819: sync_created_items (camel-ews-folder.c:660) ==5510==by 0x16939B41: ews_refresh_info_sync (camel-ews-folder.c:750) ==5510==by 0x4C78C99: camel_folder_refresh_info (camel-folder.c:1156) ==5510==by 0x33B6E7F0F7: mail_msg_proxy (mail-mt.c:469) ==5510==by 0x3B6A06BBC3: g_thread_pool_thread_proxy (gthreadpool.c:319) ==5510==by 0x3B6A069445: g_thread_create_proxy (gthread.c:1897) ==5510== Can't repeat it; don't know how it happened... except of course that it obviously happened when SyncFolderItems returned some created items. The frame in ews_message_info_clone() at camel_ews_summary:75 is setting mi-change_key on the newly cloned MessageInfo: http://git.infradead.org/evolution-ews.git/blob/cd1face:/src/camel/camel-ews-summary.c#l75 (I'm also *sure* it happened after commit 17bd5273 in which I fixed a consistent leak of our mi-change_key by adding a message_info_free() method to our class. Not only do I remember it that way, but the timestamp of my valgrind log file is about four hours later than that commit, and the *other* valgrind warnings that the -change_key leak caused are noticeable in their absence.) I'm confused by the use of camel_message_info_clone() in the first line of camel_ews_summary_add_message_info(): http://git.infradead.org/evolution-ews.git/blob/cd1face:/src/camel/camel-ews-summary.c#l417 There is *one* caller of this function, and it's the one in the above backtrace — camel_ews_utils_sync_create_items(): http://git.infradead.org/evolution-ews.git/blob/cd1face:/src/camel/camel-ews-utils.c#l973 And that *creates* a new MessageInfo of its own... which AFAICT never gets freed, although valgrind doesn't seem to be complaining about that, and I don't know why. Removing the clone in camel_ews_summary_add_message_info() and just using '(void *)info' seems to work just as well; I'm not really sure what's going on here. And either way, I've never been able to repeat the above warning. Chen, was there a reason for the clone? And why isn't valgrind complaining about it? Can anyone see something that would cause the above complaint that it *did* make? -- dwmw2 ___ 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] CSV, LDIF and VCF file import problems
I have been trying to sort out an import issue at the user-list. I guess the level of inquiry falls within the hacking domain. I have some CSV and VCF files of my Contacts created with Windows-7 export tool. I plan to import the contacts into Evolution running on Fedora Linux (Lovelock). My Evolution version is 3.0.0 Problem: Evolution is imports the contacts from the CSV file but drops the First name and Surname fields. The same thing happens with LDIF files. Evolution imports VCF files correctly with one exception - The Phone value (work) is duplicated into 'Other' Phone Field. Hence, the 'Work Phone' and 'Other Phone' share the same number. *Here is a sample VCF card:* BEGIN:VCARD VERSION:2.1 N:Fakelast;Fakefirst FN:Fakefirst Fakelast TITLE:Musician TEL;WORK;VOICE:02012473049 EMAIL;PREF;INTERNET:fakeper...@yahoo.com REV:20110403T050042Z END:VCARD Question: - (1) There is only one phone number in the TEL;WORK;VOICE field. Why is Evolution Showing that number as a *WORK* number as well as an *OTHER* number? ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
