Original report on Launchpad:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1008898

To try and give a bit more background on what's going on here.

We have a piece of python called nm.py in the Ubuntu Installer that talks over DBUS to Network Manager.

That piece of code was designed to work with both python2 and python3, however we noticed that it completely fails on python3 because of invalid signature.

The script can be found at: http://paste.ubuntu.com/1025375/
The workaround we applied is: http://paste.ubuntu.com/1025377/

Basically, with python2, the following:
self.manager.AddAndActivateConnection(obj, dbus.ObjectPath(device), dbus.ObjectPath(saved_path))

Would match the service signature of "a{sa{sv}}oo".

But the same code running with python3 doesn't as the objects appear to get downcasted to strings, before checking for the existing signatures.

This obviously makes the program crash as "a{sa{sv}}ss" (python3) != "a{sa{sv}}oo" (service).

(In reply to comment #0)
> Jun 5 08:00:19 ubuntu ubiquity[3109]: dbus.exceptions.DBusException:
> org.freedesktop.DBus.Error.UnknownMethod: Method "AddAndActivateConnection"
> with signature "a{sa{sv}}ss" on interface "(null)" doesn't exist

For D-Bus calls to be reliable, you should specify an interface (use dbus_interface=... in the call, or call the method via a dbus.Interface wrapper). I don't know whether that's what causes this signature mismatch or not, though; it's just best-practice.

When you introspect the object represented by self.manager, what do you get? (To find out, run "gdbus introspect --system -d org.freedesktop.NetworkManager -o /org/freedesktop/NetworkManager -x", assuming self.manager represents the /org/freedesktop/NetworkManager object on org.freedesktop.NetworkManager on the system bus.) I get this, among other things:

...
    <method name="AddAndActivateConnection">
      <arg name="connection" type="a{sa{sv}}" direction="in"/>
      <arg name="device" type="o" direction="in"/>
      <arg name="specific_object" type="o" direction="in"/>
      <arg name="path" type="o" direction="out"/>
      <arg name="active_connection" type="o" direction="out"/>
    </method>
...

OK, so this is actually a combination of two things.

(In reply to comment #3)
> For D-Bus calls to be reliable, you should specify an interface (use
> dbus_interface=... in the call, or call the method via a dbus.Interface
> wrapper).

Because you didn't do this, dbus-python couldn't correlate the signature of the method with the signature in the Introspect() result, and had to guess what you meant. Normally that'd be OK, because you used ObjectPath as a hint that you thought the service would expect object paths.

However, the signature-guessing function in dbus-python was broken for ObjectPath and Signature objects under Python 3, because those objects have changed from a subtype of the old meaning of str (= bytes) in Python 2, to a subtype of the new meaning of str (= unicode) in Python 3. I've fixed that in git, I'll attach a patch here.

The precedence is:

* using dbus.SomeType (lowest)
* Introspect() result
* signature="..." (highest)

If dbus-python wasn't constrained by backwards-compatibility, the signature would be required (like it is in GDBus), but unfortunately that's not really an option.

Created attachment 62596 [details] [review]
Py3: correctly guess the signature of ObjectPath(...) and  Signature(...)

Under Python 2, ObjectPath and Signature are subtypes of str (= bytes),
and the existing type-guessing worked.

The type-guessing code assumed that all unicode objects were just
strings, but that assumption became false in the Python 3 port:
ObjectPath and Signature are still subtypes of str, but str now means
unicode, not bytes.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=50740