Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
Patrick Ohly wrote: In the upstream libical certain functions return char * pointers into memory stored in ring buffers. The caller must not free those pointers. The drawback is that the life time of those strings is not predictable. In the current Evolution libical, those same functions (not renamed!) return copies of the string which the caller has to free. Code which was written using the old semantic of the calls will leak memory. Code adapted to the new semantic (like Evolution) will crash when combined with the upstream libical without the same patch. Ok, I definitely see the benefit there. This is similar to POSIX calls which now offer alternative versions (usually with "_r" appended to the name) that don't use a static buffer or a ring buffer, in order to be reentrant? If all users of the upstream libical are willing to adapt their code, then the best solution would be to simply import the Evolution patch into upstream. As much as I'd like to see that happen, I don't think it's realistic. libical is used by dozens of downstream projects, and a sudden forced API change is likely to encourage them to fork (or stay forked, if they've already done so) -- exactly the opposite of the end we are trying to achieve! If there is resistance against that, then we could provide two versions of each of these API calls: one with the old name and old behavior and one with the new behavior and a name suffix. That seems more realistic. The alternative might be to offer a global flag that tells libical to behave one way or the other? (I think something like that was suggested at some point.) While I definitely think the new method of memory allocation makes far more sense (we'll definitely use it in Citadel, as all of our code is multithreaded) -- expecting the entire community to perform a "flag day" API change in lockstep is likely to cause confusion and delay. If we pursued either the alternate function names or the global flag, is there likely to be any pushback from the Evolution team? -- Art ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
Chenthill wrote: On Sat, 2008-09-06 at 11:02 +0200, Patrick Ohly wrote: Hello! http://sourceforge.net/projects/freeassociation/ has released 0.32 of libical on 2008-09-01. The KDE-PIM team has switched to that code for KDE 4.2. On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote: On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: I discovered last week that there is an attempt to resurrect libical from non-maintainership, merge all of the patches from various forks, and start making sane releases again[1]. Are the evolution team as whole interested in merging their changes to libical upstream and depending on it to be installed when a release is made with all of the relevant changes? libical isn't exactly a small library, and statically linking it is a waste of memory for everyone. I vaguely recall the biggest diff being timezone handling. Not sure about that. They have merged the "system timezone database conversion" code, if that's what you mean. Unfortunately they missed the recent bug fixes required for that code to handle the upcoming summer->winter time transition. We really should have been more active with keeping them informed about Evolution-libical changes. I have alerted them and the KDE-PIM team of the problem. However, they haven't included the modified memory handling. Considering that this breaks the user space API merging it might be a hard sell. I'll happily start working on extracting the changes to EDS and pushing them into the new libical repository, if the Evolution team as a whole agrees that the fork of libical will be dropped. +1 +1 from my side too. We were discussing about this at http://bugzilla.gnome.org/show_bug.cgi?id=541209 and wanted the changes to be merged upstream. We wanted to get this done for 2.26. thanks, Chenthill In what way does it break the userspace API? Is it possible that the API could be extended in such a way that memory handling depends upon how it's called? We would *really* like to get everyone merged and re-unify this library once and for all. Everyone would benefit. -- Art ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Mon, 2008-09-08 at 12:16 -0400, IGnatius T Foobar wrote: > In what way does it break the userspace API? Is it possible that the > API could be extended in such a way that memory handling depends upon > how it's called? Chenthill already provided the relevant links: http://bugzilla.gnome.org/show_bug.cgi?id=516408 http://bugzilla.gnome.org/show_bug.cgi?id=528986 For the sake of discussion let me summarize how the API has changed, then suggest ways how that could be dealt with. In the upstream libical certain functions return char * pointers into memory stored in ring buffers. The caller must not free those pointers. The drawback is that the life time of those strings is not predictable. In the current Evolution libical, those same functions (not renamed!) return copies of the string which the caller has to free. Code which was written using the old semantic of the calls will leak memory. Code adapted to the new semantic (like Evolution) will crash when combined with the upstream libical without the same patch. There are defines in the Evolution libical header which can be used to detect what the memory handling is, so code can be written so that it works with both the old and the new semantic. SyncEvolution goes one step further and also does a runtime check, so the same binary works with both an old and a new Evolution release. If all users of the upstream libical are willing to adapt their code, then the best solution would be to simply import the Evolution patch into upstream. If there is resistance against that, then we could provide two versions of each of these API calls: one with the old name and old behavior and one with the new behavior and a name suffix. Evolution then has to be patched to use the new calls, which can be done either with a global search/replace or via defines (ugly!). SyncEvolution would work fine without code changes, it'll simply fall back to not freeing the strings. -- 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] Removing libical fork, moving to new upstream?
On Mon, 2008-09-08 at 12:16 -0400, IGnatius T Foobar wrote: > Chenthill wrote: > > On Sat, 2008-09-06 at 11:02 +0200, Patrick Ohly wrote: > > > > > Hello! > > > > > > http://sourceforge.net/projects/freeassociation/ has released 0.32 of > > > libical on 2008-09-01. The KDE-PIM team has switched to that code for > > > KDE 4.2. > > > > > > On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote: > > > > > > > On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: > > > > > > > > > I discovered last week that there is an attempt to resurrect libical > > > > > from non-maintainership, merge all of the patches from various forks, > > > > > and start making sane releases again[1]. Are the evolution team as > > > > > whole interested in merging their changes to libical upstream and > > > > > depending on it to be installed when a release is made with all of the > > > > > relevant changes? libical isn't exactly a small library, and > > > > > statically > > > > > linking it is a waste of memory for everyone. > > > > > > > > > I vaguely recall the biggest diff being timezone handling. > > > > > > > Not sure about that. They have merged the "system timezone database > > > conversion" code, if that's what you mean. Unfortunately they missed the > > > recent bug fixes required for that code to handle the upcoming > > > summer->winter time transition. We really should have been more active > > > with keeping them informed about Evolution-libical changes. I have > > > alerted them and the KDE-PIM team of the problem. > > > > > > However, they haven't included the modified memory handling. Considering > > > that this breaks the user space API merging it might be a hard sell. > > > > > > > > > > > I'll happily start working on extracting the changes to EDS and > > > > > pushing > > > > > them into the new libical repository, if the Evolution team as a whole > > > > > agrees that the fork of libical will be dropped. > > > > > > > > +1 > > > > > +1 from my side too. We were discussing about this at > > http://bugzilla.gnome.org/show_bug.cgi?id=541209 and wanted the changes > > to be merged upstream. We wanted to get this done for 2.26. > > > > thanks, Chenthill > In what way does it break the userspace API? Is it possible that the > API could be extended in such a way that memory handling depends upon > how it's called? All the information/discussion about this is available at, http://bugzilla.gnome.org/show_bug.cgi?id=516408 and http://bugzilla.gnome.org/show_bug.cgi?id=528986 > > We would *really* like to get everyone merged and re-unify this > library once and for all. Everyone would benefit. We provide our support too to get this done!! thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] lost password
Am Sonntag, den 07.09.2008, 17:09 -0500 schrieb Isaac Karjala: > I'm not sure if maybe this should go to the more general evolution > list The mailing list description clearly says "Discussion about Evolution code", so the general evolution list would be much more appropriate, yes. > but I lost the password to my gmail. The correct password is stored > in Evolution for retrieving mail, how ever an incorrect password is > stored for sending mail. This is vague. Which evolution version is this, which distro, does it use gnome-keyring? > The password is normally generated and stored in keepassx What is that?! > , but apperently I accidentially changed the stored password. it's > 100 characters of complete jibberish, the answer to the security > question is also 100 characters of complete jibberish and there is no > "parent" email to reset the password through. Great. Get a new gmail account and don't use jibberish again. andre -- mailto:[EMAIL PROTECTED] | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Unauthorised licence change to e-spinner.[ch]
On Sat, 2008-09-06 at 10:12 -0400, Michael Meeks wrote: > Hi Christian, > > On Fri, 2008-09-05 at 15:16 +0200, Christian Persch wrote: > > Both of these claims are false. > > Wow - that is bad. Reverting immediately, sorry [ and thanks > for > picking this up so quickly ! ]. > > > e-spinner.[ch] is derived from ephy-spinner.[ch] from Epiphany, and > I > > hold the copyright on much of the code in it. It is licensed under > the > > Sure; and indeed it clearly had your copyright header at the > top; Argh > - Sankar - why are there two headers at the top of that file ? Ah. this is my mistake. I prepended the new license to the files. Opened the files in gvim tabs and accidentally closed multiple tabs without pruning the header. Sorry. -- Sankar ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
On Sat, 2008-09-06 at 11:02 +0200, Patrick Ohly wrote: > Hello! > > http://sourceforge.net/projects/freeassociation/ has released 0.32 of > libical on 2008-09-01. The KDE-PIM team has switched to that code for > KDE 4.2. > > On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote: > > On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: > > > I discovered last week that there is an attempt to resurrect libical > > > from non-maintainership, merge all of the patches from various forks, > > > and start making sane releases again[1]. Are the evolution team as > > > whole interested in merging their changes to libical upstream and > > > depending on it to be installed when a release is made with all of the > > > relevant changes? libical isn't exactly a small library, and statically > > > linking it is a waste of memory for everyone. > > > > I vaguely recall the biggest diff being timezone handling. > > Not sure about that. They have merged the "system timezone database > conversion" code, if that's what you mean. Unfortunately they missed the > recent bug fixes required for that code to handle the upcoming > summer->winter time transition. We really should have been more active > with keeping them informed about Evolution-libical changes. I have > alerted them and the KDE-PIM team of the problem. > > However, they haven't included the modified memory handling. Considering > that this breaks the user space API merging it might be a hard sell. > > > > I'll happily start working on extracting the changes to EDS and pushing > > > them into the new libical repository, if the Evolution team as a whole > > > agrees that the fork of libical will be dropped. > > +1 +1 from my side too. We were discussing about this at http://bugzilla.gnome.org/show_bug.cgi?id=541209 and wanted the changes to be merged upstream. We wanted to get this done for 2.26. thanks, Chenthill. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
