[00:12:48] <legoktm>	 tgr: I forgot to grep, there are actually 2 more places in CentralAuth that needed updating: https://gerrit.wikimedia.org/r/275727
[00:14:08] <legoktm>	 thanks
[00:31:30] <Krinkle>	 Hm.. on mediawiki.org pref page I get "Unsaved changed" warning every time I click on anything there or reload 
[00:31:33] <Krinkle>	 I thought that was fixed?
[00:31:41] <Krinkle>	 unsaved changes*
[00:56:37] <MatmaRex>	 Krinkle: the timezone input is still broken with some values. or maybe the Translate one.
[00:56:49] <MatmaRex>	 https://phabricator.wikimedia.org/T122702
[00:57:52] <MatmaRex>	 Krinkle: looks like https://gerrit.wikimedia.org/r/#/c/264603/ still needs to be merged
[00:59:12] <MatmaRex>	 Krinkle: see my comment, you sure?
[00:59:39] <Krinkle>	 MatmaRex: I verified it last week, but I can debounce it again to next week
[00:59:45] <Krinkle>	 I don't have time for it otherwise
[00:59:56] <Krinkle>	 Changed to +1 per Alex's comment
[01:00:01] <Krinkle>	 Didn't see yours yet
[01:00:55] <Krinkle>	 Krenair: Select elements have a value but not a value attribute
[01:01:02] <Krinkle>	 hence no defaultValue either
[01:01:08] <Krinkle>	 So the logic doesn't apply to it
[01:01:26] <Krinkle>	 matanya: Select elements have a value property in the DOM but no value attribute 
[01:01:33] <Krinkle>	 it's a dynamic pointer to the selected option
[01:01:41] <Krinkle>	 The logic shouldn't apply to such elements
[01:01:50] <Krinkle>	 Makes it dirty unconditionally
[01:02:15] <Krinkle>	 Not sure what Translate did to trigger it with an <input> element
[01:02:58] <MatmaRex>	 Krinkle: was that to me? :D
[01:03:19] <MatmaRex>	 Krinkle: but <select> is if-ed out elsewhere
[01:05:00] <MatmaRex>	 Krinkle: the part where it changes "input" to "input[name]" is definitely right though, that fixes the Translate issue together with the already-merged Translate patch
[01:05:21] <MatmaRex>	 so i'd take out the .hasAttribute() path and merge that already
[01:09:50] <Krinkle>	 Right, the [name] filter should be a good start
[01:29:44] <MatmaRex>	 Krinkle: https://gerrit.wikimedia.org/r/264603 updated. merge?
[02:05:02] <tgr>	 huh, I'm logged in on mw.org but not on test.wikipedia
[02:05:13] <tgr>	 despite having seemingly valid session cookies
[02:05:48] <tgr>	 is the unpersist on session load failure patch only in master?
[16:55:44] <anomie>	 bd808: Did we decide we don't care about logging it for https://gerrit.wikimedia.org/r/#/c/272937/ ?
[16:57:49] <bd808>	 anomie: I think so, yes. There are lots of good reasons that content caching should be encouraged at the User-Agent layer even when Set-Cookie headers are present. The new code there should effectively protect such requests from being stored in intermediate caches which is protection that is wanted.
[16:58:13] <bd808>	 We could log as well, but I'm not sure that it will end up being more than noise
[16:58:52] <bd808>	 If we keep the safe guard in our Varnish config then we can see things that somehow slip through the cracks
[16:59:11] <bd808>	 although I've been told that those logs are ephemeral :/
[17:00:03] <bd808>	 It would be nice for that patch to get on the train this week if there aren't any egregious problems with it
[17:02:42] * anomie +2s
[17:54:46] <anomie>	 bd808: https://gerrit.wikimedia.org/r/275857 might be one better for matching the varnish deal, though.
[17:56:14] <bd808>	 hmm.. new function for me
[17:56:46] <bd808>	 so that one would only fire off if the other check was missed somehow?
[17:57:59] <anomie>	 Yeah, if it somehow slipped by OutputPage (e.g. anything that doesn't use OutputPage) that should catch it, and log. Unfortunately we can't get a sensible backtrace out of that one, it'll probably be an ob_end_flush() somewhere unrelated.
[19:00:19] <MatmaRex>	 i just updated https://www.mediawiki.org/wiki/User:Matma_Rex/Collaborations . the page has gotten pretty large, took four tries before the save went through. :P
[19:40:59] <legoktm>	 MatmaRex: Interesting how only 2 of the people on the prolific list are not +2 ers
[20:02:45] <SMalyshev>	 anybody here that knows how mediawiki cache purging works?
[20:03:29] <tgr>	 SMalyshev: varnish cache? WAN cache? parser cache?
[20:03:36] <SMalyshev>	 tgr: varnish
[20:05:17] <ori>	 SMalyshev: https://wikitech.wikimedia.org/wiki/Multicast_HTCP_purging
[20:06:11] <tgr>	 SMalyshev: look for classes called SquidSomething
[20:06:19] <tgr>	 we are not good at renaming things
[20:06:30] <SMalyshev>	 ori: ok, thanks. That doesn't cover the url part though - i.e. if I have en.wikipedia.org/wiki/Duck, it can be also /w/index.php/Duck and /w/index.php?title=Duck too
[20:06:49] <SMalyshev>	 so do I need to purge all forms, or only one form? and if so, which one?
[20:07:13] <RoanKattouw>	 I think Varnish rewrites them all to /wiki/Duck
[20:07:25] <RoanKattouw>	 Title::getSquidURLs() is what generates the list of URLs to purge
[20:07:45] <ori>	 that is true, but mobile needs to be purged separate iirc
[20:07:45] <RoanKattouw>	 Also when you say "do I need to purge", what are you trying to achieve? You should not need to do it yourself
[20:07:53] <ori>	 and yes, that.
[20:07:56] <SMalyshev>	 RoanKattouw: yeah, the problem is I need to fix a problem in it for wikidata, so I can't use it as an example :)
[20:08:22] <SMalyshev>	 RoanKattouw: I want to achieve this: https://phabricator.wikimedia.org/T128667
[20:08:40] <SMalyshev>	 but I don't know which URLs I need to purge 
[20:09:17] <RoanKattouw>	 There are some rewrite things to mitigate the &title= problem but I don't know the details. ori might, and if he doesn't then bblack (in -operations) would know
[20:09:31] <SMalyshev>	 The problem is getInternalURL() produces one form with parameters and another form without parameters
[20:09:37] <SMalyshev>	 and I'm not sure which one is correct
[20:10:04] <SMalyshev>	 e.g. http://localhost/wiki/Special:EntityDataUriManagerTest/Q14.rdf and http://localhost/w/index.php?title=Special:EntityDataUriManagerTest/Q14.txt&toppings=candy
[20:10:30] <SMalyshev>	 so if I want to purge URL Q14.rdf?toppings=candy, which URL should I use?
[20:11:05] <SMalyshev>	 I'll try to ping bblack then
[20:12:13] <SMalyshev>	 ori: or maybe you prechance know where the varnish code for rewrites lives?
[20:14:16] <tgr>	 I don't think URLs with random parameters get cached
[20:14:52] <SMalyshev>	 they are not random :)
[20:15:07] <SMalyshev>	 it's just a test, real ones are different of course
[20:15:14] <ori>	 SMalyshev: templates/varnish/templates/varnish
[20:15:32] <ori>	 sorry
[20:15:35] <ori>	 SMalyshev: templates/varnish/templates/varnish/normalize_path.inc.vcl.erb
[20:15:37] <SMalyshev>	 ori: thanks, will check out there
[20:15:39] <ori>	 in operations/puppet
[20:15:55] <ori>	 and the url we use is the index.php?title= one
[21:07:48] <Krinkle>	 So apparently we can change the background color of workboards now
[21:07:49] <Krinkle>	 https://phabricator.wikimedia.org/project/board/445/
[21:08:05] <Krinkle>	 Resist the temptation!
[21:14:06] <bd808>	 there are gradient options too
[21:14:16] * bd808 goes to update greasmonkey script
[21:15:18] <bd808>	 done via css classes like "phui-workboard-color phui-workboard-gradient-red"
[21:17:47] <MatmaRex>	 Krinkle: you can add cat facts to the workboard sidebar.
[21:17:59] <MatmaRex>	 https://phabricator.wikimedia.org/project/view/48/
[21:18:05] <Krinkle>	 What I really want is to be able to set the sidebar to contain a link to the Feed there used to be
[21:18:06] <MatmaRex>	 (if anyone asks, i didn't tell you that)
[21:18:07] <Krinkle>	 of all open tasks
[21:18:17] <Krinkle>	 Now it requires some kind of hacky "Link" item in the sidebar manually crafted
[21:18:21] <MatmaRex>	 Krinkle: can do that too, almost. https://phabricator.wikimedia.org/project/view/402/
[21:18:25] <MatmaRex>	 it does, yes
[21:18:32] <MatmaRex>	 it's awful
[21:18:47] <bd808>	 20after4 was going to see if we could add the feed back as a plugin
[21:19:00] <bd808>	 He probably hasn't found time to work on it though
[21:19:56] <bd808>	 we were going to make a plugin using the same stuff that does the made up cat facts to bring quips back but we can't get to the data (hosted in labs) from phab :/
[21:21:38] <Krinkle>	 Because labs is protected!
[21:22:24] <bd808>	 prod can't talk to labs
[21:22:45] <tgr>	 just make a monthly quips dump
[21:23:06] <bd808>	 I made a json endpoint to fetch -- https://tools.wmflabs.org/bash/random.json -- but unreachable
[21:23:16] <bd808>	 yeah a dump would probably work
[21:32:51] <Krinkle>	 labs can't talk to prod, prod can't talk to labs.
[21:33:14] <Krinkle>	 It's almost like the cold war.
[21:34:32] <bd808>	 nope. other way around. Labs can talk to anything public in prod but prod can't talk to public things in labs. Try `curl -v https://tools.wmflabs.org/bash/random.json` from a prod host
[21:35:36] <bd808>	 there are some things that can cross from prod to labs, but not http(s)
[21:36:51] <bd808>	 which makes sense as prod can talk to other external http(s) things either except via the proxy that whitelists some content
[21:37:16] <bd808>	 using curl/wget inside the cluster is a great way to get backdoored
[22:25:38] <ori>	 MaxSem: https://github.com/facebook/hhvm/wiki/building-and-installing-hhvm-on-osx-10.9#install-with-homebrew