[Tracker] nfo:hasMediaStream max cardinality change

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martyn, You have to be more careful about ontology changes: https://git.gnome.org/browse/tracker/commit/?id=6b2dff6e18bd9a9d4238557b2dce2565fea49491 Maxcardinality changes are not supported by our ontology change coping mechanism:

Re: [Tracker] REVIEW: external-crawler branch, part4

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 c5d068279c9db7ac45e577b18b38d0bcb62b1d06 + guint external_crawler : 1; /* TRUE if we're being feed files +* instead of discovering them +* ourselves */ + guint

Re: [Tracker] REVIEW: external-crawler branch, part3

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/08/2014 10:27, Philip Van Hoof wrote: b291f85416674b4b7a54cded5f6e6fe8af22d181 + if (!priv-root) { +g_object_unref (priv-root); + } Perhaps this got fixed afterwards in a later commit and I missed it, but it can't

Re: [Tracker] REVIEW: external-crawler branch, part3

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/08/2014 10:58, Philip Van Hoof wrote: On 8/08/2014 10:27, Philip Van Hoof wrote: Can you squash those two commits together before merging master? Just git rebase -i, you know the drill ;-) 8cdc0188e2c4d341e6e9788370e9381e085ae34b

Re: [Tracker] REVIEW: external-crawler branch, part1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/08/2014 10:56, Martyn Russell wrote: Yah, just fix it anyway ;-) Poor Aleksander. git blame is too good. c2863b39b4e8f178c4d87ceee5d96ad0c3647585 if (fs-priv-item_queue_blocker) { trace_eq ( cancelled: item queue blocked waiting for

Re: [Tracker] REVIEW: external-crawler branch, part4

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/08/2014 11:11, Martyn Russell wrote: On 08/08/14 09:54, Philip Van Hoof wrote: It will mess up your alignment and padding and that makes future API changes more difficult. You'll need to know how the bit fields will happen on each

Re: [Tracker] REVIEW: external-crawler branch, part1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/08/2014 10:56, Martyn Russell wrote: On 08/08/14 08:58, Philip Van Hoof wrote: Reply inline below. e5b5280b5f336b80b00d9c9671a72391ab1f0a9b +data-dbus_path = g_strdup_printf (/%s, dbus_name); + +p = data-dbus_path

Re: [Tracker] nfo:hasMediaStream max cardinality change

is being used by the N9, Jolla and a few other users. I think Pelagicore too for example -- or they should be). Kind regards, Philip On 8/08/2014 10:38, Philip Van Hoof wrote: Martyn, You have to be more careful about ontology changes: https://git.gnome.org/browse/tracker/commit/?id

Re: [Tracker] nfo:hasMediaStream max cardinality change

Russell wrote: On 08/08/14 10:55, Philip Van Hoof wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 How to implement this would go like this: Hi Philip, Thanks for the email here, allow me to respond :) - - Detect the change with nao:lastModified and the existing introspection

Re: [Tracker] Fear and Loathing in Las Vegas

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/09/2014 15:50, fr33domlover wrote: Hi Freedom lover, I think it can be useful, here's an example: Assume you have Tracker installed, and you want to install some photo album manager which has a tendency to find your photos and upload to the

Re: [Tracker] Proposed future for Tracker - Smaller modules

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/09/2014 12:34, Martyn Russell wrote: Hi Martyn, Module = tracker-store - ontology (database schema) - libstemmer (stemming library used by libtracker-fts) - libtracker-common (type and various utilities) - libtracker-data (database access

Re: [Tracker] Proposed future for Tracker - Smaller modules

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/09/2014 17:11, Martyn Russell wrote: Hi Martyn, My proposal would be to keep tracker-store, ontology and libtracker-sparql together (as one project). The reason I didn't put libtracker-sparql with tracker-store / core things is that

Re: [Tracker] Proposed future for Tracker - Smaller modules

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/09/2014 18:54, Martyn Russell wrote: On 08/09/14 17:46, Philip Van Hoof wrote: [cut] No reason. libtracker-sparql users shouldn't care. Off the top of my head: 1. To provide a DBus interface (may be a legacy reason, but ...) Only

Re: [Tracker] libmediaart should get a 1.x.y, it's used in production environments that need semver versioning guarantees

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/09/2014 10:09, Martyn Russell wrote: Which should by now have a libmediaart 1.0.0 and follow semver.org versioning rules, as Tracker is a production component depending on API stability of libmediaart. Yea, but Tracker wasn't 1.0.0 for a

Re: [Tracker] libmediaart bug 722795 - Saving .mediaartlocal/ dirs everywhere

to be writing to his removable devices. We should be as read only to filesystems that we scan as possible. Kind regards, On 10/09/2014 11:39, Martyn Russell wrote: On 10/09/14 10:37, Philip Van Hoof wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I agree, we should just remove it. I never

[Tracker] How to use tracker:modified right

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Having been asked to review this bug, it came to my attention that the tracker:modified feature is not well understood by all. https://bugzilla.gnome.org/show_bug.cgi?id=727759 I did write it down, though ;-). Perhaps certain people ignored that.

Re: [Tracker] How to use tracker:modified right

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15/09/2014 12:43, Martyn Russell wrote: On 12/09/14 15:47, Philip Van Hoof wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Having been asked to review this bug, it came to my attention that the tracker:modified feature is not well

[Tracker] The Utopian idea, Tracker as it should be

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So on IRC ssam2 and martyn were discussing this and then asking me if what they concluded was something I agreed with. So one more time :-) My idea is this: The SPARQL Endpoint - --- o. libtracker-sparql and tracker-store get merged

Re: [Tracker] The Utopian idea, Tracker as it should be

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/09/2014 17:05, Martyn Russell wrote: o. libtracker-sparql and tracker-store get merged together. Perhaps we rename libtracker-sparql, perhaps not, perhaps it doesn't matter. o. Instances of tracker-store become managed by

Re: [Tracker] The Utopian idea, Tracker as it should be

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/09/2014 18:57, Debarshi Ray wrote: On Wed, Sep 17, 2014 at 02:16:03PM +0200, Philip Van Hoof wrote: Nepomuk separate: Sharing the ontology with KDE desktop, without GNOME's politics interfering of trying to dominate needlessly the processes

Re: [Tracker] The Utopian idea, Tracker as it should be

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17/09/2014 20:43, Ivan Frade wrote: [cut mine] Some thoughts about the ontology: 1) KDE is not using nepomuk anymore: https://community.kde.org/Baloo#Baloo.2C_Nepomuk.2C_KDE_Platform_4_and_KF5 Damned. That's because we screwed up! I

Re: [Tracker] The Utopian idea, Tracker as it should be

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21/09/2014 19:03, Ralph Böhme wrote: Hi On 21 Sep 2014, at 18:05, Vishesh Handa m...@vhanda.in wrote: I thought I should chime in. I'm currently the maintainer of Baloo in KDE, and was the maintainer of the Nepomuk project in KDE. Great!

Re: [Tracker] The Utopian idea, Tracker as it should be

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22/09/2014 12:30, Martyn Russell wrote: On 21/09/14 17:05, Vishesh Handa wrote: We, in KDE, were quite fed up with the ontologies. With Baloo, we're no longer using any ontologies. The project simple aims to be a good search The

Re: [Tracker] The Utopian idea, Tracker as it should be

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22/09/2014 15:56, Vishesh Handa wrote: [cut] Good luck with your project though Vishesh! Yes. Good luck nonetheless. Maybe someday we can outsource simple indexing of easily searchable content to Baloo? Sure. From an implementation

[Tracker] Ontology change support upgrading nrl:maxCardinality 1 to multiple

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, As many might have noticed in the changelog of 1.2.1 release we decided to revert the nrl:maxCardinality change made on 08-28. That's because this ontology change force a reindex and removal of your existing metadata. That's data loss

Re: [Tracker] Ontology change support upgrading nrl:maxCardinality 1 to multiple

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/09/2014 1:53, John Bestevaar wrote: Hi John, I do hope i am not out of order here as i am not a code person. My sympathies with your present situation and the misery of it. If you will indulge me in stating the bleeding obvious: Solving

[Tracker] Ready for review - Was: Ontology change support upgrading nrl:maxCardinality 1 to multiple

:~$ tracker-sparql -q 'select ?a ?b { ?a extra:hasThing ?b }'Results: a, b a, c pvanhoof@lenny:~$ No data loss, and it suddenly allows multiple values. Kind regards, Philip On 24/09/2014 22:32, Philip Van Hoof wrote: Hi everyone, As many might have noticed in the changelog of 1.2.1 release we

Re: [Tracker] Ready for review - Was: Ontology change support upgrading nrl:maxCardinality 1 to multiple

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/09/2014 17:00, Philip Van Hoof wrote: Hi guys It's done! I'm amazed that so soon I figured out my own old code again. Available for review and test (please do test) here: https://git.gnome.org/browse/tracker/log/?h=maxcardinality

Re: [Tracker] Ready for review - Was: Ontology change support upgrading nrl:maxCardinality 1 to multiple

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29/09/2014 12:30, Martyn Russell wrote: On 26/09/14 16:09, Philip Van Hoof wrote: Here you go, that makes reviewing easier :-) https://git.gnome.org/browse/tracker/log/?h=maxcardinality-change-support-rebased Thanks Philip, Comments

Re: [Tracker] Ontology change support upgrading nrl:maxCardinality 1 to multiple

the now supported ontology change! Kind regards, Philip On 24/09/2014 22:32, Philip Van Hoof wrote: Hi everyone, As many might have noticed in the changelog of 1.2.1 release we decided to revert the nrl:maxCardinality change made on 08-28. That's because this ontology change force

Re: [Tracker] Migrating tracker-utils/ into one 'tracker' command

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Martyn, I like this idea a lot. Would it also be possible to make tracker-$name in argv[0] to be recognized by the new 'tracker' command's command line parsing to be the same as $name in argv[1]? Then for one release we could just make symlinks

Re: [Tracker] Migrating tracker-utils/ into one 'tracker' command

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/10/2014 15:21, Martyn Russell wrote: Hi, In principal it's possible, but the question is more about where this is done. This is probably more of a packaging job than anything (other than 'tracker' itself handling it (which is trivial to

Re: [Tracker] How to use cgroups for Tracker?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/10/2014 16:35, Martyn Russell wrote: Hello all, Recently I've started looking into support for cgroups due to this bug: http://bugzilla.gnome.org/show_bug.cgi?id=737663 It was suggested I ask you guys to see what the best way forward

Re: [Tracker] [systemd-devel] How to use cgroups for Tracker?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21/10/2014 13:21, Lennart Poettering wrote: Well, looking at that bug it appears to me that this is caused because you try to use inotify for something it shouldn't be used for: to recursively watch an entire directory subtree. If you fake

Re: [Tracker] [systemd-devel] How to use cgroups for Tracker?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23/10/2014 1:03, Lennart Poettering wrote: On Thu, 23.10.14 00:52, Philip Van Hoof (phi...@codeminded.be) wrote: Don't try to work around limitations of kernel APIs by implementing inherently not scalabale algorithms in userspace. I mean

Re: [Tracker] [systemd-devel] How to use cgroups for Tracker?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23/10/2014 13:01, Lennart Poettering wrote: On Thu, 23.10.14 11:40, Martyn Russell (mar...@lanedo.com) wrote: [cut] I know it's a hard problem to solve, but if it's not solved with the proposed solutions, the kernel developers shouldn't really

[Tracker] --disable-tracker-fts doesn't compile

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi guys, Trying a build with --disable-tracker-fts apparently doesn't compile at this moment. Kind regards, Philip -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJUe5ARAAoJEEP2NSGEz4aDmcIIAKy0Qqdr+Y1iln2NF7z6xjL2

Re: [Tracker] --disable-tracker-fts doesn't compile

:1142: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/pvanhoof/repos/gnome/tracker' Makefile:867: recipe for target 'all' failed make: *** [all] Error 2 pvanhoof@lenny:~/repos/gnome/tracker$ On 30/11/2014 22:45, Philip Van Hoof wrote

