commit 305cbdb6c0e4c822b8755442b9d286eebf88c44b
Author: Matthew Barnes <mbarnes@redhat.com>
Date: Sun Jun 17 18:50:44 2012 -0400
NEWS update for 3.4.2 release.
NEWS | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
commit b237ef7173eb1905e430bb1c436e1250251af189
Author: Jordi Mallach <jordi@debian.org>
Date: Sun Jun 17 18:53:18 2012 +0200
Bug #678255 - edata-cal missing libebackend-1.2 requirement.
(cherry picked from commit 01110e0ec95d51e36b8569cb621babc5a54b366f)
calendar/libedata-cal/libedata-cal.pc.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
commit 8825c22d1d2657924efdd0f4a1e1db5d169ed81b
Author: Milan Crha <mcrha@redhat.com>
Date: Fri Jun 15 16:26:44 2012 +0200
Bug #674454 - Crash in e_book_backend_ldap_authenticate_user()
addressbook/backends/ldap/e-book-backend-ldap.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
commit d3eeb57252c130d9a4909d02d522eb83a94d8688
Author: Milan Crha <mcrha@redhat.com>
Date: Fri Jun 15 15:25:08 2012 +0200
Bug #678069 - Crash in _gdata_entry_update_from_e_contact()
.../backends/google/e-book-backend-google.c | 63 ++++++++++++++++----
1 file changed, 50 insertions(+), 13 deletions(-)
commit 37b906729e635174d0c8ba6ef369cb5d5534bea0
Author: Nilamdyuti Goswami <nilamdyuti@gmail.com>
Date: Thu Jun 14 18:59:09 2012 +0530
Assamese translation reviewed
po/as.po | 953 ++++++++++++++++++++++++++++++--------------------------------
1 file changed, 458 insertions(+), 495 deletions(-)
commit 44ca306be758390421eccafbc6158ef389ef8631
Author: Nilamdyuti Goswami <nilamdyuti@gmail.com>
Date: Thu Jun 14 18:55:22 2012 +0530
Assamese translation reviewed
po/as.po | 960 +++++++++++++++++++++++++++++++-------------------------------
1 file changed, 480 insertions(+), 480 deletions(-)
commit be57410db84211ddf94a02dc1cf0eb506a5d6190
Author: Milan Crha <mcrha@redhat.com>
Date: Wed Jun 13 12:18:38 2012 +0200
Disable cfs_try_release_memory() in dispose, rather than finalize
camel/camel-folder-summary.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
commit fb2c8a0929c0d25410fb4e1435120fb3cc15cab9
Author: Milan Crha <mcrha@redhat.com>
Date: Tue Jun 12 18:58:42 2012 +0200
Bug #677841 - Workaround for crash in imapx_command_append_message_done()
camel/providers/imapx/camel-imapx-server.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
commit 777c4879e65ed558dcb46c48fdeb9027dd5bf556
Author: Milan Crha <mcrha@redhat.com>
Date: Tue Jun 12 11:29:09 2012 +0200
Bug #668247 - Broken non-basic-latin folder name handling
camel/camel-utf8.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
commit b2dde29dcfae77e7f2a283cae1eb157afdf763e6
Author: Milan Crha <mcrha@redhat.com>
Date: Mon Jun 11 22:05:26 2012 +0200
Backport IMAPx changes for bug #664639 from master
camel/providers/imapx/camel-imapx-conn-manager.c | 22 ++++++++++++++++++++--
camel/providers/imapx/camel-imapx-server.c | 4 +---
2 files changed, 21 insertions(+), 5 deletions(-)
commit 0d1aa9243998c9cb40b9f47a89fc8e61f85917fd
Author: Milan Crha <mcrha@redhat.com>
Date: Thu Jun 7 13:14:57 2012 +0200
Bug #677183 - maildir account doesn't open
camel/camel-settings.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
commit 74c7636d14005d4cac3bc714274057544f0f60c7
Author: Milan Crha <mcrha@redhat.com>
Date: Wed Jun 6 11:16:46 2012 +0200
Avoid possible GError memory leak
camel/camel-folder-summary.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
commit 4f3651c3d77f5f4e806291f366db2850912d0b7a
Author: Milan Crha <mcrha@redhat.com>
Date: Mon Jun 4 14:10:48 2012 +0200
Bug #673817 - Crash in e_book_backend_file_dispose()
addressbook/backends/file/e-book-backend-file.c | 69 ++++++++++++++---------
1 file changed, 42 insertions(+), 27 deletions(-)
commit ee07222891be4274492b94bc5548d81c58993853
Author: Milan Crha <mcrha@redhat.com>
Date: Thu May 31 11:49:34 2012 +0200
Bug #673946 - Cannot delete search folders
camel/camel-provider.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
commit f86152ced36d6d28a6d86c01da40000cbbaee5cf
Author: David Woodhouse <David.Woodhouse@intel.com>
Date: Mon May 21 16:45:56 2012 +0100
Bug 667725 - imapx_untagged: code should not be reached
This code is evil.
When we scan a folder for new messages, we issue a 'FETCH 1:* (UID FLAGS)'
or similar command.
When we receive an untagged FETCH from the server telling us flags for a
message, we make a decision about whether that information was solicited
by such a command, or whether it was unsolicited.
If it was unsolicited, we process it normally as an asynchronous flags
update and all is well.
If it was solicited, we add the UID to a list. When the FETCH (UID FLAGS)
command *completes*, we'll sort that list and then fetch the full headers
for each message.
However, we weren't very good at telling when an update was solicited.
Assuming that only solicited messages will have a UID is bogus.
This was failing if an unsolicited update came in when the (UID FLAGS)
fetch had completed, and we were already fetching the message headers.
The "new" UID would be added to the end of the list, even if we were
already fetching that message or if we already had it in cache. We'd
issue a FETCH command for it, and the barf when the server complied,
because when the UID list wasn't sorted we wouldn't find the offending
uid when we looked for it.
The simple "fix" for this is to keep a boolean flag 'scan_changes' which
is TRUE only when that FETCH (UID FLAGS) command is running. If a flags
change comes in at any other time, it is definitely unsolicited and
should *not* be added to the uidset. This at least protects us from
having UIDs added after we've sorted the list and started to do other
things with it, which was causing the crash.
In fact, this whole 'solicited' vs. 'unsolicited' thing is a design
mistake. In imapx_untagged() we should never care about what we asked
for and what we didn't. That's why the responses are *untagged*. The
server tells us things about the state of the mailboxes, and we should
process that information into our own local cache — it shouldn't
*matter* what we asked for. But that's a more intrusive fix for another day.
In addition, we were reliably *triggering* this behaviour in some cases
because we had to issue a SELECT for the folder in question before
issuing the FETCH (UID FLAGS) command. And on completion of the SELECT,
if UIDNEXT had increased, we were automatically issuing a *new* FETCH
(UID FLAGS) command starting from the last-known-uid in our cache. This
was entirely gratiutous, so use the same scan_changes boolean flag to
avoid it in that situation.
(cherry picked from commit 17f3fa1b12faa89158458d976c110cc9f8733a56)
camel/providers/imapx/camel-imapx-server.c | 42 ++++++++++++++++++++++++----
1 file changed, 36 insertions(+), 6 deletions(-)
commit 3eab064e9e503567c0053fcf8e268d211451c79e
Author: David Woodhouse <David.Woodhouse@intel.com>
Date: Mon May 21 16:42:26 2012 +0100
Fix off-by-one in uidset handling for fetches
When we get to the end of the for() loop processing the uidset, the index
variable is one *more* than the last item. That's how for() loops in C
work.
But when we break out of the middle because we are limiting the batch
size, we were forgetting to do the same and we were storing the index
of the last item that we'd already fetched.
This was causing us to re-fetch the last message of one batch, as the
first message of the next batch. Mostly harmless, but spotted and fixed
as part of bug 667725.
(cherry picked from commit 7dd91af4568d1247e32e33319a875c274d6c7ca5)
camel/providers/imapx/camel-imapx-server.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
commit 8dbcc6452f72984ff4403407174712144fb766e9
Author: David Woodhouse <David.Woodhouse@intel.com>
Date: Mon May 21 16:22:36 2012 +0100
Bug 676506 - imapx: After QRESYNC leaves us out of sync, a "full resync" doesn't work either.
Always fetch from the beginning of the folder.
(cherry picked from commit e689ff03dfa4d23722d14bdfd93103a91e4cd7e5)
camel/providers/imapx/camel-imapx-server.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
commit 5186c995c06fb3398688de3518d899dc149f73b8
Author: David Woodhouse <David.Woodhouse@intel.com>
Date: Sun May 20 00:40:53 2012 +0100
Bug 676403 - imapx: Syncing folder after server-side deletion of many messages is *very* slow
Fix this by introducing a new camel_folder_change_info_remove_uids()
function, and using it for the 'vanished' code. This reduces the time taken
from about 40ms per message, to about 50µs.
(cherry picked from commit 23a77e1d521c34e04121395ffe5df9a567c22e77)
camel/camel-folder-summary.c | 48 ++++++++++++++++++++++++++++
camel/camel-folder-summary.h | 2 ++
camel/providers/imapx/camel-imapx-server.c | 24 ++++++++++++--
3 files changed, 72 insertions(+), 2 deletions(-)
commit 6fe2278f6dc8105ff128166ef232498ad8ab5f8d
Author: Antoine Jacoutot <ajacoutot@gnome.org>
Date: Sun May 20 20:28:44 2012 -0400
Bug 676108 - OpenBSD needs _XOPEN_SOURCE_EXTENDED for strptime(3)
strptime(3) was introduced in XPG4. On OpenBSD, just defining
_XOPEN_SOURCE gets you the older XPG3 which doesn't include strptime(3),
so we need to define _XOPEN_SOURCE_EXTENDED to get XPG4v2.
(cherry picked from commit 2236bc3631b8f8c4995dabf65d27cdc39c7493f9)
libedataserver/e-time-utils.c | 1 +
1 file changed, 1 insertion(+)
commit 057cc27efec4f7e719ee8e1cc1e20481548bd8ff
Author: Milan Crha <mcrha@redhat.com>
Date: Thu May 17 14:37:46 2012 +0200
Use locks in factory's weak object notify callback on data-book/cal
addressbook/libedata-book/e-data-book-factory.c | 6 ++++++
calendar/libedata-cal/e-data-cal-factory.c | 6 ++++++
2 files changed, 12 insertions(+)
commit 02898f33d846a9860efd2a2c6c54e00df2ef4aad
Author: Milan Crha <mcrha@redhat.com>
Date: Tue May 15 13:44:41 2012 +0200
Bug #671603 - Birthday calendar broken since 3.3.4
.../backends/contacts/e-cal-backend-contacts.c | 96 +++++++++++++-------
1 file changed, 62 insertions(+), 34 deletions(-)
commit 0d73790d2a19c87c1cabf536ea5a94e05da0eb9c
Author: Chenthill Palanisamy <pchenthill@novell.com>
Date: Mon May 14 11:33:55 2012 +0530
post release version bump
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)