I suppose, it might be some bug in getting the right authentication link from google. By the way, when you enter your credentials, google says it doesn't trust gwibber - and asks to press additionaly a confirmation button - may be here comes the problem with the link, as it catches some wrong address?

It worked only with the link :).
Both: publishing and previewing the Buzz content. I did not modified the /usr/lib/python2.6/dist-packages/gwibber/microblog/buzz.py, but also I've to say that I use the Gwibber from the official Gwibber repository (it's newer than the ubuntu's one).

Sorry about that. Its my first patch :). I created a single file containing all changes to both /usr/lib/python2.6/dist-packages/gwibber/lib/gtk/buzz.py and /usr/lib/python2.6/dist-packages/gwibber/microblog/buzz.py.

I am still getting errors and can't get messages, but I have never actually gotten Buzz to work with gwibber from my gmail account. Can someone look at the branch and verify it works for them and perhaps help figure out why it isn't working for me? Here are the errors I am getting:

It seams like gwibber stores its account information in unicode format and the hmac library does not accept unicode characters. A quick and dirty fix to the error you posted should be encoding the unicode strings into ASCII text. I have attached a bzr diff to your branch that does this.

There is no doubt a better solution to this error (maybe storing account information as ascii instead of unicode?).

In one post it is sugested that the error may be produced by the remote server not sending a notify before ending the tls connection. The following quote may be of interest:

Nikos said, "Several sites terminate the TLS connection without following the TLS protocol (i.e. sending closure alerts), but rather terminate the TCP connection directly. This is a relic of SSLv2 and it seems other implementations ignore this error. GnuTLS doesn't and thus prints this error. You could ignore it, but then you could not distinguish between a premature connection termination (i.e. by someone injecting a stray TCP termination packet) and normal termination."

Like i staded in an earlier post, the gnutls error itself does not seem to affectany functionality.

The encode to ascii fix was a poor one, but i ment it as an example as to where to start. It will fail if access_token or secret_token will contain a character with no equivalent in ascii:

u'ă'.encode('ascii') #this will fail

You could try to encode to UTF-8 instead of ascii, but i can't guarantee it will work. It gives no errors on my system, but neither did the ascii encoding, so i cant promise it will work. The author of the gwibber plugin may be able to find a more portable and less error prone fix.

"Thanks for your patch, unfortunately our busy developers haven't been
able to review your patch in a timely manor. The gwibber codebase has
seen significant change and it is likely this patch no longer applies.
Please review it again and if it is still applicable, update it to work
with the latest gwibber trunk. We will be doing a patch review day in
the next few weeks and would like to review your patch. Thanks again for
your contribution!"