Code review comment for lp://staging/~barry/ubuntuone-storage-protocol/lp1077092

Phew! That was a fun one to track down and fix. ;)

Let's start by disabling the dbus auto-restart of the ubuntuone-syncdaemon on
a production system. You have to do this or the `u1sdtool -q` command is
ineffectual. It does quit the daemon, but dbus re-activates it so the one in
bin/ubuntuone-syncdaemon will never be able to start.

The easiest way I found for doing this was to comment out the Name and Exec
lines in /usr/share/dbus-1/services/com.ubuntuone.SyncDaemon.service, then
kill -HUP dbus to re-read its service files. Now when you `u1sdtool -q`, it
kills the running syncdaemon and dbus won't restart it.

On Feb 07, 2013, at 12:13 AM, Alejandro J. Cura wrote:

>I'm trying to run both branches together like this:
>(make sure to ./run-tests in the u1sp branch first, so protobuf files get generated).
>
>alecu@bollo:~/canonical/ubuntuone-client/review_lp1077089$ u1sdtool -q; PYTHONPATH=.:~/canonical/ubuntuone-storage-protocol/review_lp1077092/ ./bin/ubuntuone-syncdaemon --debug
>
>The syncdaemon debug log shows that the authentication fails when using the
>new branches, and I'm able to authenticate using the system's syncdaemon, so
>there must be something that's working differently.

Yep. It turns out that I was confused by the confusing differences in
nomenclature. python-oauth uses the older terms "consumer" and "access token"
while python-oauthlib uses the RFC 5849 terms "client" and "resource owner".
When doing the conversion between the two regimes, I got them backwards and
was passing the first four arguments to oauthlib's Client constructor in the
reverse order.

This should now be fixed. I've updated the LP: #1077092 merge proposal branch
for the correct order in client.py, and it looks to me like both the tests
pass, and the cross-branch test you describe above successfully connects.

Hopefully this resolves any outstanding issues with the two branches, but
please let me know if it's still not working!