GitLab

It was cool when Tracker search was barely integrated anywhere.
Nowadays, it's nothing but an aging showcase app (eg. was conceived
in the gtk2 days and barely ported to gtk3, and it shows everywhere).

If you want a modern and capable search UI, try Nautilus. If you
are outraged that tracker-needle is gone and ended up here, by all
means be my guest, reset to the parent of this commit and take it
out of tree. If you join #tracker I'll gladly give you advise on
how could it be brought up-to-date. But our hands are full, sorry,
we leave cool UIs to others.

This is a mix of store and miner features which can't be assumed to go
together. It is better to leave configuration UI up to the environment,
in the GNOME case this is gnome-control-center search panel.

For settings that fall in the cracks, or for environments that don't
integrate Tracker search in their configuration UI, there's the rather
capable dconf-editor which will provide all toggles, and will explain
them better than any UI we may have.

In the future the CLI tools might gain some configuration subcommand,
but it will not be a graphical UI.

Those are unmaintained, are broken, don't compile, or a combination of
all. Sadly there hasn't been enough manpower during the last years to
keep those up to par. Future seems shiny enough for nautilus, as the
features are being developed in-tree.

If anyone ever remembers there were such plugins and misses them
enough to take over maintainership, by all means reset to the parent
of this commit and take those out of tree. You will have my gratitude.

Thanks too to everyone who ever contributed in those plugins, I'm
not happy to let that much work go.

The libmediaart dependency was disabled in commit 6a050686, it
doesn't make sense to drag this code around.

Those ontology files are the tracker core, as the database files' structure
is modeled around those classes and properties. Include those as a GResource
so they're guaranteed to be there, all other ontology files are optional
and must be provided on TrackerDataManager initialization.

The NAO ontology has been split between the official bits (included in the
GResource) and the non-official bits (just used by the evolution miner, and
moved to 90-tracker)

Just set it in library LDFLAGS, otherwise introspection may
find the installed libraries before the ones being built, which
is not the right thing if there are new symbols/types to be looked
up.

This removes various code paths that we believe to be unused.

  * The userguides miner has been removed altogether.
  * The application miner no longer parses MeeGo-style .desktop files
  * The TRACKER_DISABLE_MEEGOTOUCH_LOCALE environment flag is gone
    (it already did nothing)
  * Character set detection with libmeegotouch is removed, only enca
    or libicu are supported
  * Meego-specific flags are gone from .desktop files
  * Functional tests have lost their vestigal Scratchbox and Aegis support

There are 5 ontologies referencing Maemo, 4 of which are largely unused.
These have been kept around in case anyone is using them outside
Tracker.

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

There's no code to actually implement this nowadays, the configure.ac
stuff is a relic.

It's only used on the tracker-resdump helper, and can be easily
replaced with the GLib counterparts.

If other unices want a similar level of protection, additional
implementations should be added. In the mean time, it's just
harsh to make tracker impossible to compile there.

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

Hopefully just temporarily. At the very least the processing
should be taken out of the extractor threads, as it requires
file operations that are not allowed there.

In the worst case, we must reconsider this dependency, as it
might become a window of opportunity to writing on the filesystem,
even if on a very specific folder.

This is something we can do on master, older stable releases will
have to stick to optional support.

The threads calling the new tracker_seccomp_init() function, and all
threads/processes spawned from these, will enter a restricted mode
where only a few sensible syscalls are allowed, and more specifically,
filesystem/socket access are restricted to being respectively
readonly and local only.

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

The brown paper bag release that 1.11.0.1 was meant to be, because FML.

For real, modify configure.ac

As specified in https://www.w3.org/TR/rdf-sparql-XMLres/. This cursor
implementation is able to read the XML expected under that content
type.

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

This is yet another libtracker-sparql backend to connect to remote
HTTP SPARQL endpoints. Connections are made explicitly through the
tracker_sparql_connection_remote_new() API call, passing a server
to connect to. This commit introduces support for
application/sparql-results+json as specified in
https://www.w3.org/TR/sparql11-results-json/. XML format will be
handled next.

Just readonly queries are supported, and provided there's no
authentication schemes.

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

Not much worth releasing yet, but having tracker-1.10 have a higher
soname than master is confusing.

There is a --enable/disable-png check below.

So I can use G_DECLARE_DERIVABLE_TYPE() instead of writing out
everything manually.

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

Gsettings are self-documenting, plus translatable. There is no need to
duplicate this documentation, and even less if it focuses on the
deprecated keyfile format. It is time to hide that under the rug.

sqlite3_errstr was added in that version.

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

We can point to the tracker product.

Only do this if we need to load the FTS5 module, sqlite3 might have
been compiled with SQLITE_OMIT_LOAD_EXTENSION, which will make things
go very wrong (poking NULL vfuncs in a 0'ed out sqlite3_api_routines)
at runtime.

This facility must be enabled if we need to load our FTS module, so
bail out at configure time if it's not there.

It seems to break the build because of an Automake bug, see:
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928>

This reverts commit 5ae20fb9.

Lesson learned (again): don't do something just because Automake tells
you to.

Notice the same thing happened back in commit e46bfc1c which
was reverted again in b1e3997c.

Based on this warning from libtoolize:

    libtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT'