Re: [Evolution-hackers] Evolution: Taking forward...

2008-10-13 Thread Mikhail Zabaluev
Hash: SHA1


Srinivasa Ragavan wrote:
 Hello guys,
 We have had a set of problems that we are carrying around for some time like :
   * Copyright assignments, which is not the best way looking for the 
 future of Evolution. It sucks and sort of limits contributions to Evolution 
 and we wanted to drop it.
   * The current licensing incompatibility issues of Evolution with 
 Samba4/libmapi (GPLv3). Evolution needs to link with libmapi/samba4 for the 
 new mapi based connector being developed for Exchange 2007.
 So here is the plan :
   * Drop Evolution copyright assignments and make it really easy to 
 contribute to Evolution
   * Move Evolution licensing to  LGPL v2 and LGPL v3 to let us re-use 
 the code more easily around the platform.  This also moves us closer to 
 Thunderbird's MPL/LGPL model. 
 We think this is good for Evolution and (of course) we continue to invest in 
 Evolution. We are also working to ensure we have the rights to re-license all 
 of the code. We will do the licensing/header changes as we audit the code 
 ownership situation.
 It would be really helpful if you can post a public/explicit mail with 
 permissions to do it, or code pointers - if you think you wrote a piece of 
 Evolution code  object.

You're free to convert the license to my Bogofilter plugin code, as well
as any other patches I've committed to Evolution, to LGPL v2 or v3.
I appreciate your efforts.

Mikhail Zabaluev
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla -

Evolution-hackers mailing list

Re: [Evolution-hackers] strtok camel from evolution-data-server

2006-07-06 Thread Mikhail Zabaluev
В Чтв, 06/07/2006 в 21:23 +0200, Philip Van Hoof пишет:
 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.

I don't see a problem; you can always split the e-d-s install into
several packages. For RPM this is just about trivial (mind your
dependencies though), and I believe it's the same for deb.
I do such splits, e.g. when individual libraries or plugins in the
installation list have outstanding dependencies.

 Hacks like packaging tricks:
 I AM NOT going to require packaging tricks. Packaging tricks are hacks.

Packaging is a normal practice as long as you do it correctly.

Evolution-hackers mailing list

[Evolution-hackers] Bogofilter plugin 0.2.0

2006-05-30 Thread Mikhail Zabaluev

After much slacking off, I've made available a new release of the
Bogofilter junk plugin for Evolution:

New in this release:
- Updated the configure script to Evolution 2.6
- Fixed the plugin configuration to substitute the plugin directory
location obtained from Evolution's pkgconfig file.


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.
Evolution-hackers mailing list

Re: [Evolution-hackers] building evolution-data-server against the already installed libdb

