[00:18:38] what exactly is a freenode? [00:21:05] !log restarted diamond on all exec nodes to stop sending nfs stats [00:21:06] restarted is not a valid project. [00:21:09] !log tools restarted diamond on all exec nodes to stop sending nfs stats [00:21:11] Logged the message, Master [00:21:51] !log tools restarted diamond on almost all nodes to stop sending nfs stats, some still need to be flushed [00:21:55] Logged the message, Master [00:37:20] qwebirc651189: I dunno what "a" freenode is, but freenode is the name of the IRC network you are currently connected to. :-) [00:53:52] 3Tool Labs tools / 3[other]: [grrrit-wm] literal \n's in IRC messages - 10https://bugzilla.wikimedia.org/57688#c2 (10PiRSquared17) 5NEW>3RESO/WOR I've never seen this. [01:00:16] legoktm: you around? [01:00:25] stalker :P [01:00:25] sup [01:00:44] Just saw your post on VPT, thats a copyright issue [01:00:52] possibly. [01:01:04] No possibly about it [01:01:13] Ok. [01:01:20] Dispenser refused to release the code so it could be ported [01:03:02] There's a good argument to be made that as derived work from GPL then it is necessarily GPL itself. Honestly, I don't think it's worth the trouble. [01:06:29] legoktm take it down. I have a splitting headache and your not helping [01:09:39] I put those files up if somebody wanted to personally use it. You can keep it up if you password protect and give Reedy the password [01:22:14] so... my fcgi web app keeps dumping core while allocating memory every few hours; I've got it running using basically the same config as the first example here: https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/Help#Example_configurations - it's not memory-intensive so this is rather strange; any ideas? [01:22:33] Earwig: bump up memory to 4G anyway [01:22:37] and see if that helps [01:22:38] but how [01:22:47] Earwig: -mem 4G [01:22:49] Earwig: It might be slowly leaking. [01:22:50] to what [01:23:01] webservice doesn't take arguments like that, does it? [01:23:09] YuviPanda: fcgi dude. [01:23:15] Coren: aah, right. [01:23:18] so already at 4G [01:23:33] Earwig: Do you fork and exec from it? [01:23:35] no [01:23:59] Then you've almost certainly got a leak of some sort. You might want to check with qacct to see how much ram it peaked at. [01:24:25] hmm [01:27:10] DispenserAFK: I took it down. [01:27:34] Hope your headache gets better [01:30:24] thank you [01:39:44] Coren: sorry... uh... how am I supposed to interpret this info? did `qacct -o tools.copyvios -j`, looked at the most recent few entries, all have a 'maxvmem' hovering around 2.25G [01:40:39] Earwig: thats easily enough to OOM the webservice. [01:41:07] Indeed; because the 4G includes the actual webserver and its connections, and so on. [01:41:18] I think ~2GB by default of the 4 is allocated to overhead [01:44:11] when I look at http://tools.wmflabs.org/?status, they're all kinda around that level, so I don't really understand what you're saying... but, uh, okay, I will go leak hunting. [02:26:08] 3Tool Labs tools / 3[other]: Migrate https://toolserver.org/~magnus/wikishootme/index.html - 10https://bugzilla.wikimedia.org/61175#c1 (10This, that and the other) 5NEW>3RESO/FIX https://tools.wmflabs.org/wikishootme/ [06:45:27] join #wikimedia-de-intern [07:49:32] !log deployment-prep cxserver being configured! {{gerrit|140723}} by Kartik and Niklas \O/ [07:49:34] Logged the message, Master [08:39:06] 3Wikimedia Labs / 3deployment-prep (beta): Investigate broken puppet on Beta Cluster - 10https://bugzilla.wikimedia.org/67349#c4 (10Antoine "hashar" Musso) Well done! Having the issue reported is bug 67333 - Yell loudly of failed puppet runs on Beta Cluster instances Which depends on Bug 63296 - puppet la... [09:05:03] (03PS1) 10Alexandros Kosiaris: Resyncing passwords to production [labs/private] - 10https://gerrit.wikimedia.org/r/143580 [09:08:55] (03CR) 10Alexandros Kosiaris: [C: 032 V: 032] Resyncing passwords to production [labs/private] - 10https://gerrit.wikimedia.org/r/143580 (owner: 10Alexandros Kosiaris) [09:17:14] !log integration Upgrading Gerrit on integration-dev to http://quelltextlich.at/gerrit-2.8.1-4-ga1048ce.war . Would let me test Gerrit against the hash mismatch bug {{bug|53895}} [09:17:16] Logged the message, Master [09:26:06] !log integration upgraded Jenkins on integration-dev [09:26:08] Logged the message, Master [09:39:44] Wikitech Wikiadmins: https://wikitech.wikimedia.org/wiki/The_Creator_of_the_original_flappy_bird_game_is_thinking_about_returning_flappy_bird_to_the_app_store! spam [09:46:14] Revi: blanked meanwhile [09:51:30] (+some nonsense) [10:08:28] https://wikitech.wikimedia.org/wiki/McAusten too: out of scope, obviously [11:01:51] 3Tool Labs tools / 3Erwin's tools: Migrate https://toolserver.org/~erwin85/randomarticle.php to Tool Labs - 10https://bugzilla.wikimedia.org/60871#c8 (10merl) I am creating a replacement tools at http://tools.wmflabs.org/random Welcome site and instruction still missing but redirecting to a radom page of th... [11:15:06] 3Tool Labs tools / 3[other]: Migrate http://toolserver.org/~para/GeoCommons/* to Tool Labs - 10https://bugzilla.wikimedia.org/63304#c1 (10This, that and the other) 5NEW>3RESO/FIX Appears to have been migrated, with a redirect in place. [11:17:36] 3Tool Labs tools / 3[other]: Migrate http://toolserver.org/~para/cgi-bin/kmlexport to Tool Labs - 10https://bugzilla.wikimedia.org/61540#c4 (10This, that and the other) 5NEW>3RESO/FIX Now back up again. Closing this as fixed, as the tool has been migrated. Any future issues with the web service should b... [11:24:06] 3Tool Labs tools / 3Erwin's tools: Migrate https://toolserver.org/~erwin85/relatedchanges.php to Tool Labs - 10https://bugzilla.wikimedia.org/60872#c8 (10This, that and the other) 5ASSI>3RESO/FIX The tool has been migrated, so I'm closing this bug. Any further issues should be reported as separate bugs.... [11:26:06] 3Tool Labs tools / 3Erwin's tools: Migrate https://toolserver.org/~erwin85/subpages.php to Tool Labs - 10https://bugzilla.wikimedia.org/60876#c1 (10This, that and the other) 5NEW>3RESO/FIX The tool has been migrated, with a redirect in place, and appears to be functioning. http://tools.wmflabs.org/erwin... [11:30:07] 3Tool Labs tools / 3Erwin's tools: Migrate https://toolserver.org/~erwin85/projects.php to Tool Labs - 10https://bugzilla.wikimedia.org/60879#c1 (10This, that and the other) Hasn't this been superseded by [[Special:SiteMatrix]]? [11:31:36] 3Tool Labs tools / 3Erwin's tools: Migrate https://toolserver.org/~erwin85/newpages.php to Tool Labs - 10https://bugzilla.wikimedia.org/60875#c1 (10This, that and the other) 5NEW>3RESO/FIX Appears to be working on Labs, with a redirect in place. https://tools.wmflabs.org/erwin85/newpages.php [11:36:21] 3Tool Labs tools / 3Erwin's tools: Migrate https://toolserver.org/~erwin85/talkcatintersect.php to Tool Labs - 10https://bugzilla.wikimedia.org/60874#c1 (10This, that and the other) It says it is disabled for enwiki. Is this still needed on Labs? [11:37:21] 3Tool Labs tools / 3Erwin's tools: Migrate https://toolserver.org/~erwin85/shortpages.php to Tool Labs - 10https://bugzilla.wikimedia.org/60873#c1 (10This, that and the other) 5NEW>3RESO/FIX Now appears to be working on Labs, with a redirect in place. https://tools.wmflabs.org/erwin85/shortpages.php [11:47:51] 3Tool Labs tools / 3Erwin's tools: Migrate https://toolserver.org/~erwin85/randomarticle.php to Tool Labs - 10https://bugzilla.wikimedia.org/60871#c9 (10This, that and the other) It's been migrated [1], and appears to work. However, the "simple" version [2], linked from the introductory text of the normal v... [13:28:51] 3Wikimedia Labs / 3tools: Include imagescaler::packages in tool labs - 10https://bugzilla.wikimedia.org/66354#c2 (10Jarry1250) (In reply to Tim Landscheidt from comment #1) > We included the fonts packages for bug #58740 in exec nodes in February > (since then replaced by ::mediawiki::multimedia::fonts). Du... [13:29:28] * anomie notes that wm-bot seems to be missing [13:34:16] anomie: user181 is wm-bot [13:34:24] !ping [13:34:24] !pong [13:34:54] Revi: Then it should /nick, shouldn't it? [13:35:15] yes, but I don't know much about wm-bot [13:35:21] so you should ask petan [13:35:55] maybe browse code with repo in @help? ;p [13:36:02] I am running http://meta.wikimedia.org/wiki/WM-Bot version wikimedia bot v. 2.6.0.1 [libirc v. 1.0.0] my source code is licensed under GPL and located at https://github.com/benapetr/wikimedia-bot I will be very happy if you fix my bugs or implement new features [13:36:02] @help [13:44:01] Silke_WMDE: Comment for the Signpost on Labs migration/switchoff? Happy with how it's gone? Was big was the last-minute influx? [13:44:47] *How big was [13:49:09] Jarry1250: Oh, right, thanks for the reminder! I'll get back to you in a instant! [13:54:56] Jarry1250: If you have other questions Silke_WMDE can't help you with, just ping me. [13:58:50] Coren: wanna merge https://gerrit.wikimedia.org/r/#/c/143193/ [14:05:22] Coren: I can't answer that question about the number of last minute migrations. [14:07:06] 3Tool Labs tools / 3[other]: Migrate to Tool Labs: https://toolserver.org/~krinkle/MoreContributions/input.php - 10https://bugzilla.wikimedia.org/61036#c3 (10Krinkle) See bug 64499 for the request to implement wildcards in the GUC tool (which is the main feature my tool provided). [14:12:37] Hej Jarry1250, good to see you! We need urgently SVG Translate! :P (At best with the new SVG language switch feature) [14:13:37] Jarry1250: also the author Nikola of the other SVG tool is inactive now [14:15:36] Silke_WMDE: the short of it: we saw a roughly ~15% increase in the 3-4 days preceeding the toolserver shutdown; it's not possible to know /why/ someone joins labs of course but it's reasonable to presume much of that bump is attributable to last-minute migrations. [15:01:22] 3Wikimedia Labs / 3Infrastructure: puppet labsstatus not reported when using role::puppet::self - 10https://bugzilla.wikimedia.org/63296#c4 (10Bryan Davis) Getting reporting into wikitech working may be as easy as setting `report_server` in /etc/puppet/puppet.conf to point to the labs master server when ::pu... [15:32:51] bd808: puppet.conf report_server = virt1000 , that sounds too easy :-] [15:33:47] It does, but I think it actually might work. I was trying to figure out how to add that using our current puppet.conf management mechanisms. [15:34:08] I really want to make the puppet reports from beta go into logstash though too. [15:34:42] and query logstash to trigger alarms? [15:35:15] It could if we wanted to get an alarm for each failure [15:35:24] to test it out, maybe you can manually hack the puppet.conf on one of the instance and see what happens. Should turn green (ok) in wikitech interface [15:35:33] * bd808 nods [15:35:40] gotta train myself on logstash :/ [15:35:54] Except puppet will nuke the local change on the next run :( [15:36:19] /etc/puppet/puppet.conf is managed by puppet (so meta) [15:36:19] well that is good to confirm it works [15:36:29] then I guess you could use something like $override_puppet_master_reporter [15:36:35] like you did for salt master iirc [15:37:28] Yeah that might work. I'll poke at it a bit today [15:38:58] meanwhile I attended openstack infra meeting yesterday and quickly introduced my Zuul cloner of doom to clone multiple repos [15:39:01] they love the idea :-] [15:39:13] Nice. [15:39:29] we need the psr / monolog libs merged in vendor [15:39:40] that would be swell [15:39:47] I have yet to migrate the existing job to Zuul cloner though [15:43:03] Coren: Where's the whitelist/blacklist of DB tables to replicated to labs? [15:43:10] (03PS1) 10Giuseppe Lavagetto: add phabricator [labs/private] - 10https://gerrit.wikimedia.org/r/143621 [15:43:44] Reedy: operations/software; look for maintain-replicas.pl [15:44:11] Brilliant, thanks [15:44:59] (03CR) 10Giuseppe Lavagetto: [C: 032 V: 032] add phabricator [labs/private] - 10https://gerrit.wikimedia.org/r/143621 (owner: 10Giuseppe Lavagetto) [15:47:36] (03PS1) 10Giuseppe Lavagetto: Revert "add phabricator" [labs/private] - 10https://gerrit.wikimedia.org/r/143624 [15:47:45] (03CR) 10Giuseppe Lavagetto: [C: 032 V: 032] Revert "add phabricator" [labs/private] - 10https://gerrit.wikimedia.org/r/143624 (owner: 10Giuseppe Lavagetto) [15:48:47] Coren: just read the email you send over the week end regarding jenkins isolation :D [15:49:27] Coren: seems all my potential concerns are addressed beside having a direct access to the openstack api \O/ [15:50:15] hashar: Allowing access to the API is on our todo, but it'll take quite a bit. That said, most of what you might want to speak to openstack for you can do through wikitech. [15:51:36] 3Wikimedia Labs / 3Infrastructure: puppet labsstatus not reported when using role::puppet::self - 10https://bugzilla.wikimedia.org/63296#c5 (10Andrew Bogott) > Getting reporting into wikitech working may be as easy as setting > `report_server` in /etc/puppet/puppet.conf to point to the labs master server >... [15:51:55] Coren: I guess, would need to heavily adjust the OpenStack software that maintain a pool of instances. [15:52:21] Coren: I played a bit more with Docker and talked with Chris Steipp. Since docker lxc would need a lot of work compared to simply reusing labs / KVM [15:52:37] at the cost of adding more resources to the labs. But servers are cheap ™ [15:53:22] Well, it's certainly cheaper in complexity to just add more workers to our labs setup. [15:55:23] I guess I will send a few more direct emails tonight. Write a summary and have folks to sign off [15:56:36] not sure how much effort would be needed to allow access to the OpenStack API versus adjusting the pooling software [15:56:47] will write a bit this evening [16:07:06] 3Wikimedia Labs / 3Infrastructure: puppet labsstatus not reported when using role::puppet::self - 10https://bugzilla.wikimedia.org/63296#c6 (10Bryan Davis) (In reply to Andrew Bogott from comment #5) > > Getting reporting into wikitech working may be as easy as setting > > `report_server` in /etc/puppet/pupp... [16:50:36] Jarry1250: Where can I send you a few words to? [16:52:06] 3Wikimedia Labs / 3tools: User accounts should have a replica.my.cnf - 10https://bugzilla.wikimedia.org/57485#c3 (10Andre Klapper) Yuvi: Can you answer comment 1? [18:08:27] Hi, i noticed last night the Wikidata Game seemed broken, as in, i can still "play" it and make edits, but they dont actually become edits [18:08:36] nothing in my user contributions [18:08:45] even though i was logged in and did stuff [18:08:47] anything known? [18:22:14] mutante: I'm pretty sure Gerard would know better than most of us. [18:23:55] Coren: ok, thanks [18:30:04] YuviPanda, matanya, marktraceur, is the 'etherpad' in labs pretty much defunct? It has a public IP that points to an instance that seems to not be doing anything. [18:30:13] andrewbogott: yeah, defunct. [18:30:18] Yeah it should be fine to get rid of [18:30:19] andrewbogott: was migrated to prod [18:30:28] ok. And I should close https://bugzilla.wikimedia.org/show_bug.cgi?id=56887 as well, right? [18:30:32] yes andrewbogott, it is dead [18:30:32] as moot? [18:31:00] wow, unanimous! [18:31:57] KILL IT WITH FIRE AND rm -rf --no-preserve-root [18:32:21] 3Wikimedia Labs / 3(other): Set appropriate 404 status code for etherpad.wmflabs.org instead of 200 - 10https://bugzilla.wikimedia.org/56887#c1 (10Andrew Bogott) 5NEW>3RESO/INV etherpad.wmflabs.org is no longer used [18:33:05] Coren, were you already able to look at service group behavior on http://wikitech-test.wmflabs.org/wiki/Main_Page ? [18:33:24] Right now they display as . which I'm unsure about. [18:34:10] Hey YuviPanda, I think I've asked this before but I forget [18:34:12] andrewbogott: I deployed the patch on my local box instead; simpler. :-) And I don't how how /else/ you'd display them -- that's the actual username/groupname and is unambiguous. What's your concern? [18:34:17] is there a way to use labs web proxy with https? [18:34:28] https://hue-e.wmflabs.org/ [18:34:32] ottomata: the proxy serves as an https terminator. [18:34:34] ottomata: You get HTTPS for free, normally. [18:34:56] the http server i'm trying to connect to is doing https [18:34:58] ottomata: it's just there by default. you just need to listen on port 80 on your host. [18:35:02] So, typically you don't support https on your individual instance. If you want to test https on a specific instance (and have a cert &c ) then you probably need a public IP [18:35:04] ottomata: proxy does termination [18:35:15] naw, andrewbogott, i'm tesing this for production [18:35:19] hue has https built in [18:35:26] i'm not actually trying to use this in labs [18:35:27] just test [18:35:28] Coren: only that it's redundant since the groups are displayed in project context. But if you're happy then I'm happy. [18:35:29] ottomata: No way to use the proxy for that then. [18:35:44] k [18:35:45] thanks [18:36:09] andrewbogott: Honestly, I prefer a little explicit redundancy than having the group designated with a different label depending on which interface one uses. [18:36:27] We had enough issues with the local- confusion already. :-) [18:37:19] OK, I'm pretty sure that's right. The only confusion is that those servicegroups use the short name on the commandline, right? So people will now try $become tools.mysg and fail [18:37:23] unless $become is smart about that [18:41:21] Coren: If you want to log in to wikitech-test-frontend.eqiad.wmflabs, there's an ldap server there with a copy of prod ldap. [18:41:31] We can run that maintenance script and see what gets trashed :) [18:41:48] Is there a puppet problem with Ubuntu-14.04-trusty? I created a generic webserver-php5 several days ago and the site is now inaccessible. Project signwriting, instalce signwriting-icon-server-2 i-0000043c.eqiad.wmflabs state ACTIVE, puppet failed. IP 10.68.17.168 [18:42:19] andrewbogott: Ooo. Also Ascii Art! [18:42:29] Rainbow unicorn FTW! [18:42:33] slevinski: I'll have a look, remind me in 30 mins or so if I don't get back to you? [18:42:54] Coren: yeah, the web server on that is using vagrant. Hence, ascii unicorn :) [18:43:19] So, you should be able to use your normal auth to view ldap, just use -h localhost... [18:44:48] physikerwelt: do I recall correctly that you're an SMW maintainer? [18:45:55] 廌 [18:46:01] that is Unicode Han Character 'unicorn' (U+5ECC) [18:46:09] ascii is deprecated folks! [18:46:21] hashar: is it a unicorn or a kirin? Totally different! [18:46:26] * andrewbogott doesn't know if they're actually different [18:47:27] no clue either [18:48:02] hashar: hha :) [18:50:09] Coren: let me know when you're ready for me to run the purge on that test box [18:50:30] andrewbogott: Fire at will! [18:51:25] will: duck! [18:53:34] hm, "2005 items needed cleanup. 741 removed, 1264 failed." [18:53:38] that doesn't seem right! [18:54:04] ... why failed? That's downright odd. [18:54:25] dunno, looking [19:00:25] Coren: oh, looks like just a disk full [19:00:33] well, the log says disk full, even though the disk isn't. [19:00:35] ... d'oh. [19:00:41] Mebbe out of inodes? [19:00:52] Which filesystem is that? [19:04:55] just /var [19:06:46] I really don't see anything full there. [19:06:48] Hmmm. [19:07:03] I tried a second run, it deleted a bunch more and then started reporting fails again. [19:07:30] and, third time's the charm, now it's done. [19:07:44] That... isn't supposed to happen. [19:08:17] yeah. The script is wildely inefficient, I assume it's running out of some ldap resource that doesn't get garbage-collected fast enough to keep up. [19:09:31] "result=53 message="There is not enough space on the disk for the database to perform the write operation" etime=1" that's what it looks like in opendj when it fails [19:10:10] So… I'm not sure how much we care. I can put a nap in the purge script... [19:10:43] Meh. [19:11:13] From what I can see, it didn't go on a rampage and destroy LDAP. That counts. :-) [19:11:47] hashar, is it possible to have a different extension branch auto-pulled by betalabs? [19:12:00] no [19:12:08] we run everything from master :D [19:12:12] what is the use case? [19:13:18] yurikR2: ^^ [19:15:13] Coren, nap: https://gerrit.wikimedia.org/r/#/c/143676/ [19:15:28] I'll schedule this roll-out and purge for Monday right after I do the OpenStack upgrade. [19:16:01] Sleep every entry? Really? I doubt that'll help. [19:18:43] Ah, because you don't think that the problem was overloading ldap? [19:25:53] It's probably some sort of resource leak, but I doubt it was just speed that did it. [19:26:20] I think the sleep is just going to make it more painful to have to run it a couple times. :-P [19:27:06] 3Wikimedia Labs / 3(other): Set appropriate 404 status code for etherpad.wmflabs.org instead of 200 - 10https://bugzilla.wikimedia.org/56887#c2 (10Tim Landscheidt) Eh, some server *is* providing the message Nemo quoted :-). [19:27:10] the error messages I saw were in the opendj log, not in the php log. So it seems like the resource leak can't have been in the php script [19:27:19] hm [19:27:23] well, maybe [19:27:25] * andrewbogott rereads [19:29:06] 3Wikimedia Labs / 3(other): Set appropriate 404 status code for etherpad.wmflabs.org instead of 200 - 10https://bugzilla.wikimedia.org/56887 (10Andrew Bogott) 5RESO/INV>3REOP [19:29:07] 3Wikimedia Labs / 3(other): Set appropriate 404 status code for etherpad.wmflabs.org instead of 200 - 10https://bugzilla.wikimedia.org/56887#c3 (10Andrew Bogott) Oh, true. My temptation, though, is to resolve this by deleting the instance entirely... [19:29:20] hashar, might help with zero imho - i make tons of changes, self +2 it to go into a testing env, and later Adam okay's it by merging it into master... what do you think? [19:29:42] yurikR2: that you are using back practices? *grin* [19:30:02] s/back/bad/ [19:30:17] beta is mean as a staging area before code lands to prod. So it should be reasonably stable [19:30:24] we run browser tests against it for example [19:30:48] if you want to test, you might want to have a dev branch and have it deployed on a Zero testing instance in labs [19:30:56] hashar, you are right, but it would be good to have an "alppha" staging area :) [19:31:07] then you could push merge commits and have adam review the branch merge and the result land on beta :D [19:31:33] remember that for production we blindly cut the wmf branches out of master twice (i think) per week [19:31:48] so if you land unstable code, it might well end up on the prod cluster if the timing is unfortunate [19:31:48] Coren: in any case… you're happy with the state of ldap that resulted, right? [19:32:12] andrewbogott: I can see nothing wrong with it, and the code's logic is sound. [19:32:23] ok then :) [19:32:30] andrewbogott: I don't see how it could go all Kaiju on us and trample Tokyo. [19:32:52] yurikR2: so in short, master branches should have prod ready code. Experiments / alpha code should be harnessed behind a feature switch like $wgZeroPortalCrazyFeature = false ; [19:32:55] Coren: did you have some other wikitech issues for me? [19:33:20] yurikR2: and you can get your own playground instance on labs but out of beta cluster. The team doing Flow etc does that IIRC [19:33:45] andrewbogott: No, though we need to sit down a think overall redesign sometime soon since it's on our objectives plate. :-) You won't be in London, right? [19:34:15] nope [19:34:45] We'll figure something out then. [19:34:58] hashar, it would be fairly painful to set up multi-lang zero + m + zeroportal on a non-betalabs :( oh well, will manage somehow :) [19:35:19] yurikR2: yeah I agree :D [19:35:28] yurikR2: so you would have to land code that is a bit more robust ! [19:35:55] thx [19:35:58] yurikR2: beta is not meant for development, it is really for release / qa / pre production checks [19:36:10] yeah, i know. Just complaining :) [19:36:24] yurikR2: we had some discussion to create another cluster (maybe alpha cluster) that would be a bit more wide open and let folks cherry pick patches / dev branch on it [19:36:29] yurikR2: but did not happen so far. [19:36:46] yurikR2: maybe you can join the mediawiki/Vagrant effort and reproduce part of the setup in there? That is a neat dev env [19:37:44] hashar, i'm already using vagrant, the problem is more of a shared multi-host setup that betalabs emulates [19:38:04] slevinski: ok, this is a known bug -- there was a few-minute interval in which puppet and apache broke itself; you were unlucky enough to get a puppet run during that time. [19:38:15] slevinski: I fixed by doing 'sudo rmdir /etc/apache2/sites-local/' which caused puppet to regenerate things properly. [19:55:00] this patch to install xsltproc has had +1 in gerrit for a while, can someone bump it over the edge, its very simple. https://gerrit.wikimedia.org/r/#/c/141588/ [20:00:04] Coren: ^ [20:09:55] Coren: you aorund?| [20:10:17] Betacommand: What's up? [20:11:32] Coren: people are looking for a whois tool http://tools.wmflabs.org/betacommand-dev/SIL.html [20:12:42] there is a direct url http://tools.wmflabs.org/betacommand-dev/cgi-bin/SIL?ip= [20:14:27] What can I do? [20:15:11] Coren: throw a link to the discussions on the meta page [20:29:04] Sorry, what meta page? I haven't been following a discussion there. [20:37:46] Coren, I'm purging some old gluster scripts: manage-keys, manage-volumes-daemon, manage-exports. I see nfs replacements for the first two, but not for manage-exports. Is that because that was rolled into manage-nfs-volumes-daemon? [20:38:08] * Coren nods. [20:38:26] manage-nfs-volumes-daemon is the one that creates the exports files. [20:38:33] Looks like it was in charge of mounting /mnt/keys on the client. [20:38:37] I guess that's handled by puppet now [20:38:53] I wonder if it's still running and failing everywhere... [20:38:54] * andrewbogott looks [20:39:50] hm, seems not... [20:46:33] I don't see how it would; it was only added from some specific nodes in the site.pp that no longer exist. [23:06:36] hi, on toolserver, was commonswikimedia_p a databasealias for commonswiki_p? [23:08:14] don't know, but it would be nice to have aliases like that in labs [23:08:33] (and other related aliases that make more sense than the existing db names) [23:08:50] assuming we don't have them already of course [23:09:19] it seems the cause of a bug I am still experiencing [23:24:00] 3Tool Labs tools / 3Erwin's tools: Migrate https://toolserver.org/~erwin85/relatedchanges.php to Tool Labs - 10https://bugzilla.wikimedia.org/60872#c9 (10Andre Koopal) As it wasn't working on commons after migration, I still considered it not completely migrated. But I have find the cause and it is working n... [23:35:15] 3Tool Labs tools / 3Erwin's tools: Migrate https://toolserver.org/~erwin85/randomarticle.php to Tool Labs - 10https://bugzilla.wikimedia.org/60871#c10 (10Andre Koopal) Commons is working now as well. Had a quick look at 'simple', changed the database calls there as well, but that was not enough, need more i... [23:43:23] Dispenser, i get why u didn't transfer the 'links' to wmflabs, but why not the other tools? [23:44:37] dabsolver was actually a pretty useful, if not the only tool of its kind.. [23:44:37] It requires port the framework. If I am ultimately going to have to rent/build a server I'll have to port it again [23:45:48] And IIRC there were some copyright issues with switching to FLOSS [23:46:27] Didn't need to worry about licensing on TS [23:46:49] i never used ur 'links' tool anyways, a 'cheap' version made by legoktm worked wonders for me... [23:46:58] So I sometimes copied some really complicated code rather than rewrite [23:46:59] ah so dab is released freely? [23:48:27] Which tools are we talking about _exactly_ [23:49:19] just dabsolver and dablinks [23:49:55] dablinks, redlinks, dab_solver, backlinkscount, watcher, rdcheck, checklinks [23:53:19] Where's Russell Blau and JaGa they haven't opened up DPL data like on TS? [23:55:20] Ultimately the Visual Editor will include dab solver, question is how many years before that happens [23:56:03] not many sane minds uses virtual editor..