Re: [Tracker] Rescue tracker db backup

[Philip Van Hoof]

On Fri, 2012-12-14 at 05:45 +0200, Jānis Rukšāns wrote:

Hi Janis,

> Thanks for your answers!
> 
> >> Integrity check failure means that your N9 had a serious HW failure. For
> >> that you should return your device to a Nokia service center.
> 
> I figure so (the first thing that comes to mind is NAND failing).
> Still, I will need to get that data back into the phone once it's
> fixed.

nod

> >> Note that you should completely shut down Tracker's process and that
> >> this isn't easy as your N9's other softwares will periodically
> >> reactivate it based on their needs. So those process must be shut down
> >> too to avoid this, while you are working with the files.
> 
> My idea is/was to do hard-reset followed by a backup. That gives a
> clean db, which can be copied to a PC, updated from the real backup
> and then used for restore.

Sadly that will also copy-back the corruption from your backup.db to
your then overwritten meta.db.


> So far I've been able to extract the most important data I need using
> plain SQL, but getting the full graph into another db calls for some
> custom coding to adjust resource IDs and URIs. Having some progress on
> that, too. Too bad tracker does not export it's ontology functions (at
> least Fedora -devel packages don't have those headers), had to write
> that part from scratch.

Sounds good.

> By the way, are the :graph fields actually used anywhere? Or can I
> safely use NULL or some existing graph ID?

They are actually used on the N9.

Kind regards,

Philip


-- 


Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Low hanging fruit from the catacombs of Jolla

[Philip Van Hoof]

On Fri, 2012-12-14 at 08:39 +, Martyn Russell wrote:

> * tracker-0.10.37-fix-linking-with-newer-toolchain.patch
> * tracker-0.10.37-fix-linking-with-newer-glib.patch
> 
>These two shouldn't be needed - looks like a fix added to circumvent
>breaks elsewhere. Not something we should be applying upstream AFAICS.

Yes I agree, adding manual -lgio-2.0 and -lgthread-2.0 is just wrong.

> * tracker-0.10.37-add-userguides-service-for-maemo.patch
> 
>This seems unnecessary with >= 0.14.

Ok. That's strange because they are using 0.14.2.

> * 0005-Fix-missing-gobject-introspection-checks.patch
> 
>This is to disable introspection. So not what we want upstream. There
>is a --disable-introspection switch already for configure. Perhaps
>this wasn't around a while ago?

I'll communicate this to them when I speak them again.

> * 0003-tracker-0.9.26-create-tests-aegis.patch
> 
>This is really not for the public version of Tracker I would say.

I even wonder whether Jolla ships with Aegis ...

> * 0002-Tracker-extract-Parse-the-video-filename-to-obtain-e.patch 
> 
>Reviewed, but needs resolution as Aleksander says. Still applies too.

Ok check.

> * 0001-Tracker-0.7.23-desktop-files.patch
> 
>Pushed.

Thanks awesome.

> Thanks for bringing these up Philip.

Np

Kind regards,

Philip

-- 


Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Low hanging fruit from the catacombs of Jolla

[Philip Van Hoof]

On Fri, 2012-12-14 at 13:56 +, Martyn Russell wrote:
> On 14/12/12 13:52, Philip Van Hoof wrote:
> > On Fri, 2012-12-14 at 08:39 +, Martyn Russell wrote:
> >
> >> * tracker-0.10.37-fix-linking-with-newer-toolchain.patch
> >> * tracker-0.10.37-fix-linking-with-newer-glib.patch
> >>
> >> These two shouldn't be needed - looks like a fix added to circumvent
> >> breaks elsewhere. Not something we should be applying upstream AFAICS.
> >
> > Yes I agree, adding manual -lgio-2.0 and -lgthread-2.0 is just wrong.
> >
> >> * tracker-0.10.37-add-userguides-service-for-maemo.patch
> >>
> >> This seems unnecessary with >= 0.14.
> >
> > Ok. That's strange because they are using 0.14.2.
> 
> Actually, they should stay clear of 0.14.2 and use 0.14.4, there are 
> some nasty issues fixed between those versions.

I'll tell them, or feel free to ping Aard on #jollamobile - freenode.

> If they are using 0.14 why is the patch mentioning 0.10 - I guess 
> they're just using the patch because it was there before. They should be 
> able to remove that.

Yeah, probably.

> >> * 0005-Fix-missing-gobject-introspection-checks.patch
> >>
> >> This is to disable introspection. So not what we want upstream. There
> >> is a --disable-introspection switch already for configure. Perhaps
> >> this wasn't around a while ago?
> >
> > I'll communicate this to them when I speak them again.
> 
> I could be wrong, but this uses automake macros I think and they didn't 
> have that macro set up on their systems before at Nokia. It's quite 
> stupid to require a macro to disable the thing the macro is installed as 
> part of, but that's how gtkdoc and the introspection foo work. This 
> might be why this is still needed.

Hrmm, somebody should finally fix this in gtkdoc and (its) autofoo. For
how many years has this been bugging people? yes..years. meh

> >> * 0003-tracker-0.9.26-create-tests-aegis.patch
> >>
> >> This is really not for the public version of Tracker I would say.
> >
> > I even wonder whether Jolla ships with Aegis ...
> 
> I would dump it entirely, it caused no end of disruption and problems 
> for developers and users throughout.
> 
> But it's not my platform :)

I agree, and I agree that it's also not my platform :).

> >> * 0002-Tracker-extract-Parse-the-video-filename-to-obtain-e.patch  
> >>
> >> Reviewed, but needs resolution as Aleksander says. Still applies too.
> >
> > Ok check.
> >
> >> * 0001-Tracker-0.7.23-desktop-files.patch
> >>
> >> Pushed.
> >
> > Thanks awesome.
> 
> No problem :)

Cheers, which reminds me: are you going to fosdem Martyn? :)


Philip


-- 


Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] Allowing exteral processes like MTP handling to do extraction and sparql insert, bypassing miner-fs

[Philip Van Hoof]

Hi there,

SO I started taking a look at how tracker-miner-file.c processes the
files by sending it to the tracker-extract process by using the
libtracker-extract library.

It uses quite a bit of GAsync calls in cascading order before it all is
done processing. But so far only the tracker:volume handling is in the
wrong location and not accessible by libtracker-extract users.

That is the miner_files_add_to_datasource call in tracker-miner-file.c
and all the code that depends on this call: mostly volume handling.

Everything else I've started porting to this extract-test.c file that
probably, most likely even, doesn't yet compile but that has the bean
for a get_metadata_async and a get_metadata_finish API that will be
usable by a external process like an MTP daemon.

The idea is to put such an API into libtracker-extract and then nicely
wrap it with Qt, C#, Vala, etc bindings.

I've just attached my unfinished business as my gf has arrived and I
really need to stop coding in a few minutes (or else ...).

:-)

Any experienced Tracker developer will see where I'm going with that
code. An early review would be welcome.
 
Kind regards,

Philip

-- 


Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be
#include 
#include 

#define MTP_GRAPH_URN "urn:uuid:fd9d3960-4600-11e2-bcfd-0800200c9a66"

typedef struct {
	TrackerSparqlBuilder *sparql
	GFile *file;
	gchar *urn;
	gchar *url;
	gchar *filename;
	GSimpleAsyncResult *simple;
} ExtractionData;

static GSimpleAsyncResult*
extraction_data_free (ExtractionData *data)
{
	GSimpleAsyncResult *simple = data->simple;
	
	g_free (data->urn);
	g_free (data->url);
	g_free (data->filename);

	if (data->file) {
		g_object_unref (data->file);
	}

	if (data->sparql) {
		g_object_unref (data->sparql);
	}

	return simple;
}

/* TODO: port (not necessarily easy to add)
static void
miner_files_add_to_datasource (TrackerMinerFiles*mf,
   GFile*file,
   TrackerSparqlBuilder *sparql)
{
	TrackerMinerFilesPrivate *priv;
	const gchar *removable_device_uuid;
	gchar *removable_device_urn, *uri;
	const gchar *urn;
	gboolean is_iri;

	priv = TRACKER_MINER_FILES_GET_PRIVATE (mf);
	uri = g_file_get_uri (file);

	removable_device_uuid = tracker_storage_get_uuid_for_file (priv->storage, file);

	if (removable_device_uuid) {
		removable_device_urn = g_strdup_printf (TRACKER_DATASOURCE_URN_PREFIX "%s",
		removable_device_uuid);
	} else {
		removable_device_urn = g_strdup (TRACKER_NON_REMOVABLE_MEDIA_DATASOURCE_URN);
	}

	urn = miner_files_get_file_urn (mf, file, &is_iri);

	if (is_iri) {
		tracker_sparql_builder_subject_iri (sparql, urn);
	} else {
		tracker_sparql_builder_subject (sparql, urn);
	}

	tracker_sparql_builder_predicate (sparql, "a");
	tracker_sparql_builder_object (sparql, "nfo:FileDataObject");

	tracker_sparql_builder_predicate (sparql, "nie:dataSource");
	tracker_sparql_builder_object_iri (sparql, removable_device_urn);

	tracker_sparql_builder_predicate (sparql, "tracker:available");
	tracker_sparql_builder_object_boolean (sparql, TRUE);

	g_free (removable_device_urn);
	g_free (uri);
}
*/

static void
sparql_builder_finish (ExtractionData *data,
   const gchar   *preupdate,
   const gchar   *postupdate,
   const gchar   *where)
{
	tracker_sparql_builder_graph_close (data->sparql);
	tracker_sparql_builder_insert_close (data->sparql);

	if (where && *where) {
		tracker_sparql_builder_where_open (data->sparql);
		tracker_sparql_builder_append (data->sparql, where);
		tracker_sparql_builder_where_close (data->sparql);
	}

	/* Prepend preupdate queries */
	if (preupdate && *preupdate) {
		tracker_sparql_builder_prepend (data->sparql, preupdate);
	}

	/* Append postupdate */
	if (postupdate && *postupdate) {
		tracker_sparql_builder_append (data->sparql, postupdate);
	}
}

static void
extractor_get_embedded_metadata_cb (GObject *object, GAsyncResult *result, gpointer user_data)
{
	ExtractionData *data = user_data;
	TrackerSparqlBuilder *preupdate, *postupdate, *sparql;
	const gchar *where;
	GError *error = NULL;
	TrackerExtractInfo *info = tracker_extract_client_get_metadata_finish (object, result, &error);

	if (error == NULL) {
		TrackerSparqlBuilder *preupdate, *postupdate, *sparql;
		const gchar *where;

		preupdate = tracker_extract_info_get_preupdate_builder (info);
		postupdate = tracker_extract_info_get_postupdate_builder (info);
		sparql = tracker_extract_info_get_metadata_builder (info);
		where = tracker_extract_info_get_where_clause (info);

		sparql_builder_finish (data, tracker_sparql_builder_get_result (preupdate),
		

Re: [Tracker] Allowing exteral processes like MTP handling to do extraction and sparql insert, bypassing miner-fs

[Philip Van Hoof]

Sorry, couldn't resist. Some obvious fixes and added some TODO marks and
questions in the code for whoever reviews this idea to read.

Kind regards,

Philip

On Fri, 2012-12-14 at 18:15 +0100, Philip Van Hoof wrote:
> Hi there,
> 
> SO I started taking a look at how tracker-miner-file.c processes the
> files by sending it to the tracker-extract process by using the
> libtracker-extract library.
> 
> It uses quite a bit of GAsync calls in cascading order before it all is
> done processing. But so far only the tracker:volume handling is in the
> wrong location and not accessible by libtracker-extract users.
> 
> That is the miner_files_add_to_datasource call in tracker-miner-file.c
> and all the code that depends on this call: mostly volume handling.
> 
> Everything else I've started porting to this extract-test.c file that
> probably, most likely even, doesn't yet compile but that has the bean
> for a get_metadata_async and a get_metadata_finish API that will be
> usable by a external process like an MTP daemon.
> 
> The idea is to put such an API into libtracker-extract and then nicely
> wrap it with Qt, C#, Vala, etc bindings.
> 
> I've just attached my unfinished business as my gf has arrived and I
> really need to stop coding in a few minutes (or else ...).
> 
> :-)
> 
> Any experienced Tracker developer will see where I'm going with that
> code. An early review would be welcome.
>  
> Kind regards,
> 
> Philip
> 
> _______
> tracker-list mailing list
> tracker-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/tracker-list

-- 


Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be
#include 
#include 

#define MTP_GRAPH_URN "urn:uuid:fd9d3960-4600-11e2-bcfd-0800200c9a66"

typedef struct {
	TrackerSparqlBuilder *sparql
	GFile *file;
	gchar *urn;
	gchar *url;
	GSimpleAsyncResult *simple;
} ExtractionData;

static GSimpleAsyncResult*
extraction_data_free (ExtractionData *data)
{
	GSimpleAsyncResult *simple = data->simple;
	
	g_free (data->urn);
	g_free (data->url);

	if (data->file) {
		g_object_unref (data->file);
	}

	if (data->sparql) {
		g_object_unref (data->sparql);
	}

	return simple;
}

/* TODO: port (not necessarily easy to add)
static void
miner_files_add_to_datasource (TrackerMinerFiles*mf,
   GFile*file,
   TrackerSparqlBuilder *sparql)
{
	TrackerMinerFilesPrivate *priv;
	const gchar *removable_device_uuid;
	gchar *removable_device_urn, *uri;
	const gchar *urn;
	gboolean is_iri;

	priv = TRACKER_MINER_FILES_GET_PRIVATE (mf);
	uri = g_file_get_uri (file);

	removable_device_uuid = tracker_storage_get_uuid_for_file (priv->storage, file);

	if (removable_device_uuid) {
		removable_device_urn = g_strdup_printf (TRACKER_DATASOURCE_URN_PREFIX "%s",
		removable_device_uuid);
	} else {
		removable_device_urn = g_strdup (TRACKER_NON_REMOVABLE_MEDIA_DATASOURCE_URN);
	}

	urn = miner_files_get_file_urn (mf, file, &is_iri);

	if (is_iri) {
		tracker_sparql_builder_subject_iri (sparql, urn);
	} else {
		tracker_sparql_builder_subject (sparql, urn);
	}

	tracker_sparql_builder_predicate (sparql, "a");
	tracker_sparql_builder_object (sparql, "nfo:FileDataObject");

	tracker_sparql_builder_predicate (sparql, "nie:dataSource");
	tracker_sparql_builder_object_iri (sparql, removable_device_urn);

	tracker_sparql_builder_predicate (sparql, "tracker:available");
	tracker_sparql_builder_object_boolean (sparql, TRUE);

	g_free (removable_device_urn);
	g_free (uri);
}
*/

static void
sparql_builder_finish (ExtractionData *data,
   const gchar   *preupdate,
   const gchar   *postupdate,
   const gchar   *where)
{
	tracker_sparql_builder_graph_close (data->sparql);
	tracker_sparql_builder_insert_close (data->sparql);

	if (where && *where) {
		tracker_sparql_builder_where_open (data->sparql);
		tracker_sparql_builder_append (data->sparql, where);
		tracker_sparql_builder_where_close (data->sparql);
	}

	/* Prepend preupdate queries */
	if (preupdate && *preupdate) {
		tracker_sparql_builder_prepend (data->sparql, preupdate);
	}

	/* Append postupdate */
	if (postupdate && *postupdate) {
		tracker_sparql_builder_append (data->sparql, postupdate);
	}
}

static void
extractor_get_embedded_metadata_cb (GObject *object, GAsyncResult *result, gpointer user_data)
{
	ExtractionData *data = user_data;
	TrackerSparqlBuilder *preupdate, *postupdate, *sparql;
	const gchar *where;
	GError *error = NULL;
	TrackerExtractInfo *info = tracker_extract_client_get_metadata_finish 

Re: [Tracker] Allowing exteral processes like MTP handling to do extraction and sparql insert, bypassing miner-fs

[Philip Van Hoof]

Version that compiles and works (but without volume management)

gcc extract-test.c `pkg-config gio-2.0 tracker-extract-0.16
tracker-sparql-0.16 --cflags --libs` -ggdb

On Fri, 2012-12-14 at 18:40 +0100, Philip Van Hoof wrote:
> Sorry, couldn't resist. Some obvious fixes and added some TODO marks and
> questions in the code for whoever reviews this idea to read.
> 
> Kind regards,
> 
> Philip
> 
> On Fri, 2012-12-14 at 18:15 +0100, Philip Van Hoof wrote:
> > Hi there,
> > 
> > SO I started taking a look at how tracker-miner-file.c processes the
> > files by sending it to the tracker-extract process by using the
> > libtracker-extract library.
> > 
> > It uses quite a bit of GAsync calls in cascading order before it all is
> > done processing. But so far only the tracker:volume handling is in the
> > wrong location and not accessible by libtracker-extract users.
> > 
> > That is the miner_files_add_to_datasource call in tracker-miner-file.c
> > and all the code that depends on this call: mostly volume handling.
> > 
> > Everything else I've started porting to this extract-test.c file that
> > probably, most likely even, doesn't yet compile but that has the bean
> > for a get_metadata_async and a get_metadata_finish API that will be
> > usable by a external process like an MTP daemon.
> > 
> > The idea is to put such an API into libtracker-extract and then nicely
> > wrap it with Qt, C#, Vala, etc bindings.
> > 
> > I've just attached my unfinished business as my gf has arrived and I
> > really need to stop coding in a few minutes (or else ...).
> > 
> > :-)
> > 
> > Any experienced Tracker developer will see where I'm going with that
> > code. An early review would be welcome.
> >  
> > Kind regards,
> > 
> > Philip
> > 
> > ___
> > tracker-list mailing list
> > tracker-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/tracker-list
> 
> ___
> tracker-list mailing list
> tracker-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/tracker-list

-- 


Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be
#include 
#include 

#define MTP_GRAPH_URN "urn:uuid:fd9d3960-4600-11e2-bcfd-0800200c9a66"

typedef struct {
	TrackerSparqlBuilder *sparql;
	GFile *file;
	gchar *urn;
	gchar *url;
	GSimpleAsyncResult *simple;
} ExtractionData;

static GSimpleAsyncResult*
extraction_data_free (ExtractionData *data)
{
	GSimpleAsyncResult *simple = data->simple;
	
	g_free (data->urn);
	g_free (data->url);

	if (data->file) {
		g_object_unref (data->file);
	}

	if (data->sparql) {
		g_object_unref (data->sparql);
	}

	return simple;
}

/* TODO: port (not necessarily easy to add)
static void
miner_files_add_to_datasource (TrackerMinerFiles*mf,
   GFile*file,
   TrackerSparqlBuilder *sparql)
{
	TrackerMinerFilesPrivate *priv;
	const gchar *removable_device_uuid;
	gchar *removable_device_urn, *uri;
	const gchar *urn;
	gboolean is_iri;

	priv = TRACKER_MINER_FILES_GET_PRIVATE (mf);
	uri = g_file_get_uri (file);

	removable_device_uuid = tracker_storage_get_uuid_for_file (priv->storage, file);

	if (removable_device_uuid) {
		removable_device_urn = g_strdup_printf (TRACKER_DATASOURCE_URN_PREFIX "%s",
		removable_device_uuid);
	} else {
		removable_device_urn = g_strdup (TRACKER_NON_REMOVABLE_MEDIA_DATASOURCE_URN);
	}

	urn = miner_files_get_file_urn (mf, file, &is_iri);

	if (is_iri) {
		tracker_sparql_builder_subject_iri (sparql, urn);
	} else {
		tracker_sparql_builder_subject (sparql, urn);
	}

	tracker_sparql_builder_predicate (sparql, "a");
	tracker_sparql_builder_object (sparql, "nfo:FileDataObject");

	tracker_sparql_builder_predicate (sparql, "nie:dataSource");
	tracker_sparql_builder_object_iri (sparql, removable_device_urn);

	tracker_sparql_builder_predicate (sparql, "tracker:available");
	tracker_sparql_builder_object_boolean (sparql, TRUE);

	g_free (removable_device_urn);
	g_free (uri);
}
*/

static void
sparql_builder_finish (ExtractionData *data,
   const gchar   *preupdate,
   const gchar   *postupdate,
   const gchar   *sparql,
   const gchar   *where)
{
	if (sparql && *sparql) {
		if (data->urn != NULL) {
			gchar *str;
			str = g_strdup_printf ("<%s>", data->urn);
			tracker_sparql_builder_append (data->sparql, str);
			g_free (str);
		} el

[Tracker] Request for review, API allowing external software like MTP daemons to get metadata as correct sparql insert

[Philip Van Hoof]

Hi guys,

I have finished my feature that allows MTP daemons to through an API get
a correct SPARQL INSERT query with extracted metadata for a file.

This is the branch: extract-sparql 
http://git.gnome.org/browse/tracker/log/?h=extract-sparql

This is the currently only commit:
http://git.gnome.org/browse/tracker/commit/?h=extract-sparql&id=e4af9b34e22b60d37251426a29dfcd9b566f6e0e


This is the newly added API:

static void
on_finished (GObject *none, GAsyncResult *result, gpointer user_data)
{
GMainLoop *loop = user_data;
GError *error = NULL;
gchar *sparql = tracker_extract_get_sparql_finish (result, &error);

if (error == NULL) {
g_print ("%s", sparql);
g_free (sparql);
} else {
g_error("%s", error->message);
}

g_clear_error (&error);

g_main_loop_quit (loop);
}

int main (int argc, char **argv)
{
const gchar *file = "/tmp/file.png";
const gchar *dest = "file:///tmp/destination.png"
GMainLoop *loop;

g_type_init();

loop = g_main_loop_new (NULL, FALSE);
tracker_extract_get_sparql (file, dest, NULL, time(0),
time(0), on_finished, loop);

g_main_loop_run (loop);

g_object_unref (loop);

return 0;
  }

I have also added usage of the API to the tracker-sparql binary:

$ cp /home/pvanhoof/Documents/Photos/pasfoto-small.png /tmp/tempfile.png
$ /opt/tracker/bin/tracker-sparql --metadata-file-path=/tmp/tempfile.png \
--metadata-graph-urn=urn:uuid:173b2520-4828-11e2-bcfd-0800200c9a66 \
--metadata-dest-url=file:///home/pvanhoof/Documents/Photos/photo.png


INSERT SILENT {
GRAPH  {
_:file a nfo:FileDataObject , nie:InformationElement ;
 nfo:fileName "photo.png" ;
 nfo:fileSize 38155 ;
 nfo:fileLastModified "2012-12-17T09:20:18Z" ;
 nfo:fileLastAccessed "2012-12-17T09:20:18Z" ;
 nie:isStoredAs _:file ;
 nie:url "file:///home/pvanhoof/Documents/Photos/photo.png" ;
 nie:mimeType "image/png" ;
 a nfo:FileDataObject ;
 nie:dataSource 
 ;
 tracker:available true .
_:file a nfo:Image , nmm:Photo ;
 nfo:width 150 ;
 nfo:height 192 ;
 nmm:dlnaProfile "PNG_LRG" ;
 nmm:dlnaMime "image/png" .

}
}

$ 


Please review.

Kind regards,

Philip

-- 


Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Allowing exteral processes like MTP handling to do extraction and sparql insert, bypassing miner-fs

[Philip Van Hoof]

check my last mail to the ml

--
Sent from my Nokia N9On 17/12/12 10:44 Martyn Russell wrote:
On 15/12/12 08:52, Philip Van Hoof wrote:
> Version that compiles and works (but without volume management)
>
> gcc extract-test.c `pkg-config gio-2.0 tracker-extract-0.16
> tracker-sparql-0.16 --cflags --libs` -ggdb

Philip, not had time to look at this yet, but I would suggest a git 
branch upstream and the location of the source to play with :)

Thanks,

-- 
Regards,
Martyn

Founder and CEO of Lanedo GmbH.


___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Request for review, API allowing external software like MTP daemons to get metadata as correct sparql insert

[Philip Van Hoof]

Is somebody planning to review this?

Martyn? Jürg? Alexander? Carlos? :)

Kind regards,

Philip

On Mon, 2012-12-17 at 10:35 +0100, Philip Van Hoof wrote:
> Hi guys,
> 
> I have finished my feature that allows MTP daemons to through an API get
> a correct SPARQL INSERT query with extracted metadata for a file.
> 
> This is the branch: extract-sparql 
> http://git.gnome.org/browse/tracker/log/?h=extract-sparql
> 
> This is the currently only commit:
> http://git.gnome.org/browse/tracker/commit/?h=extract-sparql&id=e4af9b34e22b60d37251426a29dfcd9b566f6e0e
> 
> 
> This is the newly added API:
> 
> static void
> on_finished (GObject *none, GAsyncResult *result, gpointer user_data)
> {
> GMainLoop *loop = user_data;
> GError *error = NULL;
> gchar *sparql = tracker_extract_get_sparql_finish (result, &error);
> 
> if (error == NULL) {
> g_print ("%s", sparql);
> g_free (sparql);
> } else {
> g_error("%s", error->message);
> }
> 
> g_clear_error (&error);
> 
> g_main_loop_quit (loop);
> }
> 
> int main (int argc, char **argv)
> {
> const gchar *file = "/tmp/file.png";
> const gchar *dest = "file:///tmp/destination.png"
> GMainLoop *loop;
> 
> g_type_init();
> 
> loop = g_main_loop_new (NULL, FALSE);
> tracker_extract_get_sparql (file, dest, NULL, time(0),
> time(0), on_finished, loop);
> 
> g_main_loop_run (loop);
> 
> g_object_unref (loop);
> 
> return 0;
>   }
> 
> I have also added usage of the API to the tracker-sparql binary:
> 
> $ cp /home/pvanhoof/Documents/Photos/pasfoto-small.png /tmp/tempfile.png
> $ /opt/tracker/bin/tracker-sparql --metadata-file-path=/tmp/tempfile.png \
>   --metadata-graph-urn=urn:uuid:173b2520-4828-11e2-bcfd-0800200c9a66 \
>   --metadata-dest-url=file:///home/pvanhoof/Documents/Photos/photo.png
> 
> 
> INSERT SILENT {
> GRAPH  {
> _:file a nfo:FileDataObject , nie:InformationElement ;
>nfo:fileName "photo.png" ;
>nfo:fileSize 38155 ;
>nfo:fileLastModified "2012-12-17T09:20:18Z" ;
>nfo:fileLastAccessed "2012-12-17T09:20:18Z" ;
>nie:isStoredAs _:file ;
>nie:url "file:///home/pvanhoof/Documents/Photos/photo.png" ;
>nie:mimeType "image/png" ;
>a nfo:FileDataObject ;
>nie:dataSource 
>  ;
>tracker:available true .
> _:file a nfo:Image , nmm:Photo ;
>nfo:width 150 ;
>nfo:height 192 ;
>nmm:dlnaProfile "PNG_LRG" ;
>nmm:dlnaMime "image/png" .
> 
> }
> }
> 
> $ 
> 
> 
> Please review.
> 
> Kind regards,
> 
> Philip
> 

-- 
Philip Van Hoof
Freelance software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Request for review, API allowing external software like MTP daemons to get metadata as correct sparql insert

[Philip Van Hoof]

Hey Guys,

Again, is somebody planning to review this? If not I'm planning to go
ahead and push it to master.

Kind regards,

Philip

On Sun, 2012-12-23 at 19:16 +0100, Philip Van Hoof wrote:
> Is somebody planning to review this?
> 
> Martyn? Jürg? Alexander? Carlos? :)
> 
> Kind regards,
> 
> Philip
> 
> On Mon, 2012-12-17 at 10:35 +0100, Philip Van Hoof wrote:
> > Hi guys,
> > 
> > I have finished my feature that allows MTP daemons to through an API get
> > a correct SPARQL INSERT query with extracted metadata for a file.
> > 
> > This is the branch: extract-sparql 
> > http://git.gnome.org/browse/tracker/log/?h=extract-sparql
> > 
> > This is the currently only commit:
> > http://git.gnome.org/browse/tracker/commit/?h=extract-sparql&id=e4af9b34e22b60d37251426a29dfcd9b566f6e0e
> > 
> > 
> > This is the newly added API:
> > 
> > static void
> > on_finished (GObject *none, GAsyncResult *result, gpointer user_data)
> > {
> > GMainLoop *loop = user_data;
> > GError *error = NULL;
> > gchar *sparql = tracker_extract_get_sparql_finish (result, &error);
> > 
> > if (error == NULL) {
> > g_print ("%s", sparql);
> > g_free (sparql);
> > } else {
> > g_error("%s", error->message);
> > }
> > 
> > g_clear_error (&error);
> > 
> > g_main_loop_quit (loop);
> > }
> > 
> > int main (int argc, char **argv)
> > {
> > const gchar *file = "/tmp/file.png";
> > const gchar *dest = "file:///tmp/destination.png"
> > GMainLoop *loop;
> > 
> > g_type_init();
> > 
> > loop = g_main_loop_new (NULL, FALSE);
> > tracker_extract_get_sparql (file, dest, NULL, time(0),
> > time(0), on_finished, loop);
> > 
> > g_main_loop_run (loop);
> > 
> > g_object_unref (loop);
> > 
> > return 0;
> >   }
> > 
> > I have also added usage of the API to the tracker-sparql binary:
> > 
> > $ cp /home/pvanhoof/Documents/Photos/pasfoto-small.png /tmp/tempfile.png
> > $ /opt/tracker/bin/tracker-sparql --metadata-file-path=/tmp/tempfile.png \
> > --metadata-graph-urn=urn:uuid:173b2520-4828-11e2-bcfd-0800200c9a66 \
> > --metadata-dest-url=file:///home/pvanhoof/Documents/Photos/photo.png
> > 
> > 
> > INSERT SILENT {
> > GRAPH  {
> > _:file a nfo:FileDataObject , nie:InformationElement ;
> >  nfo:fileName "photo.png" ;
> >  nfo:fileSize 38155 ;
> >  nfo:fileLastModified "2012-12-17T09:20:18Z" ;
> >  nfo:fileLastAccessed "2012-12-17T09:20:18Z" ;
> >  nie:isStoredAs _:file ;
> >  nie:url "file:///home/pvanhoof/Documents/Photos/photo.png" ;
> >  nie:mimeType "image/png" ;
> >  a nfo:FileDataObject ;
> >  nie:dataSource 
> >  ;
> >  tracker:available true .
> > _:file a nfo:Image , nmm:Photo ;
> >  nfo:width 150 ;
> >  nfo:height 192 ;
> >  nmm:dlnaProfile "PNG_LRG" ;
> >  nmm:dlnaMime "image/png" .
> > 
> > }
> > }
> > 
> > $ 
> > 
> > 
> > Please review.
> > 
> > Kind regards,
> > 
> > Philip
> > 
> 

-- 
Philip Van Hoof
Freelance software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Request for review, API allowing external software like MTP daemons to get metadata as correct sparql insert

[Philip Van Hoof]

Hey Martyn,

I have quite a bit on my plate lately with renovating houses and other
stuff, like finding a new customer etc, that I'll delay working on this
for some time for now.

If somebody wants to pick it up, I mostly agree with your review
commends and adapting the branch to fix these issues would be a great
start.

Perhaps I'll pick it up myself starting by fixing these issues. So if
somebody does start adapting the branch a little note would be
appreciated (to avoid doubling efforts).

Kind regards,

Philip

On Fri, 2013-01-04 at 15:20 +, Martyn Russell wrote:
> On 03/01/13 21:30, Philip Van Hoof wrote:
> > Hey Guys,
> 
> Hello Philip,
> 
> > Again, is somebody planning to review this? If not I'm planning to go
> > ahead and push it to master.
> 
> I have just reviewed it briefly. My comments:
> 
> 1. There are some white space issues here which need cleaning up. 
> Trailing white space, etc. see 
> src/libtracker-extract/tracker-extract-sparql.c.
> 
> 2. Coding style too.
> 
> 3. Shouldn't you use the tracker_sparql_* API properly in 
> sparql_builder_finish() ? WE're appending strings here but we have APIs 
> for inserting URNs and blank notes already which could make this a lot 
> easier. We should use these:
> 
>tracker_sparql_builder_object_blank_open() and _close()
>(unless you need to refer to _:file later on of course)
> 
>and
> 
>tracker_sparql_builder_object_iri()
> 
> 3. Extra spaces before end of function are unnecessary ;)
> +   g_clear_error (&error);
> +
> 
> 4. I would have made sparql_builder_finish() take arguments in the order 
> we use in TrackerExtractInfo for consistency, but that's me being pedantic.
> 
> 5. tracker_extract_get_sparql() takes a "temp_file", is teh file 
> temporary? Is it a URL or a path? we should be more specific with 
> variables like this especially if this is new API.
> 
> 6. No need for the check here, just strdup it... also, I would keep the 
> variable name the same so it's clear what it is we're passing (i.e. a urn).
> 
> +   if (graph) {
> +   data->graph_urn = g_strdup (graph);
> +   }
> 
> 7. Why not use -1 or a valid time_t for last_mod and last_access? Not 
> sure why we need the extra _set booleans here.
> 
> +   if (last_mod != 0) {
> +   data->last_mod = last_mod;
> +   data->last_mod_set = TRUE;
> +   } else {
> +   data->last_mod_set = FALSE;
> +   }
> 
> 8. This looks a bit wrong to me. First, we always set the file from the 
> temp_file variable given, but then we might set the url to be something 
> different based on dest_url. Not only is this confusing but I expect it 
> to cause problems inside tracker if the file used for the URL != file 
> used for the PATH. I can see why you want to do this, but we didn't do 
> it this way round with Nokia, we issued a separate update for the file 
> details when it actually was saved as something else. The problem I see 
> is that you could have a query which returns urn->path as /foo and 
> urn->uri as file:///bar and that's clearly wrong:
> 
> +   data->storage = tracker_storage_new ();
> +   data->file = g_file_new_for_path(temp_file);
> +   if (dest_url) {
> +   data->url = g_strdup (dest_url);
> +   } else {
> +   data->url = g_file_get_uri (data->file);
> +   }
> 
> You could ALWAYS set the url from the file and keep the dest_url as a 
> separate struct member to help avoid any confusion and I think it would 
> make a lot more sense here.
> 
> 9. No need to use a variable here, you can just return the function 
> value with a cast I imagine:
> 
> +   res = g_simple_async_result_get_op_res_gpointer (simple);
> +
> +   return res;
> 
> 
> 10. Please put system includes before glib and libraries (coding style):
> 
> +#include 
> +#include 
> +#include 
> +
> 
> 11. I wonder why you don't provide a sync API too?
> 
> 12. This is wrong too:
> 
> +#endif /* __LIBTRACKER_EXTRACT_ENCODING_H__ */
> 
> 13. Copyright should probably be 2013 ;)
> 
> 14. Why do we change src/libtracker-common/tracker-marshal.list at all?
> 
> 15. I've not checked the whole on_fileinfo_received() part because it's 
> really complex in the miner-fs already and we were fixing problems there 
> for years related to parent existence and creation prior to insertion of 
> a child path. This worries me about this branch because I get the 
> impression from quick review that it's not really addressed fully. You 
> also seem to allow parent 

