Re: [Evolution-hackers] Does evolution source still contains GPLv2 code?
Srini, So in current state, Evolution is still combined by GPL and LGPLv2/LGPLv3 code, right? The target is LGPLv3/LGPLv3 only, isn't it? Thanks, Harry On Fri, 2008-10-17 at 08:42 +0530, Srinivasa Ragavan wrote: Jeff, The COPYING (GPLv2) old license, COPYING.LGPLv2 COPYING.LGPLv3 are present in the tarballs. Evolution still has some files left not moved to LGPLv2/LGPLv3. NEWs files might have been saying that some license changes code went in. Sorry for the confusion. -Srini. On Fri, 2008-10-17 at 11:01 +0800, Jeff Cai wrote: Hi From the 2.24 tar package and svn trunk, I can still find the COPYING file which says that it is GNU GENERAL PUBLIC LICENSE v2. But from NEWS, it says Evolution source code license changed to LGPLv2 LGPLV3 (Sankar P). Sankar, I'm curious about whether evolution still contains GPLv2 code. Jeff ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers -- [EMAIL PROTECTED] Solaris Desktop Group, Sun Microsystems Tel: +86-10-82618200 ext. 82870/ +86-10-62673870 Fax: +86-10-62780969 ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Too many open files for folders.db
On Mon, 2008-10-13 at 10:05 +0200, Andre Klapper wrote: Am Montag, den 13.10.2008, 12:50 +0800 schrieb Harry Lu: When will you plan to release 2.24.1? Like always in the last two years: According to the schedule at http://live.gnome.org/TwoPointTwentyfive OK. So we have to make an internal patch for 2.24.0 before 2.24.1 is released. Thanks, Harry andre -- [EMAIL PROTECTED] Solaris Desktop Group, Sun Microsystems Tel: +86-10-82618200 ext. 82870/ +86-10-62673870 Fax: +86-10-62780969 ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Getting rid of shipped libdb
Evolution in OpenSolaris is still using the bundled BDB since Sun has a license with Oracle that we cannot ship BDB libs/headers in OpenSolaris for now. I do hope this could be changed. But for now, we'd like to still have an option to use the bundled one. Thanks, Harry On Mon, 2008-10-06 at 14:51 -0400, Matthew Barnes wrote: On Mon, 2008-10-06 at 22:15 +0530, Srinivasa Ragavan wrote: IIRC, I had replied to Ross on a similar query, start GNOME 2.24. Still OpenSUSE ships with in-built libdb. I'm not aware of any other distro. JPR, who use to maintain Evolution few years back, gave me the notes on why it was decided to go this way (forking libdb). So if we have answers for all those points, I'm fine for that. We don't want to break anything thatz fine otherwise. I'm not tracking libdb at all, if you have the answers, then lets recalculate and plan for it in 2.26. Just as a data point, E-D-S on Fedora links to the system libdb. My understanding is it wasn't so much a fork as a freeze, since I guess libdb has had trouble maintaining ABI or API stability in the past. I don't think any significant changes have been made to our bundled libdb other than build-related and maybe security-related stuff. I guess the real question is whether libdb is stable these days. I don't recall any issues with it over the past year since switching over to the system library. Would be great to drop both it and our bundled libical for 2.26. Matt ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers -- [EMAIL PROTECTED] Solaris Desktop Group, Sun Microsystems Tel: +86-10-82618200 ext. 82870/ +86-10-62673870 Fax: +86-10-62780969 ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Request for improved svn commit messages
When we began to make Evolution patches 5 years ago, we were required to make the commit changlog the same as the one in ChangeLog by Evolution maintainers. So we have been doing copypaste for all the time. Maybe this has been changed. But I still prefer this old way. This makes the viewcvs from http://svn.gnome.org more readable. And as we don't need to write down a short log, this might take less time :) Just my 2 cents. Harry Srinivasa Ragavan ??: Oh, I remember a thread on d-d-l where there was discussion on two ChangeLogs (one part of tree and other part of svn logs). Btw, I'm one of those who use those short logs for svn commits and I know a few people who copy ChangeLogs to svn commit logs. In anycase, I really dont know/see what is the benefit of this over the short messages. Many times with patches and review being on bugzilla, atleast I find easy to see what broke where with just the bug number part of commit logs over viewcvs. -Srini. On Fri, 2007-10-05 at 09:47 +0200, Frederic Crozat wrote: Hi everyone, I'd like to suggest to Evolution hackers, whenever it is possible for them, to try to improve their svn commit messages. Some of you are currently using a very short commit message (something like fix for bug#xxx), which make reading svn commit extremely difficult without having to go each time on bugzilla to see what was the fix really for. Moreover, it also adds complexity when you are checking a file history and bump into such commits. May I suggest you use either the same ChangeLog entry you wrote in the various changelog file (so it is even faster, just use copy/paste :) or even a stripped version of it (it used to be extremely useful for CVS to see which files were changed at the same time, but it is no longer required with svn atomic commit) ? Thanks you in advance. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] URL colour in Mail
From gtkhtml/src/htmlcolorset.c's html_colorset_set_style(), it seems should be link_color instead of link-color. Calum, What API could we use to get the gtk theme setings for URL colors? Thanks, Harry On Tue, 2006-08-15 at 12:38 +0100, Calum Benson wrote: On Sat, 2006-08-12 at 10:01 +0200, Igor Jagec wrote: Hi there! Is it possible to change URL colour? It is set to #FF by default, and I want it to be #006600. I played a bit with gconf editor and my ~/.evolution/mail/config/gtkrc-mail-fonts and what ever I did, It didn't help. There's a gtk theme setting for URL colours, but whether Evo respects it or not I don't know. I guess you'd need to add something like: GtkHTML::link-color = #006600 to your ~/.gtkrc-2.0 file to try it (create the file if it doesn't exist). Cheeri, Calum. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] CAL_STATIC_CAPABILITY_* documentation?
Jules, I will try to explain some of these based on my understanding when developing evolution-jescs. See my comments below. Harry Jules Colding 写道: On Tue, 2006-05-09 at 14:32 +0200, Jules Colding wrote: On Tue, 2006-05-09 at 14:30 +0200, Jules Colding wrote: * CAL_STATIC_CAPABILITY_NO_AUDIO_ALARMS No audio alarms. Again, how is this related to the backend? Hmm... cut'n paste from a HTML page. These horizontal lines wasn't intended to be in the mail. Here is a better list from current CVS HEAD: * CAL_STATIC_CAPABILITY_NO_ALARM_REPEAT No repeating alarms. How is this related to the backend? Isn't it the Evolution front-end that do the alarm stuff? The backend doesn't support storing repeat alarms. So this feature will disabled from the GUI. * CAL_STATIC_CAPABILITY_NO_AUDIO_ALARMS No audio alarms. Again, how is this related to the backend? The backend doesn't support storing audio alarms. * CAL_STATIC_CAPABILITY_NO_DISPLAY_ALARMS No visual alarms. Again, how is this related to the backend? Similar as above. * CAL_STATIC_CAPABILITY_NO_EMAIL_ALARMS No email alarms. Again, how is this related to the backend? Similar as above. * CAL_STATIC_CAPABILITY_NO_PROCEDURE_ALARMS What is this? The backend doesn't support storing alarms which will call other programs. * CAL_STATIC_CAPABILITY_NO_TASK_ASSIGNMENT The backend can not assign tasks to individual entities. * CAL_STATIC_CAPABILITY_NO_THISANDFUTURE The backend can not do a search for events/tasks that are starting at any time from and including now. When modifying a recurrence event, the backend doesn't support modifying "This and Future instances". * CAL_STATIC_CAPABILITY_NO_THISANDPRIOR The backend can not do a search for events/tasks that are starting at any time before but including now. Similar as above. * CAL_STATIC_CAPABILITY_NO_TRANSPARENCY What is this? The backend doesn't support the event's transparency property. This feature will be disabled in the GUI. * CAL_STATIC_CAPABILITY_ONE_ALARM_ONLY Only one alarm can be active at any one time. Again, how is this related to the backend? Isn't it the Evolution front-end that do the alarm stuff? The backend only support storing one alarm. * CAL_STATIC_CAPABILITY_ORGANIZER_MUST_ATTEND The organizer is a required participant in any meeting. * CAL_STATIC_CAPABILITY_ORGANIZER_NOT_EMAIL_ADDRESS What is this? The organizer field of a meeting is not a e-mail address. It might be a user id, for example. * CAL_STATIC_CAPABILITY_REMOVE_ALARMS Alarms can be removed. * CAL_STATIC_CAPABILITY_SAVE_SCHEDULES What is this? Don't send meeting invitation or updating info from GUI. The backend will do this by itself. * CAL_STATIC_CAPABILITY_NO_CONV_TO_ASSIGN_TASK What is this? Convert from what? * CAL_STATIC_CAPABILITY_NO_CONV_TO_RECUR What is this? Convert from what? A normal event can not be converted to a recurrence event.(???) * CAL_STATIC_CAPABILITY_NO_GEN_OPTIONS What is this? * CAL_STATIC_CAPABILITY_REQ_SEND_OPTIONS What is this? * CAL_STATIC_CAPABILITY_RECURRENCES_NO_MASTER What is this? * CAL_STATIC_CAPABILITY_ORGANIZER_MUST_ACCEPT The organizer must accept the meeting. * CAL_STATIC_CAPABILITY_DELEGATE_SUPPORTED Support for delegation * CAL_STATIC_CAPABILITY_NO_ORGANIZER Support for meeting without any organizer. * CAL_STATIC_CAPABILITY_DELEGATE_TO_MANY Can delegate to more than one at the same time. * CAL_STATIC_CAPABILITY_HAS_UNACCEPTED_MEETING What is this? Thanks, jules ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] gnome-session's Make CRITICAL warning crash
Hi, Recently we find there are quite a lot of crashes for Evolution 2.5 running on gnome 2.13. Now I just find the reason: http://mail.gnome.org/archives/desktop-devel-list/2005-November/msg6.html and http://cvs.gnome.org/viewcvs/gnome-session/gnome-session/main.c?r1=1.70r2=1.71 So now all critical warnings turn to crashes. That is why Jeff Cai found 3 crashes when starting Evolution recently. I am not sure whether all of us know about this, so just FYI. I guess there might be more crashes. Sorry I didn't noticed this earlier since I was running/debuging Evolution 2.5 on gnome 2.12. Harry ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
