[00:02:25] bearND: hmm, we'll need to work it out with Yuvi and/or the Labs guys to get any dependent libraries installed... [00:05:11] dbrant: indeed [00:05:30] there's always something... [00:05:49] :) [06:40:53] 3Wikimedia Labs / 3Infrastructure: Database upgrade MariaDB 10: Metadata access in INFORMATION_SCHEMA causes complete blocks - 10https://bugzilla.wikimedia.org/69182#c5 (10Sean Pringle) As an interim measure the MariaDB 10 labsdb instances now have "information_schema_p": +--------------------------------+... [07:37:23] 3Wikimedia Labs / 3Infrastructure: Database upgrade MariaDB 10: Metadata access in INFORMATION_SCHEMA causes complete blocks - 10https://bugzilla.wikimedia.org/69182#c6 (10metatron) Great, thanks for this interim solution. Daily update is ok (for me) as the tools-info tool did a 68000 sec caching anyway. Sti... [07:38:38] 3Wikimedia Labs / 3Infrastructure: Database upgrade MariaDB 10: Metadata access in INFORMATION_SCHEMA causes complete blocks - 10https://bugzilla.wikimedia.org/69182#c7 (10metatron) http://tools.wmflabs.org/tools-info/ [08:19:55] 3Wikimedia Labs / 3Infrastructure: Database is slow. Load times abnormally high at times. - 10https://bugzilla.wikimedia.org/69326 (10Cyberpower678) 3NEW p:3Unprio s:3normal a:3None The replicated database can't seem to decide whether to be slow or fast. It's starting to become mildly annoying to h... [08:21:23] 3Wikimedia Labs / 3Infrastructure: Database is slow. Load times abnormally high at times. - 10https://bugzilla.wikimedia.org/69326 (10Cyberpower678) p:5Unprio>3Normal [08:36:08] 3Wikimedia Labs / 3Infrastructure: Database is slow. Load times abnormally high at times. - 10https://bugzilla.wikimedia.org/69326#c1 (10Cyberpower678) And another: [executiontime] => Array ( [basic_stats] => Array ( [queries] => Array... [08:49:28] hmmp monkeys again [10:12:07] yuvipanda: in the garden room now! [11:01:31] valhallasw`mania: hey! I'm at the garden room now [11:29:02] yuvipanda: now I'm at the license talk :-P and then going to check the fcgi talk [11:29:48] valhallasw`mania: there's a fcgi talk? [11:29:57] fcci* [11:30:23] "FastCCI: Taming the Commons Category Tree" [11:32:21] ah [11:32:23] ll [11:32:24] ok [11:32:25] brb [11:35:34] Ohh. Misread the title then [11:36:15] valhallasw`mania: heh, you're not the only one [12:08:49] yuvipanda: now I'm upstairs again! :-P [13:00:48] * valhallasw`mania prods yuvipanda [13:24:45] petan: the rcstream is fixed! (well, tempfixed) [13:25:22] valhallasw`mania: :) [13:25:30] valhallasw`mania: are you gonna port flask-mwoauth to use mwoauth? :) [14:17:07] Does the puppet role role::lamp::labs disable sites in apache site-enabled? [14:19:59] and replace it with 00-dummy.conf? [14:22:04] Negative24: it makes puppet manage the contents of the directory, meaning it will delete any files it doesn't recognize. you can place files in sites-local/ [14:23:47] My problem right now is that /var is on a 1.9gb partition and that's where puppet (or the ubuntu deb) places apache's docroot. I edited the sites in site-available and enabled them with a2ensite but after a minute or so the sites in site-enabled get removed and replaced with 00-dummy.conf. [14:24:53] ori: We should change the puppet role to place the docroot in /srv/public_html or something like that. [14:25:35] Negative24: you can put the files that you put in site-enabled in sites-local [14:25:47] and they'll get loaded automatically, just as they would if they were in sites-enabled [14:25:51] and they won't get wiped by puppet [14:26:39] ori: Sounds good. I'll do that but isn't sites-local for other scripts that aren't apache? [14:26:53] nope [14:27:14] That's what it looks like in apache.conf [14:27:31] ? [14:36:50] ori: The line says # vim: syntax=apache ts=4 sw=4 sts=4 sr noet [14:37:23] hm? [14:37:31] that's a modeline [14:37:40] Include sites-local/* doesn't include an extension [14:37:52] http://vim.wikia.com/wiki/Modeline_magic [14:37:57] it doesn't need to [15:17:02] addshore: ALL THE CHANNELS [15:33:51] legoktm: :/ [15:33:57] ? [15:34:03] Config class :O [15:34:11] why we no use namespaces? [15:34:20] php already has a Config class [15:34:28] ouch [15:34:31] MWConfig? [15:34:32] :P [15:34:33] sucks to be php [16:22:08] 3Wikimedia Labs / 3deployment-prep (beta): Automate updating the puppet checkout - 10https://bugzilla.wikimedia.org/66683#c9 (10Bryan Davis) 5PATC>3RESO/FIX Thanks Filippo! [16:59:48] scfc_de: btw, there's an nda group in ldap now, so if you want graphite / icinga-prod access, you can ask for it! [17:01:45] yuvipanda: Nice! What's the request process? [17:02:23] scfc_de: ask mutante, mostly. he's handling all of it. I think your NDA must be signed and with legal, and then there's just an LDAP addition [17:03:53] yuvipanda: Okay, will do later. [17:03:58] scfc_de: \o/ cool [17:04:07] scfc_de: I'm also getting to start on labmon work sooooon :) [17:09:46] andrewbogott_afk: hmm, I can't log in to diamond-collector.eqiad.wmflabs, while I *can* into graphite-trusty.eqiad.wmflabs (same project). what gives? [17:10:09] yuvipanda: You mean I get proper alarms of impending doom soon? :-) [17:10:25] scfc_de: well, graphite doesn't alarm you :) that'd be icinga, and that's not scheduled atm [17:10:59] scfc_de: and graphite is also not an 'official ops project', it's still my 'volunteer time' :) [17:12:10] Well, it's a start :-). [17:12:22] scfc_de: graphite.wmflabs.org is dead, btw [17:35:21] hi there ! looks like there's a problem with urllib with python, have you made any change recently or is any issue known ? [17:35:35] I get "/usr/lib/python2.7/urllib.py:1268: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal" [17:35:57] urllib.quote(u'testé') for instance returns this error [17:39:47] mhh, actually maybe my problem is more related with pywikipedia than with python itself, I get the same error on my own computer… [17:45:06] Coren_WM2014: around? [18:36:19] !log integration rebasing puppet repo on integration-puppetmaster [18:36:21] Logged the message, Master [19:19:51] hi ! Is there a place where the crontabs are backuped ? Because I'm afraid I've just lost mine !! [19:26:38] Coren_WM2014: ^ ? [19:28:03] Toto_Azero: try ~/...DATA.crontab ? [19:29:49] liangent: not the latest crontab, but many thanks anyway, at least I could use this ! [19:33:49] Toto_Azero: yeah it's the version saved during migration [19:33:54] datacenter migration [19:36:03] liangent: actually I typed 'crontab l' forgetting the '-' and I'm afraid it made my crontab disapper :/ [19:48:15] Toto_Azero: No, there is no backup. If "crontab l" (without an existing file "l") removes the crontab, then that's a bug. Could you file a bug report under Wikimedia Labs>tools, please? [19:50:50] scfc_de: I confirm that "crontab l", while returning "Can't open l: No such file or directory at /usr/local/bin/crontab line 137.", removes the current crontab [19:51:04] scfc_de: where should I report it ? [19:52:09] on bugzilla ? [19:55:01] (yes this is it, I'm filling it) [19:58:10] 3Wikimedia Labs / 3tools: 'crontab l' (with no dash) removes current crontab - 10https://bugzilla.wikimedia.org/69355 (10Toto Azéro) 3NEW p:3Unprio s:3normal a:3Marc A. Pelletier Typing command "crontab l" instead of "crontab -l" (without an existing file "l") removes the current crontab. [20:12:27] Toto_Azero: Yes, thanks. [22:08:07] andrewbogott_afk: still afk?