delta/dbus-python.git/test, branch dbus-python-1.2.12 gitlab.freedesktop.org: dbus/dbus-python.git Fix NO_REPLY test for Python 3 2019-09-02T13:24:36+00:00 Simon McVittie smcv@collabora.com 2019-09-02T13:24:36+00:00 5e3a97992b206037c137a8cfda1a2c2f18fac45a Signed-off-by: Simon McVittie <smcv@collabora.com> 
Signed-off-by: Simon McVittie <smcv@collabora.com>
Configure test bus to allow unrequested replies 2019-09-02T12:59:41+00:00 Simon McVittie smcv@collabora.com 2019-09-02T12:58:37+00:00 416dd1461cb68e0648382722832e7a22025d3683 This lets us catch them in the test code. Fixes: e9f658d9d57b97395545c5ed2eaf9a85436f135d Signed-off-by: Simon McVittie <smcv@collabora.com> 
This lets us catch them in the test code.

Fixes: e9f658d9d57b97395545c5ed2eaf9a85436f135d
Signed-off-by: Simon McVittie <smcv@collabora.com>
Add a test for NO_REPLY method calls 2019-09-02T12:45:44+00:00 Simon McVittie smcv@collabora.com 2019-09-02T12:10:30+00:00 e9f658d9d57b97395545c5ed2eaf9a85436f135d See https://gitlab.freedesktop.org/dbus/dbus-python/issues/26 Signed-off-by: Simon McVittie <smcv@collabora.com> 
See https://gitlab.freedesktop.org/dbus/dbus-python/issues/26

Signed-off-by: Simon McVittie <smcv@collabora.com>
test-p2p: Add test coverage for sending and receiving fds 2019-09-02T12:04:57+00:00 Simon McVittie smcv@collabora.com 2019-09-02T12:04:57+00:00 d1d876399be089bd94343140da8d41479f0c1fd1 Signed-off-by: Simon McVittie <smcv@collabora.com> 
Signed-off-by: Simon McVittie <smcv@collabora.com>
Add basic test coverage for UnixFd 2019-09-02T11:39:32+00:00 Simon McVittie smcv@collabora.com 2019-09-02T11:39:32+00:00 5b0af53bbb3f4e12af4d979d8501ff6fa10af051 Signed-off-by: Simon McVittie <smcv@collabora.com> 
Signed-off-by: Simon McVittie <smcv@collabora.com>
Silence -Wcast-function-type with gcc 8 2019-07-23T10:14:14+00:00 Simon McVittie smcv@collabora.com 2019-07-23T10:14:14+00:00 b24fd92dcaac567568641df0490acac334dd94c9 Casting via void (*)(void) is the documented way to suppress this warning. This is required because the CPython API treats function pointers as generic, with flags to indicate different calling conventions. Signed-off-by: Simon McVittie <smcv@collabora.com> 
Casting via void (*)(void) is the documented way to suppress this
warning. This is required because the CPython API treats function
pointers as generic, with flags to indicate different calling
conventions.

Signed-off-by: Simon McVittie <smcv@collabora.com>
with-session-bus.sh: Remove unused script 2019-07-15T14:51:05+00:00 Simon McVittie smcv@collabora.com 2019-07-15T12:48:56+00:00 5aa311eca9b3226e033030ce78a3d60abd4ea092 Signed-off-by: Simon McVittie <smcv@collabora.com> 
Signed-off-by: Simon McVittie <smcv@collabora.com>
Add clearer licensing information in SPDX format 2019-07-15T14:51:05+00:00 Simon McVittie smcv@collabora.com 2019-07-15T12:08:16+00:00 28734ae1661ea029fa2ed06fab6a4d6cf6ade098 Signed-off-by: Simon McVittie <smcv@collabora.com> 
Signed-off-by: Simon McVittie <smcv@collabora.com>
Remove remaining support for Ubuntu 14.04 'trusty' 2019-07-15T12:47:08+00:00 Simon McVittie smcv@collabora.com 2018-12-17T17:27:48+00:00 745230046f0497582e2ee4b3648b32624451e754 Signed-off-by: Simon McVittie <smcv@collabora.com> 
Signed-off-by: Simon McVittie <smcv@collabora.com>
cross-test-server: Avoid a race condition in the client 2018-05-09T07:53:34+00:00 Simon McVittie smcv@debian.org 2018-05-08T08:18:28+00:00 62789b8dd79f2b29252f31c1f424cc43e4ca5ec5 There is a race condition here between these chains of events, which as far as I can tell has existed for at least 10 years: * server receives Tests.Trigger() and schedules SignalTests.Triggered * server returns to main loop * server emits SignalTests.Triggered * client receives SignalTests.Triggered and * server receives Tests.Trigger() and replies with success * client receives success and emits SignalTests.Trigger * server receives SignalTests.Trigger and calls CallbackTests.Response() * client receives CallbackTests.Response() and calls Tests.Exit() * server receives Tests.Exit() and replies with success * client quits its main loop If we don't reply to Tests.Trigger() until after the SignalTests.Triggered signal has been sent, because the client called Tests.Trigger() asynchronously, messages are not re-ordered and the reply arrives after the signal; so the whole chain of events leading up to "client receives SignalTests.Triggered" happens before "client receives success and emits SignalTests.Trigger" and there is no race condition. Bug-Debian: https://bugs.debian.org/898158 
There is a race condition here between these chains of events, which as
far as I can tell has existed for at least 10 years:

* server receives Tests.Trigger() and schedules SignalTests.Triggered
* server returns to main loop
* server emits SignalTests.Triggered
* client receives SignalTests.Triggered

and

* server receives Tests.Trigger() and replies with success
* client receives success and emits SignalTests.Trigger
* server receives SignalTests.Trigger and calls CallbackTests.Response()
* client receives CallbackTests.Response() and calls Tests.Exit()
* server receives Tests.Exit() and replies with success
* client quits its main loop

If we don't reply to Tests.Trigger() until after the SignalTests.Triggered
signal has been sent, because the client called Tests.Trigger()
asynchronously, messages are not re-ordered and the reply arrives after
the signal; so the whole chain of events leading up to
"client receives SignalTests.Triggered" happens before
"client receives success and emits SignalTests.Trigger" and there is
no race condition.

Bug-Debian: https://bugs.debian.org/898158