[00:04:58] <sumanah>	 OrenBochman: hi, how are you doing?
[00:05:30] <OrenBochman>	 i'm ok
[00:05:34] <OrenBochman>	 how are you ?
[00:05:57] <sumanah>	 I'm okay - glad the storm has passed here in NYC
[00:06:12] <OrenBochman>	 ;-)
[00:06:25] <OrenBochman>	 I'm glad u got power!
[00:08:37] <sumanah>	 Thanks!
[00:08:48] <sumanah>	 ori-l: I laughed at your line about a choice of UI disasters
[00:09:04] <OrenBochman>	 anyhow I should be getting a new machine soon
[00:09:15] <sumanah>	 oh, nice
[00:10:36] <ori-l>	 sumanah: i'm one of those people who pushes elevator buttons multiple times when i'm in a rush, as though that makes the elevator faster. i think eclipse might serve the same purpose for me. you can't turn it into a nice environment, but you have lots of configuration controls and knobs to channel frustration into.
[00:10:43] <sumanah>	 HA
[00:11:07] * sumanah  considers the multiple meanings of the verb "tweaking"

[00:11:10] <OrenBochman>	 err eclipse is hackable
[00:11:24] <robla>	 ori-l: little topic switch:  could the event logging stuff have had an effect on the job queue?
[00:11:47] <robla>	 here's the job queue graph: https://gdash.wikimedia.org/dashboards/jobq/deploys .  look at the second to last graph on this page
[00:12:04] <ori-l>	 robla: at the risk of hubris, no
[00:12:08] <robla>	 job handling fell off a cliff right around the time THM and the Event logging code went out
[00:12:27] <ori-l>	 nothing's using it to log events and all the php code does is declare the JS bits as an RL module
[00:12:38] <robla>	 I suspect it's probably TMH-related, but I figured I better ask
[00:13:42] <ori-l>	 it's probably a bad sign that i'm the go-to guy when mysterious bugs crop up
[00:13:56] <ori-l>	 but really, no -- i can't see any point of connection between the two
[00:14:41] <robla>	 ori-l: well, the problem starting showing about 3 minutes after the event logging deployment.  However, it happened 1 minute after the second of two TMH deployments
[00:16:23] <robla>	 so...not entirely grasping at straws  :)
[00:17:18] <ori-l>	 i'm tempting the furies by rejecting this strenuously, but i honestly can't come up with even an implausible story about how the two are related. it's possible that some other aspect of the deployment triggered it, but i can't see how the eventlogging code would be related. do you have a hunch?
[00:19:47] <robla>	 I think Aaron and Asher are discussing in #wikimedia-operations now
[00:20:56] <binasher>	 robla: what we're discussing is the new jobqueue implementation, which needs some fixing
[00:21:08] <binasher>	 but its only live on wikidatawiki and test/test2wikis
[00:21:15] <robla>	 yeah, just trying to catch up on the backlog
[00:22:39] <binasher>	 robla: just catching up here.. are you concerned about the drop in overall job activity based on the graph or on user reports?
[00:23:16] <robla>	 binasher: the drop in activity combined with a creeping backlog on enwiki
[00:23:23] <robla>	 http://ganglia.wikimedia.org/latest/graph_all_periods.php?c=Miscellaneous%20pmtpa&h=spence.wikimedia.org&v=506&m=enwiki_JobQueue_length
[00:23:48] <robla>	 that has usually been the telltale sign that the job runners aren't running jobs
[00:23:48] <binasher>	 robla: how do the job runners handle multiple mediawiki versions?
[00:24:22] <robla>	 well, now that you mention it, possibly quite poorly
[00:24:44] <binasher>	 min(job_timestamp) on enwiki is 20121030002259
[00:24:46] <robla>	 it may rely on the previously true fact that the job runners didn't change much
[00:25:11] <binasher>	 when did 1.21wmf3 go out?
[00:25:19] <binasher>	 AaronSchulz: ^^
[00:25:27] <robla>	 a day or so earlier
[00:25:35] <robla>	 so I suppose that's probably not likely
[00:25:44] <robla>	 (not the likely cause, that is)
[00:27:11] <binasher>	 Aaron|home: ^^
[00:28:33] <Aaron|home>	 monday
[00:29:21] <robla>	 binasher: Oct 29 - 19:36 logmsgbot_: reedy rebuilt wikiversions.cdb and synchronized wikiversions files: testwiki and mediawikiwiki to 1.21wmf3
[00:29:48] <robla>	 15:41 logmsgbot_: reedy rebuilt wikiversions.cdb and synchronized wikiversions files: test2wiki to 1.21wmf3
[00:29:48] <robla>	 15:40 logmsgbot_: reedy synchronized php-1.21wmf3 'Initial file sync-out'
[00:32:49] <ori-l>	 am i officially not a witch? i have a giant code review to complete
[00:33:28] <robla>	 ori-l: not officially, but we're postponing the drowning test
[00:33:43] <robla>	 :)
[00:33:43] <ori-l>	 :)
[00:34:41] <Reedy>	 ori-l: you really need to stop writing so much php code
[00:36:35] <ori-l>	 you joke, but those ten-odd lines are ten more than i would have it
[00:37:25] <Reedy>	 Copy paste it all into MediaWiki:Common.js
[00:47:19] <robla>	 Aaron|home: I think, based on chrismcmahon's comments, that we're probably going to need to postpone the TMH deployment, even if j^'s fix is deployed and confirmed to fix the thumb problem
[00:48:47] <robla>	 unfortunately, the only viable time available is right during the wikidata sync up
[00:49:02] <robla>	 (without postponing until next week)
[00:50:10] <binasher>	 ah hah
[00:50:28] <Aaron|home>	 binasher: hm?
[00:50:38] <binasher>	 enwiki jobs are running, but only enotifNotify jobs
[00:51:02] <binasher>	 most of what's in the queue are refreshLinks2 jobs
[00:51:36] <binasher>	 this was the last time one of those were started:
[00:51:36] <binasher>	 2012-10-30 16:38:06 fenari enwiki: refreshLinks2 Wikipedia:Administrator_intervention_against_vandalism/TB2
[00:51:55] <binasher>	 it never finsihed
[00:52:04] <binasher>	 everything at the start is also for Wikipedia:Administrator_intervention_against_vandalism
[00:52:09] <binasher>	 note that job was started from fenari
[00:52:20] <Reedy>	 Most likely me, I think
[00:53:46] <Reedy>	 So all teh job runners decided to stop doing anything that isn't enotif jobs at midnight?
[00:53:54] <binasher>	 oh no, my bad
[00:53:59] <binasher>	 2012-10-31 00:40:49 mw9 enwiki: enotifNotify Wikipedia:Administrator_intervention_against_vandalism/TB2 editor=HBC
[00:54:33] <ori-l>	 hexmode: i think you misunderstood my email..
[00:54:55] <hexmode>	 oh, look, there I am ;)
[00:55:09] <hexmode>	 ori-l: completely possible
[00:55:15] <hexmode>	 sorry?
[00:55:28] <ori-l>	 i have no special love for eclipse; i suggested it precisely because it works with gerrit. gerrit is where your reviews end up; they're viewable / editable from the web interface.
[00:55:38] <ori-l>	 np!
[00:56:09] <hexmode>	 ori-l: I only skimmed and didn't see thta you said that.
[00:56:22] <binasher>	 Reedy: oh, that was enotifNotify for that vandalism thingy.. yeah, no enwiki refreshLinks2 jobs have run since 2012-10-30 16:38:06 fenari enwiki: refreshLinks2 Wikipedia:Administrator_intervention_against_vandalism/TB2 table=templatelinks
[00:56:52] <Reedy>	 which I guess is why the first job in the enwiki queue is timestamped about 00:30
[01:07:50] <binasher>	 ahh
[01:10:23] <binasher>	 no wiki at all has run refreshLinks2 jobs from an actual jobrunner since 2012-10-30 00:33:23
[01:16:39] <binasher>	 htmlCacheUpdate is broken too
[01:17:23] <binasher>	 the job runners make no attempt at all to run any of these
[01:17:40] <Aaron|home>	 so the "default queue" jobs are broke but the priority ones work?
[01:18:23] * binasher  stares at TimedMediaHandler

