Add gsd-rfkill mock

[agx]

This can be useful to test behavior of dependent components like desktop shells.

Single properties can be toggled via

   gdbus call --session -d org.gnome.SettingsDaemon.Rfkill -o /org/gnome/SettingsDaemon/Rfkill -m org.freedesktop.DBus.Properties.Set 'org.gnome.SettingsDaemon.Rfkill' 'BluetoothHasAirplaneMode' "<true>"

and airplane mode for all wwan/bt/wifi at once:

   gdbus call --session -d org.gnome.SettingsDaemon.Rfkill -o /org/gnome/SettingsDaemon/Rfkill -m org.freedesktop.DBus.Mock.SetAirplaneMode true

I can see that this might be to DE specific but I thought I'd submit it as it might be useful to others.

[agx]

Looking at the (downloaded) logs I fail to see why pytest exits with 1.

[martinpitt]

@agx: There's several ruff, black, and pylint errors, starting here: https://github.com/martinpitt/python-dbusmock/actions/runs/11702695738/job/32591410796?pr=223#step:4:677

[martinpitt]

It's not even pytest, it already fails in the first run during the python3 -m unittest run. This reproduces in a local container run, and across all OSes at the same place, so not a coincidence/flake.

Both python3 -m unittest tests.test_gsd_rfkill and python3 -m unittest tests.test_iio_sensors_proxy in isolation work, but running the whole suite silently aborts with 1.

Under strace, the tests hang in TestIIOSensorsProxy.test_accelerometer_claimed_properties_changes instead of exiting immediately -- so yay changed behaviour. With strace -D it exits, but also not meaningfully:

5504  recvmsg(11, {msg_namelen=0}, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
5504  sendmsg(11, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\2\1\1\0\0\0\0\t\0\0\0005\0\0\0\6\1s\0\4\0\0\0:1.9\0\0\0\0\5\1u\0\26\0\0\0\7\1s\0\24\0\0\0org.freedesktop.DBus\0\0\0\0", iov_len=72}, {iov_base="", iov_len=0}], msg_iovlen=2, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 72
5507  <... poll resumed>)               = 1 ([{fd=3, revents=POLLIN}])
5504  epoll_wait(3,  <unfinished ...>
5507  write(4, "\1\0\0\0\0\0\0\0", 8)   = 8
5507  recvmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="l\2\1\1\0\0\0\0\t\0\0\0005\0\0\0\6\1s\0\4\0\0\0:1.9\0\0\0\0\5\1u\0\26\0\0\0\7\1s\0\24\0\0\0org.freedesktop.DBus\0\0\0\0", iov_len=2048}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 72
5507  write(4, "\1\0\0\0\0\0\0\0", 8)   = 8
5507  recvmsg(3, {msg_namelen=0}, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
5507  write(4, "\1\0\0\0\0\0\0\0", 8)   = 8
5507  poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, 0) = 1 ([{fd=4, revents=POLLIN}])
5507  read(4, "\3\0\0\0\0\0\0\0", 8)    = 8
5507  poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, -1

and that's it. No exits, no signals, no meaningful errnos other than EGAIN.

Initially I suspected something along "each test leaks some fd or memory D-Bus connection, and collectively they run out", but disabling a few other big tests doesn't change it. After disabling test_{api,cli,bluez5,code}.py, the run looks like

# python3 -m unittest -v
test_default_state (tests.test_gnome_screensaver.TestGnomeScreensaver.test_default_state)
Not locked by default ... ok
test_lock (tests.test_gnome_screensaver.TestGnomeScreensaver.test_lock)
Lock() ... ok
test_set_active (tests.test_gnome_screensaver.TestGnomeScreensaver.test_set_active)
SetActive() ... ok
test_airplane_mode (tests.test_gsd_rfkill.TestGsdRfkill.test_airplane_mode) ... ok
test_mainobject (tests.test_gsd_rfkill.TestGsdRfkill.test_mainobject) ... ok
test_accelerometer_available (tests.test_iio_sensors_proxy.TestIIOSensorsProxy.test_accelerometer_available) ... ok
test_accelerometer_claimed (tests.test_iio_sensors_proxy.TestIIOSensorsProxy.test_accelerometer_claimed) ... ok
test_accelerometer_claimed_properties_changes (tests.test_iio_sensors_proxy.TestIIOSensorsProxy.test_accelerometer_claimed_properties_changes) ... 

However, running the exact same set of tests explicitly works:

python3 -m unittest tests.test_gnome_screensaver tests.test_iio_sensors_proxy tests.test_iio_sensors_proxy -v

Disabling just test_accelerometer_claimed_properties_changes just makes it fail in the next one.

So @agx , sorry, this left me with a huge puzzle, and needs a lot more time thrown at it 😢

[martinpitt]

@agx ah, thanks for the update, that seems to have done it. I also just noticed that the pylint test started to fail 5 days ago, apparently after Fedora got a new pylint version. Also, bluez now added some console beautification, that needs a test adjustment. I'll fix that separately, then you can rebase.

(I haven't reviewed your changes yet, sorry)

[agx]

I could reproduce locally and

pytest tests/test_gsd_rfkill.py tests/test_iio_sensors_proxy.py

already failed. It seems the multiple calls to _get_gsdrfkill_objects confused it (although Idk why). Removing those and using the p_obj directly lets the following iio-sensor-proxy tests pass.

EDIT: it's the call to dbus.SessionBus(). Adding this makes the following iio-sensor-proxy test reliably fail.

[martinpitt]

@agx : Tests fixed in #224, so your next rebase should go green.

[agx]

@agx : Tests fixed in #224, so your next rebase should go green.

That worked. Thanks a lot for the help!

[martinpitt]

TBH this is the kind of "fairly easy/shallow" mock that I'd really rather intended to keep in the respective tests that use them -- for any concrete test that shouldn't be more than 10 lines or so.

But I suppose that ship has sailed with low_memory_monitor.py or gnome_screensaver.py, so it's hard to say no now 😁

So if that's somehow useful for you to maintain in this central location, ok!

Thanks!

[agx]

So if that's somehow useful for you to maintain in this central location, ok!

The major upside of having it upstream is that there are tests and that it makes it easy to use it from multiple projects. So if it's not too much of a burden having it merged would be great.