1. 21 Oct, 2021 1 commit
  2. 13 Oct, 2021 1 commit
  3. 10 Oct, 2021 1 commit
  4. 09 Oct, 2021 1 commit
  5. 05 Oct, 2021 1 commit
  6. 04 Oct, 2021 2 commits
  7. 02 Oct, 2021 1 commit
    • Alex Richardson's avatar
      ecm_add_test: add -DQT_FORCE_ASSERTS to compile flags by default · 5f6a21d5
      Alex Richardson authored and Alex Richardson's avatar Alex Richardson committed
      While debugging a failing test (KProcessTest in KCoreAddons), I noticed
      that the Q_ASSERT() statements inside that test weren't being executed
      because RelWithDebInfo builds default to passing -DQT_NO_DEBUG.
      With this change the test I was debugging now asserts early instead of
      failing a QCOMPARE later on.
      5f6a21d5
  8. 29 Sep, 2021 1 commit
  9. 28 Sep, 2021 1 commit
  10. 27 Sep, 2021 2 commits
    • Alex Richardson's avatar
      Handle git remotes that aren't called origin in _repository_name() · 1dad57d4
      Alex Richardson authored
      I was seeing `error: No such remote 'origin'` in the cmake output.
      This commit avoids hardcoding `origin` as the upstream URL and instead
      uses the `git rev-parse @{u}` to get the configured upstream.
      
      As a follow-up we may want to check if this should be executed by default,
      but for now this fixes a warning that I'm seeing with various projects.
      1dad57d4
    • ivan tkachenko's avatar
      Fix UDev URL · 3df459ce
      ivan tkachenko authored
      Plain freedesktop.org 302-redirects to www.freedesktop.org.
      
      Also, fixes a warning during CMake generation step in plasma-desktop.
      See plasma/plasma-desktop!572
      3df459ce
  11. 26 Sep, 2021 1 commit
    • Michael Pyne's avatar
      python: Bump maximum version for Python 3 module generator check. · 12f4266e
      Michael Pyne authored
      The proximate problem is that the Python Module generator cmake script
      has started failing for people with Python 3.10, which a CMake backtrace
      pointing into FindPythonModuleGeneration.cmake with an error of the form
      "The max python version in PythonModuleGeneration must be updated."
      
      At least one distro has addressed this by simply patching out modules
      that happen to use this CMake module [1].
      
      From what I can tell and the testing I've done, the cause is pretty
      simple: The CMake script attempts to find the best Python 3 version by
      starting from an impossible version and working backwards until it finds
      a version that is installed.
      
      As a sanity check, if the "impossible" version is actually present, it
      aborts. But this appears to be just a sanity check, and not any sort of
      guard against buggy version handling code later.
      
      While the best fix is probably to start from a known *good* version and
      move up until we stop finding better versions, there's problems here
      (e.g. a user with 3.6 and 3.8 installed would fail to see 3.7 and so be
      left with 3.6 as the "best" match), so I opted just to increase the max
      version significantly, and improve the documentation as to what's
      happening and whether it is safe to repeat the step again later.
      
      [1]: https://bugs.gentoo.org/746866
      12f4266e
  12. 20 Sep, 2021 2 commits
  13. 13 Sep, 2021 1 commit
  14. 11 Sep, 2021 2 commits
  15. 01 Sep, 2021 2 commits
  16. 16 Aug, 2021 1 commit
  17. 15 Aug, 2021 1 commit
  18. 14 Aug, 2021 1 commit
  19. 06 Aug, 2021 1 commit
  20. 05 Aug, 2021 4 commits
  21. 04 Aug, 2021 1 commit
  22. 20 Jul, 2021 1 commit
    • Adriaan de Groot's avatar
      suppress tar errors · 72e9fb9e
      Adriaan de Groot authored
      With non-GNU tar, passing the --sort option may print out an
      error message saying the option isn't supported; that's
      confusing and not useful to the consumer.
      72e9fb9e
  23. 19 Jul, 2021 1 commit
  24. 18 Jul, 2021 1 commit
  25. 17 Jul, 2021 1 commit
  26. 16 Jul, 2021 3 commits
  27. 15 Jul, 2021 3 commits
  28. 13 Jul, 2021 1 commit