[01:19:57] <Reedy>	 I guess we could disable TMH for a bit...
[01:20:01] <Reedy>	 and then revert it back to the start of time
[01:21:16] <binasher>	 the first part is at least worth trying now :)
[01:21:27] <binasher>	 and on that note, i need to take off
[01:22:10] <binasher>	 let me know somehow if that gets the jobs jobbing
[01:26:41] <Reedy>	 Looks like it's still only doing enotifNotify jobs...
[01:48:06] <Reedy>	 XMLHttpRequest cannot load http://meta.wikimedia.org/wiki/Special:RecordImpression?banner=2012EditorSu…rvey2012&userlang=en&db=wikidatawiki&sitename=Wikidata&country=GB&bucket=1. Origin http://www.wikidata.org is not allowed by Access-Control-Allow-Origin.
[01:48:30] <ori-l>	 Reedy: i beat you by several minutes :P
[01:48:45] <ori-l>	 proudest moment of my life
[01:48:49] <Reedy>	 Say who where what now?
[01:49:00] <ori-l>	 i want to thank my parents, ..
[01:49:33] <ori-l>	 on #wikimedia-fundraising. using document.createElement('img').src = "http://..." works.
[01:50:06] <Reedy>	 I did not see it, ergo there is no proof.
[01:50:07] * Reedy  grins

[01:51:04] * ori-l  shakes fist.

[01:51:24] <Reedy>	 And on HTTPS it gives Uncaught TypeError: Cannot read property 'name' of undefined
[01:51:59] <Reedy>	 I'll let you make people fix it then ;)
[01:52:17] <ori-l>	 there's an old bugzilla ticket to send CORS headers
[01:52:50] <ori-l>	 as a more general solution to requests across wmf properties
[01:56:21] * robla  reads backlog after learning that TMH was disabled...

[01:57:36] <robla>	 Reedy: TMH doesn't seem to be the culprit based on my read of things, and we really need to have it in production
[01:58:38] <Reedy>	 https://gdash.wikimedia.org/dashboards/jobq/
[01:58:48] <Reedy>	 We've got a lot more jobs suddently queued.. :/
[01:59:00] <Reedy>	 I'll re-enable it
[02:01:01] <robla>	 Reedy: hrm....well....let's hold off a little bit I guess
[02:01:21] <Reedy>	 said 1 second before it completed...
[02:01:22] <Reedy>	 lol
[02:01:35] <robla>	 Reedy: well, I'm waffling anyway
[02:01:39] <Reedy>	 it was off nearly 40 minutes
[02:01:51] <robla>	 yeah, that's what occurred to me right after I typed that
[02:02:13] <robla>	 we're probably seeing a normal enotif spike
[02:02:52] <robla>	 750 is still low by normal standards
[02:07:15] <robla>	 Reedy: go ahead and get some sleep.  TimStarling: we might need you to poke at this for a little bit
[02:08:10] <robla>	 gotta get out of the office myself in a few minutes, but I'll get back online later
[11:30:01] <hashar>	 so spent the morning trying to cleanup our newParserTests
[11:30:11] <hashar>	 that is a real mess and I give up :-]
[11:30:18] <hashar>	 too manyh hacks
[11:30:56] <^demon>	 Been there. Tried that.
[11:31:13] <hashar>	 might just rewrite it from scratch
[11:31:54] <hashar>	 anyway I found out it setup a whole environment before each tests
[11:31:54] <hashar>	 and delete it after
[11:32:08] <hashar>	 including clearing any caches / setup a filerepo etc ...
[11:32:08] <hashar>	 definitely slow :(
[11:36:37] <DanielK_WMDE_>	 hi hashar, ^demon
[11:38:16] <^demon>	 Hey DanielK_WMDE_
[12:25:54] <hashar>	 ^demon: does the Gerrit debian packages contains the openstack patch ?
[12:26:01] <hashar>	 or did you install a new war manually ?
[12:26:58] <^demon>	 Our last two installs have been custom wars, not from debian (which is why we swapped it for ensure => present instead of pinning the version)
[12:27:07] <^demon>	 All built from our stable-2.4-wmf branch
[12:27:25] <hashar>	 I thought we had a Gerrit package
[12:27:40] <hashar>	 any idea where I can get the production .war from?
[12:27:50] <^demon>	 We do, but it does practically nothing other than create the gerrit2 user.
[12:28:08] <^demon>	 I had a copy on noc. Lemme stash it there again for you.
[12:30:28] <^demon>	 hashar: http://noc.wikimedia.org/~demon/gerrit-2.4.2-2-ge9a1970.war
[12:31:35] <^demon>	 hashar: If you're ever interested in building our custom war, you can clone gerrit.wm.o/operations/gerrit -b stable-2.4-wmf && mvn package -Dgerrit.include-documentation=1 -Dgwt.style=pretty
[12:32:00] <hashar>	 ^demon: is that on wikitech ? ;-]
[12:32:04] <anomie>	 Hmm. Changeset 16872 depends on another changeset that still has issues, and "Gerrit Code Review" is spamming the log trying to submit it and failing every half hour. Is there a way to "unsubmit" in Gerrit, or some other way to handle this?
[12:32:13] <anomie>	 (note to self, check dependencies next time)
[12:32:26] <^demon>	 hashar: Nope. I plan on making some auto-build thingie for jenkins at some point. Just haven't gotten around to it.
[12:32:35] <^demon>	 anomie: Change your review to -2
[12:32:45] <^demon>	 (Or otherwise remove your +2)
[12:33:26] <anomie>	 ^demon- thanks
[12:33:39] <^demon>	 The "automatic retrying" is kind of nice behavior, if it didn't spam.
[12:33:56] <anomie>	 I didn't know whether that would work, and I thought I'd just ask instead of fooling around hoping something would work.
[12:38:52] <^demon>	 hashar: Gitblit plugin passed review upstream and will be usable for 2.5 :)
[12:39:06] <^demon>	 As did the <canvass>-based "network graph" (a la Github)
[12:39:11] <hashar>	 nice!!
[12:39:19] <hashar>	 can't wait for them
[12:39:37] <^demon>	 Me too. I've been trying to find a way around the LDAP issue so we're not still blocked on upgrade.
[12:39:42] <hashar>	 ^demon: apt-get install gerrit  does provide me a gerrit.war in /var/lib/gerrit2 :-]
[12:39:49] <hashar>	 probably outdated though
[12:40:04] <^demon>	 2 versions behind.
[12:40:18] <hashar>	 can't we update the deb package to ship the new war ?
[12:40:31] <^demon>	 Bug Ryan :\
[12:40:36] * hashar  gives up

[13:10:58] <hashar>	 ^demon: I did a very minor edit on wikitech https://wikitech.wikimedia.org/view/Gerrit#Custom_package
[13:11:33] <^demon>	 I'm going to tweak, minor difference.
[13:13:26] <hashar>	 and kudos on replicating the extensions to GitHub
[13:13:46] <hashar>	 448 repos, 11 members
[13:13:47] <hashar>	 doh
[13:21:21] <^demon>	 JeroenDeDauw: I've created SemanticExtraSpecialProperties for you (empty). If you want to go ahead and push the existing github history, that'd be great.
[13:21:35] <^demon>	 (Not having a HEAD will make L10n-bot explode)
[14:00:28] <^demon>	 hashar: https://gerrit-review.googlesource.com/#/c/38952/ \o/
[14:00:33] <^demon>	 About. Time.
[14:00:53] <hashar>	 ^demon: the java gc ?
[14:01:07] <^demon>	 Yeah. jgit 2.1.0 supports gc now :)
[14:01:16] <hashar>	 nice
[14:16:08] <Nemo_bis>	 aww despite what above, after reading http://lists.wikimedia.org/pipermail/wikitech-l/2012-October/064160.html for a moment I thought ^demon fixed https://bugzilla.wikimedia.org/show_bug.cgi?id=40331
[14:16:45] <^demon>	 If I'm talking about replication, I mean git replication.
[14:16:52] <^demon>	 I haven't done anything re: 40331.
[14:20:36] <JeroenDeDauw>	 DanielK_WMDE: you want haz review https://gerrit.wikimedia.org/r/#/c/30984/
[14:20:52] <JeroenDeDauw>	 ^demon: ok, I'll do that now
[14:21:01] <JeroenDeDauw>	 Don't want Nikerabbit and siebrand to lynch me to much :)
[14:21:15] <^demon>	 :)
[14:35:12] <hashar>	 ^demon: got a Gerrit question for ya :-]
[14:35:37] * ^demon  hides

