1. 30 Jun, 2014 1 commit
  2. 10 Jun, 2014 1 commit
  3. 05 Jun, 2014 1 commit
  4. 30 Apr, 2014 2 commits
  5. 27 Jan, 2014 1 commit
  6. 20 Jan, 2014 2 commits
  7. 06 Jan, 2014 3 commits
  8. 27 Nov, 2013 1 commit
  9. 01 Nov, 2013 5 commits
  10. 10 Oct, 2013 1 commit
  11. 09 Oct, 2013 2 commits
  12. 08 Oct, 2013 4 commits
  13. 16 Sep, 2013 2 commits
    • Simon McVittie's avatar
      Remove support for platforms with no 64-bit integer type · b47d5062
      Simon McVittie authored
      This has been a soft requirement since 1.5.0; anyone on such platforms
      would have had to configure --without-64-bit, provoking a warning that
      instructed them to report a D-Bus bug with details of their platform.
      Nobody has done so, so if anyone still lacks a 64-bit integer type,
      they're on their own.
      
      (Also, I tried the build with --without-64-bit and it's full of
      fatal compiler warnings, so it's not clear that we're actually
      losing anything by removing this "feature".)
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65429Reviewed-by: default avatarChengwei Yang <chengwei.yang@intel.com>
      b47d5062
    • Simon McVittie's avatar
      dbus-sysdeps-win: don't include wspiapi.h · 3b9c2817
      Simon McVittie authored
      This block provoked a warning on mingw-w64 because we were redefining
      _inline. According to Ralf's research, it was introduced in 452ff68a:
      Windows 2000 doesn't have getaddrinfo and related functions in
      ws2tcpip.h, but does have a shim implementation in wspiapi.h.
      
      At the time of 452ff68a, mingw32 didn't have wspiapi.h, so it's unclear
      why there was a __GNUC__ code path here. The "#define _inline" on that
      code path looks likely to be some sort of workaround for a faulty version
      of wspiapi.h? Current mingw-w64 does have wspiapi.h, so we enter the
      __GNUC__ code path and get the redefinition.
      
      dbus no longer supports Windows 2000, so we no longer need wspiapi.h
      at all, and can rely on XP or later. (Ralf's policy is to only support
      versions of Windows that are still supported by Microsoft, and Windows 2000
      reached the end of its life-cycle in 2010.)
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
      Reviewed-by: Ralf Habacker
      3b9c2817
  14. 13 Sep, 2013 2 commits
  15. 05 Sep, 2013 2 commits
  16. 03 Sep, 2013 1 commit
    • Simon McVittie's avatar
      Tests: allow dbus-glib to be replaced with use of libdbus-internal · 30e7a813
      Simon McVittie authored
      We only use dbus-glib for its main loop; within dbus, DBusLoop is
      available as an alternative, although it isn't thread-safe and
      isn't public API.
      
      For tests that otherwise only use libdbus public API, it's desirable to
      be able to avoid DBusLoop, so we can run them against an installed
      libdbus as an integration test. However, if we don't have dbus-glib,
      we're going to have to use an in-tree main loop, which might as well
      be DBusLoop.
      
      The major disadvantage of using dbus-glib is that it isn't safe to
      link both dbus-1 and dbus-internal at the same time. This is awkward
      for a future test case that wants to use _dbus_getsid() in dbus-daemon.c,
      but only on Windows (fd.o #54445). If we use the same API wrapper around
      both dbus-glib and DBusLoop, we can compile that test against dbus-glib
      or against DBusLoop, depending on the platform.
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852Reviewed-by: Ralf Habacker's avatarRalf Habacker <ralf.habacker@freenet.de>
      30e7a813
  17. 22 Aug, 2013 1 commit
  18. 28 Jun, 2013 2 commits
  19. 25 Jun, 2013 1 commit
  20. 13 Jun, 2013 1 commit
  21. 12 Jun, 2013 3 commits
  22. 06 Jun, 2013 1 commit