Re: [Tracker] Request for review, API allowing external software like MTP daemons to get metadata as correct sparql insert

[Philip Van Hoof]

On Fri, 2013-01-04 at 15:20 +, Martyn Russell wrote:
> On 03/01/13 21:30, Philip Van Hoof wrote:

I'll reply to the most important parts of your review:

> 8. This looks a bit wrong to me. First, we always set the file from the 
> temp_file variable given, but then we might set the url to be something 
> different based on dest_url. Not only is this confusing but I expect it 
> to cause problems inside tracker if the file used for the URL != file 
> used for the PATH. I can see why you want to do this, but we didn't do 
> it this way round with Nokia, we issued a separate update for the file 
> details when it actually was saved as something else. The problem I see 
> is that you could have a query which returns urn->path as /foo and 
> urn->uri as file:///bar and that's clearly wrong:

Yes the separate update was/is the solution for Nokia's N9. The idea
here or now is that no separate update would be needed at all with this
solution: the MTP daemon does both the extraction and the initial sparql
insert in one pass.

And then the MTP daemon does a rename() call from tempfile to dest-url.
Completing the file transfer.

That sparql insert can happen while the download takes place (allowing
the MTP daemon to insert protocol based metadata before file data is
transferred and available - for extraction).

> 15. I've not checked the whole on_fileinfo_received() part because it's 
> really complex in the miner-fs already and we were fixing problems there 
> for years related to parent existence and creation prior to insertion of 
> a child path. This worries me about this branch because I get the 
> impression from quick review that it's not really addressed fully. You 
> also seem to allow parent URNs to not exist before adding a child to the 
> database. That's not how we've done things in the miner-fs and this 
> really breaks what people using the DB can expect. Correct me if I am wrong.

Right, parent URNs aren't yet created with this solution and should
probably be.

I guess putting INSERT queries upfront the metadata one needs to be
possible as well as getting a separate query for in case the MTP daemon
wants to do multiple passes. ie. First protocol based metadata insert,
which needs the parent URNs at that point and which doesn't yet need the
file content to be available, then extraction based metadata insert; for
which the file content must be available.

And what this creates must also be compatible with what miner-fs will
otherwise create.

The idea here is that while a (large) file is being transferred,
protocol based metadata is already in the Nepomuk store available for
applications that are interested in tracker:available-false 'to be
deployed' data. ie. a DivX or DVD being transferred and a movie
application saying: "DVD with title XYZ with actors ABC and written by
DEF is being transferred to your phone (20% completed)". And After that
an extraction to get extra metadata that isn't included in the protocol
based metadata (and all that without needing miner-fs).

> 16. I presume the tracker-storage.[ch] addition to libtracker-extract is 
> a straight copy of the files from libtracker-miner? I am not sure if 
> this is such a good idea - but I've not been sure what to do here for a 
> while now. From a quick git grep on the code, it seems we only use it in 
> tracker-writeback, tracker-extract and tracker-miner-fs, and since 
> miner-fs already links with libtracker-extract, it looks like the 
> logical choice to move it there.

Right

> 22. The reason I asked for a sync API is so we could use it in 
> tracker-sparql ;)

Not sure if a sync api is really needed since it would just wrap a
GMainLoop anyway. But could be done for convenience.


Kind regards,

Philip


-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Request for review, API allowing external software like MTP daemons to get metadata as correct sparql insert

[Philip Van Hoof]

On Tue, 2013-01-08 at 11:40 +, Martyn Russell wrote:
> On 08/01/13 11:13, Philip Van Hoof wrote:
> > On Fri, 2013-01-04 at 15:20 +, Martyn Russell wrote:
> >> On 03/01/13 21:30, Philip Van Hoof wrote:
> >
> > Yes the separate update was/is the solution for Nokia's N9. The idea
> > here or now is that no separate update would be needed at all with this
> > solution: the MTP daemon does both the extraction and the initial sparql
> > insert in one pass.
> >
> > And then the MTP daemon does a rename() call from tempfile to dest-url.
> > Completing the file transfer.
> 
> As long as what's on the disk is represented in the DB, that's fine. At 
> the moment we don't have any cases (I know of) where the file is 
> available in the DB but not on the disk (or visa versa).

Well no, to be ahead of 'the file is on the disk' is one of the ideas
behind 'better supporting MTP daemons' use-case'.

> This can lead to incorrect results for applications using Tracker which 
> we want to avoid.

They have tracker:available for that. When a removable media is
disconnected, the file is also not available on the disk. That's why we
have tracker:available.

> > That sparql insert can happen while the download takes place (allowing
> > the MTP daemon to insert protocol based metadata before file data is
> > transferred and available - for extraction).
> 
> There are a number of issues with this approach to be considered. For 
> example:
> 
> 1. How does anyone querying the information know when the file is 
> ACTUALLY available? tracker:available?

Yes

> 2. What if you don't have all the information until it's downloaded and 
> it's needed for querying ahead of time? This is usually the biggest 
> problem here. Simple things like file size or even specific metadata can 
> be important enough here.

You don't have all information, but you do have the protocol based
metadata. Often this is sufficient information to display, in certain
use-cases, ahead of the file being on disk.

> >> 15. I've not checked the whole on_fileinfo_received() part because it's
> >> really complex in the miner-fs already and we were fixing problems there
> >> for years related to parent existence and creation prior to insertion of
> >> a child path. This worries me about this branch because I get the
> >> impression from quick review that it's not really addressed fully. You
> >> also seem to allow parent URNs to not exist before adding a child to the
> >> database. That's not how we've done things in the miner-fs and this
> >> really breaks what people using the DB can expect. Correct me if I am 
> >> wrong.
> >
> > Right, parent URNs aren't yet created with this solution and should
> > probably be.
> 
> This is a requirement I would say. It's a hard problem to solve well 
> too, just speak to Sam about his recent work to improve this and 
> recursive issues :)

Right.

Ideally Sam puts this in a shared library and not in miner-fs's binary,
so that this MTP support and what Sam is improving can use the same code
in a correct and nice way.

> > I guess putting INSERT queries upfront the metadata one needs to be
> > possible as well as getting a separate query for in case the MTP daemon
> > wants to do multiple passes. ie. First protocol based metadata insert,
> > which needs the parent URNs at that point and which doesn't yet need the
> > file content to be available, then extraction based metadata insert; for
> > which the file content must be available.
> 
> Not really. If that insert fails, then you're not guaranteeing the 
> parent is inserted, which we do at the moment.

Why would the insert fail other than something being a bug that must be
fixed?

> Separate queries for the parent are really the way to go here. Once 
> that's done you have to handle failures and retries before the child can 
> be added, etc. This is why the miner-fs has a lot of code in this area 
> to handle this stuff. Ideally, it would be good to make use of that code 
> here so we don't have to fix issues we've already fixed in the miner-fs.
> 
> > And what this creates must also be compatible with what miner-fs will
> > otherwise create.
> 
> Yea I agree.
> 
> > The idea here is that while a (large) file is being transferred,
> > protocol based metadata is already in the Nepomuk store available for
> > applications that are interested in tracker:available-false 'to be
> > deployed' data. ie. a DivX or DVD being transferred and a movie
> > application saying: "DVD with t

Re: [Tracker] Request for review, API allowing external software like MTP daemons to get metadata as correct sparql insert

[Philip Van Hoof]

On Tue, 2013-01-08 at 12:02 +, Martyn Russell wrote:
> On 08/01/13 11:56, Philip Van Hoof wrote:
> > On Tue, 2013-01-08 at 11:40 +, Martyn Russell wrote:

> >> Not really. If that insert fails, then you're not guaranteeing the
> >> parent is inserted, which we do at the moment.
> >
> > Why would the insert fail other than something being a bug that must be
> > fixed?
> 
> In the past, inserts have failed because the extracted metadata is not 
> in line with the ontology of the day OR because the database is fscked. 

Both are bugs that must be fixed.

> So it's usually a corner case anyway. Sometimes it's a limitation or 
> restraint we have in the DB, like unique nie:url cases - but that's more 
> about the code being wrong than something we can't control.

Also a bug that must be fixed.

> > And with this miner-fs isn't involved. The MTP daemon has better control
> > than inotify over the file-transfer to know when to update and when not
> > to update.
> 
> Sure. Though Nokia IIRC wanted updates to things like nfo:fileSize and 
> done so we didn't spam too much but had updates every n seconds, etc.

Voila, perfect solution imo. Use-case based there's no reason to have
millisecond accuracy for nfo:fileSize while a download is happening.

Unless the person who is requesting this use-case is stupid for
expecting the Nepomuk storage to provide this information. Instead this
person should see such information as application state and get the
information at the source (fstat or inotify) rather than at the
abstraction (Nepomuk).

imho Nepomuk stores aren't supposed to be real time :), but some
information can be inserted ahead of time (in case of MTP daemon
support).

> > BTW. the '20% completed' does not belong in Nepomuk and needs to be
> > communicated differently (it's application state information).
> 
> Yea, I thought it might.

Kind regards,

Philip

-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Using older glib in tracker

[Philip Van Hoof]

Hi Marcin,

I'm assuming you meant to ask whether it is possible to use GLib 2.20 or
2.22 to build Tracker 0.10 instead of Tracker 2.20/2.22 to build.
 
If the configure.ac script requests a specific version, then that
version is the oldest version that you can use.

Up until last year was Tracker using a lot of very recent additions and
improvements to GLib. Using a lower version than the one requested by
configure.ac will therefor not work (not without patching and working
around not having the feature for which the version in configure.ac got
bumped - which the team generally doesn't / didn't do without reason).

For most systems an upgrade of GLib should not be any problem. GLib is
maintained rigidly and upgrades of GLib are generally considered safe.

Kind regards,

Philip

On Thu, 2013-01-24 at 16:55 +0100, Marcin Mielniczuk wrote:
> Hi,
> 
> 
> Is it possible to use tracker 2.20 (or 2.22) to build tracker 0.10 or
> newer?
> 
> 
> Regards,
> --
> Marcin
> ___
> tracker-list mailing list
> tracker-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/tracker-list

-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Using older glib in tracker

[Philip Van Hoof]

On Tue, 2013-01-29 at 11:01 +0100, Marcin Mielniczuk wrote:

Hi,

> I was asking whether it is possible to use GLib 2.20 or 2.22 to build
> Tracker 0.10+ instead of Glib 2.28+ to build

ok

> The problem is that glib upgrade is not that easy. There are some
> closed source packages which segfault with glib 2.29 for example.

That means that your closed source packages probably have a serious bug.

Of course can't the Tracker project take into account bugs of closed
source packages. You'll have to workaround this (you can install a
specific version of GLib in a directory and use LD_LIBRARY_PATH).

My advice for such a situation is to use such a workaround anyway, as
you can't block yourself from upgrading GLib forever and yet your closed
source packages will always have to work with that specific GLib
version. So you'll need LD_LIBRARY_PATH.

For example:

o. Install old GLib 2.20 in /opt/myclosedapp
o. Install MyClosedApplication in /opt/myclosedapp
o. mv /opt/myclosedapp/bin/myclosedapp /opt/myclosedapp/bin/myclosedapp.orig
o. cat > /opt/myclosedapp/bin/myclosedapp < 
> 2013/1/29 Philip Van Hoof 
> Hi Marcin,
> 
> I'm assuming you meant to ask whether it is possible to use
> GLib 2.20 or
> 2.22 to build Tracker 0.10 instead of Tracker 2.20/2.22 to
> build.
> 
> If the configure.ac script requests a specific version, then
> that
> version is the oldest version that you can use.
> 
> Up until last year was Tracker using a lot of very recent
> additions and
> improvements to GLib. Using a lower version than the one
> requested by
> configure.ac will therefor not work (not without patching and
> working
> around not having the feature for which the version in
> configure.ac got
> bumped - which the team generally doesn't / didn't do without
> reason).
> 
> For most systems an upgrade of GLib should not be any problem.
> GLib is
> maintained rigidly and upgrades of GLib are generally
> considered safe.
> 
> Kind regards,
> 
> Philip
> 
> On Thu, 2013-01-24 at 16:55 +0100, Marcin Mielniczuk wrote:
> > Hi,
> >
> >
> > Is it possible to use tracker 2.20 (or 2.22) to build
> tracker 0.10 or
> > newer?
> >
> >
> > Regards,
> > --
> > Marcin
> 
> > _______
> > tracker-list mailing list
> > tracker-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/tracker-list
> 
> --
> Philip Van Hoof
> Software developer
> Codeminded BVBA - http://codeminded.be
> 
> 
> 

-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] errors in the end of sudo make install

[Philip Van Hoof]

If you changed this recently:

--with-nautilus-extensions-dir=/usr/lib/nautilus/extensions-3.0/

You need to make distclean


-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] Nemomobile patches

[Philip Van Hoof]

Hi guys,

Patches being applied to Tracker for Nemomobile:

https://build.pub.meego.com/package/files?package=tracker&project=CE%
3AMW%3AShared

Ideally we try to integrate as much as possible of these patches
upstream.

Kind regards,

Philip

-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Tracker Internal Documentaion

[Philip Van Hoof]

Hi Vishesh,

It's always a good idea to pose these questions on the Tracker public
mailing list, so I replied with the mailing list in CC:

So you have a denormalized schema in SQL where each multi value field in
Nepomuk is represented by a table, and each RDF class is represented by
a table with the exception of some of the xsd primitive ones (which are
implied because SQLite knows how to handle these things, for example
xsd:int, xsd:string, etc).

Then the libtrackersparql makes a WAL SQLite connection, parses your
SPARQL and generates on the fly SQL for that. This happens often using
subqueries, and without building an AST first - making the
parse-translate phase relatively fast and resource friendly, which is a
design-choice as Tracker is indented to run on devices with few
resources.

This code does that:
https://git.gnome.org/browse/tracker/tree/src/libtracker-data/tracker-sparql-query.vala

That design-choice of course has a draw back in that the queries have to
manually optimized very often and/or to get things fast enough we often
had to store data in a rendundant way. We did this with domain specific
indexes which I explained in this blog item:

http://pvanhoof.be/blog/index.php/2010/07/07/domain-indexes-finished-technical-conclusions
http://pvanhoof.be/blog/index.php/2010/07/03/sqlites-wal-deleting-a-domain-specific-index
http://pvanhoof.be/blog/index.php/2010/07/01/working-on-domain-specific-indexes


This function is the code that translates a statement (from the SPARQL
UPDATE we make RDF statements and then we process those) to SQL inserts:

https://git.gnome.org/browse/tracker/tree/src/libtracker-data/tracker-data-update.c#n732

A lot of the SPARQL UPDATE part is here:
https://git.gnome.org/browse/tracker/tree/src/libtracker-data/tracker-sparql-pattern.vala

Note that we have a buffer where we eliminate duplicates like:

 a Class.
 Prop1 Value1.
 a Class.
 Prop2 Value2.
 Prop1 Value3.

We translate that to:

 a Class; Prop1 Value; Prop2 Value3.

Except when we utilize the null support:

http://pvanhoof.be/blog/index.php/2011/08/09/support-for-null-with-trackers-insert-or-replace-feature
http://pvanhoof.be/blog/index.php/2011/08/15/null-support-for-insert-or-replace-available-in-master

The second blog item and my own comments in the first illustrate the
problem with optimizing statement-sets like above just like that.

Then we also added a few SQLite functions which are used by the
SPARQL->SQL translation and for most of our own SPARQL extensions (we
ship with a bunch of SPARQL extensions that allow query writers to make
queries faster):

https://git.gnome.org/browse/tracker/tree/src/libtracker-data/tracker-db-interface-sqlite.c#n826

The data-manager is mostly about creating the SQL tables and
preparation. It can also handle a limited amount of ontology changes
(adding and removing of classes and properties and their extensions like
domain specific indexes):
https://git.gnome.org/browse/tracker/tree/src/libtracker-data/tracker-data-manager.c

Kind regards,

Philip


On Thu, 2013-04-11 at 05:18 +0530, Vishesh Handa wrote:
> Hey Philip
> 
> I'm one of the KDE Nepomuk developers. I've been looking into the
> tracker project for some time now, since it's good to know how other
> people internally implement things. However, it has been very hard for
> me to find any documentation on the inner working of tracker.
> 
> 
> I'm specifically interested in how the database schema is designed. I
> did find this "Semantic Social Desktop and Mobile Devices"
> presentation [1] which gives a very rough overview of how each class
> has its own table.
> 
> 
> Could you perhaps point me to some internal documentation? It would be
> most helpful. Otherwise, could I ask your some detailed questions
> about the tracker internals?
> 
> I have looked at the source code, but it's a little hard to understand
> for a new comer.
> 
> [1] https://live.gnome.org/Tracker/Documentation/Presentations
> 
> -- 
> Vishesh Handa
> 


___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Tracker Internal Documentaion

[Philip Van Hoof]

   Prop2 Value2.
>  Prop1 Value3.
> 
> We translate that to:
> 
>  a Class; Prop1 Value; Prop2 Value3.
> 
> Except when we utilize the null support:
> 
> 
> http://pvanhoof.be/blog/index.php/2011/08/09/support-for-null-with-trackers-insert-or-replace-feature
> 
> http://pvanhoof.be/blog/index.php/2011/08/15/null-support-for-insert-or-replace-available-in-master
> 
> The second blog item and my own comments in the first
> illustrate the
> problem with optimizing statement-sets like above just like
> that.
> 
> Then we also added a few SQLite functions which are used by
> the
> SPARQL->SQL translation and for most of our own SPARQL
> extensions (we
> ship with a bunch of SPARQL extensions that allow query
> writers to make
> queries faster):
> 
> 
> https://git.gnome.org/browse/tracker/tree/src/libtracker-data/tracker-db-interface-sqlite.c#n826
> 
> The data-manager is mostly about creating the SQL tables and
> preparation. It can also handle a limited amount of ontology
> changes
> (adding and removing of classes and properties and their
> extensions like
> domain specific indexes):
> 
> https://git.gnome.org/browse/tracker/tree/src/libtracker-data/tracker-data-manager.c
> 
> 
> 
> Thanks for all this information
> 
>  
> 
> Kind regards,
> 
> Philip
> 
> 
> On Thu, 2013-04-11 at 05:18 +0530, Vishesh Handa wrote:
> > Hey Philip
> >
> > I'm one of the KDE Nepomuk developers. I've been looking
> into the
> > tracker project for some time now, since it's good to know
> how other
> > people internally implement things. However, it has been
> very hard for
> > me to find any documentation on the inner working of
> tracker.
> >
> >
> > I'm specifically interested in how the database schema is
> designed. I
> > did find this "Semantic Social Desktop and Mobile Devices"
> > presentation [1] which gives a very rough overview of how
> each class
> > has its own table.
>     >
> >
> > Could you perhaps point me to some internal documentation?
> It would be
> > most helpful. Otherwise, could I ask your some detailed
> questions
> > about the tracker internals?
> >
> > I have looked at the source code, but it's a little hard to
> understand
> > for a new comer.
> >
> > [1]
> https://live.gnome.org/Tracker/Documentation/Presentations
> >
> > --
> > Vishesh Handa
> >
> 
> 
> 
> 
> 
> 
> -- 
> Vishesh Handa
> 

-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Tracker Internal Documentaion

[Philip Van Hoof]

On Thu, 2013-04-11 at 14:29 +0200, Philip Van Hoof wrote:
> On Thu, 2013-04-11 at 15:53 +0530, Vishesh Handa wrote:

> > In the Nepomuk KDE world we generally use graphs to group triples
> > based on which application has stored the information. This is
> > especially useful in the case of indexing. When a file has been
> > modified and needs to be re-indexed, we need to throw away the
> > previous data and re-index it. The file could in this case have both
> > indexed and non-indexed data such as tags and ratings. So, we only
> > remove the statements that were added by the indexer and then reindex
> > the file.
> 
> This isn't supported by Tracker.
> 
> > This seems like a very common use case. I'm curious as to how tracker
> > solves this problem.
> 
> It doesn't. Full graph support was not a design consideration, only
> limited support for it was.

Let me rephrase that: there is a solution for this in Tracker, but it's
somewhat specific to miner-fs.

The miner-fs file indexer will only overwrite triples that have as
origin the miner-fs's graph. When you write a triple you'll always
overwrite its graph value (it's recommended to always provide it and to
never use the one of miner0fs).

Tracker's graph support is like supporting a default graph value, but
only a default one (not more than one).

So basically, miner-fs indexes a file and stores its metadata in sparql
using its own graph.

Another app stores or updates new metadata and uses its own graph.

When miner-fs updates the metadata of the file, it will only overwrite
data in its own graph.

Kind regards,

Philip

-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Tracker Internal Documentaion

[Philip Van Hoof]

On Thu, 2013-04-11 at 18:12 +0530, Vishesh Handa wrote:



> If it's possible could you please elaborate as to how this is
> implemented in the database?

It's implemented in the SQLite tables as an extra column.


> Oh. So, suppose a music file existed with a performer "Coldpay" and
> modified the id3 tags to now say "Coldplay". The file would get
> reindexed and it would now have both performers? The old and the new
> one?

> The performer is generally stored with a 'nmm:performer' property and
> does not have a max cardinality of 1.

No, multivalue properties are first clearned and then rewritten (by
miner-fs). When another client adds a value to a multivalue property
then the graph of all is set to the clients', so miner-fs wont overwrite
it anymore.

An example:

1) file.mp3 a nmm:MusicPiece has nmm:performer 'somebody' as extracted
by tracker-extract/miner-fs and written in tracker-store:

GRAPH  {
 a nmm:MusicPiece, nfo:FileDataObject;
   nie:url 'file://.../file.mp3';
   nie:title 'test';
   nmm:performer 'somebody' .
}

2) client updates nmm:performer:

GRAPH  {
 nmm:performer 'somebody else' .
}

3) Result:

GRAPH  {
 a nmm:MusicPiece, nfo:FileDataObject;
   nie:title 'test';
   nie:url 'file://.../file.mp3' ;
   nfo:lastModifiedSomething '...' .
}

GRAPH  {
 nmm:performer 'somebody else' .
}

4) miner-fs sees an update on file.mp3, update is on performer and
title:

GRAPH  {
   nie:title 'new title';
nfo:lastModifiedSomething '...' .
}

Because miner-fs won't change statements that aren't in its own graph
and because we support only one graph per statement (meaning that client
has overwritten it for nmm:performer).

Kind regards,

Philip

-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Semantic Desktop for Gnome

[Philip Van Hoof]

On Tue, 2013-05-07 at 10:48 -0700, Ivan Frade wrote:


> Are there other considerations?
> 
> 
> We prefer the applications writing directly into tracker. Some
> reasons:

[cut excellent reasons]

Add this reason: Because Tracker has, with tracker-writeback, a service
to write such metadata to files.

Kind regards,

Philip


-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] Disk usage optimization

[Philip Van Hoof]

HI guys,

For one of my customers I'm getting the question how to reduce the disk
usage.

I wrote the journalling and periodic backup of meta.db myself so I of
course know how to disable these, what the consequences are and how to
ensure that all still works and all that ;)

My question to the team is to think with me on how we can further reduce
disk space usage for products where this is a consideration (for example
embedded appliances where additional storage is an expensive component
if it has to be large).

Next to disabling journaling and using synchronous mode in SQLite after
putting meta.db in .local and adapting the Backup/Restore to operate on
the main meta.db instead of the journal or periodic backup, I was
thinking about disabling fts, but also disabling extracting and mining
of nie:plainTextContent.

But also a perhaps crazy idea would be to implement a virtual table for
SQLite that can compress certain literals' columns. A kind of the
opposite of a indexed property: it'll be very slow, but as it is rarely
queried on it's fine that it is slow. Just that the property's value
must still be stored for the times when it is needed.

For example for properties like nie:plainTextContent, but then per
resource would the cell be stored compressed or not (and all SQLite
access to it would decompress it, for example collation would).

The problem is that many users want nie:plainTextContent to be there,
but they don't want it to consume so much diskspace (and it can be slow
to access it).

Another idea could be filesystem specific: pointing in SQLite, somehow,
to the inode of the FS straight to the contents of the file whenever the
file is a plain text one. This might be even more crazy. I don't know.

Putting all of meta.db on a compressed filesystem is also an idea.

Kind regards,

Philip

-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] Response to a question of a company about SPARQL watching

[Philip Van Hoof]

Hi team,

I received a series of questions from a company in automotive industry 
about implementing full SPARQL watching in Tracker's store. They told me 
they have something that does periodic requering of queries executed by 
the SPARQL clients.


We of course discussed this during our Nokia sprints a few years ago. 
Because I think the community should also know about our conclusions and 
ideas of back then I'll copy paste my response to the people who sent me 
the questions.


https://live.gnome.org/Tracker/Documentation/SignalsOnChanges

At some point we also wanted to implement full SPARQL query watching or 
triggering or SPARQL views, but due to this being too complex to monitor 
the complete graph of a Nepomuk tree we decided to go for class signals 
instead and let the clients do the remainder themselves (by requering or 
having a more clever update mechanism).


Note the complexity that every change to a relation or literal property 
(with relation I mean a property that is a reference to another object) 
in the root of the Nepomuk tree of your data, can possibly be a trigger 
for any such SPARQL view (or SPARQL watching, however you want to call 
it). This is far more complicated than traditional triggers in most 
database systems, as those triggers usually operate on a single table. 
The complexity is more comparable to query views in products like SQL 
Server or Oracle, on queries that are very complicated (subqueries, 
joins and rather hard expressions on the literals like regular 
expressions in some cases on a decomposed denormalized schema -> not fun 
to implement query views for that). Of course can we make certain 
assumptions about RDF while inserting of statements happens, in relation 
to SPARQL queries. It's probably not impossible because of those 
assumptions that can be made. HOWEVER :-)


The idea behind class signals is that we'll signal the clients that they 
might have to check the results of the query they are showing to the 
user. They can then rerun their own SPARQL query themselves to achieve 
full SPARQL watching (themselves). Such signalling systems aren't 
uncommon in MVVM designs where the view-model will translate the 
incomplete event that came from the model to complete updates on its 
view. (view would in qt be QML, view-model would be a QAbstractItemModel 
(and QSparql has one which you could use to decorate), and the model 
would be for example a QList of the results you get from QSparql or the 
QAbstractItemModel it supports itself).


A reason for that is that we didn't want to make tracker-store stateful 
with relation to the clients.


We didn't want to make it stateful with relation to clients because one 
idea is to one day have a libtracker-sparql that, just like libsqlite 
does for SQL and DB schemas, provides a way for any application to 
provide it with an ontology and then (just) start using SPARQL INSERT 
and SPARQL on that ontology. In this scenario the GNOME desktop (or the 
KDE desktop) would provide the Nepomuk ontology and the GNOME filesystem 
miner would use libtracker-sparql to fill it up. That there is a service 
like tracker-store, activated by D-Bus, is in that design scenario just 
an implementation detail of libtracker-sparql. That then there exists 
something like a semantic desktop is not really because of 
libtracker-sparql but because of the desktop having chosen the same 
Nepomuk based ontology for all of its libtracker-sparql clients 
(including the miners).


In other words is libtracker-sparql just a library that helps you build 
a semantic desktop, instead of "Tracker" providing you with "the" 
semantic desktop.


That means that this tracker-store (in libexec) would be provided by 
libtracker-sparql as a D-Bus activated 'tool' or 'implementation detail' 
that shuts itself down after a period of no-write activity. You can see 
how this can't work well together with full SPARQL watching: unless we 
have a very quick way to know in a stateless (with relation to the 
libtracker-sparql clients) way what results it has for what queries (of 
all the clients) and whether the just arrived SPARQL INSERT influences 
them at startup of the 'tool' / 'implementation detail'. Obviously can't 
this tool's startup time be long, as this would influence badly the 
SPARQL INSERT performance for the libtracker-sparql client doing the 
write query.


Because of that is the class signal signal stateless. And because of 
that we prefer all query state to remain in the libtracker-sparql 
clients themselves.


Meaning that they are responsible for reexecuting the query, and not the 
store. The store will, however, provide hints. Hints based on classes. 
Hence the name class signals.


That DOESN'T mean that the reexecuting can't be done transparently by 
libtracker-sparql (so developers who use of libtracker-sparql must not 
necessarily be aware when using such a higher level feature). Just that 
the executing-of the query, in a full SPARQL watching des

Re: [Tracker] Disk usage optimization

[Philip Van Hoof]

Op 13/06/2013 1:22, Ivan Frade schreef:

Hi Ivan,


Some other ideas, if your use cases are limited:

 You could disable the indeces you dont need. They use some space in 
sqlite.


True. Minizing the usage of tracker:indexed and especially 
tracker:domainIndex is a good idea to reduce storage. Although this will 
have a serious impact on performance of queries using the fields. So I 
wouldn't recommend this for everybody.


 For some properties, we store its value and collation to sort 
correctly in different locales. If you don't need that sorting, you 
could remove this duplication.
Correct. I almost forgot about that one. This will, however, mean that 
it's not possible to sort correctly on that field anymore? Ideally if we 
remove the collation column we can still sort correctly but then only 
slower. Afaik that should be possible and/or is already the case, no?


 You could also prune the extractors to get *only* the information you 
need... specially text properties.
Right. I wonder if it's worthwhile to try to make this possible for 
upstream by having it configurable per extractor. For example in the 
.rule file of an extractor module we could specify which properties to 
extract (if they are available), and then having some infrastructure to 
avoid huge amounts of if-then-else in the extractor modules' code.


Tanks for the tips, especially the one about the collator column which I 
had forget about myself.


Kind regards,

Philip






On Wed, Jun 12, 2013 at 2:50 AM, Martyn Russell <mailto:mar...@lanedo.com>> wrote:


On 12/06/13 09:00, Philip Van Hoof wrote:

HI guys,


Hello Philip,


For one of my customers I'm getting the question how to reduce
the disk
usage.


Do you have a requirement here?
How much are you looking to reduce it by?
What is it now?
What are your limits, etc?


I wrote the journalling and periodic backup of meta.db myself
so I of
course know how to disable these, what the consequences are
and how to
ensure that all still works and all that ;)

My question to the team is to think with me on how we can
further reduce
disk space usage for products where this is a consideration
(for example
embedded appliances where additional storage is an expensive
component
if it has to be large).

Next to disabling journaling and using synchronous mode in
SQLite after
putting meta.db in .local and adapting the Backup/Restore to
operate on
the main meta.db instead of the journal or periodic backup, I was
thinking about disabling fts, but also disabling extracting
and mining
of nie:plainTextContent.


Absolutely, this should make quite some difference to the DB size.

  ./configure --disable-tracker-fts

I would start here.


But also a perhaps crazy idea would be to implement a virtual
table for
SQLite that can compress certain literals' columns. A kind of the
opposite of a indexed property: it'll be very slow, but as it
is rarely
queried on it's fine that it is slow. Just that the property's
value
must still be stored for the times when it is needed.


Do you have a real use case in mind here?


For example for properties like nie:plainTextContent, but then per
resource would the cell be stored compressed or not (and all
SQLite
access to it would decompress it, for example collation would).

The problem is that many users want nie:plainTextContent to be
there,
but they don't want it to consume so much diskspace (and it
can be slow
to access it).

Another idea could be filesystem specific: pointing in SQLite,
somehow,
to the inode of the FS straight to the contents of the file
whenever the
file is a plain text one. This might be even more crazy. I
don't know.


You may sacrifice speed here, we would also need to consider how
to cater for cases where the file is not tracker:available of course.


Putting all of meta.db on a compressed filesystem is also an idea.


We need more information about what you're limits are first I
would say.

-- 
Regards,

Martyn

Founder and CEO of Lanedo GmbH.

___
tracker-list mailing list
tracker-list@gnome.org <mailto:tracker-list@gnome.org>
https://mail.gnome.org/mailman/listinfo/tracker-list




___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list


___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] Reviving the libstreamanalyzer based extractor module

[Philip Van Hoof]

Hi team,

During a Tracker/Nepomuk/SPARQL training I gave at one of my customers I 
noted the interest in extractors that can dive into archives and 
document types that have a tree of other documents (like MIME documents).


Right now a Tracker extractor module can't extract an MP3 that is 
attached in an E-mail located in a Maildir or stored in a tar.gz file. 
My recommendation for E-mail client authors is and will probably always 
be to store MIME parts, that have disposition set to attachment or not, 
Base64 decoded on the filesystem. So that means that the cache of an 
E-mail client stores an MP3 attachment of an E-mail ... as an MP3. And 
not as a blob of Base64 encoded quote plain text unquote (which is 
stupid and not useful). That way writing a miner for such an E-mail 
client would mean to configure the FS miner to just index the cache 
directory (and perhaps tweak the nie:url value and add nmo rdf:type 
qualifiers).


That or libtracker-extract should allow a stream or buffer based 
extraction, and/or a file descriptor based one (in which case we could 
pass the extractor modules, the ones now only used by tracker-extract, a 
by pipe created FD from the E-mail client, and write the Base64 decoded 
data to the pipe FD - or something). Unfortunately is tracker-extract 
right now entirely FILE based (not really FD based, nor stream based).


Also do some use-cases of Tracker's FS miner want files in archives to 
be indexed.


Tracker's native extractors can't do any of this. That's because they 
are open/seek/read/close based and not stream based. The 
libstreamanalyzer library aims to implement extraction of metadata in a 
stream based way, with support for diving into archives and MIME documents.


It was for that reason that I once wrote tracker-topanalyzer.cpp in the 
src/tracker-extract directory. It's unmaintained nowadays.


I think it would be a great first addition if the tracker-extract .rule 
file based environment would be adapted to have two levels of matching: 
first on container and then on MimeType. The first level would for all 
of its native extractors be "Just File", and for the libstreamanalyzer's 
be "MIMEDocument" and "Archive". The second level would be the same as 
now. Ideally this level system could also be used for multimedia files 
(videos have first a MIME type and then a codec type, for example).


Then would it start being possible for a extractor module like 
tracker-topanalyzer.cpp to get kicked into action for diving into 
archive files and MIME documents (and the native ones would still 
operate on native file types).


Also should the tracker-topanalyzer.cpp be fixed. It has been a long 
time that it was last tested and I don't expect it to still work. And 
for it to work it would probably be needed that libstreamanalyzer gets 
adapted to follow Tracker's Nepomuk adaptations (right now 
libstreamanalyzer doesn't know about the nmm ontology, afaik).



Kind regards,

Philip




___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Reviving the libstreamanalyzer based extractor module

[Philip Van Hoof]

Op 14/06/2013 19:36, Ivan Frade schreef:
Hi Ivan,

During a Tracker/Nepomuk/SPARQL training I gave at one of my customers 
I noted the interest in extractors that can dive into archives and 
document types that have a tree of other documents (like MIME documents).


 Just today another message in this mailing list was mentioning it :)

Yep. I noticed it.


That or libtracker-extract should allow a stream or buffer based
extraction, and/or a file descriptor based one (in which case we
could pass the extractor modules, the ones now only used by
tracker-extract, a by pipe created FD from the E-mail client, and
write the Base64 decoded data to the pipe FD - or something).
Unfortunately is tracker-extract right now entirely FILE based
(not really FD based, nor stream based).


 FD passing and buffered extraction are both good ideas. They are also 
independent. We could implement any of them without the other.


A problem that I see with the FD passing using pipe is that we can't 
know for sure whether a library that we depend on for metadata 
extraction wont use seek() and assume they got a real file's fd. I'm 
even afraid that most do. The others are probably buffer or mmap based. 
Meaning that libstreamanalyzer's way of just rewriting all extractors to 
be stream based is probably the only way to end up with a consistent and 
sensible solution for in-archive metadata extraction.




I think it would be a great first addition if the tracker-extract
.rule file based environment would be adapted to have two levels
of matching: first on container and then on MimeType. The first
level would for all of its native extractors be "Just File", and
for the libstreamanalyzer's be "MIMEDocument" and "Archive". The
second level would be the same as now. Ideally this level system
could also be used for multimedia files (videos have first a MIME
type and then a codec type, for example).


Is this two level matching really needed? at the end we recognize the 
containers with mime-types (e.g. application/x-tgz). With the current 
.rules files, we can assign those "container mime-types" to the 
topanalyzer.
You're right if there is only one such kind of extractor. As soon as you 
want to select libstreamanalyzer for one kind of archive-mime-type 
combination and another extractor for another archive-mime-type 
combination, this wont work. But I agree that we could have a 
tracker-extract-container.c and .rule for application/x-tgz among other 
container types that then splits it out to 
tracker-extract-container-streamanalyzer.cpp and 
tracker-extract-container-somethingelse.c based on logic defined not in 
the top .rule system but on what tracker-extract-container.c itself 
does. And at first this can simply be to throw them all to a 
streamanalyzer.cpp one (which will likely look a lot like what 
tracker-topanalyzer.cpp is now).


Note that there's no reason to keep tracker-topanalyzer.cpp's filename. 
With the .rule based system the filename topanalyzer.cpp makes no sense 
anymore.



Then would it start being possible for a extractor module like
tracker-topanalyzer.cpp to get kicked into action for diving into
archive files and MIME documents (and the native ones would still
operate on native file types).

Also should the tracker-topanalyzer.cpp be fixed. It has been a
long time that it was last tested and I don't expect it to still
work. And for it to work it would probably be needed that
libstreamanalyzer gets adapted to follow Tracker's Nepomuk
adaptations (right now libstreamanalyzer doesn't know about the
nmm ontology, afaik).


I wonder if Jos is still working on it. We could bring back to life 
that topanalyzer extractor, use it for compressed files and move on 
from there.
If Jos isn't working on it anymore, surely we can look into it 
ourselves. I doubt that Jos would reject patches that conditionally make 
libstreamanalyzer spit out a better ontology than the broken upstream 
Nepomuk ontologies for multimedia. A bit of stream and decorator in C++ 
will do good to us.


Kind regards,

Philip

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Disk usage optimization

[Philip Van Hoof]

Op 14/06/2013 20:13, Ivan Frade schreef:

Hi Philip,

 My ideas are more in the line of "fine tune Tracker for your specific 
use case". Don't think they apply to master.
Hmm, Given that Tracker is fit and designed for embedded use-cases I 
don't think the project should not allow compile time and/or configure 
time configurability of behaviour.


For example the --disable-journal and the --disable-fts are also 
behaviour changes. We could equally easily add a 
--disable-collator-column and a --disable-plaintext-extraction so that 
system integrators can easily build a Tracker package that is optimized 
for storage instead of optimized for performance.


For longer term future I'd even go as far as to easily allow replacing 
the entire ontology. Although I think for that we should rather bring 
libtracker-sparql and tracker-store together as libsparql-store, have a 
semantic-nepomuk-desktop package that installs the ontology and let 
libtracker-miner and tracker-miner-fs be packages that depend on 
semantic-nepomuk-desktop and libsparql-store.


And then on tracker-miner-fs have a --disable-plaintext-extraction and 
on libsparql-store have a --disable-journal, --disable-fts and 
--disable-collator-column.


This would effectively mean so-called splitting the project. But I've 
always felt that in the long term this should happen. It would also 
allow tracker-miner-fs to focus more on the mining and indexing of 
files, and libsparql-store on being a embedded and/or highly efficient 
and reliable SPARQL endpoint and SPARQL INSERT store.


I also think that libtracker-extract should probably move towards a 
truly publicly usable libmetadata-extract which exposes buffer and 
stream based metadata extraction for not just tracker-extract but for 
any program that needs this. Although it would use this 
libmetadata-extract just like how it uses libtracker-extract now, the 
tracker-extract binary should be an implementation detail of 
tracker-miner-fs after that. The problem I see with the current 
architecture of tracker-extract as the service to do metadata extraction 
is that it can only work well for file based metadata extraction, while 
the world of metadata is massively, insanely massivele larger than just 
files on your filesystem. If you just open your eyes to see it.



On Fri, Jun 14, 2013 at 6:39 AM, Philip Van Hoof <mailto:phi...@codeminded.be>> wrote:


Op 13/06/2013 1:22, Ivan Frade schreef:

Hi Ivan,

For some properties, we store its value and collation to sort
correctly in different locales. If you don't need that sorting,
you could remove this duplication.
Correct. I almost forgot about that one. This will, however, mean
that it's not possible to sort correctly on that field anymore?
Ideally if we remove the collation column we can still sort
correctly but then only slower. Afaik that should be possible
and/or is already the case, no?


  Without the collation the order can be wrong in some locales. It is 
not about speed, IIRC.


Can it be made to be correct without the collation column? Surely the 
collation column got created out of the same data the current property's 
column stores? Meaning that collation data can be made in alloca() 
buffers on the fly (which is of course going to be a lot slower).


Kind regards.
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] A use-case for SPARQL and Nepomuk

[Philip Van Hoof]

Wrote this one:

http://pvanhoof.be/blog/index.php/2013/06/24/a-use-case-for-sparql-and-nepomuk

-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] A use-case for SPARQL and Nepomuk

[Philip Van Hoof]

Hi Tshepang,

Funny thing is that I do sometimes get questions from companies that are 
trying to integrate Tracker into their embedded appliance. They struggle 
with the issues that I mentioned last few days here on the mailing list 
(it's too bulky, we don't want to support the entire Nepomuk ontology - 
we just want to use it for this this and that -, we only need a miner 
for that and not for this, how do we limit what the miner extracts from 
files, how do we reduce the storage usage, etc).


I just don't know for sure how to inspire enough and the right people to 
do a new refactoring effort that makes it more easy for those companies 
to integrate the components. Purely in our free time it will probably 
not happen fast ..


Something like this is what I have in mind:

- tracker-store and libtracker-sparql become libsparql-lite or 
libtracker-sparql as a separate project
   - It'll allow installing your own set of ontologies (even requires 
you to do so)
   - It'll bootstrap from your ontology and it'll manage certain 
ontology changes live, even without clients having to disconnect from 
libtracker-sparql

   - It'll handle SPARQL + our extentions
   - It'll handle SPARQL UPDATE + our extentions

- A desktop-nepomuk package, co-maintained with Nepomuk-KDE (what we 
always wanted)

  - Provides the Nepomuk ontology

- Other ontology packages could be installed on top, different instances 
of libsparql-lite and/or joining different sets of ontologies together 
should be made possible with libsparql-lite (on a GNOME and KDE desktop, 
app developers should aim to all target desktop-nepomuk).


- The FS miner and tracker-extract join together, tracker-extract 
becomes a user of libtracker-extract
  - By default has a backend that does SPARQL UPDATE on a 
libtracker-sparql setup with the desktop-nepomuk package (not very 
different from now, just separate)


- libtracker-extract gets extended with public API that aids miner 
writers with metadata extraction from streams, files and buffer (offset 
in a mmap, for example)


- Miners are separate projects (GNOME has already started this here 
https://git.gnome.org/browse/gnome-online-miners) (the FS miner should 
also be just like this)


Kind regards,

Philip

Op 25/06/2013 19:39, Tshepang Lekhonkhobe schreef:

On Mon, Jun 24, 2013 at 11:28 PM, Philip Van Hoof  wrote:

Wrote this one:

http://pvanhoof.be/blog/index.php/2013/06/24/a-use-case-for-sparql-and-nepomuk

Tracker-related blog posts are few and far between, so I celebrate
each time I see one. Thanks.
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list



___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] A use-case for SPARQL and Nepomuk

[Philip Van Hoof]

Op 26/06/2013 0:24, Philip Van Hoof schreef:

I can't resist writing down my ideas on this part. I must warn that it's 
very crazy. Heh ;-)


- The FS miner and tracker-extract join together, tracker-extract 
becomes a user of libtracker-extract
  - By default has a backend that does SPARQL UPDATE on a 
libtracker-sparql setup with the desktop-nepomuk package (not very 
different from now, just separate)


- libtracker-extract gets extended with public API that aids miner 
writers with metadata extraction from streams, files and buffer 
(offset in a mmap, for example)
Basically in libstreamanalyzer you make a |Strigi::IndexWriter| that you 
use as behaviour for |Strigi::StreamAnalyzer| (the setIndexWriter method 
on StreamAnalyzer takes what I call a strategy behaviour). The strategy 
can for example implement merging together Nepomuk statements to form a 
SPARQL UPDATE sentence. This is also what the tracker-topanalyzer.cpp 
does (when it actually worked).


With streams this can usually be done while streaming of the stream is 
taking place. Because of that I agree with Jos's design for stream based 
access, like for files and archive file types - in my opinion it's more 
capable than libtracker-extract and tracker-extract).


Because it's more difficult to add file format support for it, the 
Tracker project (during Nokia times) didn't pick libstreamanalyzer and 
instead we wrote our own extractor modules for tracker-extract. I must 
say that it was a close call: I discussed it a few times with 
libstreamanalyzer's maintainer, Jos, but we didn't have hard 
recuirements from Nokia to recurse into archive filetypes 
(notwithstanding we all agreed Strigi was *really* cool stuff). Not 
important for the customer in Scrum means no sprint task. No sprint task 
means that it never happens (unless the open source community picks it 
up, in which case it would have happened: this is also why I was allowed 
to experiment during one sprint-task with that tracker-topanalyzer.cpp).


The world didn't stop. So when I would get a carte blanche today, to 
design a new metadata extraction framework, I'd take the following into 
consideration (the world of metadata has changed massively):


/METADATA:/

1. Is sometimes minable from online resources (social media, services,
   etc) (You do a SPARQL UPDATE from a web miner which gets it);
2. Can arrive packaged together the dataobject with many
   synchronization solutions and use-cases (You do a SPARQL UPDATE from
   sync apps);
3. Is indeed often minable from local resources (files) (which is why
   the FS miner exists, strigi's libstreamanalyzer does this too);
4. Must sometimes be mined by recursively going into an archives (MIME
   documents, ZIP and tar archives) (main libstreamanalyzer's use-case);
5. Must sometimes aggregate from multiple resources to turn meaningful
   (for relationships between domains);
1. Metadata is everywhere, their dataobjects are everywhere.
   Informationelements ideally relate to other informationelements;
2. For example a Contact's geographical location is available on a
   web resource, his address was filled in in the contacts
   application by the user, his phone number got mined from the
   phone, his photo was taken using a camera (and his face was
   recognized and fingerprinted by the camera);
3. Ideally all of that metadata is found and then inserted as one
   transactional SPARQL INSERT;
1. The utopian "I have a dream"
2. This helps applications consuming contacts a lot: all info
   is instantly available at transaction commit, a single
   change signal, etc


I totally prefer Jos's design of libstreamanalyzer over 
libtracker-extract because it's clearly much more capable for #4 and #2. 
It'll be slower than simple open/read or mmap for #3 (Stream 
abstractions make things possible, but they don't make things faster) 
and more difficult because file format libraries usually don't offer a 
stream based API: Try libpng with a 'stream' pointing to a .png file in 
a ZIP file -> you have to write a stream based PNG metadata extractor 
from scratch whereas libtracker-extract can just use libpng. I salute 
Jos for trying to inspire people to "just do that".


However, I don't think it's necessarily a good fit for #1 and #5.

What I have in mind for a use-case like 5.2 is something like this:

We found out that there is a contact to mine
We find what the resources are that are available for this contact to 
get metadata from (very often we can introspect that from the contact's 
initial metadata)

We visit those resources and get the metadata

Example

Jos is a contact. Jos's metadata resources are:
   - Camera for photo relationships (is on the photo)
   - Website for geographical location (is in this city)
   - Or pho

Re: [Tracker] PATCH: Faster PNG extractor

[Philip Van Hoof]

Op 27/06/2013 19:06, Martyn Russell schreef:

That's quite some difference!

Thanks for posting some numbers. Important! :)

My first thought is, why did you create a new extractor instead of 
improve the original one?


Hi Martyn,

I think they might have opted for a different extractor because of this 
reason:


"If PNG-faster fails to read the PNG file (which should happen if, for 
instance the IDAT chunks are variable sized), the extractor will fail 
and the regular PNG extractor can re-try the extraction."


To be honest I kinda like the .rule file behaviour solution for this, 
although letting it fall back within one module also sounds good to me. 
Just that in terms of code maintainability and how the .rule system is 
designed, letting a 'faster' extractor fail based on file content's 
possibilities (in case the failure is trapped by a more generic 
extractor in the fall back) should in my opinion be fine as a practice. 
For example the faster video extractors also come upfront the slower 
GStreamer ones using the .rule system, for a similar reason.


The patch link you gave is good, but I would love to see a diff from 
our actual extractor right now to see how easily we could merge the 
changes into that one.


I think it should be open for debate first wether or not we want the 
specialized "fixed-sized IDAT chunk" based PNG extractor to be a 
separate extractor module and use the .rule system for prioritizing and 
allowing extractor modules to fall back to lower priority modules, or 
wether we want it to be in one PNG extractor.


Kind regards,

Philip

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] PATCH: Faster PNG extractor

[Philip Van Hoof]

Op 28/06/2013 8:30, Jonatan Pålsson schreef:

Hi Jonatan,

The main reason for not modifying the original extractor is that I 
want to keep it as a fallback if this new extractor fails due to an 
unexpected file structure. Since png-faster tries to skip to the end 
of the file by estimating the location of the metadata contained in 
the end of the file using the file size & IDAT chunk size, I predict 
it may fail more often than the original. Since tracker-extract 
handles these failures gracefully, this is not a problem however.


The best way I can see to get a similar functionality in to the 
existing extractor would be to modify libpng to allow skipping to the 
end of the file (right now there is a comment in the existing png 
extractor noting that this functionality is missing from the library), 
but since reading the PNG format is relatively simple I opted to put 
this functionality in the extractor rather than first patching libpng 
(I am not sure how much work this would be, either).


What are your thoughts on keeping png-faster as a separate, optional 
extractor module which can be enabled when extraction speed is of 
primary concern?


After reading this, my opinion is that we should keep it as separate 
modules. What do you think, Martyn?


Patching libpng is a longer term fine solution, too. Not sure how 
willing libpng maintainers will be, but for the time being we can deal 
with the opitmization this way.


Kind regards,

Philip

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] tracker-extract goes south

[Philip Van Hoof]

Hi Ralph,

Did you enable either libstreamanalyzer support, or Qt support (for 
pixbuf extraction)? That's --enable-qt or --enable-libstreamanalyzer.


Those are if I recall correctly the only two reasons for extractor 
modules to link with C++ code for tracker-extract. It's of course 
possible that one of the libraries that tracker-extract's modules link 
with have a C API with a C++ implementation. I think poppler might be 
like that. In that case we should try to find out what the parameters 
where for this one:


 fdf51bfe g_module_open (807c206, 2, fdbe2698, fdbe9176) + 2cc
 fdbe91bd load_module (8097d04, 1, 0, fdbe94a2) + 55

(With gdb you could print them if you up to that location in the stack 
after the crash, you'll also need debugging symbols of GLib and 
tracker-extract for that).


Kind regards,

Philip



Op 27/06/2013 17:54, Ralph Böhme schreef:

Hi

after a long and struggling journey I managed to get Tracker 0.15 mostly up and 
running with OpenCSW for Solaris [1].
The package still uses 0.15.2 because 0.16 depend on a newer glib package not 
available yet in OpenCSW.

Now, for some reason tracker-extract keeps crashing when fired via dbus or when 
launched manually. In order to preclude a faulty extract module causing this, I 
removed all but the text extract module:

