1. 21 Sep, 2020 1 commit
  2. 16 Sep, 2020 9 commits
  3. 15 Sep, 2020 2 commits
  4. 14 Sep, 2020 8 commits
  5. 13 Sep, 2020 2 commits
  6. 12 Sep, 2020 1 commit
  7. 11 Sep, 2020 1 commit
  8. 10 Sep, 2020 1 commit
  9. 08 Sep, 2020 3 commits
  10. 07 Sep, 2020 5 commits
    • Carlos Garnacho's avatar
      Release 2.99.5 · 4656f694
      Carlos Garnacho authored
      4656f694
    • Carlos Garnacho's avatar
      Merge branch 'wip/carlosg/fix-manpages-install' into 'master' · c771ffa1
      Carlos Garnacho authored
      Fix manpages install
      
      See merge request !311
      c771ffa1
    • Carlos Garnacho's avatar
      manpages: Fix installation of manpage files · 0cd3d0f0
      Carlos Garnacho authored
      The xsltproc step has two small gotchas: the output does not happen on
      stdout, so we are capturing empty stdout, and installing an empty file instead
      of our nice manpages.
      
      But also, the target filename gets determined by the XSL based on the input,
      so a manpage filename is as defined in its NAME section. This means we cannot
      do filename changes to add the version this late in the stage.
      
      Furthermore, the tracker-xdg-portal-3 manpage follows a different naming scheme
      (i.e. not "tracker3-*").
      
      Handle this all at once, specify per manpage target files that do match the
      xsltproc output, and ensure the file gets generated at the current build dir.
      0cd3d0f0
    • Carlos Garnacho's avatar
      manpages: Reference daemons with their executable name · 520f9841
      Carlos Garnacho authored
      Those are now versioned, so reference them as such in their respective
      manpages.
      
      Note: The name change also changes the target manpage file written by
      our xsltproc step, since it is defined by the file+xsl. This will silently
      go ignored, as installation of manpages is broken (we install empty files).
      This will get fixed in later commits.
      520f9841
    • Carlos Garnacho's avatar
      manpages: Update references to the tracker3 CLI tool · 988e0893
      Carlos Garnacho authored
      We did reference it in manpages as simply "tracker", which is definitely
      not going to be the case. Make CLI examples, titles and section names
      correctly reference the real "tracker3" name.
      
      Note: The name change also changes the target manpage file written by
      our xsltproc step, since it is defined by the file+xsl. This will silently
      go ignored, as installation of manpages is broken (we install empty files).
      This will get fixed in later commits.
      988e0893
  11. 06 Sep, 2020 1 commit
  12. 04 Sep, 2020 4 commits
  13. 03 Sep, 2020 2 commits
    • Carlos Garnacho's avatar
      tests: Add FTS tests for some extraneous input · 91676e6b
      Carlos Garnacho authored
      Test dots and quotes in input so far.
      91676e6b
    • Carlos Garnacho's avatar
      libtracker-data: Do not expose FTS5 syntax through fts:match · da9eb9a0
      Carlos Garnacho authored
      We used to simply forward all FTS match string interpretation to SQLite's
      FTS implementation, and used to allow and announce its features, e.g.
      use of AND/OR keywords for more complex matches.
      
      When FTS5 came through, the FTS query syntax got a major revamp, also
      in the complexity of the allowed syntax, including non natural language
      (e.g. symbols like ^ or *).
      
      This makes all the gory details of this parser available to users, but
      also its pitfalls, e.g. execution-time errors are raised when the search
      string contains special symbols non-interpretable by the FTS5 parser.
      
      Since fts:match is often plugged directly to search entries in UIs around,
      it seems a bad approach to maybe fail the query or not depending on the
      last character entered. Arguably applications might cater for this
      additional level of syntax, but it's sadly not trivial and kind of a moving
      target (fts5 still does add features from time to time), seems bad to leave
      this up to applications.
      
      So, hide all FTS5 syntax from the upper layers. The fts:match string forcibly
      becomes '"%s"*' so it is ensured that all the input string is interpreted as
      "search terms". It is also ensured that the given search string cannot break
      out of that. The '*' character makes the last term in the search string be
      interpreted as a prefix search.
      
      We lose some neat things there, like AND/OR mentioned above, or the
      possibility to match a single property instead of a whole row. AND is already
      the default, OR can be obtained through additional fts:match, and the last
      one is a rather obscure feature. Might be neat to bring back in another form
      someday. (e.g. make fts:match a FILTER function).
      
      Also, update tests to these new expectatives.
      
      Fixes: gtk#3114
      da9eb9a0