Bug 629192 - Twitter isn't functioning
Summary: Twitter isn't functioning
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: pino
Version: 14
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Filipe Rosset
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 638984 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-01 08:27 UTC by Ankur Sinha (FranciscoD)
Modified: 2012-08-16 22:15 UTC (History)
27 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-16 22:15:52 UTC
stickster: fedora_requires_release_note+


Attachments (Terms of Use)

Description Ankur Sinha (FranciscoD) 2010-09-01 08:27:11 UTC
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

Comment 1 Arun S A G 2010-09-01 08:31:09 UTC
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

Comment 2 Gianluca Sforna 2010-09-01 08:39:15 UTC
So I guess it's time to push a snapshot in updates-testing and see how it goes...

Comment 3 Rahul Sundaram 2010-09-02 18:46:49 UTC
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.

Comment 4 Gianluca Sforna 2010-09-02 21:04:19 UTC
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.

Comment 5 Gianluca Sforna 2010-09-02 21:11:36 UTC
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.

Comment 6 Rahul Sundaram 2010-09-02 21:34:52 UTC
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.

Comment 7 Bill Nottingham 2010-09-10 14:15:27 UTC
Marking as a blocker, as it's involves shipping a desktop app that does not work for one of it's main uses.

Comment 8 Chen Lei 2010-09-15 12:34:02 UTC
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.

Comment 9 Rahul Sundaram 2010-09-16 10:50:27 UTC
Did you talk to upstream about picking up a snapshot and when the 0.3 release is scheduled?

Comment 10 Chen Lei 2010-09-16 13:53:01 UTC
(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

Comment 11 Bill Nottingham 2010-09-16 15:18:33 UTC
Is there any chance at all to backport the fix? (I'm guessing the port to oauth is nontrivial, so, no.)

Comment 12 Chen Lei 2010-09-17 03:52:17 UTC
(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).

Comment 13 Rahul Sundaram 2010-09-20 06:06:43 UTC
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.

Comment 14 Mike McLean 2010-09-24 19:41:06 UTC
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 ;)

Comment 15 Chen Lei 2010-09-30 12:04:43 UTC
(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).

Comment 16 Rahul Sundaram 2010-09-30 14:29:43 UTC
Is there a problem shipping the snapshot?  Is it unusable?

Comment 17 Mike McLean 2010-09-30 21:25:50 UTC
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.

Comment 18 Adam Williamson 2010-10-01 18:05:58 UTC
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.

Comment 19 Destinatus 2010-10-01 19:03:03 UTC
*** Bug 638984 has been marked as a duplicate of this bug. ***

Comment 20 Destinatus 2010-10-01 19:17:24 UTC
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.

Comment 21 Destinatus 2010-10-01 21:14:30 UTC
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.

Comment 22 Nicu Buculei 2010-10-04 06:26:18 UTC
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.

Comment 23 Bill Nottingham 2010-10-04 15:28:57 UTC
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?

Comment 24 Chen Lei 2010-10-04 16:24:31 UTC
(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.

Comment 25 Mike McLean 2010-10-05 20:10:06 UTC
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.

Comment 26 Mike McLean 2010-10-05 20:11:06 UTC
The gwibber in F14 has been working fine for me this past week.

Comment 27 Dagan McGregor 2010-10-06 22:10:16 UTC
 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?

Comment 28 Destinatus 2010-10-06 22:26:16 UTC
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.

Comment 29 Tom "spot" Callaway 2010-10-07 17:24:58 UTC
As the gwibber maintainer, I'd be okay with that.

Comment 30 Adam Williamson 2010-10-08 17:03:39 UTC
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!

Comment 31 Paul W. Frields 2010-10-12 14:43:02 UTC
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.

Comment 32 Tom "spot" Callaway 2010-10-12 15:20:04 UTC
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.

Comment 33 John Poelstra 2010-10-12 15:30:30 UTC
next steps
   1) add release note documenting the change (Fedora docs team), then ...
   2) confirm release note and remove from F14Blocker list (anyone)

Comment 34 eric 2010-10-12 18:05:52 UTC
(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.

Comment 35 Adam Williamson 2010-10-12 20:07:27 UTC
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

Comment 36 Adam Williamson 2010-10-12 20:09:01 UTC
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

Comment 37 Mike B. 2011-01-05 08:58:05 UTC
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

Comment 38 Tim Niemueller 2011-04-21 22:35:25 UTC
I think this bug can be closed by now with Gwibber as working alternative?

Comment 39 Fedora End Of Life 2012-08-16 22:15:56 UTC
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


Note You need to log in before you can comment on or make changes to this bug.