2006-03-05 Thread Mikhail Zabaluev
В Пнд, 27/02/2006 в 17:49 -0500, Mikhail Teterin пишет:
 I'm trying to convince the maintainers of the evolution-data-server
 FreeBSD port (
 to build the software against the db4-version installed by the separate
 port of SleepyCat's db4 (
 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, 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?

I used to compile e-d-s 1.4 along an external db4.3, by applying a
simple patch. It didn't seem to cause any problems.
So, what's the purpose of bundling an obsolete version of Berkeley DB
inside the project?
Evolution-hackers mailing list

[Evolution-hackers] Bogofilter junk plugin patch

2005-12-20 Thread Mikhail Zabaluev

I've massaged my Bogofilter junk plugin into a patch for inclusion in
the Evolution source tree, attached below.
The plugin is included in the experimental list.
RCS file: /cvs/gnome/evolution/,v
retrieving revision 1.864
diff -u -r1.864
---	19 Dec 2005 11:23:08 -	1.864
+++	19 Dec 2005 12:44:52 -
@@ -101,6 +101,7 @@
@@ -109,6 +110,7 @@
@@ -1403,8 +1405,8 @@
 plugins_experimental_always=backup-restore folder-unsubscribe mail-to-meeting mail-remote prefer-plain save-attachments
-plugins_experimental=$plugins_experimental $IPOD_SYNC
-all_plugins_experimental=$plugins_experimental_always ipod-sync
+plugins_experimental=$plugins_experimental $IPOD_SYNC $BF_JUNK_PLUGIN
+all_plugins_experimental=$plugins_experimental_always bf-junk-plugin ipod-sync
 case x$enable_plugins in
@@ -1701,6 +1703,7 @@
Index: po/
RCS file: /cvs/gnome/evolution/po/,v
retrieving revision 1.291
diff -u -r1.291
--- po/	18 Dec 2005 12:31:19 -	1.291
+++ po/	19 Dec 2005 12:44:56 -
@@ -274,6 +274,7 @@
Index: plugins/bf-junk-plugin/ChangeLog
RCS file: plugins/bf-junk-plugin/ChangeLog
diff -N plugins/bf-junk-plugin/ChangeLog
--- /dev/null	1 Jan 1970 00:00:00 -
+++ plugins/bf-junk-plugin/ChangeLog	1 Jan 1970 00:00:00 -
@@ -0,0 +1,10 @@
+2005-12-18  Mikhail Zabaluev [EMAIL PROTECTED]
+*, org-gnome-bf-junk-plugin.eplug.xml:
+Adapted for inclusion in the Evolution source tree.
+2005-11-22  Mikhail Zabaluev [EMAIL PROTECTED]
+* README: Added reference to Spam Trainer.
+* README: Reflect on the fix for bug #313096 that made it to Evolution 2.5.2.
Index: plugins/bf-junk-plugin/
RCS file: plugins/bf-junk-plugin/
diff -N plugins/bf-junk-plugin/
--- /dev/null	1 Jan 1970 00:00:00 -
+++ plugins/bf-junk-plugin/	1 Jan 1970 00:00:00 -
@@ -0,0 +1,20 @@
+	-I$(top_srcdir)	\
+plugin_DATA = org-gnome-bf-junk-plugin.eplug
+liborg_gnome_bf_junk_plugin_la_SOURCES = bf-junk-filter.c
+liborg_gnome_bf_junk_plugin_la_LDFLAGS = -module -avoid-version $(NO_UNDEFINED)
+BUILT_SOURCES = $(plugin_DATA) $(error_DATA)
+	org-gnome-bf-junk-plugin.eplug.xml
Index: plugins/bf-junk-plugin/README
RCS file: plugins/bf-junk-plugin/README
diff -N plugins/bf-junk-plugin/README
--- /dev/null	1 Jan 1970 00:00:00 -
+++ plugins/bf-junk-plugin/README	1 Jan 1970 00:00:00 -
@@ -0,0 +1,34 @@
+Bogofilter plugin for Evolution
+This plugin implements junk filtering for the Evolution mailer,
+provided by the bogofilter utility. Bogofilter (
+if a fast and nimble mail filter using a so-called Bayesian technique to
+classify junk and non-junk email.
+For Evolution versions before 2.5.2, the definition file for the stock
+junk filter plugin, 'org-gnome-sa-junk-plugin.eplug', must be removed
+from the plugin directory to avoid conflict with any alternate junk plugin.
+Simply disabling the SA plugin in the configuration won't help.
+This is due to a flaw in the loading code for this hook type
+(see GNOME bug #313096).
+To be able to classify emails as spam, bogofilter needs to have some
+messages in its ham (non-spam) wordlist. This presents something of a
+chicken-and-egg problem for Evolution, because it can feed messages
+to the junk filter for learning as non-junk only after these messages have been
+classified as junk and moved into a junk folder. Thus, if you haven't got a

Re: [Evolution-hackers] Evolution and Evolution-Data-Server branched

2005-09-01 Thread Mikhail Zabaluev
В Чтв, 01/09/2005 в 15:16 +0530, Harish Krishnaswamy пишет: 
 On Thu, 2005-09-01 at 10:30 +0400, Mikhail Zabaluev wrote:
  В Срд, 31/08/2005 в 19:57 +0530, Harish Krishnaswamy пишет:
The gnome-2-12 branch for Evolution and Evolution-Data-Server has been
   created. This would be the stable branch for Evolution 2.4 and
   Evolution-Data-Server 1.4
  Will the IMAP code, broken since 2.3.6, be fixed back to shape?
 The much-talked-about IMAP issue reported in 2.3.6 had been fixed soon
 after it was reported and the Evolution (or more correctly, EDS was released with the fixes.

How come I can't access my IMAP folders (via SSH) in 2.3.8/1.3.8, with
the same effect as with 1.3.6: at startup, the IMAP account tree appears
collapsed. If I expand it, the retrieval freezes, and Evolution can't be
With 2.3.5/1.3.5, the account tree is initially expanded and mail
retrieval proceeds as normal.

 (And I hope we are both referring to IMAP not the IMAP4rev1 backend).


Evolution-hackers mailing list