[00:16:17] Righto [00:16:17] I have a feeling I'll be very well acquainted with ops in the near future [00:16:17] yeah [00:16:17] marktraceur: paravoid replied to you on wikitech-l about etherpadlite :-] [00:16:17] guess you are going to enjoy writing a puppet manifest hehe [00:16:17] * marktraceur hasn't gotten it yet [00:16:17] and as I told you yesterday, the challenge will be to figure out how to get the node.js dependencies to be deployed [00:16:18] Yeah. [00:16:18] hashar: Oh, the email I already replied to? Or did he send a second one? [00:16:18] oh you replied [00:16:18] nice [00:16:18] :) [00:16:18] marktraceur: Thanks. [00:16:18] mwalker, I mean. [00:16:18] Although you're both awesome. [00:16:18] Yes. [00:16:18] Yes we are. [00:16:18] I'll let mark take all the credit on this one - I like to pretend I know nothing about gerrit [00:16:19] mwalker: It does make it less likely that people will ask you for stuff [00:16:19] That seems like a good policy, considering how often people tend to need to ask about it. o_O [00:16:20] it's also good because I truly don't know anything about it [00:16:20] I poke it [00:16:20] and it occasionally does useful things [00:16:20] other times it just giggles like a schoolgirl [00:16:20] and I feel violated [00:16:20] mwalker: You feel violated by schoolgirls' giggles? Noted. [00:16:21] when it comes from gerrit! [00:16:21] Ah. [00:16:21] it's taunting me! [00:16:26] New patchset: Ottomata; "Add replace_space function" [analytics/webstatscollector] (master) - https://gerrit.wikimedia.org/r/51598 [00:16:27] Change abandoned: Ottomata; "(no reason)" [analytics/webstatscollector] (master) - https://gerrit.wikimedia.org/r/51598 [00:16:36] Change restored: Ottomata; "(no reason)" [analytics/webstatscollector] (master) - https://gerrit.wikimedia.org/r/51598 [00:16:37] <^demon> greg-g: So in scheduling that upgrade, I forgot this meeting...do we have another slot today? [00:16:40] New patchset: Ottomata; "Add replace_space function" [analytics/webstatscollector] (master) - https://gerrit.wikimedia.org/r/51608 [00:24:20] Change abandoned: Ottomata; "Using this one:" [analytics/webstatscollector] (time_travel) - https://gerrit.wikimedia.org/r/50195 [00:25:52] New patchset: Ottomata; "Add replace_space function" [analytics/webstatscollector] (master) - https://gerrit.wikimedia.org/r/51608 [00:35:08] dang, he's gone and I missed it [00:36:52] greg-g: His stuff appears to still be in the office, so despair not [00:37:24] greg-g: ^demon is still here, he's in a meeting [00:37:36] which should be over.... 7 minutes ago [00:39:08] and it's over :D [01:08:51] New patchset: Zfilipin; "Add proper test for ResourceLoader errors." [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/51294 [01:09:39] Change merged: Zfilipin; [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/51294 [16:19:01] New patchset: Jeroen De Dauw; "Re-enable voting for EducationProgram" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/50916 [17:32:26] lo [17:33:50] New review: Hashar; "Had that on my radar for the whole week, simply forgot about merging / deploying it :-] Sorry for th..." [integration/zuul-config] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/50916 [17:33:50] Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/50916 [19:01:19] Change abandoned: Ottomata; "(no reason)" [analytics/webstatscollector] (master) - https://gerrit.wikimedia.org/r/51598 [19:35:42] New patchset: Demon; "Add replace_space function" [analytics/webstatscollector] (time_travel) - https://gerrit.wikimedia.org/r/51680 [19:49:05] New review: Diederik; "Ok." [analytics/webstatscollector] (time_travel); V: 2 C: 2; - https://gerrit.wikimedia.org/r/51680 [19:51:01] Change merged: Diederik; [analytics/webstatscollector] (time_travel) - https://gerrit.wikimedia.org/r/51680 [19:52:27] New patchset: Demon; "Add replace_space function" [analytics/webstatscollector] (master) - https://gerrit.wikimedia.org/r/51608 [19:52:27] Change merged: Demon; [analytics/webstatscollector] (master) - https://gerrit.wikimedia.org/r/51608 [21:23:16] greg-g: wanna talk about beta now ? [22:04:49] ooh interesting. new gzip-compatible compressor that does slightly better: http://www.networkworld.com/news/2013/030113-google-publishes-zopfli-as-open-source-267274.html [22:04:54] might be nice for pngcrush :) [22:06:08] This compressor takes more time (100x slower), but compresses around 5 percent better than zlib [22:06:21] ouch [22:07:10] well it goes on to say "2 to 3 times slower" than zlib at maximum [22:07:16] and most folks don't use zlib -9 [22:07:23] cause it's slow ;) [22:07:27] yup [22:07:49] hashar: sure, where are you? [22:07:53] might be worth it for PNG thumb generation though [22:08:02] greg-g: 6th but I will come down to you :-] [22:08:08] ah, I was just there! [22:08:35] if it's for resources you can compress once and forget about [22:08:38] might be fine [22:09:48] yeah wouldn't probably want to use that on dynamic html pages [22:09:57] but thumbs we do once and then cache, so that's ideal [22:11:48] the only issue there is going to be how long the user really has to wait (eg upload an image -> thumb is generated right then) [22:11:53] greg-g: finishing a puppet manifest and I Come. Roughly in 5-10 mins [22:12:25] guess some testing would be nice [22:14:06] hashar: awesome [22:16:49] notice: /Stage[main]/Role::Lucene::Front_end::Poolbeta/Mount[/a]: Triggered 'refresh' from 1 events [22:16:50] yeahhh [22:18:18] it is good to be hacking again after a few days of meeting / meetup [22:18:43] still have to figure out the l10nupdate user trying to get deployed on labs but hell… that will be for later [22:18:52] greg-g: wanna take sun outside while I smoke ? [22:22:12] hashar: sure thing, meet you out front [22:22:20] k going down now [22:30:39] oh nice one of their test corpuses for the compression was…. 100 megabytes worth of english wikipedia ;D [22:33:07] That's not very many articles! [22:34:37] nope [22:34:41] we got more [22:40:56] hi is Chris Steipp around? Not sure what his nick is [22:41:20] if anyone wants to debug the multi-site login token issue, i could do it [22:42:25] chrome on my machine is having that issue [22:42:27] yurik: He's csteipp [22:42:40] thx RoanKattouw [22:42:47] Hi yurik [22:43:02] That would be great! [22:43:24] csteipp: what tokens would you want me to look at? [22:43:42] i am logged in into *wiki, but not in wikivoyage [22:44:23] i didn't want to logoff (might clear all tokens), so went to http://en.wikipedia.org/wiki/Special:UserLogin [22:44:24] yurik: Are you reliably not getting logged in? Or did you just hit this now? [22:44:26] and logged in [22:44:55] reliable, but i don't want to clear all my tokens manually as i suspect that might stop the issue [22:45:35] Are you able to see your cookies? [22:45:45] so when i re-logged in without loggin out using special:userlogin, i saw all the images (autologin ones i take it) [22:45:53] csteipp: yes 🍪 🍪 🍪 [22:45:55] Hey hashar, is there any chance this can be fixed? https://gerrit.wikimedia.org/r/#/c/51786/1/specials/SpecialGlobalGroupPermissions.php [22:46:22] Krenair: invalid PHP ? no way [22:46:24] Oh it's PHP 5.4 vs. 5.3 -.- [22:46:30] ( foo ) [22:46:41] It's valid PHP. [22:46:46] Old versions just don't recognise it as such >_> [22:46:46] yurik: so do you see a centralauth_ cookie for wikivoyage? [22:46:47] any random text is valid php! [22:46:48] glad it caught it hehe [22:46:51] sec [22:47:04] Krenair: cluster has 5.3 and MW 1.21 is still supporting 5.3.x [22:47:08] Krenair: :( [22:47:32] csteipp: i see en.wikivoyage.org cookie - centalnotice_bucket [22:48:34] yurik: So no "centralauth_Session" [22:48:43] csteipp: nope [22:50:06] So yurik, did you mean that you're logging in with tokens, as in you have "remember my login..." checked? [22:50:26] Or you just meant the autologin tokens? [22:50:26] i did not set "remember" [22:50:32] Ok, cool [22:50:51] the login page showed all the wiki-family images [22:50:58] So the next best step is probably for you to log out [22:51:11] And you should see that you're logged out on all the wmf sites [22:51:17] btw, en.wiki which i used to login has 10 cookies [22:51:18] Then log back in [22:51:31] Yeah, i know :( [22:51:46] But when you login with chrome, if you can watch the network [22:51:53] So you can see the headers of the connections [22:52:08] (ctrl+i, then go to network tab) [22:53:24] csteipp: logged off (enwiki), checked all other *.wikipedia (all logged off), re-logged in, same issue [22:53:46] yurik: Did you have the network tab open? [22:53:56] no, saw it too late, let me redo [22:54:34] I just want to make sure your browser actually made the call to "Special:AutoLogin?token=...." [22:55:36] And make sure you have a, "Set-Cookie: centralauth_Session=...." in the response headers. [22:57:46] csteipp: looking at all the calls from en.wiki -- i see all the special:autologin?token=... (all tokens are different) [22:58:08] yurik: Yep, they should be. [22:58:26] So you should see one for each family [22:58:43] Now if you visit en.wikivoyage.org [22:58:44] csteipp: yes, i see one for each, but no go [22:59:04] and look at the request headers for the call to Main_Page [22:59:55] csteipp: in req header : Cookie:centralnotice_bucket=1-4.2 [22:59:56] See if there is a centralauth_Session sent with the request [23:00:12] Grr... No Session? [23:00:15] nope [23:00:20] That's wierd [23:00:29] now, this is chrome beta [23:00:43] so it could be something weird like that [23:00:45] Oh, do you still have the Special:AutoLogin call open? [23:00:57] yes [23:01:02] with all the network calls [23:01:03] different tab [23:01:10] Can you look at the Headers [23:01:21] and look at the response headers? [23:01:23] which call? [23:01:37] Any of them... maybe the wikivoyage one? [23:01:49] http://en.wikipedia.org/w/index.php?title=Special:UserLogin&action=submitlogin&type=login&returnto=Main+Page ? [23:01:54] a, ok, sec [23:02:38] I just want to confirm that en.wikivoyage.org/wiki/Special:AutoLogin actually sent back a centralauth_Session cookie [23:02:55] csteipp: Set-Cookie:centralauth_User=Yurik; expires=Wed, 28-Aug-2013 22:56:58 GMT; path=/; domain=.wikivoyage.org; httponly [23:02:57] Set-Cookie:centralauth_Token=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.wikivoyage.org; httponly [23:02:58] Set-Cookie:centralauth_Session=xxxxxxxxxx; path=/; domain=.wikivoyage.org; httponly [23:03:08] (xxx's are mine) [23:03:16] (good call :) [23:03:28] Alright, so Chrome is just refusing to store the cookie [23:03:46] guess so [23:04:12] Possibly related to this issue: http://arstechnica.com/business/2013/02/firefox-22-will-block-third-party-cookies/ [23:04:15] Hmm.. so that is Chrome 26? [23:04:26] I could give you all the headerss stuff if that would help [23:04:43] yurik: Not really [23:04:43] i'm running Version 27.0.1423.0 canary [23:05:08] btw, slightly outdated, wants a restart [23:06:23] Oh yurik: do you have "Block third-party cookies and site data" checked in your cookie preferences? [23:07:07] csteipp: yes [23:07:21] hmm, could that be the reason for everyone? [23:07:47] checking without ... [23:07:50] Hmm.... maybe. Can you try unchecking (just temporarily) and seeing if it works? [23:07:52] Thanks :) [23:08:12] csteipp: yep [23:08:14] fixed [23:08:25] now if FF will do this by default... [23:08:34] yurik: Thanks... that explains it [23:08:48] do you think this is the same issue as everyone else was having? [23:08:53] Yeah, I think more and more browsers are going to do this [23:09:00] I'm going to guess it's similar [23:10:12] sigh, well, thanks, hope we could come up with a workaround... anyone cares to purchase "W.org" ? [23:10:41] its fore sale :) [23:11:44] than we would have wikipedia.w.org, and no issues [23:37:44] kaldari: for centralnotice; do you recall why we start centralnotice using the SiteNoticeAfter hook; and not just using say a $.ready() call? [23:39:23] I was wanting to start loading the notice data as soon as possible, even before the DOM was finished loading [23:40:11] In my tests though, it didn't seem to actually make much difference [23:40:25] we could probably move it back to $.ready() [23:41:31] ok -- the motivation behind this is because the mobile front end currently does not implement the sitenoticeafter hook; so I'm taking this opportunity to look at other ways to do it [23:42:56] mwalker: The whole thing should be rethought. In the old days we only displayed sitenotices in 1 particular div. Now we might inject them into the DOM anywhere. [23:43:31] or nowhere [23:44:09] :) [23:44:16] since notices aren't necessarily 'banners' now [23:44:46] ya -- I'm going to start delivering JS to be executed by the controller before banner injection into the DOM [23:44:53] but; I think the div still makes sense [23:45:24] just be careful not to break the local sitenotices [23:45:41] are those going to be supported in mobile as well, or just CentralNotices? [23:47:00] jon isn't sure :p [23:50:09] kaldari: do you know anything about how the sitenotice stuff works -- like who actually adds the sitenotice div? [23:50:26] I think it's in core [23:51:24] there's also the DismissableSiteNotice extension which I think is a fancier version of the basic idea [23:53:01] I think all the wikis have DismissableSiteNotice turned on [23:53:44] odd -- CentralNotice will always take precedence over site notice (even if empty) -- so theres no point to that extension [23:54:43] I think it can display both simultaneiously [23:55:15] most of the core sitenotice stuff is in the Skin code