-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bluez5: Remove incorrect variant levels. #214
bluez5: Remove incorrect variant levels. #214
Conversation
I verified the expected types by comparing the output of Some properties should be defined as |
eba1a76
to
ef5810b
Compare
Ugh -- seems I have misunderstood D-Bus properties forever. The D-Bus spec says that all properties have to be wrapped into a variant -- the .Get() and .Set() APIs take/give variants only. Also, dbus docs say that But apparently somewhere along the line the variant gets added/stripped. So this indeed doesn't just affect bluez5, but all other templates as well. I'll land this, and then send a follow-up PR for fixing all the others. Thanks for pointing out! |
tests/test_bluez5.py
Outdated
adapter = self.dbus_con.get_object("org.bluez", path) | ||
|
||
adapter_prop_types = _introspect_property_types(adapter, "org.bluez.Adapter1") | ||
assert adapter_prop_types == { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be self.assertEqual()
for better failures.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, good point. I'm used to running tests with pytest
which produces nice failure messages as it rewrites the assert
statements internally. Will change it to self.assertEqual()
for consistency.
ef5810b
to
4d8378b
Compare
Oh, you were quick -- I already fixed that locally and did some other minor cleanups. I'll also push the "fix the rest" commit right here, this really belongs together. I'll take it from here, thanks! |
The levels were set too high, causing introspection to return type 'v' for all properties, which is incorrect and not matching the BlueZ API. Additionally, some DBus clients (such as dbus-next) perform type validation at runtime and refuse to process such mismatching properties. This removes the variant levels and adds a unit test to ensure the introspection details returned by the mocks match the expected API.
To be fair, I've looked at those docs multiple times and could never quite make sense of the I only noticed something was wrong when I used |
The previous commit only fixed the bluez template, but this was a general misunderstanding of how D-Bus properties work. They are defined as variants, but the API already wraps/unwraps them.
4d8378b
to
118b73e
Compare
@fkleon Right, seems I fell into the same trap. It seems the usual client libs magically unwrap the extra variant transparently then, as this never came up before. But I confirmed with The rawhide NM hang is unrelated, I'll look at that separately. Thanks! |
The levels were set too high, causing introspection to return type 'v' for all properties, which is incorrect and not matching the BlueZ API.
Additionally, some DBus clients (such as dbus-next) perform type validation at runtime and refuse to process such mismatching properties.
This removes the variant levels and adds a unit test to ensure the introspection details returned by the mocks match the expected API.