[Evolution-hackers] UID in vCard
Hello! I'd like to write down some thoughts on vCard UID handling in EDS. Andrew mentioned it on IRC, so I'm copying him. Let me define the terms to make the difference clear: * UID: part of the contact properties. Ideally set once when a new contact is created in such a way that it is globally unique (same semantic as iCalendar 2.0 UID, not just unique inside the current address book). Can and should be passed around and preserved when exporting/importing contacts. * local ID: local meta data about a contact, only relevant inside an address book to look up contacts. The current situation is that EDS uses the vCard UID property for its own local ID. When trying to create a new contact with UID already set, that UID will be overwritten. This is problematic for interoperability (one cannot store a vCard as-is) and syncing (which would benefit considerably from a creator-assigned, fixed UID). This is partly an API and partly an implementation issue. The libebook<->e_addressbook_factory D-Bus API just passes vCards, so a vCard property has to be used for any local ID, and UID is the one that is used. e_book_add_contact() doesn't have an explicit "local ID" retval. Clients have to use e_contact_get_const(contact, E_CONTACT_UID) to retrieve the assigned local ID. Other APIs avoid that. For example, e_book_add_contact_async() + EBookIdAsyncCallback return the ID out-of-band. The more recent EBookClient API always uses separate ID retvals. However, in contrast to the EBook API it specifies that these are the UID of the created contact and not some kind of local ID. The older API left that undefined and just talked of "id". I see several ways forward: 1. Accept that a contact ID as used in the EBook API is the vCard UID and make it possible to set that UID when creating a new contact. That implies for adding a contact: * remove the code which overwrites the UID * add check for existence of the UID in the address book and a corresponding error code if it does 2. Use the local ID in the EBook API and support storing the vCard UID separately. Support lookup of a contact by UID. The advantage of the second approach is that it is potentially more efficient. I myself took advantage of that in the EDS<->QtContacts bridge code. But it never was a full solution (depended on 32 bit local IDs, which is okay for the file backend, but not all of them, and required patching EDS). The disadvantage of the second approach is an API change and/or extension. It has some potential advantages, but as the EDS<->QtContacts bridge is not used anymore, there is little incentive to do the extra work right away. So I suggest to pursue the first approach instead. I think it is possible for the file backend. Is it also possible for other backends? Or are some unable to store the UID and look up contacts (efficiently) by it? In that case we will have to relax the semantic of the API and accept that some backends still use their own local ID. "Supports UID" should be defined as a capability of the backend so that clients can take it into account. -- 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] UID in vCard
On Mo, 2011-11-14 at 11:22 +0100, Milan Crha wrote: > On Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote: > > So I suggest to pursue the first approach instead. I think it is > > possible for the file backend. > > > > Is it also possible for other backends? Or are some unable to store > > the UID and look up contacts (efficiently) by it? In that case we will > > have to relax the semantic of the API and accept that some backends > > still use their own local ID. "Supports UID" should be defined as a > > capability of the backend so that clients can take it into account. > > Hi, > I wouldn't call it "local UID", it's rather "backend's UID" I wouldn't use the term UID at all for this local (or backend) ID. UID has a specific meaning for both iCalendar 2.0 (where it is well-defined) and vCard (where it is less well-defined). Introducing yet another flavor of UID just leads to confusion, in particular when the same contact has both the original vCard UID and a local backend "UID". > and mostly > not, this is not doable for groupware backends which are using > server-supplied unique identifiers for contacts/calendars, like message > IDs in evolution-mapi, which talks to Exchange servers. It's easier, and > makes sense, to use server-side IDs, which are meant to be unique. > It's also a reason, from my point of view, why > e_data_book_respond_create_contacts() passes UIDs of newly created > objects back to the client. So we do need the concept of local IDs which are not the same as the creator-assigned UID. What about a CardDAV server? It has server-supplied IDs (the path to the resource) and a UID as part of the vCard stored there? How is that handled at the moment? And what does that mean for the file backend? I still think it would be good if the file backend supported creator-assigned UIDs. That other backends can't do that doesn't mean that file backend is not allowed to do it, right? > For example with Google calendar, which is served by CalDAV backend, the > backend fetches newly added event from the server only to present UI > with real object from the server, because the server can modify the > event on its own when creating it (it adds default alarms, if set in > Google's calendar preferences on the Web). Are you saying that Google Calendar EDS does *not* report the original iCalendar 2.0 UID? -- 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] UID in vCard
On Di, 2011-11-15 at 10:50 +0100, Christian Hilberg wrote: > Hi everyone, > > Am Montag 14 November 2011, um 11:22:57 schrieb Milan Crha: > > On Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote: > > > So I suggest to pursue the first approach instead. I think it is > > > possible for the file backend. > > > > > > Is it also possible for other backends? Or are some unable to store > > > the UID and look up contacts (efficiently) by it? In that case we will > > > have to relax the semantic of the API and accept that some backends > > > still use their own local ID. "Supports UID" should be defined as a > > > capability of the backend so that clients can take it into account. > > > > Hi, > > I wouldn't call it "local UID", it's rather "backend's UID" and mostly > > not, this is not doable for groupware backends which are using > > server-supplied unique identifiers for contacts/calendars, like message > > IDs in evolution-mapi, which talks to Exchange servers. It's easier, and > > makes sense, to use server-side IDs, which are meant to be unique. > > It's also a reason, from my point of view, why > > e_data_book_respond_create_contacts() passes UIDs of newly created > > objects back to the client. > > [...] > > Just adding a few bits on how the situation is for the Kolab groupware server. > > The evolution-kolab backend cannot ask the Kolab server for a UID (since there > is no API for that) nor does the server enforce certain UIDs on a PIM object > (but, > of course, that there be one). The only requirement is that the PIM object's > UID > be unique in a given PIM folder. If the UID is globally unique, all the > better. That's the same situation as with the file backend then: a client could decide to set a UID in the vCard before creating the contact, and the Kolab backend+server would use that UID instead of creating their own. Good :-) How does the backend work at the moment? Does it always overwrite an existing UID like the file backend does or does it already work as I proposed? If it does, do you throw a E_BOOK_ERROR_CONTACT_ID_ALREADY_EXISTS when the existing UID is not unique? > PIM objects already residing on the Kolab server do carry a UID, created by > the > client which created the object (evolution-kolab, Kontact, Horde, Outlook with > a Kolab connector, Thunderbird via Lightning/SyncKolab, ...). Do you attempt to make the UID globally unique, for example by using a UUID? > When it comes to importing a PIM object, it is not possible to retain its > UID in the cases where the same UID exists on the server already for another > PIM > object (unlikely, but possible, since Kolab object UIDs are not required to be > globally unique). As long as we're in offline mode, we may at first succeed > retaining > the object's UID, but when going online any syncing with the server, find that > a new UID must be set on the object. What happens during syncing? Do you resolve the add<->add conflict by duplicating the item, merging them or discarding one copy? -- 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] UID in vCard
Hello! Before I reply to Christian, let me elaborate a bit more on why overwriting the UID is bad for syncing. I thought it was obvious, but probably not ;-} What I have in mind is a system where contact data moves freely and ad-hoc between peers, without being forced to go through a central server, stick to a fixed topology or use a specific database technology. This cannot be done with today's technology because avoiding duplicates becomes unreliable. CouchDB comes close, but is a closed system. You also cannot create two independent CouchDB instances and then merge them (at least that is my understanding - I might be wrong on that particular aspect). A creator-assigned global UID would be the right way of solving this. Storages or systems which do create and preserve such a UID cannot participate in that system. I'd like to make sure that the EDS file backend can be part of it, even if it is just for experiments. For more details, see the TODOs on "ad-hoc synchronization" in http://syncevolution.org/blogs/pohly/2011/state-union-version-12 On Di, 2011-11-15 at 15:01 +0100, Christian Hilberg wrote: > Am Dienstag 15 November 2011, um 11:03:24 schrieb Patrick Ohly: > > On Di, 2011-11-15 at 10:50 +0100, Christian Hilberg wrote: > > [...] > > > Just adding a few bits on how the situation is for the Kolab groupware > > > server. > > > > > > The evolution-kolab backend cannot ask the Kolab server for a UID (since > > > there > > > is no API for that) nor does the server enforce certain UIDs on a PIM > > > object (but, > > > of course, that there be one). The only requirement is that the PIM > > > object's UID > > > be unique in a given PIM folder. If the UID is globally unique, all the > > > better. > > > > That's the same situation as with the file backend then: a client could > > decide to set a UID in the vCard before creating the contact, and the > > Kolab backend+server would use that UID instead of creating their own. > > Good :-) > > If a new UID is to be created, it is the responsibility of the Kolab client to > assign one. The Kolab server itself is unaware to object UIDs and will not > touch > them (no read/write/anything). With "client", I meant an EDS client here (= the application using libebook). That there is a Kolab client and server involved is of course important for you, but not so much for a user of the abstract libebook API ;-) > > How does the backend work at the moment? Does it always overwrite an > > existing UID like the file backend does or does it already work as I > > proposed? > > Existing UIDs are (and must be) preserved. This is a requirement for Kolab > client > interop, since they all rely on the object's UID to reference it (especially > regarding > changes to the contents of the PIM object). In Kolab, there is no way to > correctly reference an object other than using its UID. > > > If it does, do you throw a > > E_BOOK_ERROR_CONTACT_ID_ALREADY_EXISTS when the existing UID is not > > unique? > > Eeewww. :-) evolution-kolab presently sits on Evo/EDS 2.30.3 (which some like > to call "just plain old" here =). No error message in that case. If the UID > already exists, it gets rewritten. It was a tradeoff here - an existing Kolab > object and its UID superseedes a new one. Imported objects are regarded as > "new" (being assigned a new UID), should the UID they carry already exist in > the given PIM folder. The original UID would do no good in the Kolab context > if another object with that same UID already exists, since other groupware > clients do have an idea about the object this UID refers to already. Trying > to find out whether the imported object could actually be an update for an > already existing one seemed too complex and out-of-scope for the initial > evolution-kolab implementation. We're now porting to current Evo/EDS git > master, > but I would still keep the current implementation unchanged when it comes > to how to interpret UIDs of imported objects. That is the whole point of this mail thread: a vCard UID may have a meaning outside of the storage in which it currently exists. EDS cannot know whether that is the case. Currently it assumes that the UID has no meaning and throws it away when adding contacts. Consider sending around vCard with globally unique UID. A user might import that vCard once into Kolab using Kolab client A. Then when he tries again with Kolab client B, the client can warn him reliably that this particular contact was already imported. > > > PIM objects already residing on the Kolab server do carry a UID, created > > > by the > > > client which created th
Re: [Evolution-hackers] UID in vCard
On Fri, 2011-11-18 at 11:23 +0100, Christian Hilberg wrote: > Am Mittwoch 16 November 2011, um 15:55:54 schrieb Patrick Ohly: > > Hello! > > [...] > > On Di, 2011-11-15 at 15:01 +0100, Christian Hilberg wrote: > > > If a new UID is to be created, it is the responsibility of the Kolab > > > client to > > > assign one. The Kolab server itself is unaware to object UIDs and will > > > not touch > > > them (no read/write/anything). > > With "client", I meant an EDS client here (= the application using > > libebook). That there is a Kolab client and server involved is of course > > important for you, but not so much for a user of the abstract libebook > > API ;-) > > While the E-D-S client (like Evo) might not be interested whether it is > a Kolab backend being used, there is still one thing you may wish to consider > here. > We could of course map between Kolab PIM object UIDs and E-D-S UUIDs in our > backend. That should never be necessary. As you said, having such two different ids doesn't buy the user much. Only a radical step away from "do what you want with UID" to "UID must be UUID and preserved" will - not realistic anytime soon, but at least a proof-of-concept would be nice. > > That is the whole point of this mail thread: a vCard UID may have a > > meaning outside of the storage in which it currently exists. EDS cannot > > know whether that is the case. Currently it assumes that the UID has no > > meaning and throws it away when adding contacts. > > Not globally true. The file backend may do so, but it is the backend > implementation > deciding whether re-writing a UID or not. E-D-S cannot decide that, since it > does > not know what a given backend is dealing with. What I meant is the Evolution/EDS API expectation that adding a contact will never fail because of a UID conflict. Whether the backend implements that by always overwriting the UID (as the file backend does) or by keep it when possible and overwriting otherwise (as in the Kolab backend) is indeed a backend implementation detail. But it has the same effect: a libebook user cannot reliably detect an add<->add UID conflict. It can check for a contact with the UID first (by assuming that ID in the libebook API == UID in vCard), but then there's still a race condition between that check and creating that contact. -- 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] UID in vCard
On Fri, 2011-11-18 at 17:27 +0100, Christian Hilberg wrote: > Am Freitag 18 November 2011, um 16:53:38 schrieb Patrick Ohly: > > On Fri, 2011-11-18 at 11:23 +0100, Christian Hilberg wrote: > > > > That is the whole point of this mail thread: a vCard UID may have a > > > > meaning outside of the storage in which it currently exists. EDS cannot > > > > know whether that is the case. Currently it assumes that the UID has no > > > > meaning and throws it away when adding contacts. > > > > > > Not globally true. The file backend may do so, but it is the backend > > > implementation > > > deciding whether re-writing a UID or not. E-D-S cannot decide that, since > > > it does > > > not know what a given backend is dealing with. > > > > What I meant is the Evolution/EDS API expectation that adding a contact > > will never fail because of a UID conflict. Whether the backend > > implements that by always overwriting the UID (as the file backend does) > > or by keep it when possible and overwriting otherwise (as in the Kolab > > backend) is indeed a backend implementation detail. > > From evolution-kolab's point of view, it would be simple to return a > "*mp* UID already exists, try again"-error to E-D-S in that case, > provided the E-D-S API for that existed. As Matthew said, the Evolution UI itself is probably not able to handle such an error at the moment. So at the end of the day, it might be the client which has to tell EDS+backend and/or libebook which behavior it wants: preserve UID at all costs (including throwing errors) or emulate the current semantic (don't throw errors, overwrite UID if necessary). > > But it has the same effect: a libebook user cannot reliably detect an > > add<->add UID conflict. It can check for a contact with the UID first > > (by assuming that ID in the libebook API == UID in vCard), but then > > there's still a race condition between that check and creating that > > contact. > > Again, in Kolab context, the user of the calendar lib or addressbook lib > would still get a vague indication only. The race condition could still > occur, since there is (a) no transactional system provided by the Kolab server > for PIM object creation and (b) any Kolab client is required to fully work > in offline mode. This leads to another pet peeve of mine: all backends should be able to work in read/write offline mode. This implies syncing between local and remote data when going online, which should be provided as a core feature of EDS instead of being replicated in every single backend. Akonadi provides such a feature. I have some ideas how SyncEvolution could be used for that inside EDS/Evolution, but that's a topic for another day and mail thread... > AFAICS, the following may be a good start: > * have E-D-S generate good UUIDs > * give the backends the chance to report if a UUID already exists > (if the error does not pop up instantly, it does not mean everything > is well, but *if* it does, certainly E-D-S can try again and generate > another UID, and notify the user) > * encourage all backend implementors not to overwrite existing UIDs, > if at all possible Agreed. -- 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] History is gone after wip/gsettings branch merge
On Mon, 2011-11-28 at 08:27 +0100, Milan Crha wrote: > Hi, > I just realized a very sad thing, the history of certain files is gone > after the merge of wip/gsettings branch into evolution master. I tried > both gitk and git log on mail/e-mail-session.c and the history is ending > on October 6th, 2010. I had a copy of the git repo before that merge and the history of that file also ended on that date. I doubt that this has anything to do with any git merge. > The question is: Can this be fixed? Very hard. Most likely the initial conversion from svn was incomplete. One could redo the conversion and/or rewrite the history, but that implies all commits done later and all trees that other people currently work with become invalid and need to be rebased. IMHO it would be better to add the missing history as independent branches. > P.S.: I never trusted the git merge, it breaks many things, from commit > times/dates Huh? How that? "git merge" only adds one commit. It does not rewrite existing commits from any of the branches that get merged. > to lost work from others if the merger is not careful > enough. Now that is indeed a valid concern. A "git merge" is like applying a single, fairly complex patch (assuming that the branch which gets merged is large). To be on the safe side, a merge could be prepared, pushed to a separate branch and then get reviewed before fast-forwarding the real branch. The downside is that any change on the real branch in the meantime requires redoing the merge or accepting some kind of unreviewed merging again: merge A+B = C gets reviewed, A' + C does not, which might be okay if the delta between A and A' is small and does not lead to further conflicts with C. -- 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] History is gone after wip/gsettings branch merge
On Mon, 2011-11-28 at 10:59 +0100, Milan Crha wrote: > On Mon, 2011-11-28 at 10:15 +0100, Patrick Ohly wrote: > > On Mon, 2011-11-28 at 08:27 +0100, Milan Crha wrote: > > > Hi, > > > I just realized a very sad thing, the history of certain files is gone > > > after the merge of wip/gsettings branch into evolution master. I tried > > > both gitk and git log on mail/e-mail-session.c and the history is ending > > > on October 6th, 2010. > > > > I had a copy of the git repo before that merge and the history of that > > file also ended on that date. I doubt that this has anything to do with > > any git merge. > > Hrm, is it? Actually I now doubt that my git repo was old enough. I thought you talked about the account settings, which is the one which I hadn't pulled yet. Either way, a git merge doesn't rewrite history. > I know it's a new file, but I thought it's older than > October 6th, 2010. It seems that a06e4484b on October 6th, 2010 renamed and modified the file (mail-session.c -> e-mail-session.c) at the same time. That defeats git's --follow and --find-renames heuristics. That's actually an argument in favor of doing merges instead of just applying the final, resulting patch: the file renaming can be committed in a single commit together with the related changes (autotools, include statements) without changing the file content itself. Then in a separate commit, make the actual changes to the content. That is easier to review (because the diffs will be much smaller) and I bet that "git log" would be able to show the full history for the renamed file. Very interesting discussion :-) SyncEvolution almost never accepts new features via merging, instead applying the final, squashed patch. The argument was that a linear development history is easier to read. But it does have this disadvantage of not handling rename+modification and also looses valuable history about the patch itself, or at least makes it harder to find. -- 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
[Evolution-hackers] e_cal/book_open() + only_if_exists
Hello!
With EDS 3.2 and 3.3 I've seen the following problem on a clean account
(no databases, no gconf keys):
* An invocation of SyncEvolution to list databases calls
e_book_new_system_addressbook(), which creates a
gconf /apps/evolution/addressbook/sources entry for the system
address book.
* A second invocation of SyncEvolution finds the definition of the
system address book via e_book_get_addressbooks() and tries to
open it with e_book_open(only_if_exists=false), which then fails
with various errors, depending on the EDS version ("Cannot open
book: db error 0x2 (No such file or directory)" in 3.2,
"DB_RUNRECOVERY" in 3.3).
The problem can be avoided by always passing only_if_exists=true to the
open calls. The way how the API is defined and/or implemented, creating
an database definition and creating the actual database files are two
different steps.
Therefore a client can never be sure whether a database really exists,
and thus it always to pass only_if_exists=true.
If that is the case, then why have it at all? We might as well ignore
the value in the current implementations and mark it as deprecated in
the APIs.
Or do I miss something?
--
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] e_cal/book_open() + only_if_exists
On Tue, 2012-02-14 at 08:45 +0100, Milan Crha wrote:
> On Mon, 2012-02-13 at 21:52 +0100, Patrick Ohly wrote:
> > * A second invocation of SyncEvolution finds the definition of the
> > system address book via e_book_get_addressbooks() and tries to
> > open it with e_book_open(only_if_exists=false), which then fails
> > with various errors, depending on the EDS version ("Cannot open
> > book: db error 0x2 (No such file or directory)" in 3.2,
> > "DB_RUNRECOVERY" in 3.3).
> >
> > The problem can be avoided by always passing only_if_exists=true to
> > the open calls. The way how the API is defined and/or implemented,
> > creating an database definition and creating the actual database files
> > are two different steps.
>
> Hi,
> that's rather a bug in the backend. Calling with only_if_exists=false
> might mean that the backend should create a new book/calendar, in case
> it's not available yet. Otherwise, if you call with only_if_exists=true,
> the backend should claim an error when the requested book/calendar
> cannot be opened.
Sorry, typo in my email. I meant "the problem can be avoided by always
passing only_if_exist=false". In other words, never use
only_if_exists=true because it serves no useful purpose. Is that correct
or is there some legitimate usage for only_if_exists=true?
--
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
[Evolution-hackers] libecal: memory leak
Hello! I've updated one of the chroots for SyncEvolution's nightly testing to current Debian Testing. Now I am seeing a memory leak in libecal 3.2.2: ==23530== 597 bytes in 15 blocks are definitely lost in loss record 4,401 of 4,550 ==23530==at 0x4C27673: malloc (vg_replace_malloc.c:263) ==23530==by 0x7D8AC02: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2) ==23530==by 0x7DA13BD: g_strdup (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2) ==23530==by 0x13BF5CCF: gdbus_proxy_async_method_done (e-gdbus-templates.c:1016) ==23530==by 0x78F7803: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0x7909789: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0x7912E10: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0x7912FB1: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0x13BF5438: e_gdbus_proxy_emit_signal (e-gdbus-templates.c:600) ==23530==by 0xC5BE7BB: ffi_call_unix64 (in /usr/lib/x86_64-linux-gnu/libffi.so.5.0.10) ==23530==by 0xC5BE236: ffi_call (in /usr/lib/x86_64-linux-gnu/libffi.so.5.0.10) ==23530==by 0x78F7CC6: g_cclosure_marshal_generic (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0x78F7803: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0x79095BE: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0x7912E10: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0x7912FB1: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3000.2) ==23530==by 0xB82F0FE: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.3000.2) ==23530==by 0xB81D9AD: ??? (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.3000.2) ==23530==by 0x7D840CE: g_main_context_dispatch (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2) ==23530==by 0x7D848C7: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2) ==23530==by 0x7D84A98: g_main_context_iteration (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2) ==23530==by 0x13BF36EA: gdbus_proxy_call_sync (e-gdbus-templates.c:1442) ==23530==by 0x13BF72B8: e_gdbus_proxy_call_sync_string__string (e-gdbus-templates.c:1608) ==23530==by 0x1650896A: e_gdbus_cal_call_create_object_sync (e-gdbus-cal.c:571) ==23530==by 0x164DEE15: e_cal_create_object (e-cal.c:3932) ==23530==by 0xFA0B881: SyncEvo::EvolutionCalendarSource::insertItem(std::string const&, std::string const&, bool) (EvolutionCalendarSource.cpp:446) Does that look familiar to anyone? -- 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
[Evolution-hackers] libebook master: obsolete vCard used despite updated properties
Hello!
I tested SyncEvolution against current EDS master and found a problem:
setting a UID before committing an updated contact has no effect.
The sequence of events is this:
1. e_contact_new_from_vcard() where the vCard contains no UID.
2. e_contact_set(E_CONTACT_UID, ) -> g_object_set()
3. e_book_commit_contact() -> e_vcard_to_string() -> D-Bus
In step 3, e_vcard_to_string() returns the cached evc->priv->vcard
without the UID although it has a UID in its attributes
(evc->priv->attributes).
I think the culprit is this commit here:
commit cca25e98a71d8c06f9ce1b53658ec4675f2dd5c2
Author: Bartosz Szatkowski
Date: Tue Oct 18 12:29:07 2011 +0200
Bug #656603 - Add support for generating vCard 2.1 in libebook
[...]
@@ -1016,17 +1246,16 @@ e_vcard_to_string (EVCard *evc,
{
g_return_val_if_fail (E_IS_VCARD (evc), NULL);
- /* If the vcard is not parsed yet, and if we don't have a UID in
priv->attributes
- return priv->vcard directly */
- /* XXX: The format is ignored but it does not really matter
-* since only 3.0 is supported at the moment */
- if (evc->priv->vcard != NULL && evc->priv->attributes == NULL)
- return g_strdup (evc->priv->vcard);
-
switch (format) {
case EVC_FORMAT_VCARD_21:
+ if (evc->priv->vcard && strstr_nocase (evc->priv->vcard, CRLF
"VERSION:2.1" CRLF))
+ return g_strdup (evc->priv->vcard);
+
return e_vcard_to_string_vcard_21 (evc);
case EVC_FORMAT_VCARD_30:
+ if (evc->priv->vcard && strstr_nocase (evc->priv->vcard, CRLF
"VERSION:3.0" CRLF))
+ return g_strdup (evc->priv->vcard);
+
return e_vcard_to_string_vcard_30 (evc);
default:
g_warning ("invalid format specifier passed to
e_vcard_to_string");
It removes the check for evc->priv->attributes. Adding that check back
fixes the problem.
Question: why does the removed comment only mention UID? Isn't any
contact modification detected by checking evc->priv->attributes?
--
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
[Evolution-hackers] PHOTO uri + escaping
Hello! I am seeing an issue where the Synthesis engine doesn't parse a vCard with PHOTO;VALUE=uri the same way as libebook's e_contact_inline_local_photo() does. The vCard has: PHOTO;VALUE=uri:file:///home/nightly/.local/share/evolution/addressbook/130 3826927.6946.21@mob-sync2/photos/pas_id_4F511ADB000F_photo-file0.image %252FGIF The actual file name is: /home/nightly/.local/share/evolution/addressbook/1303826927.6946.21@mob-sync2/photos/pas_id_4F521E7A000F_photo-file0.image%2FGIF Note that %2FGIF was encoded as %252FGIF in the vCard. The Synthesis engine does no decoding of the %25 before trying to read the file. I think this is a bug, and I take full credit, eh, blame for it as I added that too simplistic URI handling code ;-) However, why does the file name end in %2FGIF in the first place? It would be much more readable to just use .GIF. That notwithstanding, of course I intend to fix the bug in the Synthesis engine. -- 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] libebook master: obsolete vCard used despite updated properties
On Sat, 2012-03-03 at 13:26 +0100, Patrick Ohly wrote:
> It removes the check for evc->priv->attributes. Adding that check back
> fixes the problem.
Attached is the patch. I must admit that I'm not up-to-date about
release plans. From Matthew's email I gathered that there will be a
release on Monday?!
Please include this patch. I think it is obviously correct, or at least
as correct as the original code was before introducing the vCard 2.1
support - see below.
> Question: why does the removed comment only mention UID? Isn't any
> contact modification detected by checking evc->priv->attributes?
I'm still wondering about that, primarily because I want to be sure that
the code really works in all cases.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
>From 956c91eb6e8ed89d3847738768d53752d2e2d7a4 Mon Sep 17 00:00:00 2001
From: Patrick Ohly
Date: Sun, 4 Mar 2012 14:24:03 +
Subject: [PATCH] EContact: fix "parse vcard + update contact + commit"
The commit which introduced vCard 2.1 encoding support (cca25e)
removed the "evc->priv->attributes" check. Without that check
the encoder will always return a cached vCard, even if the
EContact was modified in the meantime.
Found when updating of a contact with SyncEvolution's --update
operation failed because the UID set after parsing the vCard was
ignored and thus committing the update wasn't possible. Might also
break quite a lot of other functionality!
Fixed by addding the "evc->priv->attributes" in both cases (vCard 2.1
and 3.0).
---
addressbook/libebook/e-vcard.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/addressbook/libebook/e-vcard.c b/addressbook/libebook/e-vcard.c
index 1ff8af2..375a9d1 100644
--- a/addressbook/libebook/e-vcard.c
+++ b/addressbook/libebook/e-vcard.c
@@ -1251,12 +1251,14 @@ e_vcard_to_string (EVCard *evc,
switch (format) {
case EVC_FORMAT_VCARD_21:
- if (evc->priv->vcard && strstr_nocase (evc->priv->vcard, CRLF "VERSION:2.1" CRLF))
+ if (evc->priv->vcard && evc->priv->attributes == NULL &&
+ strstr_nocase (evc->priv->vcard, CRLF "VERSION:2.1" CRLF))
return g_strdup (evc->priv->vcard);
return e_vcard_to_string_vcard_21 (evc);
case EVC_FORMAT_VCARD_30:
- if (evc->priv->vcard && strstr_nocase (evc->priv->vcard, CRLF "VERSION:3.0" CRLF))
+ if (evc->priv->vcard && evc->priv->attributes == NULL &&
+ strstr_nocase (evc->priv->vcard, CRLF "VERSION:3.0" CRLF))
return g_strdup (evc->priv->vcard);
return e_vcard_to_string_vcard_30 (evc);
--
1.7.2.5
___
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] valgrind error in evolution-addressbook-factory + libdb
Hello! Checking the EDS daemons from master under valgrind found this: # ==23596== Conditional jump or move depends on uninitialised value(s) # ==23596==at 0x9A404E7: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so) # ==23596==by 0x9A41CB1: __log_put (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so) # ==23596==by 0x9A42F2D: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so) # ==23596==by 0x9A43D9F: __log_put_record (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so) # ==23596==by 0x9986B1B: __ham_add_el (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so) # ==23596==by 0x997E1FD: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so) # ==23596==by 0x99F5548: __dbc_iput (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so) # ==23596==by 0x99F314F: __db_put (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so) # ==23596==by 0x9A04EBA: __db_put_pp (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so) # ==23596==by 0x103CC953: do_create (e-book-backend-file.c:915) # ==23596==by 0x103CCBFC: e_book_backend_file_create_contacts (e-book-backend-file.c:988) # ==23596==by 0x4E4AC31: e_book_backend_sync_create_contacts (e-book-backend-sync.c:85) # ==23596==by 0x4E4D3D7: book_backend_create_contacts (e-book-backend-sync.c:493) # ==23596==by 0x4E4ED2A: e_book_backend_create_contacts (e-book-backend.c:465) # ==23596==by 0x4E513D3: operation_thread (e-data-book.c:157) # ==23596==by 0x83E9D07: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2) # ==23596==by 0x83E77E5: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2) # ==23596==by 0x8678B4F: start_thread (pthread_create.c:304) # ==23596==by 0x896690C: clone (clone.S:112) # ==23596== Uninitialised value was created by a stack allocation # ==23596==at 0x994DB80: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so) That is with libdb 5.1.29-1 from Debian Testing, in 64 bit mode. At first glance it doesn't look like EDS can be causing this. I don't have time to investigate by compiling libdb from source right now, but at least I wanted to point out that there might be a cause for random crashes. -- 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] valgrind error in evolution-addressbook-factory + libdb
On Tue, 2012-03-06 at 14:33 +0100, Patrick Ohly wrote:
> Hello!
>
> Checking the EDS daemons from master under valgrind found this:
>
> # ==23596== Conditional jump or move depends on uninitialised value(s)
> # ==23596==at 0x9A404E7: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==by 0x9A41CB1: __log_put (in
> /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==by 0x9A42F2D: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==by 0x9A43D9F: __log_put_record (in
> /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==by 0x9986B1B: __ham_add_el (in
> /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==by 0x997E1FD: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==by 0x99F5548: __dbc_iput (in
> /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==by 0x99F314F: __db_put (in
> /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==by 0x9A04EBA: __db_put_pp (in
> /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==by 0x103CC953: do_create (e-book-backend-file.c:915)
> # ==23596==by 0x103CCBFC: e_book_backend_file_create_contacts
> (e-book-backend-file.c:988)
> # ==23596==by 0x4E4AC31: e_book_backend_sync_create_contacts
> (e-book-backend-sync.c:85)
> # ==23596==by 0x4E4D3D7: book_backend_create_contacts
> (e-book-backend-sync.c:493)
> # ==23596==by 0x4E4ED2A: e_book_backend_create_contacts
> (e-book-backend.c:465)
> # ==23596==by 0x4E513D3: operation_thread (e-data-book.c:157)
> # ==23596==by 0x83E9D07: ??? (in
> /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2)
> # ==23596==by 0x83E77E5: ??? (in
> /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2)
> # ==23596==by 0x8678B4F: start_thread (pthread_create.c:304)
> # ==23596==by 0x896690C: clone (clone.S:112)
> # ==23596== Uninitialised value was created by a stack allocation
> # ==23596==at 0x994DB80: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
>
> That is with libdb 5.1.29-1 from Debian Testing, in 64 bit mode.
>
> At first glance it doesn't look like EDS can be causing this. I don't
> have time to investigate by compiling libdb from source right now, but
> at least I wanted to point out that there might be a cause for random
> crashes.
It's not bad as I thought. Am I too pessimistic? ;-)
I've tracked it down and filed a bug against Debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662917
>From the report:
-
I've tracked the root cause in __ham_add_el() in src/hash/hash_page.c:
if (is_databig) {
doff.type = H_OFFPAGE;
===>UMRW_SET(doff.unused[0]);
===>UMRW_SET(doff.unused[1]);
===>UMRW_SET(doff.unused[2]);
UMRW_SET is a NOP unless --enable-umrw is used during
configure. Compiling with --enable-umrw avoids the valgrind warning.
The unitialized value is used in a comparison of a checksum with 0.
I can convince myself that this is probably okay, because it doesn't
matter whether some of the data the checksum was calculated over
was uninitialized as long as it doesn't change later on.
But nevertheless, having to deal with such random valgrind errors
while debugging other code isn't nice. Please consider using
--enable-umrw when compiling libdb.
--
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] PIM server synchronization and Evolution online/offline state
On Wed, 2012-04-04 at 13:32 +0200, Christian Hilberg wrote: > Which is the long-term vision for Evolution in this regard? Lack of proper offline support has been my main motivation for developing SyncEvolution. I know from others that they, too, would love to see this supported natively in EDS+Evolution, without the need for an external application. If there is sufficient interest, then I would be open for discussions about how SyncEvolution could be integrated seamlessly into Evolution. This would bring offline support for CalDAV, CardDAV, ActiveSync and might even add support for SyncML peers (client or server). But note that the current code is in C++ and depends on additional libraries that are not currently part of the GNOME stack (libsynthesis, libneon for offline CalDAV/CardDAV). Rewriting it in pure C+GNOME would be a lot of work. -- 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] Evolution module renames
On Fri, 2012-05-11 at 09:52 +0200, Milan Crha wrote: > It's a general issue, because you never know what you'll have pulled in, > and what steps you should do before you actually pull those changes in. > I do not know if we can anyhow instruct autotools to not do this hard > dependency of .am and .ac files, but I'm afraid we cannot do anything > with this. --disable-maintainer-mode if you have AM_MAINTAINER_MODE in configure.ac. In general I don't trust "make uninstall", in any project. It's usually not available when needed again, probably untested, or will fail for some other reason (like the one you found). I rather install into a directory that I can wipe out entirely, or use checkinstall. -- 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
[Evolution-hackers] e_cal_client_check_timezones() + e_cal_client_tzlookup() + Could not retrieve calendar time zone: Invalid object
Hello!
I've started testing a version of SyncEvolution which uses the
EBook/CalClient API. The import test fails for a VEVENT which uses a
custom timezone:
BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:EST/EDT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:19671029T02
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:19870405T02
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=1SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:20060416T205224Z-4272-727-1-251@gollum
DTSTAMP:20060416T205224Z
DTSTART;TZID=EST/EDT:20060406T14
DTEND;TZID=EST/EDT:20060406T143000
TRANSP:OPAQUE
SEQUENCE:2
SUMMARY:timezone New York with custom definition for 2006
CLASS:PUBLIC
CREATED:20060416T205301Z
LAST-MODIFIED:20120531T085920Z
END:VEVENT
END:VCALENDAR
e_cal_client_check_timezones() fails with "Could not retrieve calendar
time zone: Invalid object". This comes from the attempt to look up
"EST/EDT" in an empty calendar:
icaltimezone *
e_cal_client_tzlookup (const gchar *tzid,
gconstpointer ecalclient,
GCancellable *cancellable,
GError **error)
{
...
if (e_cal_client_get_timezone_sync (cal_client, tzid, &zone,
cancellable, &local_error)) {
g_warn_if_fail (local_error == NULL);
return zone;
}
if (g_error_matches (local_error, E_CAL_CLIENT_ERROR,
E_CAL_CLIENT_ERROR_OBJECT_NOT_FOUND)) {
/* We had to trigger this error to check for the
* timezone existance, clear it and return NULL. */
g_clear_error (&local_error);
}
...
It's normal that e_cal_client_get_timezone_sync() fails. But it fails with an
unexpected error:
signal sender=:1.3 -> dest=(null destination) serial=94
path=/org/gnome/evolution/dataserver/Calendar/1636/9;
interface=org.gnome.evolution.dataserver.Calendar; member=get_timezone_done
uint32 18
string "org.gnome.evolution.dataserver.Calendar.InvalidObject"
string "Could not retrieve calendar time zone: Invalid object"
string ""
Therefore the error is not cleared and e_cal_client_check_timezones()
aborts instead of accepting the "EST/EDT" time zone as it is.
This works in Evolution itself, probably because it let's the backend
itself do the e_cal_client_check_timezones() with a different lookup
function.
What is the preferred way of fixing this?
We could define that e_cal_client_get_timezone*() must return the
E_CAL_CLIENT_ERROR_OBJECT_NOT_FOUND error when the time zone doesn't
exist and fix it to do so. Or we could make the error check in
e_cal_client_tzlookup() more liberal and ignore all E_CAL_CLIENT_ERRORs.
The latter might be easier, in particular considering that multiple
different calendar backends might need fixing to reliably return
E_CAL_CLIENT_ERROR_OBJECT_NOT_FOUND.
--
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 ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Update on the composer port
On Sun, 2012-09-02 at 00:16 +0200, Dan Vratil wrote: > Behavior of the editor is almost identical to GtkhtmlEditor, except for HTML > mode -> Plain text switching. GtkhtmlEditor is simply switching renderers on > top of a single DOM document, but we can't do this with WebKit. I looked how > others do it and ended up with a "Switching to plain text will lose all > formatting, OK?" dialog. Please excuse my ignorance, but how will plain text mode work in the future? Will it still be possible to define item lists, indent blocks, etc.? I edit and send only plain text emails, but I use these formatting helps from Evolution, including saving of drafts with this markup. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ 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] Regarding API breakage and lost test cases
On Tue, 2012-10-02 at 13:30 +0900, Tristan Van Berkom wrote: > I'm still trying to find my footing here, the migration guide > and new documentation on ESourceRegistry don't seem to outline > how a new addressbook is actually created. > > i.e. if I wanted to test a specific addressbook backend, > I would need a way to create one and populate it inside some sandbox > directory. The location of the database files is fixed for the file backend. It has to be in ~/.local/share/evolution and is derived from the UUID. I agree that an explicit path property for the file backend would be nice. > I'm getting as far as: > > // Create scratch source > e_source_new_with_uid(); > > // Add it to the registry > e_source_registry_new(); > e_source_registry_add_sources(); > > // Fetch the new source from the registry (no longer 'scratch') > e_source_registry_ref_source(); > > // Create the book now that we have a valid source (... or so we > // suspected) > e_book_new (); > > Problems I'm encountering are: > > a.) It seems that e_source_registry_ref_source() only finds the > newly created source the next time I startup the test app > (so this may indicate a bug, that the local registry is not > updated after adding a new source). Not sure about that one. To some extend the API depends on processing D-Bus events in the main event loop. Perhaps that's not happening in your test app? > b.) e_book_new() complains that the new source has no backend: > >"e-book.c:2944: cannot get book from factory: > No backend name in source 'Unnamed'" You need to add the right extensions to the new source: source = e_source_new(); ESourceBackend *backend = e_source_get_extension(source, E_SOURCE_EXTENSION_ADDRESS_BOOK); e_source_backend_set_backend_name(backend, "local"); > I'm sure I've missed something ridiculous here, while observing > the sources e-data-book-factory.c, it seems that if the source > were given an addressbook extension with the intended backend > name... that it would happily go ahead and create a book. > > But, while we do have: > e_source_get_extension() & e_source_has_extension() > > I'm not seeing: > e_source_add_extension() _get_extension() adds the extension implicitly. -- 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 ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Regarding ESource and ESourceExtension
On Mon, 2012-10-08 at 14:42 -0400, Matthew Barnes wrote: > Not sure if this fully addresses your question or not. I'm still at a > bit of loss as to your use case. One example would be SyncEvolution, configuring and using additional features in EDS if and only if they are supported. If that cannot be detected at runtime, then one of several much less attractive workarounds must be used: * configure option in SyncEvolution - which users will get wrong * detect version of EDS and its backend (not even sure whether that works with enough granularity) and map to hard-coded list of capabilities - will be difficult to keep up-to-date -- 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 ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Addresbook query result ordering
On Mon, 2012-10-15 at 20:59 +0900, Tristan Van Berkom wrote: > Secondly, I see three potential ways of approaching this problem and I > wonder which way would be preferable. > > These are the possible avenues I'm aware of: > > a) Extend EBookQuery API > > This seems the most natural way to go about it, as I see it a query > can contain multiple query terms and a single 'sort order' for the > results; i.e. something like: > >e_book_query_set_order (query, EContactField, AscendingOrDescending); > > However, the EBookQuery does not contain multiple terms, instead it > contains... multiple queries, which would make the API quite awkward > since it would never make sense to have a query with more than one > order defined for it's results. > > Modifying the query also has other drawbacks, it seems some backends > like to send the serialized query expressions over the network, > perhaps backwards compatibility would become a serious issue here > (I've not investigated very far into this). > > b) A new set of query apis > > This might be the right choice considering drawbacks of 'a', in this > case we could introduce an entirely new set of apis concerned with > getting results from the addressbook. > > so methods such as: > >e_book_client_get_contacts (book, query, ...) > > would receive a complimentary: > >e_book_client_get_sorted_contacts (book, query, sort_field, ASCEND...) > > possibly deprecating all of the orderless apis which preceded > these new apis along the way. > > This has the obvious disadvantage of implementation difficulty, > i.e. EDS has still not been ported to use the new gdbus-codegen > tool so all of that d-bus stuff would need to be done by hand > (possibly less overall effort to just port to gdbus-codegen first). > > One upside to this is that backends which don't yet support the > sorted results could fall back on existing APIs, possibly by > introducing an EBookBackendSortable interface or such > (question still would remain... how to advertise at runtime > whether the sorting is supported by the active backend, perhaps > via the 'capabilities' backend property). > > c) The least attractive and easiest way would be to simply add an > api to EBookClient telling it "in what order should you sort > the addressbook" (or, an ESourceExtension configuring the sort > order). There is a forth option: d) add sorting to EBookView and leave e_book_client_get_contacts() as it is. Extending EBookView might be easier than extending EBookQuery. Note that when adding sorting, it also makes sense to add a "maximum number of contacts" parameter. Without sorting, that value is useless because is not predictable which contacts will be included in the result. With sorting, it becomes possible to populate a fixed-size view without having to receive all results. -- 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 ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] UI interaction from book/calendar backends
On Thu, 2012-11-22 at 13:04 -0500, Matthew Barnes wrote: > Actually I don't think evolution-source-registry requires GTK+. If it's > the password dialog you're thinking of, we only link to gcr-base-3 which > speaks via D-Bus to the process actually showing the password dialog. > > I'm not sure if evolution-source-registry is ultimately the right place > for user interfaces, but I can't think of a better solution at present. > > I have a few requests, though: > > 1) Write this as a ESourceRegistryServer extension, and just link to >GTK+ from the extension module. That way it's easily removable if >the Tizen folks don't want it, or they want to implement their own >version using Qt. Qt is so old-fashioned MeeGo - HTML5 rulez in Tizen! >:-> Thanks for keeping this in mind. I thing it is just good engineering and will hopefully also turn out to be useful outside of Tizen, which - just to avoid any confusion - does not use EDS at the moment and might never do. I'm bringing it up as an example of a distro where compiling EDS is hard at the moment because of the GTK dependency - there might be other, similiary limited platforms. -- 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 ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Plan to support and use vCard 4.0 (RFC 6350) in evolution-data-server
Hello! I only saw this email now - please copy me directly on emails that you want me to see. On Fri, 2013-05-17 at 15:34 +0200, Milan Crha wrote: > Hello all, > there was a little discussion about vCard 4.0, aka [RFC6350], which > adds, among other things, a valuable KIND attribute, which is used to > differentiate what the vCard is for. That would get rid of the > evolution's X-EVOLUTION-LIST attribute, and maybe more. Here's a list of > changes between 3.0 and 4.0 vCard [2]. The RFC is not that old yet, it's > only from August 2011, but I guess it's not a problem. > > I'd like to know from others their opinion, whether it would be > appreciated to switch to vCard 4.0 by default in evolution > (-data-server). The plan is to keep backward compatibility with 3.0, > even be able to save in 3.0 format (probably by some combo in a save > dialog to pick the format user prefers), but otherwise switch internally > into vCard 4.0. That way specialized editors could be created (as you > know, there are currently only two, one for general contact, the other > for contact list; maybe it'll make sense to introduce new contact editor > for organization, room, and so on). In general I consider that a good thing. vCard 4.0 is a step forward, but it is not going to be adapted unless someone starts. But being the first to move forward will also mean that there will be problems exchanging data with peers that are still on vCard 3.0, simply because some information cannot be stored there. This is nothing new and SyncEvolution is prepared for such kind of format mismatches, it just will be some work to adapt it. In Evolution it would be good to have the ability to mark an address book as "only supports vCard 3.0 properties". Such a flag should disable all UI features which rely on vCard 4.0. Then address books which mirror a remote vCard 3.0 address book will be usable without surprises for the user. > I also do not know how will other programs work, when user would try to > import a 4.0 vCard, while the program only knows 3.0. I believe the > reading should not be strict on versions, the version only gives a > "hint" what the card can, and what it should not, contain, right? One would hope so, but there's nothing in the standard requiring that. A client might also decide to play it safe and reject vCard 4.0 because it simply cannot know whether the vCard 3.0 decoding rules still apply. For example, in an early draft of vCard 4.0 the set of characters which needed quoting was defined differently than in 3.0. This was reverted back to the rules from 3.0 later on to enhance backward compatibility, but it might as well have stayed in the spec. -- 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 ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] libecal soname change
Hello! I just noticed that libecal bumped its soname to libecal-1.2.so.16 in EDS 3.10. The corresponding commit is: commit f30ae26320b359666b345c92405bf87f3f43250a Author: Matthew Barnes Date: Tue Jul 16 06:34:02 2013 -0400 Bump libecal / libedata-cal soname for API breaks. Matthew, can you elaborate what that break is? I've looked at a diff of the header files, but most of it is just reformatting. If there is an API break in there, then I missed it. -- 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 ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libecal soname change
On Thu, 2014-01-02 at 08:22 -0500, Matthew Barnes wrote: > On Thu, 2014-01-02 at 11:30 +0100, Patrick Ohly wrote: > > I just noticed that libecal bumped its soname to libecal-1.2.so.16 in > > EDS 3.10. The corresponding commit is: > > > > commit f30ae26320b359666b345c92405bf87f3f43250a > > Author: Matthew Barnes > > Date: Tue Jul 16 06:34:02 2013 -0400 > > > > Bump libecal / libedata-cal soname for API breaks. > > > > Matthew, can you elaborate what that break is? > > The libdata-cal bump was to cover the preceding commits: [...] > The libecal bump looks like it may have been a mistake on my part. I > must have been under the impression the client-side API changed as well. Indeed, it looks like the soname change was unnecessary. It's too late to fix now, though. Can we perhaps agree on a different procedure for soname changes? If a patch requires a soname change, then alert the list here. Then interested developers can double-check whether a change really is necessary and/or whether a different solution can be found. In addition, the email will serve as warning about upcoming soname changes for developers (like me) who want to provide pre-compiled binaries. -- 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 ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Evolution Data Server] Locale change notification delayed
On Wed, 2014-02-12 at 15:27 +, Potrola, MateuszX wrote: > Hi, > > >Regarding your specific issue - it's probably working the same way in > >master as in the branch - my guess is that this is due to D-Bus property > >changes being delayed until the main loop is hit. > > >It may be that a simple call to g_dbus_interface_skeleton_flush() inside > >the loop which sets locale on each book would fix this. > > You are right - it's the same on master branch, but adding > g_dbus_interface_skeleton_flush call after setting locale fixes the issue. > How I can submit patch, should I open new item on bugzilla and send it there? Yes, that's usually the best approach to ensure that patches get included in EDS. Please include patches that apply to master and the gnome-3-8-openismus branches. Please CC me and I can commit them (unless someone beats me to it - I am currently on vacation). Bye, Patrick ___ 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] WebKit based Evolution composer status and future
On Mon, 2014-03-17 at 09:25 +0100, Tomas Popela wrote: > Regarding the future of WebKit based Evolution composer I'm proposing > this: merge webkit-composer branch into master when the 3.12 release > will be branched and continue to work on it in master branch. This will > hopefully bring more testers for the new composer. When the code will be > in master I will continue to develop it and also porting it to WebKit2 > with the rest of Evolution. While I have no say in how Evolution gets developed, I nonetheless would like to warn against merging unstable and known buggy code into master. What if it turns out that the code can't be stabilized in time for the next release? Can it be reverted or will Evolution have to go out with known regressions? I know that sometimes one has to take the bullet and release something to get bug reports that one would not get otherwise. But IMHO that should be the last resort when all other options of finding those bugs have been exhausted. Just my 2 cents. Bye, Patrick ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] custom labels
Hello! Both Google and Apple support custom labels for basically all of a contacts properties (telephone, email, address, instant messaging, etc). They use group tags to associate the extra label with the property: item4.ADR:;;custom address item4.X-ABLabel:custom-label Does anyone have suggestions for how this could and/or should be handled by EDS and Evolution? Obviously the Evolution UI would need to be modified to actually show the information. As a first step I would already be happy if the information didn't get lost during a import/edit/export cycle. I tried grouping, but when editing the field (an EMAIL in my test) its group tag was removed, thus breaking the connection to the custom label. After editing in Evolution: item1.X-ABLabel:foobar EMAIL;TYPE=WORK;X-EVOLUTION-UI-SLOT=1:email value modified I also tried a custom parameter, but that also got lost: EMAIL;X-ABLabel=foobar;X-EVOLUTION-UI-SLOT=1;TYPE=WORK:email value -> EMAIL;TYPE=WORK;X-EVOLUTION-UI-SLOT=1:email value modified I tried this with Evolution 3.4 (the one shipped with my current desktop, Debian Stable). Has perhaps anything been done regarding this in later versions? I am undecided about what EDS and Evolution should use internally to represent custom labels. I lean towards a custom parameter because although grouping is supported by EVCard, it hasn't been really used, has it? The concept of "fields of interest" would still work if the field also has the custom label as parameter (not that we have special support for anything other than UID and REV, but at least conceptually something else could also be supported). On the other hand, deviating from the format of the peers will make interoperability harder. I'm not sure yet how I would do the conversion in SyncEvolution between X-ABLabel as parameter and X-ABLabel as property with group. Importing/exporting vCards manually also is affected by the choice of the internal format. Bye, Patrick ___ 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] Contacts database modifications history
On Tue, 2014-04-15 at 13:16 +, Potrola, MateuszX wrote: > In my project I’m using EDS as backend for storing contacts > synchronized using Syncevolution. > > I would like to have ability to receive some kind of notifications (or > store information in some additional database) about modifications > made to contacts database during synchronization. > > What I mean by modification is information about contact id and list > of contact’s fields that were modified (creation and removal of > contact can be special case - list of all contact’s fields that are > set will be returned). > > I know that current implementation of EBookView allows for something > similar - it allows for detecting newly created, removed or modified > contacts, but unfortunately it doesn’t provide details of > modification. For those who were around at the time, there used to be a similar feature which recorded the UIDs of added, modified and removed contacts. It did not record individual changes and was not as configurable as Mateusz wants it to be now. I was on of those who argued in favor of removing that API because it had several design flaws: 1. Reading changes automatically destroyed the recorded changes, so one could not use it to just check whether something had been modified. 2. Changes were recorded for each client asking for it. EDS had no way of knowing whether the client was still interested in the changes and no garbage collection, so it ended up recording changes in perpetuity if the client was not given a chance (or forgot) to unregister. I wouldn't mind seeing a change tracking API getting re-added to EDS if these design flaws get addressed. If there is not enough interest in that, then a solution were such a feature can be added to EDS by a system integrator via plugins or conditional compilation would also satisfy Mateusz needs. > I came up with two slightly different approaches how this could be > achieved. > > First one is to create new address book backend (which will be > inhering from file backend used by Syncevolution) and add there logic > for calculating modifications when creating/modifying/removing > contacts. These modifications will be stored in additional database, > so some additional functions for handling this will need to be added > to EBookSqlite class. > > Here are some pros and cons that I can see: > > Pros: > > - If someone don’t want to keep track of modifications history > he can still use file backend > > - We can be sure that contacts database and modifications > database will be in sync, by using attach function of sqlite > (databases will be separated but transaction for modifying both of > them will be treated as one transaction) Does it have to be a separate sqlite database? You could also use a new table directly in the sqlite datbase also used for the contact data. > Cons: > > - Quite complex implementation, especially if some API needs to > be exposed by EBookClient Perhaps the API for reading the changes could be limited to direct read access, potentially outside of the core libebook? > Second solution is to extend current implementation of EBookView and > add new signals like: contacts_added, contacts_modified, > contacts_removed which will be providing ids and list of modified > fields. Also new function for setting fields of interest will need to > be added. Again in the address book backend implementation of logic > for calculating modifications and emitting this signals will have to > be added (it can be added to current file backend implementation or > like in previous idea, new backend can be created based on file > backend). Note that the EBookView could also be used as-is by doing the detailed check of what was modified in the receiving process. For new contacts it is very likely that the fields of interest were added, and updating contacts happens rarely enough that the overhead of sending updated data that then completely gets filtered out shouldn't matter. > Pros: > > - Way of storing modifications information is up to the client > application, > > - In our case we would like to know what modifications were made > during synchronization, EDS is not aware of which modification of > contacts are part of which synchronization, but client application has > this knowledge. > > Cons: > > - We may end up with out of sync data in case if some signals > will be not emitted. I see that as the most important reason why I would prefer the more integrated approach. Bye, Patrick ___ 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] Contacts database modifications history
On Wed, 2014-04-16 at 09:02 +, Potrola, MateuszX wrote: > > > First one is to create new address book backend (which will be > > > inhering from file backend used by Syncevolution) and add there logic > > > for calculating modifications when creating/modifying/removing > > > contacts. These modifications will be stored in additional database, > > > so some additional functions for handling this will need to be added > > > to EBookSqlite class. > > > > > > Here are some pros and cons that I can see: > > > > > > Pros: > > > > > > - If someone don’t want to keep track of modifications history > > > he can still use file backend > > > > > > - We can be sure that contacts database and modifications > > > database will be in sync, by using attach function of sqlite > > > (databases will be separated but transaction for modifying both of > > > them will be treated as one transaction) > > > > Does it have to be a separate sqlite database? You could also use a new > > table > > directly in the sqlite datbase also used for the contact data. > > > No, it don't need to be separate sqlite database, but I was thinking > about case where database will be locked because some operation like > locale update is ongoing, with separate database modifications data > could be still concurrently accessed. Doesn't sqlite allow reading while a write is ongoing? > > Note that the EBookView could also be used as-is by doing the detailed > > check of > > what was modified in the receiving process. For new contacts it is very > > likely that > > the fields of interest were added, and updating contacts happens rarely > > enough > > that the overhead of sending updated data that then completely gets filtered > > out shouldn't matter. > I'm not sure about using EBookView as-is and checking what was > modified in receiving process, because notification will be sent when > data in contacts database will be already changed, so receiving > process should first get all contacts from database before starting > synchronization to be able to do detailed check of what was modified, > which in case of large number of contacts may unnecessarily increase > memory consumption, especially as you've said that updates happens > rarely. This is a valid concern. Both doing the diff inside the EDS backend (as part of the write) or in SyncEvolution would work better. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ 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] Contacts database modifications history
On Wed, 2014-04-16 at 12:23 +0200, Milan Crha wrote: > On Tue, 2014-04-15 at 13:16 +, Potrola, MateuszX wrote: > > I would like to have ability to receive some kind of notifications (or > > store information in some additional database) about modifications > > made to contacts database during synchronization. > > > Hi, > the compose of a "diff" for done changes is probably the hardest thing > on this whole thing you'd like to achieve. There is always (at least) > one place where this "diff" should be computed. I'm not much willing to > add it into evolution-data-server itself, because it has no good use for > it (at least not as of now). I tend to agree. It would be very hard to come up with a general purpose diff that works across a wider range of use cases. If it is configurable, the config language and implementation would have to be unnecessarily flexible (and thus complicated) for what Mateusz probably has in mind. I still think a plugin doing the diff would be okay. > As Patrick pointed out, the previous implementation had sever issues > which made the feature basically unusable. If we cannot make it done for > all backends, then it probably might not be part of the > evolution-data-server. We have a slightly different understanding of EDS here. You see EDS as an abstraction layer that offers just the functionality that can be implemented with all backends. We focus on EDS + local storage and try to make the best use of its capabilities, even if that means adding things to it which won't work with other backends. That's find, I think we can do both. It just means that whatever API gets added that only works with local storage needs to be clearly marked as "local only" in the documentation and/or there has to be a discovery mechanism for determining whether a certain EBookClient instance supports it. > Anyway, I would prefer if you could create a plugin to SyncEvolution > (does it support plugins?), also because it's the software you are > targeting, not evolution-data-server code, Not necessarily. At the moment the focus is on cached PBAP address books that are only written by SyncEvolution, but that may change in the future. Perhaps someone wants to rip out SyncEvolution and do the caching differently, or wants to have address books that can be edited by the user. The change tracking still needs to work in those cases. Another argument for doing it inside EDS is that it can be combined with the actual sqlite database update. To me, that is the only bullet-proof way of ensuring that the change tracking information will be consistent with the actual content. This must work in a car, where the head unit can loose power at any moment. Ensuring that the sqlite database doesn't get corrupted is difficult enough. Ensuring that different processes get a chance to write different files will be even harder. I'd like to mention further use case for allowing hooks during the execution of EDS writes: this can be used to pre-compute data that is later going to be shown by a UI other than Evolution. I think EDS already does some of this for Evolution (like computing a full name) in a way that, strictly speaking, depends on the UI that is going to show the data. One even crazier idea was to maintain an on-disk data structure that can be memory-mapped to access contact data, including strings and their parsed photos ready to be displayed, without going through sqlite and all the string handling. I'm not a terribly big fan of that idea myself, but if there were hooks in EDS which could be used to track DB changes reliably, that would allow implementing this idea without further changes to EDS itself. > Still, all this looks too complicated, adding unnecessary burden, > consider that you specifically target SyncEvolution changes, thus why > not to extend SyncEvolution to write its own backlog of done changes in > some place, where your application may just read them from? SyncEvolution indeed does a read/update/write cycle when updating contacts. This would be a natural place to add a hook for such a plugin. Implementing it will be a bit tricky because it happens under the hood in the Synthesis sync engine, but I guess it could be done, if the alternative (a similar hook in EDS) is not acceptable. > On Wed, 2014-04-16 at 09:02 +, Potrola, MateuszX wrote: > > What is the probability of failure of emitting signals ? > > The probability is close to 0. If it happens, then it's a bug in the > backend (or the related code) and should be fixed as soon as discovered. The more likely failure is that EDS emits the change, but then the computer is shut down before the receiving side gets a chance to handle it => EDS DB was modified, change log in the receiver was not. Bye, Patrick ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hac
Re: [Evolution-hackers] Contacts database modifications history
On Wed, 2014-04-23 at 16:08 -0400, Tristan Van Berkom wrote: > This is my prerogative and I can accept that it is not shared with the > maintainers of EDS, nevertheless I would still like to caution against > opening up the SQL tables owned by EBookSqlite to be shared with plugins > (it may take a little more time in the beginning to flesh out a well > defined interactive API that satisfies the needs of plugins, but this > will pay off in better long term stability, anyway this is my opinion). I agree with you, plugins should not make assumptions about the content of sqlite database. This needs to be documented clearly. However, the goal is not to let plugins access the existing tables. Instead, the goal is to let plugins create their own custom tables and update them as part of the same transaction that EBookSqlite uses to update its own tables. Name clashes need to be avoided, but that is a minor issue. We might also want to add hooks for DB updates and locale changes. Does this address your concern? Bye, Patrick ___ 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] Contacts database modifications history
On Thu, 2014-04-24 at 13:51 +, Potrola, MateuszX wrote: > > On Wed, 2014-04-23 at 16:08 -0400, Tristan Van Berkom wrote: > > > This is my prerogative and I can accept that it is not shared with the > > > maintainers of EDS, nevertheless I would still like to caution against > > > opening up the SQL tables owned by EBookSqlite to be shared with > > > plugins (it may take a little more time in the beginning to flesh out > > > a well defined interactive API that satisfies the needs of plugins, > > > but this will pay off in better long term stability, anyway this is my > > > opinion). > > > > I agree with you, plugins should not make assumptions about the content of > > sqlite database. This needs to be documented clearly. > > > > However, the goal is not to let plugins access the existing tables. > > Instead, the goal is to let plugins create their own custom tables and > > update > > them as part of the same transaction that EBookSqlite uses to update its own > > tables. Name clashes need to be avoided, but that is a minor issue. We might > > also want to add hooks for DB updates and locale changes. > I think that we can still create solution where internal tables from > EBookSqlite will be protected from accessing from plugins and all > queries will be run in the same transaction (which is most important > part for us). > Shared transaction across databases may be possible by using sqlite > ATTACH command. Plugins can create their own databases and ask > EBookSqlite to attach them to the one used by EBookSqlite, providing > some names that will identify them (this name will have to be > prepended to each table name when making query). For this to work we still need to grant the plugin access to the sqlite connection of the EBookSqlite database. All that we gain is that sqlite helps a bit with resolving table name conflicts and that data gets separated into more files (not necessarily an advantage). Note that we still need to be careful about name conflicts, because sqlite will pick the most recently attached table first if the table name is not unique (http://www.sqlite.org/draft/lang_attach.html). In other words, a plugin that happens to pick the same name as core EBookSqlite will cause EBookSqlite to use the plugin's table instead. We also loose the option to turn on WAL (http://www.sqlite.org/draft/wal.html) because atomicity is not guaranteed for attached databases. EDS might not use WAL at the moment, but it would be an interesting exercise to run benchmarks with it enabled. Bottom line is that I don't see ATTACH as a viable solution for the problem, in contrast to clearly documenting the table naming convention and the boundary between EBookSqlite and plugin. Bye, Patrick ___ 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] custom labels
On Fri, 2014-04-11 at 12:18 +0200, Patrick Ohly wrote: > Hello! > > Both Google and Apple support custom labels for basically all of a > contacts properties (telephone, email, address, instant messaging, etc). > They use group tags to associate the extra label with the property: > > item4.ADR:;;custom address > item4.X-ABLabel:custom-label > > Does anyone have suggestions for how this could and/or should be handled > by EDS and Evolution? > > Obviously the Evolution UI would need to be modified to actually show > the information. As a first step I would already be happy if the > information didn't get lost during a import/edit/export cycle. > > I tried grouping, but when editing the field (an EMAIL in my test) its > group tag was removed, thus breaking the connection to the custom label. > After editing in Evolution: > > item1.X-ABLabel:foobar > EMAIL;TYPE=WORK;X-EVOLUTION-UI-SLOT=1:email value modified > > I also tried a custom parameter, but that also got lost: > > EMAIL;X-ABLabel=foobar;X-EVOLUTION-UI-SLOT=1;TYPE=WORK:email value > -> > EMAIL;TYPE=WORK;X-EVOLUTION-UI-SLOT=1:email value modified > > I tried this with Evolution 3.4 (the one shipped with my current > desktop, Debian Stable). Has perhaps anything been done regarding this > in later versions? > > I am undecided about what EDS and Evolution should use internally to > represent custom labels. I lean towards a custom parameter because > although grouping is supported by EVCard, it hasn't been really used, > has it? The concept of "fields of interest" would still work if the > field also has the custom label as parameter (not that we have special > support for anything other than UID and REV, but at least conceptually > something else could also be supported). The custom parameter has one major drawback: it cannot store arbitrary string values. Line breaks and double quotes are not possible. The EDS vCard parser is also slightly broken and fails for X-ABRELATEDNAMES;X-ABLabel=domestic partner:domestic partner A space without quoting is valid according to http://tools.ietf.org/html/rfc2425#page-5 but e-vcard.c complains "invalid character found in parameter spec" and proceeds at the next line. > On the other hand, deviating from the format of the peers will make > interoperability harder. I'm not sure yet how I would do the conversion > in SyncEvolution between X-ABLabel as parameter and X-ABLabel as > property with group. Importing/exporting vCards manually also is > affected by the choice of the internal format. Even if we used X-ABLabel + grouping, directly exchanging vCards with Apple will still not work properly due to the X-JABBER/AIM/... vs IMPP difference. Further work would be needed either way. I have not tested whether Apple understands X-AIM/JABBER/... instead of IMPP. I'm still undecided. A too complex X-ABLabel property value could be simplified to store it in a X-ABLabel parameter, but that'll drop user data. At this point it really would be good to get feedback from others. Is using groups going to be possible with EContact and Evolution or are we forced to use the simpler parameter approach, despite its limitations? Bye, Patrick ___ 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] Introspection enablement for libecal - huge changes needed?
On Wed, 2014-05-14 at 15:34 +0200, Milan Crha wrote: > Hello, > maybe you noticed that we have a GSoC project for this year, to enable > introspection for calendar part of evolution-data-server (libecal), > which will make it usable for other languages as well. As said already, doing this as add-on of libical and then later taking advantage of it in EDS seems like the right approach. > Will is a student which will do the main work. The current problem is > libical, its icalcomponent, enums and all other structures. I thought > that we will be able to introspect this with simple boxed types, but it > doesn't seem to be possible, thus the only option I can see is to > massively change API of the calendar and define proxies for libical > structures and enums. These proxies would be fully GObject-based, which > might be a plus, I hope. > > I would, for example, define a GObject ICalComponent, which would have > its i_cal_component_* API functions, mimic all the icalcomponent API, > hiding the icalcomponent structure in the background. Would it be possible to keep the current EDS API around and just add the new introspectable API? > Such change will be huge, but more importantly it'll be an earthquake > for anything using libecal (the ECalComponent would not use > icalcomponent anymore, it would start using ICalComponent instead). ECalComponent would use a proxy of the original icalcomponent, right? If the introspection layer in libical has a way to convert to and from the original icalcomponent and the introspectable proxy, then ECalComponent could convert back and forth as needed, depending on which API the EDS client uses. > Because of this earthquake, I would like to hear from others their > opinion. Maybe we overlooked some option in introspection (there is > preferred to create introspection based on code annotations, not to > define them by hand), but I'm afraid the most of the projects like > SyncEvolution, whether it'll be able to handle such change gracefully. I've made my peace with ABI and API changes in EDS ;-} I'm not happy about them, but I can handle them with a combination of ifdefs and compilation of backend shared objects on different Linux distros. Just give me enough and explicit warning beforehand. If an API change can't be avoided, then don't let SyncEvolution hold you back. Bye, Patrick ___ 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] Introspection enablement for libecal - huge changes needed?
On Fri, 2014-05-16 at 19:28 +0200, Milan Crha wrote: > The main problem is that the API returns pointers which are part of the > structure that you ask the value of it - like when you ask for a > subcomponent of an icalcomponent. If it exists, you get a child of the > parent component. This makes a disaster due to the unpredictable memory > management in python or javascript (introspection-using languages in > general?). The libecal uses this libical behaviour too. As an example, > if you ask for an alarm of an ECalComponent, then you receive a new > structure which holds a libical structure, which is part of the > ECalComponent (icalcomponent of it). Any changes done through this > structure are immediately propagated into the parent's ECalComponent, > aka there is no "save" involved. If you free ECalComponent before the > alarm structure, then the free of the alarm structure causes a crash. As > you cannot influence the memory-free time in python... and even if it > would be possible, then we cannot expect from the introspection > interface users (developers) to tweak their code in a way they are not > used to (like making some memory/variable management on their own). Aren't you going to run into the same problem with a GObject-based proxies for these libical objects? The proxies are reference-counted, the libical objects are not, so they may go away before their proxies do. This would leave the proxy with a dangling pointer or (if it somehow tracks the lifetime of the owner of the object) in a state where it is unusable. Bye, Patrick ___ 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] custom labels
On Fri, 2014-05-02 at 10:51 +0200, Patrick Ohly wrote: > I'm still undecided. A too complex X-ABLabel property value could be > simplified to store it in a X-ABLabel parameter, but that'll drop user > data. I went ahead with the X-ABLabel as parameter approach. My gut feeling is that this will be easier to support in EDS and Evolution than connecting two different properties. The full flexibility of a property is not needed for labels; for example, line breaks can be entered neither on an iPad nor in Google Contacts. SyncEvolution >= 1.4.99.2 will start to copy custom labels into X-ABLabel when syncing with a CardDAV server. As mentioned before, Evolution currently drops the parameter extension. I've created a bug for that: https://bugzilla.gnome.org/show_bug.cgi?id=730636 Bye, Patrick ___ 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] custom labels
On Fri, 2014-05-23 at 15:58 +0200, Milan Crha wrote: > On Fri, 2014-05-23 at 14:56 +0200, Patrick Ohly wrote: > > I went ahead with the X-ABLabel as parameter approach. > > Hi, > I'm sorry you didn't get any answer for this thread. I always forgot of > it, also due to not having much opinion on the subject. > > I still do not fully understand what are the custom labels for. Is it a > per-attribute property or a per-contact property? It feels like > categories, if the later. What are the labels used for in UI? Instead if just the pre-defined "Work", "Home", "Other", etc., the user can also enter arbitrary text. For example, instead of "Other Tel: foo" the user can enter "Vacation Tel: bar" for a telephone number that is to be used when that contact is in his vacation home. It's even more important for dates. There might be a lot more dates to be stored than just birthday and anniversary, so a repeating X-ABDate property is used with custom labels to allow that. Same for related persons. Bye, Patrick ___ 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] custom labels
On Mon, 2014-05-26 at 07:38 +0200, Milan Crha wrote: > On Sun, 2014-05-25 at 21:41 +0200, Patrick Ohly wrote: > > Instead if just the pre-defined "Work", "Home", "Other", etc., the user > > can also enter arbitrary text. For example, instead of "Other Tel: foo" > > the user can enter "Vacation Tel: bar" for a telephone number that is to > > be used when that contact is in his vacation home. > > > > It's even more important for dates. There might be a lot more dates to > > be stored than just birthday and anniversary, so a repeating X-ABDate > > property is used with custom labels to allow that. Same for related > > persons. > > Hi, > aha, I see, so it's more like TYPE parameter, with more fine-grained > values. Would it be too complicated to use TYPE instead? So you mean something like TYPE=X-? The problem would be to distinguish between "X-FOOBAR as a TYPE extensions" and "X-FOOBAR as user entered text". X-ABLabel avoids that by introducing a new parameter. > It'll be > slightly complicated for evolution's UI, but probably easier than > dealing with it in a separate widget. I'm not sure whether this is easier for the UI. The whole EContact API deals poorly with arbitrary number of repeating properties. For some properties one can iterate over all of them (E_CONTACT_TEL), for others one can't (E_CONTACT_ADDRESS is documented as a single EContactAddress? Might be a documentation bug). For IM information it's definitely not possible to access arbitrary chat handles; the API only supports those for which a E_CONTACT_ADDRESS_ exists. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ 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] Refactoring contact editor
On Wed, 2014-09-03 at 18:14 +0200, Milan Crha wrote: > On Wed, 2014-09-03 at 12:55 -0300, Tristan Van Berkom wrote: > > While we're here, do you think it would be a good idea to > > migrate away from the hard coded list of vcard labels/ids ? > > > > If you're going to redo the UI anyway, it might be a good > > idea to move towards something more flexible, with UI > > functionalities such as: > > o Add a new email/phonenumber/address > > - When adding a new phone number, let the > > user enter their own label, a user may have > > one or more "HOME" phone numbers, etc > > o Delete an email/phonenumber/address > > o View all emails/phonenumbers/addresses regardless > > of whether they are in any hard coded list of labels > > > > With the possibility of synchronizing your addressbook with > > another addressbook (on your mobile or wherever), it would > > be interesting to support the data which can be found in > > a given vCard that may not have been created by evolution, > > in which case it becomes important to read the whole vCard > > for what it is. > > > > However, I suppose there might be localization issues with > > this, I suppose the hard coded fields that evolution lets > > you edit have translatable labels in the UI, perhaps there > > is some not-too-difficult way to allow both (to be honest, > > it's possible that evolution at least lets you view all > > of the emails/phonenumbers/addresses, I'm not sure, but > > at least allowing that would be worthwhile). > > > > Hi, > it sounds like Patrick Ohly's "[Evolution-hackers] custom labels" > discussion [1] from this year's spring. That's much more work than > just replace custom widgets with a stock expander. That could be part of it. The more important aspect (to me at least) is the increased flexibility (no longer limited to a fixed number of telephone numbers/emails/etc.) and easier access to information. In most cases, all data will fit into one page, while at the moment one has to switch between different tabs to see everything. Bye, Patrick ___ 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] Refactoring contact editor
On Thu, 2014-09-04 at 18:16 +0200, schaarsc wrote: > Am Mittwoch, den 03.09.2014, 18:14 +0200 schrieb Milan Crha: > > it sounds like Patrick Ohly's "[Evolution-hackers] custom labels" > > discussion [1] from this year's spring. That's much more work than > > just replace custom widgets with a stock expander. > > besides of being more work than just removing code... > From my point of view there is still the unsolved issue on where to > store the custom label. > I'd rather like to see this standardized first instead of using > X-ABLABEL, You mean, an official "ITEMLABEL" property (note that LABEL is taken in vCard) in a future vCard RFC? While that would be useful, I wouldn't hold my breath while waiting for it ;-) > for example by allowing free text in TYPE or by adding a new > type (TYPE=CUSTOM;CTYPE=my-label) Using a parameter instead of a property has the problem of not being able to store arbitrary text. The MIME DIR spec simply doesn't support it at the moment. See the earlier mail thread referenced by Milan about this - as I said there, my conclusion was that the limitations probably are acceptable for the kind of values entered by users, but I am open for other suggestions. Bye, Patrick ___ 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] Move authentication of backends back to the client (3.13.90)
On Mon, 2015-02-02 at 17:25 +0100, Milan Crha wrote: > Hello, > I just committed a change, for 3.13.90 development version, into > evolution-data-server [1], evolution [2], evolution-ews [3] and > evolution-mapi [4], which moves authentication back to the clients. As discussed with Milan on IRC, I was worried that this change would break compatibility with SyncEvolution although SyncEvolution primarily (exclusively?!) is used with local storage, which works without authentication. I now looked further and found that SyncEvolution already works with the new EDS, despite the changed API (e_book_client_connect, e_cal_client_connect). That's because SyncEvolution opens an ESource with e_client_open(), which hasn't changed. SyncEvolution obviously won't work for sources which require authentication, but I don't think that'll be a big issue. [...] I have not looked at the concept in detail, but it looks reasonable at first glance. > The other follow-up work will be to adapt any "clients" and libraries > which might be affected by this change. I'd like to help as much as > I'll be able, thus if there will be any issues spotted, feel free to > ping me or drop me an email and I'll help you to migrate your code. I > also removed all the old authentication code and functions, to avoid > those system-modal prompts and basically all the old behavior users > didn't like, the same as to cleanup API as much as possible. > Bye, > Milan > > [1] > https://git.gnome.org/browse/evolution-data-server/commit/?id=884fb8d872787d9 One comment that I already made on IRC: adding one additional int parameter to e_book_client_connect and e_cal_client_connect falls a bit short IMHO. I bet there will be some point in the future when some other new parameter will also be needed, causing another API break which could be avoided now. What I would prefer instead of the additional int parameter is a string->variant hash with a list of keys which can be extended in the future without breaking the API. Old clients not passing enough information then can either use reasonable defaults (when possible) or get an error telling the user to get his software updated. I think that's better than causing old software unconditionally to not compile (due to a API change) or to not run (due to an ABI/soname change), because it keeps the option open to run some old software unchanged. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ 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] Move authentication of backends back to the client (3.13.90)
On Thu, 2015-02-19 at 07:43 +0100, Milan Crha wrote: > On Wed, 2015-02-18 at 13:54 +0100, Patrick Ohly wrote: > > What I would prefer instead of the additional int parameter is a > > string->variant hash with a list of keys which can be extended in > > the future without breaking the API. Old clients not passing enough > > information then can either use reasonable defaults (when possible) > > or get an error telling the user to get his software updated. > > Hi, > I would not do that this way. It would be horrible to call the > function and create extra arguments for it in some sort of array and > variants and so on. It's a pita to convert parameters forth and back > when passing them through GDBus already, thus rather not add the same > burden to the client functions too. I'm not convinced, but it's your project. However, I reserve the right to say "told you so" once the API needs to be changed the next time. > > I think that's better than causing old software unconditionally to > > not compile (due to a API change) or to not run (due to an > > ABI/soname change), because it keeps the option open to run some old > > software > > unchanged. > > I always understood that it's the soname version which is meant to > cover these situations. Not that the two versions of eds can be > installed in parallel in one prefix. But distro's typically don't do that because it's extra work to maintain two versions of the same software in parallel. It also would not work for EDS, because each client library is typically tightly coupled with a certain daemon version, and those cannot be installed or run in parallel. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] importing iCalendar with VTIMEZONE definitions into Evolution
Dear Evolution hackers, there are various discussions in bugzilla about problems in Evolution with timezones (#317422, #315235, #332911). As part of #317422 chenthill has submitted a patch which fixes problems if the calendar backend already knows the custom timezone while the GUI doesn't. My understanding is thus that the backends are responsible for storing these extra timezone definitions. Please correct me if I'm wrong here. I am the developer of the "SyncEvolution" SyncML client for Evolution [1]. It uses the ecal API to extract and store iCalendar 2.0 items that it gets from the SyncML library. I have not found a good method yet to also store the VTIMEZONE definition in the backend. What I currently do is: 1. icomp = icalcomponent_new_from_string() 2. event = icalcomponent_get_first_component(ICAL_VEVENT_COMPONENT) 3. e_cal_create_object(event) If I omit the second step, e_cal_create_object() complains with "Invalid object", but obviously with the second step the backend only sees the VEVENT and never gets a chance to store the VTIMEZONE definition. The Evolution GUI also doesn't get this right: importing an iCalendar item with timezone definition into a local calendar drops the custom timezone definition and thus shifts the event (Evolution 2.4 - I haven't tried 2.6 yet). Can anybody tell me what's the right way to import iCalendar? [1] http://sourceforge.net/projects/sync4jevolution -- Bye, Patrick Ohly -- [EMAIL PROTECTED] [EMAIL PROTECTED] (MakeCD related mails) http://home.pages.de/~ohly/ http://makecd.core.de/ (MakeCD home page) ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Want to post bounty for SyncML plugin (to use with eGroupware)
On Thu, 2006-05-25 at 13:33 +0900, Daniel Bo wrote: > I will post a bounty for a plugin to Evo for SyncML, and have asked for > help from the eGroupware community before I do. I would like input from > the potential programmers of the plugin on how to write the bounty and > whether there is a better API for the sync. I have a command line SyncML client nearly ready for testing with calendars, contacts and tasks. egroupware seems to use the Funambol SyncML server - this should work. There's no need to post a bounty, I'll release the client anyway. A version for just contacts has been available for a while now [1]. However, I didn't intend to put it into a plugin because I wanted to avoid the learning curve for that - perhaps your bounty would motivate someone to work on that aspect. > Please look at the details on the eGroupware forums: > http://egroupware.org/forum/viewtopic.php?t=28568 The URL above didn't work, but with a little searching I found: http://forum.egroupware.org/viewtopic.php?t=28568 [1] http://sourceforge.net/projects/sync4jevolution -- Bye, Patrick Ohly -- [EMAIL PROTECTED] [EMAIL PROTECTED] (MakeCD related mails) http://home.pages.de/~ohly/ http://makecd.core.de/ (MakeCD home page) ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] importing iCalendar with VTIMEZONE definitions into Evolution
On Fri, 2006-06-02 at 14:11 +0530, Chenthill wrote: > On Thu, 2006-06-01 at 22:51 +0200, Patrick Ohly wrote: > > I am the developer of the "SyncEvolution" SyncML client for Evolution > > [1]. It uses the ecal API to extract and store iCalendar 2.0 items that > > it gets from the SyncML library. I have not found a good method yet to > > also store the VTIMEZONE definition in the backend. > > > What I currently do is: > > 1. icomp = icalcomponent_new_from_string() > > 2. event = icalcomponent_get_first_component(ICAL_VEVENT_COMPONENT) > > 3. e_cal_create_object(event) > You can get the timezone components separately using > zone = icalcomponent_get_first_component (ICAL_VTIMEZONE_COMPONENT) > and then add it to the backend using > e_cal_add_timezone (ECal *ecal, icaltimezone *izone, GError **error). Thanks, that seems to work. > > The Evolution GUI also doesn't get this right: importing an iCalendar > > item with timezone definition into a local calendar drops the custom > > timezone definition and thus shifts the event (Evolution 2.4 - I haven't > > tried 2.6 yet). > This might be that the timezone is already present in libical and not > correct. Could you please verify it ? No, it wasn't. When importing the file e_cal_add_timezone() is not called (verified in a debugger), but ended up in .evolution/calendar/local/*.ics anyway. That it doesn't show up in the GUI properly must have been something different. I'll retest with 2.6.2 once I find the time to compile it. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] [EMAIL PROTECTED] (MakeCD related mails) http://home.pages.de/~ohly/ http://makecd.core.de/ (MakeCD home page) ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] automated testing of Evolution data server with SyncEvolution
leworld/dataserver.log.gz [4] http://www.estamos.de/runtests/2006-10-14-17-00/0.4-2.18.0/5-scheduleworld/dataserver.log.gz -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] automated testing of Evolution data server with SyncEvolution
On Sun, 2006-10-15 at 23:32 +0200, Øystein Gisnås wrote: > 2006/10/15, Patrick Ohly <[EMAIL PROTECTED]>: > > * Is someone going to take care of the reported regression or do > > you need a patch to fix it? Whoever changed the code between 2.6 > > and 2.8 should be in a better position to fix it, so I am a bit > > reluctant to investigate further in code that I don't know. > > It seems like this is quiet times when it comes to patch review. I am > very sure though, that a bug report with a good patch will much more > likely be applied soon. If upstream doesn't look at it, I will > consider applying it to Debian. Ah, good. > > * Is someone running Evolution and in particular the Evolution > > data server under valgrind as part of release testing or regular > > quality assurance? > > I know there is performance work in relation with evolution for suse > installations. For general quality assurance there are not enough > routines in place. I know it's on the todo list of the developers. > When it comes to valgrind testing, evolution becomes quite slow so > patience is a must. One can test e-d-s non-interactively, which is what I am doing at the moment. Okay, if no-one else is working on it I'll have to see what I can find out on my own. > > * Which branches are still maintained? At the moment Debian still > > has 2.6 in testing and unstable; if there is a chance to still > > get bug fixes into that version, I'd concentrate on that first > > instead of the more recent 2.8. > > There is still a chance to get bug fixes into 2.6. Right now I plan an > upload of evolution-exchange 2.6.3, but there may be uploads of evo > and e-d-s soon, depending of the severity of the problems. > > 2.8 is in experimental, and we still hope we can push that in before > the release of etch. I would recommend developing against 2.8 > actually, since your application isn't targeted for etch. But some users (myself included) would compile it for the Debian version, so I want that Evolution to work as good as possible. I suspect that a patch for the stability problem would work for both 2.6 and 2.8 (the valgrind stack backtrace looks very similar), so I'll target 2.6 first. The vcard import problem is specific to 2.8 anyway. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] SyncML for mail (was: Re: automated testing of Evolution data server with SyncEvolution)
On Tue, 2006-10-17 at 14:49 +0200, Philip Van Hoof wrote: > On Sun, 2006-10-15 at 22:57 +0200, Patrick Ohly wrote: > > > I have not mentioned it on this list before, so before I come to the > > real reason for this email let me introduce it briefly: SyncEvolution[1] > > is a SyncML client that I wrote to synchronize address books, calendars > > and tasks list between Evolution and mobile devices or Evolution > > instances on different computers. > > This might be interesting for tinymail too. Especially synchronising > E-mail to a local mbox or Maildir on a flashdisk and/or over GPRS, > Bluetooth or whatever in some efficient bandwidth saving way (as some > can become expensive per amount of MB, like GPRS). Funambol, the company behind the GPL SyncML C++ client library that I use and to some extend help to improve, is working on push mail via SyncML. None of this has been tested with Linux clients yet, though. > Maybe we should exchange ideas and discuss how we can make the user > experience of both the developer and end-user even better sooner or > later? Definitely, but right now I am pretty loaded with work and won't have time for an in-depth discussion. Please, lets defer it a bit. Depending on how Evolution specific the discussion would be the Funambol developers list might be a better place, too. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] automated testing of Evolution data server with SyncEvolution
On Mo, 2006-10-16 at 19:21 +0200, Patrick Ohly wrote: > > > * Is someone running Evolution and in particular the > Evolution > > > data server under valgrind as part of release testing or > regular > > > quality assurance? > > > > I know there is performance work in relation with evolution for suse > > installations. For general quality assurance there are not enough > > routines in place. I know it's on the todo list of the developers. > > When it comes to valgrind testing, evolution becomes quite slow so > > patience is a must. > > One can test e-d-s non-interactively, which is what I am doing at the > moment. Okay, if no-one else is working on it I'll have to see what I > can find out on my own. I found out what the problem is, see http://bugzilla.gnome.org/show_bug.cgi?id=363102 The memory access error is caused by two threads operating on the same data: the main one is writing the calendar to disk in the idle loop, the other is processing a CORBA request to delete components of that same calendar. There is a mutex, but none of the CORBA implementation functions lock it. Any suggestions how to fix this? As I said in that issue, several solutions come to mind: - lock the mutex inside the high-level e_cal_backend_* functions - lock the mutex inside the low-level functions like remove_component - serialize idle saving and CORBA requests by having the saving executed as a CORBA call (not sure exactly how that could be done...) Of course, one could always disable the writing of the calendar data in the idle loop, but without some other means to flush the data it would be very dangerous to wait until an orderly shutdown of the E-D-S process. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] automated testing of Evolution data server with SyncEvolution - vcard import problem in 2.8
On So, 2006-10-15 at 22:57 +0200, Patrick Ohly wrote: > * Is someone going to take care of the reported regression or do > you need a patch to fix it? Whoever changed the code between 2.6 > and 2.8 should be in a better position to fix it, so I am a bit > reluctant to investigate further in code that I don't know. I found out what the problem is, see http://bugzilla.gnome.org/show_bug.cgi?id=356176 The fix is included in that issue (add one line with a function call). It should be easy to verify that it causes no harm and indeed fixes the problem. Can someone commit it for E-D-S 2.8.2? Øystein, can you make sure that it gets included in Debian packages if Etch would otherwise be released with an E-D-S where this bug is still present? Should I file a bug in the Debian tracker as a reminder? -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] sorting out bugs by taking a look at the dup count
Dear Andre, thanks for taking care of organizing the bugs! Please keep up the good job. On Do, 2006-10-19 at 14:36 +0200, Andre Klapper wrote: > > http://bugzilla.gnome.org/show_bug.cgi?id=312348 > e-d-s calendar/orbit2 memory corruption > 19 duplicates, stacktrace with line numbers&symbols available > 363102 seems to be unrelated, but could also be addressed as it seems > to > be a similar problem. If someone has suggestions about 363102 I'd be happy to implement them as this is the number one problem for me. I'm away over the weekend; if I still don't hear anything by Monday I'll look at the code again and add mutex locking where I consider it appropriate. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] automated testing of Evolution data server with SyncEvolution
On Mi, 2006-10-18 at 19:24 +0200, Patrick Ohly wrote:
> I found out what the problem is, see
> http://bugzilla.gnome.org/show_bug.cgi?id=363102
[...]
> There is a mutex, but none of the CORBA implementation functions lock
> it. Any suggestions how to fix this? As I said in that issue, several
> solutions come to mind:
> - lock the mutex inside the high-level e_cal_backend_* functions
I went for this one. In wasn't always sure for all calls whether a mutex
lock was necessary or not, so I might have added too many (affecting
performance and limiting concurrency?) as well as not adding enough
(f.i. during initialization and file opening/closing).
A first test run of SyncEvolution tests for the calendar backend
completed successfully and Evolution itself also still works. I'll wait
until the modified E-D-S has passed the full test suite for some days,
then attach the patch to the bugzilla entry and also add bugs to the
Debian tracker as discussed earlier.
In the meantime please find the current patch against 1.8.1 attached. As
usual, any comments are welcome.
--
Bye, Patrick Ohly
--
[EMAIL PROTECTED]
http://www.estamos.de/
#
# Patch managed by http://www.holgerschurig.de/patcher.html
#
--- evolution-data-server-1.8.1/calendar/backends/file/e-cal-backend-file.c~idle-save-locking
+++ evolution-data-server-1.8.1/calendar/backends/file/e-cal-backend-file.c
@@ -70,7 +70,12 @@
gboolean is_dirty;
guint dirty_idle_id;
- GMutex *idle_save_mutex;
+ /* locked in high-level functions to ensure data is consistent
+ * in idle and CORBA thread(s?); because high-level functions
+ * may call other high-level functions the mutex must allow
+ * recursive locking
+ */
+ GStaticRecMutex idle_save_rmutex;
/* Toplevel VCALENDAR component */
icalcomponent *icalcomp;
@@ -135,10 +140,10 @@
g_assert (priv->uri != NULL);
g_assert (priv->icalcomp != NULL);
- g_mutex_lock (priv->idle_save_mutex);
+ g_static_rec_mutex_lock (&priv->idle_save_rmutex);
if (!priv->is_dirty) {
priv->dirty_idle_id = 0;
- g_mutex_unlock (priv->idle_save_mutex);
+ g_static_rec_mutex_unlock (&priv->idle_save_rmutex);
return FALSE;
}
@@ -193,18 +198,18 @@
priv->is_dirty = FALSE;
priv->dirty_idle_id = 0;
- g_mutex_unlock (priv->idle_save_mutex);
+ g_static_rec_mutex_unlock (&priv->idle_save_rmutex);
return FALSE;
error_malformed_uri:
- g_mutex_unlock (priv->idle_save_mutex);
+ g_static_rec_mutex_unlock (&priv->idle_save_rmutex);
e_cal_backend_notify_error (E_CAL_BACKEND (cbfile),
_("Cannot save calendar data: Malformed URI."));
return TRUE;
error:
- g_mutex_unlock (priv->idle_save_mutex);
+ g_static_rec_mutex_unlock (&priv->idle_save_rmutex);
e_cal_backend_notify_error (E_CAL_BACKEND (cbfile), gnome_vfs_result_to_string (result));
return TRUE;
}
@@ -216,13 +221,13 @@
priv = cbfile->priv;
- g_mutex_lock (priv->idle_save_mutex);
+ g_static_rec_mutex_lock (&priv->idle_save_rmutex);
priv->is_dirty = TRUE;
if (!priv->dirty_idle_id)
priv->dirty_idle_id = g_idle_add ((GSourceFunc) save_file_when_idle, cbfile);
- g_mutex_unlock (priv->idle_save_mutex);
+ g_static_rec_mutex_unlock (&priv->idle_save_rmutex);
}
static void
@@ -290,10 +295,7 @@
priv->dirty_idle_id = 0;
}
- if (priv->idle_save_mutex) {
- g_mutex_free (priv->idle_save_mutex);
- priv->idle_save_mutex = NULL;
- }
+ g_static_rec_mutex_free (&priv->idle_save_rmutex);
if (priv->uri) {
g_free (priv->uri);
@@ -1085,9 +1087,13 @@
g_return_val_if_fail (uid != NULL, GNOME_Evolution_Calendar_ObjectNotFound);
g_assert (priv->comp_uid_hash != NULL);
+ g_static_rec_mutex_lock (&priv->idle_save_rmutex);
+
obj_data = g_hash_table_lookup (priv->comp_uid_hash, uid);
- if (!obj_data)
+ if (!obj_data) {
+ g_static_rec_mutex_unlock (&priv->idle_save_rmutex);
return GNOME_Evolution_Calendar_ObjectNotFound;
+ }
if (rid && *rid) {
ECalComponent *comp;
@@ -1103,8 +1109,10 @@
icalcomp = e_cal_util_construct_instance (
e_cal_component_get_icalcomponent (obj_data->full_object),
itt);
- if (!icalcomp)
+ if (!icalcomp) {
+g_static_rec_mutex_unlock (&priv->idle_save_rmutex);
return GNOME_Evolution_Calendar_ObjectNotFound;
+}
*object = g_strdup (icalcomponent_as_ical_string (icalcomp));
@@ -1130,6 +1138,7 @@
*object = e_cal_component_get_as_string (obj_data->full_object);
}
+ g_static_rec_mutex_unlock (&priv->idle_save_rmutex);
return GNOME_Evolution_Calendar_Success;
}
@@ -1148,23 +1157,30 @@
g_return_val_if_fail (priv->icalcomp != NULL, GNOME_Evolution_Calendar_NoSuchCal);
g_return_val_if_fail (tzid != NULL, GNOME_Evolution_Calendar_ObjectNotFound);
+ g_static_rec_mutex_lock (&priv->idle_save_rmutex);
+
Re: [Evolution-hackers] automated testing of Evolution data server with SyncEvolution - vcard import problem in 2.8
On Fr, 2006-10-20 at 02:11 +0200, Øystein Gisnås wrote: > > Øystein, can you make sure that it gets included in Debian packages > if > > Etch would otherwise be released with an E-D-S where this bug is > still > > present? Should I file a bug in the Debian tracker as a reminder? > > Yes and yes. I will look into it and incorporate before etch if it > looks good. An entry in BTS ensures me (and the rest of the team) > won't forget it.. Done, please see Debian BTS #395416 and #395417. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Requests
On Do, 2007-01-04 at 05:40 +0100, Andre Klapper wrote: > > A greater wish would be an interface for eGroupware, perhaps per SyncML > > or so. There are external programs already, but it's still a bit > > complicated. > > yes, there's an syncml plugin available, as far as i know - it is > possible already. what's exactly "complicated" here? There are even two, OpenSync and my (IMHO of course) less complex SyncEvolution. SyncEvolution is tested against eGroupware. What is missing in both solutions is a true Evolution plugin. I'd be happy to accept a patch for SyncEvolution which adds that... at least this might be relevant for this list ;-) -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Question about Groupwise and Memos (see bug 389668)
On Sat, 2007-02-10 at 09:39 -0800, Nathan Owens wrote: > As for the Start Date - the memos component isn't meant to be a Journal. It > only uses the VJOURNAL > format because I didn't want to write a new backend (and at the time, the > consensus on the > evolution-hackers list was that VJOURNAL would be appropriate). This is unrelated to your GUI proposal, but let me point out nevertheless that this was a good choice: adding support for memo synchronization in the upcoming SyncEvolution 0.6 was a breeze exactly because the same backend and backend API as for calendars was used. Thanks for working on this, BTW. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Addressbook Maintainership
On Fri, 2007-05-18 at 18:00 +, Srinivasa Ragavan wrote: > It is with great pleasure I announce that Ross Burton joins me > as "Addressbook maintainer". Good news indeed. Thanks a lot to Ross for everything he has done already, and of course also to everyone else who helps to improve Evolution and to keep it nice and shiny! On the other hand, does that mean that I should stop bothering you with reports about problems in the EDS DBus version of libecal, Ross? ;-) -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] comma-separation of event CATEGORIES
Hello, I got a report that SyncEvolution does not handle CATEGORIES correctly in ical 2.0 events when multiple categories are specified. It turned out that Evolution or more likely, libical, import/export such events with the comma separator escaped like this: CATEGORIES:Anniversary\,Holiday RFC 2445 specifies CATEGORIES with a normal comma as separator and gives this example: CATEGORIES:APPOINTMENT,EDUCATION When importing such an event, Evolution stores it with two different category properties and then only uses the later one in the GUI: CATEGORIES:APPOINTMENT CATEGORIES:EDUCATION At first glance there doesn't seem to be an open bug related to this; it still happens with Evolution 2.10. I will open a bug and investigate further, but let me bring up some points here first: * I suppose right now Evolution continues to use its own libical. Are there plans to synchronize with upstream (whathever that is at the moment)? * Any bug fix for this should be backwards compatible and treat \, just like a normal comma because all existing .ics files will continue to contain \, and I would like to add a hack to SyncEvolution which converts between \, and , to work around the issue in existing Evolution versions. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] comma-separation of event CATEGORIES
On Sun, 2007-06-24 at 18:28 +0200, Patrick Ohly wrote: [separator of CATEGORIES \, incompatible with iCalendar 2.0] > At first glance there doesn't seem to be an open bug related to this; it > still happens with Evolution 2.10. I will open a bug http://bugzilla.gnome.org/show_bug.cgi?id=455274 > and investigate > further, Sorry, no time for that :-/ -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] EDS API calls hang when EDS dies - how to detect that?
Hello, SyncEvolution users have started to report that the "syncevolution" process hangs, as far as I could tell from the reports while accessing the Evolution Dataserver through libecal's or libebook's synchronous functions (e.g. in e_book_get_contact()). It then also happened to me randomly with Evolution 2.6.3 from Debian stable. The reason apparently was that the Evolution Dataserver process had died (the Evolution GUI said that much and ps confirmed it), but e_book_get_contact() didn't return. The main point of this email is not the EDS crash (I trust that 2.12 will be more stable due to all the hard work you guys put into it - I will compile it as soon as time permits or perhaps even better, run SyncEvolution more regularly against unstable versions), but what I can do in SyncEvolution to detect the EDS crash and report it properly to the user. Looking at the current libebook API documentation [1] I see a "backend-died" signal prototype. I don't remember having seen that before - was the signal or its documentation added recently? I suppose I can call g_signal_connect(ebook, "backend-died", mycallback, NULL), then in mycallback print an error and abort the process, right? Aborting the process is a very drastic reaction, it would be much nicer if e_book_get_contact() would return an error in that case. Can I achieve that by doing something in my code with the existing libebook shared objects shipped today? [1] http://www.gnome.org/projects/evolution/developer-doc/libebook/EBook.html -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] EDS API calls hang when EDS dies - how to detect that?
On Sun, 2007-09-23 at 22:13 +0100, Ross Burton wrote: > On Sun, 2007-09-23 at 22:21 +0200, Patrick Ohly wrote: > > I suppose I can call g_signal_connect(ebook, "backend-died", mycallback, > > NULL), then in mycallback print an error and abort the process, right? > > > Aborting the process is a very drastic reaction, it would be much nicer > > if e_book_get_contact() would return an error in that case. Can I > > achieve that by doing something in my code with the existing libebook > > shared objects shipped today? > > Every blocking function should detect the backend crashing and return an > error message. I'm not tremendously up to speed on the details of > Bonobo, but this should be a fairly simple patch. I agree that the blocking functions should detect the problem and return, but currently they don't and even if this got fixed, I wouldn't like to force people to upgrade Evolution for the fix. Any idea how I can fix that in the code which calls the API? > I'll point out that the DBus port should handle this already. :) I know, I have seen the timeouts on the Maemo port - sometimes even too early... ;-) -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Ubuntu 7.10 upgrade leaves useless libedataserver around
Hello, I think we have some Evolution packagers around here, so let me draw your attention to a problem that a SyncEvolution user recently had (see [1]). He upgraded to Ubuntu 7.10/Evolution 2.12, but still had a SyncEvolution binary around which depended on the older libedataserver1.2-7 from Evolution 2.10 (or 2.8). That library was not removed during the upgrade (not sure exactly why), which led to rather obscure error messages when starting SyncEvolution: (process:7164): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `(null)' (process:7164): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (process:7164): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `ESourceGroup' (process:7164): e-data-server-CRITICAL **: e_source_group_peek_sources: assertion `E_IS_SOURCE_GROUP (group)' failed 21:07:48 GMT -0700 [ERROR] - calendar: not found: Cumples' IMHO it would be nice if the libedataserver1.2-9 packaged conflicted with libedataserver1.2-7 so that users who upgrade are notified that they need a SyncEvolution which is compatible with 2.12, either because their package manager knows that SyncEvolution depends on libedataserver1.2-7 or when SyncEvolution fails to start with a missing library error message. Note that I also ran into problems starting Evolution 2.6.3 after running Evolution 2.12 in the same account; I had to reset my gconf data to get 2.6.3 running again (more on that in another email) - I'm mentioning it here because it seems related. In case anyone is interested, because binary incompatibilities with Evolution releases require different SyncEvolution binaries I have gathered that information in [2]. [1] http://sourceforge.net/tracker/index.php?func=detail&aid=1818718&group_id=146288&atid=764733 [2] http://www.estamos.de/projects/SyncML/Compatibility.html#Evolution -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Evolution] New version of the Evo SVN Makefile - patch for Debian Etch
On Di, 2007-10-02 at 18:42 -0400, Paul Smith wrote: > Anyway, if you want a simple way to build Evo from SVN without > rebuilding all of Gnome (as with GARNOME), give it a whirl! > > http://mad-scientist.us/evolution.html Thanks a lot for this, I found it very useful. It did not quite do what I needed (building on Debian Etch), so I patched it (attached): * I don't need evolution-exchange and evolution-webcal, so I added the possibility to remove packages and enable flags from PACKAGES via local.mk: IGNORE_PACKAGES, IGNORE_FEATURES * Added package check for debian-etch, reusing the rules for Ubuntu: distro := debian-etch in local.mk * Etch's gtk+-2.0 and intltool are not recent enough for 2.12. I compiled them separately first and pointed with PKG_CONFIG_PATH, LD_LIBRARY_PATH (otherwise configure check for glib fails!) and PATH towards that installation (my local.mk is attached). The Makefile had to be changed to preserve these values. * I don't have root priviliges on the SyncEvolution nightly test machine, so I needed a way to disable sudo. * Added "export BONOBO_ACTIVATION_PATH=$prefix/lib/bonobo/servers" to evolution-svn to pick the right components for 2.12.1 * gnome-doc-utils was needed. I suspect it also needs to be added to ubuntu-PREREQS. I have successfully built Evolution 2.12.1 with these modifications on my desktop and without root priviliges on the SyncEvolution nightly test machine. One big warning! After starting Evolution 2.12.1 once and (after killing all of its processes) restarting Evolution 2.6.3 from Debian Etch the latter crashed reproducibly with: (evolution-2.6:19361): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `(null)' (evolution-2.6:19361): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (evolution-2.6:19361): GLib-GObject-WARNING **: invalid uninstantiatable type `' in cast to `ESourceGroup' (evolution-2.6:19361): e-data-server-CRITICAL **: e_source_group_peek_name: assertion `E_IS_SOURCE_GROUP (group)' failed After restoring .gconf and .gconfd from a backup (= kill gconfd, copy whole directory hierarchy) it worked again. I did not investigate in more detail, but I saw that 2.12.1 had modified the source definitions in .gconf/%gconf-tree.xml. So unless precautions are taken, updating from 2.6.3 to 2.12.1 is a one-way street! -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ CCACHE := SUDO := true prefix := /usr/local/evo-svn distro := debian-etch V := branch := 2.20 IGNORE_PACKAGES := evolution-exchange evolution-webcal IGNORE_FEATURES := --enable-exchange=yes PKG_CONFIG_PATH := /home/patrick/evo-svn/gtk+2.0/lib/pkgconfig:$(PKG_CONFIG_PATH) export PKG_CONFIG_PATH PATH := /home/patrick/evo-svn/gtk+2.0/bin:$(PATH) LD_LIBRARY_PATH := /home/patrick/evo-svn/gtk+2.0/lib:$(LD_LIBRARY_PATH) export LD_LIBRARY_PATH *** /scratch/evo-src/Makefile.orig 2007-10-03 00:23:39.0 +0200 --- Makefile 2007-10-25 19:00:20.0 +0200 *** *** 58,66 --- 58,81 # Comment this out if you don't want to use ccache CCACHE := ccache + # Set this to "true" if you have to build without root priviliges. + # Beware that file locking of a local mailbox file may be affected! + # Installing without root priviliges is not recommended if you + # get email from a local file. + # SUDO := true + SUDO := sudo + # Set this to empty if you want to see the rules being run V := @ + # Optional packages which are not to be built, e.g.: + # IGNORE_PACKAGES := evolution-exchange evolution-webcal + IGNORE_PACKAGES := + + # Optional features which are not to be enabled, e.g.: + # IGNORE_FEATURES := --enable-exchange=yes + IGNORE_FEATURES := + # You can override the above by creating local.mk setting these vars # if you don't want to modify this makefile. *** *** 76,92 # These are the prerequisite packages needed on the system before we can build # Evo. There are different ways to check for them, based on distro. ! DISTROS := ubuntu ubuntu-PREREQS := \ gtk-doc-tools subversion libldap2-dev libnss-dev libnspr-dev \ libgail-dev flex bison build-essential evolution-dev \ icon-naming-utils $(CCACHE) # These are the packages we need to build from SVN, and any config/make/etc. # customized options we need to provide. ! PACKAGES := libsoup gtkhtml gnome-icon-theme evolution-data-server \ ! evolution evolution-exchange evolution-webcal CONFIG_VARS = CC='$(CC)' CFLAGS=-g CONFIG_OPTS = --prefix='$(prefix)' --- 91,114 # These are the prerequisite packages needed on the system before we can build # Evo. There are different ways to check for them, based on distro. ! DI
[Evolution-hackers] libtool madness: creates *.so*T linked against the wrong libs
Hello,
I try to compile Evolution 2.12.x on Debian Etch, using Paul Smith's
Makefile. I was successful once, but not anymore. The problem is that
"libtool --install" puts e.g. a libebook.so into my installation
directory which was linked against the system's libcamel and not the one
from Evolution 2.12.x.
I traced it down to the install step:
[EMAIL PROTECTED](/scratch/evo-src/evolution-data-server/addressbook/libebook)$
rm .libs/libebook-1.2.so.9.1.0T
[EMAIL PROTECTED](/scratch/evo-src/evolution-data-server/addressbook/libebook)$
/bin/sh ../../libtool --mode=install /usr/bin/install -c 'libebook-1.2.la'
'/usr/local/evo-svn/lib/libebook-1.2.la'
libtool: install: warning: relinking `libebook-1.2.la'
(cd /scratch/evo-src/evolution-data-server/addressbook/libebook; /bin/sh
../../libtool --mode=relink gcc -g -Wall -Wmissing-prototypes
-Wno-sign-compare -o libebook-1.2.la -rpath /usr/local/evo-svn/lib
-version-info 10:0:1 Evolution-DataServer-Addressbook-common.lo
Evolution-DataServer-Addressbook-skels.lo
Evolution-DataServer-Addressbook-stubs.lo e-address-western.lo
e-book-listener.lo e-book-query.lo e-book-view-listener.lo e-book-view.lo
e-book.lo e-contact.lo e-destination.lo e-name-western.lo e-vcard.lo -pthread
-L/home/patrick/evo-svn/gtk+2.0/lib -lxml2 -lgnome-2 -lpopt -lgnomevfs-2
-lbonobo-2 -lgconf-2 -lgobject-2.0 -lbonobo-activation -lORBit-2 -lm
-lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lglib-2.0 ../../camel/libcamel-1.2.la
../../libedataserver/libedataserver-1.2.la )
gcc -shared .libs/Evolution-DataServer-Addressbook-common.o
.libs/Evolution-DataServer-Addressbook-skels.o
.libs/Evolution-DataServer-Addressbook-stubs.o .libs/e-address-western.o
.libs/e-book-listener.o .libs/e-book-query.o .libs/e-book-view-listener.o
.libs/e-book-view.o .libs/e-book.o .libs/e-contact.o .libs/e-destination.o
.libs/e-name-western.o .libs/e-vcard.o -Wl,--rpath
-Wl,/home/patrick/evo-svn/gtk+2.0/lib -Wl,--rpath -Wl,/usr/local/evo-svn/lib
-L/home/patrick/evo-svn/gtk+2.0/lib -L/usr/lib -lxml2 -lgnome-2 -lpopt
-lgnomevfs-2 -lbonobo-2 -lgconf-2 -lgobject-2.0 -lbonobo-activation -lORBit-2
-lm -lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lglib-2.0 -L/usr/local/evo-svn/lib
-lcamel-1.2 -ledataserver-1.2 -pthread -Wl,-soname -Wl,libebook-1.2.so.9 -o
.libs/libebook-1.2.so.9.1.0
/usr/bin/install -c .libs/libebook-1.2.so.9.1.0T
/usr/local/evo-svn/lib/libebook-1.2.so.9.1.0
(cd /usr/local/evo-svn/lib && { ln -s -f libebook-1.2.so.9.1.0
libebook-1.2.so.9 || { rm -f libebook-1.2.so.9 && ln -s libebook-1.2.so.9.1.0
libebook-1.2.so.9; }; })
(cd /usr/local/evo-svn/lib && { ln -s -f libebook-1.2.so.9.1.0 libebook-1.2.so
|| { rm -f libebook-1.2.so && ln -s libebook-1.2.so.9.1.0 libebook-1.2.so; }; })
/usr/bin/install -c .libs/libebook-1.2.lai
/usr/local/evo-svn/lib/libebook-1.2.la
PATH="$PATH:/sbin" ldconfig -n /usr/local/evo-svn/lib
--
Libraries have been installed in:
/usr/local/evo-svn/lib
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,--rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
--
[EMAIL PROTECTED](/scratch/evo-src/evolution-data-server/addressbook/libebook)$
ldd .libs/libebook-1.2.so.9.1.0 | grep camel
libcamel-1.2.so.10 =>
/scratch/evo-src/evolution-data-server/camel/.libs/libcamel-1.2.so.10
(0xb7b4d000)
[EMAIL PROTECTED](/scratch/evo-src/evolution-data-server/addressbook/libebook)$
ldd .libs/libebook-1.2.so.9.1.0T | grep camel
libcamel-1.2.so.8 => /usr/lib/libcamel-1.2.so.8 (0xb7b2c000)
Note how gcc relinks libebook-1.2.so.9.1.0 correctly against
libcamel-1.2.so.10, but then libebook-1.2.so.9.1.0T gets installed. I
had removed that file but libtool must have recreated it - I have no
idea where.
Before I start to dissect the "libtool" script (no, please, please,
spare me), does this look familiar to anyone?
--
Bye, Patrick Ohly
--
[EMAIL PROTECTED]
http://www.estamos.de/
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libtool madness: creates *.so*T linked against the wrong libs
On Thu, 2007-11-01 at 17:15 +0100, Patrick Ohly wrote:
> Hello,
>
> I try to compile Evolution 2.12.x on Debian Etch, using Paul Smith's
> Makefile. I was successful once, but not anymore. The problem is that
> "libtool --install" puts e.g. a libebook.so into my installation
> directory which was linked against the system's libcamel and not the one
> >from Evolution 2.12.x.
>
> I traced it down to the install step:
>
> [EMAIL
> PROTECTED](/scratch/evo-src/evolution-data-server/addressbook/libebook)$ rm
> .libs/libebook-1.2.so.9.1.0T
> [EMAIL
> PROTECTED](/scratch/evo-src/evolution-data-server/addressbook/libebook)$
> /bin/sh ../../libtool --mode=install /usr/bin/install -c 'libebook-1.2.la'
> '/usr/local/evo-svn/lib/libebook-1.2.la'
> libtool: install: warning: relinking `libebook-1.2.la'
> (cd /scratch/evo-src/evolution-data-server/addressbook/libebook; /bin/sh
> ../../libtool --mode=relink gcc -g -Wall -Wmissing-prototypes
> -Wno-sign-compare -o libebook-1.2.la -rpath /usr/local/evo-svn/lib
> -version-info 10:0:1 Evolution-DataServer-Addressbook-common.lo
> Evolution-DataServer-Addressbook-skels.lo
> Evolution-DataServer-Addressbook-stubs.lo e-address-western.lo
> e-book-listener.lo e-book-query.lo e-book-view-listener.lo e-book-view.lo
> e-book.lo e-contact.lo e-destination.lo e-name-western.lo e-vcard.lo -pthread
> -L/home/patrick/evo-svn/gtk+2.0/lib -lxml2 -lgnome-2 -lpopt -lgnomevfs-2
> -lbonobo-2 -lgconf-2 -lgobject-2.0 -lbonobo-activation -lORBit-2 -lm
> -lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lglib-2.0 ../../camel/libcamel-1.2.la
> ../../libedataserver/libedataserver-1.2.la )
> gcc -shared .libs/Evolution-DataServer-Addressbook-common.o
> .libs/Evolution-DataServer-Addressbook-skels.o
> .libs/Evolution-DataServer-Addressbook-stubs.o .libs/e-address-western.o
> .libs/e-book-listener.o .libs/e-book-query.o .libs/e-book-view-listener.o
> .libs/e-book-view.o .libs/e-book.o .libs/e-contact.o .libs/e-destination.o
> .libs/e-name-western.o .libs/e-vcard.o -Wl,--rpath
> -Wl,/home/patrick/evo-svn/gtk+2.0/lib -Wl,--rpath -Wl,/usr/local/evo-svn/lib
> -L/home/patrick/evo-svn/gtk+2.0/lib -L/usr/lib -lxml2 -lgnome-2 -lpopt
> -lgnomevfs-2 -lbonobo-2 -lgconf-2 -lgobject-2.0 -lbonobo-activation -lORBit-2
> -lm -lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lglib-2.0 -L/usr/local/evo-svn/lib
> -lcamel-1.2 -ledataserver-1.2 -pthread -Wl,-soname -Wl,libebook-1.2.so.9 -o
> .libs/libebook-1.2.so.9.1.0
[...]
I found that libtool shuffles the libs around:
44512: gcc -shared .libs/Evolution-DataServer-Addressbook-common.o
.libs/Evolution-DataServer-Addressbook-skels.o
.libs/Evolution-DataServer-Addressbook-stubs.o .libs/e-address-western.o
.libs/e-book-listener.o .libs/e-book-query.o .libs/e-book-view-listener.o
.libs/e-book-view.o .libs/e-book.o .libs/e-contact.o .libs/e-destination.o
.libs/e-name-western.o .libs/e-vcard.o -Wl,--rpath
-Wl,/home/patrick/evo-svn/gtk+2.0/lib -Wl,--rpath -Wl,/usr/local/evo-svn/lib
-L/home/patrick/evo-svn/gtk+2.0/lib -L/usr/lib -lxml2 -lgnome-2 -lpopt
-lgnomevfs-2 -lbonobo-2 -lgconf-2 -lgobject-2.0 -lbonobo-activation -lORBit-2
-lm -lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lglib-2.0 -L/usr/local/evo-svn/lib
-lcamel-1.2 -ledataserver-1.2 -pthread -Wl,-soname -Wl,libebook-1.2.so.9 -o
.libs/libebook-1.2.so.9.1.0
4523: IFS='
'
4526: test relink = relink
4527: eval '(cd $output_objdir && $rm ${realname}T && $mv $realname
${realname}T && $mv "$realname"U $realname)'
44527: cd .libs
44527: rm -f libebook-1.2.so.9.1.0T
44527: mv -f libebook-1.2.so.9.1.0 libebook-1.2.so.9.1.0T
44527: mv -f libebook-1.2.so.9.1.0U libebook-1.2.so.9.1.0
4529: test -n ''
4536: exit 0
So originally the library was compiled okay, but during the "relinking"
step a "-L/usr/local/evo-svn/lib" is missing in the gcc invocation
(-Wl,-rpath for that path is present!) and the wrong libcamel is picked
up.
> Before I start to dissect the "libtool" script (no, please, please,
> spare me), does this look familiar to anyone?
The questions now are: why is the relinking necessary and why does it go
wrong?
--
Bye, Patrick Ohly
--
[EMAIL PROTECTED]
http://www.estamos.de/
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libtool madness: creates *.so*T linked against the wrong libs
On Thu, 2007-11-01 at 17:56 +0100, Patrick Ohly wrote: > > gcc > -shared .libs/Evolution-DataServer-Addressbook-common.o > .libs/Evolution-DataServer-Addressbook-skels.o > .libs/Evolution-DataServer-Addressbook-stubs.o .libs/e-address-western.o > .libs/e-book-listener.o .libs/e-book-query.o .libs/e-book-view-listener.o > .libs/e-book-view.o .libs/e-book.o .libs/e-contact.o .libs/e-destination.o > .libs/e-name-western.o .libs/e-vcard.o -Wl,--rpath > -Wl,/home/patrick/evo-svn/gtk+2.0/lib -Wl,--rpath -Wl,/usr/local/evo-svn/lib > -L/home/patrick/evo-svn/gtk+2.0/lib -L/usr/lib -lxml2 -lgnome-2 -lpopt > -lgnomevfs-2 -lbonobo-2 -lgconf-2 -lgobject-2.0 -lbonobo-activation -lORBit-2 > -lm -lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lglib-2.0 -L/usr/local/evo-svn/lib > -lcamel-1.2 -ledataserver-1.2 -pthread -Wl,-soname -Wl,libebook-1.2.so.9 -o > .libs/libebook-1.2.so.9.1.0 > [...] > > So originally the library was compiled okay, but during the > "relinking" > step a "-L/usr/local/evo-svn/lib" is missing in the gcc invocation > (-Wl,-rpath for that path is present!) and the wrong libcamel is > picked > up. Scratch that. -L/usr/local/evo-svn/lib was added right in front of -lcamel-1.2, but because -L/usr/lib came first it had no effect. I need better eyes. I'm not sure how to fix this in libtool. My workaround is an explicit LDFLAGS=-L/usr/local/evo-svn/lib in the environment of configure and make. Hmm, the .la files installed in /usr/local/evo-svn/lib still reference /usr/lib/libglib and then linking SyncEvolution fails. Okay, so I'll hack those, too... Somehow I get the feeling that I am not solving this properly. Any suggestions are welcome. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution-data-server crashes when running syncevolution - poll() called with GPollFD?
Hello, can someone please comment on: http://bugzilla.gnome.org/show_bug.cgi?id=41 I got Evolution 2.12.x compiled and can reproduce the problem and look at it in a debugger, but I have no clue about the underlying reason. It's somehow related to having poll() as poll_func in a main loop context. This problem currently affects many (probably all) users of SyncEvolution who synchronize calendars with SyncEvolution 2.12.0. It popped up when Ubuntu Gutsy was released and people upgraded their distros. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution-data-server crashes when running syncevolution - poll() called with GPollFD?
On Thu, 2007-11-01 at 18:45 -0400, Matthew Barnes wrote:
> On Thu, 2007-11-01 at 23:06 +0100, Patrick Ohly wrote:
> > can someone please comment on:
> > http://bugzilla.gnome.org/show_bug.cgi?id=41
> >
> > I got Evolution 2.12.x compiled and can reproduce the problem and look
> > at it in a debugger, but I have no clue about the underlying reason.
> > It's somehow related to having poll() as poll_func in a main loop
> > context.
>
> poll() isn't the problem, this is:
Right, I got distracted by the "[signal handler called]" inside poll().
Poor excuse, I simply wasn't thinking properly anymore :-/
[...]
> Hope this helps,
Yes, it did - thanks!
>From the issue:
---
Okay, I found the reason. In Evolution 2.12.x the behavior of
e_cal_create_object() for objects with a fixed UID has changed. Previously the
call would fail if the UID was already used and then SyncEvolution falls back
to updating that object, roughly like this:
if(!e_cal_create_object(m_calendar, subcomp, &uid, &gerror) &&
gerror->domain == E_CALENDAR_ERROR &&
gerror->code == E_CALENDAR_STATUS_OBJECT_ID_ALREADY_EXISTS) {
e_cal_modify_object(m_calendar, subcomp, CALOBJ_MOD_ALL, &gerror)
}
This code no longer works because now e_cal_create_object() *removes* the
conflicting UID. Then e_cal_modify_object() crashes because the hash is called
with a NULL UID pointer.
I don't know if this change was intentional; perhaps it was added to allow a
second e_cal_create_object() too succeed. I think it would have been better to
preserve the old behavior and document it. Clients need to decide how to handle
the E_CALENDAR_STATUS_OBJECT_ID_ALREADY_EXISTS error anyway and IMHO updating
instead of duplicating the event is the more useful choice. If the client
wanted to duplicate, it could clear the UID.
Anyway, now that the reason is clear it was easy to add a workaround. Now the
code makes less assumptions about e_cal_create_object() (which is always good)
and restores the UID before e_cal_modify_object(). I'll keep the issue open
until I have a SyncEvolution with the workaround released, then close it.
Thanks to all who helped investigate this and to Matthew Barnes for pointing me
in the right direction on the Evo developer list.
---
--
Bye, Patrick Ohly
--
[EMAIL PROTECTED]
http://www.estamos.de/
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] EDS API calls hang when EDS dies - how to detect that?
On Sun, 2007-09-23 at 22:21 +0200, Patrick Ohly wrote:
> Looking at the current libebook API documentation [1] I see a
> "backend-died" signal prototype. I don't remember having seen that
> before - was the signal or its documentation added recently?
>
> I suppose I can call g_signal_connect(ebook, "backend-died", mycallback,
> NULL), then in mycallback print an error and abort the process, right?
I tried that, but although the evolution-data-server process is gone the
signal wasn't delivered.
My actual code is:
g_signal_connect_after(m_calendar,
"backend-died",
G_CALLBACK(EvolutionSyncClient::fatalError),
(void *)"Evolution Data Server has died
unexpectedly, database no longer available.");
I saw in the code that (backend_died" (BTW, why the underscore instead
of the hyphen used elsewhere?) is hooked to component_died in
e-component-listener.c which in turn depends on
ORBit_small_listen_for_broken(). Somehow the callback given to
ORBit_small_listen_for_broken() is never called: I have a breakpoint
there in a debugger.
[a bit later]
Tracing through it in the debugger I see that orbit2-2.14.7/linc2 is
responsible for monitoring the file descriptor. linc notices that the
link goes down (LINK_DISCONNECTED in link_connection_state_changed_T_R)
and it schedules an idle callback which would have raised the
necesessary signals (g_idle_add (link_connection_broken_idle, cnx)).
The problem now is: this idle callback is not invoked.
[yet a bit later]
I stepped through g_idle_add(). The idle callback is attached to the
default context returned by g_main_context_default():
(gdb) p *default_main_context
$16 = {mutex = {runtime_mutex = 0x0, static_mutex = {
pad =
"\001\000\000\000\000\000\000\0005U\000\000\000\000\000\000\001\000\000\000\000\000\000",
dummy_double = 4.9406564584124654e-324, dummy_pointer = 0x1, dummy_long =
1}}, cond = 0x0, owner = 0x0,
owner_count = 0, waiters = 0x0, ref_count = 1, pending_dispatches =
0x8198010, timeout = 0, next_id = 5,
source_list = 0x81983a0, in_check_or_prepare = 0, poll_records = 0x8198020,
n_poll_records = 2,
cached_poll_array = 0x0, cached_poll_array_size = 0, wake_up_pipe = {9, 10},
wake_up_rec = {fd = 9, events = 1,
revents = 0}, poll_waiting = 0, poll_changed = 1, poll_func = 0xb73fc7c0
, current_time = {tv_sec = 0,
tv_usec = 0}, time_is_current = 0}
(gdb) p default_main_context
$17 = (GMainContext *) 0x81982e8
This is not the context of the thread which runs the orbit loop:
g_main_context_iterate (context=0x81a0528, ...
So if I understand this correctly, the problem with the synchronous EDS
API calls is that no thread drives the default event loop unless the
application does that.
[trying it out in SyncEvolution]
Adding a background thread which runs an event loop in the default
context indeed caused the "backend-died" signal to be emitted. I thought
that maybe now the API functions would also return an error, but not so:
unless I terminate the process in my own "backend-died" signal handler
the process remains stuck in the synchronous API call.
Enough for now: I have a solution which is good enough for
SyncEvolution. I still wonder if and how the problem could be fixed in
the EDS libs, but this is out of scope for me - sorry!
--
Bye, Patrick Ohly
--
[EMAIL PROTECTED]
http://www.estamos.de/
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] libtool madness: creates *.so*T linked against the wrong libs - solved
Hello,
just in case someone runs into the email thread, here's what properly
solved my problem that some of the Evolution .la files specified a
libglib from Debian Etch's /usr/lib although a more recent one was
needed: not only glib2 has to be compiled from a more recent source than
currently in Debian Etch, but also *all* GNOME libraries which reference
it.
I had only recompiled libglib because its shared object was backwards
compatible against the system's shared objects, but getting libtool to
use just the new glib2 turned out to be troublesome because other .la
files pulled in /usr/lib/libglib2.so. Here's what I recompiled (might
have forgotten some, though):
* glib2
* libidl
* orbit2
* libbonobo2
* gtk2
--
Bye, Patrick Ohly
--
[EMAIL PROTECTED]
http://www.estamos.de/
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] nightly builds of Evolution + testing with SyncEvolution
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]. 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 ;-} 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'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? Are there other tests of the EDS API which I should run? If Novel already does regular testing this probably isn't needed. [1] http://mad-scientist.us/evolution.html -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] nightly builds of Evolution + testing withSyncEvolution
On 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? How do I detect failures? I just tried it on evolution-data-server and got e.g.: [...] Failed 48/662 tests, 92% okay Failed tests: 2/23 2/24 2/26 2/27 2/28 2/29 2/32 2/47 2/48 2/50 2/51 2/52 2/53 2/56 2/71 2/72 2/74 2/75 2/76 2/77 2/80 2/95 2/96 2/98 2/99 2/100 2/101 2/104 2/119 2/120 2/122 2/123 2/124 2/125 10/295 10/325 14/344 14/345 14/346 15/347 15/349 15/350 15/351 27/486 31/503 32/505 39/599 39/600 PASS: regression == All 1 tests passed == make[5]: Leaving directory `/tmp/runtests/head/tmp/evolutiontrunk-build/evolution-data-server/calendar/libical/src/test' The "make check" at top level returned no error code. Looking at calendar/libical/src/test/regression.c I see that it always returns 0, so I guess I have to scan the log output to find failures, right? Are the failures above something that should be reported? To make regular testing useful failing tests either have to be skipped or fixed in a timely fashion. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] nightly builds of Evolution +testing withSyncEvolution
On Wed, 2008-02-13 at 09:44 +0530, Srinivasa Ragavan wrote: > On Tue, 2008-02-12 at 19:55 +0100, Patrick Ohly wrote: > > 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. Then how do I run the existing tests instead? -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] compiling Evolution from source: incorrectly picks up system libs (Bugzilla #518728)
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! To those who run into this problem: deinstalling the host's development packages for Evolution should avoid the problem. It's not an option for me though as I also compile against those in other builds of SyncEvolution. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution doesn't honor LC_TIME (and other LC_ variables)
On Mi, 2008-03-05 at 10:59 +0100, Raúl Núñez de Arenas Coronado wrote: > Since Evolution uses gettext to get the appropriate format strings for > "strftime", no matter what you say on your LC_TIME, you only get the > date and time information properly formatted for your language if you > set LANG (or LANGUAGE). I noticed that too and it keeps annoying me at regular intervals, but never enough to investigate - thanks for the nice explanation! > I don't think I'm the only one out there that needs a fine grained > locale, You are not, I do the same with German data settings while text is in English. > I'm not sure about which solution is best, and probably the "%x" > solution is easier and will do the right job. If that's the case, I can > try to change the sources so strftime uses "%x" and not hardcoded > combinations of "%d" and "%m". I cannot comment on the best technical approach, but I would love to see some solution implemented. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] evolution-data-server addressbook backend
On Tue, 2008-03-18 at 11:34 +0100, Matthias Braun wrote: > I just started developing a custom addressbook(1) backend and have a few > questions regarding the API. First I wonder about the functions > get_contact_list, get_contact and get_changes. They don't seem to be > used by evolution. Are there applications around that use them? Yes. SyncEvolution[1] uses them. If you want to run automated tests against your new backend, then you can compile and configure SyncEvolution so that its "client-test Client::Source::vcard30" test accesses it - you have to set the "evolutionsource" property in the configs. See the HACKING document in the SyncEvolution distribution for details. [1] http://www.estamos.de/projects/SyncML/ -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] checking Evolution with valgrind
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
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).
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.
e_book_get_changes():
static void unref(GList *pointer) {
if (pointer) {
GList *next = pointer;
do {
EBookChange *ebc = (EBookChange *)next->data;
g_object_unref(ebc->contact);
g_free(next->data);
next = next->next;
} while (next);
g_list_free(pointer);
}
}
e_cal_get_changes():
static void unref(GList *pointer) {
if (pointer) {
GList *next = pointer;
do {
ECalChange *ecc = (ECalChange *)next->data;
g_object_unref(ecc->comp);
g_free(next->data);
next = next->next;
} while (next);
g_list_free(pointer);
}
}
e_book_get_contacts():
e_cal_get_object_list_as_comp():
static void unref(GList *pointer) {
if (pointer) {
GList *next = pointer;
do {
g_object_unref(G_OBJECT(next->data));
next = next->next;
} while (next);
g_list_free(pointer);
}
}
--
Bye, Patrick Ohly
--
[EMAIL PROTECTED]
http://www.estamos.de/
evo.supp.bz2
Description: application/bzip
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] checking Evolution with valgrind
On Tue, 2008-03-25 at 23:44 +0530, Srinivasa Ragavan wrote: > On Tue, 2008-03-25 at 20:58 +0100, Patrick Ohly wrote: > > 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. I'm afraid it won't help Evolution much apart from catching regressions from now on, because ... > The best is that if you could track it down to Evolution, file a bug > with the valgrind traces and CC me there. ... this is exactly what I won't have time for - sorry! I was hoping that some other developer would perhaps be motivated to use valgrind to analyse some of these problems. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] checking Evolution with valgrind
On Wed, 2008-03-26 at 15:03 -0400, Matthew Barnes wrote: > On Wed, 2008-03-26 at 19:33 +0100, Patrick Ohly wrote: > > > The best is that if you could track it down to Evolution, file a > bug > > > with the valgrind traces and CC me there. > > > > ... this is exactly what I won't have time for - sorry! I was hoping > > that some other developer would perhaps be motivated to use valgrind to > > analyse some of these problems. > > I run Evolution and E-D-S under valgrind occasionally but haven't made a > regular habit of it. I'll try to start doing that regularly. Great, here's a good reason to fire it up: http://bugzilla.gnome.org/show_bug.cgi?id=524964 Hint: your changes seem to be involved in the use-after-free and ensuing crash found in the nightly testing ;-) My offer still stands: I could add interested developers to CC of the emails which report nightly test success or failure. I look at the results rather sporadically; this time only two days have passed since the tests started to fail, but it could easily be a week or more. The tests still produce new valgrind leak reports for which I don't have suppression rules; in particular the "potentially lost" reports seem to be a bit random. Currently I'm still in the "ignore leaks" mode and just suppress anything that I find. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] checking Evolution with valgrind
On Sat, 2008-03-29 at 12:32 -0400, Matthew Barnes wrote: > On Sat, 2008-03-29 at 14:46 +0100, Patrick Ohly wrote: > > My offer still stands: I could add interested developers to CC of the > > emails which report nightly test success or failure. I look at the > > results rather sporadically; this time only two days have passed since > > the tests started to fail, but it could easily be a week or more. > > Sign me up, please. > > Not sure how responsive I'll be at fixing leaks as they emerge, but I'd > like to stay informed at least. Thanks for volunteering. As an example, the attached email was marked in red in my inbox due to an incoming filter which checks for "failed". "evolutiontrunk" is the build step of the latest Evolution source. If it fails, then the other steps are attempted with whatever did compile or is left from a previous compilation. The rationale is that if building the Evolution GUI fails, EDS testing would still run. "client-api" and "syncevolution" are the repository checkouts of these two components; "compile", well, compiles them. When that fails, no tests are run. "evolution" is the part where EDS and the SyncEvolution client are tested - this is what we want to succeed. The rest of the email can be ignored. > Thanks for your efforts here, by the way. It's very much appreciated. Thanks for your kind words. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ --- Begin Message --- http://www.estamos.de/runtests/2008-03-29-10-00/head-evolution-trunk-minimal evolutiontrunk successful client-api successful syncevolution successful compile successful dist skipped: disabled in configuration evolution: CLIENT_TEST_ALARM=1200 CLIENT_TEST_LOG= CLIENT_TEST_EVOLUTION_PREFIX=file:///tmp/runtests/head/work/databases run_garnome /home/patrick/evo-svn/gtk+2.0 /tmp/runtests/head/tmp/evolutiontrunk-result valgrindcheck.sh ./client-test Client::Source: failed (return code 35072) scheduleworld skipped: disabled in configuration egroupware skipped: disabled in configuration synthesis skipped: disabled in configuration funambol skipped: disabled in configuration /home/patrick/bin/runtests.py --client-tag r_tested --configure --enable-static-cxx LDFLAGS=-Wl,--as-needed --prefix=/usr --tmp=/tmp/runtests/head/tmp --workdir=/tmp/runtests/head/work --resultdir=/home/patrick/runtests/2008-03-29-10-00/head-evolution-trunk-minimal --resulturi=http://www.estamos.de/runtests/2008-03-29-10-00/head-evolution-trunk-minimal --shell=run_garnome /home/patrick/evo-svn/gtk+2.0 /tmp/runtests/head/tmp/evolutiontrunk-result --evosvn=trunk=/home/patrick/evo-svn --enable evolutiontrunk --enable compile --enable evolution --test-prefix=valgrindcheck.sh --from [EMAIL PROTECTED] --to [EMAIL PROTECTED] --- End Message --- ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] cleaning up the timezone handling mess
lans to tackle the problem? Is someone working on it? Similar questions in #301363 were not answered. Do you agree with the outlined plan in principle? If no-one else is working on it and you agree, then I would describe the new API call in more detail and see whether I can get it implemented. I would reuse the same code in SyncEvolution in order to improve the situation with older Evolution releases and to avoid depending on an extended libecal in the binary releases. What is the timeline for this? 2.22 is released; if this version is picked up by distributions unpatched, then we are bound to run into the same problems again end of 2008 and probably also 2009. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VTIMEZONE TZID:GMT -0600 (Standard) / GMT -0500 (Daylight) BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETFROM:-0500 TZOFFSETTO:-0600 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T02 TZOFFSETFROM:-0600 TZOFFSETTO:-0500 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=4;BYDAY=1SU END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20060907T131935Z DTSTART;TZID="GMT -0600 (Standard) / GMT -0500 (Daylight)":20060912T073000 SUMMARY:Weekly Phone Call UID:04008200E00074C5B7101A82E008309E865A56D2C601000 0100066DB701609E60F4B9352E50A0E0F6334 DTEND;TZID="GMT -0600 (Standard) / GMT -0500 (Daylight)":20060912T08 RRULE:FREQ=WEEKLY;UNTIL=20201229T133000Z;INTERVAL=1;BYDAY=TU;WKST=SU SEQUENCE:0 PRIORITY:5 CREATED:20060907T131935Z LAST-MODIFIED:20060907T132254Z STATUS:CONFIRMED TRANSP:OPAQUE END:VEVENT END:VCALENDAR BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft CDO for Microsoft Exchange VERSION:2.0 BEGIN:VTIMEZONE TZID:GMT -0600 (Standard) / GMT -0500 (Daylight) BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETFROM:-0500 TZOFFSETTO:-0600 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=11;BYDAY=1SU END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T02 TZOFFSETFROM:-0600 TZOFFSETTO:-0500 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=2SU END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT DTSTAMP:20080320T114812Z DTSTART;TZID="GMT -0600 (Standard) / GMT -0500 (Daylight)":20080325T073000 SUMMARY:One Time Meeting UID:04008200E00074C5B7101A82E008808C1CEBC5ACC701000 010004F43682C84AEE84A8399EB29FF07BA7C DTEND;TZID="GMT -0600 (Standard) / GMT -0500 (Daylight)":20080325T08 SEQUENCE:0 PRIORITY:5 CREATED:20080320T114811Z LAST-MODIFIED:20080320T114816Z STATUS:CONFIRMED TRANSP:OPAQUE END:VEVENT END:VCALENDAR ___ 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 Do, 2008-04-03 at 19:45 +0200, Patrick Ohly wrote: > did the slightly inflammatory subject catch your attention? Hmm, it seems didn't, or the people who maintain the Evolution calendar are not reading this list/on vacation/busy. Should I rather lead this discussion in the bug tracker? -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] detecting new ical memory tracking
Hello, I now have the situation that I feared in issue #516408: SyncEvolution trunk uses libical calls where the returned string must be freed when SyncEvolution runs with Evolution 2.22 and must not be freed when run with older Evolution releases. My plan still is to only provide only one binary for 2.10, 2.12, 2.22, therefore I need the runtime detection of the API change that I suggested in http://bugzilla.gnome.org/show_bug.cgi?id=516408#c31 Introducing the code rewrite suggested by Michael is impossible. Can I have the less intrusive patch included on trunk and the stable branch, please? Or is there some other version number which can be queried at runtime? I'd rather not parse /proc/self/maps to find out what the revision of libecal is... As discussed in #516408, checking the version number would be sub-optimal. FWIW, the leak shows up nicely in the nightly testing: http://www.estamos.de/runtests/2008-04-08-10-00/head-evolution-trunk-minimal/6-evolution/ -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ 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 Mo, 2008-04-07 at 23:40 -0600, P Chenthill wrote: > On Thu, 2008-04-03 at 19:45 +0200, Patrick Ohly wrote: > > One could argue that the sending program is at fault: it could have used > > a different TZID after changing the timezone definition. Alternatively > > it could have sent a more complex VTIMEZONE which also includes the > > historic rules. I believe both causes other problems in practice. > > Speculating about it is futile anyway and won't change the meeting > > invitations that Evolution has to deal with. > > > > Besides, don't blame Outlook too much: Evolution >= 1.12 now does > > exactly the same thing. For example, a meeting invitation now uses > > "/softwarestudio.org/Tzfile/America/Los_Angeles" and only includes the > > current rules for daylight saving transitions. > It just includes the current rules for outlook compatibility. Yep, that's the "I believe both causes other problems in practice" part ;-) > I am just back after a small vacation. Ah, that explains the silence. I'll be away over the weekend and Monday myself and don't know whether I'll have time before I came back. > I dont think anyone is work on this issue currently. I made a patch for > exchange backend for solving this issue long time back. But > unfortunately its not committed in trunk. Why? Technical issues that I should be aware of? > It uses a timestamp in the > VTIMEZONE file to store the latest one always. By this way we would also > know the last time period when the timezone has been changed for that > location. I can't claim to understand the patch or the code that it applies to. When you say that only the latest VTIMEZONE is stored, that implies that only one is stored, right? How does that solve the problem of having an event in the calendar which depends on an old revision of the VTIMEZONE and another one which needs the current revision? > I am ok with handling using the sequence numbers. I am not sure whether > a new libecal API would be needed to solve this, since the timezones > would be handled at the backend. The client adds the VTIMEZONE and some time later the corresponding event. At that time the backend won't be able to correlate the two, but that is necessary to change the TZID in the event if the VTIMEZONE was stored with a different TZID. Only the client can do that. > It would be better to handle all the timezones in a common place inside > EDS. The reason for that is, same timezones can exist in multiple > calendars which could not be matched to either system timezone or > through the fuzzy logic. Currently it is handled separately for every > calendar and the same information is stored redundantly. Another issue > which should be taken care of is, the system timezones should not be > stored in the cache. They should always be taken from the libical > builtin timezone. Please consider these too while implementing the > solution. That's way beyond what I have time for, sorry. Besides, I want to keep my changes as small as possible to increase the chance of getting them into the stable branch. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] detecting new ical memory tracking
On Di, 2008-04-08 at 18:29 -0400, Matthew Barnes wrote: > More broadly, we should add some versioning macros and symbols to > libedataserver similar to [1], so Patrick could do something like: > > #if EDS_CHECK_VERSION(2,22,0) > ... free libical strings ... > #endif > > Would that address your needs, Patrick? It probably would work in practice, but I would have to make assumptions about which versions contain this new feature. As Chris Lord pointed out, eds-dbus might pick up the patch and then offer it under a different version. As of last weekend, SyncEvolution can synchronize calendars on Maemo with EDS-DBus, so I care about that. Making it work with that were part of the reason for changing SyncEvolution. Even if you add versioning information to 2.22.x, I still would have to depend on dlsym() tricks to work with older releases. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ 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 Fri, 2008-04-11 at 00:55 -0600, P Chenthill wrote: [Exchange calendar backend patch] > In cases of exchange the old VTIMEZONE and the new VTIMEZONE would have > the same tzid, only the rules would be different. All events old and new > will just use the latest timezone from the backend since they would have > the same tzid in their start/end dates. And that would be wrong for the old events which are truly in the past. Consider the 2006 example that I sent: when viewing the year 2006 in the calendar, the system timezone definition is used and thus Evolution correctly uses the summer saving rules from 2006. Using the updated VTIMEZONE for events in that year would lead to a one hour shift during those weeks where old and new rules differ. It's arguably the lesser evil for recurring events because the current, still relevant recurrences would be displayed correctly, so there is some value in it. But for old events which are archived for reference purposes it would be just wrong. What I am suggesting would solve this problem by preserving both the old and the new VTIMEZONE. For recurring events the mapping to the more complex system timezone definitions helps. [VTIMEZONE and VEVENT are added separately] > I don't think it works like that. iirc the whole VCALENDAR (used as > top-level component in itip-formatter) which has events and timezone > gets passed to the backend, the backend adds the timezone and events to > the cache, notifies the UI. After looking at the Evolution source code I already came to the same conclusion. However, clients like SyncEvolution do add VTIMEZONE and VEVENT separately. That is necessary because the UID of each new VEVENT is required immediately, which is not possible (or at least very awkward) via ecal_receive_objects(). This makes the new function a bit more complex, but I still think it is doable to come up with a solution which can be used by backends and clients. Attached is a proposal. In SyncEvolution I would lookup existing VTIMEZONE in the calendar via the e_cal_tzlookup_ecal() utility function, which then uses e_cal_get_timezone(). I checked the code of the file backend. The e_cal_check_timezone() call would fit right before the icalcomponent_merge_component() call and would use the other tzlookup function which checks against local VTIMEZONE components. All the other backends would have to be adapted in a similar way. I considered modifying the general e_cal_backend_file_receive_objects(), but decided against it because individual backends might have better ways of dealing with the problem. I also don't want to touch code which I cannot test. I will be out of town for three days. If there are no objections, then I'll try to get working code together when I come back, hopefully before I go on a business trip for two weeks the week after. Time, anyone got some time? -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ /** * This function cleans up VEVENT, VJOURNAL, VTODO and VTIMEZONE * items which are to be imported into Evolution. * * It deals with VTIMEZONE conflicts which occur when the calendar * already contains an old VTIMEZONE definition with the same TZID, * but different summer saving rules. Replacing the VTIMEZONE * potentially breaks displaying of old events, whereas not replacing * it breaks the new events (the behavior in Evolution <= 2.22.1). * * The way this problem is resolved is by renaming the new VTIMEZONE * definition until the TZID is unique. A running count is appended to * the TZID. All items referencing the renamed TZID are adapted * accordingly. * * Using VTIMEZONE definitions is problematic because they cannot be * updated properly when timezone definitions change and are * incomplete (for compatibility reason only one set of rules for * summer saving changes can be included, even if different rules * apply to different years). This function also looks for matches * of the used TZIDs against system timezones and replaces such TZIDs * with the corresponding system timezone. This works for TZIDs * following the Olson naming scheme by comparing the / * part and for Outlook TZIDs (via a hard-coded lookup table). * * @param comp either a VCALENDAR containing a list of * VTIMEZONE/VEVENT/VTODO/VJOURNAL items (in * arbitrary order) or such a list directly; * these are the items which are modified * @param tzlookup a callback function which is called to retrieve * a calendar's VTIMEZONE definition; the returned * string is freed by e_cal_check_timezones(); * NULL indicates that no such timezone exists * or an error occurred * @param customan arbitrary pointer which is passed through to * the tzlookup function * @retval erroran error description in case of a fa
Re: [Evolution-hackers] cleaning up the timezone handling mess
On Tue, 2008-04-15 at 13:59 +0530, chenthill wrote: > To preserve the timezone history, the best way would be to store the old > rules in VTIMEZONES which should be done in libical. If I understand you correctly, you are suggesting to merge a VTIMEZONE with TZID=FOO that comes with a new meeting invitation with a previously stored VTIMEZONE with the same TZID, so that the merged VTIMEZONE has the rules from both the original VTIMEZONE. The problem is that incoming VTIMEZONE definitions from Exchange do not contain information to which year the rules apply. In the examples that I quoted, both use DTSTART:16010101T02 and thus are mutually exclusive. > I do not recommend having another set of tzid's with > versions in it for maintaining the old rules. This would trigger the > comparison of rules between different versions of timezones. 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? > Once the > outlook timezones are mapped with libical ones, the libical timezones > which would have the old rules can be used. Mapping "foreign" TZIDs to system timezones always should be attempted first. Storing a VTIMEZONE under a different name is only the fallback. > > [VTIMEZONE and VEVENT are added separately] > > > I don't think it works like that. iirc the whole VCALENDAR (used as > > > top-level component in itip-formatter) which has events and timezone > > > gets passed to the backend, the backend adds the timezone and events to > > > the cache, notifies the UI. > > > > After looking at the Evolution source code I already came to the same > > conclusion. However, clients like SyncEvolution do add VTIMEZONE and > > VEVENT separately. That is necessary because the UID of each new VEVENT > > is required immediately, which is not possible (or at least very > > awkward) via ecal_receive_objects(). > I hope SyncEvolution is the only backend which does it in this way. SyncEvolution is not a backend. It is a client program using the synchronous libecal API. I believe OpenSync works the same way, although I haven't looked at it during the last two years. > I am > not sure if we would need a libecal API for this. Is it not possible to > handle it inside e_cal_backend_add_timezone? No, because the call cannot return the information to which TZID the timezone was mapped. Modifying the "icaltimezone *zone" would be an API change. > Yeah you can get the code after two weeks, not a problem. Please file a > bug on this since the old bug is about, outdated evolution timezones > which is obsolete now as we pickup the timezones from the system. The > bug also has a too many comments already. Probably we can also schedule > a meeting on irc and have a discussion on this. Please let me know the > time which would be suitable for you. I'll create a new bug report. Should we move the discussion away from this list? Usually we could meet on IRC during the evening CEST, but there's not much time this week. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ 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
Hello, attached a first revision of the new API call which implements the mapping of TZIDs to internal ones. I'm currently using (and testing) the code in SyncEvolution and it works already for some simple test cases. Some parts are marked as TODO; those will be filled in later. Right now I just want to illustrate the idea with a bit more code. Note also that I slightly rewrote the API documentation. There are likely memory leaks of libical strings. It is pretty hard to tell in advance which strings and entities need to be freed; IMHO the only reliable way to get this right is to have test cases and use valgrind. I'll do that before the final revision of the patch. Now, one specific question: how should I create a GError in the out-of-memory situation of e_cal_check_timezones()? I checked some of the other Evolution code to get an idea, but at least the few places I looked at didn't seem to check for out-of-memory. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ /* * Copyright (C) 2008 Patrick Ohly * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY, TITLE, NONINFRINGEMENT or FITNESS FOR A PARTICULAR * PURPOSE. See the GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA * 02111-1307 USA */ #ifndef ECAL_EXTENSION_H #define ECAL_EXTENSION_H #include #include G_BEGIN_DECLS /** * This function cleans up VEVENT, VJOURNAL, VTODO and VTIMEZONE * items which are to be imported into Evolution. * * Using VTIMEZONE definitions is problematic because they cannot be * updated properly when timezone definitions change. They are also * incomplete (for compatibility reason only one set of rules for * summer saving changes can be included, even if different rules * apply in different years). This function looks for matches of the * used TZIDs against system timezones and replaces such TZIDs with * the corresponding system timezone. This works for TZIDs containing * a location (found via a fuzzy string search) and for Outlook TZIDs * (via a hard-coded lookup table). * * Some programs generate broken meeting invitations with TZID, but * without including the corresponding VTIMEZONE. Importing such * invitations unchanged causes problems later on (meeting displayed * incorrectly, e_cal_get_component_as_string() fails). The situation * where this occurred in the past (found by a SyncEvolution user) is * now handled via the location based mapping. * * If this mapping fails, this function also deals with VTIMEZONE * conflicts: such conflicts occur when the calendar already contains * an old VTIMEZONE definition with the same TZID, but different * summer saving rules. Replacing the VTIMEZONE potentially breaks * displaying of old events, whereas not replacing it breaks the new * events (the behavior in Evolution <= 2.22.1). * * The way this problem is resolved is by renaming the new VTIMEZONE * definition until the TZID is unique. A running count is appended to * the TZID. All items referencing the renamed TZID are adapted * accordingly. * * @param comp a VCALENDAR containing a list of * VTIMEZONE and arbitrary other components, in * arbitrary order: these other components are * modified by this call * @param tzlookup a callback function which is called to retrieve * a calendar's VTIMEZONE definition; the returned * definition is freed by e_cal_check_timezones(); * NULL indicates that no such timezone exists * or an error occurred * @param customan arbitrary pointer which is passed through to * the tzlookup function * @retval erroran error description in case of a failure * @return TRUE if successful, FALSE otherwise. */ gboolean e_cal_check_timezones(icalcomponent *comp, icaltimezone *(*tzlookup)(const char *tzid, const void *custom, GError **error), const void *custom, GError **error); /** * An implementation of the tzlookup callback which clients * can use. Calls e_cal_get_timezone(). * * @param custom must be a valid ECal pointer */ icaltimezone *e_cal_tzlookup_ecal(const char *tzid,
Re: [Evolution-hackers] cleaning up the timezone handling mess
On Wed, 2008-04-16 at 13:59 +0530, chenthill palanisamy wrote: > The VTIMEZONE from libical currently do > not provide the history of timezone changes (older + current rrules) for > the system timezones. Libical should be modified so that the VTIMEZONE's > generated stores the timezone history. The Tzfile would have the history > stored on the system, libical just does not store it in VTIMEZONE. Wow, in that case the situation is much worse than I thought. My impression was that the patch to use system timezone definitions would solve the problem of using out-dated, incomplete timezone definitions shipped with Evolution. The truth is that it only eases the maintenance pain regarding out-dated definitions, but doesn't address the "timezones change over time" problem at all, right? If this was a known limitation, why was it not already filed as bug a long time ago? Evolution users running into timezone problems were instead told to update to the latest Evolution release and update their system timezone definitions, which in many cases didn't help at all. > Say if a meeting is received from exchange server with some Tzid for > America/New_York. As we discussed below, this needs to be mapped to > system timezone and libical should provide the VTIMEZONE which has the > timezone history. This way, we need not use the VTIMEZONE sent by > exchange and still display the older/current events properly. I agree that libical absolutely must use the complete timezone history stored on the system. This is independent from mapping "foreign" TZIDs to native ones; both is necessary, but can be implemented separately. Do you have an estimate how much work improvements for libical would be? Where are the places which have to be changed? How can we distinguish between extracting a VTIMEZONE which is to be sent to some other program and extracting a VTIMEZONE for internal use? Finally, one organizational question: should a patch be prepared against the libical in the GNOME or the SF repository? According to this post, the SF repository is trying to consolidate the various versions floating around: http://sourceforge.net/forum/forum.php?thread_id=1912252&forum_id=51011 How does the Evolution team stand with regards to that effort? > > > I do not recommend having another set of tzid's with > > > versions in it for maintaining the old rules. This would trigger the > > > comparison of rules between different versions of timezones. > > > > 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. > > > I hope SyncEvolution is the only backend which does it in this way. > > > > SyncEvolution is not a backend. It is a client program using the > > synchronous libecal API. > Ah ok. I misunderstood that it has a corresponding external backend as > well. Have a look at http://www.estamos.de/projects/SyncML/index.html - calling a SyncML server that VEVENTs are exchanged with "external backend" kind of fits, but not quite. > > > I am > > > not sure if we would need a libecal API for this. Is it not possible to > > > handle it inside e_cal_backend_add_timezone? > > > > No, because the call cannot return the information to which TZID the > > timezone was mapped. Modifying the "icaltimezone *zone" would be an API > > change. > The tzid need not be changed for the VEVENT. The following would work > fine even if VTIMEZONE and VEVENT are handled separately, > > e_cal_backend_add_timezone - Add the timezone to backend's cache if the > timezone cannot be matched with the system timezone else do not add. > > e_cal_backend_get_timezone - use the mapping and provide proper system > timezone or if its unable to map, it needs to get the timezone from the > cache. > > The clients can now use the corresponding libecal API's to get the right > timezone. So, I feel this can be done commonly to all backends at EDS. This fails to handle VTIMEZONE definition collisions in those cases where no mapping to system timezones is found. In that case the VTIME
Re: [Evolution-hackers] cleaning up the timezone handling mess
On Mi, 2008-04-16 at 13:59 +0530, chenthill palanisamy wrote: > > I'll create a new bug report. Should we move the discussion away from > > this list? > > I think if we discuss this on IRC, we can conclude on the design > faster. It would be better to do the patch reviews in bugzilla. Chenthill and I tried to meet on IRC, but despite his generous offer to meet outside his working hours we haven't found a slot yet. As I wanted to get something working before leaving for a two-week business trip where I cannot do anything on the code itself, I completed the code/patch as I had suggested earlier. It's still incomplete (no Outlook TZID table, memory handling of ical strings missing), but it solves the problem of importing conflicting time zone definitions already and maps TZIDs which contain a location at the end. As suggested by Chenthill I have moved the discussion to a new issue in the tracker. Please watch it and reply there if you are interested: http://bugzilla.gnome.org/show_bug.cgi?id=528902 "time zone handling insufficient" -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] detecting new ical memory tracking
Hello, this issue is getting urgent and needs to be solved, otherwise I cannot get rid of the memory leaks which currently break the nightly testing with trunk. I have created http://bugzilla.gnome.org/show_bug.cgi?id=528986 with the appeal to add the "ical_memfixes" variable (patch attached to that bug again). Please apply or implement some other runtime detection mechanism. These also needs to go into 22.x. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Subversion commit access
Hello,
I hesitated for a while ("With great power comes great responsibility",
and I have enough responsibilities already, thanks very much), but being
able to submit my patches to the Subversion repository directly would
make life easier for all involved, so... may I have write access to the
Evolution Subversion repository? Who can authorize that?
I would continue to discuss patches in the bug tracker, like before.
--
Bye, Patrick Ohly
--
[EMAIL PROTECTED]
http://www.estamos.de/
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] compile error: GNOME_KEYRING_RESULT_NO_MATCH
Hello, r8721 of evolution-data-server/libedataserverui/e-passwords.c in the 22.x branch fails to build if a libgnome-keyring older than 2.20.1 is installed (which is the case up to and including Ubuntu 7.20 Gutsy). The number 2.20.1 comes from [1], I haven't verified it myself. Adding a ">= 2.20.1" to EDS configure.in "solves" the problem in the sense that keyring support gets disabled automatically. No idea whether that is the right way to address this dependency or whether it is worth a bug report. At least I wanted to Google to find this, therefore this post. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463494 -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] default bug handling policy
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. 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. 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 -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] default bug handling policy
On Mon, 2008-05-05 at 17:09 -0400, Matthew Barnes wrote: > Distro maintainers can > always cherry-pick from trunk if they want, though I personally have > stopped doing that. I would expect the upstream developers to do that instead of multiplying the work by expecting all downstream packagers to do it independently. But of course it is not my time I am talking about here ;-} > It's kind of an engineering judgment call whether to backport. If the > patch doesn't break any freezes in effect for the stable version and is > considered not-too-risky or fixes a severe problem, then it will likely > be applied to the stable branch. Makes sense. It would help to comment in the bug report itself whether back porting was considered. If back porting was considered and the reasons against it are documented, then expect that no further time will be wasted on reopening the issue. > If a bug gets resolved as FIXED without the patch being backported and > you think it should have been, feel free to re-open the bug and ask. > Sometimes it's just an oversight. I cannot re-open bugs. Taking the bug 523541 as example, it is set to RESOLVED/FIXED although Chentill asked to have the patch applied to gnome-2-22. I'm a bit afraid that this will be forgotten. -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Subversion commit access
On Fri, 2008-05-02 at 17:32 +0200, Patrick Ohly wrote:
> I hesitated for a while ("With great power comes great responsibility",
> and I have enough responsibilities already, thanks very much), but being
> able to submit my patches to the Subversion repository directly would
> make life easier for all involved,
My account is ready. I have started to commit those patches which were
accepted in the bug tracker so far. Let me know if I missed anything or
violated some policy.
--
Bye, Patrick Ohly
--
[EMAIL PROTECTED]
http://www.estamos.de/
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] detecting new ical memory tracking
On Mon, 2008-04-21 at 11:13 +0530, Srinivasa Ragavan wrote:
> Your deal is to add a new global variable, and dlopen it to find if it
> is new e-d-s or not. Is there something new we already added in 2.22.x
> that you can find to dlopen, instead of adding a new ?
As discussed in the bug tracker, there was no such change and if if
there had been, it would have been risky to rely on unrelated changes to
detect the memfix patch.
The "ical_memfix" variable is now part of trunk and gnome-2-22. If there
are any other client library in the same situation as myself, you might
find the attached code from SyncEvolution useful. I tried both compiling
against 2.22.x directly as well as compiling against 2.12 and running
with 2.22.x (this is actually now part of the nightly testing).
--
Bye, Patrick Ohly
--
[EMAIL PROTECTED]
http://www.estamos.de/
/*
* Copyright (C) 2008 Patrick Ohly
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY, TITLE, NONINFRINGEMENT or FITNESS FOR A PARTICULAR
* PURPOSE. See the GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
* 02111-1307 USA
*/
#include "libical/icalstrdup.h"
#ifndef LIBICAL_MEMFIXES
#if defined(HAVE_CONFIG_H)
# include
#endif
#if defined(_GNU_SOURCE) && defined(HAVE_DLFCN_H)
# include
# define LIBICAL_RUNTIME_CHECK
#endif
#include
char *ical_strdup(const char *x)
{
#ifdef LIBICAL_RUNTIME_CHECK
static enum {
PATCH_UNCHECKED,
PATCH_FOUND,
PATCH_NOT_FOUND
} patch_status;
if (patch_status == PATCH_UNCHECKED) {
patch_status = dlsym(RTLD_NEXT, "ical_memfixes") != NULL ?
PATCH_FOUND : PATCH_NOT_FOUND;
}
if (patch_status == PATCH_FOUND) {
/* patch applied, not need to copy */
return (char *)x;
}
#endif
return x ? strdup(x) : NULL;
}
#endif /* !LIBICAL_MEMFIXES */
/*
* Copyright (C) 2008 Patrick Ohly
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY, TITLE, NONINFRINGEMENT or FITNESS FOR A PARTICULAR
* PURPOSE. See the GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
* 02111-1307 USA
*/
#ifndef ICALSTRDUP_H
#define ICALSTRDUP_H
#ifndef HANDLE_LIBICAL_MEMORY
# define HANDLE_LIBICAL_MEMORY 1
#endif
#include
#ifdef __cplusplus
extern "C" {
#pragma }
#endif /* __cplusplus */
#ifndef LIBICAL_MEMFIXES
/**
* The patch in http://bugzilla.gnome.org/show_bug.cgi?id=516408
* changes the ownership of strings returned by some libical and libecal
* functions: previously, the memory was owned by the library.
* After the patch the caller owns the copied string and must free it.
*
* This utility function ensures that the caller *always* owns the
* returned string. When compiled against a current Evolution Dataserver,
* the function becomes a NOP macro. Otherwise the function duplicates
* the string; it handles NULL by passing it through.
*
* When compiled against an old Evolution Dataserver, then a runtime
* check can be enabled to to determine whether the string needs to be
* duplicated. If uncertain, it always duplicates the string. If the
* check fails, then memory is leaked, which also happens when running
* programs which do not know about the patch.
*
* To enable the runtime check, compile the .c file with -D_GNU_SOURCE
* and -DHAVE_DLFCN_H. If HAVE_CONFIG_H is set, then config.h is included
* and can be set to set some of these defines. If enabled, then link with
* -ldl.
*
* ical_strdup() must be wrapped around the following functions:
* - icalreqstattype_as_string
* - icalproperty_as_ical_string
* - icalproperty_get_parameter_as_string
* - icalproperty_get_value_as_string
* - icallangbind_property_eval_string
* - icalperiodtype_as_ical_string
* - icaltime_as_ical_string
* - icalvalue_as_ical_string
* - icalcomponent_as_ical_string
* - e_cal_component_get_recurid_as_string
*
* @param xresult of one
[Evolution-hackers] time zone problem: extending API in stable branch?
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! -- Bye, Patrick Ohly -- [EMAIL PROTECTED] http://www.estamos.de/ ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
