Twitter dropping support for basic auth

Description of problem:
It isn't getting my twitter timeline

Version-Release number of selected component (if applicable):
[Ankur@070905042 ~]$ rpm -q pino
pino-0.2.11-1.fc13.x86_64

How reproducible:
Always

Steps to Reproduce:
1.Add a twitter account to pino
2.select the twitter account and let pino get your timeline
3.

Actual results:
It gets stuck on "Getting updates".

Expected results:
Should get and update latest timeline

Additional info:
X

Problem is twitter has stopped supporting basic authentication. OAuth is not supported in pino yet. It is scheduled for pino 0.3 http://pino-app.appspot.com/index

So I guess it's time to push a snapshot in updates-testing and see how it goes...

I am not sure picking up a random snapshot of the day is really the answer to this. Does the latest HEAD support this at all? I have this discussed it with upstream and primary maintainer for Fedora here and it appears there is bad news

http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars/2

See the section on FOSS clients.

Rahul, surely I'd expect the maintainer and upstream to work more or less together on the thing in order to select an appropriate snapshot in time.

However, I also read the ars article today and it seems to be trickier than I'd expected, very sad.

In light of this:

"""Most FOSS client developers have simply chosen to embed their keys in their source code with the hope that Twitter won't notice. I was about to give up on Gwibber, but Canonical intervened on my behalf (special thanks to Ken VanDine) and negotiated a compromise with Twitter that will allow Gwibber to continue using the service."""

Can Fedora, Red Hat or someone else attempt to do the same for pino, after all, it's our default client.

Appropriate snapshot is an option if Pino has support for it and what if someone reads the source and sends it to Twitter? Twitter is going to block it as per their utterly broken scheme. As far as negotiating an exception, please bring it up to desktop or devel list. Maybe we can get one.

Marking as a blocker, as it's involves shipping a desktop app that does not work for one of it's main uses.

I'll update pino to the 0.3 snapshot this weekend for test purpose. Not sure if pino 0.3 can be finally released before F14 final freeze date.

Did you talk to upstream about picking up a snapshot and when the 0.3 release is scheduled?

(In reply to comment #9)
> Did you talk to upstream about picking up a snapshot and when the 0.3 release
> is scheduled?

I'll update pino 0.3 snapshot[1] in rawhide soon for test purpose if no one objects.

No sure if upstream has a such schedule currently since pino 0.3 is still under pre-alpha stage. I'll ask upstream for a release plan after pino 0.3 alpha is released.

[1]http://bitbucket.org/troorl/pino3

Is there any chance at all to backport the fix? (I'm guessing the port to oauth is nontrivial, so, no.)

(In reply to comment #11)
> Is there any chance at all to backport the fix? (I'm guessing the port to oauth
> is nontrivial, so, no.)

I don't know vala at all, but it seems it's almost impossible to backport features from pino 0.3 to pino 0.2 (from upstream pino 0.3 is a completely new project).

Ok. Please update rawhide to 0.3 snapshot so that we can test if it is in a shippable state for Fedora 14. Otherwise we will have to switch to Gwibber or not ship with a microblogging client. Inform upstream if necessary of our deadlines.

In my case pino stalls out on 'connecting.' Furthermore it refuses to exit, it has to be killed.

I'm trying out the 0.3 build on f14 beta
http://koji.fedoraproject.org/koji/buildinfo?buildID=195712

I note that my account info did not migrate to the new version, which is fair I suppose given the oauth thing. OAUTH validation isn't working (redirects to twitter, paste the code, click verify, ... nothing), but what should I expect from a random unreleased koji build ;)

(In reply to comment #13)
> Ok. Please update rawhide to 0.3 snapshot so that we can test if it is in a
> shippable state for Fedora 14. Otherwise we will have to switch to Gwibber or
> not ship with a microblogging client. Inform upstream if necessary of our
> deadlines.

It seems pino 0.3 can't be released before F14 final, I think we can ship Gwibber as the default twitter client for F14 (maybe we should split mx into more packages to save space on livecd).

Is there a problem shipping the snapshot? Is it unusable?

Hmm, well I tried pino-0.3-0.1.20100915hg.fc14 again and this time it managed to authenticate via OAUTH.

It is however very clunky and lacking functionality. Three of the four menu headings (Pino, View, and Help) are empty lists. Edit has one entry, New Account, which has sub-entries for identica and twitter.

I just tried to tweet with it and it doesn't seem to be working. There is a "sending statuses" notice that just keeps spinning.

The account pane on the side and a number of context menus that don't seem to actually function. In particular the "Settings" entry does nothing.

All in all, not a good user experience. I'm not a big fan of Gwibber, but it's better than this.

This was discussed at the blocker review meeting of 2010-10-01. It was accepted as a blocker under the criterion "All applications listed under the Applications menu must withstand a basic functionality test and not crash after a few minutes of normal use. They must also have working Help and Help -> About menu items". Desktop team, please either ensure pino is fixed somehow for final, or pick a twitter client that works, or don't ship one; the fix doesn't have to be to make pino work, any of the above is fine.

*** Bug 638984 has been marked as a duplicate of this bug. ***

I reported the same bug yesterday yesterday not realising one had already been filed (obviously my Bugzilla search-fu could do with an update). It hasn't been noted here yet, but pino-0.2.11-1 doesn't work with identi.ca either. Thought I'd mention it as I just saw a note on the desktop list from Jesse Keating saying:

  "From what I understand, pino also works with identi.ca,
  and there is no issues with the current version in F14 for
  doing that."

Alas, there is. I've tried numerous times since F14 Alpha was released and pino has never gotten past the "updating..." phase for either Twitter or identi.ca.

After seeing a report on the desktop mailing list that pino works fine with identi.ca I ran some more tests, deleting "~/.cache/pino" and "~/.config/pino" after each test so I was starting from a clean state. I was wrong: pino does indeed work fine if you're only using identi.ca, or if you make sure to not add a Twitter account *before* adding an identi.ca account.

I'll leave pino running with both accounts to see if it'll eventually hang as it was doing before.

Upgraded my desktop from F13 to F14 Beta and Pino works flawlessly with identi.ca. I also have configured there a twitter account which simply does not receive updates.

That being said, if we know the current snapshot doesn't work with twitter, is it worth shipping it over the 0.2.x stable version?

(In reply to comment #23)
> That being said, if we know the current snapshot doesn't work with twitter, is
> it worth shipping it over the 0.2.x stable version?

The current pino 0.3 can support Twitter's OAuth security system, but the snapshot is not even an alpha release. So I think it's not appropriate to ship pino 0.3 for F14 currently(we can push pino 0.3 as an update when possible), the pino 0.2 in Fedora can only log in identi.ca since 2010.9.1.

I don't think we should be shipping pino (either version) as is. Folks will be looking for a twitter client and pino is going to give them a bad impression of the distro in that department.

The gwibber in F14 has been working fine for me this past week.

 I sent comment on Desktop mailing list, but to clarify for users of this bug, the Gwibber 2.33 client in F13 updates-testing works fine with OAuth for Twitter, and identi.ca support.

 And the user interface update supports Twitter lists, and general other features Pino lacks.

 Original reason for removing Gwibber and moving to Pino was based on earlier couchdb and erland dependancies (20MB+ of dendancies). This no longer the case with the SQLite backend.

 Is there any logic in trying to push a broken Pino, or leaving the install with no client at all, when Gwibber is known to work?

Seconded. From a user experience point of view, pino makes Fedora look bad. Gwibber works and has a more polished UI, whereas pino's UI is less polished and more importantly only works currently if you (a) only use identi.ca or (b) don't add a Twitter account before adding an identi.ca account.

As the gwibber maintainer, I'd be okay with that.

it seems like we decided definitely not to ship pino, only decision left is whether to replace it with gwibber or replace it with a release note saying to try gwibber. :) can team please implement this in time for TC1 build on tuesday? Thanks!

pino has been made optional in comps. No other changes have been made at this point. Here is mclasen's most recent statement about it:

http://lists.fedoraproject.org/pipermail/desktop/2010-October/006574.html

If that's to be interpreted as the Desktop SIG's answer on what to do with the Live image, then it means the latter of comment #30's two choices. And I presume that would remove this bug from the F14Blocker list.

I suspect people will be rather disappointed if there is not a Twitter/Identi.ca client in the default install, but I'll defer to the Desktop SIG.

next steps
   1) add release note documenting the change (Fedora docs team), then ...
   2) confirm release note and remove from F14Blocker list (anyone)

(In reply to comment #33)
> next steps
> 1) add release note documenting the change (Fedora docs team), then ...
> 2) confirm release note and remove from F14Blocker list (anyone)

I'll be drafting this later this afternoon and will post the text so everyone will be able to make suggestions.

As soon as the comps change is made this ceases to be a blocker, we do not cover documentation in the blocker process at present.

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

spot: the desktop team's decision was made on the basis that it was too late to safely switch to gwibber and ensure there were no problems with its integration; they recognized that a working twitter client would be the *ideal* solution, but in practice it wasn't considered safe enough to switch at this late stage.

--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

The current state is: Pino 0.2 (current in F14) has connectivity issues with Twitter. There's an (alpha/beta) version out of Pino 3, which can work with Twitter, but it's still very rough, as mentioned in Comment 17. (even the 3-JAN-2011 release suffers most of these issues).

I'd very much propose to switch to a mature and stable microblogging client for F15: obvious candidates would be Gwibber or Turpial.

Can we get input from the Desktop Team? At this point in time, switching to Gwibber for F15 would be still possible...
--
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I think this bug can be closed by now with Gwibber as working alternative?

This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 14 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping