Install tracker by default

[Jeremy Bícha]

Benefits
========

1. It speeds up searching for files in the Files app.

2. It enables full-text search in the Files app. In other words, you can look for files that contain specific words, instead of searching just by filename.

3. It allows the Batch Rename feature in the Files app able to rename based on file metadata. For instance, you can use the Artist name for properly tagged music files as part of the new file name.

4. It enables file and folder search in the Activities Overview on GNOME. Without tracker, this is a functional regression from Unity and is noticed by a lot of people.

Other Info
----------
You can customize the folders it indexes from Settings > Search > gear button. (LP: #1702878)

How to Install
==============
Until this is installed by default, you can install it yourself. Run this command in a terminal then log out and log back in (LP: #1697769):

sudo apt install tracker

Original Bug Report
===================
For Nautilus' built-in search to not be very slow, Nautilus needs to use tracker for search.

This is especially important since it's being seriously proposed for Ubuntu 17.10 that we drop the "type-ahead search" patch that reverted the removal of that feature by Nautilus years ago. (LP: #1666681)

To not cripple Ubuntu GNOME, it was previously decided to let Nautilus build against tracker but not use that functionality on Unity. See this patch:

https://bazaar.launchpad.net/~ubuntu-desktop/nautilus/ubuntu/view/head:/debian/patches/ubuntu_tracker_only_on_GNOME.patch

This bug is requesting that patch be dropped and the extra tracker components be allowed into main and installed by default in Unity.

[Khurshid Alam (khurshid-alam)]

What about zeitgeist. Other things integrated with zeitgeist. So we run tracker indexing service only to recursive search in nautilus?

[Carlos Garnacho (carlosg)]

With my obvious tracker maintainer bias, I support the move. Tracker has been slowly but steadily improving in stability throughout the 1.x series, the common complains about CPU and logging have decreased as well from where I stand. Although I also suggest you have a look at the settings and see if vendor overrides might make sense for your users.

Tracker is heading now to 1.12.x which according to the current plan will be the last 1.x release series (in preparation for 2.x), it will remain feature frozen but still open to stability and performance improvements.

Khurshid: zeitgeist and tracker have little in common. Zeitgeist is about activity tracking, Tracker for these purposes is a filesystem indexer. The usecase being discussed here is nautilus indeed, but having tracker by default could make other gnome apps that strongly rely on Tracker work on Unity, like gnome-music or gnome-documents.

[Carlos (csoriano)]

Khurshid: I think deciding one or the other is tangential, they are just two different tools both necessary for the default core experience of Ubuntu. One is necessary for Unity 7, the other is necessary for Nautilus (and other GNOME apps/tools).

[Jorge Castro (jorge)]

Hi Jeremy/Carlos, thanks for working on better search for Nautilus, we've needed this for a long time. I have some questions!

- What does an upgrade look like? Let's say I have a home directory with gigs of data, when I accomplish an upgrade to 17.10 when/how does indexing take place? Is this something that happens in the background or during a package installation? Is indexing a long process? Is it something we need to display to the user? Is it one of those things where we'll need to inform users in the release notes that an expensive io operation will take place as part of the upgrade?

- In the past I recall having to modify inotify handles for performance, at some point the default handles we set in ubuntu would run out and search wouldn't work well at all. Since that was years ago I'm assuming these sorts of issues have been sorted out?

Thanks!

[Carlos Garnacho (carlosg)]

Hey Jorge, some answers, for the same definition of "some" :P

- What does an upgrade look like? Let's say I have a home directory with gigs of data, when I accomplish an upgrade to 17.10 when/how does indexing take place?

Indexing would take place when the services have been started on the user session, presumably started by the install scripts, or on session restart. tracker-miner-fs has a configurable timeout (defaults to 15s) to avoid I/O during session startup, as it's already pretty high at that time.

- Is this something that happens in the background or during a package installation?

All indexing happens in the background, on startup tracker-miner-fs performs an initial crawling where it 1) sets up directory monitors and 2) ensures its idea of the FS is up-to-date (eg. there's not been changes between reboots).

After that, tracker-miner-fs just listens to directory monitor events and updates its DB, subdirectories newly added to recursively indexed folders would be crawled in a similar way when discovered. And same for local mounted volumes, although we don't index those by default.

Indexing is also influenced by AC adapter/battery state and configuration, it reduces to a crawl or pauses altogether given the right conditions.

- Is indexing a long process?

It depends, Tracker only indexes XDG folders (and $HOME non-recursively) by default, so indexing depends on the amount of files/directories and I/O throughtput. There's of course worst cases like multi-TB 2500rpm HDDs with millions of files, but on more average setups tracker-miner-fs should take the order of seconds. A somewhat favorable example, reindexing from scratch ~8K items take tracker-miner-fs ~2s on this ssd-powered laptop.

But tracker-miner-fs only manages FS-level information, the isolated tracker-extract process performs the actual content sniffing, and the time spent there is variable too per mimetype, eg. heavy PDF documents might take poppler several seconds each, while plain text files could be handled in the ballpark of hundreds per second.

Oh, and there's also file/dir name pattern matching to cut down uninteresting portions of the filesystem, tracker-miner-fs eg. tries to avoid git repos, uncompressed tarballs and whatnot.

- Is it something we need to display to the user?

It's your call really... gnome doesn't bother for example. Some apps like gnome-music do track activity and show a "Loading..." in-app banner, but little else.

- Is it one of those things where we'll need to inform users in the release notes that an expensive io operation will take place as part of the upgrade?

It's maybe wise to do that, it will churn a few extra cycles globally.

- In the past I recall having to modify inotify handles for performance, at some point the default handles we set in ubuntu would run out and search wouldn't work well at all. Since that was years ago I'm assuming these sorts of issues have been sorted out?

I assume so, tracker is admittedly greedy with inotify handles, but there's been for quite some time now the runtime checks for the user limit, leaving also some room for other apps wanting file monitors.

If with the big slice of handles that Tracker t...

[Martin Pitt (pitti)]

So all of this tells me that tracker isn't a replacement for typeahead search. They have two entirely different use cases:

 * Typeahead search only affects the currently displayed directory (or should anyway -- you search through what you see, not through the entirety of the file system). It is fast as it's only one readdir(), and nautilus already did that as it's displaying at least the first portion of the directory and there is no need to stat() the individual files. It also needs to be instant and correct even when I just copied a large directory from somewhere else or am looking at a remote sftp/cifs directory, and work everywhere.

 * Tracker imposes a huge cost due to always indexing everything (even if you never search for it). It's good for tasks like "where did I put my files last week". However, it is necessarily only approximate, as it has some delay (which can be quite large if you are on battery, or just copied a large bunch of files), and not universal (non-XDG directories, remote file systems), etc.

So I don't see how "enable tracker" can ever be a replacement for typeahead search, and TBH I still don't buy that we have to penalize each and every installation with the tracker overhead even though most people don't do full-hard disk searches all the time (and many don't do this at all). And if you do need a "search through my home dir", you *still* need to do an actual search due to the latency/approximative nature of indexing. It's not an acceptable answer to say "sorry, we don't show the file you just downloaded as we didn't get to indexing it yet".

I see tracker as a nice opt-in (!) feature for people who often do full searches, so this might become a checkbox in the search box?

[Carlos Garnacho (carlosg)]

Hi Martin,

You're right. Tracker is not a replacement for type-ahead search, reducing tracker to this would be far too simplistic.

Using Tracker is however a technical decision adopted by the nautilus team, they use it in a way that doesn't even attempt to be functionally equivalent to type-ahead search. As I see it, Ubuntu has two choices:

1) Investing time/resources in updating a patch that will get bigger and trickier to rebase over time, with the downside of possible stability issues ending up in the wrong bug reporting system, being ignored or not addressed properly, and generally frustrating users.

2) Getting closer to upstream, which means accepting additional processes to get your files indexed in the background and best-effort latency upon filesystem changes, and getting a more versatile search in return.

Whatever the decision is, and as far as I'm personally concerned, by all means be my guest :)

[Carlos (csoriano)]

Hey Jorge,
great questions! Carlos Garnacho answered pretty well.
Nautilus doesn't really need to display that we are indexing the files or so, since it's done in low priority it will be done when it's done. The user shouldn't see a performance issue with that (if the kernel scheduler works as intended).

Hey Martin,
"So all of this tells me that tracker isn't a replacement for typeahead search."
No, tracker is an indexing tool that Nautilus uses.
"Typeahead search only affects the currently displayed directory"
Yeah, with tracker and the latest improvement in Nautilus search I think it fulfils this use case (+ the whole recursive search use case of course).
"Tracker imposes a huge cost due to always indexing everything"
As long as is low priority and the kernel scheduler works fine it shouldn't be an issue.

"So I don't see how "enable tracker" can ever be a replacement for typeahead search"
Maybe I was not clear enough in my first post. (don't mean to be rude, just clear) Tracker is needed for search in Nautilus. Period. Then, one of the use cases of Nautilus search is searching an item in the current directory, which the result is quite close to type-ahead (with the latest UI improvements we did for this specific use case).

"I see tracker as a nice opt-in"
No, not really. We rely on that not only for fast searches but also for:
- Showing part of the text of the files you are searching for (Planned feature, although we already rank the files by that too)
- Advanced search by filters and UI (Already in there)
- Advanced search by tags and UI (Planned feature)
- Batch renaming tool. Is required for all the metadata, artist name and album for musics, Camera device for the pictures etc. (Already in there, quite sad Ubuntu won't be able to use the new batch renaming dialog we implemented)

We rely on an indexing tool for a modern application and good experience and for any feature we are planning to introduce. Even if Ubuntu decide to enable type-ahead with a downstream patch, an indexing tool for Nautilus will still be necessary and is far broader than just fulfilling the type-ahead use case. It's needed for the type-ahead case, but by far it's not the only thing it's needed for, and unfortunately is becoming a burden maintenance to have the indexing tool optional in Nautilus.

The indexing tool we decided to use and work for us is Tracker. I don't really care using something different if in a future there is a better indexing tool that provides us with the same features and maintainability and interaction with upstream. But the reality now is this one.

I agree with Carlos Garnacho though, personally I'm completely fine with either decision, I just think we are in a lose-lose situation, and would love to fix it in a not very complex way :)

[Carlos (csoriano)]

Just adding few more comments I missed:
"sorry, we don't show the file you just downloaded as we didn't get to indexing it yet".
True. We do a regular search in parallel for this case, which unfortunately involves lot of I/O. The point is this to be the less common case, we are lucky enough that is usually this way with XDG_FOLDERS working pretty well for the regular user use.
In an ideal world we would have better kernel inotify and all indexed, I'm really looking forward to see this happen, but it's not the current reality.

"remote file systems"
In those cases and we show a warning and we only search in the current folder by default. An indexing tool is useless here and will always be (maybe we could take a look at this somehow? Not sure how invalidation would work).

"even though most people don't do full-hard disk searches all the time"
I have the complete opposite experience/opinion. Maybe they don't because they don't use tracker + Nautilus and therefore full hard disk searches are kinda useless?
I found out most of people using Nautilus + Tracker use the full hard disk search, rather than setting the option to only do in the current folder, as it's usually more convenient to just search rather than navigate.

Hope is clearer now.

[Martin Pitt (pitti)]

Carlos [2017-02-28 12:08 -0000]:
> "Tracker imposes a huge cost due to always indexing everything"
> As long as is low priority and the kernel scheduler works fine it shouldn't be an issue.

This isn't true. This will use a lot more CPU and disk cycles, thus decreasing
battery life. Or, if you don't index while on battery, it's going to be even
less reliable.

> "So I don't see how "enable tracker" can ever be a replacement for typeahead
> search" Maybe I was not clear enough in my first post. (don't mean to be
> rude, just clear) Tracker is needed for search in Nautilus. Period.

That's the bit I'm totally not convinced of. Due to it's "background/async"
nature, it's not reliable for searching, and it's also way too much overhead to
replace a single-directory level search (i. e. what you usually do for
typeahead search). Doing a fully recursive search is okay to be slow, as that's
only being used seldomly, and if you do it you most probably want the results
to be correct, not approximative.

So my (very subjective) opinion is that any indexing tool is not an appropriate
backend for searching. This isn't particularly tracker's fault, it's just the
nature of what an indexer is. Also, note that I'm not speaking authoritatively
for the Ubuntu desktop team, this is just my personal opinion. I would just not
appreciate it to see getting an indexer imposed onto everyone for rare use
cases (like content-based batch renaming) -- optimize for the common case
instead. As I said, if you care about content preview etc., it's still fine to
give users an opt-in into this.

[Carlos (csoriano)]

Hey Martin,

Just wanted to mention I disagree with your statements and that I have the opposite experience and feedback from users (we agree we disagree, which is fine of course :)).

