[00:02:39] I found a scary way of doing it [00:03:23] set nginx to ingore Set-Cookie and to just add the session keys/username to the cache key [00:05:34] Ryan_Lane: hey, got 5-10 min to talk with me about https://bugzilla.wikimedia.org/show_bug.cgi?id=35148 ? setting up the Gerrit project owner groups -- if you can devolve the power to me, that's great [00:06:14] also Ryan_Lane, what happened to the nginx project? [00:09:19] eh? [00:09:36] I already discussed this with hashar [00:09:40] and AFAIK it's solved [00:10:11] JRWR: what do you mean? it's still there [00:10:22] sumanah: I don't understand what's to discuss [00:11:22] Ryan_Lane: could you put the solution/plan into a comment in the bug? I wasn't around for the discussion. What's the resolution? [00:11:32] who's gonna make the groups? [00:11:41] I mean, populate the Gerrit project owner groups [00:12:30] I think the group is already created [00:12:42] seems anyone in ops or wmf group can make groups [00:13:05] ok, so the issue is actually populating the groups https://gerrit.wikimedia.org/r/#admin,group,6 and https://gerrit.wikimedia.org/r/#admin,group,7 [00:13:32] Those are not populated yet. Shall I try to populate them? [00:13:45] I can't; greyed out. [00:13:49] Ryan_Lane: ^ [00:16:52] sumanah: I added you to wmf group [00:16:58] log out, log in, then it should work [00:18:21] log out/in is required because gerrit caches groups [00:18:45] remember, don't add anyone in ops or wmf to that group manually [00:18:52] the groups should be included [00:19:00] only add volunteers [00:28:55] Ryan_Lane: I cannot access my SSHKeys nor the instance panel anymore [00:29:09] use the labs channel :) [00:29:28] Ah! too many to count [00:52:49] Ryan_Lane: No, I do not have permission to add anyone to that Gerrit project group [00:52:52] ("wmf") [00:52:58] I logged out and logged in again. [00:53:13] shouldn't you be trying to edit mediawiki? [00:53:28] OK! [00:53:36] I also need to add people to the wmf group. [00:53:44] that's an ldap group [00:53:49] I was going to start there. Oh. [00:53:57] this is why I wanted mediawiki group to be a gerrit group :) [00:54:00] easier to modfy [00:54:01] *modify [00:55:24] RoanKattouw: re https://www.mediawiki.org/wiki/Special:Code/MediaWiki/112930#c32165 [00:55:28] can you elaborate? [00:55:46] Well you're naming a closure [00:55:48] I'm not sure what's weird about it or why it wouldn't be legal [00:55:52] it's not a closure [00:55:57] Yes it is [00:56:07] $(document).on( 'mousemove', function updateCursorPosition( e ) { .... } ); [00:56:08] OK, so, Ryan_Lane, to summarize: I can add volunteers to the "mediawiki" Gerrit project owners list ("group"), but I cannot add WMF developers ("wmf") or WMF operations ("ops") because those are LDAP groups? That's ok as long as we know whom to ping to add people to those LDAP groups [00:56:14] That's a closure but it's named [00:56:24] Note that this doesn't actually set the updateCursorPosition variable at all [00:56:31] I know [00:56:33] it's not supposed to [00:56:35] But somehow it's valid syntax and the function name is just ignored [00:56:40] it's not ignored [00:57:02] So what the hell does this do then? I've never seen this syntax before [00:57:12] sumanah: you can add people to the wmf group [00:57:20] via modify-ldap-group on formey [00:57:23] using sudo [00:57:31] be careful doing so, though [01:00:48] RoanKattouw: basically closures don't exist in javascript, everything is just a function. a function expression is a valid value for anything. Function expressions can be named. They usually are. This name is never used outside the scope of the function only when referencing it (e.g. var foo = function bar() {}. foo.name == 'bar';). This name is used for 2 things. As documentation (i.e. descriptively name the function), and in stack traces. [01:01:01] The weird thing is when you put a function expression without passing or saving it into a variable [01:01:18] then it automagically expands into var {name} = function {name} { }; [01:01:25] Right [01:01:42] But either way, the name here is redundant [01:02:03] Ryan_Lane: is there documentation somewhere saying that it's okay to add any WMF-employed or -contracted engineer to the wmf LDAP group? If there isn't, I'm wary, because what if that gives them privs they shouldn't have? [01:02:38] functionally speaking. I personally like to name functions where possible and not duplicate (for example in an object literal it gets dull to name them because the name would be used twice: var foo = { bar: function bar() { } }; then its convenient to leave name off. [01:03:08] anyway, I'll remove it in this case since its just an event handler [01:12:42] Ryan_Lane: I can wait till you fix PHP on labsconsole to bug you some more about this permissions documentation thing :-) [01:14:11] it's back up [01:14:37] ok, see above, Ryan_Lane ("is there documentation somewhere...") [01:15:10] also, what triggers the procedure for ops people to get added to and removed from that LDAP group? hiring, and what else? [01:15:23] to ops? [01:15:30] people who have ops privileges [01:15:34] so, not just wmf staff [01:15:40] but people we consider to be on the ops team [01:15:47] OK. Who determines that? [01:15:57] hell if I know [01:16:04] basically if we give them root [01:16:16] so, bottom line, don't touch that group [01:16:45] wmf should likely be staff [01:16:49] and maybe it's a shitty group name [01:16:56] I know I won't, but I'm documenting "here's how Gerrit project ownership works & why people would get removed or added" so I want to clarify the ops part of the puzzle [01:17:00] it's a wmf staff who have shell [01:17:20] ops manages ops [01:17:24] no one else needs to care or know [01:17:34] Ryan_Lane: well, not quite [01:17:45] ok, put "touch this group and die" [01:18:05] I care, because it influences "who has the power to do foo?" (which I am documenting) [01:18:16] Ryan_Lane: Is labsconsole fixed now? Next on your list: secure broke, see -tech [01:18:18] ops has power to do whatever they want [01:18:38] RoanKattouw: ah. I bet puppet forced an upgrade of something [01:18:42] Yay labsconsole is up [01:18:49] nagios-wm PROBLEM - HTTP on singer is CRITICAL: Connection refused [01:36:25] Ryan_Lane: and what was the last you heard from hashar re Bug 35209 - Mass-create a bunch of Gerrit accounts for existing SVN committers ? [01:36:45] no one told me anything [01:38:21] * sumanah writes clearer directions in that bug. [01:47:37] that would just be running "add-labs-user --wikiname="" --mail="" [01:47:52] in a loop for all existing svn users.. right [01:48:45] mutante: well, for all SVN users who don't have obfuscated email addresses, and who actually have names listed [01:49:07] gotcha [01:49:42] mutante: I wrote it out a bit in https://bugzilla.wikimedia.org/show_bug.cgi?id=35209#c0 [01:50:00] mutante: if you want to create the CSV, I'll hand-fix it to fix the obfuscations [01:50:02] etc [01:50:05] sanitize the data [01:51:06] i see [01:51:32] wonderin if hashar already wrote a script [01:52:08] I don't know :-( [01:52:25] I think he was thinking of using something from CPAN, MediaWiki::User [02:06:31] sumanah: re, got disconnected, tried ldaplist on formey.. ran into "IndexError: list index out of range" when trying to list everything .. for now [02:06:55] i'll see if hashar is around [02:07:45] mutante: ! if you have an interest in doing this... [02:12:53] sumanah: how about "everybody who has an 'N' in the 'Ready for git?' column" on http://svn.wikimedia.org/users.php [02:13:14] or does this mean the user itself said they are not ready to use git [02:37:48] mutante: the "ready for git" marker does NOT reflect any particular user preference [02:38:26] mutante: if you can generate a list from people who have a "Y" in that "ready for git" column, that would be cool [13:42:32] Hey, there is currently a major issue with the moodbar that vandals are abusing [13:42:52] They are using it to send 5000+ feedbacks in a couple minutes [13:43:20] and since it isn't hooked up to Extension:AbuseFilter or the spam blacklist, they are spamming racist conspiracy sites [13:43:45] https://en.wikipedia.org/w/index.php?title=Special%3ALog&type=&user=KingMolestia&page=&year=&month=-1&tagfilter=&hide_patrol_log=1&hide_review_log=1 [13:43:51] and more... [13:45:25] I see it [13:45:32] I'm lokoing at the bug report and the log right now [13:45:56] thanks [13:52:11] please see if that disabled it or if the feature is still active [13:52:36] ok [13:52:49] (I have never used the feedback dashboard stuff so...) [13:54:33] and let me know! :-P [13:56:19] I had to create a temporary new account, since admins don't see the moodbar :P [13:56:24] ah [13:57:37] It's still up :( [13:57:41] rats. [13:57:52] lemme see which config var does it [13:57:59] I thought that one would have got it [13:59:29] oh it's this mood bar thing [14:00:23] yeah [14:02:03] trying again, please wait [14:02:16] ok it went around [14:02:19] please check again [14:02:42] in theory this wood turn off the entire mooodbar feature [14:02:45] would [14:02:47] moodbar [14:02:49] :-/ [14:03:34] ReaperEternal: [14:03:36] ^^ [14:04:51] ok [14:05:21] the stuff is stillin the log of course, that will still have to be cleared out (hid or whatever) but hopefully [14:05:28] nothing new til that hole is fixed up [14:05:32] Seems to be disabled now, thanks! [14:05:38] yay [14:05:45] thanks for the bug [14:29:10] Well, the vandalbots seem to have been stopped [14:29:17] thanks for the help apergos [14:29:23] sure [14:29:51] I just happened to see the bug scroll by in the channl [14:31:22] Bye [14:31:31] bye [17:14:35] http://www.mediawiki.org/wiki/20_percent time [17:15:02] today is AaronSchulz and preilly [17:16:20] basically, I think code review, code review and more code review [17:56:29] robla: so, code review [17:59:02] * robla looks through the list [17:59:09] preilly: yup, code review [17:59:18] ha ha [18:00:02] hee, I made fuhny [18:40:57] binasher: thanks for what you've done so far, got another error message now: (Can't contact the database server: Host 'i-00000176.pmtpa.wmflabs' is not allowed to connect to this MySQL server (deployment-sql)) [18:44:00] Thehelpfulone: Ryan_Lane: you may need to redo the grants on that db [18:45:38] okay, well I'm a n00b to the development side so I guess that's a job for Ryan_Lane or someone with similar knowledge (unless it's not too difficult, then I could have a look) [18:49:53] ah [18:49:55] hm [18:50:01] probably need to set the grants for the web servers [18:50:38] of course, I don't know the mysql root password [18:55:53] on what hosts? [19:58:38] Ryan_Lane: hi [19:58:47] Ryan_Lane: password for root on mysql is puppet [19:58:55] anyway you don't even need to know it [19:58:58] sudo mysql works too [19:59:15] it works from localhost only [20:00:07] oh [20:00:11] this isn't -labs [20:00:13] nvm me [20:00:35] Thehelpfulone: hi [20:01:00] hi petan [20:01:21] see -labs [23:03:30] hi folks [23:04:30] http://www.mediawiki.org/wiki/20_percent checkin [23:04:41] Hi [23:05:27] bsitu: are you in a spot where you're comfortable code reviewing yet, or do you think it makes more sense fixing up 1.19 tarball release blockers? [23:05:34] (or something else) [23:07:19] robla: I think I should do a few more 1.19 fixes [23:08:23] here's the query for blockers: https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&list_id=99857&resolution=---&target_milestone=1.19.0%20release&known_name=1.19%20release%20blockers&query_based_on=1.19%20release%20blockers [23:08:51] a different view of the same thing: http://etherpad.wikimedia.org/119triage [23:10:23] looks like most of them have been resolved [23:11:06] yeah, Aaron is on top of one of them [23:11:21] there is one though: https://bugzilla.wikimedia.org/show_bug.cgi?id=34885 [23:11:33] Trevor started this, but wasn't able to finish it off [23:12:50] bsitu: is that one you might be able to finish off? [23:14:03] I can take a look at it, but I am not very good at javascript though [23:15:09] k...lemme look at some of the other bugs [23:17:49] hiya robla, how are you feeling? [23:18:03] awjr: doing pretty well, thanks! [23:18:10] sorry im late was pushing out a fix for a mobilefrontend bug [23:18:18] good im glad to hear it :) [23:18:24] no worries about being late [23:18:43] I think the coordination needed here is pretty minimal for experienced devs: code review [23:18:54] k sounds good [23:19:14] aaron sent me a long list of his revs to review earlier this week, i'll start there [23:21:59] bsitu: I'm searching through this for a likely candidate or two: https://bugzilla.wikimedia.org/buglist.cgi?priority=High&list_id=99870&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&resolution=---&query_based_on=High%20priority%20bugs&query_format=advanced&known_name=High%20priority%20bugs [23:22:16] awjr: http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWiki&path=%2Ftrunk%2Fphase3&status=new&author=aaron [23:22:22] anything else easy in there too :) [23:22:45] hahaha AaronSchulz you'll keep me busy tomorrow [23:27:04] bsitu: https://bugzilla.wikimedia.org/show_bug.cgi?id=33214 ? [23:27:51] okay