$ pwd
/opt/csw/lib/tracker-0.16/extract-modules
$ ls
bak libextract-text.so
$ sudo rm -f /var/cores/*
$

# /opt/csw/libexec/tracker-extract --verbosity=3 --file=/Volumes/test/test.txt
Initializing tracker-extract...

Tracker-Message: Setting up monitor for changes to config 
file:'/root/.config/tracker/tracker-extract.cfg'
Locale 'TRACKER_LOCALE_LANGUAGE' was set to 'de_DE.UTF-8'
Locale 'TRACKER_LOCALE_TIME' was set to 'de_DE.UTF-8'
Locale 'TRACKER_LOCALE_COLLATE' was set to 'de_DE.UTF-8'
Locale 'TRACKER_LOCALE_NUMERIC' was set to 'de_DE.UTF-8'
Locale 'TRACKER_LOCALE_MONETARY' was set to 'de_DE.UTF-8'
Initializing Storage...
Mount monitors set up for to watch for added, removed and pre-unmounts...
No mounts found to iterate
Setting priority nice level to 19
Loading extractor rules... (/opt/csw/share/tracker/extract-rules)
   Loaded rule '10-abw.rule'
   Loaded rule '10-dvi.rule'
   Loaded rule '10-epub.rule'
   Loaded rule '10-html.rule'
   Loaded rule '10-ico.rule'
   Loaded rule '10-jpeg.rule'
   Loaded rule '10-mp3.rule'
   Loaded rule '10-msoffice.rule'
   Loaded rule '10-oasis.rule'
   Loaded rule '10-pdf.rule'
   Loaded rule '10-png.rule'
   Loaded rule '10-ps.rule'
   Loaded rule '10-tiff.rule'
   Loaded rule '10-xmp.rule'
   Loaded rule '11-msoffice-xml.rule'
   Loaded rule '90-text-generic.rule'
   Loaded rule '93-mplayer-generic.rule'
   Loaded rule '93-totem-generic.rule'
Extractor rules loaded
Couldn't get memory information:'/proc/meminfo', Datei »/proc/meminfo« konnte 
nicht geöffnet werden: No such file or directory
Guessing mime type as '(null)'
Segmentation Fault (Speicherabzug geschrieben)

The message "Guessing mime type as '(null)'" is just a broken debug message 
that uses the wrong variable, I've checked that...

$ sudo pstack /var/cores/core.tracker-extract.19507/1
core '/var/cores/core.tracker-extract.19507/1' of 19507:
/opt/csw/libexec/tracker-extract --verbosity=3 --file=/Volumes/test/te
-  lwp# 1 / thread# 1  
  fe63c422 memcpy   (8097f20, f79a7158, 1, f79866b1) + 22
  f7986721 __1cDstdGlocaleEinit6F_v_ (f796fb80, 9fbfe096, feffe95c, fe5a6dce, 
fda2c860, fda2fd44) + 81
  f79754fb 
__1cDstdNbasic_istream4Cwn0ALchar_traits4Cw___2t6Mn0AIios_baseJEmptyCtor__v_ 
(fda2fd28) + 6b
  f7974ef4 __SLIP.INIT_A (feffe9d8, f79bacb4, feffe9d8, f7995a79, fe7fb8bc, 
fb8406d8) + 34
  f797534b __1cU__STATIC_CONSTRUCTOR6F_v_ (fe7fb8bc, fb8406d8, fb840ed8, 
feffea18, fe7cbba6, fb840edc) + b
  f7995a79  (fb840edc, fe7fb35c, 1, fe7fb3e4, f799578c, 0)
  fe7cbba6 call_init (fb840e98, 1, 2, fe7cc1ad) + 11a
  fe7cc2a7 load_completion (fd9008b8, 0, feffea88, fe7d131d) + 10b
  fe7d13db dlmopen_check (fe7fb140, 8097dd8, 2, fdf40018) + cb
  fe7d14c5 dlopen   (8097dd8, 2, 1, fdf5130e) + 4d
  fdf51345 _g_module_open (8097dd8) + 43
  fdf51bfe g_module_open (807c206, 2, fdbe2698, fdbe9176) + 2cc
  fdbe91bd load_module (8097d04, 1, 0, fdbe94a2) + 55
  fdbe94c3 initialize_first_module (8095b00, fe7be504, fe7908c8, fdbe94fe) + 2d
  fdbe953b tracker_extract_module_manager_get_mimetype_handlers (809a6f8, 0, 
feffebd8, 80591c3) + 4b
  08059218 tracker_extract_get_metadata_by_cmdline (8080190) + 68
  0805bbdf run_standalone (807dec0, 805ebb8, feffec68, 805bdbe) + af
  0805bdd5 main (1, feffeca0, feffecb0, fe7fb8bc) + 19e
  0805660d _start   (3, feffed80, 0, 0, 0, feffedcd) + 7d
$

So it seems it's going south in some C++ init (std::locale::init ?), so this is 
possibly a crash related to some glib glitch, not a Tracker issue.


GLib doesn't use C++ afaik. I think it's a oninit problemin C++  of a 
library that one of the tracker-extract modules links with.




I'd 

Re: [Tracker] Tracker closing the databse

[Philip Van Hoof]

My opinion on this is that objects like cursor and connection should be 
marked with an interface called Disposable that defines a method called 
Close.


This way developers using it can more easily structure their code.

For example in a language like C# there is a language-specific feature 
named "using" for the purpose of supporting classes that implement 
Disposable:


public class Connection : IDisposable
{
public void Connect () {
db = sqlite3_open (...);
}

public void Dispose () {
if (db)
sqlite_close (db);
}
}

Client code:

using (Connection conn = new Connection()) {
conn.Connect();
Query = conn.Query("select ...");
foreach (var row in Query.Execute()) {
}
}

This in C# will ensure Connection conn to be disposed by its Dispose 
member defined by IDisposable. Implying that sqlite_close is called, for 
sure (guaranteed by the C# language).


Whenever a IDisposable isn't used with using and/or its Dispose method 
manually called (for example in a finally block of a try-catch-finally), 
the compiler by defaults errors or otherwise warns: the developer knows.


For a Vala language binding, this should happen with 
Tracker.SparqlConnection. In other language bindings it could also be 
handled. And with GObject introspection, code analyzers on GObject C 
code could also make those warnings take place at compile time.


What I'm trying to say is that it's not that because we are stupid 
enough to do C, that we should ignore or be blind for what is possible 
in other typed languages (I'm not a big fan of untyped languages, but 
I'll even go as far as to claim that we should even consider listening 
to the crazy dynamic language guys - however insanely crazy their 
'ideas' are).


Kind regards,

Philip


Martyn Russell schreef op 4/07/2013 22:02:

On 07/03/2013 02:43 PM, Putinei .Ionut wrote:

Hello,


Hello,


I run a  bunch for queries with tracker_sparql_connection_query(sync
version).with same TrackerSparqlConnection.

After 40-50 queries my app hangs.

I see in tracker log that about the same time tracker is closing the
sqlite database.

Do you have any advice for this issue?Could the fact that tracker is
closing database i get the hang?


Are you able to share the code with us?

I suspect you have references open to one or more TrackerSparqlCursor 
objects, though it's hard to tell without looking at the code.



Why is the reason to close the database.since i have seen in code
that close is done in "tracker_db_interface_sqlite_finalize" that is
seem like a destructor function GObject TrackerDBInterface.


Usually, if you unref and finish with the connection we clean up yes.
If you're not expecting this it could be related. Again, sharing the 
code would go a long way to help us help you figure out what might be 
the problem.


Thanks,



___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] Wrote Tracker propaganda

[Philip Van Hoof]

I wrote this one:

http://pvanhoof.be/blog/index.php/2013/07/06/why-do-you-need-tracker

Apologizes :-)
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Another Solaris patch

[Philip Van Hoof]

Hi Ralph,

Relax, all of the Tracker maintainers have full time daytime jobs. We 
will get to reviewing these patches soon.


I'm moving this weekend from my gf's appartment to my newly renovated 
house, which I expect to be pretty busy with. But I'll try to look at 
the patches of you and Jonatan as soon as possible.


If other team maintainers have more time, they can go ahead of course. 
Just give a small note here on the ML and/or reply with review comments 
as usual.


Kind regards,

Philip

Ralph Böhme schreef op 10/07/2013 19:37:

Hi

Am 05.07.2013 um 17:06 schrieb Ralph Böhme :

here's another one that adds a /proc/meminfo replacement.

hum, is everybody on vacation?

-r



___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list


___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Another Solaris patch

[Philip Van Hoof]

Hi Ralph,

I have applied this patch to master. Two notes for future.

ps. I wouldn't make these notes just for a single patch as yours, but as
I noticed there's an interest in publishing and pushing multiple such
patches I'll make the recommendations now:

o. Get the indentation right. Your patch used spaces for indentation. We
use tabs for indentation and spaces for alignment as described here:
http://pvanhoof.be/blog/index.php/2009/09/25/indentation

If you encounter old code that is wrongly indented, adapt the code
surrounding your patch to match those indentation rules (but don't adapt
the entire file, only the stuff relevant to your changes, as in the end
we still care more about git bisect working in a usable way than we care
about indentation nazism. Although Martyn, bless our great release
maintainer, can be a real pain in the ass when it comes to getting your
indentation right. Don't say I didn't warn you ;-).

I'm not sure if he's right or not for being so hard on this, but in the
end you'll have to yield and do it right or it just wont get in. Hehe.
Someday we'll be big and strong like Martyn, bless our great release
maintainer, and then you can enforce arbitrary code indentation rules
yourself. We love you Martyn.

o. Put the component that you committed to upfront the commit message.
In this case you could have used 'libtracker-common: what you changed'.

When you have multiple components you can separate them with comma's
before the colon or you can omit the ones where insignificant changes
where made. Ideally you split the commits up per such component. For
example if you made changes to the SPARQL endpoint to support a new
feature of the filesystem indexer, commit first to the libtracker-sparql
and tracker-store components before committing the dependent filesystem
indexer changes.

Etcetera:

Note that we're as a team very much into keeping our git repository
usable and clean as an actual code repository with good commit history.
So we're not just using it as a code backup or archive like most
software developers do.

In principle must every commit compile and work (unit tests and
functional tests must all pass). BUT we DON'T like huge commits. Each
commit must be reviewable easily. Gerrit style.

(Always) work in a branch, do git rebase -i master (or origin) to rebase
your branch commits on top of master (and merge them, indeed), and then
git push rebasedbranch:master or do git checkout master; git merge
rebasedbranch; git push origin master. That or just publish to us your
rebasedbranch (on github for example) and then we'll push it.


Kind regards,

Philip

- 


On Fri, 2013-07-05 at 17:06 +0200, Ralph Böhme wrote:
> Hi
> 
> here's another one that adds a /proc/meminfo replacement.
> 
> -Ralph
> 
> ___
> tracker-list mailing list
> tracker-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/tracker-list

-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] PATCH: Allow disabling all extractors

[Philip Van Hoof]

On Tue, 2013-07-09 at 13:35 +0200, Jonatan Pålsson wrote:
> Hi list,

Hi Jonatan,

> I noticed it is not possible to disable some of the extractors
> provided with Tracker (such as the extractor for generic text, DVI and
> PS). This is a feature I needed, so I added --enable/--disable
> switches to the configure.ac script for the extractors not currently
> switchable. The default is of course to have these extractors enabled.
> 
> If this is of interest, I come bearing patches :)

Good!

> Allow disabling PNG:
> Allow disabling AbiWord:
> Allow disabling DVI:
> Allow disabling MP3:
> Allow disabling PS:
> Allow disabling generic text:
> Allow disabling icon / .ico
> Also, I added a switch to not install the Tracker graphics (which are
> only interesting for systems capable of displaying graphics):

I've pushed them all as-is. The patches where good.

> I could also instead post the patches as diffs (or one big diff) to
> the mailing list if this is preferable.

Nope, this was awesome.

Ideally you prepare a branch without the Tracker-IVI specific commits.
That way I don't have to skip them while rebasing your commits on top of
master. That should be your task ;-), as I'm not a maintainer of the
Tracker-IVI work.

For example
git checkout -b optional_extractors tracker-ivi/optional_extractors
git branch optional_extractors_upstream
git rebase -i optional_extractors
#Comment out the Tracker-IVI specific commits' pick lines
git push tracker-ivi optional_extractors_upstream

And you publish (just) optional_extractors_upstream to us.

I also recommend not using autogen.sh for your Tracker-IVI specific
configure switches. You should use your package system's features for
this purpose instead. Consider taking a look at Tracker's gitorious
repository which hosts the branches and tags for MeeGo Harmattan's
debian packaging and adaptations that are specific for the N9.

Just do the exact same thing.

Kind regards,

Philip

-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Another Solaris patch

[Philip Van Hoof]

On Thu, 2013-07-11 at 11:42 +0200, Tshepang Lekhonkhobe wrote:
> 2 things

:)

> * Martyn is great indeed

He's awesome.

> * You likely forgot about
> https://wiki.gnome.org/Tracker/Documentation/CodingStyle

Having so much documentation that maintainers like myself forget about
it, is a good thing ;-)

Hope you will be on your horse massively testing those Tracker-IVI
things, Tshepang. We can always use community testing the way you did
for us previously! Just promise me to make it really hard for them to
introduce bugs (oh and remind me to buy you a couple of beers if we ever
meet at a conference, for your testing and reviewing work).

Kind regards,

Philip

-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] My disagreement with a recent change in the ontology for GNOME Notes

[Philip Van Hoof]

Hi Pierre-Yves,

I should probably have watched the ML more carefully now that it's committed 
and too late.

https://git.gnome.org/browse/tracker/commit/?id=6c1885f241880b528d29c2270022dac2bdd5be86
https://bugzilla.gnome.org/show_bug.cgi?id=701828

+nfo:xmlContent a rdf:Property ;
+   rdfs:comment "XML/HTML or other rich representation of a document" ;
+   nrl:maxCardinality 1 ;
+   rdfs:domain nfo:Document ;
+   rdfs:range xsd:string .

I disagree with this approach. We should not put formatted content into
the Nepomuk storage:

The field is useless for any other application but the hosting
application. We can't query it, because its contents are formatted and
we don't have query capabilities to query your formatted contents. And
even if we would allow storage of formatted content like XML, we should
enforce the format using a DTD or other XML schema so that we're sure
that the inserted format is valid and known.

Neither of that is what nfo:xmlContent specifies, so I think it does not
belong in the ontology at all. Tracker's Nepomuk storage isn't a
freeform 'store whatever you want' with the sole exception of
nie:plainTextContent (which I honestly dislike a lot for the same
reason).

If GNOME Notes wants to store notes in Tracker, then it should store
data and metadata in it. And store UI data, like X/Y positions and list
offsets or indexes by itself. This simply does not belong in Tracker, at
all.

Allowing GNOME application to store whatever they want, using XML or not
(as I don't care about the actual format), is crazy. Model your
application correct and store information correct. Don't abuse Tracker
to solve your 'whatever' storage needs. And XML is indeed 'whatever',
just like JSON, binary, CSV, etc are: we can't use them in SPARQL.


Kind regards,

Philip

-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] My disagreement with a recent change in the ontology for GNOME Notes

[Philip Van Hoof]

This is an example how you should do it instead, Pierre-Yves:

https://wiki.gnome.org/Tracker/Documentation/Examples/SPARQL/Email

MIME as document type is probably a lot more rich than GNOME's notes
format is. Yet we have modeled MIME into the NMM ontology just fine.

Note that the text/html contents are not stored in the examples.

The reference to the text/html part should be a nfo:DataObject. For
example a nfo:FileDataObject with a nie:url pointing to a file on the
filesystem containing the text/html contents. It could also be a nie:url
pointing to a uri schema that triggers a messaged daemon into fetching
and/or giving you the MIME part over a FD passed D-Bus IPC, much like
gvfs's FS daemons work.

Neither such an E-mail nor gvfs should store HTML documents (on a SAMBA
or a IMAP storage) into Tracker's Nepomuk storage. Even the
nie:plainTextContent is a questionable thing to store (and embedded
users of Trackers are questioning us removing the property for storage
capacity reasons).

If you want GNOME notes to offer text/html contents, while allowing
applications to query Tracker over SPARQL for notes, use nie:url with
nfo:DataObject and provide a service that delivers the contents to the
querying application.

Let us know when you have fixed this design mistake so that we can
remove the xmlContents property from our ontology. As I doubt that
Nepomuk upstream would ever accept this anyway.

Kind regards,

Philip

On Thu, 2013-07-11 at 13:22 +0200, Philip Van Hoof wrote:
> Hi Pierre-Yves,
> 
> I should probably have watched the ML more carefully now that it's committed 
> and too late.
> 
> https://git.gnome.org/browse/tracker/commit/?id=6c1885f241880b528d29c2270022dac2bdd5be86
> https://bugzilla.gnome.org/show_bug.cgi?id=701828
> 
> +nfo:xmlContent a rdf:Property ;
> + rdfs:comment "XML/HTML or other rich representation of a document" ;
> + nrl:maxCardinality 1 ;
> + rdfs:domain nfo:Document ;
> + rdfs:range xsd:string .
> 
> I disagree with this approach. We should not put formatted content into
> the Nepomuk storage:
> 
> The field is useless for any other application but the hosting
> application. We can't query it, because its contents are formatted and
> we don't have query capabilities to query your formatted contents. And
> even if we would allow storage of formatted content like XML, we should
> enforce the format using a DTD or other XML schema so that we're sure
> that the inserted format is valid and known.
> 
> Neither of that is what nfo:xmlContent specifies, so I think it does not
> belong in the ontology at all. Tracker's Nepomuk storage isn't a
> freeform 'store whatever you want' with the sole exception of
> nie:plainTextContent (which I honestly dislike a lot for the same
> reason).
> 
> If GNOME Notes wants to store notes in Tracker, then it should store
> data and metadata in it. And store UI data, like X/Y positions and list
> offsets or indexes by itself. This simply does not belong in Tracker, at
> all.
> 
> Allowing GNOME application to store whatever they want, using XML or not
> (as I don't care about the actual format), is crazy. Model your
> application correct and store information correct. Don't abuse Tracker
> to solve your 'whatever' storage needs. And XML is indeed 'whatever',
> just like JSON, binary, CSV, etc are: we can't use them in SPARQL.
> 
> 
> Kind regards,
> 
> Philip
> 

-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] My disagreement with a recent change in the ontology for GNOME Notes

[Philip Van Hoof]

On Thu, 2013-07-11 at 13:52 +0200, Pierre-Yves Luyten wrote:

Hi Pierre-Yves,
 
> > I should probably have watched the ML more carefully now that it's
> > committed and too late.

> My bad, I hope the fact there was no release yet allows us to revert
> without concern.

No problem, no hurry, take your time to fix Notes first.

> > We can't query it, because its contents are formatted and
> > we don't have query capabilities to query your formatted contents. And
> > even if we would allow storage of formatted content like XML, we should
> > enforce the format using a DTD or other XML schema so that we're sure
> > that the inserted format is valid and known.
> 
> 
> I think pushing data into Tracker make sense if the format is
> understood by several applications. Which is why i first thought "HTML",
> and pushing there only the *representation* of the note.

Not only should the format be known, common and specified; we also need
to have a possibility to query it.

With XML data we would have to bring in XPath inside of SPARQL to query
on fields that are XML. This would have profound effects on the query
speed as this goes completely outside of the realm of SPARQL (meaning
that on for example a Cartesian product, during a join, and/or subquery,
we'd have to perform the XPath query on each row: bye bye any form of
reasonable performance, even when dealing with a few hundred rows).

And of course XML allows you to store subfields in fields:

John

How do we query for all notes that came from John? With SPARQL (without
having to introspect the nfo:xmlContent)?

Instead you should of course use the NCO ontology and relate a contact
as the from of your note (like the NMO does for MIME among onther
message types).

> However in the specific case of notes, XML seemed correct since Tomboy
> format [1] is already understood by several applications, such as
> Tomboy, Gnote, Conboy, Tomdroid, ongoing Macboy - and Bijiben. (In the
> XML case however, we can notice if we stick to Tomboy format, both rich
> content and metadata are to be stored.)

The text/html and the iCal format are also already understood by a
multitude of applications, and yet neither NFO, NCO, NMO nor NCAL are
storing HTML (NFO, NMO), from/to as iCal (NCO) or the calendar item as
iCal (NCAL): the ontologies model the data instead.

You need to do the same for notes. I'd be ok with creating a Nepomuk
Notes Ontology, if that suits the needs of Tomboy, GNote, Conboy,
Tomdroid, Macboy and Bijiben. Get those people's heads together and
negotiate a appropriate Notes ontology. Then talk with us and/or KDE's
Nepomuk team and then we can as a group in agreement propose this to
upstream Nepomuk.

I can't imagine nfo:xmlContent being accepted and so this way Tracker
will be the only Nepomuk implementation that has it. That's not good for
anybody.


> > Don't abuse Tracker to solve your 'whatever' storage needs.
> 
> Sure, this is not the idea at all.

Then we agree :-)


Kind regards and thanks for picking this up,

Philip

> Regards,
> Pierre-Yves
>  
> [1] https://wiki.gnome.org/Tomboy/NoteXmlFormat

Sure. Nice format. For you to store.


-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Clues regarding improving performance of tracker-store

[Philip Van Hoof]

Ivan Frade schreef op 12/07/2013 18:52:

Hi guys,

I plan to write a more detailed guide to improving insert performance 
when I have more time. This weekend I'm very busy with moving from my 
gf's appartment to my newly renovated house ;), so i'll keep it short.


Important is to use the INSERT OR REPLACE feature instead of 
DELETE+INSERT, another thing you can do is increase the LRU cache size 
and tweak the various buffer sizes we have in tracker-data-update.c.


Finally changing the ontology could help. But because of the decomposed 
schema you wouln't touch tables of ontology domains that aren't related 
to your insert of data a lot.


Except indeed when there are hierarchies. So if a total ontology rewrite 
is fine, try to reduce inheritance. Aggregation over inheritance ('has 
a' instead of 'is a') in the ontology will often be faster, but it also 
depends on a variety of things for which you should study the insert 
queries that we generate for a given insert v. ontology situation. 
Aggregation will often make your SELECT queries more complicated (and if 
you need the data, probably slower too). We optimized first for read 
speed, then write speed.


The inserting, updating and deleting on the SQL layer itself is by the 
way not the only thing that influences insert performance. The SPARQL 
parsing, buffering and grouping into transations among other things 
(like IPC overhead) also play a role. Although I must say that after so 
many years of being plagued by Nokians who didn't like Tracker because 
it was Not Invented Here (not by their own team) and somewhat enforced 
upon them, we did ensure that it's really really optimized (and teams 
where challenged to find performance improvements and open bugs on them, 
instead of making empty arguments that it's not). It would surprise me 
if you'd find a single strdup or malloc that shouldn't be there, for 
example. But I'll be more than happy if you eliminate one.


Next you have indexes and domain specific indexes that'll slow down 
inserting. And you have the signals on changes that you can turn off on 
a class, which will have a memory usage and performance impact while 
inserting (not doing something is always faster than doing something).


If you don't need FTS, then disabling FTS should make a huge performance 
improvement. For the same reason (a lot of things wont be done anymore, 
which is always faster than doing them. But FTS is also a nice feature 
to have. So make your choice).




 Most of my ideas for improving performance are domain specific (cut 
Tracker to do exactly what you need). Philip wrote also some ideas to 
reduce the database file size recently in this mailing list.


A lot of those ideas need to be implemented. Some of them aren't easy. 
And yet others are in Jürg's mind waiting to be unleashed on the world. 
And some in my mind, but then I'm sure Jürg thought about it too already ;-)


Kind regards,

Philip

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] PATCH: Allow specifying user data & cache directory paths in DConf

[Philip Van Hoof]

Hi Jonatan,

When you do something like this:

+  if (cache_dir == NULL || g_strcmp0 (cache_dir, "") == 0) {
+cache_dir = g_build_filename (g_get_user_cache_dir (),
+  "tracker",
+  NULL);

Then you can leak cache_dir in case cache_dir = strdup(""). This isn't 
allowed in Tracker's code. You did the same thing for data_dir.


I guess a simple ok-fix would be to put g_free(cache_dir) upfront the 
g_build_filename assignment. That works for NULL too, so it's fine that way.



Jonatan Pålsson schreef op 8/08/2013 15:42:

Hi list,

I would like to re-locate the user data directory and user cache.
Currently these directories are retrieved using g_get_user_data_dir ()
and g_get_user_cache_dir (), which in turn may be affected by the user
by setting appropriate XDG_* variables. I would however like a more
persistent setting, so I added the user-cache-dir and user-data-dir
keys to the org.freedesktop.Tracker.DB namespace in DConf.

The behavior of the two keys is similar. If the key is set, it takes
precedence over g_get_user_*_dir () and the supplied path is used for
storing the files. If the key is empty (the default setting), the old
behavior is preserved.

Please see the following patch:
https://github.com/Pelagicore/tracker-ivi/commit/213456024d686305d0f6a30b09fa81f04e601fdd

I also have a patch for setting the path to the ontology directory. I
will submit it in a different thread to keep the discussion separate.



___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] PATCH: Allow specifying the ontology directory in DConf

[Philip Van Hoof]

Hi Jonatan,

You're leaking db_config. You must clean it up in the or a shutdown 
function (and make sure it's called if that db_config was instantiated).


Kind regards,

Philip

Jonatan Pålsson schreef op 8/08/2013 15:42:

Hi list,

Currently it is possible to specify the directory holding the Tracker
ontologies using a pre-processor flag. I would however like this to be
more configurable (due to work with custom ontologies). The following
patch allows users to configure the ontologies directory using a key
in DConf. The new key is called ontologies-dir and is placed in
org.freedesktop.Tracker.DB.

The patch is available here:
https://github.com/Pelagicore/tracker-ivi/commit/70037b236124a2354a7928786a9047c29b67de79

I don't believe the patch will apply cleanly without first applying
https://github.com/Pelagicore/tracker-ivi/commit/213456024d686305d0f6a30b09fa81f04e601fdd
(user data & cache in DConf) - but I can create a clean patch if this
previous patch is not of interest.



___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] PATCH: Fix segfault in tracker-ontologies (shows in tracker-miner-fs) when ontologies are missing

[Philip Van Hoof]

Ho Jonatan,

I don't really agree with this approach. We should not 'just' check for 
NULL and let the software continue as if nothing happens. Invalid 
ontologies means that we can't go on. So abort() is probably the only 
sensible way out.


Trying to accept that stuff returns NULL and then happily continuing the 
rest of the software isn't really an option. Either the software can do 
its stuff and then it does it, or it can't and then it aborts (with an 
appropriate error message and/or error mechanism). Trying to continue 
and by that further destroying data and/or corrupt databases is not good.


In this case what could also be done, if you do want to improve 
error-handling, is that tracker-store returns an error for each and 
every of its D-Bus calls. I don't consider trying to handle NULL an 
improvement (rather, it's worse that way as you know about the problem 
later in the code rather than sooner this way).


Kind regards,

Philip

Jonatan Pålsson schreef op 8/08/2013 15:42:

Hi list,

When moving the ontology directory around (I recently submitted a
patch for this functionality), I noticed that tracker-miner-fs
segfaults when the ontologies are not found. I think there should be a
check for ontology presence, and also ontology validity, but have not
yet implemented this.

I have however added some checks for the return value of the
gvdb_table_list () function, which seems to return NULL when the gvdb
files are bad. These files go bad when no ontologies are loaded.

To reproduce the segfaults, move the $PREFIX/share/tracker/ontologies
directory temporarily, so that it cannot be found. Or apply the
previous patch which allows configuring the ontology directory path,
and mess the path up from DConf ;)

The following patch guards for NULLs when reading gvdb files during
the loading of namespaces, classes and properties. Warning messages
are printed when either of the aforementioned values are missing.

Here's the patch:
https://github.com/Pelagicore/tracker-ivi/commit/d643bbfe0442d43c83124aebc0c55470f5675117



___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] REVIEW: Fix Deprecations Branch

[Philip Van Hoof]

On Tue, 2013-09-03 at 17:53 +0100, Martyn Russell wrote:
> Hi all,
> 
> Jürg, Philip, any chance of a quick review from you guys:
> 
>https://git.gnome.org/browse/tracker/log/?h=fix-deprecations
> 
> Jürg, I actually couldn't see a GTask VAPI on my distro, I guess it's 
> available in later versions of Vala?


Compare these two APIs, I think you need to pass the cancellable as
parameter to g_task_new here:

https://developer.gnome.org/gio/2.36/gio-GIOScheduler.html#g-io-scheduler-push-job
https://developer.gnome.org/gio/2.36/GTask.html#g-task-new


WritebackData *data;
+   GTask *task;
+
+   task = g_task_new (controller, NULL, NULL, NULL);
data = writeback_data_new (controller,
   writeback_handlers,
   priv->connection,
   subject,
   results,
   invocation,
   request);
 
-   g_io_scheduler_push_job (io_writeback_job, data, NULL, 0,
-data->cancellable);
+   g_task_set_task_data (task, data, NULL /*(GDestroyNotify) 
writeback_data_free */);
+   g_task_run_in_thread (task, io_writeback_job);
+   g_object_unref (task);


So it should go like this:


data = writeback_data_new (controller,
   writeback_handlers,
   priv->connection,
   subject,
   results,
   invocation,
   request);

task = g_task_new (controller, data->cancellable, NULL, NULL); 




-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] REVIEW: Fix Deprecations Branch

[Philip Van Hoof]

On Fri, 2013-09-06 at 13:53 +0200, Jonatan Pålsson wrote:
> Hi Martyn!
> 
> On 6 September 2013 13:36, Martyn Russell  wrote:
> > On 06/09/13 10:01, Jonatan Pålsson wrote:

[cut]

> I have a feeling that the "ontologies.gvdb" file influences the
> behavior I observed. This may have been my imagination however. This
> file is not removed by the tracker-control -r command. By the way, is
> this intended, or is tracker-control -r supposed to remove the gvdb
> file as well? The manual says -r will remove *databases* - which it
> indeed does, but the gvdb file?

The ontologies.gvdb file is needed to detect ontology changes. It's not
a database with content except for the most current ontology (which is
meta information). Although if there's no content then no ontology
changes must ever happen, of course. This, however, depends on the
existence of backups by the user (a user can restore a backup and gain
content databases that way).


> 
> As a side note, the tracker-store.ontology.journal file also survives
> "tracker-control -r", is this also the intended behavior? Otherwise I
> might write up a patch for removing these two files.

Same explanation.

Perhaps we can remove these files on tracker-control -r (or add another
flag that does this), but I'd rather await Jürg's input on this as I
remember we concluded that there are use-cases for which the files must
not be removed.

> >> /usr/local/libexec/tracker-store
> >>
> >> After these commands, the store should segfault.
> >>
> >> Also, perhaps related to the crashes;
> >> - on line 963 of tracker-data-update.c , should GValueArray actually
> >> be a GArray? I believe resource_buffer->predicates is a GArray
> >> already, but is assigned the wrong type here. (see line 1371)
> >

Read deprecation note here:

https://developer.gnome.org/gobject/stable/gobject-Value-arrays.html#g-value-array-new

And compare with this API:

https://developer.gnome.org/glib/unstable/glib-Arrays.html#g-array-sized-new

And then look at line 1375

old_values = g_array_sized_new (FALSE, TRUE, sizeof (GValue),
multiple_values ? 4 : 1);

Notes on GValueArray:

The prime purpose of a GValueArray is for it to be used as an object
property that holds an array of values. A GValueArray wraps an array
of GValueelements in order for it to be used as a boxed type
through G_TYPE_VALUE_ARRAY.

GValueArray is deprecated in favour of GArray since GLib 2.32. It is
possible to create a GArray that behaves like a GValueArray by using the
size ofGValue as the element size, and by setting g_value_unset() as the
clear function using g_array_set_clear_func(), for instance, the
following code:

   1
GValueArray *array = g_value_array_new (10);
can be replaced by:

   1
   2
GArray *array = g_array_sized_new (FALSE, TRUE, sizeof (GValue), 10);
g_array_set_clear_func (array, (GDestroyNotify) g_value_unset);


I'm idd not entirely sure whether the GLib team also ensures
compatibility with the GVAlueArray struct, though.


> > Great that you noticed this. Did fixing this fix the crashing for you?
> > I would accept patches to that branch if you've got the time.
> >
> 
> Unfortunately it did not :( I did however get different segfaults, so
> it appears to have fixed one of the issues. I may have time to push
> some to this branch, but I would like to solve all the segfaults first
> (locally on my machine), to ensure the patches are good.




-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] PATCH: Fix segfault when peeking on an empty TrackerPriorityQueue

[Philip Van Hoof]

Thanks for the patches Jonatan,

I have reviewed and pushed these commits to master.

Kind regards,

Philip

On Thu, 2013-09-12 at 10:57 +0200, Jonatan Pålsson wrote:
> Hi list,
> 
> I noticed tracker_priority_queue_peek will try indexing outside the
> segments array's bounds when the priority queue is empty.
> 
> Here's a patch which adds a bounds check:
> https://github.com/Pelagicore/tracker-ivi/commit/2a98cb923f99e85dcda10106bf6c338fe11bb8bc
> 
> Here's a patch testing the new check, and also showing the issue with
> the old code:
> https://github.com/Pelagicore/tracker-ivi/commit/3c2f32b0067ffca3ed1fe94ff118cecdb5d8bd58
> 

-- 
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] performance analysis on tracker

[Philip Van Hoof]

Hi Leng,

Check out
https://git.gnome.org/browse/tracker/tree/tests/functional-tests/performance-tc.py

Kind regards,

Philip

Leng, John schreef op 13/09/2013 16:01:

Hi all,

I'm a fresh guy to tracker.
I want to do some analysis on tracker, is there any reference or suggestion ?
Any method will be appreciate.
Thanks.

Best Regard,
John
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list



___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Disable indexing on NFS

[Philip Van Hoof]

Hi Janinko,

I don't think tracker's fs miner detects NFS mount points (yet, as I 
think a patch for that would be a great idea). You could add the mount 
point to your list of ignores in Tracker's config as a temporary solution.


ps. If writing a patch to detect NFS mount points, the patch shouldn't 
make it impossible to do so. As scanning NFS mount points ought to be a 
possible use-case.


Kind regards,

Philip

janinko.g schreef op 13/09/2013 21:11:

Hello,

How can I tell tracker to ignore NFS? Every time I start my computer, 
my NAS server gets overloaded, because tracker wants to reindex 
everything on in.


Thanks,
Honza Brázdil


___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list


___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Disable indexing on NFS

[Philip Van Hoof]

Martyn Russell schreef op 16/09/2013 18:46:

[cut]


ps. If writing a patch to detect NFS mount points, the patch shouldn't
make it impossible to do so. As scanning NFS mount points ought to be a
possible use-case.


The question is really whether we consider ANY mount point. Currently 
we index all mount points separately but we also coalesce them, e.g. 
if we have:


  /media/a
  /media/b

both should be indexed. However, if we have:

  /media/a
  /media/a/nfs-mounted-location/

The second of the two should be consolidated into the first because 
it's a parent of the second.


That's all fine - but what I think is happening here is we are 
indexing $HOME and there is an nfs mount in $HOME/foo perhaps? It's 
also quite possible that people mount other file system types in 
$HOME/bar, etc. So the question becomes: do we want to have an option 
to stay on the same file system or not - that should cover all NFS and 
other file system type cases.


Thoughts?


I agree. No immediate thoughts from me on this. I'm guessing that if the 
indexer is handling both right, the second pass over files of $HOME/foo 
should cooperatively work against the first pass and the other way 
around. But it's not ideal that a second pass happens in the first 
place. I'm guessing some level of detecting this at configuration 
parsing or at another later location in the FS miner wouldn't be the 
worst idea.


Kind regards,

Philip

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Tracker creating multiple entries in Media Players

[Philip Van Hoof]

Hi Benjamin,

Unfortunately you are out of luck (or you are lucky if you love 
programming the solution, as you will have to do this):


The version of Tracker on the N900 is really old. Many softwares running 
on the N900 are not compatible with more recent versions of Tracker.  
After the release of the N900 the Tracker team completely redesigned 
Tracker. This includes its client API (from a RDFQ API to a SPARQL based 
one).


No complete compatibility layer has been written (and the existing one 
would need to be completed to make more recent versions of Tracker run 
on a N900). The existing one is also no longer being shipped with 
Tracker. You need Tracker 0.8's versions to find its source code.