[Martin Pitt (pitti)]

Hello Carlos,

Carlos [2017-02-28 13:58 -0000]:
> Just wanted to mention I disagree with your statements and that I have
> the opposite experience and feedback from users (we agree we disagree,
> which is fine of course :)).

Yep :-) (I'm not making the call anyway). Thanks for sharing your
perspective (e. g. both techies and non-tech people I know don't use full
search, so interesting to read what other people use it for).

[Carlos (csoriano)]

A clarification thanks to Jeremy Bicha asking about this.

Tracker is not needed for a fast search in the current directory. We do that apart with the cache already in Nautilus. So the type ahead use case for adding tracker can be dismissed.

For now, Tracker is for everything else I mentioned (and the features we are planning to add in a future).
I'm thinking of removing the optional dependency for 3.26 upstream and require tracker due to the plans we have in mind for next release and the burden of maintainability that is having this optional dependency, both in code maintainability (ifdefs), testing, reproducibility and default experience we want for the app.

I'm open to discuss this with distros that do not enable tracker by default right now like Ubuntu, etc. (so I guess what we are doing in this bug report), because once I remove the optional dependency I'm pretty sure nobody will want to make a patch to make it optional or remove tracker downstream, it would be too hard.

[Doug McMahon (mc3man)]

I would suggest you put up a test ppa for use in an ubuntu session & see how it shakes out. The sooner the better as currently 17.04 installs are cheap & disposable.

As far as type-ahead, the main attraction wasn't current dir. only, it's that it searched/returned 1st character on exactly where as gnome search does anywhere in the filename exactly. (at least current gnome search in ubuntu session.
Users will miss that if the new search doesn't do, but such is progress.

[Jeremy Bícha (jbicha)]

Doug, nautilus 3.23.90 with the typeahead patch disabled is in the GNOME3 Staging PPA for zesty.

To try nautilus with tracker, make sure 'tracker' and 'tracker-miner-fs' are installed.

Then you can try to run these comamnds:
pkill nautilus
XDG_CURRENT_DESKTOP=GNOME nautilus

[Jeremy Bícha (jbicha)]

To summarize, I see 2 performance questions:

- Initial indexing (How long does it take? Does it make the computer noticeably less responsive?)
- Search (Is search in Nautilus more or less responsive with tracker? How noticeable is the difference?)

[Martin Pitt (pitti)]

> To summarize, I see 2 performance questions:

I'd add:

 - Is it acceptable to have approximate search results if the indexing isn't (yet) up to date?
 - Does it significantly affect battery life?

[Carlos Garnacho (carlosg)]

Hey Jeremy,

- Initial indexing (How long does it take? Does it make the computer noticeably less responsive?)

I already tried to reply this to Jorge, it does depend. Depends on the amount of files and disk throughput.

- Search (Is search in Nautilus more or less responsive with tracker? How noticeable is the difference?)

Full-text search in Tracker is fairly optimized, plain FTS queries usually take ~30-50ms across multiple thousands of indexed documents. This is fast enough for search-as-you-type as nautilus uses it, and definitely faster than the recursive filename matching paths.

Hi Martin,

- Is it acceptable to have approximate search results if the indexing isn't (yet) up to date?

If tracker-miner-fs is not paused/throttled down, it will pick up changes in monitored folders just as fast as any other app, there is very little extra overhead above the gio/inotify delays.

- Does it significantly affect battery life?

Given Tracker is pretty conservative while on battery, that's a bold "no".

However "acceptable" or "significant" something is is entirely in the eye of the beholder. It's not news that there's a trade off between instantness and cpu/battery, Tracker can't get the best of both worlds at the same time.

[Carlos Garnacho (carlosg)]

- Initial indexing (How long does it take? Does it make the computer noticeably less responsive?)

I realize I might have not replied to the "responsiveness" bit. Given Tracker miners set up themselves with low scheduler/io priority and high niceness, I expect it to have little impact in perceived responsiveness.

[Carlos (csoriano)]

Hey Doug,

"it's that it searched/returned 1st character on exactly where as gnome search does anywhere in the filename exactly"

That's actually a quite good insight, and we can definitely implement it making higher the "search hit score" to those files that has the characters positioned in the right place so the result will be in the same order as type-ahead (given that no other search factors are involved like filters, FTS etc.). It's actually an easy fix (related code https://git.gnome.org/browse/nautilus/tree/src/nautilus-query.c#n357)

Can you report a bug and I will take care of this?

[Martin Pitt (pitti)]

Carlos Garnacho [2017-03-01 10:59 -0000]:
> > - Is it acceptable to have approximate search results if the indexing isn't (yet) up to date?
>
> If tracker-miner-fs is not paused/throttled down, it will pick up
> changes in monitored folders just as fast as any other app, there is
> very little extra overhead above the gio/inotify delays.

> > - Does it significantly affect battery life?
>
> Given Tracker is pretty conservative while on battery, that's a bold "no".

It's hard to make these statements simultaneously be true. There's clearly a
trade-off between correctness and efficiency here. Unless nautilus pokes
tracker to wake up and do a shallow (no previews, etc.) index/force-refresh the
searched-for directory unthrottled right away? Then that would be the
equivalent of a "classic" search, except that the gained data would be
available in the tracker DB for the next time.

[Carlos (csoriano)]

Hey Martin,

It's just an inotify monitor. Read how that works, you will see what's the performance (close to zero, and everyone uses them, not just tracker).

Don't take it bad please, but I wouldn't like to spam this bug report more, we should settle down on basic knowledge about how the kernel inotify and file system works and its implications and impact on performance.

Hmm I think there is nothing more new to discuss in this bug report so far, looking forward to more questions/feedback.

[Jeremy Bícha (jbicha)]

Hi, here's a quick update. Nautilus 3.24 is in Ubuntu 17.10 Alpha now. I dropped ubuntu_tracker_only_on_GNOME.patch because it does not make sense any more (it enabled some features based on whether GNOME was the current desktop).

Nautilus does have several features that will only work if tracker is installed. The biggest 2 features for Ubuntu I see are:
- File search in GNOME Shell's Activities Overview (GNOME's equivalent of Unity's Dash)
- I'm told that search is much, much faster in indexed directories and that people will complain that search is slow after removing type-ahead if tracker is not installed.

My understanding is that every other GNOME distro includes tracker by default (except maybe Gentoo).

Does tracker have bugs? Sure. Do people hate tracker for various reasons? Yes. But I haven't seen anyone in this discussion point to a current, specific, actionable bug reports where tracker is causing significant problems.

[Jeremy Bícha (jbicha)]

Without tracker, Videos in your Downloads/ or Music/ or Videos/ folders won't automatically show up on the main page of the Videos app (totem). Instead, you have to click the + button and explicitly add them.

[Khurshid Alam (khurshid-alam)]

@Carlos Garnacho

I have tested this on a low-end laptops first with no tracker and then with tracker installed with default configuration (and there our problem lies.) The default configuration is just unacceptable.

1. Why does tracker index bzr, vendor, pycache folders by default? I put my git projects inside documents. You can literally see that with tracker daemon -f. Also, It should ignore any directory starting with "." by default

2. There are many other configuration available in Gsettings which aren't exposed in GUI.

3. I configure following things:
    -- enable-writeback false
    -- index-optical-discs false
    -- index-on-battery false
    -- index-removable-devices false
    -- ignored-directories ['core-dumps', 'CVS', 'lost+found', 'po', 'vendor', '.git']
    -- ignore-stop-words true
    -- ignore-numbers true
    -- max-words-to-index 1000
    -- removable-days-threshold 3 ? (I don't not understand this)

After this the system is somewhat working well. There are no aggressive indexing. All files can still be searched from shell. Documents, Bijiben etc works without any problems.

There are many options which can be disabled during compilation. For example extractor metadata for ps.gz, gif, iso, xps, abw seems pretty useless to me (who use it and why?). These can be disabled during compilation.

I will keep testing but I believe tracker can be enabled in Ubuntu with proper default settings keeping it at absolute minimal level.

[Carlos Garnacho (carlosg)]

On Sat, Apr 29, 2017 at 5:58 PM, Khurshid Alam
<email address hidden> wrote:
> @Carlos Garnacho
>
> I have tested this on a low-end laptops first with no tracker and then
> with tracker installed with default configuration (and there our problem
> lies.) The default configuration is just unacceptable.

https://developer.gnome.org/gio/unstable/GSettings.html#id-1.4.19.2.9.25

>
> 1. Why does tracker index bzr, vendor, pycache folders by default? I put

Because nobody provided patches. I will welcome yours at
https://bugzilla.gnome.org/enter_bug.cgi?product=tracker

What are 'vendor' folders at all?

> my git projects inside documents. You can literally see that with
> tracker daemon -f. Also, It should ignore any directory starting with
> "." by default

It does ignore hidden files/folders, both unix and msdos style on vfat mounts

>
> 2. There are many other configuration available in Gsettings which
> aren't exposed in GUI.

As far as Tracker is concerned, UI is part of the integrator. The
tracker-preferences executable is a relic and will be eventually
discontinued.

>
> 3. I configure following things:
> -- enable-writeback false
> -- index-optical-discs false
> -- index-on-battery false
> -- index-removable-devices false
> -- ignored-directories ['core-dumps', 'CVS', 'lost+found', 'po', 'vendor', '.git']
> -- ignore-stop-words true
> -- ignore-numbers true
> -- max-words-to-index 1000
> -- removable-days-threshold 3 ? (I don't not understand this)

- You seem to reset a bunch of those settings to their default:
index-optical-discs, index-removable-devices, ignore-stop-words,
ignore-numbers and removable-days-threshold
- You added 'vendor' to ignored-directories, good. Adding '.git' is
both useless and needless though, the hidden directory will be ignored
by default anyway, what you want (and the default) is having '.git' on
ignored-directories-with-content, so the parent directory is ignored
(and thus the whole cloned repo).
- The remaining settings (enable-writeback, index-on-battery,
max-words-to-index), how did you measure the impact of these
modifications? Did you reindex from scratch after every modification?
What were you aiming to measure, system responsivity, indexing
responsitivity, cpu usage, ... ?

>
> After this the system is somewhat working well. There are no aggressive
> indexing. All files can still be searched from shell. Documents, Bijiben
> etc works without any problems.

Perhaps you've just left initial indexing to happen? Tracker is
obviously smart enough to avoid reindexing stuff for the sake of it,
after initial indexing happened it will sit idle most of the time
unless there's file monitor events to attend to. Also, checking an
unmodified, up-to-date directory tree (as it usually happens on miner
startup) is orders of magnitude faster than indexing it from scratch.

>
> There are many options which can be disabled during compilation. For
> example extractor metadata for ps.gz, gif, iso, xps, abw seems pretty
> useless to me (who use it and why?). These can be disabled during
> compilation.

I have the feeling here and other places above that you are
extrapolating personal...

[Khurshid Alam (khurshid-alam)]

[Sorry for late reply, I didn't get any notification]

>Because nobody provided patches. I will welcome yours at
>https://bugzilla.gnome.org/enter_bug.cgi?product=tracker

> What are 'vendor' folders at all?
 vendor: Composer (php librarry manager) dumps libraries into vendor folder in the same directory where `composer update` is called. This is default behavior of composer. One way to think of the vendor directory is as a more generic form of "lib"

I filed a bug https://bugzilla.gnome.org/show_bug.cgi?id=782562

>how did you measure the impact of these
>modifications? Did you reindex from scratch after every modification?

First time I ran tracker never stopped indexing. I monitored tracker-miner-fs.log and also with (/usr/libexec/tracker-extract -v 2). At some point you would expect logging to stop when it becomes idle. But it didn't. Only after tweaking and hard resetting situation improved dramatically. I found similar bugs on bugzilla, I will comment there.

>I have the feeling here and other places above that you are
>extrapolating personal usecases to entire user bases.

Perhaps yes. But my intention is to put indexing at minimal level. In previous version of tracker I used with Ubuntu Gnome, meta.db in ~/.cache used to grow over 1 GB. Again I found the relative bug and will continue discussion over there. Let's not pollute this bug discussing tracker issues.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[step21 (step22)]

This bug https://bugs.launchpad.net/ubuntu/+source/tracker/+bug/1545924 should be addressed first before tracker is installed by default. Or is it already? (this is a duplicate bug, but the original is private for whatever reasons) For me this bug happens on multiple machines, at every login.

[Mathew Hodson (mhodson)]

This is fixed with nautilus 1:3.30.4-1ubuntu1 and later in Disco
---

nautilus (1:3.30.4-1ubuntu1) disco; urgency=medium

[...]

  * Depend on tracker instead of Suggests. It is no longer optional.
    (Closes: #908800)