Re: [Evolution-hackers] building evolution-data-server against the already installed libdb
On Mon, 2006-02-27 at 17:49 -0500, Mikhail Teterin wrote: Hello! I'm trying to convince the maintainers of the evolution-data-server FreeBSD port (http://freshports.org/databases/evolution-data-server) to build the software against the db4-version installed by the separate port of SleepyCat's db4 (http://freshports.org/databases/db43). I'm using the thus built evolution (against db-4.3.29) to type this message, but they remain hesitant, because of the past problems they encountered trying to build evolution using the already installed db3 instead of the version then-bundled with evolution. I'm guessing, you used to have modified version of db3, which allowed it to work, where the standard version did not. Is there anything like that in the db4.1 version bundled with e-d-s 1.4.2.1, or can we safely use any reasonably recent version of db4? Moreover, perhaps, you can be convinced to stop the bundling of db4 completely and turn it into just another pre-requisite? http://bugzilla.gnome.org/show_bug.cgi?id=319393 contains a patch we've been using in the DBus port of EDS to use a dynamic libdb. Instead of simply hacking away at the makefiles it adds an option, so is suitable for integration. EDS comes with a copy of libdb 4.1. It was copied as back in the early days of Evolution some people had db3, and some had db4, but the file format changed. The solution to this was to add migration logic from db3 to db4 in EDS, and to enforce EDS linking to db4.1 by embedding the source. Recently the DB file format hasn't changed, so the problem is moot. I've been running EDS with a dynamically linked libdb 4.1, 4.2 and 4.3 without any problems, on both Intel and ARM. I really would like this patch to be merged into EDS for G2.16, if only for the memory reduction: libdb is statically linked into both the bdb addressbook backend and libedataserver, at a cost of 600K each time. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] `make check' fails in po/
Fix is committed to CVS head. Thanks, Sushma. On Mon, 2006-02-27 at 18:02 -0500, Mikhail Teterin wrote: The references to the non-existant e2k-user-dialog.c break `make check' in the po directory :-( Can this, please, be fixed so that the checks can be run automatically after build to detect any compile or link problems? Thanks! -mi ___ 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] Re: [evolution-patches] [Mailer] Possible fix for #333213
On Sat, 2006-03-04 at 19:03 +0800, simon.zheng wrote: Hi Jeffrey and all, On Fri, 2006-03-03 at 10:00 -0500, Jeffrey Stedfast wrote: The patch is bad because callers of e_iconv() expect errno to be set on -1 and your patch breaks that guarantee. Yeah, you're right.:) Instead of changing e_iconv(), can we do more checking when invoking e_iconv()? I would really appreciate seeing the section on iconv in the POSIX.1 specification explaining what is meant and entailed by irreversable conversion and also whether this count is maintained thru multiple calls to iconv() or not[1]. Post the lastest POSIX.1 specification. http://www.opengroup.org/onlinepubs/009695399/functions/iconv.html non-identical conversation should be more exact term. It means a character in the input buffer that is valid, but for which an identical character does not exist in the target codeset. And the return value is only related to the last call to iconv(). So I think it's necessary to add more checking for return value, i.e. -1 and positive value both mean some problems in conversation. Is that possible to change like below? if ((status == (size_t) -1) || status (size_t) 0) return -1; you don't need to cast (size_t) 0, but other than that - this type of fix would be more agreeable with me :) Jeff Thanks, -Simon that answered, yes, probably we should be checking that the count is not 0 in the composer code and possibly other places in evolution as well. 1. say, for example, I call iconv() and my outbuf isn't large enough - some conversion has still occured and it has possibly already made some irreversable conversions but since iconv() will return -1, how do I know? After making my nth call to iconv() finishing the conversion of all the data, will the return code of iconv() be the cumulative count of irreversable conversions? or only that of my last call to iconv()? On Fri, 2006-03-03 at 12:13 +0800, simon.zheng wrote: Hi, Bug 333213 – Can't specify the encoding as ISO-8859-15 in mail composer on Solaris. http://bugzilla.gnome.org/show_bug.cgi?id=333213 Attached a patch for review. Changing wrapper for iconv(). Translate non-zero value returned by iconv() to -1. Thanks, -Simon ___ Evolution-patches mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/evolution-patches -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. [EMAIL PROTECTED] - www.novell.com ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
