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

[Mikhail Zabaluev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI8zUlITXggnds20gRAgkDAJ9NMGV46ezPc3HeRNEG4eT3aFi7MQCfTbAc
wqxFJaCD4NJU/szKbmyuASw=
=KaCA
-END PGP SIGNATURE-
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

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

[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@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Bogofilter plugin 0.2.0

[Mikhail Zabaluev]

Hello,

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

http://people.altlinux.ru/~mhz/software/projects/bf-eplugin/bf-eplugin-0.2.0.tar.gz

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.

Enjoy.

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
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] URGENT: Anyone knows why evolution is using both GNUTLS and NSS as security libraries

[Mikhail Zabaluev]

В Чтв, 23/03/2006 в 07:10 +0200, Tor Lillqvist пишет:
> ti 2006-03-21 klockan 23:33 +0800 skrev Irene Huang:
> 
> > I am confused why GNUTLS is a necesity when NSS is used for security
> > connection? 
> 
> Isn't it libsoup that uses gnutls? No idea why it doesn't use NSS (I
> assume they offer mostly the same functionality?)
> 
> > Can't it be removed? 
> 
> Hear, hear! Using NSS in libsoup would also be great for Win32
> portability, as I never managed to get the libsoup-over-gnutls working,
> so TLSified GroupWise connections don't work on Win32. (The problem was
> discovered only in December when I visited Bangalore.)

You may also consider the opposite: dropping NSS usage in Evolution in
favor of GnuTLS.
NSPR and NSS are notoriously tough libraries for distribution packaging:
every Gecko-based application insists on bundling them in its own
special version. Also, the license on GnuTLS is more favorable.

I believe NSS is necessary for S/MIME, not TLS.

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

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

[Mikhail Zabaluev]

В Пнд, 06/03/2006 в 09:25 +, Ross Burton пишет:
> 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.

Within a distribution, we can enforce dynamic DB linkage as we see fit.
So, I presume, it's safe to apply this patch in a package and save a bit
on memory footprint, plus get all the recent DB bug fixes.

Thank you, Ross, for clarifying the matter.

> 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.

I'll second that.


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

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

[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 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?

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@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Is it necessary to localize mail header date?

[Mikhail Zabaluev]

В Пнд, 02/01/2006 в 13:38 +0530, Parthasarathi Susarla пишет:
> > 
> > Evolution displays the header as below. Received name, subject, date
> > titles are localized, but content of Date is not. The date is only
> > output as orginal content in message source. I'm not sure if it is
> > necessary to localize it, especialy for Chinese, Japanese, Korean.
> > 
> IMHO No. Since mostly the date is field that comes from the server, and
> is a part of the RFC/822 message that comes in either in IMAP/POP. The
> only issue i see is with the time, should probably show local time,
> instead of the GMT, makes more sense that way.
> 
> Any other Ideas, anyone??

What I'd like is an option similar to that available in Outlook, where
you can specify that all in-text decoration of reply and forward
messages is done in English. Look at the first line of my message to see
why it can be useful.

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Bogofilter junk plugin patch

[Mikhail Zabaluev]

В Втр, 20/12/2005 в 10:57 -0500, Daniel Gryniewicz пишет:
> On Tue, 2005-12-20 at 15:29 +0300, Mikhail Zabaluev wrote:
> > 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.
> 
> Hi.
> 
> I have a very similar patch I've been using for a while.

Nice to hear from you. I dropped a few lines into your blog when I
discovered that we did parallel work :)

>   I would
> *highly* suggest using -u for the scan case, and -Ns and -Sn for the
> learn cases.  It makes a big difference in the learning ability.

I deemed this usage somewhat dangerous.
-u may silently reinforce false positives for an unsuspecting user.
It also writes every message's tokens into the database, so it is slower
and generates bloat.
I found no problems using bogofilter with the errors-only learning style
starting from a nearly empty wordlist, after correcting a few false
positives during the first week or so (to a total of 9 hams so far). My
database is mostly used read-only now.
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Bogofilter junk plugin patch

[Mikhail Zabaluev]

Hello,

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.
Index: configure.in
===
RCS file: /cvs/gnome/evolution/configure.in,v
retrieving revision 1.864
diff -u -r1.864 configure.in
--- configure.in	19 Dec 2005 11:23:08 -	1.864
+++ configure.in	19 Dec 2005 12:44:52 -
@@ -101,6 +101,7 @@
 NO_UNDEFINED='-no-undefined'
 SOEXT='.dll'
 SA_JUNK_PLUGIN=''
+BF_JUNK_PLUGIN=''
 DL_LIB=''
 SOFTOKN3_LIB=''
 HAL_REQUIREMENT=''
@@ -109,6 +110,7 @@
 NO_UNDEFINED=''
 SOEXT='.so'
 SA_JUNK_PLUGIN=sa-junk-plugin
+BF_JUNK_PLUGIN=bf-junk-plugin
 DL_LIB='-ldl'
 SOFTOKN3_LIB='-lsoftokn3'
 HAL_REQUIREMENT='hal'
@@ -1403,8 +1405,8 @@
 all_plugins_standard="$plugins_standard"
 
 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
 xno)
@@ -1701,6 +1703,7 @@
 plugins/groupwise-features/Makefile
 plugins/mail-account-disable/Makefile
 plugins/sa-junk-plugin/Makefile
+plugins/bf-junk-plugin/Makefile
 plugins/ipod-sync/Makefile
 plugins/publish-calendar/Makefile
 smime/Makefile
Index: po/POTFILES.in
===
RCS file: /cvs/gnome/evolution/po/POTFILES.in,v
retrieving revision 1.291
diff -u -r1.291 POTFILES.in
--- po/POTFILES.in	18 Dec 2005 12:31:19 -	1.291
+++ po/POTFILES.in	19 Dec 2005 12:44:56 -
@@ -274,6 +274,7 @@
 plugins/backup-restore/org-gnome-backup-restore.xml
 plugins/bbdb/bbdb.c
 plugins/bbdb/org-gnome-evolution-bbdb.eplug.xml
+plugins/bf-junk-plugin/org-gnome-bf-junk-plugin.eplug.xml
 plugins/calendar-file/org-gnome-calendar-file.eplug.xml
 plugins/calendar-http/calendar-http.c
 plugins/calendar-http/org-gnome-calendar-http.eplug.xml
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]>
+
+* Makefile.am, 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/Makefile.am
===
RCS file: plugins/bf-junk-plugin/Makefile.am
diff -N plugins/bf-junk-plugin/Makefile.am
--- /dev/null	1 Jan 1970 00:00:00 -
+++ plugins/bf-junk-plugin/Makefile.am	1 Jan 1970 00:00:00 -
@@ -0,0 +1,20 @@
+INCLUDES =		\
+	-I$(top_srcdir)	\
+	$(EVOLUTION_MAIL_CFLAGS)
+
[EMAIL PROTECTED]@
+
+plugin_DATA = org-gnome-bf-junk-plugin.eplug
+plugin_LTLIBRARIES = liborg-gnome-bf-junk-plugin.la
+
+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)
+
+CLEANFILES = $(BUILT_SOURCES)
+
+EXTRA_DIST = \
+	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 (http://www.bogofilter.org)
+if a fast and nimble mail filter using a so-called Bayesian technique to
+classify junk and non-junk email.
+
+CAVEATS:
+
+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 somet

[Evolution-hackers] Re: Bogofilter junk plugin

[Mikhail Zabaluev]

В Втр, 08/11/2005 в 11:32 +0530, Vivek Jain пишет:
> > http://people.altlinux.ru/~mhz/software/projects/bf-eplugin/bf-eplugin-0.1.0.tar.gz
> 
> > CAVEATS:
> > 
> > As of Evolution 2.4.0, 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 UI won't avail. This
> > is due to a flaw in the loading code for this hook type (see GNOME bug
> > #313096).
> > 
> This bug has been fixed now, it would be nice if its in the upstream
> (2.5) so that everybody can use it. Later we can consider it to be a
> default too.

You mean, if I could commit my plugin into the Evolution source tree?
I'd be delighted to, although I'll need to perform necessary makefile
adjustments to make it a subdirectory, sans the standalone configure
script.

As to making it the default. There are pros:
- fast and nimble, no monstrous pre-forked Perl daemon eating memory;
- very effective if trained well.

And cons:
- uses a single classification method -- no flexibility, no online
lookups;
- requires initial training to function properly.

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Re: [Evolution-hackers] Debugging IMAP, pointers needed

[Mikhail Zabaluev]

Hi,

В Втр, 20/09/2005 в 23:10 +0800, Not Zed пишет:
> You're telling it to use subscribed folders.
> 
> But ...
> 
> sending : A3 LSUB "" "*"
> received: A3 OK LSUB completed
> 
> You don't have any.

Right, thanks. I've subscribed to the Inbox after reading your reply. As
I did that, it appeared in the tree, sort of, but the Inbox folder icon
was plain and the "Loading..." placeholder was still there. Disabled the
account and enabled it back, now it's got Spam and Trash as well,
complete with appropriate icons, everything looks OK. So it works after
all, but not without wrinkles.
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

[Evolution-hackers] Debugging IMAP, pointers needed

[Mikhail Zabaluev]

Hello,

I'm going to investigate the IMAP bug that have been bothering me for a
while:
http://bugzilla.gnome.org/show_bug.cgi?id=315251

I need some starting points to look at in the debugger.
>From what can be seen in the logs, the client receives LIST and LSUB
responses, but nothing happens afterwards and the folder tree does not
become updated with IMAP folders. Maybe, there is nothing in the
responses to make tree items from (though INBOX is clearly listed), but
then something must be wrong with the requests. Any clues?
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

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

[Mikhail Zabaluev]

Hello,

В Птн, 02/09/2005 в 09:25 +0800, Not Zed пишет:
> So, whats the bug number of this bug report?

Well, it's bug #315251 now. Sorry for not using the proper channels in
the first place.

> > 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
> > closed.
> > With 2.3.5/1.3.5, the account tree is initially expanded and mail
> > retrieval proceeds as normal.

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

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

[Mikhail Zabaluev]

В Чтв, 01/09/2005 в 15:16 +0530, Harish Krishnaswamy пишет: 
> On Thu, 2005-09-01 at 10:30 +0400, Mikhail Zabaluev wrote:
> > Hello,
> > 
> > В Срд, 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 2.3.6.1 Evolution (or more correctly, EDS
> 1.3.6.1) 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
closed.
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).

Nope.

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers

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

[Mikhail Zabaluev]

Hello,

В Срд, 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?
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers