1. 17 Jun, 2020 1 commit
  2. 16 Jun, 2020 4 commits
  3. 04 Jun, 2020 1 commit
  4. 27 May, 2020 1 commit
  5. 07 May, 2020 2 commits
  6. 29 Apr, 2020 1 commit
  7. 25 Apr, 2020 3 commits
  8. 01 Apr, 2020 1 commit
  9. 21 Mar, 2020 1 commit
  10. 10 Mar, 2020 1 commit
  11. 09 Mar, 2020 1 commit
  12. 05 Mar, 2020 3 commits
  13. 01 Mar, 2020 2 commits
  14. 20 Feb, 2020 1 commit
  15. 19 Feb, 2020 3 commits
    • Carlos Garnacho's avatar
      libtracker-miners-common: Allow sched_setattr syscall · 78c709c3
      Carlos Garnacho authored
      glib#2039 has taught us two
      things:
      - Even if sched_setattr failures aren't handled as g_error() in
        glib, there will be some kind of warning. It's not desirable to
        extractor modules to indirectly trigger it.
      - Since priorities cannot be risen back without special capabilities
        (results in EPERM), it's not that bad to simply allow this syscall.
      
      So simply allow the sched_setattr syscall in our seccomp filter.
      
      Closes: tracker#180
      78c709c3
    • Carlos Garnacho's avatar
      tracker-miner-fs: Set cpu/io/nice settings before glib/gio usage · 75493f12
      Carlos Garnacho authored
      This was happening late enough during main() that there were already
      non-exclusive threadpools/threads created with regular scheduler
      settings. Those settings would be cached in recent glib, creating
      disparities that it will g_error() out on later. Those created threads
      might however be reused later on by different code (eg. metadata
      extraction, directly or indirectly), with the regular scheduling
      priorities set.
      
      Given that even accessing GSettings will result in threads being
      spawned underneath, there's no better choice than doing this always.
      This means the 'sched-idle' setting is ineffective. But this default
      should avoid fingers from pointing at us.
      
      Closes: tracker#180
      75493f12
    • Carlos Garnacho's avatar
      tracker-extract: Set cpu/io/nice settings before glib/gio usage · 3757daba
      Carlos Garnacho authored
      This was happening late enough during main() that there were already
      non-exclusive threadpools/threads created with regular scheduler
      settings. Those settings would be cached in recent glib, creating
      disparities that it will g_error() out on later. Those created threads
      might however be reused later on by different code (eg. metadata
      extraction, directly or indirectly), with the regular scheduling
      priorities set.
      
      Given that even accessing GSettings will result in threads being
      spawned underneath, there's no better choice than doing this always.
      This means the 'sched-idle' setting is ineffective. But this default
      should avoid fingers from pointing at us.
      
      Closes: tracker#180
      3757daba
  16. 18 Feb, 2020 4 commits
    • Carlos Garnacho's avatar
      Release 2.3.2 · 8df1ae1a
      Carlos Garnacho authored
      8df1ae1a
    • Carlos Garnacho's avatar
      libtracker-miners-common: Distcheck fix · d0e79025
      Carlos Garnacho authored
      Make sched_setattr error out softly (return EPERM, instead of a terminating
      SIGSYS signal), so we can more or less cope with that syscall, added in
      recent glib.
      
      This indirectly relies on glib#2039
      being fixed, and glib not triggering g_error() on that syscall failing.
      Let's double down on EPERM being possibly returned ATM, glib master still
      currently breaks tracker-extract, and it won't cause ill effects on older
      glib.
      d0e79025
    • Sam Thursfield's avatar
      Merge branch 'wip/carlosg/writeback-race-condition' into 'tracker-miners-2.3' · e9855a8d
      Sam Thursfield authored
      tracker-miner-fs: Do not handle writeback file updates specially
      
      See merge request !147
      e9855a8d
    • Carlos Garnacho's avatar
      tracker-miner-fs: Do not handle writeback file updates specially · be5f80dc
      Carlos Garnacho authored
      Currently, tracker-miner-fs expects an "updated" inotify event after
      returning from a PerformWriteback call, this typically meaning that
      tracker-writeback did it's job.
      
      This however may fail in 2 ways:
      - The related inotify event arrives before the PerformWriteback
        callback is called. If this happens, tracker-miner-fs will ignore
        it and await for an extra one that might never arrive. This was
        probably made much more likely to happen after commit 3bc295d2410,
        as all inotify events had a pretty high timeout.
      - The directory is not monitored at all, this may happen due to
        various reasons, like settings, or inotify handle/client limits.
      
      The outcome then is that the miner is left paused waiting for inotify
      events that may never arrive.
      
      Since it's not possible to ignore "writeback updates" in a non-racy
      manner, give it up and handle the file update as every other.
      
      Closes: gnome-music#346
      be5f80dc
  17. 17 Feb, 2020 1 commit
  18. 02 Feb, 2020 5 commits
  19. 12 Jan, 2020 3 commits
  20. 08 Jan, 2020 1 commit