Post-release version bump.

Release version 0.6.6

Bug 665376 — Add API to get a TpfPersona from a TpContact

Add static functions to quickly look up Tpf.PersonaStores and Tpf.Personas
from Tp.Accounts and Tp.Contacts (respectively).

Closes: bgo#665376

Bug 665692 — Use constructors correctly

In order to allow libfolks to be used from introspected languages (such as
Python) properly, we need to correctly use the GObject construction process,
rather than generating code which does all object initialisation inside
a *_new() function. This involves moving lots of code into construct{} blocks.

There are some complications; mostly the need for various private variables to
now be exposed as construct-only properties. Most of them should've been
anyway.

Other complications arose from the fact that moving code to a construct{}
block can subtly change the execution order of the code if the Object() call
lists properties which are non-construct properties (e.g. the “alias” property
of a Persona). The setters for these properties will now be called _after_ the
construct{} code, whereas previously they would've been called beforehand.
This rears its head in Tpf.Persona, but hopefully nowhere else.

Closes: bgo#665692

tests: Add a test case for bgo#665728

Ported from a C test case by Guillaume Desmottes
<guillaume.desmottes@collabora.co.uk>.

See: bgo#665728

backends: Tidy up prepare() and unprepare() methods’ mutual exclusion

As discovered in bgo#665728, all our prepare() (and unprepare()) methods are
currently vulnerable to being run multiple times concurrently from a single
thread. Add a _pending_prepare flag to all of them to prevent this. It
doesn't need to be locked, since it should only ever be accessed from a
single thread (since only a single thread can get through the lock{}
recursive mutex at once).

Helps: bgo#665728

Bug 665728 — prepare() isn't mutually exclusive inside a single thread

Fix Tpf.PersonaStore.prepare() to only run once, even if it's called multiple
times from the same thread (e.g. if the caller wasn't yielding on the async
call returning).

Closes: bgo#665728

telepathy: Improve debugging messages in Tpf.PersonaStore

It's a bit hard to differentiate between different instances of
Tpf.PersonaStores at the moment, so let's include their addresses in debug
messages.

Also fix a minor whitespace issue.

Fix the documented name of individuals_changed_detailed.changes

Bug 665039 — Crash in folks_backends_sw_backend_add_service

Hold a reference to the Sw.Backend while waiting for a SwClient async call
to finish in prepare().

Similar changes are made in Swf.PersonaStore to avoid potential bugs there.

Closes: bgo#665039

Ensure NameDetails public strings are non-null as we promise.

Closes: bug#663889 - crash due to NameDetails which fail to guarantee
non-null full-name/nickname

[l10n] Updated German translation

Clear out log handlers when disposing Debug to avoid crashers.

In cases where the IndividualAggregator is destroyed and instantiated
again (as in some of our tests), we could end up calling the Debug
log handlers after destroying the Debug instance (resulting in
g_static_rec_mutex_lock/unlock calls on an invalid freed mutex,
causing a segfault).

Closes: bgo#664158 - Stale log handler can cause segfault when
re-creating Aggregator in a single run

Updated Galician translations

Bump Vala and GObject Introspection requirements.

This bumps them to their first release in their current stable release
series.

This shrinks the gap between builders' build environments and what our
developers build and test with.

Post-release version bump.

Release version 0.6.5

Fix comment syntax to unbreak documentation generation.

telepathy: Fix finalisation of Tpf.Logger if it hasn't been prepared

Closes: bgo#659585

Add AbstractFieldDetails.value_type.

This allows generic handling of collections of derived objects of
mixed concrete classes.

Helps: bgo#663798 - Add AbstractFieldDetails.value_type

Updated Slovenian translation

Properly serialize AFD values for the Tp cache.

We were previously writing serialized Telepathy AbstractFieldDetails
values over each other in the final array, which was generally bad
and specifically crashed Gnome Shell.

This affects AFD-derived structures: phone numbers, email addresses,
and URLs.

