Was causing unit tests to fail and made distcheck impossible

Instead of a made up string, which doesn't have any true meaning, and which
makes libicu and libunistring differ on the number of words found, use a simpler
sentence...

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

GLib complains now if you try to remove a GSource ID that doesn't exist. The
critical means that tests can fail where before they wouldn't have.

This fixes distcheck.

This fuctionality we're removing has been around since
be58d8da where Philip added code to kill a
forked process after n seconds for really complex PDFs (or PDFs that take
longer to process on embedded devices). This was covered under NB#290406.

Later I improved the code to use select() instead of signal handlers due to
IO blocking in some situations in commit
9c4e166e and as part of GB#680897.

However, the extra complexity is no longer needed as far as I can tell. There
was a good reason for the IO blocking in the past and I believe it has been
fixed by Carlos in one commit or another and with the new GTask and
_run_in_thread() APIs we have now, it's unnecessary to use this approach. IF
anything, we should add some timeout or cancellation in the task issuing
(main?) thread instead of implementing this for each extractor. Currently we
don't do this though.

As an additional note, this may fix GB#726421.

I've tested this patch with files attached to previous bug reports related,
including GB#680897 and GB#685378.

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

Add the sqlite3_errstr() to the error that is propagated from
sqlite3_open_v2 so that we have a clearer picture of the failure.

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

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

An error from sqlite3_open_v2 will lead to a failure to create a
TrackerDBInterface. This means that DBManager.get_db_interface will
fail.

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

The EnumeratorData held a reference to TrackerCrawler while
enumerating. Just before closing the enumerator we destroy the
EnumeratorData and drop the reference. This can lead to TrackerCrawler
getting destroyed.

To prevent this, grab a new reference before dropping the older one
and keep it till the asynchronous call is alive.

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

... and simplify parent directory tracking.

The GFileEnumerator keeps a reference to the directory that is being
traversed, so we don't need to keep track of it ourselves.

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

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

function_weights() and function_property_names() (used respectively by
SPARQL fts:rank and fts:offsets functions), initialize all data at first
from the database, so it's available in memory for posterior runs,
although currently those are being quite optimistic about the database
return values in several ways, so:

- Ensure no infinite loops happen on sqlite3_step() if the stmt trips
  into some unexpected state. SQLITE_BUSY still does keep looping though.

- As initialization here is a failable task, stop using g_once_init_*
  and use an static GMutex so initialization can be tried later again
  if it failed previously.

- For the cases where initialization failed, propagate the error code
  on the sqlite3_context.

Based on work by Tim Waugh and Michael Catanzaro.
https://bugzilla.redhat.com/show_bug.cgi?id=1026283

There is a bug in SQLite version 3.8.1 which causes incorrect query
results. See the following links for more details:

    https://mail.gnome.org/archives/tracker-list/2013-November/msg00021.html
    https://bugzilla.redhat.com/show_bug.cgi?id=1034714

The bug is fixed in SQLite master already so version 3.8.2 should be
fine to use.

This way timers are in agreement with their boolean guards,
and will get continued when processing actually starts.

Carlos Garnacho authored Nov 22, 2013 and Matthias Clasen committed Nov 22, 2013

If some channel watch functions returns FALSE, don't attempt to remove the
source again on process_context_destroy(). Also, don't leak stdout_channel.
This fixes critical warnings during make check on the tracker-backup test.

Carlos Garnacho authored Nov 22, 2013 and Matthias Clasen committed Nov 22, 2013

If no UTC relation is set to the date, the computer timezone is
picked, which may obviously differ from UTC.

Carlos Garnacho authored Nov 22, 2013 and Matthias Clasen committed Nov 22, 2013

So it is easier to follow the #if condition

This log message gets emitted even if we have nothing to do on
normal bootup.  This spew is now more visible due to
See https://bugs.freedesktop.org/show_bug.cgi?id=68559

By reducing debug output, we make it easier to spot actual errors.

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

My previous attempt was totally broken as I'd accidentally been
passing --disable-upower to configure =/

This patch at least compiles with new upower; doing some testing
now.

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