Re: [Tracker] --disable-tracker-fts doesn't compile

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fixed it Reminder for people working on FTS code: please make it optional using #if HAVE_TRACKER_FTS - #endif (not #ifdef HAVE_TRACKER_FTS, #if). Kind regards, Philip On 30/11/2014 22:45, Philip Van Hoof wrote: Hi guys, Trying a build

Re: [Tracker] Location of the tracker-parser* stuff

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok. Moving/refactoring. On 1/12/2014 13:40, Aleksander Morgado wrote: On Mon, Dec 1, 2014 at 1:37 PM, Philip Van Hoof phi...@codeminded.be wrote: I wonder why tracker-parser.h and its implementation are in libtracker-fts. Apparently does

Re: [Tracker] Review request, bug fixed by a downstream integrator (Jolla)

On 22/12/2014 11:59, Carlos Garnacho wrote: Hey Philip :), On Fri, Dec 19, 2014 at 3:23 PM, Philip Van Hoof phi...@codeminded.be wrote: -BEGIN PGP SIGNED MESSAGE- https://git.gnome.org/browse/tracker/log/?h=crawler-max-depth Is this ~ what you proposed? Yup! pretty much

Re: [Tracker] Urgent - Suggestions for new major functionality - Project

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Kunaal Jain, We discussed some interesting ideas in September last year on this mailing list under the subject, The utopian idea, Tracker as it should be. https://mail.gnome.org/archives/tracker-list/2014-September/msg00030.html The discussion

[Tracker] Plan of action - Was: Urgent - Suggestions for new major functionality - Project

and more in my garden and 30m deep in the water ;-) Kind regards, Philip On 12/03/2015 12:26, Philip Van Hoof wrote: On 12/03/2015 11:27, kunaal jain wrote: I couldn't find reference to per-app databases. What exactly it is? Why do we need it? When tracker-store, libtracker-sparql

Re: [Tracker] Plan of action - Was: Urgent - Suggestions for new major functionality - Project