As many softwares running on the N900's Maemo Diablo are using the old 
API, you would need to implement this API using the new infrastructure 
(while keeping the ABI and API compatible, which basically means that 
you can't change the .h file while reimplementing the .c file):


https://git.gnome.org/browse/tracker/tree/src/libtracker?h=tracker-0.6

The new infrastructure can do more than the ancient release, so this 
isn't impossible. It's also not easy. During the 0.8 releases attempts 
where made to provide such a compatibility layer. Back then this was 
done for a Nautilus Tags plugin that was using the old API and could not 
be replaced/rewritten as new releases of Tracker happened (the ones 
which were a complete redesign of Tracker):


https://git.gnome.org/browse/tracker/tree/src/libtracker-client/tracker.c?h=tracker-0.8#n1500
https://git.gnome.org/browse/tracker/tree/src/libtracker-client/tracker.c?h=tracker-0.8#n1554
https://git.gnome.org/browse/tracker/tree/src/libtracker-client/tracker.c?h=tracker-0.8#n1614
https://git.gnome.org/browse/tracker/tree/src/libtracker-client/tracker.c?h=tracker-0.8#n1684

In theory those implementations should be sufficient to make a new 
Tracker work on a N900 Maemo Diablo. But this has never been tested (the 
compatibility layer wasn't made for a upgrade of the N900 Maemo Diablo's 
Tracker, but for the GNOME desktop and in particular just for the 
Nautilus plugin).


Doing all this would, however, be a really, really nice improvement for 
the N900's operating system to upgrade its Tracker to a modern version. 
Among other things you'll reduce battery consumption, fix hundreds of 
bugs and improve CPU and I/O utilisation. I'm pretty sure that the 
compatibility layer will also introduce bugs. So ..


Good luck!

Kind regards,

Philip


Benjamin Oppermann schreef op 6/10/2013 17:01:

Following up:
The current version of Tracker on Maemo 5 is 0.6.95-25maemo1+0m5, dated
2010-05-26
details here: http://maemo.org/packages/view/tracker/
Ben


On Sun, Oct 6, 2013, at 03:33 AM, Benjamin Oppermann wrote:

Hello,
Tracker handles the indexing of media files in Maemo 5 on the Nokia N900
for use in the media player.
In said media player, a great percentage of my music tracks are
presented as duplicates, even though the files are present only once on
the device. In Maemo forums, three ideas are circulating about how to
handle this:
1) tracker-processes -r
did not solve anything for me as the database was rebuilt with the same
fault again.
2) touch name-of-duplicate-file
Is no good for me as the problem regards not just one file, but a couple
hundred or more - not all of them, but too many to do this manually for
each one.
3) deleting the tracker folder (haven't tried that yet but looks to me
like it'd amount to the same effect as 1).

Well I just wanted to hear what you guys think about it, maybe this has
been fixed in newer versions of tracker. Unfortunately I'm unable right
now to tell which version of Tracker is used in Maemo.

Thanks,
Ben

P.S. Here are the related threads in Maemo forums:
http://talk.maemo.org/showthread.php?p=1377437#post1377437
http://talk.maemo.org/showthread.php?t=76086


--
   
   bennypr0f...@myopera.com

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list




___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Tracker creating multiple entries in Media Players

[Philip Van Hoof]

Hi Benjamin,

Sorry, I forgot to mention that the older release is no longer 
maintained (if you want to start maintaining it and/or fix this bug, go 
ahead of course. You need the 0.6 branch and this tag):


https://git.gnome.org/browse/tracker/tag/?h=tracker-0.6&id=TRACKER_0_6_95

To get the packaging stuff of your particular version, use this:
https://gitorious.org/tracker/tracker/commits/f149ba68f166fdb2328dccc14f000bf9631eff5b

Debian packaging debian/ dir for Maemo Diablo:
https://gitorious.org/tracker/tracker/source/f149ba68f166fdb2328dccc14f000bf9631eff5b:debian

You'll need a complete Diablo development environment in Scratchbox to 
build it with dpkg-buildpackage.


Either way, good luck :)

Kind regards,

Philip

Philip Van Hoof schreef op 7/10/2013 11:52:

Hi Benjamin,

Unfortunately you are out of luck (or you are lucky if you love 
programming the solution, as you will have to do this):


The version of Tracker on the N900 is really old. Many softwares 
running on the N900 are not compatible with more recent versions of 
Tracker.  After the release of the N900 the Tracker team completely 
redesigned Tracker. This includes its client API (from a RDFQ API to a 
SPARQL based one).


No complete compatibility layer has been written (and the existing one 
would need to be completed to make more recent versions of Tracker run 
on a N900). The existing one is also no longer being shipped with 
Tracker. You need Tracker 0.8's versions to find its source code.


As many softwares running on the N900's Maemo Diablo are using the old 
API, you would need to implement this API using the new infrastructure 
(while keeping the ABI and API compatible, which basically means that 
you can't change the .h file while reimplementing the .c file):


https://git.gnome.org/browse/tracker/tree/src/libtracker?h=tracker-0.6

The new infrastructure can do more than the ancient release, so this 
isn't impossible. It's also not easy. During the 0.8 releases attempts 
where made to provide such a compatibility layer. Back then this was 
done for a Nautilus Tags plugin that was using the old API and could 
not be replaced/rewritten as new releases of Tracker happened (the 
ones which were a complete redesign of Tracker):


https://git.gnome.org/browse/tracker/tree/src/libtracker-client/tracker.c?h=tracker-0.8#n1500 

https://git.gnome.org/browse/tracker/tree/src/libtracker-client/tracker.c?h=tracker-0.8#n1554 

https://git.gnome.org/browse/tracker/tree/src/libtracker-client/tracker.c?h=tracker-0.8#n1614 

https://git.gnome.org/browse/tracker/tree/src/libtracker-client/tracker.c?h=tracker-0.8#n1684 



In theory those implementations should be sufficient to make a new 
Tracker work on a N900 Maemo Diablo. But this has never been tested 
(the compatibility layer wasn't made for a upgrade of the N900 Maemo 
Diablo's Tracker, but for the GNOME desktop and in particular just for 
the Nautilus plugin).


Doing all this would, however, be a really, really nice improvement 
for the N900's operating system to upgrade its Tracker to a modern 
version. Among other things you'll reduce battery consumption, fix 
hundreds of bugs and improve CPU and I/O utilisation. I'm pretty sure 
that the compatibility layer will also introduce bugs. So ..


Good luck!

Kind regards,

Philip


Benjamin Oppermann schreef op 6/10/2013 17:01:

Following up:
The current version of Tracker on Maemo 5 is 0.6.95-25maemo1+0m5, dated
2010-05-26
details here: http://maemo.org/packages/view/tracker/
Ben


On Sun, Oct 6, 2013, at 03:33 AM, Benjamin Oppermann wrote:

Hello,
Tracker handles the indexing of media files in Maemo 5 on the Nokia 
N900

for use in the media player.
In said media player, a great percentage of my music tracks are
presented as duplicates, even though the files are present only once on
the device. In Maemo forums, three ideas are circulating about how to
handle this:
1) tracker-processes -r
did not solve anything for me as the database was rebuilt with the same
fault again.
2) touch name-of-duplicate-file
Is no good for me as the problem regards not just one file, but a 
couple

hundred or more - not all of them, but too many to do this manually for
each one.
3) deleting the tracker folder (haven't tried that yet but looks to me
like it'd amount to the same effect as 1).

Well I just wanted to hear what you guys think about it, maybe this has
been fixed in newer versions of tracker. Unfortunately I'm unable right
now to tell which version of Tracker is used in Maemo.

Thanks,
Ben

P.S. Here are the related threads in Maemo forums:
http://talk.maemo.org/showthread.php?p=1377437#post1377437
http://talk.maemo.org/showthread.php?t=76086


--
  bennypr0f...@myopera.com
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list




_

Re: [Tracker] Automatically creating an album for screenshots

[Philip Van Hoof]

Hi Martyn and Debarshi,

Martyn Russell schreef op 7/10/2013 13:28:

On 07/10/13 11:56, Debarshi Ray wrote:


[cut]


Makes sense.
The hard part is knowing what's a photo and what's a screenshot?
By filename? By location? By metadata in the file itself?


[cut]

Then where do you add this? In the extractors (we have a bunch of 
them), the miner-fs itself probably doesn't a lot of sense because it 
deals with file-only data and passes on the metadata specifics - which 
this is.




Or do you think there are better ways to do this? What do you think?


I've added some ideas to the bug report.


IMO the screenshot application should add the metadata information, 
similarly to how MTP daemons write metadata about a file themselves (by 
not writing it to the graph of the FS miner, but to their own graph, the 
FS miner won't overwrite it).


I think the screenshot application is the only actor who reliably knows 
that the newly created file is a screenshot. It can write the metadata 
(setting nie:url correct too) and the FS miner will or should behave 
correct.


INSERT OR REPLACE ( _:f a nie:InformationElement ; nmm:category 
'Screenshots' }


On top of that we could add 'gnome-screenshot' detection for 
tEXt::Software to the different image file extractors. Note that not all 
of them (actually, none, afaik) use GdkPixbuf for metadata extraction.


Note that I don't like nmm:category the way it is now (a xsd:string), it 
should probably be a nie:InformationElement, like this:


INSERT OR REPLACE { _:c a nmm:Category ; nie:title 'Screenshots' . _:f a 
nie:InformationElement ; nmm:category _:c }


Also note that nmm:Category is in domain nmm:Video, so it can't be used 
for photos.


I guess a new kind could be made by subclassing nie:isPartOf or 
nfo:DataContainer, for this. Or just use nfo:Folder (no need for a real 
directory to exist to have a nfo:Folder imo)?


Kind regards,

Philip

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Automatically creating an album for screenshots

[Philip Van Hoof]

*Review request*

Bug comment:

https://bugzilla.gnome.org/show_bug.cgi?id=709368#c4

Commit to review:

https://git.gnome.org/browse/tracker/commit/?h=gnome-screenshot&id=2e0f0f6e9fe3c2284974f915258072b1575e3779

Example usage:

pvanhoof@sput-debian:~/repos/gnome/tracker$ gnome-screenshot -f 
/home/pvanhoof/screenshot.png
** Message: Unable to use GNOME Shell's builtin screenshot interface, 
resorting to fallback X11.
pvanhoof@sput-debian:~/repos/gnome/tracker$ tracker-control -f 
/home/pvanhoof/screenshot.png

(Re)indexing file was successful
pvanhoof@sput-debian:~/repos/gnome/tracker$ tracker-sparql -q "SELECT ?u 
{ ?f nie:isPartOf nfo:image-category-screenshot; nie:url ?u }"

Results:
  file:///home/pvanhoof/screenshot.png
file:///home/pvanhoof/Pictures/Screenshot%20from%202013-10-08%2010:05:25.png

pvanhoof@sput-debian:~/repos/gnome/tracker$

ps. A review from Debarshi on the example usage is also welcome.

Kind regards,

Philip

Debarshi Ray schreef op 7/10/2013 14:57:

Hey Martyn,

On Mon, Oct 07, 2013 at 12:28:32PM +0100, Martyn Russell wrote:

Currently albums or collections are implemented using nfo:DataContainer, and
screenshots are identified by checking the tEXt::Software option for
'gnome-screenshot'.

I don't follow regarding the "tEXt::Software option" bit?

See this:
https://git.gnome.org/browse/gnome-control-center/tree/panels/background/bg-pictures-source.c#n167


I am wondering if the filesystem miner could look at tEXt::Software and
create a nfo:DataContainer for all photos that have it. Ofcourse it could
be under a optional --enable-gnome flag because this might be specific to
GNOME.

Makes sense.
The hard part is knowing what's a photo and what's a screenshot?
By filename? By location? By metadata in the file itself?

The "tEXt::Software option" is embedded into the file if you took your
screenshot using gnome-shell or gnome-screenshot.

Cheers,
Debarshi



___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list


___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] The extract-sparql branch and point 15 in Martyn's review

[Philip Van Hoof]

Team,

Although it's my own fault for not having finished the work[0] after 
Martyn's excellent review[1] ...


In point 15 Martyn correctly points out that parent URNs for files 
aren't addressed in the extract-sparql branch. This means that whenever 
you want to add metadata for a (future) file by using 
tracker_extract_get_sparql to get the metadata from our extractors, you 
don't get the directory tree's metadata alongside with it.


ie. Asking for the metadata for 
/home/user/Documents/Directory/Kind/File.png will give you metadata for 
File.png, although File.png might not exist yet as you're building it as 
/tmp/.tmp.File.png, but not for /, /home, /home/user, 
/home/user/Documents, /home/user/Documents/Directory and 
/home/user/Documents/Directory/Kind. And this although your  plan is to 
rename() /tmp/.tmp.File.png to 
/home/user/Documents/Directory/Kind/File.png meaning that for the query 
you get back to succeed, you'll need it all (including the metadata for 
the destination's tree).


So although this is my own fault (for not having finished it by now), I 
recognize today (almost a year later) that I'm not following up on this 
enough. I'm hoping that since apparently I can't find the time for this 
(I've been renovating a house, having a girlfriend (doing stuff grown up 
people apparently 'need' to do), having a daytime job and not being paid 
to do Tracker work anymore, etc, being guilty of being lazy and watching 
dumb television instead of coding - I agree -), the other members of the 
team would be willing to progressively refactor the FS miner in such a 
way that getting this tree of metadata out of the FS miner can be done 
by a library like libtracker-extract. By that I mean blocking the FS 
miner from doing it, while getting the information and building the 
correct SPARQL queries.


I'm wondering about the ideas of the other Tracker team members on this. 
I think it's important to allow applications to bypass the FS miner. Not 
because I think the FS miner isn't great (I think it is, I think 
Lanedo's developers did an awesome job). But because I think our 
metadata system should be flexible to allow such metadata input. And 
because it avoids race conditions and metadata entry timing issues 
(allowing metadata upfront the rename() call, allows us to atomically do 
things fully correct with the tracker:available property of 
informationelements).


We're so close. We should just do it and get it over with.

Kind regards,

Philip


[0] https://mail.gnome.org/archives/tracker-list/2012-December/msg00021.html
[0] https://git.gnome.org/browse/tracker/log/?h=extract-sparql
[1] https://mail.gnome.org/archives/tracker-list/2013-January/msg1.html




___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] tracker-miner-fs stuck Initializing

[Philip Van Hoof]

Martyn Russell schreef op 29/10/2013 14:09:

Hi Martyn, Carlos and Brian,

Inline reply




Could you terminate it and run your own
with /usr/lib/tracker/tracker-miner-fs -v 3? That should give some more
information about what's going on there.


Seems to have stopped with:

(tracker-miner-fs:14538): Tracker-CRITICAL **: Could not initialize
currently active mount points:
GDBus.Error:org.freedesktop.Tracker1.SparqlError.Internal: column
nie:url is not unique (strerror of errno (not necessarily related): No
such file or directory)
(tracker-miner-fs:14538): Tracker-CRITICAL **: Could not set mount point
in database 'urn:nepomuk:datasource:448659eed398985de3972d3a72c8ac8d',
GDBus.Error:org.freedesktop.Tracker1.SparqlError.Internal: column
nie:url is not unique (strerror of errno (not necessarily related): No
such file or directory)


As a last choice I'd recommend to dump previous info and retrigger
indexing with tracker-control -rs, but would be interesting to know
what's going on there.


Yeah, I have kept that in reserve.  If it has to be done, I guess I will
but I'd like to avoid it if i can, as I am sure you'd imagine.


Thank you for reporting this here. I think this issue is related to 
mounted GVFS locations.


I've noticed something strange happening with mount points and 
starting tracker. Unmounting them seemed to fix this "blockage" you 
talk of.


I've not had time to look into it myself but the errors you report 
above give us much more insight as to what's causing this.




The error coming from SPARQL INSERT indicates that nie:url for subject 
 already 
exists. The nie:url is a|||nrl:InverseFunctionalProperty so it must be 
unique 
(https://git.gnome.org/browse/tracker/tree/data/ontologies/30-nie.ontology#n42) 
in the database.


To know this nie:url, Brian could do this:

tracker-sparql -q "select ?url { 
|| nie:url ?url }"


I'm guessing that Tracker's volume management is trying to insert a 
volume for a nie:url that already exists for another resource (that is 
or isn't a volume, mountpoint or directory).


I think somewhere here at set_up_mount_point_type:

https://git.gnome.org/browse/tracker/tree/src/miners/fs/tracker-miner-files.c#n720

It's just an idea and some guessing from the reported criticals vs. 
context described by Brain, though.


|
I thought there was a bug reported about this, but I couldn't find 
it/one.


It's quite severe though and should be fixed!


Indeed

Kind regards,

Philip

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] GLib-CRITIAL warnings about g_timer_continue

[Philip Van Hoof]

Hi guys,

Logs from a systemd booted system on Tracker 0.14:

Nov 22 16:41:47 localhost dbus-daemon[901]: (tracker-miner-fs:948): 
GLib-CRITICAL **: g_timer_continue: assertion `timer->active == FALSE' 
failed
Nov 22 16:41:47 localhost tracker-miner-fs[948]: GLIB CRITICAL ** GLib - 
g_timer_continue: assertion `timer->active == FALSE' failed


Occurences in tracker-miner-fs's code:

libtracker-miner/tracker-crawler.c:
  g_timer_continue (crawler->priv->timer);

libtracker-miner/tracker-miner-fs.c:
} else if (fs->priv->extraction_timer_stopped) {
g_timer_continue (fs->priv->extraction_timer);
fs->priv->extraction_timer_stopped = FALSE;
}

Can we in the situation that happened simply activate the timer instead 
of using continue?


Kind regards,

Philip

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] sqlite-3.8.1 is broken

[Philip Van Hoof]

Hi,

Perhaps we should add a check in configure.ac disallowing the specific 
SQLite versions that are known to be broken?


That way we're sure that package builders for all platforms will care 
about not using the version.


Kind regards,

Philip

Debarshi Ray schreef op 26/11/2013 12:49:

Since we are so close to releasing Fedora 20, I filed a downstream
report against sqlite:
https://bugzilla.redhat.com/show_bug.cgi?id=1034714

I took a shot at narrowing it down to a sqlite commit, but given that
they do not use Git, and I am not an expert with the SPARQL-SQL layer,
and I could not locate an obvious one-liner to clone the Fossil
repository, I gave up.

Cheers,
Debarshi



___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list


___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] FOSDEM submission proposal

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi guys,

I have not seen anybody else proposing to do a talk on Tracker this
year at FOSDEM, so I made one:
https://penta.fosdem.org/submission/FOSDEM14/event/2324

ps. If somebody else wants to do this; I'm not really a good public
speaker so be my guest.

Philip
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSwpskAAoJEEP2NSGEz4aDyT4IAJaP+i/P+X4861Vcx7Qv+S0P
qM4dGc5XpNTjbuAd7/77vA+w/DImhT7rR1JMmgDam/EgjuoJ3efB9xvfIxBFvNpe
62h3mK66nI58BvHIZ/0SPSi8NTPbfaMriH13tDnaf6WOx1eZW15uffeWx/pBzZIs
9WCVZG9Ux1giuOGkpSwlw5QreIsAmZPlzzqiKd3x/SYaeMHcWX5TEQVCDGQCkARl
yc+8BZ1hwfd3GPxwXgbQjw4M6JtyFRkJ0+iC/yNsyqyRyVWDdvDkY1gDNklWo5eU
cOrfwoH+Tf++hP0gge7QKQvsnZKJZMhJMKyw13TiAowrWHZO+AsmAM3BtJmJx+g=
=euIY
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] FOSDEM submission proposal

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Apparently the submission proposals aren't public. I'll copy-paste it
here:


Submission:
Being one of the core developers of the Metadata Tracker software I'd
like to do a presentation about the current state of the project and
technologies where the software is being used (Jolla Phone, N9, GNOME
and infotainment systems in cars).

Abstract:
A presentation about the current state of the project and technologies
where the software is being used (Jolla Phone, N9, GNOME and
infotainment systems in cars). Encountered pitfalls and lessons learned.


Full description:
Metadata Tracker is now being used not only on the N900 and N9, but is
and will be used on the Jolla Phone. On top a software developer for
several car brands, Pelagicore, claims to be using it with custom made
ontologies. Other hardware companies have approached the team about
integrating the software with their products. In this presentation I'd
like to highlight the difficulties those companies encountered and how
the project deals with them, dependencies to get a minimal system up
and running cleanly and I'd like to propose some future ideas.


Links:

Pelagicore's Tracker-IVI branch:
https://github.com/Pelagicore/tracker-ivi/

Jolla's Tracker branch: https://github.com/nemomobile-packages/tracker

Upstream Tracker's master and branches:
https://git.gnome.org/browse/tracker/

N9 - Harmattan 1.3's Tracker:
https://gitorious.org/tracker/tracker/commits/59b5389488d25ec056d4370a17b9fbcabc016f4b

N900 - Fremantle's Tracker:
https://gitorious.org/tracker/tracker/commits/33bd46301a05e79ddd181877a6a87f6b36e06e4a



Philip Van Hoof schreef op 31/12/2013 11:23:
> Hi guys,
> 
> I have not seen anybody else proposing to do a talk on Tracker
> this year at FOSDEM, so I made one: 
> https://penta.fosdem.org/submission/FOSDEM14/event/2324
> 
> ps. If somebody else wants to do this; I'm not really a good
> public speaker so be my guest.
> 
> Philip ___ tracker-list
> mailing list tracker-list@gnome.org 
> https://mail.gnome.org/mailman/listinfo/tracker-list
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSwp6FAAoJEEP2NSGEz4aD2kEH/38WQF68bZ+CAvgcmWYzNGaW
gvNqF7HTht8lxeENLniMLGZsOUjjCdJARZ+0zfuSoxprfL47GI/G1xIyib7R/XTx
0LzkaXIW92h9PRaf2gos2s02mmw0QDRIv4Z+chLAeY0mfWsft/sD/DyAZpyRjfb+
0PLzMBoqTLAAs08QUV5pGUhn0aGLwZCQeKDEjFDh/liwR6hh0l0KsuLxdAp5Zecm
R2xJrFngXCl4WKIS1I07REoGuRHGOHqIkAhEoj5DWzgN6IRRzZJcGHb0zS8KL2oA
i+II41y9peAl+emnHXguLlsn/0V7bV+zLk8pSnef9em6omEuAcEN/DPpPimg8S0=
=AT1r
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] FOSDEM submission proposal

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Ralph,

I'm not yet sure whether the proposal for a presentation will be
approved. Once approved I think it'll be placed on a timeslot. I'll
try to remember posting it here.

Kind regards and thanks for your interest.

Philip


Ralph Böhme schreef op 2/01/2014 9:42:
> Hi
> 
> Am 31.12.2013 um 11:23 schrieb Philip Van Hoof
> :
> 
>> Signierter PGP Teil Hi guys,
>> 
>> I have not seen anybody else proposing to do a talk on Tracker
>> this year at FOSDEM, so I made one: 
>> https://penta.fosdem.org/submission/FOSDEM14/event/2324
> 
> once you know date and time, could you please follow up and post
> em? I'd like to make sure not to miss it, as I might be coming to
> FOSDEM.
> 
> Happy New Year! -Ralph
> 
> 
> 
> ___ tracker-list
> mailing list tracker-list@gnome.org 
> https://mail.gnome.org/mailman/listinfo/tracker-list
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSxSg4AAoJEEP2NSGEz4aDKu8H/2gas00Y4zF7E14x0EzXi/ce
6GFRiCv9pyAk0w2JpGcnyDLKhQbM33VDzTEhOIhFItpahDotMNg4nzLcyo1HMQ56
apQbPN5S/62lWi59qFSYaygv8ZooRlXQ8bcOjKcv/BguajeT4rjBQIhDdy/MGlSp
xRDF1TiP8Mrporxd2FvW1YxPBkbC7glBLKcxMIgu9vto7BTRFAKKYBO0NFxS0n/7
FIq1qnw3ovBq6tX8GTWIbOlJxRYLxTzycNcZ1IazRDpGza193mV+V/zx8/6HN716
QnJJZQoL9DHHuUFtDgEzpzlO9mZlRsb0s1vfHGz+/hq0HarSejH/pSqrxbs4iTo=
=vE5n
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Running Tracker with dbus system bus

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ralph Böhme schreef op 2/01/2014 9:49:
> Hi
> 
> fishing for responses, so here it goes again... :)
> 
> Am 16.12.2013 um 18:36 schrieb Ralph Böhme :
>> I'm looking into integrating Apple Spotlight support for Mac OS X
>> clients to Samba.
>> 
>> In order to simplify the design I had chosen for Netatalk (launch
>> my own dbus daemon in _root_ user context, seteuid(0) in user
>> context AFP fileserver processes before every libtracker-sparql
>> function call) I wanted the check back with you guys whether a
>> patch for Tracker that would a (run-time) option to run Tracker
>> in the system dbus context would be acceptable for you.
>> 
>> I haven't looked at the relevant code yet, but I suppose this may
>> actually be only a few lines of new code for the option and a few
>> changes where we open the dbus bus via dbus-glib (afair) API.

Via Vala's D-Bus support we use GLib's GDBus (on both sides). For read
queries depending on access level to meta.db we use SQLite WAL journal
for a direct connection with the meta.db.

Relevant files:

https://git.gnome.org/browse/tracker/tree/src/libtracker-sparql-backend/tracker-backend.vala
https://git.gnome.org/browse/tracker/tree/src/libtracker-sparql


https://git.gnome.org/browse/tracker/tree/src/libtracker-bus/tracker-bus-fd-cursor.vala

https://git.gnome.org/browse/tracker/tree/src/libtracker-bus/tracker-bus.vala

https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-dbus.vala

https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-steroids.vala

https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala

> 
> I was just trying to ask, supposed I submit proper patches that
> would allow changing the default behaviour as described, would
> these patches be acceptible? There's no sense in maintaining this
> stuff downstream, because of the need to enable any downstream
> consumer who wants to marry Samba with Tracker (distros, OEMs) to
> do so using the default packages.

I think your seteuid() to drop to the user-ID from root should be
called from your code rather than in libtracker-sparql.

Is there a reason why libtracker-sparql must be adapted?


Happy New Year


Philip

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSxS92AAoJEEP2NSGEz4aDVqoIALefwVKqSnBERIaIXzv8d6bL
QVTweYhw4kWbsb26wkBfB975rYo56plfv+ys51vW1UTWCyvp2vhDEuBOgarGSOvT
BFa74Kh9bDPJlUcq6j7NVTzrj2M8hGg6GM9EP2USwQw9nOhVvwKYJOz/gCx6ozG/
r+HoNQnMJHFAsh+49hH1aES+cN0UzU6FDP662+O1K030yNUYZhOPWfxIDnXTMUtX
Wjv5trnkJd4BqgTpDxgHzB/EPokF+ApiyQPddfrqpsRUJ3epPJoNaIOC/PybO1gX
8GrmR5vRmnt7Zpo8fnLPjTz84zp8sWuehDn00x5+g+DrfefWyQn2sY1crguPxEM=
=5E4R
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Running Tracker with dbus system bus

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ralph Böhme schreef op 2/01/2014 10:36:

Hi Ralph,

>> I think your seteuid() to drop to the user-ID from root should
>> be called from your code rather than in libtracker-sparql.
> 
> I think you misunderstood what I was trying to describe. I
> seteiud() to root in the application before calling tracker-sparql
> stuff, because I'm launching a private dbus in the root user
> context which is then starting Tracker daemons in root user
> context.

Aha yes I misunderstood that. I thought you were running Tracker as a
user and wanted to query it from root.


> 
>
>  The application process normally runs uid=0,euid=some-uid. In
> order to be able to talk to Tracker via dbus, which are both
> running in root user context, I seteuid(0) and back when using
> tracker-sparql stuff.
> 
> I must run Tracker as root, because I must be able to index a
> _shared_ ressource, ie all files of a fileserver (currently
> AFP/Netatalk, in the future SMB/Samba).

Ok, makes sense.

However, and especially given recent revelations in the news of
governments being interested in hacking into our devices (however
crazy that in itself is); tracker-extract links with a huge amount of
externally maintained code and given that this code operates with user
defined input (the files on a filesystem); I would advise very
strongly against running tracker-extract as root. Even our own code
isn't coded with high security standards in mind, although we always
and still do tag such bugs with highest critical priority.

I think it's comparable to the sore situation of extensions and GLX in
X.Org. I also think we'd need the focus of a community of a few
hundred people to make all that code secure. It is that serious and
I'd like to make sure that everybody who runs tracker-extract as root
is aware of this and wakes up in the middle of the night soaked in
cold sweat, every night, for at least half a year for each user that
he burdened with that risk.

What I would propose is to investigate the use of Linux lightweight
containers to let the tracker-extract process run in, or using
set(e)uid to drop privileges of tracker-extract as soon as possible
(for example after getting the open fd, drop privleges, and continue
with read. But I'm not even sure whether that will work - so
experimenting and investigating on this should probably be done).

For example no extractors need write access to files, so the container
and/or user to drop privileges to wouldn't need it, the mp3 extractor
needs mmap, God knows what the GStreamer based ones need, etc.

I don't think running tracker-miner-fs' process as root is as much of
a risk (as tracker-extract), although a security audit would need to
be done. Same for tracker-store.

> Trackers is apperently designed for a single user context, not for
> use a general purpose indexer on a server that shares ressources
> with clients by means of filehsharing protocols like SMB, AFP or
> NFS.
> 
>> Is there a reason why libtracker-sparql must be adapted?
> 
> The whole Tracker design must be updated to optionally allow
> running Tracker in dbus system context, not in user context.

Yes I agree with this for your use-case.

I think it should be at least a option, a commandline switch or
perhaps even a compile time option. I wouldn't be against it (noting
to your users the warning about tracker-extract that I just gave -
which I do think you ought to take very serious).

Philip

> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSxTp5AAoJEEP2NSGEz4aDEwYH/jPSgeWnu76Wwew6qb610WVi
yVwb/hS/EQ7C9lt/3JcqeKEpAInayAiBDxGVqYSZ7KTHl1wwRGDgaa3KR1Z8OKXL
Mgv4e360ieFmy9ldyw37PWrVWJmwtdyDlzTjy7XIdXIYbjAfRICAs3h7tDJc7X1x
UhexiaVuG8ZBLVr2mIKq3Mj0Xyf7us6FnncMA/p3KsoW9V/+hz6Rm3mGnJYHLrzV
i5nNvGNNnr7mlbdlnF9FxlpyeqLfQxWBVUqkpcB9AxcTcj7sJXjY2jw8R70Y7iBy
3aGzaHIFU3TU29AslTQl9CZ7+pHTqASx4Op9O+rwyPMmlE1o7vXbCnoSpGRj7jc=
=HHvu
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Running Tracker with dbus system bus

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ralph Böhme schreef op 2/01/2014 11:36:

Hi Ralph,

[cut]

>>> I must run Tracker as root, because I must be able to index a 
>>> _shared_ ressource, ie all files of a fileserver (currently 
>>> AFP/Netatalk, in the future SMB/Samba).

>> Ok, makes sense.
>> 
>> [cut - security warning about running tracker-extract as root]
> 
> Point taken.

Good :)


>> [cut - technical proposals to improve the situation and other
>> cuts]


