Re: [Evolution-hackers] New implementation of camel_imap_folder_fetch_data
So, after the lock fixes and a few other bugfixes, this is a new
implementation.
I left the partial-retrieval thingy in place. Just remove the "full"
parameter from the function and comment the else part of the "if (full)
{ } else { }" thingy to use it in a normal Camel.
static void
handle_freeup (CamelImapStore *store, gint nread, CamelException *ex)
{
if (nread <= 0)
{
if (errno == EINTR)
camel_exception_set (ex, CAMEL_EXCEPTION_USER_CANCEL,
_("Operation cancelled"));
else
camel_exception_setv (ex,
CAMEL_EXCEPTION_SERVICE_UNAVAILABLE,
_("Server unexpectedly
disconnected: %s"),
g_strerror (errno));
camel_service_disconnect (CAMEL_SERVICE (store), FALSE, NULL);
}
}
CamelStream *
camel_imap_folder_fetch_data (CamelImapFolder *imap_folder, const char *uid,
const char *section_text, gboolean cache_only,
gboolean full, CamelException *ex)
{
CamelFolder *folder = CAMEL_FOLDER (imap_folder);
CamelImapStore *store = CAMEL_IMAP_STORE (folder->parent_store);
CamelStream *stream;
/* EXPUNGE responses have to modify the cache, which means
* they have to grab the cache_lock while holding the
* connect_lock.
* Because getting the service lock may cause MUCH unecessary
* delay when we already have the data locally, we do the
* locking separately. This could cause a race
* getting the same data from the cache, but that is only
* an inefficiency, and bad luck.
*/
CAMEL_IMAP_FOLDER_REC_LOCK (imap_folder, cache_lock);
stream = camel_imap_message_cache_get (imap_folder->cache, uid,
section_text, ex);
/* TNY TODO: if (full) Detect retrieval status (if partial refetch) */
if (!stream && (!strcmp (section_text, "HEADER") || !strcmp
(section_text, "0")))
{
camel_exception_clear (ex);
stream = camel_imap_message_cache_get (imap_folder->cache, uid,
"", ex);
}
CAMEL_IMAP_FOLDER_REC_UNLOCK (imap_folder, cache_lock);
if (stream || cache_only)
return stream;
camel_exception_clear(ex);
CAMEL_IMAP_FOLDER_REC_LOCK (imap_folder, cache_lock);
if (!camel_imap_store_connected(store, ex)) {
camel_exception_set (ex, CAMEL_EXCEPTION_SERVICE_UNAVAILABLE,
_("This message is not currently
available"));
CAMEL_IMAP_FOLDER_REC_UNLOCK (imap_folder, cache_lock);
return NULL;
}
camel_exception_clear (ex);
stream = camel_imap_message_cache_insert (imap_folder->cache,
uid, full?section_text:"", "", 0, NULL);
if (stream == NULL)
stream = camel_stream_mem_new ();
if (!stream)
goto errorhander;
if (full)
{
gboolean first = TRUE, err=FALSE;
gchar line[512];
guint linenum = 0;
ssize_t nread;
CamelStreamBuffer *server_stream = CAMEL_STREAM_BUFFER
(store->istream);
gchar *tag;
guint taglen;
gboolean isnextdone = FALSE;
if (store->server_level < IMAP_LEVEL_IMAP4REV1 && !*section_text)
camel_imap_command_start (store, folder, ex,
"UID FETCH %s RFC822.PEEK",uid);
else
camel_imap_command_start (store, folder, ex,
"UID FETCH %s BODY.PEEK[%s]",uid, section_text);
tag = g_strdup_printf ("%c%.5u", store->tag_prefix,
store->command-1);
taglen = strlen (tag);
store->command++;
while (nread = camel_stream_buffer_gets (server_stream, line, 512)
> 0)
{
/* It might be the line before the last line */
if (line[0] == ')' && (line[1] == '\n' || (line[1] == '\r'
&& line[2] == '\n')))
{
isnextdone = TRUE;
continue;
}
/* It's the first line */
if (linenum == 0 && (line [0] != '*' || line[1] != ' '))
{
err=TRUE;
break;
} else if (linenum == 0) { linenum++; continue; }
/* It's the last line */
if (!strncmp (line, tag, taglen))
break;
camel_seekable_stream_seek (CAMEL_SEEKABLE_STREAM (stream),
0, CAMEL_STREAM_END);
if (isnextdone)
{
Re: [Evolution-hackers] [Evolution] tips and tricks and questions and answers.
Andre : Thanks a lot for sharing these invaluable nuggets. You rock as always :-). I have added them to the project wiki at http://www.go-evolution.org/FAQ. I appeal to all contributors to use this page for consolidating their FAQ inputs and help in making this the de facto reference point for Evolution users regarding such queries. Thanks, Harish On Wed, 2007-01-03 at 13:44 +0100, Andre Klapper wrote: > hi folks, > > looks like i'm currently a bit disappointed by the company that still > provides the software for my open enterprise(tm) (and no, it is not a > problem of time). > time to free some of the few written bits of knowledge&work that > would otherwise rot on my harddisk. > > attached you will find a file that includes a collection of evo related > questions that have been asked more often or that have been very > interesting, and of course their more or less complete answers. > no guarantee for anything included, but a "copy, paste, redistribute, > change as you like" licensee. > i sometimes used this to answer mailing lists user questions, hope it's > useful to somebody. > > "welp, so long crew" here, > andre > > plain text document attachment (evolution-FAQE), "tips and tricks and > questions and answers." > = Mail = > Questions regarding the mailer and composer, for example junk mail, > encryption or spell checking. > Please note that desktop integration issues (for example setting the > preferred browser and launching evolution from a browser) are part of the > interoperability section. > > == General == > === I cannot see some emails, but they must be there. === > Some possible reasons: > * You use filters on incoming (or outgoing) messages that move your messages > automatically to another destination. If you have enabled junk filtering, > also take a look into the junk folder. > * Check your search view in the search bar right above the message list, > perhaps you have any value in it? > * Just to be sure: Click "Edit | Show Hidden Messages". > * Take a look into Evolution's Junk folder. Messages that are marked as Junk > disappear from the original folder and are only displayed in the Junk folder. > * Check your default folder under "Edit | Preferences | Email Accounts | Edit > | Defaults". Perhaps it is set to some other folder then the folder you > thought of. > If this specially refers to an IMAP account and you upgraded Evolution to > version 2.4, and you are using a Cyrus IMAP server, then try to change your > account settings to "Show subscribed mails only". Then use "Folder | > Subscriptions" to subscribe to your Inbox and any other folder. You might > need to restart Evolution in between. This bug is fixed was Evolution 2.4.2.1 > and later. > > > === How i can update/refresh Search folders (formerly called "vFolders")? === > Refreshing a Search folder by a command is not possible (see > http://bugzilla.gnome.org/show_bug.cgi?id=257582). However, you should get an > updated view by going to another folder and then going back to your Search > folder. > > > === Why do my mail filters not work? === > Generally, be aware of the fact that the order of your filters is important. > If your very first filter has a "Stop processing" rule, all the other filters > will be ignored by the emails that match to this first filter rule. > If you want your filters to apply automatically and you are using an IMAP > account, make sure you have enabled "Apply filters to new messages in INBOX > on this server" under "Edit | Preferences | Email Accounts | Edit | Receiving > Options | Options". > Also, filters depend on the "new" flag which will be set only when a > particular mail is fetched from server for the first time. If any other mail > client is used to check mail before Evolution, Evolution's filters may not > work. > > > === Why do I get the message "No provider available for protocol email."? === > This can happen if you have just installed Evolution on a new machine and > have copied the file named filters.xml, so your filter rules are suffering > from a version mismatch with Evolution. Since the filters refer to accounts > directly, and accounts all have a unique ID number, you get the above error > if it cannot find the account anymore, so you either have not copied the > account settings or they have been changed in the meantime. To fix it, edit > your filters and re-select the folder for each Copy/Move filter. > > > === How can I get informed of new mail arriving? === > Since Evolution 2.2, a panel notification applet via D-BUS exists. > Evolution itself is only able to play a sound file or to beep. Go to "Edit | > Preferences | Mail Preferences | General | New Mail Notification". > Note that esound must be running to be able to hear your sound file. > > > === Why does new junk mail automatically get marked as read? === > Good question - one can easily miss new messages which have been incorrectly > marked as junk. Workaround: Both for
Re: [Evolution-hackers] New implementation of camel_imap_folder_fetch_data
Ah, I figured it out. The camel_imap_command_start places the lock, and
the functions that are usually used with the results unlock it.
owk.
"* On success, the store's connect_lock will be locked. It will be freed
* when you call camel_imap_response_free. (The lock is recursive, so
* callers can grab and release it themselves if they need to run
* multiple commands atomically.) "
Easy == different
On Tue, 2007-01-09 at 03:47 +0100, Philip Van Hoof wrote:
> Bweachrgg. It seems camel_imap_command_response performs an extra
> CAMEL_SERVICE_REC_UNLOCK (store, connect_lock) (for some reason, I can't
> figure out why that it is like that, but ... ).
>
> And it looks that the code calling camel_imap_folder_fetch_data assumes
> that this unlock happens (at least at some obscure places).
>
> In other words: crazy code. Anyway, adding that extra unlock seems to
> fix it (the current implementation below caused some races here).
>
> Just add an extra CAMEL_SERVICE_REC_UNLOCK (store, connect_lock) before
> the returning of the stream and in the errorhandler label.
>
> b
>
> ps. The locking code of the imap provider is really, really broken or
> done in an absolutely insane way.
>
>
> On Tue, 2007-01-09 at 02:18 +0100, Philip Van Hoof wrote:
> > Hi there,
> >
> > I just finished this one, so there's probably a huge amount of bugs in
> > it. I know I should first debug them away before posting on mailing
> > lists ;). However, it would be nice if some (other) people would test
> > this reimplementation (it's a method in camel-imap-folder.c, by the
> > way).
> >
> > Just take a look at it, compare it with the memory consumption of
> > copying everything into a GData after first copying everything into a
> > GPtrArray of a CamelImapResponse structure (which is what the original
> > does).
> >
> > ps. the if (TRUE) {} thing is because in the version for tinymail,
> > there's support for partially retrieving messages. The else part
> > implements that support (feel free to take a look at tinymail's
> > camel-lite for the implementation, it's not a secret or something).
> >
> >
> > CamelStream *
> > camel_imap_folder_fetch_data (CamelImapFolder *imap_folder, const char *uid,
> > const char *section_text, gboolean cache_only,
> > CamelException *ex)
> > {
> > CamelFolder *folder = CAMEL_FOLDER (imap_folder);
> > CamelImapStore *store = CAMEL_IMAP_STORE (folder->parent_store);
> > CamelStream *stream;
> >
> > /* EXPUNGE responses have to modify the cache, which means
> > * they have to grab the cache_lock while holding the
> > * connect_lock.
> >
> > * Because getting the service lock may cause MUCH unecessary
> > * delay when we already have the data locally, we do the
> > * locking separately. This could cause a race
> > * getting the same data from the cache, but that is only
> > * an inefficiency, and bad luck.
> > */
> >
> > CAMEL_IMAP_FOLDER_REC_LOCK (imap_folder, cache_lock);
> > stream = camel_imap_message_cache_get (imap_folder->cache, uid,
> > section_text, ex);
> >
> > /* TNY TODO: if (full) Detect retrieval status (if partial refetch) */
> >
> > if (!stream && (!strcmp (section_text, "HEADER") || !strcmp
> > (section_text, "0")))
> > {
> > camel_exception_clear (ex);
> > stream = camel_imap_message_cache_get (imap_folder->cache, uid,
> > "", ex);
> > }
> > CAMEL_IMAP_FOLDER_REC_UNLOCK (imap_folder, cache_lock);
> >
> > if (stream || cache_only)
> > return stream;
> >
> > camel_exception_clear(ex);
> >
> > CAMEL_SERVICE_REC_LOCK (store, connect_lock);
> > CAMEL_IMAP_FOLDER_REC_LOCK (imap_folder, cache_lock);
> >
> > if (!camel_imap_store_connected(store, ex)) {
> > camel_exception_set (ex, CAMEL_EXCEPTION_SERVICE_UNAVAILABLE,
> > _("This message is not currently
> > available"));
> > CAMEL_IMAP_FOLDER_REC_UNLOCK (imap_folder, cache_lock);
> > CAMEL_SERVICE_REC_UNLOCK (store, connect_lock);
> > return NULL;
> > }
> >
> > camel_exception_clear (ex);
> >
> > stream = camel_imap_message_cache_insert (imap_folder->cache,
> > uid, full?section_text:"", "", 0, NULL);
> > if (stream == NULL)
> > stream = camel_stream_mem_new ();
> >
> > if (!stream)
> > goto errorhander;
> >
> > if (TRUE)
> > {
> > gboolean first = TRUE;
> > gchar line[512];
> > guint linenum = 0;
> > ssize_t nread;
> > CamelStreamBuffer *server_stream = CAMEL_STREAM_BUFFER
> > (store->istream);
> > gchar *tag;
> > guint taglen;
> > gboolean isnextdone = FALSE;
> >
> > if (store->server_level < IMAP_LEVEL_IMAP4REV1 && !*section_text)
> > camel_imap_command_start (stor
Re: [Evolution-hackers] New implementation of camel_imap_folder_fetch_data
Bweachrgg. It seems camel_imap_command_response performs an extra
CAMEL_SERVICE_REC_UNLOCK (store, connect_lock) (for some reason, I can't
figure out why that it is like that, but ... ).
And it looks that the code calling camel_imap_folder_fetch_data assumes
that this unlock happens (at least at some obscure places).
In other words: crazy code. Anyway, adding that extra unlock seems to
fix it (the current implementation below caused some races here).
Just add an extra CAMEL_SERVICE_REC_UNLOCK (store, connect_lock) before
the returning of the stream and in the errorhandler label.
b
ps. The locking code of the imap provider is really, really broken or
done in an absolutely insane way.
On Tue, 2007-01-09 at 02:18 +0100, Philip Van Hoof wrote:
> Hi there,
>
> I just finished this one, so there's probably a huge amount of bugs in
> it. I know I should first debug them away before posting on mailing
> lists ;). However, it would be nice if some (other) people would test
> this reimplementation (it's a method in camel-imap-folder.c, by the
> way).
>
> Just take a look at it, compare it with the memory consumption of
> copying everything into a GData after first copying everything into a
> GPtrArray of a CamelImapResponse structure (which is what the original
> does).
>
> ps. the if (TRUE) {} thing is because in the version for tinymail,
> there's support for partially retrieving messages. The else part
> implements that support (feel free to take a look at tinymail's
> camel-lite for the implementation, it's not a secret or something).
>
>
> CamelStream *
> camel_imap_folder_fetch_data (CamelImapFolder *imap_folder, const char *uid,
> const char *section_text, gboolean cache_only,
> CamelException *ex)
> {
> CamelFolder *folder = CAMEL_FOLDER (imap_folder);
> CamelImapStore *store = CAMEL_IMAP_STORE (folder->parent_store);
> CamelStream *stream;
>
> /* EXPUNGE responses have to modify the cache, which means
>* they have to grab the cache_lock while holding the
>* connect_lock.
>
>* Because getting the service lock may cause MUCH unecessary
>* delay when we already have the data locally, we do the
>* locking separately. This could cause a race
>* getting the same data from the cache, but that is only
>* an inefficiency, and bad luck.
>*/
>
> CAMEL_IMAP_FOLDER_REC_LOCK (imap_folder, cache_lock);
> stream = camel_imap_message_cache_get (imap_folder->cache, uid,
> section_text, ex);
>
> /* TNY TODO: if (full) Detect retrieval status (if partial refetch) */
>
> if (!stream && (!strcmp (section_text, "HEADER") || !strcmp
> (section_text, "0")))
> {
> camel_exception_clear (ex);
> stream = camel_imap_message_cache_get (imap_folder->cache, uid,
> "", ex);
> }
> CAMEL_IMAP_FOLDER_REC_UNLOCK (imap_folder, cache_lock);
>
> if (stream || cache_only)
> return stream;
>
> camel_exception_clear(ex);
>
> CAMEL_SERVICE_REC_LOCK (store, connect_lock);
> CAMEL_IMAP_FOLDER_REC_LOCK (imap_folder, cache_lock);
>
> if (!camel_imap_store_connected(store, ex)) {
> camel_exception_set (ex, CAMEL_EXCEPTION_SERVICE_UNAVAILABLE,
>_("This message is not currently
> available"));
> CAMEL_IMAP_FOLDER_REC_UNLOCK (imap_folder, cache_lock);
> CAMEL_SERVICE_REC_UNLOCK (store, connect_lock);
> return NULL;
> }
>
> camel_exception_clear (ex);
>
> stream = camel_imap_message_cache_insert (imap_folder->cache,
> uid, full?section_text:"", "", 0, NULL);
> if (stream == NULL)
> stream = camel_stream_mem_new ();
>
> if (!stream)
> goto errorhander;
>
> if (TRUE)
> {
> gboolean first = TRUE;
> gchar line[512];
> guint linenum = 0;
> ssize_t nread;
> CamelStreamBuffer *server_stream = CAMEL_STREAM_BUFFER
> (store->istream);
> gchar *tag;
> guint taglen;
> gboolean isnextdone = FALSE;
>
> if (store->server_level < IMAP_LEVEL_IMAP4REV1 && !*section_text)
> camel_imap_command_start (store, folder, ex,
> "UID FETCH %s RFC822.PEEK",uid);
> else
> camel_imap_command_start (store, folder, ex,
> "UID FETCH %s BODY.PEEK[%s]",uid, section_text);
>
> tag = g_strdup_printf ("%c%.5u", store->tag_prefix,
> store->command-1);
> taglen = strlen (tag);
> store->command++;
>
> while (nread = camel_stream_buffer_gets (server_stream, line, 512)
> > 0)
> {
>
> /* It might be the line before the last line */
> if
[Evolution-hackers] New implementation of camel_imap_folder_fetch_data
Hi there,
I just finished this one, so there's probably a huge amount of bugs in
it. I know I should first debug them away before posting on mailing
lists ;). However, it would be nice if some (other) people would test
this reimplementation (it's a method in camel-imap-folder.c, by the
way).
Just take a look at it, compare it with the memory consumption of
copying everything into a GData after first copying everything into a
GPtrArray of a CamelImapResponse structure (which is what the original
does).
ps. the if (TRUE) {} thing is because in the version for tinymail,
there's support for partially retrieving messages. The else part
implements that support (feel free to take a look at tinymail's
camel-lite for the implementation, it's not a secret or something).
CamelStream *
camel_imap_folder_fetch_data (CamelImapFolder *imap_folder, const char *uid,
const char *section_text, gboolean cache_only,
CamelException *ex)
{
CamelFolder *folder = CAMEL_FOLDER (imap_folder);
CamelImapStore *store = CAMEL_IMAP_STORE (folder->parent_store);
CamelStream *stream;
/* EXPUNGE responses have to modify the cache, which means
* they have to grab the cache_lock while holding the
* connect_lock.
* Because getting the service lock may cause MUCH unecessary
* delay when we already have the data locally, we do the
* locking separately. This could cause a race
* getting the same data from the cache, but that is only
* an inefficiency, and bad luck.
*/
CAMEL_IMAP_FOLDER_REC_LOCK (imap_folder, cache_lock);
stream = camel_imap_message_cache_get (imap_folder->cache, uid,
section_text, ex);
/* TNY TODO: if (full) Detect retrieval status (if partial refetch) */
if (!stream && (!strcmp (section_text, "HEADER") || !strcmp
(section_text, "0")))
{
camel_exception_clear (ex);
stream = camel_imap_message_cache_get (imap_folder->cache, uid,
"", ex);
}
CAMEL_IMAP_FOLDER_REC_UNLOCK (imap_folder, cache_lock);
if (stream || cache_only)
return stream;
camel_exception_clear(ex);
CAMEL_SERVICE_REC_LOCK (store, connect_lock);
CAMEL_IMAP_FOLDER_REC_LOCK (imap_folder, cache_lock);
if (!camel_imap_store_connected(store, ex)) {
camel_exception_set (ex, CAMEL_EXCEPTION_SERVICE_UNAVAILABLE,
_("This message is not currently
available"));
CAMEL_IMAP_FOLDER_REC_UNLOCK (imap_folder, cache_lock);
CAMEL_SERVICE_REC_UNLOCK (store, connect_lock);
return NULL;
}
camel_exception_clear (ex);
stream = camel_imap_message_cache_insert (imap_folder->cache,
uid, full?section_text:"", "", 0, NULL);
if (stream == NULL)
stream = camel_stream_mem_new ();
if (!stream)
goto errorhander;
if (TRUE)
{
gboolean first = TRUE;
gchar line[512];
guint linenum = 0;
ssize_t nread;
CamelStreamBuffer *server_stream = CAMEL_STREAM_BUFFER
(store->istream);
gchar *tag;
guint taglen;
gboolean isnextdone = FALSE;
if (store->server_level < IMAP_LEVEL_IMAP4REV1 && !*section_text)
camel_imap_command_start (store, folder, ex,
"UID FETCH %s RFC822.PEEK",uid);
else
camel_imap_command_start (store, folder, ex,
"UID FETCH %s BODY.PEEK[%s]",uid, section_text);
tag = g_strdup_printf ("%c%.5u", store->tag_prefix,
store->command-1);
taglen = strlen (tag);
store->command++;
while (nread = camel_stream_buffer_gets (server_stream, line, 512)
> 0)
{
/* It might be the line before the last line */
if (line[0] == ')' && (line[1] == '\n' || (line[1] == '\r'
&& line[2] == '\n')))
{
isnextdone = TRUE;
continue;
}
/* It's the first line */
if (linenum == 0 && (line [0] != '*' || line[1] != ' '))
{
g_free (tag);
goto errorhander;
} else if (linenum == 0) { linenum++; continue; }
/* It's the last line */
if (!strncmp (line, tag, taglen))
break;
camel_seekable_stream_seek (CAMEL_SEEKABLE_STREAM (stream),
0, CAMEL_STREAM_END);
if (isnextdone)
{
camel_stream
[Evolution-hackers] ANNOUNCE: Evolution 2.9.5 and Evolution-Data-Server 1.9.5 released (with GtkHTML 3.13.5 and Evolution-Exchange-2.9.5)
Hi All, The Evolution Team is pleased to announce the release of Evolution 2.9.5 You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.13/gtkhtml-3.13.5.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.9/evolution-data-server-1.9.5.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.9/evolution-2.9.5.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.9/evolution-exchange-2.9.5.tar.bz2 Upgrade Notes : Evolution 2.9.x is the unstable series of 2.10 development. What is New ? = Evolution: Updated Translations: Djihed Afifi (ar), Danilo Šegan (sr), David Lodge (en_GB), Kjartan Maraas (nb), Gintautas Miliauskas (lt), Jordi Mas (ca), Bernat Tallaferro (ca), Clytie Siddall (vi), Priit Laes (et) Contributors: Daniel Nylander (Updated translation for documentation) Veerapuram Varadhan (346728, 268412) Simon Zheng (352108) Nickolay V. Shmyrev (340165) Nathan Owens (389664) Jerry Yu (389664) Matthew Barnes (383027, 377511) Wang Xin (389966, 389961) Harish Krishnaswamy (382860) Evolution-data-server: Updated Translations: Francisco Javier F. Serrador (es), Djihed Afifi (ar), Kjartan Maraas (nb), Theppitak Karoonboonyanan (th), David Lodge (en_GB), Christophe Fergeau (fr), Clytie Siddall (vi) Bug Fixes: 362638, 387397, 387638 and other downstream fixes Contributors: Mathew Barnes, Veerapuram Varadhan, Chenthill Palaniswamy, Jeff Cai Evolution-exchange: Updated Translations: Francisco Javier F. Serrador (es), Djihed Afifi (ar), Theppitak Karoonboonyanan (th), Kjartan Maraas (nb), David Lodge (en_GB), Clytie Siddall (vi) Bug Fixes - 357660, 346728, 268412 - Second/final round of optimization Contributors: Veerapuram Varadhan and Matthew Barnes GtkHTML: Memory leak fixes by Chris Heath (360393) Reporting Bugs If you have problems with 2.9.5, please take the time to submit the bug using Bug Buddy or at http://bugzilla.gnome.org. Try to fill in as much detail as you can regarding the circumstances that lead to the problem. If you have a feature request, you can also file that at http://bugzilla.gnome.org/ don't be discouraged if you don't hear from us right away, we get hundreds of feature requests a year. You can also check if your bug has been reported before by using the search functionality of Bugzilla. More information is available at the project website http://www.gnome.org/projects/evolution and the project wiki : http://go-evolution.org/ Thanks, V. Varadhan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [test] Move along folks, nothing to see here.
guenther, I found out the reason... "RCPT TO
failed: Requested action not taken:
mailbox unavailable"
guenther, can you try sending a test mail?
--
char *t="[EMAIL PROTECTED]";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] ANNOUNCE: Evolution 2.9.5 and Evolution-Data-Server 1.9.5 released (with GtkHTML 3.13.5 and Evolution-Exchange-2.9.5)
Hi All, The Evolution Team is pleased to announce the release of Evolution 2.9.5 You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.13/gtkhtml-3.13.5.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.9/evolution-data-server-1.9.5.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.9/evolution-2.9.5.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.9/evolution-exchange-2.9.5.tar.bz2 Upgrade Notes : Evolution 2.9.x is the unstable series of 2.10 development. What is New ? = Evolution: Updated Translations: Djihed Afifi (ar), Danilo Šegan (sr), David Lodge (en_GB), Kjartan Maraas (nb), Gintautas Miliauskas (lt), Jordi Mas (ca), Bernat Tallaferro (ca), Clytie Siddall (vi), Priit Laes (et) Contributors: Daniel Nylander (Updated translation for documentation) Veerapuram Varadhan (346728, 268412) Simon Zheng (352108) Nickolay V. Shmyrev (340165) Nathan Owens (389664) Jerry Yu (389664) Matthew Barnes (383027, 377511) Wang Xin (389966, 389961) Harish Krishnaswamy (382860) Evolution-data-server: Updated Translations: Francisco Javier F. Serrador (es), Djihed Afifi (ar), Kjartan Maraas (nb), Theppitak Karoonboonyanan (th), David Lodge (en_GB), Christophe Fergeau (fr), Clytie Siddall (vi) Bug Fixes: 362638, 387397, 387638 and other downstream fixes Contributors: Mathew Barnes, Veerapuram Varadhan, Chenthill Palaniswamy, Jeff Cai Evolution-exchange: Updated Translations: Francisco Javier F. Serrador (es), Djihed Afifi (ar), Theppitak Karoonboonyanan (th), Kjartan Maraas (nb), David Lodge (en_GB), Clytie Siddall (vi) Bug Fixes - 357660, 346728, 268412 - Second/final round of optimization Contributors: Veerapuram Varadhan and Matthew Barnes GtkHTML: Memory leak fixes by Chris Heath (360393) Reporting Bugs If you have problems with 2.9.5, please take the time to submit the bug using Bug Buddy or at http://bugzilla.gnome.org. Try to fill in as much detail as you can regarding the circumstances that lead to the problem. If you have a feature request, you can also file that at http://bugzilla.gnome.org/ don't be discouraged if you don't hear from us right away, we get hundreds of feature requests a year. You can also check if your bug has been reported before by using the search functionality of Bugzilla. More information is available at the project website http://www.gnome.org/projects/evolution and the project wiki : http://go-evolution.org/ Thanks, V. Varadhan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [ANNOUNCE] Evolution 2.9.5 and Evolution-Data-Server 1.9.5 released (with GtkHTML 3.13.5 and Evolution-Exchange-2.9.5)
Hi All, The Evolution Team is pleased to announce the release of Evolution 2.9.5 You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.13/gtkhtml-3.13.5.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.9/evolution-data-server-1.9.5.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.9/evolution-2.9.5.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.9/evolution-exchange-2.9.5.tar.bz2 Upgrade Notes : Evolution 2.9.x is the unstable series of 2.10 development. What is New ? = Evolution: Updated Translations: Djihed Afifi (ar), Danilo Šegan (sr), David Lodge (en_GB), Kjartan Maraas (nb), Gintautas Miliauskas (lt), Jordi Mas (ca), Bernat Tallaferro (ca), Clytie Siddall (vi), Priit Laes (et) Contributors: Daniel Nylander (Updated translation for documentation) Veerapuram Varadhan (346728, 268412) Simon Zheng (352108) Nickolay V. Shmyrev (340165) Nathan Owens (389664) Jerry Yu (389664) Matthew Barnes (383027, 377511) Wang Xin (389966, 389961) Harish Krishnaswamy (382860) Evolution-data-server: Updated Translations: Francisco Javier F. Serrador (es), Djihed Afifi (ar), Kjartan Maraas (nb), Theppitak Karoonboonyanan (th), David Lodge (en_GB), Christophe Fergeau (fr), Clytie Siddall (vi) Bug Fixes: 362638, 387397, 387638 and other downstream fixes Contributors: Mathew Barnes, Veerapuram Varadhan, Chenthill Palaniswamy, Jeff Cai Evolution-exchange: Updated Translations: Francisco Javier F. Serrador (es), Djihed Afifi (ar), Theppitak Karoonboonyanan (th), Kjartan Maraas (nb), David Lodge (en_GB), Clytie Siddall (vi) Bug Fixes - 357660, 346728, 268412 - Second/final round of optimization Contributors: Veerapuram Varadhan and Matthew Barnes GtkHTML: Memory leak fixes by Chris Heath (360393) Reporting Bugs If you have problems with 2.9.5, please take the time to submit the bug using Bug Buddy or at http://bugzilla.gnome.org. Try to fill in as much detail as you can regarding the circumstances that lead to the problem. If you have a feature request, you can also file that at http://bugzilla.gnome.org/ don't be discouraged if you don't hear from us right away, we get hundreds of feature requests a year. You can also check if your bug has been reported before by using the search functionality of Bugzilla. More information is available at the project website http://www.gnome.org/projects/evolution and the project wiki : http://go-evolution.org/ Thanks, V. Varadhan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [ANNOUNCE] Evolution 2.9.5 and Evolution-Data-Server 1.9.5 released (with GtkHTML 3.13.5 and Evolution-Exchange-2.9.5)
Hi All, The Evolution Team is pleased to announce the release of Evolution 2.9.5 You can download the following : http://ftp.acc.umu.se/pub/gnome/sources/gtkhtml/3.13/gtkhtml-3.13.5.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-data-server/1.9/evolution-data-server-1.9.5.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution/2.9/evolution-2.9.5.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/evolution-exchange/2.9/evolution-exchange-2.9.5.tar.bz2 Upgrade Notes : Evolution 2.9.x is the unstable series of 2.10 development. What is New ? = Evolution: Updated Translations: Djihed Afifi (ar), Danilo Šegan (sr), David Lodge (en_GB), Kjartan Maraas (nb), Gintautas Miliauskas (lt), Jordi Mas (ca), Bernat Tallaferro (ca), Clytie Siddall (vi), Priit Laes (et) Contributors: Daniel Nylander (Updated translation for documentation) Veerapuram Varadhan (346728, 268412) Simon Zheng (352108) Nickolay V. Shmyrev (340165) Nathan Owens (389664) Jerry Yu (389664) Matthew Barnes (383027, 377511) Wang Xin (389966, 389961) Harish Krishnaswamy (382860) Evolution-data-server: Updated Translations: Francisco Javier F. Serrador (es), Djihed Afifi (ar), Kjartan Maraas (nb), Theppitak Karoonboonyanan (th), David Lodge (en_GB), Christophe Fergeau (fr), Clytie Siddall (vi) Bug Fixes: 362638, 387397, 387638 and other downstream fixes Contributors: Mathew Barnes, Veerapuram Varadhan, Chenthill Palaniswamy, Jeff Cai Evolution-exchange: Updated Translations: Francisco Javier F. Serrador (es), Djihed Afifi (ar), Theppitak Karoonboonyanan (th), Kjartan Maraas (nb), David Lodge (en_GB), Clytie Siddall (vi) Bug Fixes - 357660, 346728, 268412 - Second/final round of optimization Contributors: Veerapuram Varadhan and Matthew Barnes GtkHTML: Memory leak fixes by Chris Heath (360393) Reporting Bugs If you have problems with 2.9.5, please take the time to submit the bug using Bug Buddy or at http://bugzilla.gnome.org. Try to fill in as much detail as you can regarding the circumstances that lead to the problem. If you have a feature request, you can also file that at http://bugzilla.gnome.org/ don't be discouraged if you don't hear from us right away, we get hundreds of feature requests a year. You can also check if your bug has been reported before by using the search functionality of Bugzilla. More information is available at the project website http://www.gnome.org/projects/evolution and the project wiki : http://go-evolution.org/ Thanks, V. Varadhan ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