[14:35:40] <^demon>	 What's up? :)
[14:35:42] <hashar>	 ^demon: with zuul, whenever a change is submitted, it will fetch the change, merge it on latest master and push the result to refs/for/refs/zuul/<some random sha1>
[14:35:56] <hashar>	 with the amount of changes we have, I am afraid it can fill up the git database very quickly
[14:36:16] <hashar>	 but will let us fetch the code Jenkins actually tested
[14:36:39] <hashar>	 pushing the refs/for/refs/zuul/ back in Gerrit is optional though, I could disable it if that might be a problem
[14:36:57] <^demon>	 I don't see a problem, but I'm not entirely sure what the purpose is.
[14:37:34] <hashar>	 once the refs is pushed, jenkins will grab it from Gerrit repository iirc
[14:38:32] <^demon>	 I'm still not understanding. Is there some documentation for this?
[14:38:55] <hashar>	 http://ci.openstack.org/zuul/triggers.html#zuul-references
[14:39:09] <hashar>	 I will disable it
[14:39:23] <hashar>	 zuul already keep a copy in the local file system
[14:39:28] <hashar>	 and I have setup the Jenkins jobs to use that
[14:39:38] <hashar>	 less troubles this way
[14:39:55] <^demon>	 Yeah, let's not push it back to gerrit.
[14:40:02] <^demon>	 Then I'd have to configure replication to skip it.
[14:40:42] <^demon>	 If it becomes necessary, I can't see a huge problem in us turning it on space-wise (we're only 13% full on ./review_site/git)
[14:41:48] <hashar>	 I agree
[14:41:52] <hashar>	 we can turn that on later
[14:43:14] <^demon>	 Haha, so two of my ideas to improve the project listing page (show projects you've used recently & add a search box) both just got pushed to master for review upstream.
[14:43:18] <^demon>	 Great minds think alike?
[14:43:56] <^demon>	 I should pull & try it out
[15:00:29] <thedj[work]>	 i guess there is little we can do about the gitweb speed is there ?
[15:00:55] <^demon>	 Replace it.
[15:01:01] <^demon>	 (Which we're doing as soon as we upgrade to 2.5)
[15:01:11] <thedj[work]>	 with what ?
[15:01:11] <^demon>	 Gitblit.
[15:01:25] <^demon>	 Live demo: https://demo-gitblit.rhcloud.com/
[15:02:02] <thedj[work]>	 ah, that's what github uses ?
[15:02:42] <^demon>	 I don't believe so.
[15:03:29] <^demon>	 We are going to use a new network graph plugin (which is very much like the github network graph)
[15:04:47] <Nikerabbit>	 JeroenDeDauw: :O
[15:04:52] <Nikerabbit>	 why would I lunch you
[15:05:16] <^demon>	 thedj[work]: As far as "speeding up gitweb" -- I'm not sure it's even possible. Gitweb it a piece of crap :(
[15:16:02] <Krenair>	 Can someone please review this one line timestamp-related fix? https://gerrit.wikimedia.org/r/#/c/24301/
[15:18:56] <hashar>	 ^demon: zuul on labs: http://integration.wmflabs.org/zuul/status  ;-]
[15:19:09] <hashar>	 ^demon: will show up what Zuul is doing :-D
[15:21:59] <Raymond_>	 Krenair: done
[15:22:33] <Krenair>	 Raymond_, thank you
[15:22:44] <Raymond_>	 you are welcome
[15:56:16] <Tuxedo_>	 I have so far not written any MW extension and have no idea of the best way to do the following: ...
[15:57:30] <Krenair>	 Tuxedo_, ..?
[15:57:46] <Tuxedo_>	 I have a fairly small bit of JS in placed in Common.js and would to add an option to place some kind of markup on any pages which calls the function with parameters. It's a fairly trivial and minimial js that just affects/toggles some on-page visuals, so even if the availability of the function loads on all pages of my wiki, it makes no difference.
[15:58:08] <Tuxedo_>	 What is the best method? Callback functions, hooks, magic words or simply a template? Or some existing extension? ...
[15:58:47] <Tuxedo_>	 Any pointers in a right direction would be appreciated.
[16:05:54] <chrismcmahon>	 Tuxedo_: you should probably ask again in about 30-60 minutes, most of the people who can help you will be appearing on IRC in a little while
[16:06:22] <Tuxedo_>	 Ahh, thanks for the tip.
[16:07:12] <chrismcmahon>	 Tuxedo_: no problem!  I wish I were more help, but I'm not an expert and I'd hate to tell you the wrong thing
[16:37:29] <JeroenDeDauw>	 Nikerabbit: o_O
[17:04:06] <Tuxedo_>	 I've not written any MW extension before and I just need some general directions before I go wondering in all the wrong directions:
[17:04:06] <Tuxedo_>	 I have a small bit of JS added in Common.js and would to the option of placing some kind of wiki-markup on selected pages to call the js-function with parameters. It's a trivial and minimial JS-block. The output is non-language specific, just a universally recognisable graphic click-on symbol which dynamically affects/toggles some on-page visual through js/css manipulation where needed on specific article pages.
[17:04:06] <Tuxedo_>	 Even if the function loads in the Common.js file that is returned across the whole wiki it's no major issue, as it's only small bit of code.
[17:04:07] <Tuxedo_>	 What is the best method for acheiving this? Callback functions, hooks, magic words or/and a template? Or the use of some existing extension? If so, which?
[17:04:08] <Tuxedo_>	 Many thanks for any pointers!
[17:05:20] <ori-l>	 Tuxedo_: could you simply add to your script some code to add an element to the page?
[17:06:07] <Nikerabbit>	 JeroenDeDauw: what??
[17:07:40] <Tuxedo_>	 ori-l: Yes, by identifying the document.location.href, but I still don't know how to call the script from a onclick function on the page.
[17:09:05] <ori-l>	 Tuxedo_: can you paste your JS code somewhere? dpaste.de perhaps? (not the channel)
[17:09:07] <Tuxedo_>	 I can't just add <a href="..." onclick="do_something('x')" in MW.
[17:09:41] <Tuxedo_>	 ori-l: I haven't written it yet.
[17:10:08] <ori-l>	 Tuxedo_: no, you'd have <a href="#" class="tuxedo-button">click me!</a>, and then $('.tuxedo-button').on('click', function () { /* do stuff! */ });
[17:10:43] * ori-l  waits patiently for someone to chastise him for breaking the meaning of hyperlinks and not using <button>

[17:11:15] <Tuxedo_>	 ori-l: Thanks for this tip.
[17:12:28] <ori-l>	 Tuxedo_: the example is a bit contrived, because you're presumably going to be adding the element to the page, rather than binding a handler to an element that already exists. but have a look at some sample widgets -- many (if not most) of them do exactly what you want.
[17:17:15] <Tuxedo_>	 ori-l: I'm still lost as to where/how I add/generate a <a href="#" class="tuxedo-button"> in wiki markup? Through making an extension? Also, I don't know which sample widgets to look at. I've not written any extension so far. (Maybe this will be my first.)...
[17:19:00] <ori-l>	 Tuxedo_: you won't be able to use wiki markup very easily. which browser are you using? (does it have a js console?)
[17:24:21] <RobH_>	 brion: damn it you causeed me to spittake
[17:24:30] <brion>	 hehe
[17:25:45] <ori-l>	 Tuxedo_: this should get you started http://dpaste.de/RafzM/
[17:26:23] <Tuxedo_>	 Indeed. All type of browsers are available on my system, js-console, debuggers etc. The JS is no problem. In a simple non-wiki website scenario it's just a question of creating the JS function and its calls. I'm just completely unfamiliar with how to acheive the the same in the MW environment. I guess I must write something in php that generates it all in the extensions directory. Sorry for these basic questions.
[17:27:25] <ori-l>	 Tuxedo_: the code you write isn't dependent on a js console -- i asked because i wanted to walk you through a few elementary JS moves and it would've been useful to have you type them into a console.
[17:27:27] <Tuxedo_>	 ori-l: Thanks for this example!
[17:27:45] <ori-l>	 Tuxedo_: that example adds a link to the bottom of the sidebar that pops up an alert when clicked
[17:29:01] <ori-l>	 Tuxedo_: but keep in mind that i dashed that off in a hurry so it's not to be taken as paradigmatic / optimal code. read http://www.mediawiki.org/wiki/Manual:Coding_conventions/JavaScript for more guidance.
[17:30:14] <Tuxedo_>	 Aother stupid question: Where do I place this code (http://dpaste.de/RafzM) and how do I get a call for it into a MW article?
[17:30:26] <ori-l>	 Tuxedo_: an extension is a bit more heavy weight than just having a snippet of code in common.js, but there are some things you won't be able to do using js alone. if you go that route, check out http://www.mediawiki.org/wiki/Extension:Example
[17:32:40] <ori-l>	 Tuxedo_: it depends which wiki you want this code to run on (something personal or a public facing site) and who you want this code to execute for (all visitors to the wiki? only those who choose to enable some particular feature? etc.) broadly speaking, the right way to package JS is to use either an extension or a gadget and to register your code as a resourceloader module. but if all you want to do is a quick interface hack for yo
[17:32:40] <ori-l>	 ur own public consumption, nothing wrong at all with just adding a few lines to your user.js.
[17:33:57] <Tuxedo_>	 Yes, I think I need an extension, as far as I know in order to be able to produce a particular outpout with added wikimarkup that fires up a JS function. So thanks for the above coding convention link and extension example link. I simply need to get some guidance in the right direction as I'm nearly completely unfamiliar with the MW architecture, not the programming specifics of either JS or PHP.
[17:34:04] <ori-l>	 Tuxedo_: have a look at Extension:Example (link above) and at http://www.mediawiki.org/wiki/Extension:Gadgets, and things will make more sense.
[17:35:02] <Tuxedo_>	 ori-l: Thanks again for these pointer. I will do my homework before asking again.....
[17:35:05] <ori-l>	 Tuxedo_: sure.. i'm not an expert either so it's possible some of what i'm telling you is wrong or suboptimal somehow. mediawiki.org is your friend :)
[17:35:08] <ori-l>	 np at all!
[18:00:54] <Reedy>	 AaronSchulz: about?
[18:01:14] <AaronSchulz>	 yes
[18:01:23] <Reedy>	 Did Tim completely disable scanset?
[18:02:45] <AaronSchulz>	 is it still in the conf?
[18:02:59] <Reedy>	 apparently not
[18:03:03] <Reedy>	 it's still branched though
[18:03:05] <AaronSchulz>	 I remember him writing a message to wikisource that he was disabling it
[18:03:14] <AaronSchulz>	 I thought he did already
[18:03:22] <AaronSchulz>	 and those files were already uploaded to commons beforehand
[18:03:28] <Reedy>	 I seemed to recall a discussion
[18:03:28] <Reedy>	 Right
[18:03:30] <Reedy>	 it's fine then
[18:11:21] <Tuxedo_>	 Some extensions which have the git fetch method, are they only available via git? E.g. http://www.mediawiki.org/wiki/Extension:Example
[18:11:50] <Tuxedo_>	 What about the old-fashioned archive distribution?
[18:18:13] <marktraceur>	 Tuxedo_: gitweb has a nice archive-fetch feature, so you can get a tarball there
[18:18:57] <marktraceur>	 Tuxedo_: Go to "repo summary" from the extension page, click on "snapshot" at any commit (probably the top one), and it will give you a .tar.gz
[18:19:03] <marktraceur>	 Tuxedo_: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/examples.git;a=summary
[18:19:12] <marktraceur>	 Tuxedo_: Direct download: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/examples.git;a=snapshot;h=672ab783f396259e769618a940045f4bf156a928;sf=tgz
[18:19:27] <marktraceur>	 You could probably make a template for it, or add it to the template for git repos
[18:22:27] <Tuxedo_>	 Ok, so the above is a direct link to the Examples extension as a tgz, thanks for decrypting this! (I don't have time to install Git on the server, no matter how useful it may be).
[18:25:25] <^demon>	 marktraceur: Fun fact. Gitweb doesn't cache any of those tar files (or cache anything, for that matter). It's why we had to disable bot indexing of gitweb, since the bots kept finding the links to dynamic tar files and requesting them :)
[18:26:44] <marktraceur>	 ^demon: That's pretty awful. Hopefully GitBlit happens soon? :)
[18:26:58] <^demon>	 After 2.5
[18:27:12] <^demon>	 The plugin passed review the other day.
[18:27:13] <marktraceur>	 ^demon: Have they released yet?
[18:27:26] <^demon>	 It's getting ready to release, but without the LDAP fix we can't upgrade.
[18:27:30] <marktraceur>	 Hm.
[18:27:55] <marktraceur>	 Ooh, new version of git-review
[18:28:03] <^demon>	 If the patch doesn't make it into 2.5, we'll build our own. Either way, need a patch from upstream for LDAP.
[19:01:49] <gerrit-wm>	 New review: Ottomata; "Looks good!  " [analytics/udp-filters] (master); V: 1 C: 2;  - https://gerrit.wikimedia.org/r/29779
[19:01:49] <gerrit-wm>	 Change merged: Ottomata; [analytics/udp-filters] (master) - https://gerrit.wikimedia.org/r/29779
[19:14:37] <Tuxedo_>	 ori-l: I can't get Examples/BoilerPlate extension running on my MW (too old, need to upgrade first). The code you posted at http://dpaste.de/RafzM/ - would it typically go in the wiki's extension directory (e.g. extensions/tuxedo.php) to generate the link by some by custom mediawiki markup? What does the "mw-panel" refer to in your example?
[19:16:45] <Tuxedo_>	 ori-l: I would like to be able to place for example a custom mediawiki markup anywhere inline an article space, such as: <tuxedo>[[File:Img.jpg]]</tuxedo> to output for example:
[19:16:45] <Tuxedo_>	 <img class="tuxedo-button" src="/path/to/Img.jpg">
[19:16:46] <Tuxedo_>	 From thereon I can easily capture the relevant onclick effect by the css class/js identifier via JS Common.js
[19:17:56] <Tuxedo_>	 What is a method for doing this? Are there step-by-step any examples out there somewhere?
[19:19:15] <Tuxedo_>	 (just trying to piece together an extension for the first time..).
[19:24:12] <Tuxedo_>	 I'm reading this http://www.mediawiki.org/wiki/Manual:Extensions (saving anyone from pointing me to this resource)
[19:25:29] <Tuxedo_>	 And this http://www.mediawiki.org/wiki/Manual:Developing_extensions
[19:32:18] <average_drifter>	 is Sumana here ?
[19:32:20] <average_drifter>	 hey guys
[19:32:32] <average_drifter>	 I'm looking for Sumana
[19:36:38] <RoanKattouw>	 average_drifter: She doesn't seem to be around right now. But she lives in NYC so she has the hurricane excuse :)
[19:38:24] <average_drifter>	 ok, thanks
[21:19:27] <Krenair>	 It's Tim Starling Day and I didn't realise :)
[21:20:58] <DarTar>	 ping mlitn
[21:21:54] <DarTar>	 we're preparing for the death by water of clicktracking in the E3 channel
[21:22:04] <DarTar>	 can you join if you're still around?
[21:42:48] <Nemo_bis>	 Krenair: uh!
[21:43:14] <Nemo_bis>	 wikimedia holidays are being handed out like candies nowadays though
[21:46:50] <Nemo_bis>	 Krenair: http://twitter.com/MissGayle/status/263695413033447425/photo/1
[21:48:18] <robla>	 Nemo_bis: you realize this is the 9th anniversary of the first Tim Starling day, right?
[21:48:18] <Krenair>	 Nemo_bis, I... Wait what
[21:50:32] <Nemo_bis>	 robla: time flies :[
[22:07:59] <hashar>	 jenkins is dead :(
[22:08:09] <hashar>	 too many jobs pilling up
[22:09:33] <marktraceur>	 hashar: Poor, poor Jenkins.
[22:09:37] <hashar>	 not enough executors :-]
[22:10:00] <hashar>	 GIT-Fetching and Ext-Wikibase are not doing anything but triggering other jobs
[22:10:03] <hashar>	 they take two slots
[22:10:14] <hashar>	 the last slot is busy with Parsoid-parserTests :-]
[22:10:18] <marktraceur>	 Oh, hm
[22:10:23] <hashar>	 so we have to wait for parsoid to complete hehe :-]
[22:10:28] <marktraceur>	 hashar: We aren't using that, let me remove it
[22:10:31] <hashar>	 ohh
[22:10:37] <hashar>	 just disable it :-]
[22:10:43] <marktraceur>	 hashar: It broke, so I silenced it
[22:11:01] <hashar>	 it is not causing any issue
[22:11:10] <hashar>	  I need more executor in Jenkins
[22:11:11] <hashar>	 will raise the # again
[22:11:15] <marktraceur>	 *nod*
[22:11:42] <hashar>	 marktraceur: next week I am in amsterdam for a CI sprint
[22:11:52] <marktraceur>	 Oh, sounds great!
[22:11:54] <hashar>	 marktraceur: we will talk about / implement a class to easily setup a jenkins slave
[22:11:56] <hashar>	 on labs
[22:12:06] <marktraceur>	 Even better! :)
[22:12:10] <hashar>	 so we might be able to have Jenkins slaves in labs instance for people to play with
[22:12:11] <marktraceur>	 hashar: But against policy, isn't it?
[22:12:33] <hashar>	 if someone ask you, tell them you did not know :-]
[22:12:37] <hashar>	 more seriously, which policy?
[22:13:08] <marktraceur>	 hashar: Ryan_Lane, IIRC, was the person who didn't like me setting up a slave on Labs (not to blame him, but he may know more)
[22:13:59] <hashar>	 grmblbl
[22:15:53] <hashar>	 marktraceur: will talk about that once we have finished our sprint :-]
[22:16:10] <Ryan_Lane>	 -_-
[22:16:20] <Ryan_Lane>	 no jenkins in labs!
[22:16:32] <Ryan_Lane>	 seriously, no. the answer will never be yes.
[22:16:40] <Ryan_Lane>	 it's a production service
[22:16:48] <Ryan_Lane>	 it doesn't belong in labs
[22:17:03] <marktraceur>	 hashar: I told you, he doesn't like it
[22:17:07] <Ryan_Lane>	 it's not a matter of not liking something
[22:17:12] <Ryan_Lane>	 it's against our policy
[22:17:35] <marktraceur>	 *nod* 's what I meant
[22:17:47] <Ryan_Lane>	 we don't want labs outages to affect production, and we want to be able to have long maintenance windows in labs, if possible
[22:18:03] <Ryan_Lane>	 not that we do have long maintenance windows, but we *could*
[22:18:14] <Ryan_Lane>	 :)
[22:18:15] <chrismcmahon>	 hashar: we're running selenium tests on a Jenkins instance hosted by a 3rd party provider called cloudbees, it's working well, and no reason not the make the cloudbees Jenkins instance a slave of WMF Jenkins
[22:18:28] <marktraceur>	 Ryan_Lane: AFAIK, outages in a slave won't affect the master instance. It'll keep going. hashar, is that accurate?
[22:18:43] <hashar>	 I have no knowledge about jenkins slaves
[22:18:43] <marktraceur>	 Hm.
[22:18:44] <hashar>	 but yeah, I assume it will work
[22:19:03] <hashar>	 Ryan_Lane: the idea is to get all critical stuff on the production machine (aka ops/puppet linting, the existing core tests)
[22:19:20] <hashar>	 Ryan_Lane: and get slaves in labs for bootstrapping / preparing tests. So parsoid folks can play with it.
[22:19:33] <hashar>	 once ready we could move the jobs from the labs instance to the production server
[22:19:47] <hashar>	 the master/slave would be merely to have all reports in one central place
[22:20:13] <Ryan_Lane>	 ah
[22:20:14] <Ryan_Lane>	 hm
[22:20:31] <Ryan_Lane>	 well, as long as you have some way of isolating jobs so they don't own labs, that may be OK
[22:20:36] <hashar>	 btw I found out that mw/core tests raised from roughly 140secs per run to 240secs per run since the PRecise upgrade :-/
[22:20:44] <Ryan_Lane>	 ew
[22:20:54] <hashar>	 Ryan_Lane: the isolation would be an issue indeed :/
[22:21:17] <hashar>	 but at least that would let us scale out CI to more people.
[22:21:59] <hashar>	 I like CI :-)
[22:22:13] <hashar>	 but I spend too much time tracking perfs issue / bugs / reviewing code
[22:22:18] <hashar>	 poor zuul
[22:22:59] <Ryan_Lane>	 we need zuul
[22:23:04] <Ryan_Lane>	 we need to open labs registration
[22:23:10] <Ryan_Lane>	 it's been a long time
[22:25:40] <hashar>	 faidon did review the zuul class and merged it
[22:25:47] <hashar>	 need to apply it on gallium and deploy the jobs now.
[22:26:35] <gerrit-wm>	 New patchset: Hashar; "PHP script to analyze build duration" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/31139
[22:26:55] <gerrit-wm>	 New review: Hashar; "sync from production." [integration/jenkins] (master); V: 0 C: 2;  - https://gerrit.wikimedia.org/r/31139
[22:27:00] <gerrit-wm>	 New review: Hashar; "sync from production." [integration/jenkins] (master); V: 1 C: 2;  - https://gerrit.wikimedia.org/r/31139
[22:27:01] <gerrit-wm>	 Change merged: Hashar; [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/31139
[22:27:11] <Ryan_Lane>	 cool
[22:28:04] <hashar>	 at least we have a tool now :-]
[22:28:49] <hashar>	 I am wondering if that could be a disk driver issue on gallium
[22:28:53] <hashar>	 or some kernel setting
[22:29:02] <hashar>	 (or php5-apc missing hehe)
[22:30:22] <Ryan_Lane>	 heh
[22:30:29] <hashar>	 who raised http://ganglia.wikimedia.org/latest/graph.php?r=month&z=xlarge&c=Miscellaneous+eqiad&h=gallium.wikimedia.org&v=7.2&m=cpu_wio&jr=&js=&vl=%25&ti=CPU+wio
[22:30:41] <hashar>	 been upgraded on thursday
[22:30:45] <hashar>	 CPU wio
[22:30:50] <hashar>	 waiting I/O I guess isn't it ?
[22:35:25] <Platonides>	 I guess so
[22:35:55] <hashar>	 I have seen various CDB writes that took a "long" time
[22:36:21] <hashar>	 such as writing a language l10n cache
[22:36:24] <hashar>	 up to 2 seconds
[22:36:39] <hashar>	 since our NewParserTest do that before running each test, that would explain part of the slowness
[22:37:03] <Platonides>	 why does newParserTest write a language l10n cache?
[22:43:10] <hashar>	 Platonides: no idea
[22:43:19] <hashar>	 Platonides: I did not really investigated that part
[22:43:33] <hashar>	 Platonides: one thing is sure, we need to rewrite NewParserTests.php
[22:43:38] <hashar>	 it does a ton of things before each tests
[22:43:50] <hashar>	 such as creating/deleting image files
[22:44:29] <hashar>	 the debug log even show that the filebackend does a stat() of possible thumbnails for each of those files (of course that is done on each parser tests)
[22:44:53] <hashar>	 so with 5 files, 500 parser tests, 6 possibles thumbnails size… That gives a lot of stat() calls
[22:46:27] <Platonides>	 nother thing I wanted to comment you, hashar
[22:46:42] <Platonides>	 what about adding a run of parser tests with $wgLanguageCode != 'en' ?
[22:47:26] <hashar>	 can't we change our existing test runner to use a new language ?
[22:47:32] <hashar>	 IIRC it sets $wgContLang to 'en'
[22:53:24] <Platonides>	 the tests that depend on having one language, are expected to change it
[22:53:55] <Platonides>	 they can just be based on MediaWikiLangTestCase which does the work for them
[22:54:26] <Platonides>	 but still, tests not taking that into account show up
[22:55:37] <Platonides>	 it would thus be good to have jenkins detect that early
[22:56:59] <Platonides>	 a French butler :)
[22:57:31] <robla>	 chrismcmahon: mdale1: looks like TMH IE fixes have been out there a while.  have either of you poked at them to confirm?
[22:58:04] <chrismcmahon>	 robla: last I looked the latest from mdale1 had not been merged
[22:58:06] * chrismcmahon  looks again

