[00:00:34] AaronSchulz: currently 'refs/changes/66/22466/3' => 'core', // Most of the WMF "live hacks" https://gerrit.wikimedia.org/r/#/c/22466 [00:01:04] plus about 339 symlinks in mediawiki-config [00:01:04] TimStarling: Is that the primary path being used? [00:01:19] that is the primary path in the apache configuration [00:01:29] in mediawiki-config I am including links to /apache since that is more common [00:01:49] yay, consistency [00:02:00] not my fault [00:02:09] wasn't blaming you [00:02:19] blame brion ;) [00:02:22] heh [00:02:35] Who do we have to ~~thank~~blame for /h/w/c/p and stuff? [00:02:47] jeronim [00:03:07] do you know him? [00:03:20] I think /apache was either brion or lee [00:03:20] don't think I do.. [00:03:36] but /h/w was jeronim [00:04:09] he's australian, he did some sysadmin work for us in maybe 2004-2005 [00:04:22] Reedy: so I guest remake and abandon https://gerrit.wikimedia.org/r/#/c/22466 and update that ref ? [00:05:01] You could restore it, rebase (for ease) and then commit that as an amend [00:05:10] then update the ref [00:05:17] I forgot about the restore button [00:05:39] anyway, Ryan's proposed layout has various git-deploy managed repos in /srv/deployment [00:07:31] if it's far too much of a pain in the ass, I can make the deployment system deploy to different destination locations [00:07:37] maybe we should try to avoid updating these 700 /usr/local/apache references more than once [00:08:04] we could change scap to push out to a new location, say /srv/old [00:08:21] then replace the old /usr/local/apache with a symlink farm [00:08:28] * Ryan_Lane nods [00:08:58] then once git-deploy is stable, update the apache configuration and document root symlinks so that we can remove /usr/local/apache [00:13:28] Can anyone help me identify the area that is below content on MediaWiki? I need to edit a spelling error and do not know what it is called to look up how to edit. It is the area below the site where the "last modified, etc.." info resides. THank you [00:21:09] ok, who understands our deployment of poolcounter to the point they are comfortable merging a propsed array change to the server list and knowing if it is going to kill the site? [00:21:11] Reedy: https://gerrit.wikimedia.org/r/#/c/42055/1 [00:21:30] I need to replace tarin (on public ip) with ersch (internal ip) so i can kill off tarin [00:21:46] i just have the wikitech docs on testing, i prefer a live person to confirm said docs are sane. [00:22:08] RobH: I can do it [00:22:24] TimStarling: i saw you added the intruction on how to test, so yay! =] [00:22:37] lemme push change to gerrit [00:23:09] Reedy: mediawiki-config needs to be in a separate directory to the MW checkouts [00:23:28] let's say /srv/old/mediawiki-config [00:23:43] also, can we change the php- prefix now? [00:24:06] maybe just remove it? 1.21wmf6 seems like a good directory name to me [00:24:40] the php- prefix predates the name "mediawiki", it annoys me that it was kept through hetdeploy [00:25:08] can't see why not [00:25:09] i.e. /srv/old/1.21wmf6 [00:26:45] so the idea is to commit relevant changes to mediawiki-config, puppet, etc. to allow these directory structure changes [00:27:34] then swap the existing /usr/local/apache with a symlink farm going to /srv/old [00:28:18] before the swap, /usr/local/apache will have the old code in it, referring to the old directory structure [00:28:59] and people will have to be somehow temporarily prevented from doing a git pull on the old code location [00:29:07] maybe it will have to be in a separate branch of mediawiki-config [00:29:17] to make git-pull harmless [00:31:59] RobH: I see that poolcounterd is up on ersch [00:32:10] it should be fine to just switch over the IP in the MW config [00:32:38] after sync, it will take a while for all job runners to get the new config, unless you restart them [00:33:15] but that's not a problem [00:33:52] even if you shut down poolcounterd on tarin when it is still actively being used, it shouldn't cause problems [00:34:25] because connection failures are gracefully handled, it just pretends there is no poolcounter configured [00:39:07] AaronSchulz / csteipp: Looks like we can't modify the user table before Renameuser is run [00:39:43] If we do it first, RenameuserSQL::rename will fail because it will detect that it changed nothing [00:40:28] Krenair: whats the gerrit id? [00:40:34] https://gerrit.wikimedia.org/r/#/c/39171/2 [00:43:59] $dbw->update( 'user', /* blah blah blah */ ); if ( !$dbw->affectedRows() ) { $dbw->rollback(); return false; } [00:47:49] Krenair: That's a bummer.. although I think updating RenameuserSQL to check for that based on some variable may work [00:51:00] csteipp, it should do, but I was trying to avoid changing two extensions at once [00:51:51] Krenair: I don't like doing that either, but it would make things a whole lot simpler on the CentralAuth side, I think... [00:52:23] I'm still looking at it, but I think it can be easily done. I can make a patch for it tonight. [09:43:58] hi [14:30:41] New patchset: Stefan.petrea; "Adding new pageview reports mobile (in progress)" [analytics/wikistats] (master) - https://gerrit.wikimedia.org/r/41979 [18:54:22] any CI folks around? [19:14:08] CI folks? [19:20:34] Amgine: continuous integration [19:20:57] ([[mw:CI]] exists) [19:21:02] so desu neh. [19:24:39] hashar, why is https://gerrit.wikimedia.org/r/#/c/40569/ failing? [19:26:11] MaxSem: there is an issue currently in the manifests :-] [19:26:19] some file import a non existent file [19:26:23] being fixed right now [19:38:20] MaxSem: try rebasing your changes. [19:38:46] MaxSem: https://gerrit.wikimedia.org/r/#/c/42112/ & https://gerrit.wikimedia.org/r/#/c/40569/ [19:38:53] MaxSem: Ryan merged a fix in the repo [19:38:54] cool, thanks [19:40:39] worked fine. nice [19:40:41] * hashar waves [19:40:43] :) [21:20:46] ori-l: i'd like to use your EventLogging magic in MF - is there anything special i need to do/should be aware of? i'm setting up the extension now [21:21:26] awjr: this change is required, I think: https://gerrit.wikimedia.org/r/#/c/42064/ [21:21:51] ok thanks ori-l, i'll take a look [21:22:03] once that's in, you'll be able to experiment w/the API in a JS shell [21:22:21] so you can try mw.eventLog.logEvent('MobileBetaWatchlist', { ... } ); [21:22:53] where { ... } is either an object conforming to the schema at http://meta.wikimedia.org/wiki/Schema:MobileBetaWatchlist, in which case it will be sent to the server [21:23:04] and logged in a database [21:23:31] or an object not conforming to the schema, in which case you'll get a console message indicating the failure [21:24:01] you needn't worry about logging test events in a db -- we log wgDBname with the event so it's easy to filter out stuff [21:24:27] (I know this is all appallingly under-documented, btw -- we're working on that :)) [21:44:14] ori-l ok cool - where do i define that schema? [21:44:18] ori-l: actually, you in the office? [21:44:23] and ahve a minute? [21:44:37] awjr: i am in the office, but i need a few minutes to wrap something up [21:44:44] do you want me to stop by yr desk in a few? [21:44:58] ori-l ok cool - taht would be awesome, i figure i'll get this going a lot faster with some 1:1 guidance [22:03:53] StevenW: for https://bugzilla.wikimedia.org/show_bug.cgi?id=43546 I was thinking about switching right now [22:15:24] TimStarling: So, for the re-arranging of things are we doing it on fenari (or tin?) to begin with.. Tin has Ryans /srv/deployment/mediawiki [22:15:37] With common being mediawiki-config but using a "newdeploy" branch [22:16:19] Which is local only [22:19:07] The whole plan seems to be cloudy in my mind, but I'm not sure why [22:23:03] who knows about wikilove customization? rkaldari, right? [22:23:25] He should have a decent idea, yeah [22:23:30] kaldari: ^^ [22:24:14] kaldari: https://www.mediawiki.org/w/index.php?title=Project:Support_desk&offset=20130102171421 [22:24:30] top thread is someone asking for help on customization [22:25:06] I'll point him to the documentation [22:25:27] k, I'll follow up if I can help any more :) [22:25:28] tyvm [23:36:05] Reedy: to begin with, it would be nice if we could do it on a test cluster [23:36:11] changing the paths, that is [23:36:17] even anomie's changes were full of bugs, due to lack of testing [23:36:21] once it is working, we can put the new code on tin and push it out to the new location on the apaches [23:36:24] then set up the symlink farm and do the switch [23:36:27] fenari can die a horrible firy death [23:40:40] or an honorable one