and groups of applications flocking to a tracker-store instance is sufficient (with Tracker's filesystem miner and the gnome-miners probably going to be the ones defining the most used such application group). Kind regards, Philip On Thu, Mar 12, 2015 at 8:34 AM, Philip Van Hoof phi

Re: [Tracker] Urgent - Suggestions for new major functionality - Project

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/03/2015 11:27, kunaal jain wrote: I couldn't find reference to per-app databases. What exactly it is? Why do we need it? When tracker-store, libtracker-sparql are bundled as one package (as libtracker-sparql for example) and data/ontologies

Re: [Tracker] Thunderbird indexing

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adrien Bustany (added in CC) once made a thunderbird indexer. I think you can find it in the history with git and/or it got moved to another project. On 20/04/2015 15:49, Eric Bangerter wrote: Dear all, is tracker be able to index thunderbird email

[Tracker] Review of wip/garnacho/sparql1.1 on gnome's git

Hi Carlos, Great work on the SPARQL1.1 support. Here is my review. 77dbe7a8847511f56563b50c65599dbfc14453ed: ok 23109a5c8744d057cff19ee6f767314a4a761ebd: ok 3a0f7a8317f0b8c97bd3c7305bf5386484a027b9: ok 18fe5f9c04a433d7a11cfff255893956f4383b0c: ok d4869094aa0b1a76acc384ec7a7a352fe8b79abe: ok

Re: [Tracker] Fwd: tracker 1.6.0

The sparql 1.1 support didn't make it? On Tue, 2015-09-22 at 14:55 +0200, Carlos Garnacho wrote: > -- Forwarded message -- > From: Carlos Garnacho > Date: Tue, Sep 22, 2015 at 2:54 PM > Subject: tracker 1.6.0 > To: FTP Releases

Re: [Tracker] Memory usage for tracker-extract and tracker-miner-fs

; > > valgrind --leak-check=full --log-file=valgrind-log --num-callers=30 > > /path/to/built/tracker-extract > > > > Hit ctrl-C when enough time has passed, and send back the valgrind-log > > file. Same applies to tracker-miner-fs. > > > >> > >> My tra

Re: [Tracker] Memory usage for tracker-extract and tracker-miner-fs

ter branch I can't seem to get built. > > This is on CentOS 7.1, BTW. > > I'll give 7.1.2 a try. Hopefully that will compile successfully. > > Cheers! > -Joe > > > On Jan 12, 2016, at 6:09 AM, Philip Van Hoof <phi...@codeminded.be> wrote: > > > >

Re: [Tracker] Memory usage for tracker-extract and tracker-miner-fs

2 and give that a try. I can only work > on this in the evenings when I'm not at work and the server thats housing all > of this data is otherwise not terribly busy. > > Cheers! > -Joe Rhodes > > > > > > On Jan 11, 2016, at 5:21 AM, Philip Van Hoof <phi...@codeminded.be>

Re: [Tracker] Memory usage for tracker-extract and tracker-miner-fs

On Mon, 2016-01-11 at 11:51 +0100, Carlos Garnacho wrote: Hi Carlos, > > > > Looks like my git-account has been closed on GNOME, so here is a patch > > for one of the issues in that valgrind. > > Thanks! The patch is now in master and previous stable branches. Ok, thanks for pushing it for me.

Re: [Tracker] Memory usage for tracker-extract and tracker-miner-fs

On Mon, 2016-01-18 at 12:57 +0100, Carlos Garnacho wrote: > As expected, the valgrind logs are a lot more favorable. > Tracker-extract reports: > > ==21759==definitely lost: 168 bytes in 1 blocks > ==21759==indirectly lost: 6,046 bytes in 2 blocks > > And those seem to be a memory pool

Re: [Tracker] Memory usage for tracker-extract and tracker-miner-fs

; > On Jan 21, 2016, at 7:14 AM, Philip Van Hoof <phi...@codeminded.be> wrote: > > > > On Thu, 2016-01-21 at 07:07 -0500, Joe Rhodes wrote: > >> Carlos: > >> > >> Here are the numbers as requested: > >> > >> tracker status -a |

Re: [Tracker] Tracker and sandboxed applications

On Fri, 2016-01-29 at 11:33 +0100, Sam Thursfield wrote: Hi Sam, > We had a discussion at the 2016 Developer Experience hackfest related > to sandboxing apps that use Tracker. Sounds interesting! I heard of several companies in automotive and TV setup box industries using Tracker in lightweight

Re: [Tracker] Memory usage for tracker-extract and tracker-miner-fs

On Thu, 2016-01-21 at 07:07 -0500, Joe Rhodes wrote: > Carlos: > > Here are the numbers as requested: > > tracker status -a | grep -e "nfo:Folder" -e "nfo:FileDataObject" > nfo:FileDataObject = 1704170 > nfo:Folder = 286147 About 300 MB VmRSS for 1,704,170 and 286,147 directories. That's

Re: [Tracker] Memory usage for tracker-extract and tracker-miner-fs

On Thu, 2016-01-21 at 14:02 +0100, Carlos Garnacho wrote: > > Yeah, afair the problem with Apples Spotlight RPC protocol is that it > > has no way returning results in chunks and tell the client to come > > back immediately for more results. > > > > Apples Spotlight RPC server simply puts *all*

Re: [Tracker] Extracting the extractors

Hi Sam, The way to transfer metadata over a well defined standard way is called Turtle (TTL, https://www.w3.org/TR/turtle/). SPARQL is a query language that utilizes portions of this spec (with SPARQL INSERT you can more or less put a TTL block inside of INSERT{} and it should just work. Our

Re: [Tracker] Extracting the extractors

Hi Sam, So, what happens when I read a blog like this, and I find this: Decision 3: Kick RDF in the Nuts RDF is a shitty data model. It doesn’t have native support for lists. LISTS for fuck’s sake! The key data structure that’s used by almost every programmer on

Re: [Tracker] Tracker presentation at NLGG

t expected. Kind regards, Philip On Fri, 2016-03-18 at 21:06 +0100, Philip Van Hoof wrote: > Hello, > > I should have announced this earlier, but I was damn busy with work & > co* at my customer Heidenhain. Mostly writing QAbstractItemModel models; > something we appare

[Tracker] Tracker presentation at NLGG

Hello, I should have announced this earlier, but I was damn busy with work & co* at my customer Heidenhain. Mostly writing QAbstractItemModel models; something we apparently all end up doing one way or another eventually. After FOSDEM this year, I apparently bragged too much about Tracker or

Re: [Tracker] tracker-1.8 branched

Hey Carlos, I noticed we are sometimes doing parallel releases. Have you ever considered using gitflow as branching technique? With gitflow you have a develop and a master branch. When making a feature release you branch it of develop and then when the release is made you merge the release to

Re: [Tracker] Extracting the extractors

Hi guys, Note to Sam and Cosimo that if his becomes a API used by external users, that it will in time have to follow API rules. These include not only not breaking API unless incrementing the major version numbering (which is something you shouldn't do every other week) but also things like

[Tracker] Domain ontologies

Hello guys, I just pushed a feature branch called domain-ontologies. It's a first attempt at providing the infrastructure for making it possible to have domain specific ontologies. First part is adapting the tracker_data_manager_init to have parameters domain and ontology_name. The idea would

Re: [Tracker] Domain ontologies

, not a good design or a indented concept in tracker-store's code - so you can and should just fix this if you feel like doing so). Kind regards, Philip On Thu, 2017-01-26 at 22:44 +0100, Philip Van Hoof wrote: > Hello guys, > > I just pushed a feature branch called domain-ontologies. It'

Re: [Tracker] Domain ontologies

On Tue, 2017-02-14 at 23:53 +, Sam Thursfield wrote: [cut] > > And I guess flatpak can specify which flatpak has rights to which > > domain-ontology, so that the libtracker-sparql clients running in that > > flatpak can access the right files and directories and DBus paths and > > services

Re: [Tracker] Fwd: tracker 1.11.1

Thank you Carlos. Great work :-) xxx On Mon, 2016-11-21 at 16:34 +0100, Carlos Garnacho wrote: > Codenamed "I hate mondays" > > > -- Forwarded message -- > From: Carlos Garnacho > Date: Mon, Nov 21, 2016 at 4:28 PM > Subject: tracker 1.11.1 >

Re: [Tracker] The Big Rip

Most of this sounds good to me Carlos. I'll reply inline On Fri, 2016-10-28 at 14:34 +0200, Carlos Garnacho wrote: > Hi all, > > It is well known that Tracker has been accumulating lots of code and > features over the years, with greatly varying states of maintenance. > There's been earlier

Re: [Tracker] Fwd: tracker 1.11.2

On Fri, 2016-12-09 at 00:44 +0100, Carlos Garnacho wrote: Hello Carlos, NO criticism on the content of the releases and the technical improvements, nor on the communication on the security bug and panic of certain people. Just some remarks on versioning here. > * tracker-extract: Sandbox

Re: [Tracker] Fwd: tracker 1.11.2

On Sat, 2016-12-10 at 15:52 +, Sam Thursfield wrote: > > - Double checking ontology migration code, ensure it can handle weird > > ontology changes more or less elegantly. > > sounds good, but is this actually possible? I thought we found that it > was too hard to really do this well, and

Re: [Tracker] Fwd: tracker 1.11.2

On Sat, 2016-12-10 at 16:36 +0100, Carlos Garnacho wrote: [cut] > I however think going from "odd minor number is unstable" to semver > versioning with minor!=0 is going to be confusing... Yes, changing it in the middle of a major release number is perhaps not the brightest idea. True. > I

Re: [Tracker] Fwd: tracker 1.11.2

On Sun, 2016-12-11 at 17:07 +0100, Carlos Garnacho wrote: [cut] > >> - Getting as close to supporting the full sparql 1.1 spec as possible > >> in libtracker-data: > >> * property paths: last weekend got halfway with this \o/ > >> * graph management: for DROP GRAPH I think triggers will

Re: [Tracker] Referential Integrity (Was: Re: Fwd: tracker 1.11.2)

On Wed, 2016-12-21 at 14:29 +0100, Carlos Garnacho wrote: Hello Carlos, > > Personally think some sort of reference counting will be needed for > > anonymous nodes references by different graphs.. > > It's not as much reference counting as it is a "weak pointer" what we > want here, no? i.e. we

Re: [Tracker] Fwd: tracker 1.12.0

Hey Michael Biebl, I guess that people don't know that they need a file called liblibrary-version.pc, is what might be the real thing we learned here (if anything). Unfortunately, because we devs are morons that can't agree on anything, it could also be library.pc, library-version.pc,

Re: [Tracker] Meson build instructions for Tracker

On Sun, 2017-04-09 at 18:54 +0200, Michael Biebl wrote: > > Hmmrr. Patching .c files generated by valac sounds absurd. Is there ever > > a circumstance where you want to do that instead of patching the .vapi > > or .vala file? Because if you do, that sounds like a bug in valac > > instead. >

Re: [Tracker] Meson build instructions for Tracker

+0200, Michael Biebl wrote: > 2017-04-09 19:31 GMT+02:00 Philip Van Hoof <phi...@codeminded.be>: > > I wonder if removing those .stamp files should be part of any > > make-target that is ~ standard for packaging tooling? In my opinion > > should such generated .c files

Re: [Tracker] Meson build instructions for Tracker

I wonder if removing those .stamp files should be part of any make-target that is ~ standard for packaging tooling? In my opinion should such generated .c files share the rules of .o files. On Sun, 2017-04-09 at 19:28 +0200, Michael Biebl wrote: > 2017-04-09 19:04 GMT+02:00 Philip Van Hoof &

Re: [Tracker] Meson build instructions for Tracker

On Fri, 2017-03-31 at 00:32 +0200, Michael Biebl wrote: > You are right, there is indeed an issue with valac and reproducible builds: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802528 > > I guess this should be fixed in vala proper though. nod. > Personally, I'm not a huge fan of

Re: [Tracker] (tracker-extract:3603): dconf-CRITICAL

On Tue, 2017-02-28 at 08:33 -0600, Chris wrote: > On Tue, 2017-02-28 at 09:10 +0100, Jean-Christophe Baptiste wrote: Hello Chris, You asked a question about how to do something a Tracker developer (more specifically the Debian packager) asked you to do for debugging purposes. Presumably to find

Re: [Tracker] Fwd: tracker 1.99.0

On Thu, 2017-07-06 at 12:20 +0200, Carlos Garnacho wrote: > * Domain ontologies: it is now possible to create domain-specific SPARQL > endpoints with customizable ontologies and data locations. It is possible > to do so either in-process using the traditional Tracker daemons to > do

Re: [Tracker] domain-ontologies, continued

to be quite minimal, eg. no r/w access to the user homedir > whatsoever. > > > On Sun, Jun 11, 2017 at 7:19 PM, Philip Van Hoof <phi...@codeminded.be> wrote: > > On Tue, 2017-06-06 at 20:42 +0200, Carlos Garnacho wrote: > >> Hey hey, > >> > >> Duri

Re: [Tracker] Heads up: tracker has been split in two

Hello Carlos, Great, this 'split' together with the domain ontologies will make it now more easy to more widely deploy Tracker's SPARQL endpoint in all sorts of environments. That includes containers, infotainment systems, desktops and ... who knows what the spooks and the people will come up

Re: [Tracker] wip/carlosg/resource-leak-fix merged

Fantastic news that this finally works. Thanks a lot, Carlos! On Sat, 2017-08-05 at 23:27 +0200, Carlos Garnacho wrote: > Hi!, > > I've just been merged wip/carlosg/resource-leak-fix on master. For > some background, the URNs generated in the Resource table had no > clear > lifetime, so Tracker

Re: [Tracker] No updates on File System %

Crawling is not CPU bound, but I/O bound. You should not have a lot of CPU utilization. You can configure Tracker to select which top level folders to crawl. On Fri, 2017-06-16 at 09:03 +0100, Björn Johansson wrote: > Hi and thanks for the answer. So tracker goes through *all* files at > each

Re: [Tracker] domain-ontologies, continued

On Tue, 2017-06-06 at 20:42 +0200, Carlos Garnacho wrote: > Hey hey, > > During the past week I've been continuing the stuff that Philip > started on wip/domain-ontologies. I pushed my current progress on > wip/carlosg/domain-ontologies: > >

Re: [Tracker] Fwd: tracker 2.0.0

Party! Great work Carlos. On Tue, 2017-09-12 at 13:07 +0200, Carlos Garnacho wrote: > Let's rejoice! One thing I forgot to mention in the notes... meson > build still can't build from tarballs, autotools remains in parallel > for obvious reasons. > > > -- Forwarded message

Re: [Tracker] tracker constantly crawling

Ok, I suppose you could contribute a FAM backend for tracker-miner-fs then. Wouldn't be bad to have support for multiple kinds of file- monitoring. On Thu, 2017-11-30 at 09:37 -0500, Brian J. Murrell wrote: > On Thu, 2017-11-30 at 15:26 +0100, Philip Van Hoof wrote: > > Hello Brian

Re: [Tracker] tracker constantly crawling

On Thu, 2017-11-30 at 14:21 -0500, Brian J. Murrell wrote: > On Thu, 2017-11-30 at 19:46 +0100, Philip Van Hoof wrote: > > Ok, I suppose you could contribute a FAM backend for tracker-miner- > > fs then. Wouldn't be bad to have support for multiple kinds of > > file-monitori

Re: [Tracker] tracker constantly crawling

Hello Brian, FAM is for intercepting syscalls like open I believe. This is what virusscanners need. Tracker uses inotify at this moment. With the Linux kernel there is no way to monitor a root of a filesystem other than registering each and every directory (which is what crawling is for). One

Re: [Tracker] tracker constantly crawling

On Fri, 2017-12-01 at 09:50 +, Debarshi Ray wrote: Hello Debarshi Ray, > > The answers to your original question are: no it never had FAM > > support, > > and no that doesn't sound like expected behavior. > > Tracker uses GLib's GFileMonitor API these days, which has various >

[Tracker] The PDF extractor and OCR

Hey us, the people who made Tracker, First time in my life I actually used the same software I worked on a few years ago. I bought myself a Medion laptop and cheap as it is, it of course spontaneously broke. So I had to find the invoice and other documents for it, so that I could bring it back to

Re: [Tracker] The PDF extractor and OCR

otal 0 (delta 0), reused 0 (delta 0) To github.com:pvanhoof/tracker-gnome.git * [new branch] master -> master pvanhoof@lars:~/repos/gnome/tracker-miners$ On Sat, 2018-02-24 at 12:33 +0100, Philip Van Hoof wrote: > Hey us, the people who made Tracker, > > First time in my li

[Tracker] Making Tracker somewhat work on Ubuntu 18.10

Hello all, To make Tracker somewhat work on a Ubuntu 18.10 (Cosimo), you currently need these packages from Disco: gir1.2-tracker-2.0_2.1.8-1_amd64.deb libexempi8_2.5.0-2_amd64.deb libicu63_63.1-6_amd64.deb libnautilus-extension1a_3.31.90-1ubuntu2_amd64.deb

[Tracker] Doing it right, please review me

Hello Tracker, Having been a maintainer of a ?popular? GNOME package I was obviously ideological about autotools. Not no much any more. Of course has autotools been replaced by Meson. I always tried to figure, however, 'the right way'. Then someday, I looked at my /usr/lib directory. Few people

Re: [Tracker] GSOC

On Wed, 2019-05-08 at 01:00 +0200, Carlos Garnacho wrote: > On Tue, May 7, 2019 at 12:26 AM Mahmoud Nagy via tracker-list > wrote: > > I wasn't selected from tracker as gsoc member, if possible can you > > provide some feedback to learn more from the experience. > > I'm afraid that is not

Re: [Tracker] Formatting code automatically with Uncrustify

Hello, It used to be that we were as a development team quite against this, as you could loose some of the capabilities of git-blame (which we used). The rule we had was that we'd change formatting around the code that we were changing. And gradually we would be changing the code-style.

<    1   2   3   4   5