summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Do not expose password in imapx logEVOLUTION_DATA_SERVER_3_0_3Milan Crha2011-08-302-4/+12
|
* Bug #576398 - vfolder not showing new messages from nntp groupMilan Crha2011-08-231-1/+14
|
* Bug #562912 - Unread vfolder marks unread messages as readMilan Crha2011-08-233-92/+130
|
* Bug #652437 - NNTP messages is sometimes displayed as greyMilan Crha2011-08-221-0/+5
|
* Bug #651693 - Decode QP encoded names when invoking 'Expand list Inline'Ritesh Khadgaray2011-08-191-1/+38
|
* Updated Dutch translation by Wouter BolsterleeWouter Bolsterlee2011-08-181-240/+229
|
* Added UG translationAbduxukur Abdurixit2011-08-191-732/+749
|
* Bug #651469 - Folders don't update after moving mails in maildirMilan Crha2011-08-181-5/+26
|
* Bug 656490 - imapx: Memory leak of stream tokenbufDavid Woodhouse2011-08-141-0/+1
| | | | (cherry picked from commit 51ebadee128158e7d73dc8e29fd6e67ae229b7a0)
* Bug 656487 - Memory leak in imapx fetch_folders_for_namespaces()David Woodhouse2011-08-141-0/+1
| | | | | We need to free the GSList but the namespaces themselves are fine. (cherry picked from commit d707f577c0e23f11ecae37408477885c5b260d50)
* Bug #656480 - Memory leak in camel_folder_search_search()David Woodhouse2011-08-131-1/+4
| | | | | We don't unref sexp on failure. (cherry picked from commit 86f95492d12843611f9cbb7f8635604f4f251278)
* calendar file backend: fixed incomplete sanity check in ↵Patrick Ohly2011-08-121-1/+1
| | | | | | | | e_cal_create_object(), part II Cherry-picking from master lost one hunk for e_cal_backend_file_compute_changes_foreach_key(), causing compile errors. Here's the rest of the original patch for the gnome-2-32 branch.
* libecal: e_cal_remove_object() must remove *all* recurrencesPatrick Ohly2011-08-101-4/+5
| | | | | | | | | | | | | | | | | Traditionally, e_cal_remove_object() has always removed all recurrences, despite the use of MOD_THIS underneath. That was due to the uncertain semantic of MOD_THIS without rid. Since clarifying that semantic and fixing the (file) backend accordingly, e_cal_remove_object() started to behave differently: of an event series with detached recurrences, only the parent event was removed, which then caused the failures fixed by the previous commits. This commit fixes that by switching to MOD_ALL, which properly reflects the semantic of the API call. It was tested successfully with the file backend. (cherry picked from commit 272cb7d5ef42a0c1acb72fd3a0fba2bf53f959c8)
* calendar file backend: fixed incomplete sanity check in e_cal_create_object()Patrick Ohly2011-08-101-5/+7
| | | | | | | | | | | | | | e_cal_create_object() traditionally is used for a new events which are unrelated to anything in the calendar. Adding detached recurrences to an existing meeting series has to be done with e_cal_modify_object(). The code did not correctly reject the addition of a parent event for a previously added child event event because lookup_component() returned NULL in that case. This commit renames lookup_component() and redefines the return value to match what it is used for: checking for the existance of a UID. (cherry picked from commit 0c178bbab1008a8574d58c2019c22f892010d9a0)
* ecal file backend: avoid manipulating the UID inside component_add()Patrick Ohly2011-08-101-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes the following memory handling problem: ==10069== Invalid read of size 1 ==10069== at 0x4C25812: __GI_strlen (mc_replace_strmem.c:284) ==10069== by 0x8EF011E: g_strdup (gstrfuncs.c:99) ==10069== by 0xF4E08B6: e_cal_backend_file_create_object (e-cal-backend-file.c:2363) ==10069== by 0x93E6061: e_cal_backend_sync_create_object (e-cal-backend-sync.c:214) ==10069== by 0x93E86D3: _e_cal_backend_create_object (e-cal-backend-sync.c:630) ==10069== by 0x93DD40B: e_cal_backend_create_object (e-cal-backend.c:1017) ==10069== by 0x93F0C34: impl_Cal_createObject (e-data-cal.c:401) ==10069== by 0x4E75383: _e_gdbus_gdbus_cclosure_marshaller_BOOLEAN__OBJECT_STRING (e-gdbus-marshallers.c:377) ==10069== by 0x820999E: g_closure_invoke (gclosure.c:773) ==10069== by 0x8225972: signal_emit_unlocked_R (gsignal.c:3256) ==10069== by 0x82248D0: g_signal_emit_valist (gsignal.c:2997) ==10069== by 0x8224DBC: g_signal_emit (gsignal.c:3044) ==10069== Address 0x1499c7b0 is 0 bytes inside a block of size 39 free'd ==10069== at 0x4C240FD: free (vg_replace_malloc.c:366) ==10069== by 0x9DE952C: icalvalue_free (in /usr/lib/libical.so.0.44.0) ==10069== by 0x9DDB796: icalproperty_set_value (in /usr/lib/libical.so.0.44.0) ==10069== by 0x4E4FFA2: e_cal_component_set_uid (e-cal-component.c:1479) ==10069== by 0xF4DB8F3: check_dup_uid (e-cal-backend-file.c:498) ==10069== by 0xF4DBD9B: add_component (e-cal-backend-file.c:614) ==10069== by 0xF4E0894: e_cal_backend_file_create_object (e-cal-backend-file.c:2356) ==10069== by 0x93E6061: e_cal_backend_sync_create_object (e-cal-backend-sync.c:214) ==10069== by 0x93E86D3: _e_cal_backend_create_object (e-cal-backend-sync.c:630) ==10069== by 0x93DD40B: e_cal_backend_create_object (e-cal-backend.c:1017) ==10069== by 0x93F0C34: impl_Cal_createObject (e-data-cal.c:401) ==10069== by 0x4E75383: _e_gdbus_gdbus_cclosure_marshaller_BOOLEAN__OBJECT_STRING (e-gdbus-marshallers.c:377) This occurs when a client (incorrectly) tries to create a VEVENT with RECURRENCE-ID for a UID which already exists. The sequence of events is this: - e_cal_backend_file_create_object() calls lookup_component(), which returns NULL because it only checks for the parent event (will be fixed separately). - e_cal_backend_file_create_object() keeps a pointer to the UID. - check_dup_uid() repeats the UID check, but this time finds that it is already taken and replaces the existing UID in the component before adding it. The pointer in e_cal_backend_file_create_object() points to freed memory. I've seen cases where the hash ended up using the original UID as key, with a component inside that had the new, replaced UID. As a result, retrieving the event as reported by e_cal_get_object_list() (= rewritten UID) failed in e_cal_get_object() (= original UID). The UID should not be overwritten. I can't verify it anymore (events where it occured have already been deleted), but this rewriting might explain why some of my meeting update emails couldn't be applied to previously imported events. Therefore this patch moves check_dup_uid() out of component_add(). This check and rewriting only makes sense when reading the existing calendar file, as a safe-guard against on-disk corruption. When adding or modifying events via the API, the right reaction is to add a missing UID or or reject the operation with an error. All places where component_add() is used should have the necessary checks or are preceeded by a remove_component(), which removes the UID first. (cherry picked from commit ae4f4292b0e5ecbbdc74c90b75cc31367d0d270a)
* Bug #655748 - rdate parsing failure: unknown value for period 20068Milan Crha2011-08-032-10/+15
|
* Make e-{addressbook,calendar}-factory supersede old factory at startup.David Woodhouse2011-07-302-2/+6
| | | | | | | | | | | | | I've lost count of the number of times I've run a factory for debugging purposes but actually discovered that there's another one already running, so my new one isn't being used. It's particularly likely because when you *kill* an existing factory Evolution will bitch about how calendars will never work again until you restart Evolution... but it *will* restart the factory automatically! So make the new factory supersede an old one, and make the old one quit when it's superseded. This will make debugging a whole lot saner. (cherry picked from commit 8266e0918ff843af14913fb16723cc8b18000a8d)
* Fix stray unref of server in imapx add_folders_to_summary()David Woodhouse2011-07-281-3/+1
| | | | | | | | | This was causing a double (well, multiple) free and use-after-free of the server; it has no business here. It was actually seen when a broken Yahoo server gave a namespace with NIL for the dir_sep, thus causing problems with subfolders. (cherry picked from commit c3460e79201ba988500014386dbc3f8781dbc5f3)
* Added UG translationAbduxukur Abdurixit2011-07-071-738/+670
|
* Bug #653385 - ldaps fails with server using self-signed certificateMilan Crha2011-06-301-0/+4
|
* Updated Serbian translationМирослав Николић2011-06-242-5979/+7225
|
* Bug #648468 - POP3 doesn't recover or claim error after lost connectionMilan Crha2011-06-216-52/+76
|
* Bug #565961 - Crash with recurring all-day eventMilan Crha2011-06-151-5/+11
|
* Added UG translationAbduxukur Abdurixit2011-06-101-1200/+1344
|
* CamelVeeFolder: Check for the presence of unmatched folder beforeChenthill Palanisamy2011-06-071-1/+3
| | | | accessing full_name, error in previous commit.
* Bug 640054 - sqlite summary hang. Fix vfolder transactions.Chenthill Palanisamy2011-06-071-81/+118
|
* e-data-cal-view.c: fixed cherry-pick mistakePatrick Ohly2011-06-071-30/+8
| | | | | | | | | When cherry-picking from master branch, code using e_util_utf8_make_valid() was accidentally added to the gnome-3.0. That function is not available there because the corresponding bug fix in master has not been backported (was considered too complex). This patch removes e_util_utf8_make_valid() again.
* calendar: include rid in "objects-removed" ECalView signalPatrick Ohly2011-06-072-9/+49
| | | | | | | | | | | | | | | | | | | | Since migration to D-Bus for libecal<->EDS communication, the RECURRENCE-ID (rid) has not been sent in the "objects-removed" signal. As a result, a backend could not communicate the removal of specific recurrences. This patch adds the rid after a newline to the string stored internally and transferred via D-Bus. Because the newline is only added when needed, traditional uid-only removals look the same as before and continue to work with older versions of libecal. A uid+rid combination will look like an unknown uid to an older libecal which does not know how to split them. Therefore the D-Bus API is considered unchanged and the interface number is not increased. Whether clients really interpret "objects-removed" with empty rid (= parent removed) or valid rid (= child removed) correctly is outside the scope of this patch. (cherry picked from commit 768391222fe89cbcfc1eb38be9deb9ff201ac534)
* calendar file backend: support remove with CALOBJ_MOD_ONLY_THISPatrick Ohly2011-06-071-6/+28
| | | | | | | | | Support for this capability is easy: - report removal of the detached recurrence - report error when not found - avoid modifying the parent (= full_object) (Adapted from commit 17a86ec294883db631fee24285c2585dcb0b2098)
* calendar file backend: removal notification for detached recurrence, part 2Patrick Ohly2011-06-071-0/+11
| | | | | | | | | | | | e_cal_remove_object_with_mod() can only return one pair of old/new object pointers to the caller. When the function modifies the parent and removes a detached recurrence, the removal of the detached recurrence had to be deduced by clients from the modification of the parent. Now clients are explicitly informed about removal of the detached recurrence in addition to the modification of the parent. (cherry picked from commit 571b77cdfad1788a9320ec29449c1e6a26f0c70b)
* calendar file backend: removal notification for detached recurrence, part 1Patrick Ohly2011-06-071-19/+37
| | | | | | | | | | | | | | | If e_cal_remove_object_with_mod() was called for an appointment where only a detached recurrence existed, no "objects-removed" signal was triggered although it should have been. Apparently Evolution avoids the problem by calling e_cal_remove_component() instead in this case. Fixing the problem makes writing clients easier (no special cases). With this patch, remove_instance() itself decides what it reports back to the caller. Note that it cannot report back both a modification and a removal at the moment. (cherry picked from commit 88c1996b6626e884b68dc98a76272827bc8680a0)
* calendar file backend: white list check for supported CalObjModTypePatrick Ohly2011-06-071-0/+26
| | | | | | | Explicitly check that the CalObjModType is supported before starting to work on the appointment. Relies in libecal to reject completely bogus modes with an "invalid parameter" error. (cherry picked from commit bbe2d0a49089ee9f5522ce2749a009c730dd9079)
* libecal: catch invalid CalObjModType valuesPatrick Ohly2011-06-071-2/+19
| | | | | | | | | This protects backends without their own parameter checking from being invoked with invalid CalObjModType values. Note that this only excludes values that haven't been defined. Backends still need to check whether they support the selected mode. (cherry picked from commit e6eb665600248a28bccf268be70d5d3ffcdadb62)
* libecal: added CALOBJ_MOD_ONLY_THISPatrick Ohly2011-06-073-8/+38
| | | | | | | | | | | | | | | | | | | | The goal is to have an orthogonal API where each operation also has an inverse operation. Adding a detached recurrence was possible with e_cal_modify_object(), but removing it again wasn't without modifying the parent appointment. CALOBJ_MOD_ONLY_THIS in e_cal_remove_object_with_mod() provides that inverse operation by avoiding the modifications to the parent. The semantic in e_cal_modify_object(), the other call taking a CalObjModType, is unchanged. CALOBJ_MOD_ONLY_THIS is not valid there. Because not all backends reject CALOBJ_MOD_ONLY_THIS when they don't support it, a static capability CAL_STATIC_CAPABILITY_REMOVE_ONLY_THIS is added that must be checked first before using CALOBJ_MOD_ONLY_THIS. (Adapted from commit c54220339d9fda38d537e1f8cac3637403b362ab)
* calendar file backend: support removing parent event with CALOBJ_MOD_THISPatrick Ohly2011-06-071-46/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It was possible to create a meeting series with just a detached event (RECURRENCE-ID set) by importing a meeting invitation for that single recurrence. It was not possible to arrive at that same state after adding the parent event (the one with the RRULE) because e_cal_remove_object_with_mod() removed all instances for CALOBJ_MOD_THIS and empty rid. This contradicts the intended semantic of e_cal_remove_object_with_mod(): "By using a combination of the @uid, @rid and @mod arguments, you can remove specific instances. If what you want is to remove all instances, use e_cal_remove_object instead." This patch implements the desired semantic: - e_cal_backend_file_remove_object(CALOBJ_MOD_THIS) now always calls remove_instance(). - remove_instance() was extended to also work for the parent event. - That call removes the complete object if nothing is left after removing the instance. This case must be handled by the caller. The return value is the original object (if it still exists) and NULL if not. - Because the uid pointer into the object may become invalid as part of the removal, a more permanent pointer has to be provided by the caller. (cherry picked from commit ba88feadc788ab9a2961afd6a3575d7079928c32)
* e_book_backend_file_get_contact_list: Fix memory leakChristophe Dumez2011-06-071-0/+4
| | | | | | | vcard_dbt.data should be freed if it is not appended to the contact list otherwise memory gets leaked. (Adapted from commit 4324e0125cbc23c81bd8f1dadcafdd945cf26eb1)
* e_contact_name_from_string(): Fix possible memory leakChristophe Dumez2011-06-071-1/+2
| | | | | | The 'name' variable memory was leaked when name_str is NULL. (cherry picked from commit 6f17fe55e43d366eebd7f0bc7eeba0f3c56b3785)
* e_name_western_reorder_asshole: Fix possible memory leakChristophe Dumez2011-06-071-1/+3
| | | | | Free 'prefix' variable on early return. (cherry picked from commit 5f75312bfd570a78575e8332f5f621e8c4b023d9)
* e_dbhash_new: Close and reopen db handle to avoid memory leakChristophe Dumez2011-06-071-0/+7
| | | | | | | | | | | | | According to the documentation, "If DB->open fails, the DB->close method should be called to discard the DB handle". The current code was calling open() again on the same handle without closing it it first, possibly causing memory leaks. This patch is adapted from commit 37d3c0f65c989afe9ffc2d734d86b2ae0019edae in eds-fremantle GIT repository. (cherry picked from commit 6e0731c10801393d2bf1709ccff530df63bdbe28)
* Bug #650950 - entry_compare() should iterate over attributes with the same nameChristophe Dumez2011-06-071-10/+15
| | | | | | | Extend entry_compare() to iterate over attributes that have the same name (e.g. X-HOBBY) so that it can match any of them, not just the first one in the vCard. (cherry picked from commit 16ebd8f3e9269f7b788fc093f0c7fd952732ac52)
* Bug #651113 - [libebook] Querying date fields is not supportedChristophe Dumez2011-06-071-1/+32
| | | | (cherry picked from commit 37a3503b30cc071971a6806bd43d4a3bee949bb8)
* Bug #651054 - Support queries based on "photo" contact fieldChristophe Dumez2011-06-071-0/+21
| | | | (cherry picked from commit ac16f4aeb1c146e89e709d0f0f5455275fbe62e8)
* Bug #651226 - e_book_new_system_addressbook() should create source in GConfChristophe Dumez2011-06-071-3/+71
| | | | | | The same problem was fixed in libecal by commit 3bb75464a67 and commit 05c0b7b4bd0. (cherry picked from commit 65a0f255464dc7d7b8f7f0aefeff1462f00d4475)
* Bug #650952 - Remove unknown EContact field name runtime warningChristophe Dumez2011-06-071-1/+0
| | | | (cherry picked from commit f700cef243672e64411e4ff28156930eace8b5af)
* e_book_backend_file_get_changes: Fix possible memory leakChristophe Dumez2011-06-061-0/+8
| | | | | Currently, only the list elements were freed. This patch makes sure the GLists are freed too.
* CamelDB: Initiate a transaction before writing into db.Chenthill Palanisamy2011-06-021-0/+6
|
* Bug 640054 - CamelDB: do not read the db while a trasaction is in progress.Chenthill Palanisamy2011-06-022-20/+42
| | | | Fix the dead-lock caused due to transaction (DB WRITE_LOCK) and summary lock.
* CamelDB: Ensure that begin_transaction is called before adding queries to a ↵Chenthill Palanisamy2011-06-021-0/+7
| | | | transaction
* CamelFolderSummary: Remove undefined function ↵Chenthill Palanisamy2011-06-021-1/+0
| | | | camel_folder_summary_header_load from header file
* CamelDB: Use camel_db_select while retrieving the folder versionChenthill Palanisamy2011-06-021-11/+12
|
View Lorry Controller Status