Closes: bgo#662314 - Gnome-shell restarts if I change my user status to
disconnected/unavailable

Updated Czech translation

Updated Spanish translation

Generate the same C code whether the eds backend is enabled or not.

Previously, the configure options used would alter the release tarball.

This would cause problems for anyone building from the shipped C files
(specifically, if they also disabled the eds backend, as the Debian
packagers did).

Closes: bgo#662274 - Failed to link personas: Can't link personas with
no primary store.

Warn if the primary store is not found.

This includes steps for the user to fix the problem.

Helps: bgo#662274 - Failed to link personas: Can't link personas with
no primary store.

Properly set primary stores for tests to exactly what's used.

Helps: bgo#662274 - Failed to link personas: Can't link personas with
no primary store.

Expose the details of which backends are enabled to libfolks.

Helps: bgo#662274 - Failed to link personas: Can't link personas with
no primary store.

e-d-s: set content type on ContactPhotos

Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=662616

e-d-s: load icon regardless of the mime type being available

Also, allow Edsf.MemoryIcon to be instantiated with a null
image type. The notion of the image type not being available
was half there (some comments mentioned the possibility), but
it wasn't contemplated in the constructor and in the instance
variable.

Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=662770

docs: Add description for Folks.Utils class.

docs: Add @since for MaybeBool.

docs: Add a description block for the new types.

Note, however, that this is obscured in the final docs due to
bgo#662793 (valadoc ignores comment blocks on namespaces).

docs: Don't build empty docs for libfolks-internal.

Updated Polish translation

docs: Work around a valadoc comment-parsing issue.

e-d-s: test setting is-favourite property

Helps: https://bugzilla.gnome.org/show_bug.cgi?id=660908

e-d-s: extend add-persona test to check for is-favourite

Helps: https://bugzilla.gnome.org/show_bug.cgi?id=660908

e-d-s: add favourites support to EDS backend

Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=660908

core: Add extra debug for primary store configuration

Simplify NoteFieldDetails.equal()

Simplify PhoneFieldDetails.equal()

Check the GLib.Type of both elements for AbstractFieldDetails.equal()

This simplifies the code for overridden equal() functions.

Add AbstractFieldDetails.values_equal().

This function is lets subclasses to provide "smart" value comparisons
without needing to factor in the parameters. This is particularly
important for uses like PotententialMatches.

This clarifies the roles of AbstractFieldDetails.equal() and
parameters_equal() (both in form and documentation).

Closes: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

Migrate PhoneDetails to using AbstractFieldDetails.id

Helps: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

Migrate RoleDetails to AbstractFieldDetails.id

Deprecate Role.uid in favor of AbstractFieldDetails.id

Helps: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

Guarantee all Role members are non-null.

Helps: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

Migrate NoteDetails to AbstractFieldDetails.id

Deprecate NoteFieldDetails.uid in favor of AbstractFieldDetails.id

NoteFieldDetails.equal() now ignores NoteFieldDetails.uid

Helps: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

Guarantee all NoteFieldDetails members are non-null.

Helps: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

Use the most-parent equal() function when comparing postal addresses.

Helps: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

Migrate PostalAddressDetails to using AbstractFieldDetails.id

Deprecate PostalAddress.uid in favor of AbstractFieldDetails.id

PostalAddress.equal() now ignores PostalAddress.uid

Helps: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

Add AbstractFieldDetails.id to identify instances of details.

This will unify the way we handle IDs for the various classes that
derive from AbstractFieldDetails for eccentric data stores (I'm
looking at you, Tracker).

Helps: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

Only add non-empty Role components to Edsf.Personas.

The EDS test "set-roles" was failing because some empty parameters were
getting added to Edsf.Personas, thus failing parameter equality checks.

Helps: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

Properly set the parameters for the eds/set-phones test

Helps: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

Fix eds test add-persona for param matching

Helps: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

Fix the params used for the postal-address-details eds test

Helps: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

