[02:27:45] !log LocalisationUpdate completed (1.21wmf9) at Mon Feb 11 02:27:44 UTC 2013 [02:27:48] Logged the message, Master [02:52:40] !log LocalisationUpdate completed (1.21wmf8) at Mon Feb 11 02:52:39 UTC 2013 [02:52:42] Logged the message, Master [10:37:01] New patchset: Hashar; "(bug 44424) wikiversions.cdb for labs" [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/47564 [11:50:27] New patchset: Silke Meyer; "Fixing a typo in mx-extension" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/48439 [11:56:04] New review: Nikerabbit; "mx -> mw?" [operations/puppet] (production) C: -1; - https://gerrit.wikimedia.org/r/48439 [11:58:14] New review: Silke Meyer; "Erm... yeah. Fixing a typo and adding one. m)" [operations/puppet] (production) C: 0; - https://gerrit.wikimedia.org/r/48439 [11:58:22] New patchset: Silke Meyer; "Fixing a typo in mw-extension" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/48439 [12:03:09] New patchset: Silke Meyer; "Fixing permissions on images folder" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/48441 [12:20:48] New review: Silke Meyer; "I was also wondering if this shouldn't be in mediawiki.pp as it is related to permissions on the def..." [operations/puppet] (production) C: 0; - https://gerrit.wikimedia.org/r/48441 [12:53:57] New patchset: Legoktm; "(bug 44871) Enable Translate extension for foundationwiki" [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/48444 [13:03:53] New review: Siebrand; "Please don't merge this before there is ample justification for this on the bug." [operations/mediawiki-config] (master) C: -1; - https://gerrit.wikimedia.org/r/48444 [13:55:22] !log jenkins: regenerating all phpcs-HEAD jobs so they stop failing when no files need to be processed {{bug|44567}} {{gerrit|48450}} [13:55:26] Logged the message, Master [14:56:14] Change merged: jenkins-bot; [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/47074 [14:59:09] !log hashar synchronized wmf-config/CommonSettings.php '{{bug|44251}} hardcode $wgDBuser = "wikiuser" {{gerrit|47074}}' [14:59:11] Logged the message, Master [14:59:45] mw1161: rsync: change_dir#3 "/apache/common-local" failed: No such file or directory (2) [14:59:45] mw1161: rsync error: errors selecting input/output files, dirs (code 3) at main.c(643) [Receiver=3.0.9] [14:59:46] bahhh [14:59:49] poor mw1161 [15:00:26] New review: Hashar; "deployed" [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/47074 [15:15:27] backportpackage: Error: The package 'python-tox' does not exist in the Ubuntu primary archive in raring, raring-security, raring-updates or raring-proposed [15:15:33] but it is there http://packages.ubuntu.com/raring/python-tox !!! :D [15:33:26] dpkg-buildpackage: full upload (original source is included) [15:33:27] yeahhh [15:33:33] echo $? [15:33:33] 0 [15:33:35] ahaha [15:33:38] * hashar chubabba dance [15:36:29] hehe [15:36:40] I end up with a bunch of files [15:36:48] which are supposed to build a package for me now :-] [15:36:49] ping paravoid for this yummy bit of fun? [15:36:50] https://gerrit.wikimedia.org/r/#/c/48041/ [15:36:51] :) [15:36:54] https://bugzilla.wikimedia.org/show_bug.cgi?id=44443#c1 [15:36:58] that is a lot of funny fun [15:44:34] hmm [15:44:42] I think I will end up creating a jenkins job to backport packages :-D [15:44:58] err: Could not retrieve catalog from remote server: Error 400 on SERVER: Duplicate definition: Package[build-essential] is already defined in file /etc/puppet/manifests/generic-definitions.pp at line 1073; cannot redefine at /etc/puppet/manifests/misc/package-builder.pp:11 on node integration-jobbuilder.pmtpa.wmflabs [15:44:59] grmbmbmb [15:45:32] !g I6a4e9ef4c3a70d9484ae60362b81bb35992cb477 [15:45:32] https://gerrit.wikimedia.org/r/#q,I6a4e9ef4c3a70d9484ae60362b81bb35992cb477,n,z [15:48:23] New patchset: Ottomata; "Fixing duplicate package declaration on stat1" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/48458 [15:48:30] haha [15:48:37] i'm fixing a similiar error but for a different package [15:49:32] New patchset: Ottomata; "Fixing duplicate package declaration on stat1" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/48458 [15:50:04] Change merged: Ottomata; [operations/puppet] (production) - https://gerrit.wikimedia.org/r/48458 [15:50:11] ottomata: my instance was outdated :-] [15:50:26] puppet should probably detect that they are the same [15:50:27] p [15:50:40] I mean when you have two package { 'foobar': ensure => present } [15:56:49] oh [15:56:52] so [15:57:03] apparently we can detach a process from a terminal [15:57:22] ^Z [15:57:22] bg [15:57:26] disown 1 [15:58:45] * hashar waves [15:58:47] see you later [15:58:48] huh [15:58:51] did not know that [15:58:52] ok byyee [16:02:45] New patchset: Ottomata; "Adding Frank Schulenburg user and adding him on stat1. RT 4475" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/48460 [16:03:19] Change merged: Ottomata; [operations/puppet] (production) - https://gerrit.wikimedia.org/r/48460 [16:05:09] New patchset: Aude; "Enable Wikibase Client on enwiki" [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/48461 [16:05:52] ottomata the RT man should name an heir :) [16:06:15] yeah who's on it htis week? [16:06:21] I dunno! [16:06:36] New review: Aude; "i'm doing this out of order.... have a couple backports to do for the extension." [operations/mediawiki-config] (master) C: 0; - https://gerrit.wikimedia.org/r/48461 [16:21:39] New patchset: Cmjohnson; "Decommissioning srv226-234 updating site.pp/decommissioning.pp and dhcpd file" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/48464 [16:22:56] Change merged: Cmjohnson; [operations/puppet] (production) - https://gerrit.wikimedia.org/r/48464 [16:27:40] !log commenting out srv226-234 on pybal/pmtpa [16:27:41] Logged the message, Master [16:27:49] New patchset: Jgreen; "adding r-cran-rmysql to stat1 for RT #4470" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/48467 [16:28:35] Change merged: Jgreen; [operations/puppet] (production) - https://gerrit.wikimedia.org/r/48467 [16:36:22] New patchset: Demon; "Adding torblock to debug log groups" [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/48469 [16:39:06] Change merged: Demon; [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/48469 [16:40:18] New review: Aude; "https://gerrit.wikimedia.org/r/#/c/48465/ has our backports. once that is merged, then we are okay ..." [operations/mediawiki-config] (master) C: 0; - https://gerrit.wikimedia.org/r/48461 [16:40:40] !log demon synchronized php-1.21wmf9/extensions/TorBlock 'Updating TorBlock to master' [16:40:42] Logged the message, Master [16:41:00] * aude eagerly awaits enwiki deployment :) [16:41:28] !log demon synchronized wmf-config/InitialiseSettings.php 'Enable logging group for torblock' [16:41:29] Logged the message, Master [16:41:46] <^demon> apergos: Ok, so TorBlock & InitialiseSettings changes are live. [16:41:56] sweet [16:42:01] now we just wait for it to fail [16:42:19] thank you! [16:42:48] <^demon> Bah, way too much logging. [16:43:07] <^demon> ssh to fluorine, and tail /a/mw-log/torblock.log [16:46:09] ok I won't merge that then :-D [16:46:14] sec [16:46:53] <^demon> I'm disabling some of the useless logging. [16:46:55] well that is really a lot og logging [16:46:58] yeah, saw that [16:47:22] I mean [16:47:27] "Checking Tor status"... really? [16:48:49] <^demon> Yeah, I'm removing those. [16:49:05] <^demon> "Unable to load Tor exit node list: cold load disabled on page-views." [16:49:07] <^demon> We don't care. [16:49:20] yep [16:50:31] !log demon synchronized php-1.21wmf9/extensions/TorBlock 'TorBlock to master, now with less annoying logs' [16:50:32] Logged the message, Master [16:51:04] heh [16:51:08] <^demon> apergos: Could you clear that log so we can start clean? [16:51:12] New patchset: Silke Meyer; "Fixing broken dependencies for updating mw-extensions" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/48474 [16:51:41] done [16:52:01] <^demon> Ok, now let's see what happens when we try running without --force. [16:52:13] well it's working atm [16:52:19] so hopefully... nothing [16:52:25] <^demon> Figures. Well, now we've got a way to debug next time :) [16:52:38] yep [16:52:56] thanks for setting this up! [16:54:44] ^demon: on wikidata, we're having problems with the new minwiki (new wikipedia) appearing in the list of sites [16:55:02] <^demon> apergos: np. [16:55:02] as seen in JS, it seems, but memcached and api are okay [16:55:16] any idea how to fix? to touch a file? [16:55:23] <^demon> Dunno, let's find out. [16:55:31] ok [16:55:44] <^demon> apergos: Gerrit upgrade in 8 hours :D [16:55:44] it's WikibaseLib/includes/modules/SitesModule.php [16:55:54] i suspect that's the one that needs to be "kicked" [16:56:05] it's a dynamically generated module base on the sites table [16:56:13] <^demon> So, touch & sync? [16:56:19] sure [16:56:38] the memcached was fine, on friday and it appears in the api [16:57:00] woo hoo! [16:57:12] drinks in 8.5 [16:58:23] hmmm, i don't see minwiki in http://wikidata.org/w/api.php [16:58:38] !log demon synchronized php-1.21wmf9/extensions/Wikibase/lib/includes/modules/SitesModule.php 'Touching file' [16:58:39] Logged the message, Master [16:59:29] * aude sees if that fixes it [16:59:41] New patchset: CSteipp; "Enable Global Abuse Filters on test, mediawiki, wikidata" [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/48070 [17:02:44] still no min wikipedia :( [17:02:59] <^demon> I see 'min' under several language code listings. [17:03:04] <^demon> Ctrl+F for "min," [17:03:30] <^demon> Oh hrm, but not under sites. [17:03:32] <^demon> Got it. [17:03:42] in the wikibase api modules? [17:04:31] <^demon> Yeah, I'm looking at wbgetentities [17:04:37] wbsetsitelink [17:04:39] hmmm [17:04:55] <^demon> minwiki is new-ish, right? [17:05:12] it's there as a language [17:05:15] <^demon> Were the interwiki caches rebuilt? [17:05:33] i doubt it or no idea really [17:06:07] <^demon> I doubt they were. Hmm, how to do this. [17:06:08] shouldn't matter for the wikibase modules though [17:06:39] <^demon> How do we populate the sites table? [17:07:02] we already did and it's there [17:07:11] The interwiki caches were updated a couple of times post addition of the new wikis [17:07:12] e.g. when i look on the toolserver and reedy checked [17:07:22] and the memcached seems refreshed, or maybe not [17:07:40] <^demon> Hmm. [17:08:06] it would be cool if rebuilding interwikis also repopulated the sites table [17:08:56] Probably just stick a new hook in the maintenance script.. [17:09:16] sure [17:09:24] sure it's not difficult to do [17:11:17] http://www.wikidata.org/wiki/Special:ItemByTitle/minwiki/Laman_Utamo [17:11:32] there it should offer "You can also create an item." [17:11:50] but does not, which indicates it didn't like the site code [17:12:06] * aude pokes at the code and see how to debug [17:14:53] New review: Legoktm; "LGTM, but your commit message still mentions wikidata though." [operations/mediawiki-config] (master) C: 1; - https://gerrit.wikimedia.org/r/48070 [17:18:45] Change abandoned: Demon; "Forget this. There's talk of scrapping wikibugs entirely (since wm-bot also does BZ support)" [operations/puppet] (production) - https://gerrit.wikimedia.org/r/45322 [17:34:42] New patchset: CSteipp; "Enable Global Abuse Filters on test, mediawiki" [operations/mediawiki-config] (master) - https://gerrit.wikimedia.org/r/48070 [17:38:08] ^demon: Reedy for debugging stuff with debug log, is it preferred to use wfDebug or wfDebugLog? [17:38:34] <^demon> wfDebugLog() is nice, then we can send things to their own logs with $wgDebugLogGroups [17:38:37] * aude can stick a debug point into the code [17:38:39] ok [17:49:27] good morning Ryan_Lane! you are probably checking monday emails, but have some probably easy LDAP questions for you, whenever you get a sec [17:50:28] ottomata: ? [17:50:43] New patchset: MaxSem; ".gitreview" [operations/debs/mod_tile] (master) - https://gerrit.wikimedia.org/r/48478 [17:52:19] i'm looking into hadoop ldap group lookups, so we can disable nss on the analytics machines [17:52:28] ok [17:52:33] they are documented here [17:52:34] http://svn.apache.org/viewvc/hadoop/common/trunk/hadoop-common-project/hadoop-common/src/main/resources/core-default.xml?view=markup&pathrev=1302740 [17:52:39] the relevant configs [17:52:49] i'm trying to construct an ldap search with the proper values first [17:52:53] so I can figure out what to set them to [17:52:57] I think I know most of the details [17:53:06] i'm mainly unsure on this one [17:53:10] hadoop.security.group.mapping.ldap.search.filter.group [17:53:22] hadoop.security.group.mapping.ldap.search.filter.group [17:53:22] 171 [17:53:22] (objectClass=group) [17:53:22] 172 [17:53:22] [17:53:22] 173 [17:53:23] An additional filter to use when searching for LDAP groups. This should be [17:53:23] 174 [17:53:24] changed when resolving groups against a non-Active Directory installation. [17:53:24] 175 [17:53:25] posixGroups are currently not a supported group class. [17:53:30] question1 [17:54:03] New patchset: MaxSem; ".gitreview" [operations/debs/osm2pgsql] (master) - https://gerrit.wikimedia.org/r/48479 [17:54:08] should I try to lookup the user group membership in the ou=project or ou=posixgroups (i think ou=project, since I can do direct LDAP lookup and don't have to worry about the unix group sync) [17:54:10] ? [17:54:27] hold on, I need to get coffee before I read any of this [17:54:54] haha, ok that's what I thought :p [17:54:58] ping me whenever you are ready, no hurry [17:56:34] New patchset: MaxSem; ".gitreview" [operations/debs/osm-mapnik-style] (master) - https://gerrit.wikimedia.org/r/48480 [17:57:13] ottomata's going for another week? :) [17:58:05] eh? [17:58:17] <^demon> Ryan_Lane: T minus 7 hours :D [17:59:33] ^demon: is a package already built? [17:59:40] ottomata: RT [17:59:58] <^demon> Ryan_Lane: Not yet, but all the changes for it are in gerrit. [18:00:13] <^demon> https://gerrit.wikimedia.org/r/#/c/47806/ [18:00:57] ^demon: ok. need me to build the package, or can you? [18:01:18] <^demon> If you would, that'd be great. I'm a packaging noob. [18:01:23] posixgroups are currently not a supported class? :D [18:01:45] ottomata: that's not an issue really [18:01:49] can't wait until i can edit my commit summaries :) [18:01:55] hm [18:01:56] maybe it is [18:02:23] oh. no. it's fine [18:02:37] ottomata: we use both posixgroup and groupofnames objectclasses [18:02:51] <^demon> As soon as the package is good and on brewster, I can do the apt-get upgrade on labs (the one part of the update I haven't tested yet) [18:03:01] yeah, Ryan_Lane, i'm not sure which, i thikn groupofnames would be better [18:03:05] it should be: (objectClass=groupofnames) [18:03:13] well, it apparently has to be ;) [18:03:30] posixgroup, depending on the rfc doesn't provide usernames as full dns [18:03:38] hmm, ok [18:03:41] we're using an rfc that does, so it should also be fine [18:03:42] if I try ldapsearch [18:03:44] on the CLI [18:03:49] '(objectClass=groupofnames)' cn=analytics [18:03:50] is that ok? [18:03:55] eh? [18:03:57] ok [18:04:04] why cn=analytics? [18:04:07] is that an ldap group? [18:04:09] <^demon> Ryan_Lane: I'll be back soon, gonna grab some lunch. [18:04:15] project yeah [18:04:23] ah. project-analytics [18:04:28] ottomata: so..... [18:04:29] with just '(objectClass=groupofnames)' [18:04:34] it returns tons all of them [18:04:35] be careful there [18:04:47] that group may have people in it that haven't signed an NDA [18:04:51] right [18:04:53] so [18:04:58] i just CCed you on an RT [18:05:03] that has been sitting for a while [18:05:06] the analytics one is just my test [18:05:15] the has-signed-nda group? [18:05:22] lemme find link [18:05:33] https://rt.wikimedia.org/Ticket/Display.html?id=3770 [18:05:34] yup [18:06:15] but, aside from that, '(objectClass=groupofnames)' makes sense. and hadoop shoudl know however the ldap query is supposed to be constructed. [18:06:21] i was just trying to do it via the cli so I could see it myself first [18:06:51] but, also, since there is no other cn=analytics match [18:06:57] when I do ldapsearch with only that as the filter [18:07:00] i get the expected result [18:07:08] without objectClass=groupofnames [18:07:28] how do you see the has-signed-nda group working? [18:07:46] it's cn=project-analytics [18:12:00] hmm [18:12:06] but project-analytics is the posixgroup, right? [18:12:22] re. has-signed-nda (i'd prefer to call it nda-data, nda-) [18:12:38] anyone who has signed the Data NDA would be added to the nda-data project [18:13:05] sensitive files in hdfs would be group-owned by nda-data (with proper mode) [18:13:17] it has two objectclasses [18:13:26] ah ok [18:13:29] hadoop looks up user group membership in ldap, etc. [18:13:33] * Ryan_Lane nods [18:13:49] so, cn=project-analytics has both posixgroup and groupofnames objectclasses [18:13:58] cn=project-analytics does too?, hmmmm [18:14:00] hmm [18:14:01] yes [18:14:20] cn=analytics under the project ou does no have posixgroup [18:14:25] *not [18:14:26] dn: cn=project-analytics,ou=groups,dc=wikimedia,dc=org [18:14:26] objectClass: groupofnames [18:14:26] objectClass: posixgroup [18:14:33] vs [18:14:46] # analytics, projects, wikimedia.org [18:14:46] dn: cn=analytics,ou=projects,dc=wikimedia,dc=org [18:14:54] don't use ou=projects [18:14:59] it's only used for openstack now [18:15:14] hmmmm [18:15:15] ok [18:15:44] ok, so the project-analytics one is the one that we set up to manually sync from the ou=projects thing, right? [18:15:58] so if we use that, I should group own the hdfs files by project- [18:16:00] project-nda-data [18:16:02] right? [18:17:42] I think it'll be a regular ldap group [18:17:46] that doesn't start with project- [18:19:37] hm [18:20:16] but the only cn=analytics entry I see is the one with ou=projects [18:20:58] right? just so I'm sure I'm remember this correctly [18:21:23] ou=project: analytics [18:21:23] ou=groups project-analytics [18:22:19] we sync from the ou=project cn=analytis to ou=groups cn=project-analytics [18:22:23] right? [18:27:04] ottomata: yes [18:27:41] so using project-analytics for file group ownership is the way to go, ja? [18:27:53] if i shouldn't use ou=projects? [18:28:16] all groups you'd want to use are in ou=groups [18:28:44] remember, though, that any group that starts with project- is managed by OpenStackManager [18:29:44] ok [18:29:56] that's ok though, right? those are the ones that we'd manage with labsconsole? [18:30:33] the goal here is to manage sensitive file access for users without shell accounts [18:31:09] labsconsole seems to be the easiest, since there is a web interfaces for adding ldap users into groups [18:31:20] if there's a better way we could do it [18:32:41] manage sensitive files? [18:32:45] that should likely go through ops [18:33:00] which means a group that isn't managed by OSM [18:33:07] (like ops, or wmf groups are now) [18:33:26] it's possible we'll also manage them through the web interface at some point, but it'll be managed differently [18:33:39] management of project- groups is *really* permissive [18:34:14] management of the more privileged groups will require two-factor auth when I add that feature [18:36:33] !log mw1161-mw1188 being pushed into pybal pool as general apaches [18:36:34] Logged the message, RobH [18:39:30] !log disregard, pushing one to test, mw1161 [18:39:31] Logged the message, RobH [18:47:58] RobH: mw1161 has been bitching about rsync, fwiw. [18:49:35] i dunno why its failing to sync, grrr [18:50:11] mw1161: rsync: change_dir#3 "/apache/common-local" failed: No such file or directory (2) [18:50:11] mw1161: rsync error: errors selecting input/output files, dirs (code 3) at main.c(643) [Receiver=3.0.9] [18:50:15] ^ That's what I got earlier today [18:51:52] ori-l: ping? [18:52:59] wikibugz: thx for info, seems to be 1161 specific [18:53:06] as the rest of my batch of new stuff is coming online now [18:59:11] Change merged: Ryan Lane; [operations/debs/gerrit] (master) - https://gerrit.wikimedia.org/r/47806 [19:04:55] (Ryan_Lane, sorry, was eating lunch, let's talk more about ldap after ops meeting) [19:05:02] ok [19:07:34] ori-l, re security review meeting, come on by! [19:08:13] just added you as a guest in google calendar [19:18:22] jeremyb_: can't help with this one. 11:25 -ChanServ(ChanServ@services.)- You have no special access to #wikimedia-tech. [19:18:43] and IRC people did not want Bugzilla tickets.. so shrug [19:19:06] i don't follow on the bugzilla+IRC [19:19:16] but i was just trying to tell you that you didn't need to leave [19:19:25] you can rejoin. leaving didn't help [19:19:50] it's fixed now [19:26:19] hi all! [19:26:53] seems like a stale copy of the Sites list used by Wikidata is stuck in memcached. [19:27:00] what's the procedure for purging key X from all memcached instances? [19:27:06] Is there a bug? [19:27:16] I mean a bug filed in Bugzilla. [19:27:25] i don't think there is one yet, no [19:27:56] I think any shell user purging keys from memcached will like one to track the issue. [19:28:03] <^demon> DanielK_WMDE: What's the key? [19:28:25] * aude can get it [19:28:32] one sec [19:28:58] ^demon: good question... [19:29:08] sites/SiteList#2013-01-23+Site:2013-01-23 [19:29:17] is deployment still planned? [19:29:45] thanks aude [19:29:47] * DanielK_WMDE is slow [19:29:48] it's not a great solution but you could also try backporting my patch that changes the cache key [19:29:58] https://gerrit.wikimedia.org/r/#/c/47880/ [19:30:07] this shouldn't be the normal procedure for this [19:30:31] I'll submit a patch that sets a sane timeout for this [19:30:36] aude: when was the database updated? [19:30:37] good [19:30:47] friday [19:31:06] <^demon> aude: Where's the key defined? I can't find it :\ [19:31:28] it's in SiteSQLStore.php [19:31:33] and uses constant here: [19:31:34] https://gerrit.wikimedia.org/r/#/c/47880/1/includes/site/SiteList.php [19:31:57] to help enable us to refresh things if we change serialization format or some breaking change in the code itself [19:32:53] ok, so SpecialSupportedLanguages has one hour hard coded. I guess we can go with that. [19:33:40] aude: oh, it's SiteList#... but Site:..., I guess I didn't pay attention there, how ugly :P [19:34:00] aude: next time you change the cache key, maybe take the opportunity to make that consistent [19:34:00] heh [19:34:11] sure [19:35:16] <^demon> deleted wikidatawiki:sites/SiteList#2013-01-23+Site:2013-01-23 [19:35:24] cool! [19:35:44] <^demon> I forgot the prefix :) [19:35:47] <^demon> Originally. [19:36:02] <^demon> Had to echo wfMemcKey(...) from eval.php :) [19:36:02] right [19:36:48] ^demon: so, how does that work? Is there a script that goes through all memcached instances? [19:37:36] <^demon> maintenance/mcc.php [19:37:47] <^demon> > delete [19:38:01] <^demon> mcc.php is a fun toy :) [19:38:05] still see no minwiki [19:41:10] no minwiki in api.php (it gets cached?), no minwiki in wb.getSites() [19:41:13] :( [19:41:36] o_O [19:41:39] wtf? [19:42:14] aude: is the current code old and using a different key? [19:43:03] DanielK_WMDE: it is [19:43:15] it has jan 23 cache version key [19:43:56] i suggest my patch, at least this time [19:44:03] give it a new cache key [19:44:28] yea... [19:44:46] hm, i don't see that commit in any deployment branch? [19:44:59] the new key was added in f556c7f2ae3dc09aa55801d42b8002946b768f92 [19:45:01] <^demon> Cherry pick it to 1.21wmf9, and we can deploy. [19:45:04] whouldn't that be in wmf12? [19:45:18] er, wmf9 [19:45:36] aude: just cherry-picking the patch would also change the key [19:45:56] sure [19:46:01] wmf9 [19:46:02] ^demon: i suggest to merge & backport one more patch: https://gerrit.wikimedia.org/r/#/c/48490/ [19:46:25] i can submit it to gerrit [19:46:28] Change merged: Ottomata; [operations/puppet] (production) - https://gerrit.wikimedia.org/r/48249 [19:46:35] oh, that's yours [19:46:35] <^demon> Yeah, that change looks good too. [19:46:38] that would be a godo one [19:46:42] good [19:49:38] <^demon> brb. [19:50:11] Ryan_Lane: the mobile team is expecting to push login functionality into the stable version of MobileFrontend in production tomorrow. at the moment (in beta, limited usership) we are forcing users who log in to use HTTPs. would it be problematic if we continue to force https for users who log in in production (we can easily disable the forcing of HTTPS with a config var) [19:50:13] https://gerrit.wikimedia.org/r/#/c/48492/ for updating the cache key and daniels patch would be good too [19:50:17] ^demon: no hurry [19:50:41] awjr: you mean once they are logged in they continue to use https? [19:50:49] Ryan_Lane: correct [19:51:02] I'd prefer that, in fact [19:51:09] cool :) [19:51:12] as long as when they log out they default back to http [19:51:27] are you using the same code as desktop to handle this? [19:51:39] with the cookie not marked as secure? [19:51:40] Ryan_Lane: you mean the stick https cookie? [19:51:43] yes [19:51:44] yes [19:51:44] <^demon> aude: Ok back [19:51:45] cool [19:51:51] * aude still here [19:52:23] <^demon> Ok, +2'd 48942. Did you backport Daniel's fix too? [19:52:29] Ryan_Lane: ok, awesome. i'll dbl check the logout funcionality (i know it kills the cookies but it might keep on you https otherwise) [19:52:40] ^demon: i think someone has to merge that one [19:52:46] * aude can't +2 [19:52:56] <^demon> Oh, well let's do that. [19:53:03] https://gerrit.wikimedia.org/r/#/c/48490/ [19:53:09] looks good to me :) [19:53:10] <^demon> Already done. [19:53:25] ok, and then we can cherry pick [19:53:36] * DanielK_WMDE wibbles [19:53:58] <^demon> After all this cherry picking, I wouldn't mind some pie. [19:54:21] ^demon: uh, it's not merged? [19:54:34] ^demon: you should have come to the office at wmde today. four birthdays. [19:54:34] <^demon> waiting on jenkins to run tests and merge. [19:54:40] one of them our own aude here [19:54:41] ah, sorry [19:54:42] <^demon> I +3'd. [19:54:43] (waves) [19:54:43] <^demon> +2. [19:54:45] <^demon> Wow, no +3. [19:54:50] heh [19:54:52] * aude eating cakes [19:54:57] more than just one pie ;) [19:55:28] hi hashar [19:56:07] jenkins is slow today [19:56:28] maybe that's why hashar keeps leaving... he didn't want to hear that :P [19:56:33] heh [19:57:03] DanielK_WMDE: na my IRC client sent me a notification about your message, before it finished joining all channels. [19:57:15] this should be hard enough kick for memcached to refresh [19:57:17] DanielK_WMDE: seems that produced some kind of race condition that made the client to skyrocket its CPU usage :-] [19:57:25] :o [19:57:30] short history: you killed my client you bastard! ;-]]]]]]]]]]]]]] [19:57:35] hashar: hahaha! [19:57:45] paravoid: hey, what's up? [19:57:47] DanielK_WMDE: so that is Wikidata on enwiki tonight ? [19:57:52] ottomata1: cool; thanks for the invite! is it happening today? [19:57:59] remember kids: when hashar joins, greet him as quickly as possible :P [19:58:13] naw tomorrow [19:58:19] hashar: if Reedy shows up, yea. Or maybe ^demon wants to do it... [19:58:39] * DanielK_WMDE goes and does the ESTA thing now. [19:58:42] <^demon> DanielK_WMDE: I've already said I'll do it if we can't track down Reedy :) [19:58:43] * aude wants to go around removing site links on enwiki :D [19:58:48]