>>> The whole Tracker design must be updated to optionally allow 
>>> running Tracker in dbus system context, not in user context.
>> 
>> Yes I agree with this for your use-case.
>> 
>> I think it should be at least a option, a commandline switch or 
>> perhaps even a compile time option. I wouldn't be against it
>> (noting to your users the warning about tracker-extract that I
>> just gave - which I do think you ought to take very serious).
> 
> fwiw, the requirements for the described use case don't
> neccessarily require running Tracker as root. What's need is using
> dbus system context, not session context, so that arbitrary users
> (processes with distinct uids) can connect. The latter is not
> allowed by dbus for user context services (ie you can't connect as
> arbitrary user to a dbus session service from another user (another
> euid that is)).

nod. Correct afaik.

> A proper solution (with security in mind) might be * add an option
> that makes Tracker use system dbus context instead of session
> context * add another option to take a user under which Tracker
> will run in this case, this user MUST not be root

Patches that implement this would be welcomed. At least from my side.
Note that other Tracker maintainers might also have a point of view.

Some locations in the code:

For tracker-store:

https://git.gnome.org/browse/tracker/tree/src/libtracker-bus/tracker-bus.vala#n24

https://git.gnome.org/browse/tracker/tree/src/libtracker-sparql-backend/tracker-backend.vala#n37

https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-dbus.vala#n95


This one  is used by tracker-extract:

https://git.gnome.org/browse/tracker/tree/src/libtracker-common/tracker-dbus.c#n70

The D-Bus service for all miners:

https://git.gnome.org/browse/tracker/tree/src/libtracker-miner/tracker-miner-manager.c#n409

Unfortunate manual D-Bus connection to tracker-store from miner-fs:

https://git.gnome.org/browse/tracker/tree/src/miners/fs/tracker-main.c#n772

In case you need tracker-writeback:

https://git.gnome.org/browse/tracker/tree/src/miners/fs/tracker-writeback-listener.c#n193




Philip


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSxUU6AAoJEEP2NSGEz4aDOIsH+wX+zFprX9lmP9hiL2xZSaEq
d4O9udeqGqoMa89gRHF8Jgw55He7kj5IGwoLepXQr50u5uftaNc+y2GkzmPabQoA
HebZBlVII0qYWJ7LOlfA1yj8Gtw5HediUs6gzMa6nnNSIrNP9KkumVr1P6P16YJn
2kLTJ2wnKqnFcGCDj2X92npxvw3QbJTihKgBSLBpR7E2EL7G5AFltoqxhK5rq1jM
QDD9g1svfjI92IKcpEsDcYmyZCH9voMTVYezxp+7vaNQteP7eHpQQC3rnE1FQ+qC
/w21bdEjKwQW4Y6FO0rueLuHXYtWqA4e+AlWdCoe2cki2Zih/GpN9NHhEqAAfwE=
=8z1k
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] Request for review: Make it possible to adjust GraphUpdated delay in the options

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Request for review:

This patch makes it possible to adjust the delay of GraphUpdated
signal. It's needed for devices where a higher precision is needed to
detect changes to the RDF store than one second.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSxV5EAAoJEEP2NSGEz4aDNSoH/3pJMdCE/D3LEzHK6Tfh4v1w
+gudi9b8aYTngzpttbNrTg672DSyGcE3u9S3pMvq6RZdnVLfhqSy6ul5D+RNMFKQ
3FkovNj0FAUyam7nJeTEr3Xh5DaSfJ9DY/QVovdIYCcTDoZpf/cDkcsjF6bpHDKu
FafwCMxizq5jgnblLK3U/vVA4u+q33BxeRNIhjiqiI1PpufmLz6slSe+PxUC7meh
DKS9+FYk3zRUXN57sx01KzAxZSKuhcYQCDFSS/qfQHldzzwU3ysKUT5D82WHet3Z
FK/qNdKQarc1rxdAr74jR4NWRZ7pRgPNiwjQG2P7A18gRI13b+p5W5Xjs8xYmHM=
=PUl5
-END PGP SIGNATURE-
>From 266f4757bbd4e73a38eafd384d268059bf1b7617 Mon Sep 17 00:00:00 2001
From: Philip Van Hoof 
Date: Sat, 23 Nov 2013 10:28:35 +0100
Subject: [PATCH] Make it possible to configure the delay for GraphUpdated

Helps fixing JB# 11570
---
 .../org.freedesktop.Tracker.Store.gschema.xml.in   |  5 +++
 src/tracker-store/tracker-config.c | 40 ++
 src/tracker-store/tracker-config.h |  5 +++
 src/tracker-store/tracker-config.vapi  |  1 +
 src/tracker-store/tracker-dbus.vala|  6 ++--
 src/tracker-store/tracker-main.vala|  3 +-
 src/tracker-store/tracker-resources.vala   |  7 ++--
 7 files changed, 61 insertions(+), 6 deletions(-)

diff --git a/data/gschemas/org.freedesktop.Tracker.Store.gschema.xml.in 
b/data/gschemas/org.freedesktop.Tracker.Store.gschema.xml.in
index bd4ac8d..f7c4565 100644
--- a/data/gschemas/org.freedesktop.Tracker.Store.gschema.xml.in
+++ b/data/gschemas/org.freedesktop.Tracker.Store.gschema.xml.in
@@ -24,5 +24,10 @@ Boston, MA  02110-1301, USA.
   <_summary>Log verbosity
   <_description>Log verbosity.
 
+
+  1000
+  <_summary>GraphUpdated delay
+  <_description>Delay in ms. at which GraphUpdated will happen when 
signalling data is available.
+
   
 
diff --git a/src/tracker-store/tracker-config.c 
b/src/tracker-store/tracker-config.c
index 889c40c..419aecb 100644
--- a/src/tracker-store/tracker-config.c
+++ b/src/tracker-store/tracker-config.c
@@ -45,10 +45,12 @@ static void config_constructed  (GObject   
*object);
 enum {
PROP_0,
PROP_VERBOSITY,
+   PROP_GRAPHUPDATED_DELAY,
 };
 
 static TrackerConfigMigrationEntry migration[] = {
{ G_TYPE_ENUM, "General", "Verbosity", "verbosity", FALSE, FALSE },
+   { G_TYPE_INT, "General", "GraphUpdatedDelay", "graphupdated-delay" },
{ 0 }
 };
 
@@ -72,6 +74,17 @@ tracker_config_class_init (TrackerConfigClass *klass)

TRACKER_TYPE_VERBOSITY,

TRACKER_VERBOSITY_ERRORS,
G_PARAM_READWRITE));
+
+   g_object_class_install_property (object_class,
+PROP_GRAPHUPDATED_DELAY,
+g_param_spec_int  
("graphupdated-delay",
+   "GraphUpdated 
delay",
+   "GraphUpdated delay 
in ms. (1000)",
+   0,
+   G_MAXINT,
+   1000,
+   G_PARAM_READWRITE));
+
 }
 
 static void
