Part of the code reorganization was removal of check_dup_uid() from
the normal "add component" code paths. It was only done as sanity
check when loading a file. That sanity check then incorrectly rewrote
UIDs, because it didn't take into account that detached recurrences
have (and must have) the same UID as the recurring master event.

This patch fixes check_dup_uid() accordingly. It moves the
uid g_free() into the bottom of the function to have a common
cleanup section.

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.

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 272cb7d5)

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 0c178bba)

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 ae4f4292)

* addressbook/tests/: Add a tools/ directory with .sh files from
libfolks/tests/tools/, to let us start and stop a private D-Bus
session, and set XDG_* environment variables for local use of EDS,
when running tests.
* addressbook/tests/ebook/Makefile.am: Set TESTS_ENVIRONMENT to
run the tests with the private D-Bus session.

Include gtk-compat.h to fix compilation with GTK < 2.24

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.

(Adapted from 76839122)

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 17a86ec2)

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 571b77cd)

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 88c1996b)

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 bbe2d0a4)

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 e6eb6656)

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 c5422033)

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 ba88fead)

vcard_dbt.data should be freed if it is not appended to
the contact list otherwise memory gets leaked.

(Adapted from commit 4324e012)

The 'name' variable memory was leaked when name_str
is NULL.

(Adapted from commit 6f17fe55)

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.

Free 'prefix' variable on early return.

Currently, only the list elements were freed. This patch
makes sure the GLists are freed too.

(cherry picked from commit 4078d6ff)

The same problem was fixed in libecal by commit 3bb75464
and commit 05c0b7b4.
(cherry picked from commit 65a0f255)

(cherry picked from commit 37a3503b)

(cherry picked from commit ac16f4ae)

(cherry picked from commit f700cef2)

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 16ebd8f3)

Very bad performance (100% CPU load, several minutes run time) were
seen for multiple concurrent writes. gdb shows that libdb is
apparently busy polling while writing.

The libdb API docs for DB_ENV->open() imply that either DB_INIT_CDB or
DB_INIT_LOCK must be used in apps which are not read-only, like
EDS. This patch adds DB_INIT_CDB because it is simple and fixes the
performance problem.

In some rare cases, DB_INIT_LOCK might provide better performance by
allowing concurrent writes of independent data, but that seems too
complicated for not enough gain right now (must check for deadlocks).
(cherry picked from commit faada76f)

(cherry picked from commit fec059d9)

(cherry picked from commit 89b384cf)

(cherry picked from commit a65b1d94)