Re: [Evolution-hackers] ANNOUNCE: Evolution 2.10.0, Evolution-Data-Server 1.10.0, GtkHTML 3.14.0 and Evolution Exchange 2.10.0
On Tue, 2007-03-13 at 23:04 -0400, Claudio Saavedra wrote: El Tue, 13-03-2007 a las 13:08 +0530, Harish Krishnaswamy escribió: Hi All, The Evolution Team is pleased to announce the release of * Evolution 2.10.0 * Evolution-Data-Server 1.10.0 I'm sorry to spoil the fun, but you guys left g_print (\n\a Header string finally is ** \n%s\n, header_spec-str); in e-d-s, camel/providers/imap/camel-imap-folder.c:2367, which is pretty annoying, specially because of the '\a' (i.e., a beep every time a new mail arrives or a mail is moved to another folder). This appeared with a patch for this bug[1], I tried to warn but it seems it got unnoticed. Hope it's not too late to fix this. Claudio [1] http://bugzilla.gnome.org/show_bug.cgi?id=400841 You are right - this *is* an annoyance and should have been pruned before the release, but it is a tad late - the tarballs are already out. I also feel that this g_print statement should be conditional on the debug flags turned on - and should not add noise to normal usage. The use of \a looks superfluous too. Varadhan/Sankar : Can you wrap the statement within a suitable DEBUG level check and get the change committed asap. TIA. Thanks, Harish -- Novell, Inc. Software for the Open Enterprise™ http://www.novell.com ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Fix the build with iconv?
On Tue, 2007-03-13 at 00:50 -0600, Elijah Newren wrote: Hi, I know they aren't the most critical patches in the world, but is there anyway I could convince someone to fix the build logic for iconv in evolution and evolution-data-server? The patches already exist at http://bugzilla.gnome.org/show_bug.cgi?id=388788 and http://bugzilla.gnome.org/show_bug.cgi?id=388789. It's tiring to have to manually patch lots of tarball and svn builds... On a quick evaluation by eye, the patch looks fine. I will test and update the bug after running it through my build when back in my office. (Also, I think the '#include iconv.h' statement can be safely removed in evolution:configure.in just like in evolution-data-server:configure.in. Perhaps just an oversight). Thanks, -Harish -- Novell, Inc. Software for the Open Enterprise™ http://www.novell.com ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [UPDATED] Re: Updating our list of GNOME contributors
Hi, This is a list (I hope I have not overlooked any) from the Evolution/EDS/GtkHTML/Evolution-Exchange modules. Harish Krishnaswamy Srinivasa Ragavan Chenthill Palanisamy Sankarasivasubramaniam Pasupathilingam Veerapuram Varadhan Matthew Barnes Andre Klapper Chris Heath Hiroyuki Ikezoe Parthasarathi Susarla Shreyas Srinivasan Sarfraaz Ahmed Sushma Rai Devashish Sharma Jules Colding Tor Lillqvist Rajeev Ramanathan Simon Zheng Philip Van Hoof Mengjie Yu Wang Xin Irene Huang Harry Lu Vivek Jain Sivaiah Nallagatla David Malcolm James Bowes Arunprakash Shakti Sen Praveen Kumar Johnny Jacob Evo Hackers : Friends, any omission in the above list is inadvertent - mea culpa. Please let me know, so this can be corrected. Thanks, Harish -- Pure in heart, like uncut jade, he cleared the muddy water by leaving it alone. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Where to put UI items for templates (Bug #127529)
Hi Andre,
Thank you for your concern - but I believe I *did* give Matthew some
feedback on the patch over IRC (see Chat transcript [1] below) a couple
of weeks ago - about a possible ABI violation and a possible way to
avoid it and he had agreed to rework that bit.
We do love those who love to hack on Evo :-).
Cheers,
Harish
[1] Log - #evolution - 29 Jan 2007
(20:19:07) xfceslacker: harish is there something wrong with the email I
sent?(http://mail.gnome.org/archives/evolution-hackers/2007-January/msg00053.html)
(20:20:23) harish: xfceslacker: none
(20:21:42) xfceslacker: I waited nearly a month for a response on my
last email.
(http://mail.gnome.org/archives/evolution-hackers/2007-January/msg0.html)
(20:22:05) harish: except that on a very quick glance at the patch - I
feel that inserting a new element into an enum set violates the ABI
(20:22:25) xfceslacker: ok
(20:22:30) xfceslacker: thanks
(20:22:31) xfceslacker: :)
(20:23:16) harish: xfceslacker: I do not primarily hack on the mailer
component - I have poked those who do to have a look at it and provide a
response
snip
(20:23:46) harish: xfceslacker: sorry - the team is swamped by quite a
bit of work..thanks for your patience
(20:23:53) xfceslacker: ok.
(20:24:01) xfceslacker: Anything else you see wrong with the patch?
(20:25:36) xfceslacker: I know my em_utils_load_template function is
ugly.
(20:25:42) harish: xfceslacker: I am not the best person to make the
call - but I'd prefer if you could append the new value so it extends
the current set.
(20:26:00) xfceslacker: ok
(20:27:06) xfceslacker: You're talking about _mail_component_folder_t
right?
(20:27:35) xfceslacker: or enum {
(20:27:35) xfceslacker: SEND,
(20:27:35) xfceslacker: SAVE_DRAFT,
(20:27:35) xfceslacker: + SAVE_TEMPLATE,
(20:27:35) xfceslacker: LAST_SIGNAL
(20:27:35) xfceslacker: };
(20:29:04) xfceslacker: or both?
(20:30:19) harish: _e_account_item_t on libedataserver
(20:30:27) xfceslacker: oh
(20:30:29) xfceslacker: sorry
(20:31:14) harish: Evolution is not a devel library...EDS is more
religious about changes
On Sun, 2007-02-11 at 02:30 +0100, Andre Klapper wrote:
may a developer answer this, or shall matthew ask for a third time on
this list, after waiting for six weeks for some feedback?
andre
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] ANNOUNCE: Evolution 2.8.3 and Evolution-Data-Server 1.8.3 Release (with GtkHTML 3.12.3 and Evolution-Exchange-2.8.3)
Hi All, The Evolution Team is pleased to announce the release of Evolution 2.8.3. You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.12/gtkhtml-3.12.3.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.8/evolution-data-server-1.8.3.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.8/evolution-2.8.3.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.8/evolution-exchange-2.8.3.tar.bz2 Upgrade Notes : Evolution 2.8.3 is a stable release series of 2.8 development. Release Notes: Evolution 2.8.3 --- Updated Translations: Daniel Nylander (sv), Stéphane Raimbault (fr), Nickolay V. Shmyrev (marking strings as translatable), Djihed Afifi (ar), Francisco Javier F. Serrador (es), Hendrik Richter (de), Jakub Friedl, Priit Laes (et), Changwoo (ko), Laurent Dhima (sq). Contributions : Simon Zheng (352108), Nickolay V. Shmyrev (340165), Matthew Barnes (357970, 383027, 377511), Chris Halls (372528), Wang Xin (389966, 389961, 380064), Raghavendran (343943), Kjartan Maraas (330969). Harish Krishnaswamy (208959 - bnc, 377626) GtkHTML-3.12.3 -- Updated Translations: Ilkka Tuohela (fi) Contributors: Gilles Dartiguelongue (331813), John N. Laliberte (373092), Chris Heath (362194, 338884, 360393), Michael Monroe (358641). Evolution-Data-Server 1.8.3 -- Updated Translations: Stéphane Raimbault (fr), [EMAIL PROTECTED] (fr), Djihed Afifi (ar), Gabor Kelemen (hu), Ilkka Tuohela (fi), David Lodge (en_GB), Clytie Siddall (vi), Alexander Shopov (bg), Laurent Dhima (sq), Djihed Afifi (ar), Josep Puigdemont i Casamajó (ca), Francisco Javier F. Serrador (es), Priit Laes (et), Jovan Naumovski (mk), Ankit Patel (gu). Contributors : Andreas Henriksson (Fix order of memset arguments in libdb hash) Evolution Exchange 2.8.3 - Updated Translations: Laurent Dhima (sq), Djihed Afifi (ar). Contributions: Matthew Barnes (357660). Reporting Bugs If you have problems with 2.8.3, please take the time to submit the bug using Bug Buddy or at http://bugzilla.gnome.org. Try to fill in as much detail as you can regarding the circumstances that lead to the problem. If you have a feature request, you can also file that at http://bugzilla.gnome.org/ don't be discouraged if you don't hear from us right away, we get hundreds of feature requests a year. You can also check if your bug has been reported before by using the search functionality of Bugzilla. More information is available at the project website http://www.gnome.org/projects/evolution and the project wiki : http://go-evolution.org/ Known Issues : GW users need to apply the following patch onto evolution/plugins/groupwise-features/junk-settings.c to fix a missing translation header. Non-GW users are not affected by this. Index: junk-settings.c === --- junk-settings.c (revision 33162) +++ junk-settings.c (working copy) @@ -23,6 +23,7 @@ # include config.h #endif #include glade/glade.h +#include glib/gi18n.h #include junk-settings.h #include glib/gmain.h #include gtk/gtktreemodel.h Index: ChangeLog === --- ChangeLog (revision 33162) +++ ChangeLog (working copy) @@ -1,3 +1,7 @@ +2007-01-29 Harish Krishnaswamy [EMAIL PROTECTED] + + * junk-settings.c: Include glib/gi18n.h. + 2007-01-29 Kjartan Maraas [EMAIL PROTECTED] * send-options.c: (get_cnc): NULL check to avoid a crash Thanks, Harish Krishnaswamy ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Evolution] tips and tricks and questions and answers.
Andre : Thanks a lot for sharing these invaluable nuggets. You rock as always :-). I have added them to the project wiki at http://www.go-evolution.org/FAQ. I appeal to all contributors to use this page for consolidating their FAQ inputs and help in making this the de facto reference point for Evolution users regarding such queries. Thanks, Harish On Wed, 2007-01-03 at 13:44 +0100, Andre Klapper wrote: hi folks, looks like i'm currently a bit disappointed by the company that still provides the software for my open enterprise(tm) (and no, it is not a problem of time). time to free some of the few written bits of knowledgework that would otherwise rot on my harddisk. attached you will find a file that includes a collection of evo related questions that have been asked more often or that have been very interesting, and of course their more or less complete answers. no guarantee for anything included, but a copy, paste, redistribute, change as you like licensee. i sometimes used this to answer mailing lists user questions, hope it's useful to somebody. welp, so long crew here, andre plain text document attachment (evolution-FAQE), tips and tricks and questions and answers. = Mail = Questions regarding the mailer and composer, for example junk mail, encryption or spell checking. Please note that desktop integration issues (for example setting the preferred browser and launching evolution from a browser) are part of the interoperability section. == General == === I cannot see some emails, but they must be there. === Some possible reasons: * You use filters on incoming (or outgoing) messages that move your messages automatically to another destination. If you have enabled junk filtering, also take a look into the junk folder. * Check your search view in the search bar right above the message list, perhaps you have any value in it? * Just to be sure: Click Edit | Show Hidden Messages. * Take a look into Evolution's Junk folder. Messages that are marked as Junk disappear from the original folder and are only displayed in the Junk folder. * Check your default folder under Edit | Preferences | Email Accounts | Edit | Defaults. Perhaps it is set to some other folder then the folder you thought of. If this specially refers to an IMAP account and you upgraded Evolution to version 2.4, and you are using a Cyrus IMAP server, then try to change your account settings to Show subscribed mails only. Then use Folder | Subscriptions to subscribe to your Inbox and any other folder. You might need to restart Evolution in between. This bug is fixed was Evolution 2.4.2.1 and later. === How i can update/refresh Search folders (formerly called vFolders)? === Refreshing a Search folder by a command is not possible (see http://bugzilla.gnome.org/show_bug.cgi?id=257582). However, you should get an updated view by going to another folder and then going back to your Search folder. === Why do my mail filters not work? === Generally, be aware of the fact that the order of your filters is important. If your very first filter has a Stop processing rule, all the other filters will be ignored by the emails that match to this first filter rule. If you want your filters to apply automatically and you are using an IMAP account, make sure you have enabled Apply filters to new messages in INBOX on this server under Edit | Preferences | Email Accounts | Edit | Receiving Options | Options. Also, filters depend on the new flag which will be set only when a particular mail is fetched from server for the first time. If any other mail client is used to check mail before Evolution, Evolution's filters may not work. === Why do I get the message No provider available for protocol email.? === This can happen if you have just installed Evolution on a new machine and have copied the file named filters.xml, so your filter rules are suffering from a version mismatch with Evolution. Since the filters refer to accounts directly, and accounts all have a unique ID number, you get the above error if it cannot find the account anymore, so you either have not copied the account settings or they have been changed in the meantime. To fix it, edit your filters and re-select the folder for each Copy/Move filter. === How can I get informed of new mail arriving? === Since Evolution 2.2, a panel notification applet via D-BUS exists. Evolution itself is only able to play a sound file or to beep. Go to Edit | Preferences | Mail Preferences | General | New Mail Notification. Note that esound must be running to be able to hear your sound file. === Why does new junk mail automatically get marked as read? === Good question - one can easily miss new messages which have been incorrectly marked as junk. Workaround: Both for trash and the junk folder, one can enable displaying the number of ALL messages in the preview pane (in brackets
Re: [Evolution-hackers] evolution-data-server/calendar/libical and SVN
On Wed, 2007-01-03 at 00:29 +0100, Andre Klapper wrote: hejhej, Am Dienstag, den 02.01.2007, 14:46 + schrieb Ross Burton: Those problems might not be a real issue, as nobody really hacks on libical. correct, Although not as active as the rest of the module, there have been quite a few critical bug fixes made on libical every major release. I will look into the svn-howtos to see if it is possible to get a writable checkout of libical or at least make it less of a road hump to developers. and this also means that nobody updates the timezone data think there's currently wrong data at least for iran, brazil and australia, iirc). I have opened http://bugzilla.gnome.org/show_bug.cgi?id=392170 to track and fix the discrepancies in timezone information. quote who=Mark McLoughlin The libical module will be checked out using anonymous SVN, meaning evo hackers wouldn't be able to directly hack on that checkout - When you branch, the branched evolution-data-server will still refer to libical trunk. You'd need to modify the svn:externals property to refer to the libical branch Mark : Thanks. I am already working on the problem. I am holding the option of adding the 'svn:external's until tonight to explore alternatives (making libical a snapshot copy like libdb as we do not make separate package releases of libical anyway). Cheers and a Happy New Year to All, Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] RFC: Evolution's library requirements
Hi fellow hackers, With reference to Bug 380534 on clarifying Evolution's library requirements, I am putting down my thoughts and recommendations here and will be proposing this in the weekly evolution meeting (#evolution-meet on irc.gimp.org at 1000 UTC 6 Dec 2006) tomorrow. Comments/questions welcome, as always. I see two aspects of the problem described in the bug that merit two separate approaches : a. Inbound Dependencies - The libraries that Evolution/EDS/Evolution Exchange depend on. b. Outbound Dependencies - Dependencies that EDS libraries provides to other applications that are based on or integrated with Evolution/EDS. On (a) Inbound Dependencies, I suggest that on upstream CVS, Evolution should depend on the most recent stable versions of the libraries available in the corresponding GNOME release (Evolution 2.9.x/2.8.x on GNOME 2.16, 2.6.x on GNOME 2.14). This is similar but not exactly the same as what Matthew has outlined in Bug 380534. I agree that the configure scripts need to hard-enforce these dependencies while building the packages. I feel it is important that we move away from i) the use of deprecated APIs from various GNOME libraries to the improved, maintained versions. ii) Evolution specific widgets/thread/mutex/data structures implementation that are now available in generic GNOME libraries. This is possible now in some cases (EList-GList, EThread-GThread, EMutex-GMutex?) but not all (ETable, ETree). This ensures we take advantage of the newer capabilities available and make it easier for contributors to continue adding value to our project. However, it is also true that a very large number of our users (enterprise, organizations, ISVs) still live on older GNOME Desktop environments (Gtk = 2.6), willing to upgrade specific applications (Evo) but not their entire Desktop every six months. I think this would be the case in future too that the 'majority' of the installed base stays a step or two behind the Bleeding-Edge/State-Of-The-Art Latest releases. If-defs and conditional compilations with significant addition to the maintenance complexity are a necessity to support such users who need to move to newer versions without overhauling their desktop. It is fair IMHO, however, for individual distributions to handle them according to their needs, rather than the upstream maintaining a super-set of everybody's constraints. I wish to propose an exception to the above if and only if when an inbound dependency is likely to cause a change to an outbound dependency as discussed in (b). On (b) Outbound dependencies, and this is specially relevant to bugs like 373117, where we would like to preserve the binary compatibility of outbound libraries (libebook and libecal, in particular, which are the heavily used ones and as well as various Camel/Calendar/Addressbook providers built on EDS) and take care that any changes do not trigger massive upgrade overheads for those who consume our libraries. Evolution has learnt this the hard way, erred on some and handled them with additional code overheads in other cases. Here, I would recommend that we extend the APIs rather than modify/delete them and mark the deprecated functions (to be discarded after a specified and sufficient timeline) so that they do not get used in newer code. These libraries need to support older environments (and possibly deprecated library calls) in a broader sense than in case (a). In these cases, some conditional compilation and #ifdef hacks will have to be supported on the upstream as well. I wish I could specify hard numbers on minimum dependencies for various libraries here. ( Is 'Libraries corresponding to GNOME 2.14' a good one ?) but I do not have the answers yet. If you have a POV that you feel must be considered, please do let me know or join us in the meeting tomorrow. (There has also been a separate discussion on the need to get Evolution's Camel library versioned and promise a compatible interface for foreseeable future and Varadhan is already working on this with other mail hackers). I also feel the library dependencies are best conveyed by the build tools and our decisions should be reflected in and enforced by our pkg-config and configure scripts. (remember the recurring NSS/NSPR , LDAP/NTLM issues ?) The Answer : Patch and Testing love [hint...hint ;-)] Thanks, Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [ANNOUNCE} Evolution 2.9.3 and Evolution-Data-Server 1.9.3 released (with GtkHTML 3.12.3 and Evolution-Exchange-2.9.3)
Hi All, The Evolution Team is pleased to announce the release of Evolution 2.9.3 You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.13/gtkhtml-3.13.3.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.9/evolution-data-server-1.9.3.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.9/evolution-2.9.3.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.9/evolution-exchange-2.9.3.tar.bz2 Upgrade Notes : Evolution 2.9.x is the unstable series of 2.10 development. What is New ? = Evolution : Updated Translations: Ivar Smolin (et), Jakub Friedl (cs), Karsten Bräckelmann (nb), Francisco Javier F. Serrador (es), Christophe Merlet (fr) Contributors : Francisco Javier F. Serrador (gnome-doc-tools integration, 358249) Harish Krishnaswamy (evolution.desktop install fixes, GW proxy pruning, memory leak fixes, 381642 (b.g.0), bug #208959 at bugzilla.novell.com) Nickolay V. Shmyrev (support for commandline uri in tasks), Daniel Gryniewicz (349966), Srinivasa Ragavan (Fix DoS by large emails) Sankar, Chris Halls (372528), Wang Xin (380064), Carlos Garcia (367183), Chenthill (208318 - b.n.c), Parthasarathi Susarla (348679). Matthew Barnes (357970). Evolution-Data-Server: Updated Translations: Alexander Shopov (bg), Josep Puigdemont i Casamajó (ca), Ivar Smolin (et). Bug fixes : 330157, 350880, 328836, 348123, 365000, 353924. 174655, 222605, 219729, 208318, 207960. (bugzilla.novell.com) plus miscellaneous code clean-ups and memory leak fixes. Contributors : Harish Krishnaswamy, Sankar, Srinivasa Ragavan, Chenthill, Claudio Saavedra, Ross Burton, Matthew Barnes, Andrew Ruthven. GtkHTML: Updated Translations : Ivar Smolin (et) Bug Fixes : Srinivasa Ragavan (#350981) Evolution-Exchange: Updated Translations: Vladimer Sichinava (ka), Ivar Smolin (et), Rahul Bhalerao (mr), David Lodge (en_GB), Djihed Afifi (ar), Baris Cicek (tr), Woodman Tuen (zh_HK), Åsmund Skjæveland (nn) Reporting Bugs If you have problems with 2.9.3, please take the time to submit the bug using Bug Buddy or at http://bugzilla.gnome.org. Try to fill in as much detail as you can regarding the circumstances that lead to the problem. If you have a feature request, you can also file that at http://bugzilla.gnome.org/ don't be discouraged if you don't hear from us right away, we get hundreds of feature requests a year. You can also check if your bug has been reported before by using the search functionality of Bugzilla. More information is available at the project website http://www.gnome.org/projects/evolution and the project wiki : http://go-evolution.org/ Thanks, Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Groupdav connector for Evolution
Shreyas, The code is here http://svn.opengroupware.org/OGoProjects/evolution/trunk/shreyas/ Some of the files in the packages miss copyright/license details while many still retain copyright notices from the original Evolution sources with dated entries and missing information about the new authors and modifications. Also, the newly written code needs to confirm better to the Evolution Code Style guidelines (no // style comments etc.). Can you please take care of these details and also let me know if anybody is volunteering to maintain these modules as well. Thanks, Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Copyright assignment
On Wed, 2006-11-15 at 21:15 +0100, Håvard Wigtil wrote: I found http://forge.novell.com/modules/xfcontent/private.php/evolution/docs/copyright_form.pdf , and after trying to list that directory the more sensible URL http://forgeftp.novell.com/evolution/docs/copyright_form.pdf. Could someone please update the web pages and / or confirm that the fax number and address given in http://forge.novell.com/modules/xoopsfaq/?cat_id=30 are still correct? Havard, I am working on getting the url problems straightened out with the site admins. And yes, the fax number and address given in the aforementioned page is correct. Thanks for your patience, Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution documentation
Francisco, Mucho Gracias. Srinivasa Ragavan / Radhika are currently handling the documentation tasks of Evolution. I have requested them to work with you and co-ordinate the efforts towards the adoption of gnome-doc-utils. Thanks, Harish On Tue, 2006-11-07 at 11:52 +0100, Francisco Javier F. Serrador wrote: I'd like to migrate evolution to gnome-doc-utils. Does anybody have any problem/issue/question about it? Cheers! ___ 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] [UPDATE] Evolution 2.8.1.1 released
Hi, Evolution 2.8.1.1 has been released as an update to the Evolution 2.8.1 release (GNOME 2.16 stable series) with fixes to a few critical bugs/regressions [ see details below]. You can download the source tarballs at http://ftp.gnome.org/pub/GNOME/sources/evolution/2.8/evolution-2.8.1.1.tar.bz2 Reporting Bugs If you have problems with 2.8.1.1, please take the time to submit the bug using Bug Buddy or at http://bugzilla.gnome.org. Try to fill in as much detail as you can regarding the circumstances that lead to the problem. Thanks, Harish Evolution 2.8.1.1 -- Bugs/Regressions fixed in this release : #348212, #360815, #333864, #351374, #360815, #334966, #333224, #359271, #360237, #359236. Updated Translations: Ivar Smolin (et), Josep Puigdemont i Casamajó (ca), Clytie Siddal (vi), Ankit Patel (gu), Ilkka Tuohela (fi), Jovan Naumovski (mk), Luca Ferretti (it), Kjartan Maraas (nb), Zygimantas Beručka (lt), Cyprien Le Pannérer (fr), Jordi Mas (ca), Tino Meinen (nl), Daniel Nylander (sv), Francisco Javier F. Serrador (es). ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [ANNOUNCE} Evolution 2.9.1 and Evolution-Data-Server 1.9.1 released
Hi All, The Evolution Team is pleased to announce the release of Evolution 2.9.1. What is New ? = This release does not have any new major features yet but includes plenty of bug fixes since the 2.8.[0 1] releases. Also, there is no new release on the evolution-exchange module as we have had no changes since the 2.8.1 release. You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.13/gtkhtml-3.13.1.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.9/evolution-data-server-1.9.1.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.9/evolution-2.9.1.tar.bz2 Upgrade Notes : Evolution 2.9 is the unstable series of 2.10 development. Reporting Bugs If you have problems with 2.9.1, please take the time to submit the bug using Bug Buddy or at http://bugzilla.gnome.org. Try to fill in as much detail as you can regarding the circumstances that lead to the problem. If you have a feature request, you can also file that at http://bugzilla.gnome.org/ don't be discouraged if you don't hear from us right away, we get hundreds of feature requests a year. You can also check if your bug has been reported before by using the search functionality of Bugzilla. More information is available at the project website http://www.gnome.org/projects/evolution and the project wiki : http://go-evolution.org/ Thanks, Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] What GLib and GTK+ versions do we support?
On Thu, 2006-09-14 at 16:26 -0400, Matthew Barnes wrote: Stupid question maybe, but configure.in doesn't tell me. I'm asking because I'd like to use some recently added features like the GSlice allocator in some patches I'm working o n. What's the policy on this? Use whatever GNOME 2.16 supports? 'Whatever GNOME 2.16 supports' was my top-of-the-head answer, assuming few (if any) users might want to update to the latest Evolution stand-alone keeping their GNOME desktops intact. This was my thinking when I approved the patches. On second thoughts, there are users who use Evolution (for Exchange/GroupWise connectivity) but run on a KDE desktop and it is not all fun for them to update glib and above. I feel it is more prudent to make the patch use g_slice features if a supported version was available but falls back to the old implementation otherwise. This adds to the maintenance foo but gets us a few more happy users. Any thoughts, others ? -Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Code Freeze Break Requests
Thanks so much for the review and approval love :-). The changes have been committed and the relevant bugs updated. Thanks, Harish On Fri, 2006-09-01 at 16:03 +0200, Frederic Crozat wrote: Le vendredi 01 septembre 2006 à 15:27 +0200, Vincent Untz a écrit : Le vendredi 01 septembre 2006, à 18:54, Harish Krishnaswamy a écrit : Patch #1 Bug : http://bugzilla.gnome.org/show_bug.cgi?id=324118 Description : Remove IMAP4rev1 from stable releases Approval 1/2. Approval 2/2 Patch #2 Bug : http://bugzilla.gnome.org/show_bug.cgi?id=350250 Description : Show my message list from the cache first Quite a big patch. But I trust the evo team on this one. Approval 1/2. Same comment as vincent. Approval 2/2. Patch #3 Bug : http://bugzilla.gnome.org/show_bug.cgi?id=353763 Description : cannot enter text or edit memo summary field Approval 1/2. Approval 2/2 ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] ANNOUNCE: Evolution 2.8.0, Evolution-Data-Server 1.8.0, GtkHTML 3.12.0 and Evolution Exchange 2.8.0
since last unstable release - Harish K (#324118) Sankar P (#350250) Chenthill (#353763) Nickolay V. Shmyrev (#334966). Thanks, Harish Krishnaswamy. ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Request for patch review and freeze break in evolution
Hi Nickolay, Thanks for the patch. I have reviewed this patch (looks fine) but following the due process, I prefer to have this reviewed by one of the mail hackers before the release team is approached and if approved, the change is absorbed into the release candidate. This is my current understanding of the problem : This bug * has been around for quite a while * 30 duplicates * it *is* irritating to have the app crash on exit and * impacts the user perception of the app's quality adversely. * has a patch. Also, * the impact on the application's feature/functionality is minimal. * there is no data loss (this is an assumption I need the mailer guys to validate that the crash does not abort any offline sync activity or the botch the data) The risk of absorbing this change needs to weighed against the impact of the bug. Let us have this in 2.8.0 if the mailer guys feel a) the change is not very risky and/or b) the user impact is high enough to warrant this risk now. else I would like to defer it for 2.8.1. And yes, it would have been nice if this bug had been handled much earlier before it blew up but then here we are... Thanks, Harish On Sun, 2006-09-03 at 13:15 +0400, Nickolay V. Shmyrev wrote: Hi all Bug 334966 – Evolution crashes sometimes when closing main window http://bugzilla.gnome.org/show_bug.cgi?id=334966 is a critical bug with more than 30 duplicates. It has simple patch included that should fix the problem. I think someone should review the patch and break code freeze to make users happy. ___ 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] e-d-s ABI breakage [ .so bump ] ...
On Mon, 2006-08-14 at 16:12 +0100, Michael Meeks wrote: So, I spent a while digging into this and trying to patch it to remove the changes and create something that could be back-compat, so we could downgrade the .so version again. Then - I noticed that (apparently) SL 10.1 and SLED10 shipped with the new ABI anyway; but (presuambly) we just failed to bump the .so number; at least - I'm giving up until Wed. on the grounds of incomprehensibility - but it looks like: The ebook ABI change has been committed to the 2.7.x series and not for 2.6.x which ships on SLED10 / SL 10.1. * abi breakage occured * * SL10.1/code-10 ships * * .so versions bumped - now - * Gnome 2.16 ships * Which makes it look like code-10 shipped with a libebook that (while having a different .so number) is fully compatible with the current ABI, (and yet incompatible with the previous version with the same .so number). [Addressbook] AFAICT, none of the ABI break changes in ebook were pushed into autobuild and the version on SLED10 is not ABI compatible with the one shipping with 2.7.90 and onwards. I will poke Varadhan [on CC] who packages Evolution for SLED10 and get back to you. I guess that turns the problem into (mostly) a SUSE issue that we can work around by some duplication/linking of the the various libraries twice in our packages - [ugh]; and of course - reverting the ABI breakage wouldn't help us - it'd prolly just further confuse an already messy situation. Unless I'm confused again ? [Calendar] Clock Applet (Panel) already uses the changed APIs for handling recurrence data [1] and no other application in SLED10 is affected by this - the libecal SONAME has not changed and it is binary compatible with Evolution 2.7.91. Technically - this is akin to zero breakage on SONAMES, rpm deps et all and code-wise, the impact has already been handled. [1] JP had put in the fix to the panel. -Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Evolution Team Meeting Today (16 Aug) stands canceled
Many of us in the team would be missing the meeting today as it turns out to be extension of the Indian Independence day and the adjoining festival. We would not be meeting at irc today in the regular meeting. If you have any issues that you wanted to discuss in the meeting, do please post them on to this list. Sorry for the late notice ! Regards, Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] More e-d-s ABI breakage ?
On Fri, 2006-08-11 at 21:47 +0530, Harish Krishnaswamy wrote: On Fri, 2006-08-11 at 15:54 +0100, Michael Meeks wrote: Hi Harish, First - thanks for digging these changes out for me. But - no, I'm not just interested in ebook (though for OO.o that is all), but I'm -primarily- interested Evo. itself, in being able to use and test the most recent version to help avoid regressions, and indeed ship it for older platforms. So - if you could do the same for the other e-d-s libraries, it'd be great to see what changed there too. On Fri, 2006-08-11 at 20:03 +0530, Harish Krishnaswamy wrote: The changes in question are as follows : http://cvs.gnome.org/viewcvs/evolution-data-server/addressbook/libebook/e-contact.h?r1=1.20r2=1.21 So - this changed the EContactPhoto structure - why ? surely that is rather pointless. You could easily have added an EContactMimePhoto type and added a synthetic back-compat field that would handle the old case [ if it was of (whatever) mime type you expected ]. So - I see no problem at all doing this compatibly whatsoever. Perhaps a few more (~20) lines of code tops. I had not reviewed the patch or explored the alternatives to avoid breakage. I would let the addressbook hackers to comment on that. I do think you have a point above, though. [1] OTH, I did approve the change into the release on the clear basis that ferrying Photo images on Contacts was prohibitively hampering the performance of the dbus port and the library had all to gain by ferrying a url instead. http://cvs.gnome.org/viewcvs/evolution-data-server/addressbook/libebook/e-contact.h?r1=1.21r2=1.22 You converted a gpointer value to a 'const gpointer value' - I don't see that that is particularly necessary, or likely to break the ABI of anything unless it reflects some underlying lifecycle issue. Also the enum insertions were (this time) added at the end of the enumeration, so why should that break anything ? surely that's a compatible extension. Point taken - The original patch would have introduced a break - this was reworked as an append before it was committed. The #313533 patch was vital for Ross Burton's dbus-based EDS and running EDS on devices (say Nokia 770) would not be possible w/o this change. Nonsense - at least the link above has no API change that is necessary for dbus or Nokia 770 support - unless I'm missing something huge; good buzz-words though :-) See http://www.go-evolution.org/DBus_Port_of_EDS . The charts on the link seems to be broken ATM..I will post the performance charts to the thread. BTW, An interesting link I came across... http://applications.linux.com/article.pl?sid=06/08/04/2158214from=rss --Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] More e-d-s ABI breakage ?
On Fri, 2006-08-11 at 15:54 +0100, Michael Meeks wrote: Hi Harish, First - thanks for digging these changes out for me. But - no, I'm not just interested in ebook (though for OO.o that is all), but I'm -primarily- interested Evo. itself, in being able to use and test the most recent version to help avoid regressions, and indeed ship it for older platforms. So - if you could do the same for the other e-d-s libraries, it'd be great to see what changed there too. On Fri, 2006-08-11 at 20:03 +0530, Harish Krishnaswamy wrote: The changes in question are as follows : http://cvs.gnome.org/viewcvs/evolution-data-server/addressbook/libebook/e-contact.h?r1=1.20r2=1.21 So - this changed the EContactPhoto structure - why ? surely that is rather pointless. You could easily have added an EContactMimePhoto type and added a synthetic back-compat field that would handle the old case [ if it was of (whatever) mime type you expected ]. So - I see no problem at all doing this compatibly whatsoever. Perhaps a few more (~20) lines of code tops. I had not reviewed the patch or explored the alternatives to avoid breakage. I would let the addressbook hackers to comment on that. I do think you have a point above, though. [1] OTH, I did approve the change into the release on the clear basis that ferrying Photo images on Contacts was prohibitively hampering the performance of the dbus port and the library had all to gain by ferrying a url instead. http://cvs.gnome.org/viewcvs/evolution-data-server/addressbook/libebook/e-contact.h?r1=1.21r2=1.22 You converted a gpointer value to a 'const gpointer value' - I don't see that that is particularly necessary, or likely to break the ABI of anything unless it reflects some underlying lifecycle issue. Also the enum insertions were (this time) added at the end of the enumeration, so why should that break anything ? surely that's a compatible extension. Point taken - The original patch would have introduced a break - this was reworked as an append before it was committed. The #313533 patch was vital for Ross Burton's dbus-based EDS and running EDS on devices (say Nokia 770) would not be possible w/o this change. Nonsense - at least the link above has no API change that is necessary for dbus or Nokia 770 support - unless I'm missing something huge; good buzz-words though :-) I feel sorry to know you would think I would stoop to get around the issue with buzzwords. http://www.burtonini.com/blog//2006/Jul/22 The performance tests showed this was prohibitive for EDS on DBUS. quoting Devashish I didn't explored the problem any deeper but appears that there is some problem with e_book_get_contacts code. For detailed timing reports on this test download the following files and open them with sysprof. See http://www.go-evolution.org/DBus_Port_of_EDS . --Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] ECalBackend vs. ECalBackendSync
On Mon, 2006-07-31 at 03:08 -0400, Peter Colijn wrote: Suppose I am writing a new calendar backend. Which of these two interfaces is preferred? The requirements of your application and the characteristics of your backend should guide the choice. If I implement ECalBackendSync, will operations on the calendar cause the UI to block? Not necessarily. Separate the threads that do backend operations and those that repaint UI. HTH, Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Persisting ESource
On Mon, 2006-07-24 at 14:36 -0700, Scott Herscher wrote: Hey all. I'm trying to add a property to an ESource instance after it has been created. This change doesn't seem to persist at all. In my ECalBackend class, I call e_source_set_property(...). Looking at the code, e_source_set_property() just add the key /val to it's hashtable. Where and when does it get written out to disk? How do I ensure this happens? What is the property you wish to persist ? Generic properties that need persistence should go into GConf (you can refer to the schema that defines what are saved).ECalBackend objects signals the change in property values to ECal objects and changes to/from GConf are synchronized. ESource properties specific to remote servers (such as GW) are usually saved to the server and retrieved every session. HTH, Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] pvl_list structure in libical
Hi Mathew, On Fri, 2006-07-14 at 17:06 -0400, Matthew Barnes wrote: Hi all, I've recently started maintaining Evolution for Red Hat. snip The source code is dated November 1995 and looks to be isolated to libical. It's basically a linked-list of void pointers, and I don't see anything useful here that GList doesn't already provide. Plus, the utilization of GSlice for node allocations -- rather than raw malloc()/free() calls as pvl_list uses -- might yield a small performance improvement. I'm tempted to purge it from libical and replace it with a GList structure, but first I wanted to check with the upstream maintainers to see if they'd accept such a patch. Are there other issues here that I'm not considering, such as API stability? The libical module inside EDS is a source snapshot obtained from the upstream few years ago and has remained as such ever since, save a few functionality fixes and added functions. Much of e-d-s clients (incl. Evolution) use the ECal APIs that wrap around libical functionality though there are many places in Evolution that still invoke libical functions directly. It has been our direction to code the new functionality in ECal and slowly ease out libical calls from Evolution in favor of ECal. Yes. We would be interested in moving towards GSlice based memory handling replacing icalmemory and use of G(S)List. It has been the direction we have wanted to move for sometime but has been in the back-burner in favor of stability fixes and feature additions. I would be happy to work with you on this . -Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] no-inst headers camel-private.h?
On Wed, 2006-07-19 at 14:36 +0200, Smartuser wrote: Hi, I've some question about the camel-private.h Why is it a no-inst header according to the Makefile.am? As far as i know almost every provider depends on it. Is there a reason or is it just a mistake? Serjan Pruis As the name suggests, I am led to believe that it is a private header and intentionally not installable. The mistake could actually be that the providers include this directly. Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Compilation Linking flags
On Tue, 2006-07-18 at 17:02 -0400, Teresa Thomas wrote: How can I obtain the compilation and linking flags necessary for libical and libecal (EDS)? Pkg-config doesn't seem to be supported. Thanks. They are. [EMAIL PROTECTED]:~ pkg-config --cflags libecal-1.2 -DORBIT2=1 -pthread -I/home/kharish/opt/gnome/include/evolution-data-server-1.8 -I/home/kharish/opt/gnome/include/libgnome-2.0 -I/home/kharish/opt/gnome/include/libbonobo-2.0 -I/home/kharish/opt/gnome/include/glib-2.0 -I/home/kharish/opt/gnome/lib/glib-2.0/include -I/home/kharish/opt/gnome/include/orbit-2.0 -I/home/kharish/opt/gnome/include/gconf/2 -I/home/kharish/opt/gnome/include/gnome-vfs-2.0 -I/home/kharish/opt/gnome/lib/gnome-vfs-2.0/include -I/home/kharish/opt/gnome/include/bonobo-activation-2.0 -I/usr/include/libxml2 Cheers, Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Camel in evolution-data-server, a different proposal
On Wed, 2006-07-12 at 19:13 +0200, Philip Van Hoof wrote: At this moment, all those fall under the name of evolution comma data comma server. Some of these libraries (like Camel) don't necessarily have anything to do with the Evolution data that is being managed by the data server of Evolution. The E-mails and, folder-summaries, state data and summaries of Camel are *not at all* being managed by Evolutions data server. It's simply totally unrelated to the Evolutions data server. It looks like even some Novell employees don't know that, probably cause it's being marketed as one package. Which Novell employees ? It simply looks like Evolution developers didn't know where to stack all these Evolution libraries. And thought .. oh, we already had this Evolution data server thing .. lets simply put it there. It's not good a solution, imo. A library is a library. We have package systems (like yum and apt) to solve the dependency problem for users. Evolution-Data-Server handles PIM data - (mail / calendaring / contacts information, journals) packaging them together *does* make lot of sense. I do not think you are suggesting that every library should be packaged separately, are you ? snip Conclusion .. all this coupling with Evolution and Evolution Data Server is making it harder for application developers to actually *use* the provided functionality. The current packaging *is* good for users and packaging systems. As for the application developers, you are certainly not the first one to tread this path. Ask Gaim. Clock applet. Contact applet. Open Office. Planner. Beagle. Philip - Nobody is any better with these long winding arguments back and forth. Can we get to the business at hand ? Let us spend our energies together on the camel-mmap patch instead. --Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] strtok camel : Core dump [Was : strtok camel from evolution-data-server]
Hi Philip, Most Evolution people already know this. This is just the E-mail you guys have been asking about (well, actually most of you guys asked me to make a bug in bugzilla). Yes. The Evolution Team has been in conversation with you by mail/irc and in person (at GUADEC). So or camel is going to be split from evolution-data-server, or I will fork camel. This is not the language of a 'dialogue' - this reads more like an ultimatum. The one laptop per child project, Nokia (maemo) and maybe sooner or later other vendors like PalmSource are getting more and more interested in tinymail. Situation: -- Tinymail depends on Camel. Camel gets shipped with e-d-s. Tinymail doesn't use *any* of the other e-d-s softwares, libraries nor its data. Observation: From reading code I *know* camel doesn't have to depend on e-d-s at all. It can very easily be cut-off from it. I could probably do this in a few hours work. I disagree. As I am replying, I see Ross has already answered this point. So, I will skip. THIS is ALL I need. Please DO understand this Evolution people. Try reasons ending with 'This is what Evolution/GNOME needs'. We will grok it better. Hacks like packaging tricks: I AM NOT going to require packaging tricks. Packaging tricks are hacks. I don't do hacks. Hacks are ugly. Hacks are win32. I didn't come to the opensource community to get myself stuck in hacks. I strongly disagree with hacks. I don't support hacks. I will not use hacks. I will fork if I'm forced to use hacks. Packaging is NOT a hack. It is a win/win approach for the project and its consumers. Ross has already shown the BETTER WAY in ebook. And, the addressbook component and the Evolution community have gained from his efforts. So have Ross and Opened Hand. I do not see what you want to achieve by a fork. But if you must, dear friend, what can I say : Camel is Open Source and licensed under the terms of LGPL. Your surprised pal, --Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] po/LINGUAS disaster, going on
My comments updated on http://bugzilla.gnome.org/show_bug.cgi?id=337996 -Harish On Wed, 2006-06-14 at 09:03 -0400, Matthias Clasen wrote: evolution-exchange-2.7.3 is translation-less ___ 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] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
Tor,
Please commit the patch to HEAD as well as the stable branch. The
change looks fine to me. I will also get the unregister action tested
in the regular builds on the branches and perhaps in MacOS (I do not
know if it matters, but anyway!) as a routine but I do not expect any
surprises.
Thanks,
Harish
On Sat, 2006-06-17 at 02:23 +0300, Tor Lillqvist wrote:
lö 2006-06-17 klockan 01:40 +0300 skrev Tor Lillqvist:
If my analysis is correct, this means that attempting to do a CORBA
object unregistration in the GObject finalize method is too late, isn't
it?
I tested by applying this simple patch to e-shell.c, moving the
bonobo_activation_active_server_unregister() call from impl_finalize()
to notify_no_windows_left_idle_cb():
Index: shell/e-shell.c
===
RCS file: /cvs/gnome/evolution/shell/e-shell.c,v
retrieving revision 1.272
diff -p -u -r1.272 e-shell.c
--- shell/e-shell.c 30 Jan 2006 11:49:53 - 1.272
+++ shell/e-shell.c 16 Jun 2006 23:17:50 -
@@ -360,13 +360,18 @@ static gboolean
notify_no_windows_left_idle_cb (void *data)
{
EShell *shell;
+ EShellPrivate *priv;
shell = E_SHELL (data);
+ priv = shell-priv;
set_interactive (shell, FALSE);
g_signal_emit (shell, signals [NO_WINDOWS_LEFT], 0);
+ if (priv-iid != NULL)
+ bonobo_activation_active_server_unregister (priv-iid,
+
bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
bonobo_object_unref (BONOBO_OBJECT (shell));
return FALSE;
@@ -467,10 +472,6 @@ impl_finalize (GObject *object)
shell = E_SHELL (object);
priv = shell-priv;
-
- if (priv-iid != NULL)
- bonobo_activation_active_server_unregister (priv-iid,
-
bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
e_free_string_list (priv-crash_type_names);
And lo and behold, it works! Now the ESHell gets unregistered, and when
starting Evolution again it manages to register its EShell and contact
the already running e-d-s etc.
OK to apply this patch to HEAD and stable? ChangeLog entry:
2006-06-17 Tor Lillqvist [EMAIL PROTECTED]
* e-shell.c (impl_finalize): Don't call
bonobo_activation_active_server_unregister() here, it's too late,
the EShell Bonobo object has already been deactivated and its
associated CORBA object is NULL.
(notify_no_windows_left_idle_cb): Instead, call
bonobo_activation_active_server_unregister() here, when the EShell
Bonobo object is still fully active.
I should still of course also investigate why the other (unknown)
mechanism which causes unregistration to happen anyway on Unix doesn't
work on Windows...
--tml
___
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] How would this work?
Yes. It is indeed possible for you to use the IMAP camel provider to talk to your custom server. Just have a look at how the GroupWise provider is implemented. See camel_provider_module_init () in http://cvs.gnome.org/viewcvs/evolution-data-server/camel/providers/groupwise/camel-groupwise-provider.c?rev=1.33view=markup which (when use_imap is TRUE) sets the groupwise camel provider store to that of imap. The groupwise-account-setup plugin is also a good working model for you to base the zimbra account creation on. This has some limitations currently which will be addressed in near future (and hence likely to change). --Harish On Sat, 2006-06-10 at 15:55 -0700, Scott Herscher wrote: Hey all. I'm wondering if it's possible to write a custom backend for evolution and evolution-data-server that re-uses the IMAP camel provider? I've written a custom e-book library that kinda works, and I'm getting started on writing a custom e-cal backend that will do calendaring. In the interest of time, and since the server I'm working with supports the IMAP protocol, I was hoping I could do something simple like reuse the IMAP camel-provider and use my custom addressbook and calendar plugins in setting the account up. Is this possible? If so, how would I do something like that? Scott ___ 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] Fix for #331743 - crash on first start
Yes. I have approved the patch in bugzilla. Thanks, Harish On Wed, 2006-06-07 at 10:22 -0500, Federico Mena Quintero wrote: Hi, Please look at http://bugzilla.gnome.org/show_bug.cgi?id=331743 Evolution 2.7 crashes on startup if you run it within a clean user account. This happens because EMap (the map widget for the timezone configuration dialog) uses an incorrect signal marshaller. The attached patch fixes this. Is it OK to commit? Federico ___ 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] Bogofilter plugin 0.2.0
Hi, P.S. I'm still willing and able to adapt the source for inclusion in the Evolution source tree, with the developers' consent. However, introducing choice between the two available junk plugins may render the user's configuration non-obvious, so I understand if you wish to keep only one bundled with Evolution. We are open to exploring and assessing alternatives with respect to handling spam in Evolution. Taking this up for discussion in the Evolution meeting later today. Thanks, Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Your system configuration does not matches evolution configuration
On Tue, 2006-05-16 at 21:35 +0100, Keith Sharp wrote: Is there a bug open for this? I can pretty reliably recreate this on my laptop by running Evolution, stopping Evolution cleanly, hibernating my laptop, resuming and trying to start Evolution. Keith. The message means what it says - The configuration is not what it should be for the application to run well. The work-arounds suggested all refer to environments where multiple versions of evolution/eds co-exist - and tell you how to recover from a bad combination. The action required towards a full solution is to get the environment to a valid state - remove conflicting versions or isolating matched versions in your shell environment through proper settings to BONOBO_ACTIVATION_PATH, LD_LIBRARY_PATH etc. So this is not a 'bug' that can be fixed by modifying the code. What may be a bug indeed is documentation (or a lack of it) on the prevention and recovery of such errors. Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] A bug for todo conduit.
You are right. I am moving the timezone check ahead of init-ing the
calendar server.
Thanks,
Harish
On Sat, 2006-05-13 at 11:25 +0800, Yu-Hui Liu wrote:
Just take a look at evolution/calendar/conduits/todo/todo-conduit.c,
found a bug.
http://cvs.gnome.org/viewcvs/evolution/calendar/conduits/todo/todo-conduit.c?rev=1.97view=markup
The code below:
if (start_calendar_server (ctxt) != 0) {
WARN(_(Could not start evolution-data-server));
gnome_pilot_conduit_error (conduit, _(Could not start
evolution-data-server));
return -1;
}
/* Get the timezone */
ctxt-timezone = get_default_timezone ();
if (ctxt-timezone == NULL)
return -1;
LOG (g_message ( Using timezone: %s, icaltimezone_get_tzid
(ctxt-timezone) ));
should be:
/* Get the timezone */
ctxt-timezone = get_default_timezone ();
if (ctxt-timezone == NULL)
return -1;
LOG (g_message ( Using timezone: %s, icaltimezone_get_tzid
(ctxt-timezone) ));
if (start_calendar_server (ctxt) != 0) {
WARN(_(Could not start evolution-data-server));
gnome_pilot_conduit_error (conduit, _(Could not start
evolution-data-server));
return -1;
}
Otherwise, the ctxt-timezone will be an empty pointer.
Well, there's some other bugs so the todo conduits doesn't work now. Other
conduits work well. May someone take a look at this?
Thanks.
Calvin
___
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] [ANNOUNCE] Unstable - Evolution 2.7.1, Evolution-Data-Server 1.7.1, Evolution-Exchange 2.7.1 and GtkHTML 3.11.1
Hi, One of my sanity tests on the tarballs failed while testing a GW account operation. I am still investigating the problem and not entirely sure if it was a libsoup integration issue. It did work against the older version of the library and hence I had referred to the latter, intentionally, so I could roll out the tarballs in time. The 2.2.6.1 version should work fine for other providers and most scenarios in GW too, though. Harish On Tue, 2006-04-25 at 17:54 +0200, Andre Klapper wrote: Am Montag, den 24.04.2006, 22:50 +0530 schrieb Harish Krishnaswamy: You can download the following : [...] http://ftp.acc.umu.se/pub/gnome/sources/libsoup/2.2/libsoup-2.2.6.1.tar.bz2 guess this should better be http://ftp.acc.umu.se/pub/gnome/sources/libsoup/2.2/libsoup-2.2.92.tar.bz2 :-) cheers, andre ___ 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] Request for adding version information to libcamel soname
Hi Øystein and Heikki, My hearty wishes to both of you, the new Debian Evolution package maintainers :-). Looking forward to work with you towards a better 'Evolution' for the world at large. On the bigger point, I am in favor of your suggestion on the versioning scheme for Camel. On finer thoughts, I would like to evaluate the likely impact of this change with the mail hackers, keeping in mind any likely changes to the API during the current development cycle as well as the compatibility constraints on existing deployments. I will get back to you in a couple of days. Thanks, Harish On Sun, 2006-04-23 at 23:43 +0200, Øystein Gisnås wrote: The Debian Evolution Maintainer Team is planning the upload of Evolution 2.6 to unstable to happen very soon. Before the upload, we'd like feedback from Evolution developers on the biggest change we make to the upstream release. In specific, Harish confirmed bug #321372, which is what this is about, and also Parthasarathi probably have valuable comments on this topic. The first part of the change was described in the previous mail in this thread. In addition to using version numbers to libcamel (contrast to today's 0:0:0), we plan on moving the private libcamel provider libraries to an install location that is version specific. The current location is /usr/lib/evolution-data-server-1.2/camel-providers/, which includes the API version, but not libcamel version. As far as I know, it has already been discussed to name the e-d-s directory differently. Do you have an update on if/when that will happen? What we will do on the debian side is to move the contents of camel-providers to camel-providers/8, or alternatively name it camel-providers-8 or similar. We highly value having the same names and versions in our releases as in upstream. If you could give some indications on what changes will be made upstream, and what names and versions will be used for this, we could use that name/version scheme already and avoid future conflicts. Our release will not be delayed indefinitely, but we'll put effort into avoiding a diversion from upstream directions. Therefore a quick answer will be greatly appreciated. Thanks, ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] a security issue with Evolution
Which version of Evolution are you referring to ? Evolution 2.6 does not let you send mails through accounts that have not been enabled. This issue has been fixed already. That also leads me to kindly remind you - Upgrade, Upgrade :-) Thanks, Harish On Sat, 2006-04-22 at 02:12 -0300, Jose Tavares wrote: Today I was at FISL (Forum Internacional Software Livre) accessing the net through the wifi network they were offering. It was an open wifi network with no crypto at all.. So, using Evolution I needed do disable the access of my email accounts whose pop/smtp does not offer a secure connection. Yes, there's a big provider here in Brazil that does not offer secure connection to its pop/smtp. The problem is that I left enable just an account at gmail that is configured to make secure connections.. After that, I took an old email in my outbox that had been sent with the account from the unsecured provider and selected Edit as new message. Then, I thought the From: field would have been changed automatically to my new configured default connection. Guess what happened? I sent the email with the From: field from the unsecure provider and Evolution did established an unsecure conection to the unsecure provider and sent my plain password through the network even with the unsecure account marked as disabled in Evolution!! [] JA Tavares ___ 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] Google Calendar sync
Hi Peter, Thanks for your interest. I am not aware of anyone working on Google Calendar ATM. You have the head start :). The way to approach this would be to write a new Calendar backend in Evolution-Data-Server (in C, yes). To start, * Let everybody know you are working on it and pen your thoughts on go-evolution.org. You might attract a few helping hands. * The GW calendar backend (which uses GroupWise SOAP APIs) or the http backend would be nice references to model your design on. * Let me know how much time/effort you plan to put into this and if you would like it to be added to the 2.8 roadmap. Feel free to ping the Evolution Team for any further information. Harish On Fri, 2006-04-21 at 13:27 -0400, Peter Colijn wrote: Hi, Is anyone working on a way to do 2-way sync with Google Calendar (using the XML-based API)? If not, I'd be interested in doing this. I worked on the Google Calendar team and am quite familiar with the product. I've also done some Evolution work in the past, but it was the 1.4.x days so I imagine things are quite different now. Is this something that could be done in an EPlugin? Or would I need to write a new calendar backend in C? Any pointers or tips as to the best way to do this would be appreciated. Thanks! Peter ___ 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] unprofessional or what
Hi Ralf, On Mon, 2006-04-17 at 17:09 +0200, Ralf Engels wrote: snip Bugs at bugzilla.gnome.org don't get re-viewed. So no checking, no assigning and even my patched bugs just lay around. Since a month. Even Microsoft is faster! I am sorry your patch did not receive more love than it so rightly deserved. We do encounter a huge amount of traffic in terms of patches and bugs - more than we manage to handle as we would like to. You may perhaps appreciate that Evolution has consistently topped the weekly bug activity in terms of bug reports and triaging for several months running. http://bugzilla.gnome.org/reports/weekly-bug-summary.html Thanks to lots of community love (andre, guenther) - you just need to look at the bugzilla scores of some of these hackers (who work almost exclusively on Evolution) to get a grasp of what is being done here. Patches at the patches mailing list don't get re-viewed. Ok, maybe that's not needed. Lately, much of this is moving into Bugzilla and hence some of them do not get replied. A glance at the commit traffic (thanks to the core Evolution team and our friends from Sun, China) might give you a better picture. And then we have the evolution homepage where it claims that the last IRC team meeting was six months ago. Ok, maybe Evolution is stable enough that we don't need such a thing any more. We have had consistent problems in managing this site remotely and keeping this updated. My bad in having let this slip down my to-dos. I will treat this as a wake-up call and get this fixed. Much of the activity has in fact moved to go-evolution.org - we should be making it THE official project base as soon as we can get the issues resolved. Our weekly IRC meetings do happen on Wednesdays at 1000 IST. (You are welcome, as is every Evo-lover) - We can starting posting the minutes regularly once we get rid of the site woes mentioned above. I take it that your mail reflects your love and concern for the project. We do our best and keep trying to get better - but we are humans too :-) Thanks for this opportunity to let me acknowledge the work of my wonderful colleagues and community volunteers. And yes, I will follow-up your bug reports and patches - by the end of the day. be professional. Update the homepage, go through bugzilla and write some comments to patches on the patches mailing list. Or rot... BR, Ralf I prefer Option A. Thank you. - Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] IRC meeting cancelled
Hi all, The weekly IRC meeting scheduled for 1000 UTC today stands cancelled as it is a day off in Bangalore and the team is not in office. Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Re: Gender ...
On Wed, 2006-02-15 at 12:11 +, michael meeks wrote: So, At the risk of offending the gender-confused; it would be -extremely- useful to have a Gender boolean in the evolution addresbook [ of course, perhaps there is I'm just missing it but I dug into the code ]. No. There isn't. The reason is OO.o will vary it's salutation on gender; ie. Dear Mrs. Foo Dear Mr. Foo etc. - now one can argue whether this is broken etc. but there it is ;-) the current ergonomics are rather built around this - and, you can see that such a boolean internationalizes rather nicely. Why not use 'Title' which is more generic and appropriate - there are any number of use-cases where a boolean gender would not fit. Addressing a Doctor / the Queen ;-) for eg. So - the question is: can we have it ? currently the OO.o mail merge is rather feeble without it. Certainly not on Evo 2.6 at this point, you perhaps already knew that. Any reason why 'Title' cannot fit your needs ? Regards, Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Re: evolution and pango in 2.13.90 don't play nice
At gentoo, we patched the gtkhtml-2.13.90 tarball. A new one would be nice, but is not necessary. fwiw, I rolled out Gtkhtml-2.13.90.1 tarballs yesterday that have Matthias' fix for the pango issue. Regards, Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] String/UI change notifications for commits done on UI Hackfest
hi All, We are in String/UI Change announcement period and I notice the due notifications to gnome-doc lists have not been sent for patches related to the UI Hackfest. So I will be sending a consolidated notification citing all the changes done as part of the UI Hackfest with a cut-off on Jan 13 3:00 pm IST. Please ensure any further commits with UI/String changes beyond this time are duly notified to the lists. See http://mail.gnome.org/archives/desktop-devel-list/2005-February/msg00092.html for further information. Thanks, Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Remove duplicate e-util-marshal.list in evolution/widgets/misc
This change looks fine to me. Actually, it must have been just oversight not having removed e-util-marshal.list from evolution/widgets/misc. Srini has been working on widgets/* more than any of us lately, though. Thoughts, Srini ? Thanks, Harish On Tue, 2006-01-10 at 18:47 +0800, simon.zheng wrote: Hi all, Here is bug information. http://bugzilla.gnome.org/show_bug.cgi?id=323529 We found another duplicate file e-util-marshal.list. There's two copies of e-util-marshal.list in and evo/e-util and evo/widgets/misc. They're 100% identical. What's more, we noticed the other modules in evo/widgets, such as evo/widgets/table and evo/widgets/text, use the copy in evo/e-util rather than their own built-in copies. We think the one in evo/widgets/misc might be dropped. Attached the patch, pls review and comment. Thanks, -Simon ___ 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] Spam attack on go-evolution.org
I am away from office - on leave and would be back only on Jan. Srini/Varadhan, can you please look into the same ? Thanks, Harish On Mon, 2005-12-19 at 10:28 -0500, JP Rosevear wrote: On Mon, 2005-12-19 at 14:58 +, Tor Lillqvist wrote: Check out the Recent Changes page... Lots of pages have been filled with spam. Apparently only pages that were empty until now, though? Same thing happened to the beagle wiki last week. Joe added Captcha (http://en.wikipedia.org/wiki/Captcha) support there to prevent further issues. -JP ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Future of Evolution Spellchecking?
Andre, On Tue, 2005-12-13 at 14:21 +0100, Andre Klapper wrote: so would that patch be accepted? any comments or thoughts on this? and by whom would it be accepted, because who maintains gnome-spell anymore? i know that radek was the last person working on gnome-spell (and harish as evolution maintainer told me to mail him directly), but i have not received an answer yet (it has been three days), and the string announcement period is getting closer (yes, the names of the languages have to be translated). so can someone assure me that there will be a gnome-spell release for 2.14 including this patch if i would provide it? otherwise it's just worthless and people keep waiting for spellchecking support for their language. keep in mind that it's ridiculous to have the entire gnome-desktop translated to xhosa, but not being able to have xhosa spellchecking in gnome-desktop's mailer[7], to name one example. keep in mind that we are excluding many, many potential customers out there (...this one goes out to novell ;-). This is more about gnome-spell and I am not qualified to answer that. But I agree it has a huge impact on Evolution users. I'll do a follow-up on this. in a long run (gnome 2.16?), gnome-spell should switch to use enchant instead of aspell. enchant is capable of having multiple backends loaded at once (see backends section at [8]), including aspell. but would anyone work on that port? It is on the table - anyone ? :-) Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Sending mails using disabled accounts
On Wed, 2005-11-30 at 00:38 +0100, Philip Van Hoof wrote: It looks like current CVS does not allow sending E-mails uing disabled accounts. I very often disable E-mail accounts to make it possible to choose between multiple of my E-mail addresses. you mean - not having them shown up in the mail folders tree ? How does disabling help you in choosing more easily ? Why is this possibility blocked? It boils down to what one defines 'disabling' an account as. I guess you mean it as 'I do not want to see the mails in the account till I enable it again but it is available right _there_ for all other purposes - Sending mails, Draft/Sent Item settings..etc..' - (more in the narrower sense of 'visibility'). A lot of new users suggested they interpret 'disabling' as 'I do not want anything to do with that account till I enable it again'. What has been done now is to align the behavior to what it suggests (at least to the many). Partha/Shreyas, would you like to shed more light here ? Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Re: About evolution-data-server/libedataser and evolution/e-utils
On Thu, 2005-11-24 at 16:33 +0800, Irene wrote: Hi, Harish I built evolution 2.6 on my Solaris X86 the other day. The build process was successful, however, as soon as I started evolution-2.6, it crashed. We investigated this problem and arrived at the following conclusions: camel_vee_folder_hash_folder in evolution-data-server/camle/camel-vee-folder.c invokes functions including md5_init, md5_update and md5_final. The fact is, two copies of md5_utils.[c|h] with exactly same functions defined, exist in the evolution system, one in evolution-data-server/libedataser and the other in evolution/e-utils. Right. This is the result of an incomplete migration of the files and the existence of duplicates is a known structural issue - though we have not seen bugs/functional breakage yet. This just explains why the problem has existed w/o crying for attention for this long- we do need to fix it. Camel-vee-folder.c includes evolution-data-server/libedataserver/md5-utils.h, but when evolution runs, the md5_* functions in evolution/e-utils/md5-utils.c instead of those in evolution-data-server/libedataserver/md5-utils.c are invoked, which we think should not be the case. Building with an eye for this detail (building against the right function) solves this problem. This is why it works on Linux, i guess. I need to see how Solaris x86 handles this. When we went further into this issue, we saw that there's a huge lot of duplication in evolution-data-server/libedataser and evolution/e-utils. With such duplications, similar problems may surface in the future when one copy of the code is modified while the other remains unchanged. We think that something should be done to solve this problem. yes. let us get this discussed on the meeting next week. I would love if someone can volunteer to do a detailed audit on this duplication and chalk out how we can get rid of the cruft. (In some cases, I suspect they may not be exact duplicates and both may be required in that form by different pieces). Takers, you can count on me to chip in to lend a hand :-) Cheers, Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils
On Thu, 2005-11-24 at 09:27 +, Ross Burton wrote: On Thu, 2005-11-24 at 09:19 +, Ross Burton wrote: On Thu, 2005-11-24 at 16:33 +0800, Irene wrote: Currently, the MD5Context structures in evolution-data-server/libedataserver/md5-utils.h and evolution/e-utils/md5-utils.h are different with the first one not having a doByteReverse member. Hm, that would be my fault: I've been working with e-d-s and cleaned up the libedataserver/md5-utils to remove the doByteReverse member. The obvious solution is to remove md5-utils from e-utils. It looks as if the md5-utils in e-util isn't used at all in Evolution, OK to remove it from evolution HEAD? I agree. Mailer guys, anyone think otherwise ? Ross ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] About evolution-data-server/libedataser and evolution/e-utils
Md5-utils.ch are not the only files that are duplicated. Most of the files in evolution/e-util have similar copies in evolution-data-server/libedataserver. Yes. To be more precise, evolution-exchange in addition to e-util and libedataserver :-). I've created a wiki page http://live.gnome.org/EvolutionEUtilDieDieDie listing the files which are identical, which are different, etc, to track this. Ross Thanks Ross :-). That really gets us moving to the next step. Shreyas had taken the cause up [http://go-evolution.org/Evo2.6#Misc] early during the cycle and IIRC, had started doing something on it too. Shreyas ? ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] e-util compiling errors evo-2.2.1.1
your prefix looks suspicious. Just do a make clean to get rid of the generated files and regenerate your Makefile just to be sure.. On Tue, 2005-11-01 at 08:07 -0500, AG wrote: I believe I've got a simple compile error, but I've not found very many answers via the ubiquitous google search.. Any ideas?? Thx in advance for any suggestions. make[3]: Leaving directory `/tmp/evolution-2.2.1.1/data' make[2]: Leaving directory `/tmp/evolution-2.2.1.1/data' Making all in e-util make[2]: Entering directory `/tmp/evolution-2.2.1.1/e-util' ( --prefix=e_util_marshal ./e-util-marshal.list --header e-util-marshal.h.tmp \ mv e-util-marshal.h.tmp e-util-marshal.h ) || ( rm -f e-util-marshal.h.tmp exit 1 ) /bin/sh: --prefix=e_util_marshal: command not found make[2]: *** [e-util-marshal.h] Error 1 make[2]: Leaving directory `/tmp/evolution-2.2.1.1/e-util' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/evolution-2.2.1.1' make: *** [all] Error 2 ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] ANNOUNCE : Evolution 2.4.0 and Evolution-Data-Server 1.4.0 Release
Hi All, The Evolution Team is pleased to announce the release of Evolution 2.4.0 and Evolution-Data-Server 1.4.0. What is new since Evolution 2.2 ? - - A new menu layout (More HIG compliant) - Inline PGP Signature/Encryption support. - Performance enhancements on Camel/GroupWise Backends. - Auto-fit Image Attachments - Support for GroupWise proxy accounts - Extended EPlugin support, importers as an EPlugin. - Thunderbird-compatible storage of labels on IMAP. - Support for delegation of meetings (Calendar) - Marcus Baines Line (calendar) - Removal of Exchange button and seamless access to Exchange through Evolution Mail/Calendar/Task components. And, Evolution-Data-Server is now available in LGPL. You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.4/evolution-2.4.0.tar.gz http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.4/evolution-data-server-1.4.0.tar.gz http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.4/evolution-exchange-2.4.0.tar.gz http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.8/gtkhtml-3.8.0.tar.gz http://ftp.acc.umu.se/pub/gnome/sources/libsoup/2.2/libsoup-2.2.6.tar.gz Reporting Bugs If you have problems with 2.4.0, please take the time to submit the bug using Bug Buddy or at http://bugzilla.gnome.org. Try to fill in as much detail as you can regarding the circumstances that lead to the problem. If you have a feature request, you can also file that at http://bugzilla.gnome.org/ don't be discouraged if you don't hear from us right away, we get hundreds of feature requests a year. You can also check if your bug has been reported before by using the search functionality of Bugzilla. More information is available at the project website http://www.gnome.org/projects/evolution and the project wiki : http://go-evolution.org/ Thanks, Harish ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