@@ -86,6 +99,11 @@ config_set_property (GObject  *object,
  GParamSpec   *pspec)
 {
switch (param_id) {
+   case PROP_GRAPHUPDATED_DELAY:
+   tracker_config_set_graphupdated_delay (TRACKER_CONFIG (object),
+  g_value_get_int (value));
+   break;
+
case PROP_VERBOSITY:
tracker_config_set_verbosity (TRACKER_CONFIG (object),
  g_value_get_enum (value));
@@ -103,6 +121,10 @@ config_get_property (GObject*object,
  GParamSpec *pspec)
 {
switch (param_id) {
+   case PROP_GRAPHUPDATED_DELAY:
+   g_value_set_int (value, tracker_config_get_graphupdated_delay 
(TRACKER_CONFIG (object)));
+   break;
+
/* General */
case PROP_VERBOSITY:
g_value_set_enum (value, tracker_config_get_verbosity 
(TRACKER_CONFIG (object)));
@@ -168,3 +190,21 @@ tracker_config_set_verbosity (TrackerConfig *config,
g_object_notify (G_OBJECT (config), "verbosity&qu

[Tracker] Request for review: support for Qt and support for Wayland compositor-less QGuiApplication initialisation

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Request for review:

The first patch implements support for Qt5's pixmap handling, the
second patch further improves on this by setting the plugin for this
to minimal for the Nemo OS and alters QCoreApplication to be
QGuiApplication in all cases.

Setting of the plugin should be done specific per OS. Unfortunately is
tracker-extract activated over D-Bus, so setting environment variables
that way is rather impractical.

The reason why the minimal plugin should be loaded is that if the
default plugin is used and the Wayland compositor isn't running yet,
then QGuiApplication's constructor will assert, causing
tracker-extract to get aborted. So this is to cover for early-boot
with systemd; not having to depend on Wayland already running (race
condition during early boot - bugfix for it, feature allowing
super-early boots, you name it).


Kind regards,

Philip
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSxWhSAAoJEEP2NSGEz4aD4dQIAKDGZLYwbwT9hZQMgBHFSCGh
C8Eap7Kv//Bpdv+c3cTrAh2PkTwWVQyZWlf16fcUFpvOLuWzBr9Xb7vIaa2xrwAP
c8lEJeQTG2y6pHBkDNGM/SX5ihOE8610c5tdtADjNj92xQ5xNmIQ3MW2i/XiPyoj
Nyj5smq4wpiJ4jW6kWNXhGywQtn+jX66YwF+X5xAtofsYQBu8GC7P5IPVlV0vZG6
UUq8D6FkJ3Y3D8m9SZZkKaiuUGoRDB9DPlDZYlpxnxNqE6QibaFeuLKZ8ob8ungg
nzzq+8G2eMZ/Iptaxh1hcLKRahQpjec6ldfvFjD+gGXV8OrY/leBoiBsAbznhd4=
=HWHe
-END PGP SIGNATURE-
>From 2fa925aff042cb1075a675728cf932ead96043c3 Mon Sep 17 00:00:00 2001
From: Andrew den Exter 
Date: Fri, 16 Aug 2013 06:55:43 +
Subject: [PATCH 1/2] Port to Qt5.

---
 configure.ac | 51 +---
 src/tracker-extract/tracker-media-art-qt.cpp | 16 -
 2 files changed, 53 insertions(+), 14 deletions(-)

diff --git a/configure.ac b/configure.ac
index 090ebd2..57295ca 100644
--- a/configure.ac
+++ b/configure.ac
@@ -170,7 +170,8 @@ LIBNOTIFY_REQUIRED=0.4.3
 HAL_REQUIRED=0.5
 UPOWER_REQUIRED=0.9.0
 GDKPIXBUF_REQUIRED=2.12.0
-QT_REQUIRED=4.7.1
+QT5_REQUIRED=5.0.0
+QT4_REQUIRED=4.7.1
 MEEGOTOUCH_REQUIRED=0.20
 POPPLER_REQUIRED=0.16.0
 CAIRO_REQUIRED=1.0
@@ -1591,29 +1592,53 @@ selected_for_media_art="no  (disabled)"
 ##
 
 if test "x$enable_qt" != "xno" && test "x$enable_gdkpixbuf" != "xyes"; then
-   PKG_CHECK_MODULES(QT,
- [QtGui >= $QT_REQUIRED],
- [have_qt=yes],
- [have_qt=no])
+   PKG_CHECK_MODULES(QT5,
+ [Qt5Gui >= $QT5_REQUIRED],
+ [have_qt5=yes],
+ [have_qt5=no])
 
-   TRACKER_EXTRACT_CFLAGS="$TRACKER_EXTRACT_CFLAGS $QT_CFLAGS"
-   TRACKER_EXTRACT_LIBS="$TRACKER_EXTRACT_LIBS $QT_LIBS"
+   PKG_CHECK_MODULES(QT4,
+ [QtGui >= $QT4_REQUIRED],
+ [have_qt4=yes],
+ [have_qt4=no])
 
-   if test "x$have_qt" = "xyes"; then
+
+   if test "x$have_qt5" = "xyes"; then
+  TRACKER_EXTRACT_CFLAGS="$TRACKER_EXTRACT_CFLAGS $QT5_CFLAGS -fPIC"
+  TRACKER_EXTRACT_LIBS="$TRACKER_EXTRACT_LIBS $QT5_LIBS"
+
+  AC_DEFINE(HAVE_QT5, [], [Define if we have Qt5])
   AC_DEFINE(HAVE_QT, [], [Define if we have Qt])
-  selected_for_media_art="yes (qt)"
+
+  selected_for_media_art="yes (qt5)"
+   else
+  if test "x$have_qt4" = "xyes"; then
+ TRACKER_EXTRACT_CFLAGS="$TRACKER_EXTRACT_CFLAGS $QT4_CFLAGS -fPIC"
+ TRACKER_EXTRACT_LIBS="$TRACKER_EXTRACT_LIBS $QT4_LIBS"
+
+ AC_DEFINE(HAVE_QT4, [], [Define if we have Qt4])
+ AC_DEFINE(HAVE_QT, [], [Define if we have Qt])
+
+ selected_for_media_art="yes (qt4)"
+  fi
fi
 else
-   have_qt="no  (disabled)"
+   have_qt4="no  (disabled)"
+   have_qt5="no  (disabled)"
 fi
 
 if test "x$enable_qt" = "xyes"; then
-   if test "x$have_qt" != "xyes"; then
-  AC_MSG_ERROR([Couldn't find Qt >= $QT_REQUIRED.])
+   if test "x$have_qt5" != "xyes"; then
+  if test "x$have_qt4" != "xyes"; then
+ AC_MSG_ERROR([Couldn't find Qt4 >= $QT4_REQUIRED or Qt5 >= 
$QT5_REQUIRED.])
+  fi
fi
 fi
 
-AM_CONDITIONAL(HAVE_QT, test "x$have_qt" = "xyes")
+AM_CONDITIONAL(HAVE_QT4, test "x$have_qt4" = "xyes")
+AM_CONDITIONAL(HAVE_QT5, test "x$have_qt5" = "xyes")
+AM_CONDITIONAL(HAVE_QT, test "x$have_qt5" = "xyes" || test "x$have_qt4" = 
"xyes")
+
 
 if test "x$enable_gdkpixbuf" != "xno" && test "x$enable_quil

[Tracker] Request for review: Upstreaming Jolla patch to enable album-art processing for ogg files

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Patch was titled: Save folder media art for ogg files.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSxWySAAoJEEP2NSGEz4aDtXQH/i+8u7prN4saGYNQsBsEqoi5
Oi+9BwrZ8je7UTcwLthP0m3yiT/M0tAawpMC1qUQ5P+4C6Gb61AXKsD5Gh70QhQw
7f2WHFlNrG6fR1IiZmrj8Uvk37HdWzmm1BXCkoRwDmExgyA6Hncjez6sfPP73uDN
Lxt+Y8dvrodX7sDuk+KiU3LKcR4tSaevCXy5zN+SzG2XBSDOksOorBzMvGj/RY7B
r3GWkRPAoV8MJgBWMvzsiI7WM9LclPs+E+znVqDiL+JrYjONz49tS8sEhGCkvp9D
SPZ9sCrZj6QtDsHG6IUuq9Xfy673jfGSJyztd/pe/7nM5LHpPJpy+9uPljDLqgE=
=Qejt
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Request for review: Upstreaming Jolla patch to enable album-art processing for ogg files

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

And this time with the patch attached

Philip Van Hoof schreef op 2/01/2014 14:41:
> Patch was titled: Save folder media art for ogg files.
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSxWzAAAoJEEP2NSGEz4aD+REH/jfGzRRorhE/FIie4o3rfQ5c
/49xof0R0ZidYTOEST4j8qsiiTJ2Dtm3p9huNfEgEbvA7rNzDv28iCO71J3t8/Hs
Ka/AJsOSIHdm00MIG6K7+b9a6CPSqMjP7y2wDQSbS8gOEDBaLNSvTvFPv2YlZQvO
chC8m7BCZbub/TUcutvLHhiraRv9GjQNV25Fd4CI6mri5brzUZNxpOPrqwgccVGO
hDEibIbL24FlRup8p68zpNdXBq9So5BzrO7GJshncYUNBXf7aqeGpVB+z0oLTyR0
7kudhaTm3fw9OUZNt1cxCzMvt0I8hcmIHqciq6yClmnmAjvHkRVNIBGMbsmy5AQ=
=Ur0x
-END PGP SIGNATURE-
>From 88e7c1a3da69822998df9634d61a2d5f5b3eec6a Mon Sep 17 00:00:00 2001
From: Andrew den Exter 
Date: Fri, 16 Aug 2013 08:10:12 +
Subject: [PATCH] Save folder media art for ogg files.

---
 src/tracker-extract/tracker-extract-vorbis.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/src/tracker-extract/tracker-extract-vorbis.c 
b/src/tracker-extract/tracker-extract-vorbis.c
index 124be4f..175008e 100644
--- a/src/tracker-extract/tracker-extract-vorbis.c
+++ b/src/tracker-extract/tracker-extract-vorbis.c
@@ -32,6 +32,8 @@
 
 #include 
 
+#include "tracker-media-art.h"
+
 typedef struct {
const gchar *creator;
gchar *creator_uri;
@@ -93,7 +95,7 @@ tracker_extract_get_metadata (TrackerExtractInfo *info)
VorbisData vd = { 0 };
MergeData md = { 0 };
FILE *f;
-   gchar *filename;
+   gchar *filename, *uri;
OggVorbis_File vf;
vorbis_comment *comment;
vorbis_info *vi;
@@ -360,8 +362,7 @@ tracker_extract_get_metadata (TrackerExtractInfo *info)
tracker_sparql_builder_predicate (metadata, 
"nmm:musicAlbumDisc");
tracker_sparql_builder_object_iri (metadata, album_disc_uri);
 
-   g_free (album_disc_uri);
-   g_free (vd.album);
+   g_free (album_disc_uri);
 
tracker_sparql_builder_predicate (metadata, "nmm:musicAlbum");
tracker_sparql_builder_object_iri (metadata, uri);
@@ -510,7 +511,18 @@ tracker_extract_get_metadata (TrackerExtractInfo *info)
tracker_sparql_builder_object_int64 (metadata, (gint64) time);
}
 
+   uri = g_file_get_uri (file);
+   tracker_media_art_process (NULL,
+   0,
+   NULL,
+   TRACKER_MEDIA_ART_ALBUM,
+   vd.album_artist ? vd.album_artist : vd.artist,
+   vd.album,
+   uri);
+   g_free (uri);
+
g_free (vd.artist);
+   g_free (vd.album);
g_free (vd.album_artist);
g_free (vd.performer);
 
-- 
1.8.4.2

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] Request for review: Upstreaming Jolla patches adding a libav based audio and video extractor

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This extractor uses libavformat (apt-get install libavformat-dev) to
extract metadata from certain audio and video formats.

It's written by/for Jolla by Andrew Den Exter (in CC).

I left the patches as is, not squashing them together as we generally
prefer to retain the development-cycle of a feature in our git repository.

Small adaptations were needed to port this to master, in particular
the 90*.rule file and Makefile.am of tracker-extract had to be adapted.

Kind regards,

Philip
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSxXMvAAoJEEP2NSGEz4aD5gQIAJY22u430z4D7kmsAF/lfXqA
97dQbnqDr9kAbOlLcO0CAAxEJO2Gesjfr0V5mJMPUjrI93lt5vC8Ny6PND7ogYNa
llV+W5Y3ZjoE9PcnwxUjFPMmkdSESjNqe7+fyiVpleqPim0C9MTjTkWQp12MkN0R
1Xxfr0fISTZ+kHkBwQ8EuBOqW1XAvWa3kY4CBH0AMQ2egj4dFSYfe/LedtQmyObO
ugm4OYKjA0PP1Va5s8mnylPb0sWPl5MYgzPWyAYVjx11ls3Vy8kaOluaKj0y9Bx+
CdLJ897ElSYnaC3yLnY078EIoK1bopDTaIBVJBbVKCIYOB3odE8NyvpCd9mJU1E=
=+Qvs
-END PGP SIGNATURE-
>From e14fbe8bea83a5131520d8925792b899032fcc47 Mon Sep 17 00:00:00 2001
From: Andrew den Exter 
Date: Tue, 3 Sep 2013 04:23:12 +
Subject: [PATCH 1/4] Add a libav based generic media extractor.

---
 configure.ac|  45 +++-
 src/tracker-extract/Makefile.am |  19 ++
 src/tracker-extract/tracker-extract-libav.c | 369 
 3 files changed, 432 insertions(+), 1 deletion(-)
 create mode 100644 src/tracker-extract/tracker-extract-libav.c

diff --git a/configure.ac b/configure.ac
index 090ebd2..91cb91a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1646,7 +1646,7 @@ AM_CONDITIONAL(HAVE_GDKPIXBUF, test "x$have_gdkpixbuf" = 
"xyes")
 
 AC_ARG_ENABLE(generic-media-extractor,
   AS_HELP_STRING([--enable-generic-media-extractor=ARG],
- [enables one of the (gstreamer, xine, external, 
auto) generic media extractor backends [[default=auto]]]),,
+ [enables one of the (gstreamer, xine, libav, 
external, auto) generic media extractor backends [[default=auto]]]),,
   [enable_generic_media_extractor=auto])
 
 PKG_CHECK_MODULES(GSTREAMER,
@@ -1666,6 +1666,30 @@ PKG_CHECK_MODULES(XINE,
 AC_SUBST(XINE_CFLAGS)
 AC_SUBST(XINE_LIBS)
 
+PKG_CHECK_MODULES(AVFORMAT,
+  [libavformat >= 0.8.4],
+  [have_libavformat=yes],
+  [have_libavformat=no])
+
+AC_SUBST(AVFORMAT_CFLAGS)
+AC_SUBST(AVFORMAT_LIBS)
+
+PKG_CHECK_MODULES(AVCODEC,
+  [libavcodec >= 0.8.4],
+  [have_libavcodec=yes],
+  [have_libavcodec=no])
+
+AC_SUBST(AVCODEC_CFLAGS)
+AC_SUBST(AVCODEC_LIBS)
+
+PKG_CHECK_MODULES(AVCODEC,
+  [libavutil >= 0.8.4],
+  [have_libavutil=yes],
+  [have_libavutil=no])
+
+AC_SUBST(AVUTIL_CFLAGS)
+AC_SUBST(AVUTIL_LIBS)
+
 if test "x$enable_generic_media_extractor" = "xauto"; then
if test "$have_libgstreamer" = "yes"; then
   have_generic_media_handler="yes"
@@ -1673,6 +1697,9 @@ if test "x$enable_generic_media_extractor" = "xauto"; then
elif test "$have_libxine" = "yes"; then
   have_generic_media_handler_app="Xine"
   have_generic_media_handler="yes"
+   elif test "$have_libav" = "yes"; then
+  have_generic_media_handler_app="libav"
+  have_generic_media_handler="yes"
else
   have_generic_media_handler="?"
   have_generic_media_handler_app="An external generic_media player will be 
called"
@@ -1691,6 +1718,13 @@ elif test "x$enable_generic_media_extractor" = "xxine"; 
then
else
   AC_MSG_ERROR([Couldn't find libxine])
fi
+elif test "x$enable_generic_media_extractor" = "xlibav"; then
+   if test "$have_libavformat" = "yes" && test "$have_libavcodec" = "yes" && 
test "$have_libavutil" = "yes"; then
+  have_generic_media_handler_app="libav"
+  have_generic_media_handler="yes"
+   else
+  AC_MSG_ERROR([Couldn't find libav])
+   fi
 else
have_generic_media_handler="?"
have_generic_media_handler_app="An external generic media player will be 
called"
@@ -1700,17 +1734,26 @@ if test "$have_generic_media_handler_app" = 
"GStreamer"; then
AC_DEFINE(HAVE_GSTREAMER, [], [Define if we have GStreamer])
AM_CONDITIONAL(HAVE_GSTREAMER, true)
AM_CONDITIONAL(HAVE_LIBXINE, false)
+   AM_CONDITIONAL(HAVE_LIBAV, false)
AM_CONDITIONAL(USING_EXTERNAL_GENERIC_MEDIA_PLAYER, false)
 elif test "$have_generic_media_handler_app" = "Xine"; then
AC_DEFINE(HAVE_LIBXINE, [], [Define if we have Libxine])
AM_CONDITIONAL(HAVE_LIBXINE, true)
AM_CONDITIONAL(HAVE_GSTREAMER, false)
+   AM_CONDITIONAL(HAVE_LIBAV, false)
AM_CONDITIONAL(USING_EXTERNAL_GENERIC_MEDIA_PLAYER, false)
+elif test "$have_generic_media_handler_app" = "libav"; then
+AC_DEFINE(HAVE_GSTREAMER, [], [Define if we have libav])
+AM_CONDITIONAL(HAVE_LIB

[Tracker] Request for review: Upstreaming Jolla patch that corrects rotation tags

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

By Andrew (CC), for/by Jolla.

Kind regards,

Philip
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSxXZVAAoJEEP2NSGEz4aDlhwH/3ke618ZgDlZqVZ4l3g8C4Gc
VEWvEZSL/xcIf0AEkJJNuh6DbH0bPC/0/5dDJa8qgjYcNnL5N++c2IkiMme3kf8s
J8vWGST5bxFAtlsFxrnoC33dU2vjvY9u142iP4+k/YI0K5VXBAdEIsno7aYiZ+CY
SZIe6LwbAqtnW2uHI7uFgkjgMkpNKmnZgAGu7LgVk986AB5TDEg8uopdQOD2k5kn
sWaMzDTvhJiY/6P5a+VDgKd3Li9KsP2EjyU8kLnS44lvgSC+LJ1ujj1KepPSh4f6
KemT9WDtVylDIy+41cNHfAD8R2ua7q+Bnn1kYzKW//N5xRNtJEhbOZM057NV38E=
=yHCM
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Request for review: Upstreaming Jolla patch that corrects rotation tags

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Arg, and again this time with the patch attached :-)

Philip Van Hoof schreef op 2/01/2014 15:23:
> By Andrew (CC), for/by Jolla.
> 
> Kind regards,
> 
> Philip ___ tracker-list
> mailing list tracker-list@gnome.org 
> https://mail.gnome.org/mailman/listinfo/tracker-list
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSxXbIAAoJEEP2NSGEz4aDo3cH/3kRZ2439XeBL3Dbpa6HQYIu
ovNMguApi7CjkP1ESkP0Xj7pD4SoCninJ23JsDxiPpLxkU9UYB/Kbvmzw04N7W/s
mNDOJHrM6/V8vYDnYmotB0KNFDovqnGSyKN9tXuMqEKhyfmTz5TumOmde1oAJKI8
YaD9A3i7LHPvfyab4EvlznwEnTb8hNuoqvsSUbOrSbOSyKExGrrdebun5TZhhnIQ
Rhce4fGsycCIyNTC6jBLZqoi/mRA6Zcu3xtOPN7IBJWz0s1yYAGSrYAmcukqJubh
QRyXcKfT7toxDQZXQ2+40JPgc/ptO3jjCNhJ09rApnabI0Agw+fIsY90Xw0B7jk=
=dVcj
-END PGP SIGNATURE-
>From cbc1a4e6c453c5b660f55589278ca19314333c38 Mon Sep 17 00:00:00 2001
From: Andrew den Exter 
Date: Mon, 28 Oct 2013 16:01:11 +
Subject: [PATCH] Fix incorrect mirroring of 180 rotation in xmp tags.

---
 src/libtracker-extract/tracker-xmp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/libtracker-extract/tracker-xmp.c 
b/src/libtracker-extract/tracker-xmp.c
index 8729af0..d0c5453 100644
--- a/src/libtracker-extract/tracker-xmp.c
+++ b/src/libtracker-extract/tracker-xmp.c
@@ -301,9 +301,9 @@ fix_orientation (const gchar *orientation)
} else if (orientation && g_ascii_strcasecmp (orientation, "2") == 0) {
return  "nfo:orientation-top-mirror";
} else if (orientation && g_ascii_strcasecmp (orientation, "3") == 0) {
-   return "nfo:orientation-bottom-mirror";
-   } else if (orientation && g_ascii_strcasecmp (orientation, "4") == 0) {
return  "nfo:orientation-bottom";
+   } else if (orientation && g_ascii_strcasecmp (orientation, "4") == 0) {
+   return "nfo:orientation-bottom-mirror";
} else if (orientation && g_ascii_strcasecmp (orientation, "5") == 0) {
return  "nfo:orientation-left-mirror";
} else if (orientation && g_ascii_strcasecmp (orientation, "6") == 0) {
-- 
1.8.4.2

___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Request for review: Upstreaming Jolla patches adding a libav based audio and video extractor

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Blast, looks like I forgot to git add 90-libav-generic.rule or git
format-patch somehow missed it (porting to master included renaming it
from a rule.in file, which I guess explains how I missed it).

Some day, I promise, I'll learn how to get all this stuff right
immediately.

This is what the file will contain and I'll pay special attention when
pushing my local branch (after approval) to include this file.

[ExtractorRule]
ModulePath=@modulesdir@/libextract-libav.so
MimeTypes=audio/*;video/*;


Philip Van Hoof schreef op 2/01/2014 15:09:
> This extractor uses libavformat (apt-get install libavformat-dev)
> to extract metadata from certain audio and video formats.
> 
> It's written by/for Jolla by Andrew Den Exter (in CC).
> 
> I left the patches as is, not squashing them together as we
> generally prefer to retain the development-cycle of a feature in
> our git repository.
> 
> Small adaptations were needed to port this to master, in
> particular the 90*.rule file and Makefile.am of tracker-extract had
> to be adapted.
> 
> Kind regards,
> 
> Philip
> 
> 
> 
> ___ tracker-list
> mailing list tracker-list@gnome.org 
> https://mail.gnome.org/mailman/listinfo/tracker-list
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSxXnUAAoJEEP2NSGEz4aDOWAIAL/vNbeE4LxFzR3k0FoCSD8u
5zh0QibQbvb1UaQVzUAQtErgS1nonsQ9bzEC47E/7kbL39wvpa8t3G7szYZlModb
JwiiFQ4v/RbgELDyr3jCMpblYTP3INHOS6my3jFXGfS8K9cMFZd4NiCNwIj4VKqO
SwpbHG2Ot7GlIOslHGVnzg9icdyZQEheOh0TQhzrzun9jVnc3KlNKbLchZ4o9X/o
cxP4T962ZdicWqqeZBL9g2Ku3ewoCtmsmoNqvgJr7lNJ5BrWcdk6fy+wGlCr+MR4
3Q0+BEA9Oy4d+5SlHQWACvqoupA1zFGBCFM11oQdzDy9XoCry3wW86w739oCAuY=
=i5Jw
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Request for review: Upstreaming Jolla patches adding a libav based audio and video extractor

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Philip Van Hoof schreef op 2/01/2014 15:38:
> 
> This is what the file will contain and I'll pay special attention
> when pushing my local branch (after approval) to include this
> file.
> 
> [ExtractorRule] ModulePath=@modulesdir@/libextract-libav.so

Not true. As usual, when I start making mistakes I continue with it in
good tradition (I copypasted from the original unported rule.in file).

This is that ModulePath:

 ModulePath=libextract-libav.so

> MimeTypes=audio/*;video/*;


Some day, I promise ..., I'll learn how to get all this stuff right
immediately.


> 
> Philip Van Hoof schreef op 2/01/2014 15:09:
>> This extractor uses libavformat (apt-get install
>> libavformat-dev) to extract metadata from certain audio and video
>> formats.
> 
>> It's written by/for Jolla by Andrew Den Exter (in CC).
> 
>> I left the patches as is, not squashing them together as we 
>> generally prefer to retain the development-cycle of a feature in 
>> our git repository.
> 
>> Small adaptations were needed to port this to master, in 
>> particular the 90*.rule file and Makefile.am of tracker-extract
>> had to be adapted.
> 
>> Kind regards,
> 
>> Philip
> 
> 
> 
>> ___ tracker-list 
>> mailing list tracker-list@gnome.org 
>> https://mail.gnome.org/mailman/listinfo/tracker-list
> 
> 
> ___ tracker-list
> mailing list tracker-list@gnome.org 
> https://mail.gnome.org/mailman/listinfo/tracker-list
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSxXp/AAoJEEP2NSGEz4aDdBkIAJhHAji4gFEg6KpdxMw/LAe5
K3ejCaUTT534pYUq7ygiMbIJpAR68xBdtYFAVafh8bm80ORxkuCmeiTtWQmgww4l
szDfHYgBN9a7wAkggKtPJ77zBBsfqkGACNnXU5WY7RZuWbmSMni0pkjbePA1FQ8z
+KxRW/ATFRw/84R9oV6AY/v0twaBme7p7+dbIQOC1wsFuTKMbMT8kyWhNQJPUIJ3
+PHJ0T8d/FOyWCs2OTvABLSmfPeNNOfgoyzBWcpkj9R/YpqJTifts1dn3X1UvNV/
2QRKyxtU3K2G5FBMC6GViBXruTNPHD6Kmac4/CDqA7YsUDLkenyn5htWby7wbJ0=
=04Vr
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] FOSDEM submission proposal

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Guys,

The presentation proposal is accepted. It's on the embedded track
which was my preference; I think our project is more about storage of
metadata on desktop, embedded and mobile than it is about Graph
processing (which is also a track this year).

I plan to focus the presentation not on SPARQL and RDF, although it'll
be mentioned, but on difficulties encountered when employing the
software for appliances, some future ideas, our strenghts, etc.

https://fosdem.org/2014/schedule/track/embedded/
https://fosdem.org/2014/schedule/event/metadata_tracker/

If there are specific things you think I should mention during the
presentation, please let me know.

Philip


Philip Van Hoof schreef op 31/12/2013 11:23:
> Hi guys,
> 
> I have not seen anybody else proposing to do a talk on Tracker
> this year at FOSDEM, so I made one: 
> https://penta.fosdem.org/submission/FOSDEM14/event/2324
> 
> ps. If somebody else wants to do this; I'm not really a good
> public speaker so be my guest.
> 
> Philip ___ tracker-list
> mailing list tracker-list@gnome.org 
> https://mail.gnome.org/mailman/listinfo/tracker-list
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSzmPlAAoJEEP2NSGEz4aDlEAH/1kIFRby9rVMBQ8UaoxhwqLC
YQcSJJTr/573oLeg2cfAZq83Hu2VDIGkjxjBSVCiFkOfzXhByXlIvFpD1tfn6K+i
tBQ0qEP2EH4HoQemQRNf2Qvt9s/L65stLJWj6tf261pRbNS5isfl2SKGjYBmJbLI
aQ5OlTKpFVnWAXpE6XRHX01tdf4p4MudyYvy5f3CYn6wIthcKDDSyFgYbcVGBZrL
tmrll5ux1uzeEYQCtCMSbFEpauWfQ1Baqo9CAG1mUAoEkcqpTO0BRhPzW2PN37Vi
L0tazuxoCXVV9m5vO02XDhPYgWz9q4DFpcm6KH88rhfD90a4oKPns3i7UAR9prg=
=WuUx
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] wip/passive-extraction (and API cleanup?)

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Carlos Garnacho schreef op 9/01/2014 13:48:

Hey Carlos,

> I've talking about this branch on #tracker, but now that most work
> is done there it is worth raising to the ML. In that branch there
> are two extra objects in libtracker-miner:
> 
> * TrackerDecorator is a TrackerMiner that implements a passive 
> indexing pattern, instead of being expected to feed data directly
> to tracker-store, it listens for GraphUpdated signals, so when an
> item eligible for indexing is added/updated and is still missing a
> nie:dataSource specific to the decorator, it is queued for
> processing. On startup it also queries for all elements of the
> eligible rdf:types that are missing that nie:dataSource, so all
> elements are ensured to be indexed. * TrackerDecoratorFS is a
> file-specific implementation of that object, which basically adds
> volume monitoring, so indexing within just added volumes is resumed
> if interrupted previously, or having the elements removed from the
> queue if the volume is removed.

Liking these ideas!

> In that branch, tracker-extract does use these features, it is
> been turned into a full-blown standalone miner using
> TrackerDecorator, while miner-fs stopped calling it. On one hand,
> this leads to a greatly simplified indexing in tracker-miner-fs, as
> the task is a lot less prone to failure now. On the other hand,
> this brings in the 2-pass indexing that was being requested,
> miner-fs promptly crawls and fetches GFile info, and
> tracker-extract goes soon after filling in extra information.


Nice.

> Current caveats ===
> 
> It is worth noting though that in the branch not much has been done
> yet about handling extraction failures: * extractor modules
> blocking or taking too much time * crashes in extractor modules
> 
> Possible solutions go through adding cancellability of extract
> tasks and/or having all extraction go into a subprocess that we can
> watch on, so the dbus service itself doesn't go away and doesn't
> need to be restarted. The latter could also help with Phillip's
> idea to run extraction in containers. But about these changes...

Ok.

> Future plans? =
> 
> I'm very seriously proposing to make libtracker-extract private 
> altogether, the usefulness of having 3rd party extractors is
> dubious, as neither allowing them to reimplement extraction for a
> famous mimetype nor implementing support for a mimetype we don't
> know well enough is positive, it potentially affects tracker
> stability and user perception, and helps avoid the point that if a
> mimetype has enough traction, it should be in the tracker tree. Its
> API is also a mishmash of utility functions that have little to do
> with the rest of Tracker, and written in not a quite future-safe
> way.

*nod*

> Moreover, goggling for "tracker_extract_get_metadata" (the function
> that modules must implement), I just see 3 pages of references to
> Tracker code, backtraces, and logs, very little references to
> external extractors. This API is 1/3 of the Tracker public API, yet
> it's been mostly unused externally for the 3 years it's been on.

I agree that libtracker-extract in its current shape shouldn't be
public, although it should be available for implementers of
tracker-extract modules (which don't imo need to be possible as
plugins: with the libav support by Jolla we also see that integrators
prefer to develop such support in the Tracker project rather than out
of tree or as a plugin anyway - plus I don't like the idea of
integrators adding code to our processes, given that modern IPC
systems are really good).

I think that 'external' users of metadata extraction should all be
tunneled to use tracker-extract's over IPC. A 'external' use-case that
I have in mind here, is a MTP daemon seeking to collect additional
metadata through extraction of a temporary file, inserting it itself
upfront doing the rename() to the final file (which I think is a valid
use-case to be an external user, unless TrackerDecorator addresses
this use-case too -- implement the MTP daemon as a TrackerDecorator?).

So a public libtracker-extract API for 'external' users would be one
that ends up calling tracker-extract.

Especially if ever we decide to lock tracker-extract up in a container
(for example using systemd-nspawn, for security and other reasons).


> So, I think Tracker should offer API to help integrate with
> Tracker, as such this API falls over, I propose to keep it in
> private land, and encourage the use of TrackerDecorator, which is
> also nice in the way that multiple sources add up information,
> unlike extract modules which are individually responsible of
> filling in every piece of information.

*nod*, this sounds good.

> Actually, I'd like to think we can make 1.0 soon

Would this 1.0 include the TrackerDecorator stuff? Because I think any
such redesign needs a testing phase before we call it stable.

> (we technically could ASAP, we've remain

Re: [Tracker] FOSDEM submission proposal

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ralph Böhme schreef op 9/01/2014 18:13:

Hi Ralph,

> Great! I may be attending. Fwiw, if things work out as expected,
> Tracker will pave its way into large enterprise environments,
> functioning as search engine backend for Samba. :)


That's very cool to know! We're always very proud whenever we learn
that somebody is using our software for interesting purposes and
appliances.

I can mention this on the presentation if you and/or NetAFP want that.
If it's not sure yet then I can of course not to mention it. Let me know.

Good luck with the integration of the project into your technology!

Kind regards,

Philip



> -Ralph
> 
> Am 09.01.2014 um 09:55 schrieb Philip Van Hoof
> :
> 
>> Signierter PGP Teil Hi Guys,
>> 
>> The presentation proposal is accepted. It's on the embedded
>> track which was my preference; I think our project is more about
>> storage of metadata on desktop, embedded and mobile than it is
>> about Graph processing (which is also a track this year).
>> 
>> I plan to focus the presentation not on SPARQL and RDF, although
>> it'll be mentioned, but on difficulties encountered when
>> employing the software for appliances, some future ideas, our
>> strenghts, etc.
>> 
>> https://fosdem.org/2014/schedule/track/embedded/ 
>> https://fosdem.org/2014/schedule/event/metadata_tracker/
>> 
>> If there are specific things you think I should mention during
>> the presentation, please let me know.
>> 
>> Philip
>> 
>> 
>> Philip Van Hoof schreef op 31/12/2013 11:23:
>>> Hi guys,
>>> 
>>> I have not seen anybody else proposing to do a talk on Tracker 
>>> this year at FOSDEM, so I made one: 
>>> https://penta.fosdem.org/submission/FOSDEM14/event/2324
>>> 
>>> ps. If somebody else wants to do this; I'm not really a good 
>>> public speaker so be my guest.
>>> 
>>> Philip ___
>>> tracker-list mailing list tracker-list@gnome.org 
>>> https://mail.gnome.org/mailman/listinfo/tracker-list
>>> 
>> 
> 
> 
> 
> ___ tracker-list
> mailing list tracker-list@gnome.org 
> https://mail.gnome.org/mailman/listinfo/tracker-list
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSzuUbAAoJEEP2NSGEz4aDmtoIAIGNf/xAdHU/k2ckDQYbmGyo
PvGfPLzNLFGMXDQHj8foU3KV98obsaiYxpsZYlAc/nuRceuFMMSGYuWS+h4JyYQ/
xeX2sTA1eXuw36wB9xPpgMCY3i0IIjrkzN+7WmJMxfF5EmBFMpKrGprAExzauYgo
zijc1qR8NiScybrhQmvHBm8yeiiyfHxxf+5EFml5OxXGN3Ozt3lGd0EKc/PPwzjR
FIF+9RIBcQl6FC/6tTnQdwQ5qRmfmjLTELxUQsAh2evhTXsH8EK4GJoj7KwVbkEh
fSgdOpYwi7qYbTs7jDRPzSMJq0WU0jIUcU/gOWuet41VurKPzbcKoCkl48wT5Fg=
=T4na
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] FOSDEM submission proposal

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ralph Böhme schreef op 9/01/2014 19:17:
> Hi Philip
> 
> Am 09.01.2014 um 19:06 schrieb Philip Van Hoof
> :
>>> Great! I may be attending. Fwiw, if things work out as
>>> expected, Tracker will pave its way into large enterprise
>>> environments, functioning as search engine backend for Samba.
>>> :)
>> 
>> 
>> That's very cool to know! We're always very proud whenever we
>> learn that somebody is using our software for interesting
>> purposes and appliances.
>> 
>> I can mention this on the presentation if you and/or NetAFP want
>> that. If it's not sure yet then I can of course not to mention
>> it. Let me know.
> 
> of course you can mention that if you like. The new project of
> integrating Tracker with Samba (for use as search engine backend
> for Apple OS X SMB clients) will be made under the umbrella of my
> new employer SerNet. Tracker integration with Netatalk [1], the
> opensource AFP fileserver, was finished last year, then still by my
> own company NetAFP.

Oh wow, those are very nice and interesting use-cases indeed. When you
asked about the D-Bus session vs. system stuff I of course realized
that you wanted to use it for this purpose, but that it is actually
already being used and implemented for Netatalk and that it will now
also pave its way into large enterprise environments is more than nice.


I reiterate that we don't trust the security of the many libraries
that we link with and that I think we should do sandboxing of the
tracker-extract process using containers or at least by dropping
priviledges with set(e)uid like what you proposed earlier.

I can imagine that large entrprise environments care a lot about
their file servers not being exploited by placing a carefully crafted
file on a writable share and letting tracker-extract's memory get
buffer overflowed while it runs as a priviledged user.

I know, repeating myself: it's worrying me ;-). Nonetheless it's a
very nice use-case and I feel proud for our team that our software is
being used for this.

> -Ralph
> 
> [1]
> <http://netatalk.sourceforge.net/3.1/htmldocs/configuration.html#idp139639144340800>
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSz7cuAAoJEEP2NSGEz4aDLFsIALq8Ai8Iwiai8o2nEAYIUwl6
MLxvxb7etdPnG6M2HRpDeeH2haJLmD64pUIGPWbKHPsRaZe5swHA9xSRpgovSkOF
dS2za/yi2o5Q2STr1EOp+RmnH0CeI5bZxqCnBiNd8LFTiLx63luMKiLlfhzVntRk
COdauu2n0bElttOLjKUajfvCRH2Hz/G1WQTGfkBqF1/hZ733gJtougxvua71wUJR
a1ZLZQo7ilSWBdbeR51hnanpuItR3rmR9JKRMdEmYz3OExfOmRGbKAnPvvoxcGHD
4Wb0T2O6F+0++1rNw5l1yTwEmBGVGgizSU4SLa+SQumBsQ2I9fY0Mj89Jj/cvwY=
=sGfS
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Enable a new ontology - DwC

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alan Pater schreef op 12/02/2014 2:35:
> I am creating an ontology for Darwin Core (DwC) XMP metadata.
> 
> What steps are needed to enable a new ontology in tracker?

- - git branch dwc-ontology
- - git checkout dwc-ontology
- - Write the ontology in our Turtle format. Call it 94-dwc.ontology
- Ensure that nao:lastModified is correct in the
  tracker:Ontology stuff and that it's at the top of
  the file right underneath the @prefix lines.

- - Write a 94-dwc.description file
- - Put it in data/ontologies
- - Adapt Makefile.am (add to config_DATA)
- - make && make install
- - Restart tracker-store with -v 3, you should see your
  ontology being added and created.
- - Test thoroughly with tracker-sparql. Noticing that making
  changes afterwards is not always possible; depending on what
  kind of changes you make you might have to add ontology change
  coping infrastructure (which is a horror in complexity).
- - git add 94-dwc.description 94-dwc.ontology Makefile.am
- - git commit
- - git format-patch master

Kind regards,

Philip

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS+zeUAAoJEEP2NSGEz4aDo3oH/jUm2ICf239sKo0Z71SRnxgg
BJ2V+Me47wuuhEd2whufc0lhmcNk6EjDWI5YklpmtUD0Y3YQ3ME0n4wkf/X11Wq/
O6WRyGZajLSET4FtSiRCdqoLUqOkp4BViy6qywTMCDMIYAW8WEMqKkchhBLEV6Gy
RpPQJFOEo18lbNJSn17cJPZZf+sScvE641wnRz4T2Gh7xY0tkCHda0XYj5NUQstG
vsG76RzXl+qWEm8UhvHps4hp1PzyUrOqF4yZ5VkAv0hup3aWI8yLlpxaCjydTM6E
bdzaT7E9r7l3j+KQvykjb+EOIuJrsVeItHJH4VUqRUDALcSt5iyUpSICLsKo5Vo=
=jlMS
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] trackerbird fixes

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Michael,

Our NMO ontology is indeed not the same as Nepomuk. That's because
Nepomuk's is incomplete.

More information here:

https://wiki.gnome.org/Projects/Tracker/Documentation/Examples/SPARQL/Email

Kind regards,

Philip

Michael Lipp schreef op 6/02/2014 19:33:
> Hi Martyn,
>> If I query the tracker db for items of type nfo:Document,
>> however, I also get the emails. Could it be that the inheritance
>> relationships are implemented wrongly in the tracker db?
> 
> I wouldn't claim to have become an expert in such a short time, but
> I think that the definition in data/ontoligies/34-nmo.ontology
> 
> nmo:Message a rdfs:Class ; rdfs:comment "A message. Could be an
> email, instant messanging message, SMS message etc." ; 
> rdfs:subClassOf nfo:TextDocument ; tracker:notify true .
> 
> simply doesn't comply with the nepomuk specification and is the
> cause of the problem.
> 
> - Michael
> 
> ___ tracker-list
> mailing list tracker-list@gnome.org 
> https://mail.gnome.org/mailman/listinfo/tracker-list
> 

Alan Pater schreef op 12/02/2014 2:35:


- - git branch dwc-ontology
- - git checkout dwc-ontology
- - Write the ontology in our Turtle format. Call it 94-dwc.ontology
- Ensure that nao:lastModified is correct in the
  tracker:Ontology stuff and that it's at the top of
  the file right underneath the @prefix lines.

- - Write a 94-dwc.description file
- - Put it in data/ontologies
- - Adapt Makefile.am (add to config_DATA)
- - make && make install
- - Restart tracker-store with -v 3, you should see your
  ontology being added and created.
- - Test thoroughly with tracker-sparql. Noticing that making
  changes afterwards is not always possible; depending on what
  kind of changes you make you might have to add ontology change
  coping infrastructure (which is a horror in complexity).
- - git add 94-dwc.description 94-dwc.ontology Makefile.am
- - git commit
- - git format-patch master

Kind regards,

Philip

Enigmail
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS+zhUAAoJEEP2NSGEz4aD5PYIALxZesPMmnIBxoZPo/bBKslk
x6yDjeqYKnKQv5AZ47Oj3w5StbU9IhQKvRQ/dEOffEXUQqgREBB8vLQzKLB1bZiC
XbCPlPSBXnQYjo2vkKERotLWFGJZBL8Pxcq231KI+5vdcLzBoso6rCzkBwsj5KVx
nyxBR4J6NwxelWQQGljlas9dU2a9J5jBAHCCm3Uq4X/Sy/lUgo/rD6djySef1fV4
1dho9aXRldPXnA+KLoGh9b5ti897akHXwzHeqDh0BMOisFoSeuEByH0RXmQnZD3O
dAWzjGegjIkWczDvbPnfONbgDKgK5CZRbIT3ie4WYGfQ4MBNVpV71CdRhvXNEZk=
=zLit
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Enable a new ontology - DwC

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

$(BIN)/tracker-control -ks # this removes all your data
$(LIBEXEC)/tracker-store -v 3



Alan Pater schreef op 15/02/2014 1:56:
> I need some details on how to see what tracker is doing. I've built
> a package with 94-dwc.ontology but as far as I can see it is not
> doing anything.
> 
> Specifically, what commands should I be running t see what is going
> on?
> 
> 
> 
> On Wed, Feb 12, 2014 at 3:57 AM, Philip Van Hoof
>  wrote: Alan Pater schreef op 12/02/2014
> 2:35:
>>>> I am creating an ontology for Darwin Core (DwC) XMP
>>>> metadata.
>>>> 
>>>> What steps are needed to enable a new ontology in tracker?
> 
> - git branch dwc-ontology - git checkout dwc-ontology - Write the
> ontology in our Turtle format. Call it 94-dwc.ontology - Ensure
> that nao:lastModified is correct in the tracker:Ontology stuff and
> that it's at the top of the file right underneath the @prefix
> lines.
> 
> - Write a 94-dwc.description file - Put it in data/ontologies -
> Adapt Makefile.am (add to config_DATA) - make && make install -
> Restart tracker-store with -v 3, you should see your ontology being
> added and created. - Test thoroughly with tracker-sparql. Noticing
> that making changes afterwards is not always possible; depending on
> what kind of changes you make you might have to add ontology
> change coping infrastructure (which is a horror in complexity). -
> git add 94-dwc.description 94-dwc.ontology Makefile.am - git
> commit - git format-patch master
> 
> Kind regards,
> 
> Philip
> 
> ___ tracker-list
> mailing list tracker-list@gnome.org 
> https://mail.gnome.org/mailman/listinfo/tracker-list
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS/89hAAoJEEP2NSGEz4aDE7oH/A20GUl64GNRN1tzem52ozeK
Hq3chIPNVLIpvgF7QAEOrWnVfmJ5ciRi7q6G1mUXETbr9PfoaWcVYM0UhjX8rcRE
QaGsv8V8vmg6v3BddbME+T7vM5uj6S9PUbkeDd6lbY1BSW9irCfq2e4O7RX8D9yA
oGFjyB51m+leBrM7Xo2N/lCwKxFZ4mOh2+vMOhMnDadgylAp+1qYOcYVkiB7yShT
unQH+yIkU5qBCQlIRZtxTKp8ckEoESI1vtL8TdNVB7Ka8zJgiZUpPHFYt0VFisGr
s64/8PsF30vCg+mQI7l6GQAwRORYeRPJP3yV/DnpVVNsoarcbgfmVkvUjee+kzc=
=RpKE
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] REVIEW: Xavier Claessens' "priority" branch

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi guys,

One general question I have is that if this is configuration per RDF
class (rdf:type), then why aren't we putting this in SPARQL by just
adding a tracker:priority boolean to the ontology of rdfs:Class?

So basically, just like tracker:notify.

And if not in the ontology, then why not in the .rule files?

Kind regards,

Philip

Carlos Garnacho schreef op 19/02/2014 2:00:
> Hey,
> 
> I've been having a look at xclaesse's branch to get prioritization
> of certain rdf:types over others at the time of extracting
> metadata:
> 
> http://cgit.collabora.com/git/user/xclaesse/tracker.git/log/?h=priority
>
>  There, TrackerDecorator gains API to specify those high priority 
> rdf:types, which will affect how items are sorted/queued.
> 
> tracker-extract does expose this setting for its TrackerDecorator 
> implementation through a new SetRdfTypes DBus method, so running
> apps can register these, callers are monitored so the rdf:types
> return to regular priority if those disappear.
> 
> So from looking at the code, the implementation looks quite
> correct, and it looks like a positive addition, I just have minor
> improvements:
> 
> 0. Nice cleanup to tracker-extract's tracker-config.c, long time 
> overdue :)
> 
> 1. tracker_decorator_set_priority_rdf_types() is added, but there's
> no matching GObject property, would be great to get one.
> 
> 2. In tracker-decorator.c:607: /* FIXME: Can we know the
> class_name_id ? */ element_add (decorator, subject, 0, FALSE);
> 
> Probably the right approach there is accumulating those, and
> querying those subjects similarly to how
> tracker_decorator_started() does.
> 
> 3. In tracker-extract-controller.c:41: static void 
> files_miner_status_changed (TrackerExtractController *self, const
> gchar  *status)
> 
> If we just care about status equality with "Idle", I'd make this 
> function take a boolean, or wrap one taking a boolean, so we don't
> need to make up status strings in some calls.
> 
> Also, that function does if (..) if (...), when those are mutually 
> exclusive, would seem clearer with an if (...) else if (...)
> 
> 4. In tracker-extract-controller.c:190: self->priv->watch_id =
> g_bus_watch_name_on_connection (conn, 
> "org.freedesktop.Tracker1.Miner.Files", ...)
> 
> The arguments there aren't indented properly
> 
> 5. In tracker-extract-decorator.c:578: goto out; } out:
> 
> That goto feels a bit pointless :)
> 
> And that's all I could spot in that branch, nice work Xavier :)
> 
> Cheers, Carlos
> 


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTBLWaAAoJEEP2NSGEz4aDbzMH/j4Neb38iqEJsSf16xpyiH9E
egvXMCxYggwkanfHIEmj2uMPxULllJ7PXaCtPhxRIaUUVIEmhXeLmuoE2ft6LMgl
51xdZBDDYez7EFxKjDxfWpzBVHz0SiYtpsQZ3kxV1OURLfGmS6tJylLoE/5pSrNa
lZIZJFBnU/a9z7++jOgafpr+LSI0qFej1fsP/LRhkxTXz2nmNsccIw3qDUSlxPOp
Hm8MM1/haFU7bB/GkYCo+n8H47AAJL88/VRMvG/7fwn9sdRgJ1TBg8B/viWE1Q3Y
vAqbkJdWkqQIdmVKu3wHQerFENzHgbgqZEinAxr11wgaXM8qOKQ8ttMMrufIuG4=
=Xido
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] Coverity report on Tracker's code

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


https://scan.coverity.com/projects/1524
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTE3iiAAoJEEP2NSGEz4aDbMUH/RL4klOBc4pZYIjh2XeLkZm/
zLDls3mrGTGVBxcGp+cJyPi6ep2m2XIm3RMyprMq911iXxm7RWLDX3WL9U9nUSlS
a144pu7jehMb5g8KvN0Cw2oCR7DYM4fHcsrXtEzczrh2Or0Ueouh8mnWZp/8Nw2n
ERkxhQJHJVUB6DoFRQ+kCKUxPJ6KRFoMcYFDRdoSp4UQIRU+sN90Sm2AcjdPSo1u
X9iyAxN2zdjcgAIuaFfyq3mMl5YO6/cdWHB/Xva+WLi6ECARAGFqpThBlVlvKTa9
1Y8732vfoU7YgVbqBXadyIXevAhMOaTOboEK1tvzY1XcyCO1+0v03RDEeUV4v3c=
=mx41
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] A lot more VmRSS memory usage while indexing since 0.14

[Philip Van Hoof]

Hi guys,

In a use-case on a mobile phone that used to use 0.14 we see an
increased VmRSS memory usage of tracker-miner-fs since the 0.17 based
version that we started using.

I have attached a massif dump, you can vizualize this with Massif
Visualizer.


Example snapshot:

#---
snapshot=40
#---
time=15010364654
mem_heap_B=390075965
mem_heap_extra_B=107877155
mem_stacks_B=0
heap_tree=peak
n5: 390075965 (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
 n2: 149302848 0x5E3FB26: g_array_maybe_expand (garray.c:771)
  n2: 149298400 0x5E400FE: g_array_insert_vals (garray.c:516)
   n2: 149298240 0x5CB5346: g_file_info_create_value (gfileinfo.c:1084)
n2: 149298176 0x5CB6746: g_file_info_set_file_type (gfileinfo.c:1798)
 n1: 149298176 0x5D6AD8A: g_local_file_enumerator_next_file 
(glocalfileenumerator.c:413)
  n1: 149298176 0x5CAAA46: next_files_thread (gfileenumerator.c:639)
   n1: 149298176 0x5CDA166: run_in_thread (gsimpleasyncresult.c:861)
n1: 149298176 0x5CC569E: io_job_thread (gioscheduler.c:177)
 n1: 149298176 0x5EA4EFE: g_thread_pool_thread_proxy (gthreadpool.c:309)
  n1: 149298176 0x5EA41A6: g_thread_proxy (gthread.c:801)
   n1: 149298176 0x609FD12: start_thread (pthread_create.c:310)
n0: 149298176 0x618EBB6: ??? (in /lib/libc-2.15.so)
 n0: 0 in 1 place, below massif's threshold (01.00%)
n0: 64 in 3 places, all below massif's threshold (01.00%)
   n0: 160 in 2 places, all below massif's threshold (01.00%)
  n0: 4448 in 2 places, all below massif's threshold (01.00%)
 n3: 123641386 0x5E9A1FA: g_strdup (gstrfuncs.c:356)
  n1: 102578495 0x5D66E9A: canonicalize_filename (glocalfile.c:203)
   n2: 102578495 0x5D6A88E: _g_local_file_new (glocalfile.c:289)
n1: 102578246 0x5D6A912: g_local_file_resolve_relative_path 
(glocalfile.c:539)
 n1: 102578246 0x5C9F3E2: g_file_resolve_relative_path (gfile.c:819)
  n1: 102578246 0x485340A: file_enumerate_next_cb (tracker-crawler.c:736)
   n1: 102578246 0x5CAA69E: next_async_callback_wrapper 
(gfileenumerator.c:298)
n1: 102578246 0x5CDA2C6: g_simple_async_result_complete 
(gsimpleasyncresult.c:767)
 n1: 102578246 0x5CDA3AE: complete_in_idle_cb_for_thread 
(gsimpleasyncresult.c:835)
  n1: 102578246 0x5E728C6: g_idle_dispatch (gmain.c:4657)
   n1: 102578246 0x5E75DC6: g_main_context_dispatch (gmain.c:2539)
n1: 102578246 0x5E760C2: g_main_context_iterate.part.17 
(gmain.c:3146)
 n1: 102578246 0x5E76646: g_main_loop_run (gmain.c:3339)
  n0: 102578246 0xF5AE: main (tracker-main.c:975)
n0: 249 in 2 places, all below massif's threshold (01.00%)
  n1: 2095 0x5CA9F0E: _g_file_attribute_value_set_byte_string 
(gfileattribute.c:731)
   n1: 2095 0x5D6D1A2: _g_local_file_info_get_nostat (glocalfileinfo.c:1415)
n1: 2095 0x5D6AD7E: g_local_file_enumerator_next_file 
(glocalfileenumerator.c:412)
 n1: 2095 0x5CAAA46: next_files_thread (gfileenumerator.c:639)
  n1: 2095 0x5CDA166: run_in_thread (gsimpleasyncresult.c:861)
   n1: 2095 0x5CC569E: io_job_thread (gioscheduler.c:177)
n1: 2095 0x5EA4EFE: g_thread_pool_thread_proxy (gthreadpool.c:309)
 n1: 2095 0x5EA41A6: g_thread_proxy (gthread.c:801)
  n1: 2095 0x609FD12: start_thread (pthread_create.c:310)
   n0: 2095 0x618EBB6: ??? (in /lib/libc-2.15.so)
  n0: 85116 in 164 places, all below massif's threshold (01.00%)
 n5: 93438192 0x5E9897A: g_slice_alloc (gslice.c:1003)
  n2: 42128852 0x5E98ED6: g_slice_alloc0 (gslice.c:1029)
   n2: 42016000 0x5DEEEA2: g_type_create_instance (gtype.c:1872)
n2: 42009816 0x5DC99EA: g_object_constructor (gobject.c:1849)
 n1: 41989784 0x5DCC7E6: g_object_newv (gobject.c:1632)
  n3: 41989784 0x5DCCE9A: g_object_new (gobject.c:1542)
   n2: 23327860 0x5D6D30A: _g_local_file_info_get (glocalfileinfo.c:1476)
n1: 23327840 0x5D6AD66: g_local_file_enumerator_next_file 
(glocalfileenumerator.c:405)
 n1: 23327840 0x5CAAA46: next_files_thread (gfileenumerator.c:639)
  n1: 23327840 0x5CDA166: run_in_thread (gsimpleasyncresult.c:861)
   n1: 23327840 0x5CC569E: io_job_thread (gioscheduler.c:177)
n1: 23327840 0x5EA4EFE: g_thread_pool_thread_proxy 
(gthreadpool.c:309)
 n1: 23327840 0x5EA41A6: g_thread_proxy (gthread.c:801)
  n1: 23327840 0x609FD12: start_thread (pthread_create.c:310)
   n0: 23327840 0x618EBB6: ??? (in /lib/libc-2.15.so)
n0: 20 in 1 place, below massif's threshold (01.00%)
   n2: 18661056 0x5D6A882: _g_local_file_new (glocalfile.c:288)
n1: 18660864 0x5D6A912: g_local_file_resolve_relative_path 
(glocalfile.c:539)
 n1: 18660864 0x5C9F3E2: g_file_resolve_relative_path (gfile.c:819)
  n1: 18660864 0x485340A: file_enumerate_next_cb (tracker-crawler.c:736)
   n1: 18660864 0x5CAA69E: next_async_callback_wrapper 
(

[Tracker] Request for review, jolla upstreaming

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi guys, here are the commits from Jolla. Ready for review:

https://git.gnome.org/browse/tracker/log/?h=jolla-upstreaming

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTICrgAAoJEEP2NSGEz4aDwysH/Rlqwuha/Ztvghs0djsCWAoo
enQKZUK4tc9I+jERD3b7gNbe8vP/af3ad6GQdj/PnElDJA+AnAT+yAn8Qjgu1i/J
fAxqsegT7MW4JquPFbysZkCrocHnJHLe0nPJo0YSSjo6DTzlTDWidw9xKGY5Gyag
q90NCnCL+uoPCu3Ic5YrWlghU97zpKhGoZrAqyhj8nPgffq7k/lXs6SV6FSgA4il
tEAzSSNeCzWBYwb7vziwS4GP+BbFBPGBs89zVw5VTSRKlkevn9ZTn4FxoQZRf6aX
xtq2Q0VEziW3G5dy2H7NpHIG6unK5EbbS2LMYuvScbHYxNuzDMWoXrc50EfygJo=
=k1vJ
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Request for review, jolla upstreaming

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martyn Russell schreef op 12/03/2014 13:28:
> On 12/03/14 12:24, Martyn Russell wrote:
>> OK, so it looks like this is just about disabling enca AND icu
>> for MP3 encoding detection. The existing code already does the
>> same thing when we have enca and/or icu. Is that right or? If so,
>> it looks good to me.
> 
> To clarify: I meant that you can't disable icu for mp3 encoding
> ONLY, you can only disable icu for EVERYTHING currently. You want
> this patch to disable icu for mp3 encoding guessing only right?
> 
> IF so, it looks good to me.
> 

Right. That's the point: enable libicu but disable (just) its charset
encoding detection.

Kind regards,

Philip
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTIFcyAAoJEEP2NSGEz4aDkzkH/2NezPOcFZLG+10FBarYG2wN
g/eSqGF5Hbc0lsqKoejGescVYpRYgg2Az9SDPhxEr249RnV9LVq1C+LzpI4T+Oyv
I0COst5fGR4GQ+0N5pv5gsRs7yXZuowvHF+KXFiGG3nja4dfLrYiaU46zN+cgifm
OA46mgV0+FS9jISYp7/s6WeJpKYCcskHOPoH8h9Ngz9xenewZEJfrPBfBvl+IrhF
RnO0razCEPPxiBV/ukbARt3iGjcnlFKB4bKfOsXgocXb7CSHiTe5dGDbw0Rovtwi
Hc4VR//Y1QJU9HqszkiqU9d4ud3Hl22s2hchXfLqji126SJwfM5adTSZGGgQfMA=
=Gvod
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Request for review, jolla upstreaming

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martyn Russell schreef op 12/03/2014 13:24:
> On 12/03/14 09:37, Philip Van Hoof wrote:

> Apparently, GIFLIB_MAJOR is only defined in version 4.2, wouldn't
> it make more sense to have:
> 
> #ifdef GLIB_MAJOR ... #else PrintGifError() #endif
> 
> ?

> Er, GIFLIB rather

I'll look into this.


> Cool to have a BMP extractor. Though you leak filename in the
> extractor and that needs fixing first.

ok


> The fallbacks for BMP on master should do the basics of what your
> patch does here (i.e. fill in Photo/Image ontology details) -
> detailed in the xml files.

Aha, didn't know about fallbacks yet. But it's good to have the basics
for a bmp extractor ready. Hoping that somebody fills in actual
metadata extraction ;-)

I'll fix the memory leak.

> All other patches/changes look ok to me.
> 
> Thanks Philip,

No problem.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTIFe2AAoJEEP2NSGEz4aDLU8H/0mWgK6GAvhpcP95rivTACXr
YQNWJr85vWOrQrYXvFeXE9Lh9ZOKY7FAx2AGdXkI8yW8F5Ma87Qd+2MInoc5PMNg
aeFz/rrnAfv6ktsV3p1HmPMSseDbDKTCYPC9Mje/SnFaJcr9f9PV46pSkMG/L3cu
MDy+8fNfJg1Fn4a5+tvtf6my3Hl4Dq4mJbpE1jIEHyXoR+s0uoTtUXZL+yHPNGey
dXpJ4CSLO/khdw7U8o+MwHlExPca4wLEnep2/WsRQUC9YGvwlYVufqVdC6Zknaf7
dxxIL1hoGefyxmnKU3J1qrwOA1dOmJP3vosXogvY83vkdXYDolBaheX6oEtGobQ=
=AQnX
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] An XML indexer?

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Adam,

You could write one, but I also think it's better to have indexer per
specific file format. XML is not really specific.

Kind regards,

Philip

Adam Tauno Williams schreef op 13/03/2014 12:08:
> Does Tracker have an indexer for XML files?
> 
> Mime-Type: application/xml
> 
> Just indexing them as text sort-kinda-works.
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTIZNiAAoJEEP2NSGEz4aDFb0H/3QThjmCVSYAymjqd2yUQFhr
i+gI2ptf4o2tglT9wefYL5r9lPGybFnlB5L4YHWe2O/PNrm2LFMfkYu9G9eidND5
ZQYWMRwzwooT6ZBe+7fHIafsfvCiU3eBPyHabcbg+qttU4fhV5enGy4/HiJGfsio
K94pX50Gy7SSOZ6WEBUhRSWDWSp3tya1xtRJnlyNicn5K4/GG4Oj0wgZrrPaw5Sg
nyMLBtIzMCBRSB2nqbYwU1TptwOHSA0eWMYF9CxCYsaSAs25hXTjv54/tEBBMgQf
o+H+8Rp3CcBWfmry8oN+TwbfD+TZuz+Ti9IA5smTtvELI4P4Wrt6T1792kAaNI8=
=1O87
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] Problems with removable volume support

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi guys,

Here are the problems we've seen with removable volume support:

Some platforms don't use udisk2 and/or gvfs so they fall back to the
implementations behind gio/gunix*c. These implementations aren't
always very reliable. In particular is the UUID of the volume not
always correct with those implementations. It would be nicer if we
could let something external to tracker-miner-fs fed us with that UUID
and mount point name upon mount event, rather than using GVolumeMonitor.

Some platforms use a tmpfs for the parent directory of the mount point
subdirectories. After each reboot the last modification time of that
tmpfs will or can differ and tracker-miner-fs sometimes gets confused
about that.

Some platforms will make a unique directory upfront mounting, for
example /media/sdcard/$UUID_OF_DEV/, when /media/sdcard is in the
index-recursive-directories configuration the mount event handler
sometimes causes a race condition with the mkdir handler of
/media/sdcard/$UUID_OF_DEV/.

When the index-recursive-directories contains a parent dir of a mount
point subdir and indexing removable volumes is turned on, there's a
race between unmount event and the file monitoring seeing files being
removed (as a result of the unmount presumably). I'd say mount point
subdirs should be added to ignore list automatically and handled by
the removable volume support exclusively.

Kind regards,

Philip
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTIZxjAAoJEEP2NSGEz4aDydgH/2ZtLNFmIAToqA6UXytnMoBD
dXPvV5FVJ8xv7q2B5bFnXUJaIkM8uaCnGLSm7pvOSbpGzPE14cwWmV27uBoNc7/z
e/OxRnPYU8TVjaOjGL4gmNEzFuu+nj5DAQhIGZN5ewDflrAiuIvbMHpp5TDXtlBK
NkRlYJl0+FM1MDcljcKZpQndkyuxpyZqoGMuzwVuNz9zB6ZrbQkH9QxI+ClHMs47
yHcL60Xl7pDWNR+aI0xzHEPQyr3dxmVMl8Tx21dQULrx0YeE+izycUGFxRB7Fn3p
LphtuWAnbRx8dCdUakm07nR3vwIKXL1e2fbI+UzGpzObRSk9foUdHm6OrtHck5Y=
=NAg5
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] REVIEW: 'follow-symlinks' branch

[Philip Van Hoof]

Hi Martyn,

I'm ok with the patch. I don't think we need to make it configurable.

Kind regards,

Philip

On Mon, 2014-03-17 at 09:40 +, Martyn Russell wrote:
> Hi all,
> 
> There was recent interest in following symlinks within Tracker:
> 
>https://bugzilla.gnome.org/show_bug.cgi?id=726264
> 
> For those that don't know, Tracker uses GIO and in nearly every case the 
> G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS flag, documented here:
> 
>https://developer.gnome.org/gio/stable/GFile.html#GFileQueryInfoFlags
> 
> The bug above talks about how disruptive this is for git-annex which 
> almost entirely uses symlinks to git objects/resources in .git/. We've 
> had this policy/code in Tracker for a LOOONG time, I think, to avoid 
> following files onto remote file systems or into public (e.g. 
> /usr/share) areas.
> 
> I knocked up a preliminary branch here:
> 
>https://git.gnome.org/browse/tracker/log/?h=follow-symlinks
> 
> Which removes these flags for testing, but I wanted to gauge usefulness 
> before taking this any further.
> 
> So:
> 
> 1. Would a patch/branch like this be useful to anyone?
> 
> 2. Would it make sense to make this a configuration option in the 
> miner-fs (defaulting to the current practise), that way, avoiding any 
> unexpected behaviour from what we have now?
> 
> Thoughts?
> 


___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Tracker 0.17.6

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Thanks for doing the extra work involved in a extra release Martyn and
also thanks for finding and fixing the build glitch Michael.

Great that you guys care about things like this.

Kind regards,

Philip

Martyn Russell schreef op 19/03/2014 10:11:
> On 18/03/14 21:16, Michael Biebl wrote:
>> diff --git a/examples/libtracker-sparql/Makefile.am 
>> b/examples/libtracker-sparql/Makefile.am index e4bcc89..c29d470
>> 100644 --- a/examples/libtracker-sparql/Makefile.am +++
>> b/examples/libtracker-sparql/Makefile.am @@ -5,6 +5,7 @@
>> AM_CPPFLAGS = $(BUILD_CFLAGS) \ $(LIBTRACKER_SPARQL_CFLAGS)
>> 
>> LDADD = 
>> $(top_builddir)/src/libtracker-sparql-backend/libtracker-sparql-$(TRACKER_API_VERSION).la
>>
>>
>> 
\
>> +
>> $(top_builddir)/src/libtracker-common/libtracker-common.la \ 
>> $(BUILD_LIBS) \ $(LIBTRACKER_SPARQL_LIBS)
>> 
>> 
>> seems to do the trick for me
>> 
>> I'm curious you didn't stumble upon this during "make distcheck" 
>> (which you certainly use I guess)
> 
> No I didn't interestingly. I did have the error at some stage
> yesterday, but a git clean -dfx and autogen.sh call didn't
> reproduce it.
> 
> I was hoping I wouldn't need this, but ...
> 
> I will roll a 0.17.7 today.
> 
> Thanks for noticing!
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTKWcHAAoJEEP2NSGEz4aD5NYH/2bmn6rgVWKzTf1cXrXJ8vjU
7E8px7frN+CmZobQQNKgWK1Y2bbAkzeDv9Iyuquk5SuezQBLUeKXXHA9K5WErIoT
IJsEjh48XtbmonxsrrmlqmSLWfowHY+KJhDtu9CArtQGwBP3akE38kjXQ7Mm4WgM
VJ65fEny1Ds5bz7Qwt9BPtAbeeaDOECpg+l9CSz4BgPAhBA/GQFyKRc5NDgGB93d
GaBglkflsiQmaynccN3z6jUJMZr46BmZNyFIm+7ESXBLWykkXYNXe92ILO9ObSdw
xpaq+NDpp7VmL56/y/VoL3bcIIPNGl0OMStIlRY8faBU6lO10NsvrqqXUXWq4DA=
=8iNd
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] Tracker 0.17.6

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Michael,

I think that with passive extraction the idea is that tracker-extract
passively awaits instructions (by GraphUpdated) instead of gets
actively (activated) by tracker-miner-fs.

But I'll allow Carlos to explain it more in depth.

Kind regards,

Philip

Michael Biebl schreef op 19/03/2014 10:56:
> Hi,
> 
> 2014-03-18 18:58 GMT+01:00 Martyn Russell :
>> * tracker-extract: Add desktop file to autostart process
> 
> This is something I'm curious about: What were the reasons to
> start tracker-extract (and tracker-miner-fs) via XDG autostart
> files? In the past IIRC we used D-Bus activation to start those
> services on-demand. Only tracker-store itself was started via an
> XDG autostart file.
> 
> Michael
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTKWx0AAoJEEP2NSGEz4aDiG0IAI++dgi1ObUkN370tI3CUkeI
MwsDj5km1C/oNKS4clppIVHQKuATat5kmzjxe13DsyBHEP+UKs4vPB7Co0Rw1L5D
wkHxOL8H7HTJFXbVjLTbZOm/Lgpm3FQgvZdwuWEs4LF13PK3kdnFazPXdvg3Y47Y
3VqarG51zpUGck3R7reLcrVVpdBYbftgArb+ba/CrqMYHGIcZMqZW3pCr5yhHxrX
X3RA/D6UqdEpTApJQp0/GBFj1ggXd0BI5M7F+TMvJwACN9ceM7juBQzj7NhKCbDv
bTIzKwzvbZytbiYhlgcsgE5lKgmbDjKPReZ3+OF6j3T5E9SfDNZho/rECgmJ7ag=
=4Nea
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] tracker-sparql dbus sparql results

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


get_value_type and get_variable_name:

https://git.gnome.org/browse/tracker/tree/src/libtracker-sparql/tracker-cursor.vala#n126

https://git.gnome.org/browse/tracker/tree/src/libtracker-sparql/tracker-cursor.vala#n139

You btw shouldn't use the DBus Resources1 object, but use
libtracker-sparql instead.


Ivan Frade schreef op 17/04/2014 20:14:
> Hi Jürgen,
> 
> Yes, tracker does not return bindingNames or types of the resulting
> nodes. It assumes the client takes care of interpreting the results
> of its query.
> 
> A workaround would be to parse the SparQL in the wrapper and add
> that information when translating the DBus result set to the
> openrdf format. The binding Names can be added straight forward
> from the SELECT of the query. The type information is more
> complicated to deduce, based on the position in the query and/or
> the rdfs:range of the properties (defined in the ontology).
> 
> Regards,
> 
> Ivan
> 
> 
> On Thu, Apr 17, 2014 at 10:11 AM, Jürgen Jakobitsch < 
> j.jakobit...@semantic-web.at> wrote:
> 
>> hi,
>> 
>> i'm currently developing an openrdf [1] repository implementation
>> with a tracker-sparql backend via dbus. this will enable java
>> developers to include tracker-sparql results in any application
>> (or create a sparql endpoint) extremly easily. openrdf's api is
>> quite common in the semweb community..
>> 
>> everything is working very nice already  the only trouble i'm
>> having is that i get a vector of vectors containing simple
>> strings as a result object, meaning i need to find out types
>> (literals, uris, bnodes, typed literals)..
>> 
>> is there any known way to retrieve some more information in the
>> results given via dbus? also bindingNames are missing...
>> 
>> any pointer really appreciated wkr turnguard..
>> 
>> 
>> [1] http://www.openrdf.org/
>> 
>> | Jürgen Jakobitsch, | Software Developer | Semantic Web Company
>> GmbH | Mariahilfer Straße 70 / Neubaugasse 1, Top 8 | A - 1070
>> Wien, Austria | Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22
>> 
>> COMPANY INFORMATION | web   : http://www.semantic-web.at/ |
>> foaf  :
>> http://company.semantic-web.at/person/juergen_jakobitsch PERSONAL
>> INFORMATION | web   : http://www.turnguard.com | foaf  :
>> http://www.turnguard.com/turnguard | g+:
>> https://plus.google.com/111233759991616358206/posts | skype :
>> jakobitsch-punkt | xmlns:tg  =
>> "http://www.turnguard.com/turnguard#";
>> 
>> ___ tracker-list
>> mailing list tracker-list@gnome.org 
>> https://mail.gnome.org/mailman/listinfo/tracker-list
>> 
>> 
> 
> 
> 
> ___ tracker-list
> mailing list tracker-list@gnome.org 
> https://mail.gnome.org/mailman/listinfo/tracker-list
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTUPETAAoJEEP2NSGEz4aDuUAIALHr/46yb4hUVuj5GWaxls3F
H5JODAvmGHEuQsgSmemjj9GQyFEUb2VClM6KjoBqK1+sn8FxVDKXaTn7yUMJNdjz
tzefo25nuAzwiKGgnpwjhlw474PvlhGlaEIvUiQTQiMAdE9DV5sR3gzSZ5N7Eoo7
p/8jPi4EaARgaLlxDOlAwQqpQTe3qPOPjQcNeerWgO+azemFaSYjdR1o8f32726n
7b92sidVMDv4Zoq2Osh9EEycS/4fxUvWE1eBYG7BgyNAf5QMv3S/mlmFGStZnS70
+hqumsvcWyaI+wQ3iMELqioFDfHYNdQfjYnr/jgJSFEZrYliU2lyla093frQ61Y=
=FF/z
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

Re: [Tracker] tracker-sparql dbus sparql results

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi Jürgen,

In that case you should use the Steroids1 DBus object which works by
passing file descriptors and pipe(). I'm guessing that in Java you can
use the type FileDescriptor to turn that to a InputStream.

https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-steroids.vala

Steroid1's protocol that goes over pipe()/vmsplice() already passes
the variable-names and column-types over.

Usage of Resources1 is very slow and on top it's not really a
supported interface. Resources1 is actually only for the GraphUpdated
signal, which is the only officially supported interface that the DBus
object exports.

The Steroids1 DBus object is going to stay and is used for write
queries and fallback for libtracker-sparql in case WAL direct access
mode can't be used.

Kind regards,

Philip


Jürgen Jakobitsch schreef op 18/04/2014 15:53:
> hi philipp,
> 
> i'm currently using the dbus resource because i'm writing the
> openrdf repository in java and didn't want to got down the jni, jna
> road...
> 
> i already have built in a switch in tracker-resource.vala, about
> here [1], testing the cursor.get_value_type, but the returned
> value_types are not totally correct. for some uris the value is 1
> for other uris the value type is 2... i'm gonna issue a bug report,
> as soon as i have verified, that i'm not doing something wrong.. 
> also the returned value_types are only 1 or 2.. there are not other
> values (like bnode, double, date...) although the returned string
> suggest they should be used..
> 
> wkr turnguard
> 
> [1] 
> https://git.gnome.org/browse/tracker/tree/src/tracker-store/tracker-resources.vala#n102
>
>  | Jürgen Jakobitsch, | Software Developer | Semantic Web Company
> GmbH | Mariahilfer Straße 70 / Neubaugasse 1, Top 8 | A - 1070
> Wien, Austria | Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22
> 
> COMPANY INFORMATION | web   : http://www.semantic-web.at/ |
> foaf  :
> http://company.semantic-web.at/person/juergen_jakobitsch PERSONAL
> INFORMATION | web   : http://www.turnguard.com | foaf  :
> http://www.turnguard.com/turnguard | g+:
> https://plus.google.com/111233759991616358206/posts | skype :
> jakobitsch-punkt | xmlns:tg  =
> "http://www.turnguard.com/turnguard#";
> 
> 
> 2014-04-18 11:32 GMT+02:00 Philip Van Hoof :
> 
> 
> get_value_type and get_variable_name:
> 
> 
> https://git.gnome.org/browse/tracker/tree/src/libtracker-sparql/tracker-cursor.vala#n126
>
> 
> 
> https://git.gnome.org/browse/tracker/tree/src/libtracker-sparql/tracker-cursor.vala#n139
>
>  You btw shouldn't use the DBus Resources1 object, but use 
> libtracker-sparql instead.
> 
> 
> Ivan Frade schreef op 17/04/2014 20:14:
>>>> Hi Jürgen,
>>>> 
>>>> Yes, tracker does not return bindingNames or types of the
>>>> resulting nodes. It assumes the client takes care of
>>>> interpreting the results of its query.
>>>> 
>>>> A workaround would be to parse the SparQL in the wrapper and
>>>> add that information when translating the DBus result set to
>>>> the openrdf format. The binding Names can be added straight
>>>> forward from the SELECT of the query. The type information is
>>>> more complicated to deduce, based on the position in the
>>>> query and/or the rdfs:range of the properties (defined in the
>>>> ontology).
>>>> 
>>>> Regards,
>>>> 
>>>> Ivan
>>>> 
>>>> 
>>>> On Thu, Apr 17, 2014 at 10:11 AM, Jürgen Jakobitsch < 
>>>> j.jakobit...@semantic-web.at> wrote:
>>>> 
>>>>> hi,
>>>>> 
>>>>> i'm currently developing an openrdf [1] repository
>>>>> implementation with a tracker-sparql backend via dbus. this
>>>>> will enable java developers to include tracker-sparql
>>>>> results in any application (or create a sparql endpoint)
>>>>> extremly easily. openrdf's api is quite common in the
>>>>> semweb community..
>>>>> 
>>>>> everything is working very nice already  the only trouble
>>>>> i'm having is that i get a vector of vectors containing
>>>>> simple strings as a result object, meaning i need to find
>>>>> out types (literals, uris, bnodes, typed literals)..
>>>>> 
>>>>> is there any known way to retrieve some more information in
>>>>> the results given via dbus? also bindingNames are
>>>>>

Re: [Tracker] tracker-sparql dbus sparql results

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Jürgen,

I recall writing a blog article about the feature when we implemented
it. Maybe you can extract from the date/time of the article and its
content the commits related to the implementation of the feature?:

http://pvanhoof.be/blog/index.php/2010/09/09/less-exciting-features-also-need-to-be-done-return-types

I'm not sure whether column-types (or rather return-types would indeed
be a more suitable name for rdf-world) was done 'correctly' (the way
you describe). I remember that it was done for a limited use-case and
made to work up until it worked for that use-case.

You might have to improve the current situation before it's usable for
your use-case.

Kind regards,

Philip


Jürgen Jakobitsch schreef op 21/04/2014 17:38:
> hi, after struggling with UNIX_FD (dbus type 'h') not really being 
> supported i swithed to JNA using libtracker-sparql (it's much
> easier anyway...).
> 
> i however realized that the rdf datatypes do not work as expected
> (as far as i understand tracker-cursor simply uses the first
> value_type for a column and returns it for every row returned).
> 
> how to verify :
> 
> 1. i added the following test to
> tests/libtracker-sparql/tracker-test.c
> 
> static void test_tracker_sparql_cursor_types (void) { GError *error
> = NULL;
> 
> TrackerSparqlCursor *cursor1; TrackerSparqlConnection *connection;
> 
> //const gchar* query = "SELECT ?o ?p WHERE { 
> 
> ?p ?o  . }"; const gchar* query = "SELECT ?date WHERE { 
> 
> < http://www.tracker-project.org/ontologies/tracker#added> ?date .
> } ORDER BY ?date"; connection = tracker_sparql_connection_get
> (NULL, &error); g_assert_no_error (error);
> 
> cursor1 = tracker_sparql_connection_query (connection, query, 0,
> &error); g_assert_no_error (error); gint n_columns =
> tracker_sparql_cursor_get_n_columns (cursor1); g_print("query %s",
> query); while (tracker_sparql_cursor_next (cursor1, NULL, NULL)) { 
> int i = 0; for (i = 0; i < n_columns ; i++) { g_print ("=>type of
> %s is %d ", 
> tracker_sparql_cursor_get_string(cursor1,i,NULL),(int)tracker_sparql_cursor_get_value_type
>
> 
(cursor1, i));
> } g_print("\n"); } g_object_unref(cursor1); }
> 
>  g_test_add_func 
> ("/libtracker-sparql/tracker/test_tracker_sparql_cursor_types", 
> test_tracker_sparql_cursor_types);
> 
> 2. replace  with a known entity that has
> a tracker#added predicate
> 
> 3. sudo make => ./tracker-test
> 
> 4. using the first query i get 2 or 1 (depending on ?o ?p or ?p ?o)
> for the date (tracker#added)
> 
> 5. using the second query i get 5 for the value_type (correct)
> 
> i assume that the cursor takes the value_types of the first row it 
> encounters and takes these value_types for every following row.
> such behaviour is suitable for the sql world but not for the sparql
> world. is it really the "g_once_init_leave", can i simply delete
> g_once_init_leave without sideeffects?
> 
> any pointer really appreciated.
> 
> wkr turnguard
> 
> 
> | Jürgen Jakobitsch, | Software Developer | Semantic Web Company
> GmbH | Mariahilfer Straße 70 / Neubaugasse 1, Top 8 | A - 1070
> Wien, Austria | Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22
> 
> COMPANY INFORMATION | web   : http://www.semantic-web.at/ |
> foaf  :
> http://company.semantic-web.at/person/juergen_jakobitsch PERSONAL
> INFORMATION | web   : http://www.turnguard.com | foaf  :
> http://www.turnguard.com/turnguard | g+:
> https://plus.google.com/111233759991616358206/posts | skype :
> jakobitsch-punkt | xmlns:tg  =
> "http://www.turnguard.com/turnguard#";
> 
> 
> 2014-04-18 22:17 GMT+02:00 Jürgen Jakobitsch
> :
> 
>> philip, thanks for information.. i'll take a closer look at
>> steroids1 dbus...
>> 
>> wkr turnguard
>> 
>> | Jürgen Jakobitsch, | Software Developer | Semantic Web Company
>> GmbH | Mariahilfer Straße 70 / Neubaugasse 1, Top 8 | A - 1070
>> Wien, Austria | Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22
>> 
>> COMPANY INFORMATION | web   : http://www.semantic-web.at/ |
>> foaf  :
>> http://company.semantic-web.at/person/juergen_jakobitsch PERSONAL
>> INFORMATION | web   : http://www.turnguard.com | foaf  :
>> http://www.turnguard.com/turnguard | g+:
>> https://plus.google.com/111233759991616358206/posts | skype :
>> jakobitsch-punkt | xmlns:tg  =
>> "http://www.turnguard.com/turnguard#";
>> 
>> 
>> 2014-04-18 22:04 GMT+02:00 Philip Van Hoof
>> :
>> 
>> -BE

Re: [Tracker] libtracker-sparql java bindings

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Jürgen,

Wow, great that you're making those bindings available. I hope others
will join the effort!

Kind regards,

Philip

Jürgen Jakobitsch schreef op 22/04/2014 15:07:
> hi,
> 
> as the basis for my openrdf tracker-repository project i have put
> online the first version of libtracker-sparql java bindings here :
> 
> https://github.com/turnguard/com-turnguard-libtracker-sparql
> 
> any comments, suggestions,... highly appreciated
> 
> wkr turnguard
> 
> | Jürgen Jakobitsch, | Software Developer | Semantic Web Company
> GmbH | Mariahilfer Straße 70 / Neubaugasse 1, Top 8 | A - 1070
> Wien, Austria | Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22
> 
> COMPANY INFORMATION | web   : http://www.semantic-web.at/ |
> foaf  :
> http://company.semantic-web.at/person/juergen_jakobitsch PERSONAL
> INFORMATION | web   : http://www.turnguard.com | foaf  :
> http://www.turnguard.com/turnguard | g+:
> https://plus.google.com/111233759991616358206/posts | skype :
> jakobitsch-punkt | xmlns:tg  =
> "http://www.turnguard.com/turnguard#";
> 
> 
> 
> ___ tracker-list
> mailing list tracker-list@gnome.org 
> https://mail.gnome.org/mailman/listinfo/tracker-list
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTVnLtAAoJEEP2NSGEz4aDMvIIAKa0gYETL/tbOpg+qpgQWLLA
LyOHSROaGU+BeR0fNdLM1FVmNI2Shpq0WLY3xiH24csAPw8c3FqBSuCRyrzZvBkT
HjR88X4zCFM3FQUBZJJWpoyr2S2DwsmBHb4xGgDyTnTPlrRPp3ST1SsVtTIqxylP
dKSX8fyTZyZ8vus4hPePgA3IjwPbrprLrQD1JuhCgiJeTbQhR8uO+5NCz8Sy71d4
iD+tMH4p48h0ccduK0y/IBOFoJ+Ca+RHjU9dbnigH+4J8ng++mieDYXtiBoRUlAL
kTNcqyHZVok72VNyGR/PJ/DUwuUCQORWxsytkK6Ss+hUw9FwTrwKAfZZJLZZamY=
=av3J
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list

[Tracker] Article about removable volume support under minimal environment without udisks2

[Philip Van Hoof]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi guys,

Wrote this one:

http://pvanhoof.be/blog/index.php/2014/04/22/tracker-implementing-volume-management-under-a-minimal-environment

Kind regards,

Philip
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTVtR1AAoJEEP2NSGEz4aD1m0IAKiV7yEUb+6MxYz0giy+/Qfe
yZ6To9Xc7PuMho6thDdBKkOyXHc2wQwkZ6X6knhSlCntHdgzOuhGejOzQQWeorGi
eptrcUlpNRSgwiC7yBqKsJrxQjUPE/Hq0hRbRdNSCCn2yJLLoL7EiakwBhKwNoVz
tzA8BlRiTX3M4K7OSBpJcqVq2JnkJJITuir6FLqUD/Mol84GayhkCJTWisCoHVUg
WfK7rHKRXZ0/Kk58DE8V8N4fle+byfXJzTQZD+dX2rUf5mtt9IliMJ7/8wVKJXg8
MajpPOOdnMRMMkGxVXohP4ITBPu7mbkCy7ShDwgLE6stlknv5HYjV5VkGD7piN0=
=KS5W
-END PGP SIGNATURE-
___
tracker-list mailing list
tracker-list@gnome.org
https://mail.gnome.org/mailman/listinfo/tracker-list