2015-03-17  Carlos Garnacho  <carlosg@gnome.org>

	Release 1.3.6

	Distcheck fixes

	tracker-extract-gstreamer,msoffice: Improve warning message
	If we give the uri there, it's possible to know the file that issued the
	warning without verbosity>1 logs.

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

	tracker-extract: Do not pass lesser errors as processing errors
	The errors sent back to the decorator are meant to be sort of critical/
	disrupting, things that fall upon the normal mode of operation that
	tracker-extract should be prepared for (eg. files we don't have
	extractors for) shouldn't be issued as criticals.

	tracker-extract-gstreamer: Lower message severity
	A missing plugin can hardly be warning worthy, we can't warn on user
	choices.

	tracker-extract: Use own error domain/codes
	It doesn't make much sense to reuse TRACKER_DBUS_ERROR for these
	purposes.

	libtracker-miner: Invalidate the IRI of just inserted elements
	This allows us to be smarter about when to look up the IRI on the database.
	If a file is created and being slowly written to (eg. downloads),
	::file-created will be emitted for the file eventually, but the updates
	will keep the file instance alive on the TrackerFileSystem.

	In this case we attempted to be smart and avoid querying needlessly the
	database for the IRI, which resulted on a mistakenly NULL IRI, and on
	an attempt to "create" the item again, even though it existed. This
	resulted in "UNIQUE constraint" errors.

	One thing we can do is "invalidating" the IRI, so the next time we
	call tracker_file_notifier_get_file_iri() on it, a query is forced only
	in these situations, this will make later updates happy with the right
	IRI.

	If the updates are too slow, and the file happens to be flushed out
	of the TrackerFileSystem (all non-directory files do), the next update
	would trigger again its insertion, and the IRI would be queried again,
	so we're safe in that regard.

	https://bugzilla.redhat.com/show_bug.cgi?id=1192224

	file-notifier: Exclude pending dirs from the contents sparql query
	Directories added to the pending queue (ie. at the edge of max-depth)
	may also be signaled as "updated" and added to the updated files array.
	As these directories will be crawled/queried independently later on,
	it doesn't make sense to include these in the current query for
	directory contents.

	This fixes spurious reindexes seen across tracker-miner-fs restarts,
	an(y) updated folder would be added on both queue/array, the sparql
	query for directory contents would include that folder that hasn't
	been crawled yet (hence being in the pending queue) and incorrectly
	signal all its contents as deleted. The folder would be just reindexed
	again from scratch on the next restart.

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

2015-03-15  Matej Urbančič  <mateju@svn.gnome.org>

	Updated Slovenian translation

2015-03-15  Ask Hjorth Larsen  <asklarsen@gmail.com>

	Updated Danish translation

2015-03-15  Matej Urbančič  <mateju@svn.gnome.org>

	Updated Slovenian translation

2015-03-15  Мирослав Николић  <miroslavnikolic@rocketmail.com>

	Updated Serbian translation

2015-03-13  Samir Ribic  <samir.ribic@etf.unsa.ba>

	Added Bosnian translation

2015-03-12  Carlos Garnacho  <carlosg@gnome.org>

	libtracker-data: Support fn:replace()
	In a limited form, no regex support.

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

2015-03-12  Giovanni Campagna  <scampa.giovanni@gmail.com>

	tracker-store: clear the watchdog timer when it fires
	Otherwise glib complain that we remove an invalid source.

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

2015-03-07  Seong-ho Cho  <shcho@gnome.org>

	Updated Korean translation