[01:16:40] <sumanah>	hi multichill ... how goes GLAMCamp prep?
[01:35:03] <sumanah>	hi tfinc -- just saw https://meta.wikimedia.org/wiki/Mobile_Projects/features#India_Hackathon
[01:40:05] <tfinc>	sumanah: uhuh
[01:40:20] <tfinc>	pchang was working on all of those
[01:41:06] <sumanah>	tfinc: so the H next to an item means that there was specific significant progress on it at the Mumbai hackathon?
[01:41:26] <tfinc>	correct!
[01:42:32] <sumanah>	whooooo
[02:08:15] <tfinc>	sumanah: do you mind if i tweet the dates of the hackathon ?
[02:08:27] <sumanah>	tfinc: the January one? no of course not go ahead
[02:08:34] <sumanah>	it's public & on the developer meetings page
[02:08:48] <tfinc>	k, i'll include the link then too
[02:08:56] <tfinc>	to https://www.mediawiki.org/wiki/January_2012_San_Francisco_Hackathon
[02:09:44] <sumanah>	cool, tfinc
[02:13:32] <tfinc>	done http://twitter.com/#!/WikimediaMobile/status/141701259387346945
[09:47:05] <Bryan>	morning
[10:22:37] <guillom>	Hello Bryan
[10:22:46] <Bryan>	hi
[10:23:11] <guillom>	Bryan, no pressure, but are you planning to create [[:mw:Extension:VipsScaler]] soon?
[10:25:06] <Bryan>	good idea
[10:25:15] <Bryan>	if I do not forget, tonight
[10:25:25] <guillom>	awesome, thanks :)
[13:11:57] <guillom>	gregdek, hi. Was there any work done on the Coding challenge in November? And if so, could you please add a few sentences to summarize it at https://www.mediawiki.org/wiki/Wikimedia_engineering_report/2011/November#Recent_events ?
[13:58:07] <hashar>	RoanKattouw: Reedy: can one of you please deploy https://www.mediawiki.org/wiki/Special:Code/MediaWiki/104663 when you have time ?:)
[13:58:31] <hashar>	an svn up of  extensions/VipsScaler should do it
[13:58:34] <Bryan>	hashar: don't you have shell access yourself?
[13:58:38] <Reedy>	Can't you deploy it? :p
[13:58:38] <Reedy>	^
[13:58:53] <hashar>	for some reason I don't have full rights :)
[13:58:58] <hashar>	Tim granted me access to wmf branches
[13:59:08] <Reedy>	yeah, and that works
[13:59:10] <hashar>	but now I can not svn up cause I don't have my ssh key in svn :-)
[13:59:14] <Reedy>	Nooo
[13:59:17] <Reedy>	agent forwarding
[13:59:22] <Reedy>	ssh -A fenari.wikimedia.org
[13:59:23] <RoanKattouw>	ssh -A fenari.wikimedia.org
[13:59:28] <Reedy>	Should just be the same as you did for site config stuff
[13:59:59] <hashar>	no way I am going to use ssh forwarding
[14:00:05] <hashar>	that is too evil
[14:00:16] <Reedy>	...
[14:00:23] <Reedy>	It's the way you should have always had to do it
[14:00:23] <Reedy>	:/
[14:01:30] <hashar>	the way I do it is:
[14:01:43] <hashar>	I got several ssh keys on my computers
[14:01:51] <hashar>	one of them let me access to live cluster
[14:02:00] <hashar>	then I have another key there to let me access to the other servers
[14:03:02] <hashar>	so I just need to poke ^demon about adding that key on svn :)
[14:08:10] <Reedy>	lol
[14:08:22] <Reedy>	i'll do it when i'm off the phone
[15:58:15] <Platonides>	hashar, it's possible to connect to a second host without agent forwarding
[15:58:15] <Platonides>	ssh -oProxyCommand='ssh -W %h:%p monkey.example' banana.example
[15:58:49] <Platonides>	(monkey is the bastion and banana the target host)
[15:59:22] <hashar>	looks funny :)
[15:59:45] <hashar>	the issue I have is that I can not ssh from fenari to the svn repository using svn co svn+ssh://foo
[15:59:53] <hashar>	just need my key to be pushed there :p
[16:00:09] <hashar>	gwicke: welcome back. I have updated the js parser test to use colors :)
[16:00:21] <Platonides>	you did the changes directly in fenari?
[16:00:31] <gwicke>	hashar: yay!
[16:00:35] <gwicke>	checking..
[16:00:47] <hashar>	you need to add a node module
[16:00:51] <Platonides>	(I copied that line from a mail of dkg to the openssh ml)
[16:00:53] <hashar>	colors  IIRC, look at the README
[16:01:29] <Platonides>	btw, the filename MWTerm.php looked a bit ugly
[16:02:25] <gwicke>	hashar: veeerrrry pretty!
[16:02:49] <hashar>	thanks :)
[16:02:54] <gwicke>	would be good to disable the colors if the output is not to a term
[16:03:04] <hashar>	Platonides: yeah I could not come with a better directory or better name at that time :(
[16:03:18] <hashar>	Platonides: please be bold and rename to something else (don't forget to update Autoloader.php)
[16:03:18] <Platonides>	why not just Term.php ?
[16:03:37] <hashar>	i though Term.php would conflict with some PEAR package so I added the MW prefix
[16:04:05] <hashar>	gwicke: not a term?  isn't that script supposed to be run from cli ?
[16:04:36] <gwicke>	hashar: yes, but normally I write the output to a file or less, so I can jump and search around in it
[16:05:17] <gwicke>	but that still works, so not really important
[16:05:49] <Platonides>	hashar, why not copy the changes from fenari to localhost, and commit from there?
[16:06:01] <Platonides>	seems the easiest way
[16:06:06] *gwicke 	is all sweaty after running for 40 minutes, off to the shower..
[16:06:46] <Platonides>	you could even do: ssh fenari 'cd path/repository && svn diff' | patch -p0
[16:07:14] <hashar>	that is not the issue Platonides :)
[16:07:22] <hashar>	I did commit from my computer to the wmf branch
[16:07:36] <hashar>	then I log on fenari and try to 'svn update' the wmf branch
[16:07:57] <hashar>	the working copy on fenari use svn+ssh://   so it prompts me for my ssh key :)
[16:08:06] <Platonides>	ouch
[16:08:23] <hashar>	well??? to be more correct, fenari propose a local ssh key but it is unknown to the svn server
[16:08:32] <hashar>	so I ended up having to enter a password that does not exist :)
[16:08:40] <Platonides>	xD
[16:08:44] <Platonides>	svn switch http:// + svn up
[16:08:50] <hashar>	so the solution is to take my ssh key from fenari and put it on the svn server :-))
[16:08:53] <hashar>	hehe
[16:09:01] <Platonides>	although that will mess up next guy trying to commit from fenari a change on that file
[16:09:15] <hashar>	the working copy is shared among various user.  http:// will fix it but I guess we have svn+ssh:// for some reason
[16:09:26] <hashar>	you are right
[16:09:34] <hashar>	the scheme let us easily commit live hacks. That is the reason
[16:09:35] <hashar>	\o/
[16:10:04] <Platonides>	svn server should allow that fenari key as read-only
[16:13:50] <hashar>	Node.js totally pwn
[16:14:04] <hashar>	I really prefer JS over PHP
[16:14:49] <Platonides>	I was able to manage with js
[16:14:50] <Platonides>	back in the days were there was no jQuery or resourceloader everywhere
[16:16:55] <gwicke>	hashar: you could try ssh -A
[16:17:05] <gwicke>	that forwards the agent
[16:17:13] <hashar>	gwicke: yeah that would be the solution. But Tim said ssh forwarding is evil :-)
[16:17:24] <gwicke>	ok
[16:17:42] <gwicke>	somewhat understandable, but still more secure than copying keys around..
[16:17:44] <RoanKattouw>	SSH forwarding isn't evil under all circumstances
[16:17:49] <RoanKattouw>	You should have to know what you're doing
[16:17:55] <RoanKattouw>	And be careful about what other keys are stored in that agent
[16:21:18] <gwicke>	hashar: I did some profiling this morning, about 30% seems to go into substr
[16:21:34] <gwicke>	the parser chops up everything into single-char strings
[16:21:48] <gwicke>	and then joins many of them back together ;)
[16:21:49] <Platonides>	Roan, it's convenient, but not necessarily good
[16:22:55] <gwicke>	hashar: that is in the PEG tokenizer, to be more precise
[16:24:07] <hashar>	gwicke: is that something we wrote? or an upstream issue?
[16:24:20] <gwicke>	upstream
[16:24:37] <gwicke>	but probably fixable without too much trouble
[16:25:37] <gwicke>	hashar: the colors are especially nice in the diff!
[16:27:04] <hashar>	gwicke: ?? Brion 2005 or so
[16:27:19] <hashar>	gwicke: I reused the colors he used for the parserTests.php script :p
[16:27:30] <brion>	:)
[16:27:39] <hashar>	there might be a bug somewhere
[16:27:43] <gwicke>	they are very familiar ;)
[16:27:46] <hashar>	cause the  - line are below the + lines
[16:27:55] <hashar>	+<p><a href="http://www.example.com/&quot;hello&quot;">stuff</a></p>
[16:27:55] <hashar>	-<p><a href="http://www.example.com/">"hello" stuff</a></p>
[16:27:57] <gwicke>	that is in the diff library
[16:28:11] <gwicke>	also wondered about that
[16:29:41] <gwicke>	have to head to town for some shopping, will be back later
[16:33:43] <hashar>	parserTests.js now comes with usage and --help : -)
[16:33:50] <sumanah>	yay
[16:33:57] <hashar>	npm -g install optimist
[16:33:59] <hashar>	I love that module :)
[16:34:02] <sumanah>	hashar: is that worth posting to wikitext-l about?
[16:34:15] <hashar>	not sure
[16:34:22] <brion>	sweeeeeeet
[16:34:26] <brion>	i say yes ;)
[16:34:29] <brion>	it'll get people to try it ;)
[16:34:35] <hashar>	haha
[16:34:40] <hashar>	I am going to add a filter option
[16:35:41] <hashar>	--quiet will require to just rewrite everything to use events instead of while(true) {  switch() case case case }
[16:35:50] <hashar>	that will be easier to read
[16:38:10] <sumanah>	RoanKattouw: just fyi, I smiled at "Winter is coming"
[16:38:18] <RoanKattouw>	heh
[16:38:34] <RoanKattouw>	I'm glad someone appreciated my edit summary easter egg
[16:38:47] <sumanah>	:)
[16:39:23] <RoanKattouw>	You know, with a power socket and half a season of GoT, that red-eye from Detroit to Amsterdam (back from NOLA) was really short
[16:40:50] <sumanah>	I found my 16-hr flight back from Mumbai was pretty short, too, with various entertainments
[16:41:21] <sumanah>	RoanKattouw: do you have anything for the HTTPS portion of https://www.mediawiki.org/wiki/Wikimedia_engineering_report/2011/November ?
[16:42:06] <sumanah>	Reedy: anything for the Shell Requests section of https://www.mediawiki.org/wiki/Wikimedia_engineering_report/2011/November#MediaWiki_Core ?
[16:42:48] *guillom 	thinks sumanah is trying to get French sweets the next time we meet.
[16:43:04] *sumanah 	laughs
[16:43:10] <guillom>	(But I'll take help with the report for French sweets any time)
[16:43:31] <guillom>	FYI I just pinged Ryan for Labs, and Mani & Parul for Mobile research.
[16:43:44] <guillom>	On this note, dinner time.
[16:44:08] <RoanKattouw>	sumanah: HTTPSEverywhere release happened. Otherwise, not much
[16:58:42] <sumanah>	RoanKattouw: ok, did I summarize that ok with https://www.mediawiki.org/wiki/Wikimedia_engineering_report/2011/November#Site_infrastructure ?
[16:59:28] <RoanKattouw>	Hmm, almost
[16:59:34] <RoanKattouw>	The cases they missed are obscure edge cases
[16:59:47] <RoanKattouw>	I mistakenly thought they had pulled an old version of my ruleset, but they hadn't
[16:59:57] <RoanKattouw>	So then 24h after the HE release, Ryan gave me his list of domains
[17:00:09] <RoanKattouw>	and with that I was able to add a number of obscure domanis
[17:00:10] <sumanah>	HA
[17:00:16] <sumanah>	so you did finally get that list!
[17:00:28] <RoanKattouw>	aye
[17:00:49] <RoanKattouw>	https://github.com/catrope/https-everywhere/commit/e421caa18684a350ec8c7a7b93a8b9308ecbc031
[17:00:52] *RoanKattouw 	notices a bug in those
[17:01:08] <sumanah>	you're better placed than I am to actually improve & fix the eng report, then, RoanKattouw
[17:01:20] *sumanah 	goes to count up the number of new committers from Nov
[17:01:57] <RoanKattouw>	gotta escape the dots
[17:04:32] <hashar>	I wish we could use some kind of wildcard proxy in front of our http only servers
[17:04:43] <hashar>	would also be great to av
[17:04:44] <hashar>	o
[17:05:06] <hashar>	it would also be great to avoid duplicating apache configuration between :80 and :443 virtual hosts :)
[17:18:45] <hashar>	well I ported --quick --quiet :)
[17:36:13] <gwicke>	hashar: wow ;)
[17:41:06] <hashar>	next commit will have an easter egg :)
[17:44:13] <hashar>	gwicke: you might want to talk about substr in the PEG parser with Krinkle
[17:44:22] <hashar>	I know he did a bunch of js optimization in MediaWiki core
[17:44:43] <gwicke>	ran across his nick on jsperf a few times ;)
[17:45:09] <hashar>	he is Netherlands, but usually connect in the evening
[17:45:29] <gwicke>	ok
[17:46:02] <hashar>	http://www.mediawiki.org/wiki/JavaScript_performance might help also
[17:46:33] <gwicke>	in the long term, I believe that passing offsets will always be better than passing strings
[17:46:55] <gwicke>	but that is already the second step
[17:47:20] <gwicke>	right now I believe the largest gain can be made by speeding up the bulk text match
[17:47:51] <gwicke>	will ask him about it
[17:48:11] <hashar>	how do you profile a js script under node ?
[17:48:19] <gwicke>	node --prof
[17:48:23] <hashar>	ahaha
[17:48:27] <hashar>	awesome
[17:48:32] <gwicke>	and then an analyzer that comes with v8
[17:48:40] <gwicke>	but it is quite primitive
[17:48:53] <gwicke>	no kcachegrind conversion for example
[17:49:04] <gwicke>	i love kcachegrind..
[17:50:21] <hashar>	I have used it a bit a lonnng time ago
[17:50:52] <gwicke>	also, a trace of the full test run crashes the analyzer script
[17:51:05] <hashar>	you have --filter now :)
[17:51:06] <gwicke>	so you have to abort the test to keep the size down
[17:51:15] <gwicke>	exactly ;)
[17:51:23] <gwicke>	thanks!
[17:51:34] <hashar>	I love github and node
[17:51:35] <gwicke>	that really helps while working on individual cases
[17:51:58] <hashar>	but there is always a ton of different modules to do one task
[17:52:02] <gwicke>	I used to like that style too, played a lot with twisted in python
[17:52:16] <gwicke>	but now I am spoilt by Haskell..
[17:52:27] <hashar>	never looked at it
[17:52:29] <gwicke>	does all the event stuff under the hood
[17:52:47] <hashar>	at one time I wanted to look at go (google language that looks like an interpreted scripts but that you can compile)
[17:52:47] <gwicke>	not quite as light-weight as erlang, but close
[17:53:32] <gwicke>	I have no eperience with go so far
[17:53:52] <gwicke>	the implementation has a few nice tricks, split stacks for example
[17:54:07] <gwicke>	but the language itself looks quite conservative
[17:54:57] <gwicke>	I like Haskell mainly for concurrency and its type system
[17:55:14] <gwicke>	and semi-automatic parallelization enabled by purity
[17:55:17] <hashar>	well I only played with PHP Perl Ruby Python and JS
[17:55:22] <sumanah>	Haskellians here, Tim going on about Lua in email, what's next?
[17:55:30] <hashar>	C is only hacking minor changes :-/
[17:55:53] <gwicke>	sumanah: anything but php I guess..
[17:56:05] <gwicke>	but LuaJit is awesome too
[17:56:06] <sumanah>	"burn" as kids used to say in the US in the 90s
[17:57:38] <hashar>	gwicke you might want to look at https://github.com/dannycoates/node-inspector
[17:57:47] <hashar>	seems it even allow you to change the code of a running app
[17:58:45] <hashar>	you end up with an editor in your browser
[17:58:45] <gwicke>	hmm- the parser is built as a string and then evaled
[17:58:55] <gwicke>	that messes up the normal debugging unfortunately
[17:58:59] <hashar>	with an inspector that looks like firebug :)
[17:59:31] <gwicke>	trying..
[18:00:38] <gwicke>	failed to install with npm
[18:00:45] <hashar>	oh nooo
[18:01:13] <gwicke>	TypeError: Bad argument
[18:01:15] <gwicke>	npm ERR!     at Object._open (fs.js:224:11)
[18:01:20] <gwicke>	and so on..
[18:02:44] <gwicke>	but I have installed node from the last git release tag, could be a problem for a debugger
[18:03:04] <gwicke>	node --debug (IIRC) also offers a simple debugger
[18:03:16] <gwicke>	but that does not help for evaled code
[18:03:46] <hashar>	maybe an issue with node version?  I got 0.6.2
[18:03:48] <hashar>	under mac os x
[18:04:14] <gwicke>	0.6.3, Debian
[18:05:02] <gwicke>	I tried to include code into the grammar using require, but that failed with some obscure scoping issue
[18:05:34] <gwicke>	so I had to paste it all into the top of the grammar file for now
[18:05:47] <hashar>	as long as it works, I guess you are fine
[18:06:04] <gwicke>	but you have to debug it without help from traces
[18:06:17] <gwicke>	more like c programming before gdb
[18:07:10] <gwicke>	won't scale like this, but I gave up on that for now
[18:08:01] <hashar>	gwicke: sorry need to get some bread :/
[18:08:03] <hashar>	I am out
[18:08:21] <gwicke>	hashar: np- I'll also leave soon
[18:08:24] *hashar 	notices that unfortunately he get out when robla get in :-D
[18:08:26] <hashar>	see you tomorrow!
[18:08:28] <gwicke>	thanks for your work!
[18:08:31] <hashar>	and enjoy the colors
[18:08:34] <hashar>	:-D
[18:08:35] <robla>	bye hashar
[18:08:38] <gwicke>	and the filters ;)
[18:08:40] <gwicke>	bye!
[18:08:51] <hashar>	hello / goodbye robla :)  might connect later in the evening though
[18:11:45] <gwicke>	I'm leaving too, see you tomorrow!
[18:14:04] <Krinkle>	anyone know how to run update.php on prototype ? I'm unable to properly run it
[18:14:19] <Krinkle>	tried update.php --wiki enwiki, rc-en, rc_enwiki ...
[18:14:35] <Krinkle>	plus --iknowwhatimdoing since it's wmf-branch
[18:14:58] <Krinkle>	$ php update.php --wiki rc-en --iknowwhatimdoing
[18:15:05] <Krinkle>	Command line mode for: --wiki
[18:15:06] <Krinkle>	Notice: Undefined index:  --wiki in /srv/org/wikimedia/prototype/wikis/rc/LocalSettings.php on line 56
[18:15:11] <Krinkle>	Commandline: NULL
[18:15:17] <Krinkle>	Database returned error "1046: No database selected (localhost)"
[18:17:18] <Krinkle>	update.php --help says to use --wiki
[18:19:14] <Krinkle>	okay, so LocalSettings is doing $wikidata=$wikis[$argv[0]]
[18:19:16] <Krinkle>	..
[18:19:20] <Krinkle>	update.php rc-en worked :)
[18:19:35] <Krinkle>	ARG! Fatal error: Class 'LoggedUpdateMaintenance' not found in /srv/org/wikimedia/prototype/wikis/rc/maintenance/fixExtLinksProtocolRelative.php on line 27
[18:39:19] <Krinkle>	@replag
[18:39:21] <dbbot-wm>	Krinkle: No replag currently. See also "replag all".
[18:39:25] <Krinkle>	@replag all
[18:39:26] <dbbot-wm>	Krinkle: [s1] db32: 0s, db36: 0s, db12: 0s, db26: 0s, db38: 0s; [s2] db30: 0s, db13: 0s, db24: 0s; [s3] db34: 0s, db39: 0s, db25: 0s, db11: 1s
[18:39:27] <dbbot-wm>	Krinkle: [s4] db22: 0s, db31: 0s, db33: 0s; [s5] db45: 0s, db35: 0s, db44: 0s; [s6] db47: 0s, db43: 0s, db46: 0s; [s7] db16: 0s, db37: 0s, db18: 0s
[18:46:18] <Krinkle>	@replag all
[18:46:19] <dbbot-wm>	Krinkle: [s1] db32: 0s, db36: 0s, db12: 0s, db26: 0s, db38: 0s; [s2] db30: 0s, db13: 0s, db24: 0s; [s3] db34: 0s, db39: 0s, db25: 0s, db11: 0s
[18:46:20] <dbbot-wm>	Krinkle: [s4] db22: 0s, db31: 0s, db33: 0s; [s5] db45: 0s, db35: 0s, db44: 0s; [s6] db47: 0s, db43: 0s, db46: 0s; [s7] db16: 0s, db37: 0s, db18: 0s
[19:39:21] <RoanKattouw>	hrm
[19:39:28] *RoanKattouw 	wants a way to gracefully restart job runners
[19:40:12] <AaronSchulz>	are you fantasizing about some job runner that doesn't suck?
[19:40:44] <RoanKattouw>	Wait, I think I know what's going on here
[19:40:50] <RoanKattouw>	OK so the job runners are run with --max_time=300
[19:41:09] <RoanKattouw>	That means that the main process will stop serving jobs to its children 5 minutes after it's started
[19:41:36] <RoanKattouw>	Of course on srv267 I've got a job runner with 2 children (even though procs is set to 5), both with a running time of 98 minutes
[19:41:55] <RoanKattouw>	So 2 children were served very long-running jobs that run for much longer than 5 mins
[19:42:27] <RoanKattouw>	The problems are 1) such jobs exist, they shouldn't, and 2) this reduces the job runner capacity because no new procs are spun up; the parent is trying to wind down and move to the next wiki
[19:42:42] <RoanKattouw>	I think the cause of #1 is the way RefreshLinksJob2 is written
[19:43:39] <RoanKattouw>	It fetches a single title, grabs all templatelinks (or pagelinks or whatever the job parameter says, but I'm working on templatelinks right now) entries for that title, then parses *ALL* linked titles, then ends
[19:44:07] <RoanKattouw>	Now we've got this code
[19:44:10] <RoanKattouw>	# Not suitable for page load triggered job running!
[19:44:11] <RoanKattouw>			# Gracefully switch to refreshLinks jobs if this happens.
[19:44:13] <RoanKattouw>			if( php_sapi_name() != 'cli' ) {
[19:44:22] <RoanKattouw>	Then in the if block, it inserts a RefreshLinksJob for each title
[19:44:45] <RoanKattouw>	I'm wondering if we shouldn't do that instead
[19:45:01] <RoanKattouw>	For cli too, I mean
[19:45:10] <RoanKattouw>	Because these RefreshLinksJob2 jobs run forever
[19:48:09] <AaronSchulz>	RoanKattouw: so if it doesn't convert to sub-jobs (refreshLinks2 => refereshLinks) it does $wgUpdateRowsPerJob parses
[19:48:23] *AaronSchulz 	wonders how slow that is
[19:48:42] <RoanKattouw>	orly?
[19:48:45] <RoanKattouw>	Where is that limit?
[19:48:55] <RoanKattouw>	Oh BTW, I've found a way to do a graceful restart, somewhat
[19:48:56] <AaronSchulz>	LinksUpdate::queueRecursiveJobs
[19:49:09] <RoanKattouw>	I sent SIGSTOP to the jobs-loop.sh process
[19:49:47] <RoanKattouw>	hmm
[19:50:09] <RoanKattouw>	Oh, aha, it's got a start and an end
[19:51:07] <AaronSchulz>	it could either use a lower number than $wgUpdateRowsPerJob (usually 500) or just always convert to the single-parse jobs
[19:51:40] <RoanKattouw>	hmm
[19:51:43] <RoanKattouw>	I guess it's fine this way
[19:51:47] <RoanKattouw>	500 is just a really large value
[19:51:55] <AaronSchulz>	500 "Barack Obama"s zOmgz
[19:52:05] <RoanKattouw>	Exactly
[19:52:10] <RoanKattouw>	That's what srv267 was doing to itwiki
[19:52:15] <RoanKattouw>	Only one runner left there now
[19:52:32] <RoanKattouw>	So the thing is, if you have job procs that run for 100 minutes
[19:52:40] <RoanKattouw>	code updates take a long time to take effect
[19:52:45] <AaronSchulz>	yep
[19:53:40] <RoanKattouw>	sheesh
[19:53:42] <RoanKattouw>	10780 apache    39  19  256m  97m 3912 R  100  0.8 149:39.17 php MWScript.php runJobs.php --wiki=itwiki --procs=5 --maxtime=300
[20:07:56] <Reedy>	See //www.mediawiki.org/wiki/Special:ApiSandbox
[20:09:14] <Reedy>	$desc[] = 'See ' . SpecialPage::getTitleFor( 'ApiSandbox' )->getFullUrl();
[20:21:49] <Reedy>	> var_dump( $a->getInternalUrl() );
[20:21:49] <Reedy>	string(48) "http://www.mediawiki.org/wiki/Special:ApiSandbox"
[20:21:56] <Reedy>	RoanKattouw, ^ Is that enough to fix it?
[20:22:11] <RoanKattouw>	Use getCanonicalUrl() instead
[20:22:21] <RoanKattouw>	They're the same on WMF but that's a coincidence
[20:23:12] <Reedy>	Cheers
[21:52:51] <RoanKattouw>	bsitu, rmoen: OK, the code is all reviewed, you guys ready to push it to testwiki?
[21:53:15] <rmoen>	RoanKattouw:  Yes :)
[21:53:58] <bsitu>	RoanKattouw: Yes, thank you
[21:56:29] <RoanKattouw>	Code should be live on testwiki
[21:56:33] <RoanKattouw>	Running the index creation on all wikis now
[21:56:53] <RoanKattouw>	rmoen, bsitu: Please test on testwiki, and ping me when it's good to go site-wide
[21:57:27] <bsitu>	RoanKattouw: yes, we are testing it on testwiki now
[22:11:25] <RoanKattouw>	DB updates all done
[22:22:52] <rmoen>	RoanKattouw: All tested ,we are ready.
[22:23:01] <RoanKattouw>	OK
[22:23:28] <RoanKattouw>	Holy fuck
[22:23:30] <RoanKattouw>	 225 Warning:  require(/usr/local/apache/common-local//index.php) [<a href='function.require'>function.require</a>]: failed to open stream: No such file or directory in /usr/local/apache/co
[22:23:32] <RoanKattouw>	mmon-local/live-1.5/index.php on line 3
[22:23:34] <RoanKattouw>	    224 Fatal error:  require() [<a href='function.require'>function.require</a>]: Failed opening required '/usr/local/apache/common-local//index.php' (include_path='.:/usr/share/php:/usr/loca
[22:23:36] <RoanKattouw>	l/apache/common/php') in /usr/local/apache/common-local/live-1.5/index.php on line 3
[22:23:37] <RoanKattouw>	      8 Warning:  require(/usr/local/apache/common-local//api.php) [<a href='function.require'>function.require</a>]: failed to open stream: No such file or directory in /usr/local/apache/comm
[22:23:39] <RoanKattouw>	on-local/live-1.5/api.php on line 3
[22:23:40] <RoanKattouw>	      8 Fatal error:  require() [<a href='function.require'>function.require</a>]: Failed opening required '/usr/local/apache/common-local//api.php' (include_path='.:/usr/share/php:/usr/local/
[22:23:42] <RoanKattouw>	apache/common/php') in /usr/local/apache/common-local/live-1.5/api.php on line 3
[22:23:43] <RoanKattouw>	Sorry guys I gotta fix that first
[22:24:07] <rmoen>	Woah
[22:26:20] <RoanKattouw>	OK they're subsiding now
[22:26:22] <RoanKattouw>	WTF was that
[22:26:46] <rmoen>	I don't have a clue
[22:27:36] <RoanKattouw>	It looks like $IP was set to "" ?
[22:27:56] <RoanKattouw>	Oh, wait
[22:28:01] <RoanKattouw>	$version was set to ''
[22:29:20] <RoanKattouw>	hmm, looks like a bug in MWMultiVersion
[22:29:24] <RoanKattouw>	AaronSchulz: Did you see this?
[22:29:58] <RoanKattouw>	AaronSchulz: It looks like it's possible for MWMultiVersion::loadVersionInfo() to populate $this->version with 'false' , at which point you get errors accessing /usr/local/apache/common-local//index.php
[22:30:26] <RoanKattouw>	It seems to require a corrupted .cdb file and running sync-common on the affected boxes made it go away, but still, it's scary
[22:31:15] <RoanKattouw>	rmoen: OK, now that things are quiet, MB deploy
[22:31:16] <RoanKattouw>	Here goes
[22:31:51] <rmoen>	Hooray!
[22:32:01] <AaronSchulz>	RoanKattouw: isMissing() checks version == false
[22:32:12] <RoanKattouw>	Oh, huh
[22:32:17] <RoanKattouw>	Well somehow those paths were produced
[22:32:18] <AaronSchulz>	I think some 404 code uses that
[22:32:23] <RoanKattouw>	Maybe it was APC corruption, I don't kknow
[22:34:58] <AaronSchulz>	I wonder what was making those paths
[22:35:16] <RoanKattouw>	It came from the live-1.5 wrappers
[22:35:22] <RoanKattouw>	So it must've been live-1.5/MWVersion.php
[22:35:22] <AaronSchulz>	calling getVersion() or so would fail out due to the NotMissing assertion
[22:35:40] <RoanKattouw>	Which does stuff like require "/usr/local/apache/common-local/$version/$file";
[22:35:50] <RoanKattouw>	(Well not directly, it sets $IP first, but you get the idea)
[22:36:04] <AaronSchulz>	$version = $multiVersion->getVersion();
[22:36:12] <RoanKattouw>	aye
[22:36:17] <RoanKattouw>	Well maybe it was '' or something
[22:36:20] <RoanKattouw>	or null or whatever
[22:36:41] <AaronSchulz>	yeah, definitely requires corruption
[22:36:48] <RoanKattouw>	rmoen: All done, please test on enwiki. I'm not seeing errors at least
[22:36:49] <AaronSchulz>	there was a key but it was empty
[22:36:57] <AaronSchulz>	opposed to no key to begin with
[22:37:01] <RoanKattouw>	Right, a key with a value of ''
[22:37:07] <AaronSchulz>	wierd
[22:37:19] <RoanKattouw>	But only on two boxes, where it just magically appeared
[22:48:29] <rmoen>	RoanKattouw, Thanks for deploying.  All is good
[22:48:43] <RoanKattouw>	Good
[22:55:55] <howief>	congrats guys!
[22:56:45] <howief>	this is really, really cool!
[23:09:14] <rmoen>	RoanKattouw, can I request one small config change ?  see https://www.mediawiki.org/wiki/Special:Code/MediaWiki/104775
[23:10:38] <rmoen>	Config changes to trunk/extensions/MoodBar/MoodBar.php
[23:10:53] <RoanKattouw>	On it
[23:11:00] <rmoen>	Thanks!
[23:14:39] <RoanKattouw>	rmoen: Deployed
[23:16:33] <rmoen>	RoanKattouw: On test ?
[23:16:41] <RoanKattouw>	On the live site
[23:17:20] <rmoen>	oh OK, maybe I'm seeing cache
[23:17:37] <RoanKattouw>	Oh, right
[23:17:39] <RoanKattouw>	config changed
[23:18:06] <RoanKattouw>	Touching startup.js to push through the config change to JS
[23:18:13] <RoanKattouw>	This, and the JS change, may take 5 mins to propagate
[23:19:01] <rmoen>	Oh you got the $.trim in there ?
[23:51:06] <howief>	hey jorm
[23:51:20] <howief>	do you have a sec to check out the blog draft?
[23:53:51] <jorm>	been looking at it.
[23:53:53] <jorm>	seems good.
[23:53:57] <jorm>	sec.
[23:54:05] <jorm>	lemme give it another once over.
[23:55:16] <jorm>	reading google doc; don't have perms to read in-situ drafts.
[23:55:43] <jorm>	i can't read it, dude. the google doc is weird.
[23:55:55] <jorm>	i trust your opinions, though, so just click "publish"
[23:55:57] <jorm>	DO IT