Description of problem: The recent sqlite upgrade broke search in GtkFileChooser. I get an error dialog that says: """ Could not send the search request GDBus.Error:org.freedesktop.Tracker1.SparqlError.Internal: unknown tokenizer: TrackerTokenizer """ And I see in my journal: Feb 23 21:55:59 victory-road org.freedesktop.Tracker1[9685]: (tracker-store:10032): Tracker-WARNING **: Could not create FTS insert statement: unknown tokenizer: TrackerTokenizer The tracker developers understand the issue and plan to fix it in tracker, so this change is OK in F24 and going forward. But for F23 this sqlite change should be urgently reverted, as it broke tons of applications in our stable release. This affects every GTK+ 3 application that uses a GtkFileChooser to let the user open or save files. Version-Release number of selected component (if applicable): sqlite-3.11.0-1.fc23 How reproducible: It happens for searches in some directories but not others, not sure why Steps to Reproduce: 1. Search for something in a GtkFileChooser, in an affected directory Actual results: Error dialog Expected results: No error dialog Additional info: See also: https://bugzilla.gnome.org/show_bug.cgi?id=762226
Can be reproduced by installing a clean install and then running upgrades. Any plans about how this is going to be fixed?
After reading the GNOME Bugzilla, the tracker seems to be fixed going forward. From the comments, I gathered that enabling the SQLITE_ENABLE_FTS3_TOKENIZER flag should provide a workaround until the tracker is updated. I will try that, see how it works out.
Yeah, and the new tracker is already in F24 and rawhide, so this is only needed in F23. (Or you could coordinate to do a tracker update for F23 as well; not sure if that's a good idea or not.)
Actually it looks like a tracker with bundled sqlite3 may be on the way for F23... David, do we need any changes from the sqlite developers or is this indeed the plan?
I would prefer tracker update for F23 (and probably F22, too), if it seems stable. The other option is to use the sqlite with the FTS3 flag enabled -- this was the behavior till now, after all, and could be applied at least as a workaround. From my testing, it seems to work (`tracker search something` works with sqlite with FTS3 and does not with sqlite without FTS3). For those interested, the F23 build with FTS3 enabled is at [1], and I would be grateful for testing. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=13199970
I chatted to Carlos Garnacho about this, and the new sqlite build solves to problem for older tracker versions (where new 1.6.2 and 1.4.3 releases avoided the problem by embedding sqlite and enabling the FTS3 tokenizer on that bundled version). Debian has also enabled the FTS3 tokenizer: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815499 There is nothing further needed after enabling the FTS3 tokenizer (as done in sqlite-3.11.0-3.fc23), as far as I am aware.
(In reply to Jan Staněk from comment #5) > I would prefer tracker update for F23 (and probably F22, too), if it seems > stable. As using the FTS5 tokenizer is a rather large change, it seems unwise to backport that to a stable distribution, so the FTS3 tokenizer should be enabled for F23 (thanks for the sqlite build which does that). If nothing else other than tracker depends on it, it can be disabled in F24 and onwards.
OK, so I will build and publish an sqlite update for F23 and F22 with the tokenizer enabled, which should solve this issue. In rawhide/F24, I will do just dummy release bump to satify depsolver, and leave it without the tokenizer. The new tracker should not need it (and as potential security hole, we want to eventualy NOT enable it). If another dependecy on FTS3 tracker in F24+ arise, which could not be solved in other way, I will enable it later.
> If another dependecy on FTS3 tracker in F24+ arise, which could not be solved in other way, I will enable it later. I obviously meant FTS3 tokenizer, sorry :)
sqlite-3.11.0-3.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c0444d26e4
sqlite-3.11.0-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9850932586
sqlite-3.11.0-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-9850932586
sqlite-3.11.0-3.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c0444d26e4
sqlite-3.11.0-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
sqlite-3.11.0-3.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
Please, can you reopen this bug? We have another dependency on FTS3 tokenizer: geary. I filed bug 1337903 against Geary, and installing sqlite-3.11.0-3.fc23 over my F24 install made the issue described there go away.
I see that bug 1337903 has been fixed. Is this really still an issue?
Now that sqlite 3.12 has been pushed to F24, and geary has been rebuilt against it, this issue here is obsolete.
Sorry, I was unable to change my password until now. This is working perfectly here, and has worked perfectly.