Do not assign to VALAFLAGS

Users should be able to do "make VALAFLAGS=--enable-experimental-non-null"
without overriding necessary flags like --target-glib=2.24. The variable
for use by package maintainers is AM_VALAFLAGS.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=695628
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip@tecnocode.co.uk>

Assamese translation updated for gnome 3.8

HACKING: Update documentation for strict-non-null mode

Mention how to compile with --enable-experimental-non-null.

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

Updated Indonesian translation

Updated Greek translation

Update NEWS with recent changes

Mostly avoid an expensive multi-map iteration pattern

If you have a MultiMap with, say, 100 keys each with 1 value, and you
iterate over it like this (pseudocode):

    for key in keys():
        values = get(key)
        for value in values:
            do something(key, value)

then you have constructed one GObject for the result of keys(), and
100 GObjects for the results of get() (because it returns a read-only
view). If you iterate it like this:

    iter = map_iterator()
    while iter.next():
        do something(iter.key(), iter.value())

there's only one extraneous GObject, the iterator itself.

When there are thousands of contacts, as in add-contacts-stress-test,
this really starts to matter.

This patch doesn't fix every use of get_keys() - some of them do
non-trivial work per key as well as per value, making it awkward to
convert to map_iterator() - but it's a start. It cuts 'user' CPU time
for IndividualAggregator quiescence for an e-d-s Google account with
2049 contacts (reading from cache) by around 3%.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=682903
Reviewed-by: Philip Withnall <philip@tecnocode.co.uk>
[note added to HACKING as per Philip's review]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Updated Slovenian translation

Updated Belarusian translation.

Updated Brazilian Portuguese translation

Use absolute paths for --vapidir

In the rules currently generated by Automake, valac currently runs
cd'd into the ${srcdir}. It seems unwise to rely on that, and the
only thing that will work regardless of whether ${srcdir} is ".",
relative or absolute is its "absolutized" version.

Similarly, look in both the ${srcdir} and the ${builddir} for Vala
bindings we generate: the ${srcdir} because that's where valac currently
puts them, and the ${builddir} because that's where they ought to go
in principle.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=694883
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip@tecnocode.co.uk>

Add -I$(top_srcdir) throughout

Automake adds (the equivalent of) -I$(top_builddir) to our CPPFLAGS
automatically, so we can #include "config.h". It does not add
-I$(top_srcdir). Many things in folks want to #include <folks/folks.h>,
so we should always have -I$(top_srcdir) so we can pick that up.

Out-of-tree builds previously either didn't work, or relied on having
installed folks headers (I'm not sure which).

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=694883
Reviewed-by: Philip Withnall <philip@tecnocode.co.uk>
[amended to do the same for tracker- and libsocialweb-specifics too -smcv]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>

Updated Norwegian bokmål translation

[l10n] Updated German translation

Updated Lithuanian translation

Updated Traditional Chinese translation(Hong Kong and Taiwan)

Updated Serbian translation

Updated Galician translations

Updated Polish translation

build: Include location-details.c in POTFILES.skip

This fixes a break in distcheck

build: Use @return instead of unsupported @returns valadoc

This was breaking the build when making docs

Updated Uyghur translation

Signed-off-by: Gheyret Kenji <gheyret@gmail.com>

Updated Uyghur translation

Signed-off-by: Gheyret Kenji <gheyret@gmail.com>

Updated Uyghur translation

Signed-off-by: Gheyret Kenji <gheyret@gmail.com>

Updated Czech translation

Punjabi: Translation updated (aalam)

Updated Spanish translation

Update French translation

Update French translation

support geo location information

This adds "Location" class with latitude and longitude and
single-valued "LocationDetails" which exposes that information for a
contact. The logic for choosing "the best" among many locations from
different personas is left out for now. Instead folks picks according
to the default ordering of single values, which prefers values from
the primary store.

The EDS backend provides, creates and writes the GEO property as
location.

Updated Czech translation

eds: Fix the type of a parameter in add_persona_from_details()

This build breaker was introduced in commit
dcc558d87d113dae0aa8721db3d80261c08dee57.

eds: fix Android favourite handling when creating contact

When processing PersonaDetail.GROUPS before PersonaDetail.IS_FAVOURITE
while creating a new contact in EDS, the special code for adding the
contact to the “Starred in Android” group (bgo#661490 was skipped). We
must go through _set_is_favourite instead of _set_contact_is_favourite
to get that part done, too.

eds: support 'groups' when creating a contact

There's a minor twist with supporting the setting of groups from
details: _set_contact_groups() needs to know whether the contact
is a favorite, for special handling of Google contacts.

If the PersonaDetail.IS_FAVOURITE is found first in the details, that
boolean is passed to a later _set_contact_groups(). If
_set_contact_groups() is done first, then _set_contact_is_favourite()
applies the special Google workaround.

Update the home page listed in DOAP file

Post-release version bump

Release version 0.9.1

Fix build with evolution-data-server master

Eds recently splitted certain enums from libebook into libebook-contacts.
As part of that, they are now correctly reported as error domains,
rather than bare enums, so we need to change the syntax to check them.

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

Post-release version bump

Release version 0.9.0

Temporarily disable some broken tests for the release.

Distribute the ofono backend dir

Alphabetize backend subdirs

Revert "build fix: Only depend on Gee 0.8.3, since 0.8.4 isn't released yet"

This reverts commit ad77950c7a628399e59ac3d04f07f95bb21f1887.

Bump Tracker requirement to the latest series.

Updated Polish translation

eds: Check property values have changed before committing them to EDS

This prevents timeouts when waiting for EDS to notify us of property changes,
since it won’t notify for non-changed properties. It also saves a D-Bus round
trip in the case the folks property setter is called with an unchanged value.

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

Update French translation

Revert "CUT -- disable some broken tests"

This reverts commit f58c41dfbdb53bb617215888859fafb32ad2b9d6.

CUT -- disable some broken tests

build fix: Only depend on Gee 0.8.3, since 0.8.4 isn't released yet

This can safely be reverted once Gee 0.8.4 is released.

tools: Fix ambiguous references to HashTable

Could have been GLib.HashTable or Xml.HashTable. Caught by Jenkins:
https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-folks/114/

On further investigation, this was caused by changes to the libxml2
bindings in Vala. Compilation of folks against Vala master now
succeeds, so there shouldn’t be any more HashTable failures.

eds: Fix ambiguous references to HashTable

Could have been GLib.HashTable or Xml.HashTable. Caught by Jenkins:
https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-folks/113/

Port folks to libgee 0.8.

Added hash_static and equal_static to AbstractFieldDetails.
Use AbstractFieldDetails hash_static and equal_static where needed.

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

eds test: Ensure the source is declared enabled

This seems to fix the problem with create-remove-stores from failing
sporadically. And it matches all the sample sources used in e-d-s itself.

I also added a trailing \n to match them as well (though it doesn't seem to
have any obvious effect).

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

individual-aggregator: Expand documentation on linking/unlinking API

individual-aggregator: Add some documentation on linking/unlinking API

Updated Lithuanian translation

Updated Uyghur translation

Signed-off-by: Gheyret Kenji <gheyret@gmail.com>

Updated Uyghur translation

Signed-off-by: Gheyret Kenji <gheyret@gmail.com>

Updated Uyghur translation

Signed-off-by: Gheyret Kenji <gheyret@gmail.com>

build: Don't use make functions for defining TESTS

Usage of 'make' functions in the definition of TESTS special variable
can lead to the creation of a corrupt Makefile.in, thus a corrupt Makefile.

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

Uyghur translation added

Signed-off-by: Gheyret Kenji <gheyret@gmail.com>

Updated Serbian translation

Don't rebuild docs on every "make" run.

Create timestamp files to avoid redundant valadoc invocation.

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

Bug 691382 — Restore tests disabled by bug #668415 (which has been fixed)

This ports the store-removed test to the current EDS introspection bindings
and removes the change-primary-store test on the basis that we don't really
support clients changing the primary store.

In the future, we may want to add a test to ensure we cope with the primary
store disappearing, but that's a different case.

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

Bug 686695 — support nickname in add_persona_from_details

Support nicknames in add_persona_from_details() in the EDS backend. This
adds a test case (which passes).

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

Updated Bulgarian translation

Updated slovak translation

Bug 691167 — Build failure: key-file tests built before dependencies

This fixes a regression from 96c51fe585b which built the key-file tests
before the libraries they depended upon (breaking the build).

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

Bug 690876 — eds: fix various test failures

Note bug fixed by the last several commits

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

eds test: don't assume Individuals remain after changing a linkable property

eds test: create a new address book for each test to avoid inheriting state

This fixes a bug where the second anti-linking test would fail if it ran
after the first.

eds test: ensure basic anti-link removal works

eds test: add basic anti-linking test

eds test: remove unnecessarily-strict test for extra Individual add/remove

Ideally, we should be able to fulfill this test, but it's probably not worth
the extra code complexity.

eds test: support setting email addresses in test backend

eds test: rename _parse_addrs to _parse_im_addrs for specificity.

eds test: ensure changes to linkable properties aggregate Personas together

eds test: create a new address book for each test to avoid inheriting state

This fixes a bug where the web services linking test would fail if it ran
after the im address linking test.

eds test: add test for specific behavior of linkable properties

This splits out a subtle and complicated linkable-properties bug discovered
by the set-emails test where changing the emails (which happen to be a
linkable property in the EDS backend) causes an unnecessary Edsf.Persona
creation and removal cycle.

The set-* tests are meant to confirm that reading and writing the given
property works, so seperating this should let us simplify those tests
slightly yet focus on the secondary details we care about in a specific test
case.

HACKING: Update documentation for running single tests

build: Rewrite valgrind.mk to use GNU Make conditionals

This means we’re not overwriting rules and potentially changing their
prerequisites. Incorrectly overwriting check-* rules was causing tests to
be run twice in the tests/folks directory.

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

build: Fix cleaning of .stamp files in EDS tests directory

build: Tidy up test Makefiles a little

HACKING: document how to run a single test

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

build: Update valgrind.mk to match automake-generated ‘check’ rule

The dependencies and chained rule were wrong. Not that it seems to
make much difference.

Bug 690989 — "warning: copying delegates is discouraged"

Fix a warning introduced by commit 7088fbafafd3e75f02266aa8b093d69660311b36.
Whoops.

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

build: Add a missing bracket in configure.ac

Updated Hungarian translation

telepathy: Call continuations in idle callbacks rather than directly

The continuations will proceed to a g_simple_async_result_complete() call,
rather than a g_simple_async_result_complete_in_idle() call as I expected
(and didn’t check). This could result in the first continuation executing
a lot of code and starving the other continuations (and the original
prepare() call). By delaying the continuations to the idle queue, the
original prepare() call is guaranteed to finish first. Then the
continuations can only starve each other.

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

individual-aggregator: Fix some debug spew

documentation: Document which yielding methods are safe to call concurrently

This is a follow-up commit to ce55fa2bf2f5f8cf95532da585d835bafeeb3347.
I went through all methods in folks which yield to another async method,
and tried to work out whether the caller was safe to run multiple times
concurrently (e.g. begin a second asynchronous call to it between a previous
async call beginning and finishing).

I’ve marked all such methods as safe (or not safe) as appropriate. I
haven’t made any attempt to make the unsafe methods safe, except in one
case in backend-store.vala.

phone-details: get_normalised: keep the leading '+'

It's needed to be able to call phone numbers containing an international
prefix.

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

Updated Hebrew translation.

telepathy: Yield subsequent Logger.prepare() calls if one is pending

If one PersonaStore began to prepare its Logger, then yielded on a D-Bus
call, another PersonaStore could begin to prepare its Logger and also
try to create a static D-Bus proxy (which is only supposed to be created
once). This is because the original async call hasn’t returned and set
Logger._logger by that point.

Fix this by keeping a queue of pending prepare() calls which is signalled
by the initial prepare() call once it finishes yielding.

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

telepathy: Remove Logger.prepare() return value

It’s unused. It’s private. It’s a waste of code.

telepathy: Fix bus watching by multiple Tpf.PersonaStore instances

The bus needs to be watched by all Tpf.PersonaStores which are connected to
the Logger instance, so that they all get the ‘invalidated’ signal.

Updated Greek translation

Updated Galician translations