[22:59:06] <chrismcmahon>	 and now it has, checking what I can check
[22:59:18] <robla>	 cool, thanks!
[23:00:00] <chrismcmahon>	 robla: do we know that this is on test2 now?  https://gerrit.wikimedia.org/r/#/c/30935/
[23:00:24] <robla>	 chrismcmahon: reasonably sure it is
[23:00:38] <robla>	 unless there's a weird caching issue or something (possible)
[23:00:42] <chrismcmahon>	 looking...
[23:01:25] <gerrit-wm>	 New patchset: Stefan.petrea; "X-forwarded-For field taken into consideration for geoip" [analytics/udp-filters] (master) - https://gerrit.wikimedia.org/r/31145
[23:02:35] <Platonides>	 argh, PreferencesTest needs a db when run with the other databaseless tests, but works standalone
[23:04:40] <chrismcmahon>	 I'm seeing same behavior in IE7 as yesterday, checking IE8
[23:06:43] <robla>	 XMLHttpRequest cannot load http://meta.wikimedia.org/wiki/Special:RecordImpression?banner=2012EditorSurvey&campaign=EditorSurvey2012&userlang=en&db=test2wiki&sitename=Wikipedia&country=US&bucket=0. Origin http://test2.wikipedia.org is not allowed by Access-Control-Allow-Origin.
[23:06:58] <robla>	 (not related to TMH, just stumbled into it)
[23:07:54] <Platonides>	 userlang?
[23:08:51] <chrismcmahon>	 and in IE8 also, no changes since yesterday, although thumb looks marginally nicer in Chromium http://test2.wikipedia.org/wiki/File:Bijehadena.ogv http://test2.wikipedia.org/wiki/File:Dude-catches-giant-shark-in-hawaii.ogv
[23:09:41] <robla>	 chrismcmahon: is there an actual bug report for this?
[23:11:19] <chrismcmahon>	 robla: there is not, I asked Michael for a sanity check first, but we seem to be having very different experiences with IE
[23:11:48] <robla>	 I think it's important you document your experience, especially because we're holding the release for this
[23:11:53] <chrismcmahon>	 yes
[23:15:16] <j^>	 chrismcmahon: can you check if you have the same issues in IE on test.w.o: http://test.wikipedia.org/wiki/File:Berlin_street.ogv
[23:17:24] <robla>	 j^: just verified that the javascript loaded in 1.21wmf3 (at least in debug mode) is the right version: http://bits.wikimedia.org/static-1.21wmf3/extensions/TimedMediaHandler/MwEmbedModules/EmbedPlayer/resources/mw.EmbedPlayer.js
[23:18:31] <robla>	 this line: "if an audio player we don't have room for error message interface" should only be in the new version, and it is in the version above
[23:18:32] <chrismcmahon>	 j^:  yes, same issue, IE7/IE8 both show  "Sorry, your browser either has JavaScript disabled or does not have any supported player...".  the thumb for the video is there and looks fine, the thumb has a "play" arrow, and clicking the thumb shows a js lightbox with the same error msg.
[23:19:11] <chrismcmahon>	 j^ this is http://test.wikipedia.org/wiki/File:Berlin_street.ogv
[23:19:39] <robla>	 chrismcmahon: does playing video off of commons work?
[23:19:56] <chrismcmahon>	 j^ and I know that my IE7 shows that JRE 1.6.0_07 is enabled, I don't know the status of Java in the IE8 hosted VM
[23:20:55] <robla>	 also, it'd be interesting to know that youtube works
[23:21:18] <robla>	 (could just be the testing vm isn't set up for video at all)
[23:22:21] <j^>	 just tested here and it uses cortado, chrismcmahon commons works in your setup?
[23:22:55] <j^>	 only have IE8 though
[23:23:15] <chrismcmahon>	 got a link to a video on commons?  these IE VMs are super slow
[23:23:37] <chrismcmahon>	 and not on my work laptop :(
[23:23:45] <j^>	 chrismcmahon: http://commons.wikimedia.org/wiki/File:Folgers.ogv
[23:24:39] <chrismcmahon>	 Folgers looks fine on commons in IE8
[23:25:17] <chrismcmahon>	 and IE7
[23:25:29] <j^>	 and commons import on test2: http://test2.wikipedia.org/wiki/File:Folgers.ogv
[23:27:52] <chrismcmahon>	 nope, still get the "Sorry, your browser either has JavaScript disabled or does not have any supported player...". error on Folgers on test2 in IE8
[23:28:34] <chrismcmahon>	 and it's clearly not js, there is a js spinner working in front of the error msg.
[23:29:56] <j^>	 i get that if i add ?debug=true but it throws some error unrelated to TMH but that error stops javascript so it shows the fallback
[23:31:01] <robla>	 j^: what's the unrelated error?
[23:31:12] <chrismcmahon>	 Could not set the href value"?
[23:32:30] <Krenair>	 kaldari, are you happy with that revert notification now? I was planning to merge it after the core one got approved but then I saw the summary issue and -1'd, so now I'm not confident about merging it
[23:33:07] <robla>	 chrismcmahon: what's the file and line number associated with that?
[23:33:21] <chrismcmahon>	 I don't get that error when NOT ?debug=true
[23:33:44] <chrismcmahon>	 but a different error actually, both out of load.php
[23:33:57] <chrismcmahon>	 I am really coming to dislike test and test2.
[23:34:36] <j^>	 robla: https://textb.org/t/ie/
[23:36:16] <chrismcmahon>	 j^ when NOT debug=true, I get "Expected identifier, string or number" load.php line 91
[23:37:12] <kaldari>	 Krenair: Yeah, I think it's in good shape now
[23:37:42] <kaldari>	 Terry just merged the core change
[23:38:10] <kaldari>	 Thanks for the detailed reviews!
[23:40:15] <kaldari>	 Krenair: the summary issue is fixed now
[23:40:43] <chrismcmahon>	 OK, at this point I'm not sure that we can rely on anything we see on test2/test wrt IE7/IE8
[23:44:15] <robla>	 chrismcmahon: I don't understand how you get there
[23:44:37] <robla>	 what we see on test2 is 99% likely to also show up as a problem on enwiki
[23:45:53] <robla>	 it's been a pretty reliable test environment for us
[23:46:16] <chrismcmahon>	 robla:  test2/test have always shown errors in IEs since I've been using them.  In this case those errors seem to be taking out TMH.  errors with ?debug=true set and not set are different.
[23:47:09] <robla>	 well crap...we need to get test2 fix
[23:47:16] <robla>	 *fixed
[23:47:31] <chrismcmahon>	 ShortURL is one source of IE errors
[23:48:26] <robla>	 let's disable the extensions that are causing problems
[23:49:26] <robla>	 do we have ShortURL enabled elsewhere?
[23:49:43] <robla>	 (as in, on a wiki that's not a testing wiki?)
[23:50:05] <chrismcmahon>	 not to my knowledge
[23:50:25] <chrismcmahon>	 maybe some non-Latin wikis
[23:52:38] <j^>	 chrismcmahon: after your js errors, JRE 1.6.0_07 is somewhat old. latest secure version is 1.7.0_09
[23:52:59] <chrismcmahon>	 j^: it's an old VM :)
[23:53:06] <j^>	 1.6 one can read the full hard disk or something
[23:57:12] <mdale>	 robla: whats the word?
[23:57:49] <robla>	 mdale: well, we have some error on test2 that we're trying to sort out
[23:58:03] <robla>	 not sure if it's actually related to TMH though
[23:58:14] <j^>	 mdale: what do you get with your IE8 setup at http://test2.wikipedia.org/wiki/File:Folgers.ogv
[23:58:23] <mdale>	 one sec...
[23:58:28] <Krenair>	 kaldari, why did you comment out throw new MWException( "Unrecognised parameter $param" ); in PS9?
[23:59:26] <chrismcmahon>	 mdale: the current theory is that some js error(s) in test2/test is preventing TMH from loading properly