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

Add Esperanto translation

Updated Spanish translation

Also update tracker-sparql versions for Tracker backend.

Closes: bgo#660217 - folks-0.6.3.2 requires tracker-0.12, but
configure.ac calls VALA_CHECK_PACKAGES([tracker-sparql-0.10])

Use consistent version checking for tracker-sparql-0.12

Closes: bgo#660217 - folks-0.6.3.2 requires tracker-0.12, but
configure.ac calls VALA_CHECK_PACKAGES([tracker-sparql-0.10])

core: add debug info about configured primary store

Post-release version bump.

Release version 0.6.3.2

Require Tracker 0.12

Closes: bgo#660051 - require tracker 0.12

Don't assume that "CONNECTED" Tp.Accounts have valid Tp.Connections

There's an in-between state where the Tp.Account is "CONNECTED" but hasn't
finished preparing its Tp.Connection (and thus, it's null).

Closes: bgo#659041 — tpf-persona-store.vala: try to connect to a NULL object

Ensure we prepare all TpAccounts before trying to use them.

Helps: bgo#659041 - tpf-persona-store.vala: try to connect to a NULL object

More-tightly scope variable in EDS backend.

Actually fall back to eds:system in case there's no default address book.

Closes: bgo#660140 - contacts_contact_find_persona_from_store: assertion `store
!= NULL' failed

[l10n] Updated German translation

Trivial NEWS fix.

Note in the NEWS that we fixed bgo#659732 before the 0.6.3.1 release.

Post-release version bump.

Release version 0.6.3.1

Make sure we source GConf files installed next to us.

Deal with lingering callbacks in the eds/set-avatar test.

These can be called after we've set this._main_loop = null,
so if we don't check it first, we'll hit warnings (which get
treated as errors).

This isn't an ideal solution, but there doesn't seem to be a
great way to avoid the handlers from firing after we no
longer care (we need something like thaw/freeze_notify(),
except for general signals, not just notify).

Serialize checks for completion in EDS test.

We were interleaving checks which resulted in inconsistent behavior.

Exit EDS test early in case multiple signal emissions are in-flight.

This fixes a race between the mainloop being nullified and a dependent
signal handler calling quit() again (no idea how the signals were
getting issued and handled after the initial quit() though).

eds: split up link-personas test and cut relative URI dependency

Though some code might be duplicated, it's healthy to split tests
into different executables to assure our clean-up code (wiping out
GConf entries, shutting down our own session Bus, etc) runs between
tests.

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

eds: rework tests so that they don't depend on relative URIs

Previously, tests were build around the assumption that each
Edsf.PersonaStore had an id == ESource.relative_uri. That
stopped being true (because you'll get swallowed by a black
hole in pwithnall's garden if you use relative URIs).

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

e-d-s: use UID instead of relative URI to track ESources

Some e-d-s backends (i.e.: the Exchange one) might not have
a relative URI so we can't rely on it as an address book
identifier. So from now on we use the ESource's UID.

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

tpf: no need to use a lambda since callback exists

tpf: don't unprepare the backend if it isn't prepared

Clean up variables in Tpf test to match Edsf test.

Check for expected-missing capabilities in PersonaStore tests.

Use PersonaStore.always_writeable_properties.

This removes references to the deprecated
PersonaStore.can_alias_personas and PersonaStore.can_group_personas

Closes: bgo#659737 - tests fail due to usage of deprecated methods

build: Fix regular expression to extract dlname

The regex writer unintentially made a character range in ".-+".
This was always wrong, but it actively fails when LANG=C.

Closes: bgo#658002 - defective typelib

Deprecate PersonaStore.can-[alias|group]-personas

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

Updated Slovenian translation

Updated Slovenian translation

Updated Slovenian translation

Update NEWS file for next release

build: Post-release version bump

build: Release version 0.6.3

url-details: s/HOMEPAGE/HOME_PAGE/

Quick, before this gets released and frozen!

eds: Fix potential false matches in _is_in_source_list()

It's possible for the relative URIs of two ESources to be equal (though it's
unlikely). Consequently, we need to compare by UID as well.

Bug 653623 — Would like a set of standard "type" parameters for UrlDetails

Add some consts for TYPE and some common values for it for UrlFieldDetails.

Closes: bgo#653623

individual: Prefer set properties over unset ones

I can't believe I didn't notice/think of this when I first wrote this code.
I think my licence to write software should be revoked.

Update British English translation

Bug 657738 — Favorite people are not always displayed

Ensure the TpLogger connection in Tpf.PersonaStore is always prepared before
we first attempt to use favourite contact data.

This should fix the situation where IM connections are already prepared before
folks is prepared (i.e. _connection_ready_cb() is called as soon as the
Tpf.PersonaStore is prepared).

Closes: bgo#657738