1. 16 Nov, 2018 1 commit
    • Simon McVittie's avatar
      build: Never use poll() on Darwin family (macOS, etc.) or Interix · 6cb51b22
      Simon McVittie authored
      Doing a runtime check in configure.ac (AC_RUN_IFELSE) has several
      disadvantages:
      
      * It doesn't work when cross-compiling. For example, if we build macOS
        binaries on a Linux system, we'd assume that poll() works, but in
        fact it won't.
      
      * It checks the build system capabilities, but that is not necessarily
        appropriate if (for example) a macOS 10.10 user builds binaries that
        could be used by macOS 10.12 or macOS 10.9 users.
      
      * It checks for one specific failure mode, but macOS seems to have a
        history of various implementation issues in poll().
      
      * If we want it to work in CMake, we have to duplicate it in the CMake
        build system.
      
      None of these is a showstopper on its own, but the combination of all
      of them makes the current approach to avoiding the broken poll() on
      macOS look unreliable. libcurl, a widely-portable library making
      extensive use of sockets, specifically doesn't use poll() on Darwin
      (macOS, iOS, etc.) or on Interix; let's follow their example here.
      
      See also https://bugzilla.gnome.org/show_bug.cgi?id=302672 and
      https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/
      for some relevant history.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Resolves: #232
      (cherry picked from commit 0414ea65)
      6cb51b22
  2. 03 Aug, 2018 1 commit
  3. 02 Aug, 2018 2 commits
  4. 30 Apr, 2018 2 commits
  5. 01 Mar, 2018 1 commit
  6. 20 Feb, 2018 1 commit
  7. 08 Feb, 2018 2 commits
  8. 07 Feb, 2018 2 commits
  9. 14 Dec, 2017 1 commit
  10. 13 Nov, 2017 2 commits
  11. 30 Oct, 2017 3 commits
  12. 23 Oct, 2017 2 commits
  13. 18 Oct, 2017 1 commit
  14. 03 Oct, 2017 2 commits
  15. 29 Sep, 2017 2 commits
  16. 25 Sep, 2017 4 commits
    • Simon McVittie's avatar
      Post-release version bump · 1330bd2c
      Simon McVittie authored
      1330bd2c
    • Simon McVittie's avatar
      Prepare 1.11.18 release · f45c9941
      Simon McVittie authored
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      f45c9941
    • Simon McVittie's avatar
      Remove distribution-specific init-scripts · 708a44d0
      Simon McVittie authored
      LSB-style (SysV-style) init scripts have not historically been
      portable between distributions, as evidenced by the presence of both
      "Red Hat" and "Slackware" init scripts in dbus. Many distributors
      prefer to maintain them downstream, as is done in Debian (and its
      derivatives) and in Slackware, so that the init script can follow
      OS conventions (for example regarding boot messages) and make use
      of OS-provided facilities (for example, the Debian init script uses
      dpkg's start-stop-daemon utility).
      
      The Slackware and Red Hat init scripts removed by this commit are not
      tested or maintained in practice, and so are likely to have bugs. The
      Slackware init-script provided here is not used on actual Slackware
      systems, which provide a different implementation of rc.messagebus in
      their packaging, while the Red Hat init script has been superseded by
      the systemd unit in current Fedora, CentOS and RHEL versions.
      
      The Cgywin messagebus-config provided here does appear to be used in
      production in cygwin-ports, but it's full of Cygwin-specifics with which
      the dbus maintainers are not familiar, so it is probably more appropriate
      for it to be tracked downstream as part of the Cygwin packaging.
      
      The systemd unit is not removed, since it is used on multiple Linux
      distributions with little or no modification, and receives regular
      testing and maintenance; this makes it appropriate to maintain upstream.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Bug: https://bugs.freedesktop.org/101706Reviewed-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      708a44d0
    • Simon McVittie's avatar
      Deprecate the pam_console/pam_foreground flag-file directory · 2aaa6509
      Simon McVittie authored
      This feature is now compile-time conditional, and off by default.
      
      pam_console appears to have been in Fedora and Gentoo until 2007.
      pam_foreground seems to be specific to Debian and Ubuntu, where it was
      unmaintained since 2008 and removed in 2010. The replacement for both
      was ConsoleKit, which has itself been superseded by systemd-logind and
      ConsoleKit2.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Bug: https://bugs.freedesktop.org/101629Reviewed-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      2aaa6509
  17. 28 Jul, 2017 2 commits
  18. 27 Jul, 2017 5 commits
  19. 30 Jun, 2017 1 commit
    • Simon McVittie's avatar
      build: Introduce ${runstatedir} and use it for the pid file · 1477ca50
      Simon McVittie authored
      By default ${runstatedir} is the same as ${localstatedir}/run, but many
      Linux distributions configure it to be /run and mount a tmpfs in that
      location. All other factors being equal, it is preferable to use /run
      where available because it is guaranteed to be local, whereas traversing
      /var might involve automounting a networked filesystem (even though
      /var/run itself is very likely to be a tmpfs).
      
      /run or /var/run is currently only used in a few places in dbus, but
      I plan to make more use of it during the development of
      <https://bugs.freedesktop.org/show_bug.cgi?id=100344>.
      
      The pid file is not part of the API between dbus and other software
      (other than distribution init scripts for dbus itself), so we do not
      need to keep it strictly compatible; so it is OK to move it.
      
      We do not yet use /run for the system bus socket, because that is
      part of the API between D-Bus clients and servers, and has always been
      "officially" /var/run/dbus/system_bus_socket.
      <https://bugs.freedesktop.org/show_bug.cgi?id=101628> tracks the
      possibility of changing that.
      
      Similarly, we do not replace /var/run/console with /run/console, because
      that path is part of the API between dbus-daemon and the obsolete PAM
      modules pam_console and pam_foreground that used /var/run/console.
      <https://bugs.freedesktop.org/show_bug.cgi?id=101629> tracks the possible
      future removal of that code path.
      
      In the CMake build system, the equivalent of ${runstatedir} remains
      hard-coded to the equivalent of ${localstatedir}/run for simplicity. For
      the sort of system-wide installations that would consider redefining
      ${runstatedir} to /run, the Autotools build system is strongly
      recommended: in particular this is what Linux distributions are expected
      to use.
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      Reviewed-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101569
      1477ca50
  20. 29 Jun, 2017 3 commits