Always include parameters in AFD-derived subclass equal() functions.

Helps: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

Factor out AFD parameter equality (for use in derived classes)

Helps: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

Fix the signature of RoleFieldDetails.equal()

Helps: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

Add test for RoleFieldDetails.

Helps: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

Fix trivial spacing issues.

Correctly update email based im addresses during contact changes

When we have already read a contact, but are updating it e.g. due
to a property change there is a problem in
Edsf.Persons._update_im_addressess(). Its looking at the existing
personas im_addresses for already existing im addresses before adding
new ones. However, they were already added there based on the email
addresses last time, which means we don't add them now.

The fix is simple, just look in new_im_addressess for existing
im_addresses.

https://bugzilla.gnome.org/show_bug.cgi?id=662285

Post-release version bump.

Release version 0.6.4.1

Fix the SONAME.

We accidentally decreased the SONAME with the 0.6.4 release, so this
adjusts the various easy-to-understand/impossible-to-confuse libtool
numbers.

Closes: bgo#662095

Marginally clarify our comments for the lt numbers.

This should help us avoid mangling them in the future.
Don't quote me on that.

Post-release version bump.

Release version 0.6.4

build: Fix explicit build dependency to un-break vala-free builds.

build: Distribute test-dependent makefiles.

This is mainly to enable running "make foo.gdb" from the source
distribution.

build: Include internal folks library for valadoc parsing issues

Obviously, these symbols shouldn't be documented externally, but since
valadoc uses libvala internal, it requires the ability to resolve them
(even if they won't be exposed in the finals docs).

build: Require valac if libfolks-internal files are missing.

build: Fix the libfolks path to libfolks-internal.la

build: Fix test ObjectCache for internal API breaks.

telepathy: Add support for caching vCard parameters for contacts

Add birthday, full name, e-mail address, phone number and URL support to the
Telepathy object cache so that contacts’ vCards are correctly stored when
the cache is updated.

Closes: bgo#661475

core: Add support for object version migration in object cache files

Add the ability for the variant type used in object cache files to vary with
the cache file version, and for object cache implementations to claim they
don't support given versions.

Helps: bgo#661475

telepathy: Fix mixed-assignments-and-declarations warning in test library

Updated Slovenian translation

Updated Polish translation

Updated Spanish translation

Updated Spanish translation

Clarify in configure output that we require 0.6 <= gee <= 0.8.

Closes: bgo#660937 - [regression] build failure: No package 'gee-1.0' found

Fix our birthday string parsing for Telepathy backend.

Don't prepare the Telepathy Connection until it's guaranteed to exist.

Distinguish Telepathy errors with new UNSUPPORTED_ON_NON_USER

Support Birthdays for the Telepathy backend.

Support UrlDetails for the Telepathy backend.

Support EmailDetails for the Telepathy backend.

Split utility functions into an internal library.

This lets us avoid stuffing them into unrelated public libraries.

Memoize the ContactInfo SupportedFields values.

Factor in server-side writeability of ContactInfo fields.

Include required Telepathy Connection ContactInfo features.

These are required to look up the connection's ContactInfoFlags.Can_Set
and SupportedFields. We need both to determine which ContactInfo fields
are writeable (for Tpf.Persona.writeable_properties).

Reorganize tp/individual-properties test.

Add assertions about Telepathy writeable properties to our tests.

Ensure that our test self contact has an identifier.

Print contact info for Telepathy contacts in tests.

Support writing extended info for Telepathy user contacts

Helps: bgo#657602 - Telepathy backend fails to set Personas' phone
numbers from ContactInfo

Implement ContactInfo in the Telepathy test backend.

Helps: bgo#657602 - Telepathy backend fails to set Personas' phone
numbers from ContactInfo

Telepathy: implement PhoneDetails for Tpf.Persona

Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=657602

Move SetComparator into folks/utils so it can be used by other backends

Helps: https://bugzilla.gnome.org/show_bug.cgi?id=657602