- 05 Jun, 2012 7 commits
-
-
Simon McVittie authored
-
Simon McVittie authored
-
Simon McVittie authored
During distcheck, the srcdir is read-only. During "make all", cp may preserve the read-only status of the file copied from the srcdir, resulting in failure to overwrite it with an identical file during "make check" (which depends on all-local). Signed-off-by:
Simon McVittie <simon.mcvittie@collabora.co.uk>
-
Simon McVittie authored
-
Simon McVittie authored
Ralf pointed out that the address doesn't round-trip correctly. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45896Signed-off-by:
Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by:
Ralf Habacker <ralf.habacker@freenet.de> Tested-by:
Ralf Habacker <ralf.habacker@freenet.de>
-
Simon McVittie authored
Turns out this was duplicated too. We can just use the platform-independent version, which uses the same code. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45896Signed-off-by:
Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by:
Ralf Habacker <ralf.habacker@freenet.de> Tested-by:
Ralf Habacker <ralf.habacker@freenet.de>
-
Simon McVittie authored
_dbus_transport_open_socket is called before _dbus_transport_open_platform_specific, and now handles nonce-tcp, so this version is no longer useful. Signed-off-by:
Simon McVittie <simon.mcvittie@collabora.co.uk> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45896Reviewed-by:
Ralf Habacker <ralf.habacker@freenet.de> Tested-by:
Ralf Habacker <ralf.habacker@freenet.de>
-
- 25 Apr, 2012 3 commits
-
-
Simon McVittie authored
Conflicts: NEWS dbus/dbus-internals.c dbus/dbus-mainloop.c dbus/dbus-sysdeps-unix.c dbus/dbus-sysdeps-win.c dbus/dbus-sysdeps.c dbus/dbus-sysdeps.h
-
Simon McVittie authored
-
Antoine Jacoutot authored
$(INSTALL) and $(INSTALL_DATA) try to change ownerships to root:bin when copying tests to builddir. Presumably this is a difference in behaviour between GNU and BSD install(1): the one in GNU coreutils doesn't try-and-fail to change ownership if you're not root. [Commit message added by smcv] Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48127Reviewed-by:
Simon McVittie <simon.mcvittie@collabora.co.uk>
-
- 12 Apr, 2012 2 commits
-
-
David Zeuthen authored
When libdbus-1 moved to using monotonic time support for the DBUS_COOKIE_SHA1 authentication was broken, in particular interoperability with non-libdbus-1 implementations such as GDBus. The problem is that if monotonic clocks are available in the OS, _dbus_get_current_time() will not return the number of seconds since the Epoch so using it for DBUS_COOKIE_SHA1 will violate the D-Bus specification. If both peers are using libdbus-1 it's not a problem since both ends will use the wrong time and thus agree. However, if the other end is another implementation and following the spec it will not work. First, we change _dbus_get_current_time() back so it always returns time since the Epoch and we then rename it _dbus_get_real_time() to make this clear. We then introduce _dbus_get_monotonic_time() and carefully make all current users of _dbus_get_current_time() use it, if applicable. During this audit, one of the callers, _dbus_generate_uuid(), was currently using monotonic time but it was decided to make it use real time instead. Signed-off-by:
David Zeuthen <davidz@redhat.com> Reviewed-by:
Simon McVittie <simon.mcvittie@collabora.co.uk> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48580
-
David Zeuthen authored
When libdbus-1 moved to using monotonic time support for the DBUS_COOKIE_SHA1 authentication was broken, in particular interoperability with non-libdbus-1 implementations such as GDBus. The problem is that if monotonic clocks are available in the OS, _dbus_get_current_time() will not return the number of seconds since the Epoch so using it for DBUS_COOKIE_SHA1 will violate the D-Bus specification. If both peers are using libdbus-1 it's not a problem since both ends will use the wrong time and thus agree. However, if the other end is another implementation and following the spec it will not work. First, we change _dbus_get_current_time() back so it always returns time since the Epoch and we then rename it _dbus_get_real_time() to make this clear. We then introduce _dbus_get_monotonic_time() and carefully make all current users of _dbus_get_current_time() use it, if applicable. During this audit, one of the callers, _dbus_generate_uuid(), was currently using monotonic time but it was decided to make it use real time instead. Signed-off-by:
David Zeuthen <davidz@redhat.com> Reviewed-by:
Simon McVittie <simon.mcvittie@collabora.co.uk> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=48580
-
- 27 Mar, 2012 9 commits
-
-
Simon McVittie authored
-
Simon McVittie authored
-
Simon McVittie authored
It's used by the own_prefix implementation.
-
Simon McVittie authored
Reviewed-by:
Simon McVittie <simon.mcvittie@collabora.co.uk> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46273
-
Simon McVittie authored
Conflicts: NEWS configure.ac
-
Simon McVittie authored
-
Simon McVittie authored
-
Andoni Morales Alastruey authored
In mingw-w64 both ESOMETHING and WSASOMETHING are defined, leading to a duplicate case in the switch. Reviewed-by:
Simon McVittie <simon.mcvittie@collabora.co.uk> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=47321
-
Martin Pitt authored
g_thread_init() is deprecated since glib 2.24, call g_type_init() instead. Bump glib requirement accordingly. g_thread_create is deprecated since 2.31, use g_thread_new() instead. When building with a glib earlier than 2.31, provide a backwards compatibility shim. [Added a comment about why we're using g_type_init() in a test that doesn't otherwise use GObject -smcv] [Applied to 1.4 despite just being a deprecation fix because it also fixes linking with GLib 2.32, in which gthread has been removed from gobject's Requires and moved to Requires.private, Debian #665665 -smcv] Bug: https://bugs.freedesktop.org/show_bug.cgi?id=44413 Bug-Debian: http://bugs.debian.org/665665Reviewed-by:
Simon McVittie <simon.mcvittie@collabora.co.uk>
-
- 22 Mar, 2012 4 commits
-
-
Alban Crequy authored
After parsing [allow|deny] rules with own_prefix, check they are enforced correctly. https://bugs.freedesktop.org/show_bug.cgi?id=46886
-
Alban Crequy authored
Just check that the parser accept [allow|deny] rules with own_prefix https://bugs.freedesktop.org/show_bug.cgi?id=46886
-
Alban Crequy authored
-
-
- 12 Mar, 2012 6 commits
-
-
Lennart Poettering authored
The "unixexec:" transport will create a local AF_UNIX socket with socketpair(), then fork and execute a binary on one side with STDIN and STDOUT connected to it and then use the other side. This is useful to implement D-Bus tunneling schemes, for example to get a D-Bus connection to the system bus on a different host, similar how udisks is already doing it. (udisks uses SSH TCP tunneling for this, which is a bit ugly and less secure than this solution). Suggested use is with connection strings like the following: unixexec:path=ssh,argv1=foobar,argv2=system-bus-bridge or: unixexec:path=pkexec,argv1=system-bus-bridge or even: unixexec:path=sudo,argv1=system-bus-bridge The first line would execute the binary 'system-bus-bridge' on host 'foobar' and then pass D-Bus traffic to it. This (hypothetical) bridge binary would then forward the information to the local system bus. The second and third line use this scheme locally to acquire a privileged connection through pkexec resp. sudo: instead of connecting directly to the bus, they use the same bridge binary which will forward all information to the system bus. The arguments of the protocol are 'path' for the first execlp() argument, and argv0, argv1, and so on for the following arguments. argv0 can be left out in which case path will be used. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35230Reviewed-by:
Simon McVittie <simon.mcvittie@collabora.co.uk>
-
Lennart Poettering authored
This is optimized on Linux and enumerates through /proc/self/fd with a fallback on brute-force closing of fds, in case /proc is not available. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35230Reviewed-by:
Simon McVittie <simon.mcvittie@collabora.co.uk>
-
Lennart Poettering authored
This adds a specification text for the new unixexec: transport. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35230Reviewed-by:
Simon McVittie <simon.mcvittie@collabora.co.uk>
-
John Bradshaw authored
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=47076 Bug-Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=675491Reviewed-by:
Simon McVittie <simon.mcvittie@collabora.co.uk>
-
Simon McVittie authored
-
Simon McVittie authored
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33840Reviewed-by:
Will Thompson <will.thompson@collabora.co.uk>
-
- 04 Mar, 2012 2 commits
-
-
- 28 Feb, 2012 2 commits
-
-
Simon McVittie authored
-
Simon McVittie authored
The DBusPipe code was broken by commit 6e214b5b, which switched from C runtime API to Win32 API for WinCE's benefit. In a DBusPipe, fd_or_handle is in fact always a C runtime file descriptor, which can't be used with the Win32 API (which expects a HANDLE). This commit goes back to the C runtime API. It might cause WinCE support to regress, but at least dbus-daemon.exe --print-address works again. This is enough to make a few tests work under Wine when cross-compiling from Linux to mingw-w64: in particular, this now works: DBUS_TEST_DAEMON=bus/dbus-daemon.exe DBUS_TEST_DATA=test/data \ wine test/test-dbus-daemon.exe -p /echo/session Bug: https://bugs.freedesktop.org/show_bug.cgi?id=46049Signed-off-by:
Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by:
Ralf Habacker <ralf.habacker@freenet.de>
-
- 24 Feb, 2012 4 commits
-
-
Simon McVittie authored
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39549Signed-off-by:
Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by:
Will Thompson <will.thompson@collabora.co.uk>
-
Simon McVittie authored
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39549Signed-off-by:
Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by:
Will Thompson <will.thompson@collabora.co.uk>
-
Simon McVittie authored
dbus_bool_t is the same as dbus_uint32_t, but if we have a separate bool_val member, it's more obvious that people are getting it right. It's not called bool because that's a keyword in C++. int (for file descriptors) doesn't appear in the D-Bus message wire format, but then again neither does char *, and dbus_message_iter_get_basic() and friends can return an int (due to internal index-into-array-of-fds -> fd remapping in libdbus). In theory int might not be the same size as any of the dbus_intNN_t types, and anyway it's easier to see that people are getting it right if we make it explicit. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=11191Signed-off-by:
Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by:
Will Thompson <will.thompson@collabora.co.uk>
-
Simon McVittie authored
In practice, D-Bus bindings end up reinventing DBusBasicValue anyway, so it might as well be API. Also stop claiming that all basic-typed values are guaranteed to fit in 8 bytes - this is not true if your platform has more than 8-byte pointers (I'm not aware of any such platform now, but let's not rule it out). Bug: https://bugs.freedesktop.org/show_bug.cgi?id=11191Signed-off-by:
Simon McVittie <simon.mcvittie@collabora.co.uk> Reviewed-by:
Will Thompson <will.thompson@collabora.co.uk>
-
- 21 Feb, 2012 1 commit
-
-
Simon McVittie authored
-