Aran | 28 Aug 23:29 2014
Picon

Re: Parsoid

Thanks I was able to use the equivs package to get parsoid to run
properly - I also then found the following link in some fine print on MW
Parsoid/Setup page which works too:
https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager

On 28/08/14 12:46, Brad Jorsch (Anomie) wrote:
> On Thu, Aug 28, 2014 at 11:25 AM, Aran <aran <at> organicdesign.co.nz> wrote:
>
>> I'm trying to install parsoid on Ubuntu 12. I installed nodejs from
>> source, but when I try and install parsoid via apt-get it fails saying
>> that it depends on nodejs (>= 0.8.0) even though node --version returns
>> v0.10.31!
>>
>> Anyone have any ideas what could be wrong?
>>
> The package manager doesn't know anything about software you manually
> installed.
>
> The ideal thing to do would be to just install the nodejs package: I see
> Ubuntu trusty has 0.10.25, and Debian has 0.10.29 in both testing and
> unstable. You may be able to just download the source package and rebuild
> it for precise.
>
> Or you could try using the "equivs" package to fake out the package manager.
>
>

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
(Continue reading)

Gabriel Wicke | 28 Aug 18:23 2014
Picon

Re: Parsoid

On 08/28/2014 08:46 AM, Brad Jorsch (Anomie) wrote:
> On Thu, Aug 28, 2014 at 11:25 AM, Aran <aran <at> organicdesign.co.nz> wrote:
> 
>> I'm trying to install parsoid on Ubuntu 12. I installed nodejs from
>> source, but when I try and install parsoid via apt-get it fails saying
>> that it depends on nodejs (>= 0.8.0) even though node --version returns
>> v0.10.31!
>>
>> Anyone have any ideas what could be wrong?
>>
> 
> The package manager doesn't know anything about software you manually
> installed.
> 
> The ideal thing to do would be to just install the nodejs package: I see
> Ubuntu trusty has 0.10.25, and Debian has 0.10.29 in both testing and
> unstable.

+1 for using the regular package rather than a manual install from source.
Normally the right nodejs package should be automatically pulled in when you
install parsoid from the repository as described in [1]. What happens when
you just do a 'apt-get install nodejs' ?

Gabriel

[1]: https://www.mediawiki.org/wiki/Parsoid/Setup#Ubuntu_.2F_Debian_on_amd64

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
(Continue reading)

Aran | 28 Aug 17:25 2014
Picon

Parsoid

Hello,

I'm trying to install parsoid on Ubuntu 12. I installed nodejs from
source, but when I try and install parsoid via apt-get it fails saying
that it depends on nodejs (>= 0.8.0) even though node --version returns
v0.10.31!

Anyone have any ideas what could be wrong?

Cheers,
Aran

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Nkansah Rexford | 28 Aug 13:41 2014
Picon

Realtime common upload plugin - wordpress

Hi,

Is there any way to display images uploaded into a particular category on
Wikimedia Commons to be displayed in realtime on a WordPress site?

Like a plugin that follows a particular category on commons and displays
any images that are added to it? Kinda a feeder?

Thanks

Rexford | google.com/+Nkansahrexford | sent from Smartphone
_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Quim Gil | 27 Aug 23:40 2014
Picon

dev.wikimedia.org (was Re: build.wikimedia.org)

On Tuesday, August 26, 2014, MZMcBride <z <at> mzmcbride.com> wrote:

> Legoktm wrote:
> >This is now at [[dev.wikimedia.org]]? That sounds like a much better
> >name than "build", which I thought was going to be some CI automated
> >builds server from your email title :)
>

dev.wikimedia.org it is, yes. Moving on, please.

We
> already have a publishing platform that we can and should leverage and it
> lives at www.mediawiki.org
>

This is basically decided as well. However, we still need the best of our
technical knowledge to solve this problem: how to extract API documentation
from source code repositories and import it to wiki pages. Your ideas and
help are welcome -- see the ongoing discussion at
http://fab.wmflabs.org/T491

--

-- 
Quim Gil
Engineering Community Manager  <at>  Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Chris Steipp | 27 Aug 20:13 2014
Picon

OAuth and callbacks

For those who run one of our 76(!) approved OAuth apps, or are using
OAuth extension on their own wiki..

We have a patch [1] from Mitar to allow OAuth apps to pass a
configurable callback during the OAuth handshake. This will probably
make a lot of app author's lives easier, but can also open up a couple
avenues of abuse-- specifically, it's needed for covert redirect
attacks [2]. If OAuth app authors chose loose callback requirements,
which we can assume will happen if we make approvals automatic (bug
65750), and we ever allow public consumers (huggle was asking for that
for a long time), then it would be possible for attackers to abuse our
OAuth setup.

So far, I've been really conservative about how we use OAuth (there
are two other features we would have to enable to make this attack
likely). I'd like to hear other's thoughts about:

* Assuming we implement one or two of: dynamic callbacks, automatic
approval of apps, or public consumers, but not all three, which are
most desired?

* If we do implement all three, we can limit how the callback can
differ from what is registered. I put some suggestions on the gerrit
patch, but would that cause more confusion than help?

[1] - https://gerrit.wikimedia.org/r/153983
[2] - http://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html

_______________________________________________
Wikitech-l mailing list
(Continue reading)

Quim Gil | 27 Aug 09:18 2014
Picon

Simplest UI for creating & editing Phabricator tasks

Hi,

Users of the future Wikimedia Phabricator will have a very simple and
straightforward interface to create and edit tasks. Bugzilla's UI was one
of the top complaints from new/casual users, and we can fix this in
Phabricator easily. Currently we are testing this setup in fab.wmflabs.org,
where you can see an example:

http://fab.wmflabs.org/maniphest/task/create/ (imagine that the "Points"
field is not there).

Advanced users needing to prioritize tasks, assign them to someone, and
resolve them can join the Triagers team in order to get the additional
permissions:

http://fab.wmflabs.org/project/view/74/

We are still fine tuning this process at http://fab.wmflabs.org/T64 -- your
feedback is welcome.

--

-- 
Quim Gil
Engineering Community Manager  <at>  Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Markus Glaser | 27 Aug 02:02 2014

Pre-release announcement for MediaWiki releases 1.22.10 and 1.23.3

Hello everyone,

this is a notice that on 27th August between 20:00-22:00 UTC we will release maintenance updates for
current and legacy branches of the MediaWiki software. Downloads and patches will be available at that time.

Best, 
Markus
Wiki Release Team

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Bryan Davis | 26 Aug 21:43 2014
Picon

Call for reviewers: structured logging

Thanks to a lot of hard work by Antoine [0], Zuul and Jenkins are now
testing things using the mediawiki/vendor repository. This unblocks my
patches that implement PSR-3 logging for the structured logging RFC
[1]:

* Add a PSR-3 based logging interface -
https://gerrit.wikimedia.org/r/#/c/119940/
* Use MWLogger logging for legacy logging methods -
https://gerrit.wikimedia.org/r/#/c/119941/
* Use MWLogger logging for wfLogProfilingData -
https://gerrit.wikimedia.org/r/#/c/119942/
* Add logging context to database logs -
https://gerrit.wikimedia.org/r/#/c/141599/

I'd love to see these reviewed and merged. :)

[0]: http://www.gossamer-threads.com/lists/wiki/wikitech/498938
[1]: https://www.mediawiki.org/wiki/Requests_for_comment/Structured_logging
--

-- 
Bryan Davis              Wikimedia Foundation    <bd808 <at> wikimedia.org>
[[m:User:BDavis_(WMF)]]  Sr Software Engineer            Boise, ID USA
irc: bd808                                        v:415.839.6885 x6855

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Guillaume Paumier | 26 Aug 12:45 2014
Picon

Wikimedia engineering report, July 2014

Hi,

The report covering Wikimedia engineering activities in July 2014 is now
available.

Wiki version:
https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/2014/July
Blog version:
https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/

We're also proposing a shorter version of this report focusing on priority
goals for this quarter:
https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/2014/July/summary

Below is the HTML text of the report.

As always, feedback is appreciated on the usefulness of the report and its
summary, and on how to improve them.

------------------------------------------------------------------

Major news in July include:

   - a recap of how the Operations team collaborated with the RIPE NCC
   <https://blog.wikimedia.org/2014/07/09/how-ripe-atlas-helped-wikipedia-users/>
to
   measure the delivery of Wikimedia sites to users in Asia and elsewhere;
   - an analysis of the impact of the San Francisco data center
   <https://blog.wikimedia.org/2014/07/11/making-wikimedia-sites-faster/> on
   the speed of Wikimedia sites;
(Continue reading)

Petr Bena | 26 Aug 10:34 2014
Picon

Make port 22 on gerrit.wikimedia.org default for git (same as what 29418 is now)

gerrit.wikimedia.org is a default git gateway for all of wikimedia
projects, but it still has a number of issues compared to other (IMHO
better) providers, like GitHub.

One of major issues I am now having is, that git needs to be accessed
using non-standard port because regular ssh access is still being
served on port 22. This is a problem on restricted networks where
random ports are prohibited and blocked for various reasons, while
standard ports like 21, 22, 80 etc are open.

I propose to move the current ssh port (22) to some non-standard port,
as staff which needs to use it is far smaller than developer community
that needs to access git (the server itself is for git only) and open
port 22 as a gerrit (git) port. The current port 29418 can be used as
well, so that nobody needs to update their repo's which were already
cloned.

This is technically possible and I think it would make usage of gerrit
much less of a pain in the ****.

Thanks for your considerations :P

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Gmane