TpCMParamSpec password_spec =
         { "password", DBUS_TYPE_STRING_AS_STRING, G_TYPE_STRING,
-          TP_CONN_MGR_PARAM_FLAG_REQUIRED | TP_CONN_MGR_PARAM_FLAG_SECRET,
+          TP_CONN_MGR_PARAM_FLAG_SECRET,
           NULL, 0, NULL, NULL,
           (gpointer) "password", NULL };

you should also change this:


 480     /* Password parameter: */
 481     if (!(self->priv->prpl_info->options & OPT_PROTO_NO_PASSWORD))
 482     {
 483         if (self->priv->prpl_info->options & OPT_PROTO_PASSWORD_OPTIONAL)
 484             password_spec.flags &= ~TP_CONN_MGR_PARAM_FLAG_REQUIRED;
 485         g_array_append_val (paramspecs, password_spec);
 486     }

(In reply to comment #1)
> you should also change this:

Good point, done.

I changed this to depend on TpSimplePasswordManager and the diff got magically smaller.

TpSimplePasswordManager is in bug #31900 which this bug now depends on.

+  if (error != NULL)
+    {
+      DEBUG ("Simple password manager failed: %s", error->message);
+
+      tp_base_connection_change_status (base_conn,
+          TP_CONNECTION_STATUS_DISCONNECTED,
+          TP_CONNECTION_STATUS_REASON_AUTHENTICATION_FAILED);

Could we use tp_base_connection_disconnect_with_dbus_error() to give more details of what happened? We could have a code for “Needed a password, but you didn't give me one” maybe.

(In reply to comment #4)
> Could we use tp_base_connection_disconnect_with_dbus_error() to give more
> details of what happened? We could have a code for “Needed a password, but you
> didn't give me one” maybe.

We could, and I have. I left the details a{sv} empty as getting it from the channel might be a little odd. I'll ask the question in the tp-glib bug.

Look fine then. Ship it when the tp-glib stuff exists.

Hiiyaaa Will, so tp-glib 0.13.8 was just released with TpSimplePasswordManager in it, innit. I added a couple more patches to my branch. Do you still accept?

captain shippit has entered the building.

ta