Tried Brandon's suggestion (and some others that I got privately), but no
luck. Also tried uninstalling and reinstalling git-review.
When I do "echo $PATH":
/usr/local/bin:/bin:/usr/bin:/Users/kaldari/bin:/usr/local/mysql/bin:/sbin:/usr/sbin:/usr/local/sbin:/usr/local/lib/php:/usr/local/php5/bin
which pip:
/usr/local/bin/pip
which easy_install:
/usr/local/bin/easy_install
which git-review:
/usr/local/bin/git-review
But 'git-review' or 'git review' still give the same stack trace. I'll try
asking in #git. Thanks for the suggestions!
On Wed, Oct 21, 2015 at 2:58 PM, Kevin Smith <ksmith(a)wikimedia.org> wrote:
> I'm a bit wikitech-l shy, but that looks very similar to this:
>
> http://www.gossamer-threads.com/lists/wiki/wikitech/481421
>
> Unfortunately, the solution didn't look all that satisfying to me, but
> maybe you can get something out of it.
>
>
>
> Kevin Smith
> Agile Coach, Wikimedia Foundation
>
>
> On Wed, Oct 21, 2015 at 1:47 PM, Ryan Kaldari <rkaldari(a)wikimedia.org>
> wrote:
>
>> Recently I upgraded my Mac to OSX 10.10.5 and upgraded a lot of other
>> stuff
>> in the process. But now I can't get git-review to work. Whenever I try to
>> run it, it gives the following stacktrace:
>>
>> Traceback (most recent call last):
>> File "/usr/local/bin/git-review", line 11, in <module>
>> sys.exit(main())
>> File "/Library/Python/2.7/site-packages/git_review/cmd.py", line 1522,
>> in
>> main
>> _main()
>> File "/Library/Python/2.7/site-packages/git_review/cmd.py", line 1377,
>> in
>> _main
>> (os.path.split(sys.argv[0])[-1], get_version()))
>> File "/Library/Python/2.7/site-packages/git_review/cmd.py", line 209, in
>> get_version
>> provider = pkg_resources.get_provider(requirement)
>> File
>>
>> "/Library/Python/2.7/site-packages/distribute-0.6.14-py2.7.egg/pkg_resources.py",
>> line 177, in get_provider
>> return working_set.find(moduleOrReq) or require(str(moduleOrReq))[0]
>> File
>>
>> "/Library/Python/2.7/site-packages/distribute-0.6.14-py2.7.egg/pkg_resources.py",
>> line 654, in require
>> needed = self.resolve(parse_requirements(requirements))
>> File
>>
>> "/Library/Python/2.7/site-packages/distribute-0.6.14-py2.7.egg/pkg_resources.py",
>> line 552, in resolve
>> raise DistributionNotFound(req)
>> pkg_resources.DistributionNotFound: git-review
>>
>> If I run "pip install --upgrade setuptools":
>> Requirement already up-to-date: setuptools in
>> /Library/Python/2.7/site-packages
>>
>> If I run "pip install -U git-review":
>> Requirement already up-to-date: git-review in
>> /Library/Python/2.7/site-packages
>> Requirement already up-to-date: argparse in
>> /Library/Python/2.7/site-packages (from git-review)
>> Requirement already up-to-date: requests>=1.1 in
>> /Library/Python/2.7/site-packages (from git-review)
>>
>> If I run "/usr/bin/easy_install --version":
>> distribute 0.6.14
>>
>> I couldn't find any solution on Google or in our git-review docs. Any
>> suggestions?
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
In the next RFC meeting, we will discuss the following RFC:
* Hygienic (heredoc) arguments for templates
<https://phabricator.wikimedia.org/T114432>
The meeting will be on the IRC channel #wikimedia-office on
chat.freenode.net at the following time:
* UTC: Wednesday 21:00
* US PDT: Wednesday 14:00
* Europe CEST: Wednesday 23:00
* Australia AEDT: Thursday 08:00
-- Tim Starling
As part of moving the Mobile Content Service to use Parsoid instead of
action=mobileview[1] I've ran into several missing features which make it
significantly harder for the Mobile Content Service to use Parsoid, while
providing the same functionality as before[2]:
(1) Parsoid does not follow redirects.
Automatic redirects (caused by page moves) will be (somewhat) handled by RB
infrastructure[3] soon, this does not yet cover manual redirects. Even then
it sounds like it would result in a 301 which the service would have to
deal with.
Manually (Community-) added redirects would have to be dealt differently by
parsing the Parsoid payload.
<link rel="mw:PageProp/redirect" href="..."/>
While we could overcome the redirect issues by following those redirects I
think this should be a Parsoid feature.
(2) <img> doesn't have srcset attributes with higher-res thumbnails. So,
image widening in the Android app wouldn't be feasible. While there is talk
about Parsoid potentially addressing this in the future I don't know the
timeline for this and don't see a good workaround for this from the service
side.
(3) No direct access to the spokenWikipedia audio files (from the
SpokenWikipedia templates).
A more general version of this is:
No direct access to transcoded audio / video files. [4] is the task in
question. This task is delayed in favor of adding <section> tags.
Theoretically the service could work around this by making another MW API
call. I just have not found it and I don't know how this is done for
action=mobileview. If anyone has a solution that actually works please let
me know. Exposing the spoken version of articles is one of our quarterly
goals.[5][6]
I think we should postpone the move to Parsoid until we have at least a
solution for issues #2 and #3. Subsequently, I've -2'd my patch[2] to move
the service to Parsoid.
Thanks,
Bernd
[1] https://phabricator.wikimedia.org/T108777
[2] https://gerrit.wikimedia.org/r/#/c/246100/
[3] https://github.com/wikimedia/restbase/pull/365
[4] https://phabricator.wikimedia.org/T64270
[5] https://phabricator.wikimedia.org/tag/mobile-app-goals/
[6] https://phabricator.wikimedia.org/T114525
The discussion on the Code of Conduct for technical spaces keeps
progressing, but there is one point where more feedback is would be
extremely useful. It's about this sentence, and whether it needs to stay in
the draft or be removed:
"Project administrators and maintainers have the right and responsibility
to take action on any communication or contribution that violates this code
of conduct."
The proposal for keeping it:
https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#New_proposal.2C_w…
Feedback from volunteer admins and maintainers (e.g. maintainers of an
extension or Gerrit users with +2 permissions) is especially welcomed
because a main point of contention is their responsibility when witnessing
actions of harassment in their projects. Opinions of other admins and
maintainers are very useful, since this sentence doesn't make distinction
between volunteers, professionals, or anything in between.
Needless to say, anyone can participate in this discussion, just like in
the other open discussions or new ones you want to create. The discussions
we are focusing on currently can be found at
https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Fine_tuning_the_n…
and the sections below. We are aiming to decide on them by the end of
Wednesday, and five minutes of your time commenting on any of them can make
a difference.
Thank you!
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
I've gone ahead and merged these two changes by TheDJ to MwEmbedSupport and
TimedMediaHandler extensions (they are interdependent):
* https://gerrit.wikimedia.org/r/#/c/172556/
* https://gerrit.wikimedia.org/r/#/c/172421/
These clean up how TMH's JavaScript modules get integrated into MediaWiki's
ResourceLoader, and should both reduce weird timing bugs and make it muuuch
easier to refactor things further.
It's worth checking these on the beta cluster; if all is well they can go
out to Wikimedia sites with the next branch point.
As an intermediary step, some weeks ago we merged this change to mark
parser output requiring video modules, so the standard RL caching _should_
mean everything keeps working on cached pages once the newer revs go live:
* https://gerrit.wikimedia.org/r/#/c/230153/
With all these going out, we'll be able to finalize work on integrating the
VideoJS player framework to replace our old hacked-up version of the
Kaltura player, and generally modernize and vastly improve the playback
experience.
-- brion
Hi all,
In addition to the security release for MediaWiki core earlier today, I'd
like to announce
security fixes available for the following 3 extensions:
* Extension:PageTriage - MediaWiki user Grunny discovered a DOM-based XSS in
the way the extension handled page titles.
<https://phabricator.wikimedia.org/T111029>
* Extension:Echo - Internal review discovered that Echo could display
deleted
or suppressed usernames when the username was previously used to Thank
users.
<https://phabricator.wikimedia.org/T110553>
* Extension:OAuth - Wikipedia user Sitic discovered that the OAuth extension
did not correctly enforce the IP restrictions of a Consumer when using
previously negotiated credentials.
<https://phabricator.wikimedia.org/T103022>
* Extension:OAuth - Wikipedia user Sitic discovered that OAuth would accept
a
valid signature from any Consumer when checking the authorization signature.
This allowed a registered Consumer who gained access to another Consumer's
users access tokens and secrets to use those credentials.
<https://phabricator.wikimedia.org/T103023>
**********************************************************************
Extension:PageTriage
**********************************************************************
Information and Download:
https://www.mediawiki.org/wiki/Extension:PageTriage
**********************************************************************
Extension:Echo
**********************************************************************
Information and Download:
https://www.mediawiki.org/wiki/Extension:Echo
**********************************************************************
Extension:OAuth
**********************************************************************
Information and Download:
https://www.mediawiki.org/wiki/Extension:OAuth
None of these extensions are bundled but they are in use on Wikimedia sites
hence
the announcement. Fixes are in all supported branches in Git and are thus
available
from ExtensionDistributor.
-Chad
_______________________________________________
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
Hi!
I'm working on a commenting platform for Wikipedia -- WikiComment -- and
would need some help with getting OAuth working there. If someone has a bit
of time to help me with that, then please let me know.
http://wikicomment.ut.ee/
With regards
Ivo Kruusamägi