[00:08:26] <icinga-wm>	 PROBLEM - Puppet freshness on cp1065 is CRITICAL: Last successful Puppet run was Fri 20 Dec 2013 09:08:06 PM UTC  
[00:14:15] <Nemo_bis>	 are visitors' display size/screen resolution headers logged somewhere on WMF cluster? http://tools.ietf.org/html/draft-mutz-http-attributes-00
[00:22:43] <jeremyb>	 Nemo_bis: i'm not aware of a UA that sends those
[00:23:03] <jeremyb>	 Nemo_bis: but it could be determined with JS and sent to EventLogging
[00:24:54] <Nemo_bis>	 does https://panopticlick.eff.org get them by explicitly asking?
[00:25:18] <jeremyb>	 surely
[00:26:16] <Nemo_bis>	 the headers look like this http://p.defau.lt/?4cDCZp27YPTJmGY7YDZE_w
[00:27:18] <jeremyb>	 erm?
[00:28:20] <Nemo_bis>	 the request headers when using panopticlick
[00:28:35] <Nemo_bis>	 (an excerpt, of course)
[00:28:56] <grrrit-wm>	 (03CR) 10Calak: [C: 031] Use local Wiki.png for Persian Wikipedia Logo [operations/mediawiki-config] - 10https://gerrit.wikimedia.org/r/102454 (owner: 10Ebrahim)
[00:29:43] <jeremyb>	 Nemo_bis: those aren't request headers
[00:30:38] <jeremyb>	 (POST parameters are in the body not headers...)
[00:31:03] <ori-l>	 the RFC Nemo links to describes a standard for UAs to encode this information, but that standard never graduated to being a full standard, and it never really took off
[00:31:30] <jeremyb>	 ori-l: right, i was describing what i saw in the wild when e.g. looking at what my browser sends or watching varnishtop
[00:31:46] <ori-l>	 but yes, you could log it using javascript + eventlogging
[00:31:46] <jeremyb>	 they are specified by JS, not automatically generated by some function of the browser
[00:31:47] <Nemo_bis>	 jeremyb: yes sorry, I switched from one thing to the other without saying
[00:31:54] <ori-l>	 mw.eventLog.logEvent( 'UserResolution', { width: screen.availWidth, height: screen.availHeight } );
[00:32:07] <ori-l>	 (provided a UserResolution schema existed and had those properties specified)
[00:32:19] <jeremyb>	 ori-l: does that batch all the logEvent calls into one req?
[00:32:32] <ori-l>	 no
[00:33:23] <ori-l>	 jeremyb: logging calls are either specific to an infrequently-accessed page or feature, or they're sampled client-side
[00:33:37] <jeremyb>	 huh
[00:33:56] <jeremyb>	 might that chnage?
[00:34:00] <ori-l>	 if ( Math.floor( Math.random() * 1000 ) === 0 ) { /* log an event */ }
[00:34:08] <jeremyb>	 are we actively doing our version of boomerang?
[00:34:09] <ori-l>	 I think it will change for performance metrics
[00:34:19] <ori-l>	 yes, except our version is better :)
[00:34:28] <ori-l>	 not that I'm biased, but you know.
[00:34:36] <jeremyb>	 how? how about we upstream our betterness?
[00:35:06] <jeremyb>	 was typing: i'm thinking if we really want viewport info then it can be combined with timing data (boomerang). although, idk so much about how e.g. schemas work
[00:35:08] <ori-l>	 because the logging of performance measurements is one application of EventLogging, which is a generic facility for logging data
[00:35:21] <jeremyb>	 does the API allow batching unrelated schemas?
[00:35:54] <jeremyb>	 i don't follow? you mean it's better than boomerang because it's more generic?
[00:35:55] <ori-l>	 you could add those properties to the NavigationTiming schema. but unrelated events logged from different parts of the code are not batched at the moment, no
[00:36:26] <jeremyb>	 i was thinking if you explcitly asked for them to be batched does the client or server side support batching
[00:36:27] <ori-l>	 but it's rare for multiple events to be logged from the same page, since events tend to be specific to a particular context, or randomly sampled
[00:36:51] <ori-l>	 it depends on what you mean by "batched", really
[00:37:09] <ori-l>	 if you mean building up a buffer of logged events and only dispatching it when it reaches a certain size threshold, then no
[00:37:19] <jeremyb>	 or time threshold
[00:37:34] <jeremyb>	 or as i said, if the client explicitly requested batching
[00:37:34] <ori-l>	 we thought about doing that, but it makes timestamping events trickier
[00:37:44] <jeremyb>	 i mean combine 2 schemas into one HTTP request and split them out serverside
[00:38:00] <ori-l>	 if you log events as they come, you can use the server's timestamp; the skew introduced by latency is not important
[00:38:15] <ori-l>	 if you batch events you have to timestamp them on the client and must trust that
[00:38:54] <jeremyb>	 you could use a delta rather than just an absolute timestamp. but you could also use a threshold for when to trigger sending the batch that's small. e.g. 1sec
[00:39:03] <Nemo_bis>	 it wouldn't be bad to produce some stats on display sizes as a one-time thing, byproduct of some other logging (bucketing should be easy, there are not that many sizes possible)
[00:39:08] <jeremyb>	 re batching: i mean combine 2 schemas into one HTTP request and split them out serverside
[00:39:21] <Nemo_bis>	 * of some other experiment
[00:39:28] <jeremyb>	 Nemo_bis: really? not everyone runs maximized...
[00:39:33] <ori-l>	 debouncing events isn't necessary when there is only one (or none) on a given page?
[00:39:47] <ori-l>	 jeremyb: you can get the viewport dimension, too
[00:39:48] <Nemo_bis>	 jeremyb: ?
[00:40:02] <jeremyb>	 ori-l: i was referring to "there are not that many sizes possible"
[00:40:17] <Nemo_bis>	 for the screen
[00:40:22] <ori-l>	 i'm confused
[00:40:30] <ori-l>	 what are you asking?
[00:40:42] <Nemo_bis>	 he's saying that one can resize the window at wish
[00:40:48] <jeremyb>	 ori-l: Nemo_bis says: > bucketing should be easy, there are not that many sizes possible
[00:40:51] <Nemo_bis>	 so there are millions possible sizes
[00:40:57] <jeremyb>	 ori-l: i say > not everyone runs maximized
[00:41:22] <ori-l>	 OK
[00:41:37] <jeremyb>	 although, granted, few people will have a dimension > 5000px :P
[00:41:46] <ori-l>	 anyways, you can log this data easily, but it's good to have a concrete hypothesis / question in mind
[00:42:16] <jeremyb>	 i do think it would be useful to have stats on size periodically
[00:42:17] <ori-l>	 elegantly-captured, optimally-transmitted, beautifully-structured log data is worse than useless if no one is looking at it
[00:42:28] <jeremyb>	 hah
[00:42:41] <Nemo_bis>	 Question: can we calmly develop features which are unusable in 1024x768px screens?
[00:42:55] <jeremyb>	 calmly?
[00:42:58] <ori-l>	 Nemo_bis: like what?
[00:43:15] <ori-l>	 jeremyb: i.e., would the % of users affected be so low so as to make that justified
[00:43:19] <Nemo_bis>	 mention the sin, not the sinner
[00:44:26] <Nemo_bis>	 currently we use stats like http://www.w3schools.com/browsers/browsers_display.asp which are horribly biased
[00:44:27] <ori-l>	 I honestly don't know who / what you have in mind, but feel free to mention that it is eminently possible to capture this data, and make the case for logging it and analyzing it, if you think it is needed
[00:44:37] <jeremyb>	 ori-l: re better than boomerang: i don't follow? you mean it's better than boomerang because it's more generic? isn't boomerang just about generating the stats and you have to figure out your own way to log it, etc.?
[00:45:02] <jeremyb>	 Nemo_bis: please don't ever visit or link to that domain again! kthx!! :-(
[00:45:23] <Nemo_bis>	 jeremyb: why?
[00:45:44] <jeremyb>	 i almost forgot this site exists...
[00:45:46] <jeremyb>	 http://www.w3fools.com/
[00:45:51] <ori-l>	 jeremyb: it's more generic, yes
[00:46:05] <Nikerabbit>	 Nemo_bis: just don't
[00:46:27] <Nikerabbit>	 I hate it when I have to always add -w3schools to google search
[00:46:49] <jeremyb>	 looks like Nikerabbit's on board!
[00:47:12] <jeremyb>	 ori-l: are you sure that's not orthoganol? see the last part of what i just said? (after "generic?")
[00:47:15] <Nemo_bis>	 Nikerabbit: weren't you sleeping
[00:47:22] * Nemo_bis  needs to hide better

[00:47:36] <Nemo_bis>	 anyway, I linked it only to say that it's bad, so
[00:48:08] <ori-l>	 jeremyb: I was mostly just being obnoxious and facetiously congratulating myself.
[00:48:22] <jeremyb>	 ori-l: ok :)
[00:48:31] <jeremyb>	 ori-l: yasher koach (sp?)
[00:49:31] <ori-l>	 paamayim nekudotayim
[00:50:26] <jeremyb>	 i detect water...
[00:50:32] * jeremyb  gets out a dictionary

[00:51:34] <ori-l>	 Nemo_bis: are you sure the sinner you have in mind will be persuaded by data?
[00:51:39] <ori-l>	 if not, that's another reason not to log
[00:52:41] <jeremyb>	 oh, right, zend is in TLV...
[00:52:46] <Nemo_bis>	 right; better not to
[01:00:19] * Nemo_bis  is waiting for http://gs.statcounter.com/#resolution-ww-monthly-200903-201312 to load <-- this should be a non-fool if not non-evil link, but I don't swear!

[01:03:26] <Nemo_bis>	 very curious http://gs.statcounter.com/#resolution-ww-monthly-201309-201311-map (requires flash; and getting very OT even)
[01:04:15] <ori-l>	 Nemo_bis: this reminds me...
[01:04:39] <ori-l>	 httparchive.org provides really useful stats, but for some stupid reason they exclude non-www / empty subdomains from their automatic crawl list
[01:05:05] <ori-l>	 so i had to add en, commons, meta by hand (they allow you to submit urls)
[01:05:19] <ori-l>	 i added a few, what you'd expect from a chauvinist english-speaking jerk like me
[01:05:41] <Nemo_bis>	 ori-l: they did some stupid deduplication with weird sideeffects, it's all tracked in their project iirc
[01:05:47] <ori-l>	 i've been meaning to just systematically add all projects
[01:05:54] <ori-l>	 ah
[01:06:14] <ori-l>	 tracked meaning all projects are now tracked, or tracked meaning they're aware of the bug?
[01:06:48] <Nemo_bis>	 the latter
[01:07:13] <Nemo_bis>	 but you may want to check better, I only really tested translatewiki.net and a couple projects
[01:09:03] <Nemo_bis>	 I wonder if they extract data from archive.org warc files too
[01:31:56] <jeremyb>	 wtf. $ git grep -in stats wikimedia.conf
[01:31:56] <jeremyb>	 wikimedia.conf:54:    # Stats
[01:31:56] <jeremyb>	 wikimedia.conf:55:    RewriteRule ^/stats(/(.*$)|$) http://wikimedia.org/stats/%{HTTP_HOST}/$1 [R=301,L]
[01:32:13] <jeremyb>	 when was the last time that worked?
[01:38:51] <Nemo_bis>	 funny, that's for the URLs how they looked around 2005 right?
[01:44:26] <icinga-wm>	 PROBLEM - Puppet freshness on analytics1022 is CRITICAL: Last successful Puppet run was Wed 18 Dec 2013 10:29:11 PM UTC  
[01:44:26] <icinga-wm>	 PROBLEM - Puppet freshness on analytics1021 is CRITICAL: Last successful Puppet run was Wed 18 Dec 2013 10:28:53 PM UTC  
[02:01:04] <grrrit-wm>	 (03PS1) 10Aaron Schulz: [WIP] Make scap transport CDB files via JSON [operations/puppet] - 10https://gerrit.wikimedia.org/r/103080 
[02:09:34] <logmsgbot>	 !log LocalisationUpdate completed (1.23wmf7) at Sat Dec 21 02:09:34 UTC 2013
[02:09:52] <morebots>	 Logged the message, Master
[02:18:39] <logmsgbot>	 !log LocalisationUpdate completed (1.23wmf8) at Sat Dec 21 02:18:39 UTC 2013
[02:18:56] <morebots>	 Logged the message, Master
[02:33:00] <logmsgbot>	 !log LocalisationUpdate ResourceLoader cache refresh completed at Sat Dec 21 02:33:00 UTC 2013
[02:33:16] <morebots>	 Logged the message, Master
[02:49:09] <icinga-wm>	 ACKNOWLEDGEMENT - Varnish HTTP text-frontend on cp1065 is CRITICAL: Connection refused daniel_zahn RT 6538
[03:02:48] <icinga-wm>	 ACKNOWLEDGEMENT - RAID on virt5 is CRITICAL: CRITICAL: Active: 14, Working: 14, Failed: 1, Spare: 0 daniel_zahn RT 6541
[03:03:21] <icinga-wm>	 ACKNOWLEDGEMENT - Disk space on virt11 is CRITICAL: DISK CRITICAL - free space: /var/lib/nova/instances 31908 MB (2% inode=99%): daniel_zahn RT 6540
[03:09:26] <icinga-wm>	 PROBLEM - Puppet freshness on cp1065 is CRITICAL: Last successful Puppet run was Fri 20 Dec 2013 09:08:06 PM UTC  
[03:21:49] <grrrit-wm>	 (03Abandoned) 10Dzahn: redirect vikipedi[a].com.tr to tr.wikipedia.org [operations/apache-config] - 10https://gerrit.wikimedia.org/r/88705 (owner: 10Dzahn)
[03:25:02] <jeremyb>	 mutante: going to ACK the puppet fail too? :)
[03:25:15] <grrrit-wm>	 (03CR) 10Dzahn: [C: 031] "intention looks good, but haven't used the new system yet either. though, if the new amazing Jenkins checks like it, that's a good sign (s" [operations/apache-config] - 10https://gerrit.wikimedia.org/r/102753 (owner: 10Jeremyb)
[03:25:51] <jeremyb>	 hah, amazing
[03:26:31] <jeremyb>	 mutante: is there somewhere set up to test redirects in labs?
[03:30:53] <jeremyb>	 looking at apache conf i see search.wikimedia.org
[03:31:12] <jeremyb>	 manybubbles|away: do you plan to continue supporting search.wikimedia.org ?
[03:31:31] <jeremyb>	 iirc it's related to apple dictionary or something
[03:36:10] <jeremyb>	 i guess it uses mediawiki api and so it should just work?
[03:36:19] <jeremyb>	 i wonder if it needs to move to eqiad (or did already)
[03:38:05] <jeremyb>	 looks like wikitech's out of date and it's just served on cluster instead of from yongle
[03:38:12] <jeremyb>	 http://search.wikimedia.org/?site=wikipedia&lang=en&search=foo
[03:38:13] <jeremyb>	 https://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/apple-dictionary/index.php?revision=28980&view=markup
[03:38:21] <jeremyb>	 https://wikitech.wikimedia.org/wiki/search.wikimedia.org
[04:45:26] <icinga-wm>	 PROBLEM - Puppet freshness on analytics1021 is CRITICAL: Last successful Puppet run was Wed 18 Dec 2013 10:28:53 PM UTC  
[04:45:26] <icinga-wm>	 PROBLEM - Puppet freshness on analytics1022 is CRITICAL: Last successful Puppet run was Wed 18 Dec 2013 10:29:11 PM UTC  
[04:45:46] <icinga-wm>	 PROBLEM - MySQL Recent Restart on db1047 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds.  
[04:45:56] <icinga-wm>	 PROBLEM - MySQL Slave Running on db1047 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds.  
[04:46:46] <icinga-wm>	 RECOVERY - MySQL Recent Restart on db1047 is OK: OK 6268975 seconds since restart  
[04:46:46] <icinga-wm>	 RECOVERY - MySQL Slave Running on db1047 is OK: OK replication Slave_IO_Running: Yes Slave_SQL_Running: Yes Last_Error:  
[04:50:46] <icinga-wm>	 PROBLEM - MySQL Recent Restart on db1047 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds.  
[04:50:56] <icinga-wm>	 PROBLEM - MySQL Slave Running on db1047 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds.  
[04:51:36] <icinga-wm>	 RECOVERY - MySQL Recent Restart on db1047 is OK: OK 6269275 seconds since restart  
[04:52:46] <icinga-wm>	 RECOVERY - MySQL Slave Running on db1047 is OK: OK replication Slave_IO_Running: Yes Slave_SQL_Running: Yes Last_Error:  
[04:53:54] <Bsadowski1>	 jeremyb: Did someone change the CU data retention time?
[04:54:12] <Bsadowski1>	 apergos ^ Reedy ^
[04:57:50] <p858snake|l>	 Tim-away did last year I think
[04:58:17] <p858snake|l>	 well he fixed the scripts so they actually worked or something
[05:19:41] <jeremyb>	 Bsadowski1: erm?
[05:20:24] <Bsadowski1>	 How long is it now?
[05:20:26] <jeremyb>	 presumably there's a different retention period for logs of CU checks vs. retention of all actions ever made
[05:23:27] <Bsadowski1>	 Is this accurate?: http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/CheckUser/CheckUser.php?view=markup#l51
[05:23:36] <Bsadowski1>	 Or is it different now?
[05:24:04] <Bsadowski1>	 The action that I saw was in July 2013, jeremyb
[05:35:09] <jeremyb>	 Bsadowski1: uhhhh
[05:35:29] <jeremyb>	 Bsadowski1: we don't use svn anymore. not even for pywikipediabot
[05:38:03] <grrrit-wm>	 (03PS2) 10Jforrester: Enable VisualEditor by default on "phase 4" Wikipedias [operations/mediawiki-config] - 10https://gerrit.wikimedia.org/r/102208 
[05:38:39] <James_F>	 jeremyb: Is there a plan to decom svn?
[05:39:20] <jeremyb>	 James_F: there was discussion of what to do for the move to eqiad. and now it's on one of the gerrit boxes. (moved)
[05:39:32] <jeremyb>	 James_F: presumably it will stay up (read only) for some time to come
[05:39:40] <jeremyb>	 or else why bother to move it
[05:39:50] <jeremyb>	 don't remember the discussion 100%
[05:39:53] <jeremyb>	 ask chad :)
[05:40:09] <James_F>	 jeremyb: It's just going to lead to people being confused. :-(
[05:40:28] <jeremyb>	 James_F: i was just looking into adding a big scary banner at the top...
[05:40:59] * James_F  nods.

[05:41:49] <jeremyb>	 i wonder when i can get a review for https://gerrit.wikimedia.org/r/94111 ? :P
[05:44:26] <James_F>	 jeremyb: Not my repo, sorry. :-)
[05:44:36] <jeremyb>	 James_F: i know...
[05:44:47] <jeremyb>	 James_F: what are you now anyway? VE and?
[05:46:02] <James_F>	 jeremyb: VE and VE-MW and VE-MW-WMF and OOjs and OOjs-UI and sort-of Parsoid and Beta Features and a few other bits and bobs.
[05:47:28] <jeremyb>	 pdfhack?
[05:47:42] <grrrit-wm>	 (03CR) 10Jforrester: [C: 04-1] "As I said, please don't merge this unexpectedly. :-)" [operations/mediawiki-config] - 10https://gerrit.wikimedia.org/r/102208 (owner: 10Jforrester)
[05:48:20] <James_F>	 jeremyb: Not really my thing, though I'm tangentially aware of it.
[05:48:38] <jeremyb>	 haha, DO NOT MERGE!!
[05:48:49] <James_F>	 Indeed.
[05:49:03] <James_F>	 Giving people the gift of VisualEditor unexpectedly might be a little disruptive.
[05:49:12] <jeremyb>	 you could even abandon it and resurrect later 
[05:49:32] <jeremyb>	 100 years of crosswords huh...
[05:52:22] <jeremyb>	 $ < wikiversions.dat awk '{print $2;}' | sort | uniq -c | sort -nr
[05:52:22] <jeremyb>	     875 php-1.23wmf7
[05:52:22] <jeremyb>	       4 php-1.23wmf8
[05:52:46] <jeremyb>	 so the 3 tests + mediawikiwiki are wmf8
[05:53:44] <jeremyb>	 gitblit needs better url routing!
[05:57:06] <icinga-wm>	 PROBLEM - RAID on searchidx1001 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds.  
[05:57:56] <icinga-wm>	 RECOVERY - RAID on searchidx1001 is OK: OK: optimal, 1 logical, 4 physical  
[06:02:52] <jeremyb>	 i guess with our branch cutting there's not a great way to track submodule changes over time
[06:04:03] <jeremyb>	 because submodules aren't in master
[06:04:44] <jeremyb>	 but i guess you can just look and see what the branch cutting conf is wrt what ref to pull. i guess some just take master and some are more conservative
[06:04:58] <jeremyb>	 if it's set to just take master then just look at the extensions master
[06:05:46] <jeremyb>	 Bsadowski1: https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FCheckUser.git
[06:08:43] * jeremyb  has left some WIP in a sandbox. some bugs in there too (broken redirects)

[06:08:56] <jeremyb>	 https://git.wikimedia.org/commitdiff/operations%2Fapache-config.git/95314a306a906995e281a89b2795c1954079e00d
[06:09:03] <jeremyb>	 good night
[06:09:09] <jeremyb>	 :)
[06:10:26] <icinga-wm>	 PROBLEM - Puppet freshness on cp1065 is CRITICAL: Last successful Puppet run was Fri 20 Dec 2013 09:08:06 PM UTC  
[07:46:26] <icinga-wm>	 PROBLEM - Puppet freshness on analytics1021 is CRITICAL: Last successful Puppet run was Wed 18 Dec 2013 10:28:53 PM UTC  
[07:46:26] <icinga-wm>	 PROBLEM - Puppet freshness on analytics1022 is CRITICAL: Last successful Puppet run was Wed 18 Dec 2013 10:29:11 PM UTC  
[09:11:26] <icinga-wm>	 PROBLEM - Puppet freshness on cp1065 is CRITICAL: Last successful Puppet run was Fri 20 Dec 2013 09:08:06 PM UTC  
[10:47:26] <icinga-wm>	 PROBLEM - Puppet freshness on analytics1021 is CRITICAL: Last successful Puppet run was Wed 18 Dec 2013 10:28:53 PM UTC  
[10:47:26] <icinga-wm>	 PROBLEM - Puppet freshness on analytics1022 is CRITICAL: Last successful Puppet run was Wed 18 Dec 2013 10:29:11 PM UTC  
[11:48:21] <grrrit-wm>	 (03PS1) 10Spage: Add integration/kss to deployment repo config [operations/puppet] - 10https://gerrit.wikimedia.org/r/103095 
[11:52:41] <grrrit-wm>	 (03CR) 10Spage: "Dumbly following hashar's instructions in bug 58620 :)" [operations/puppet] - 10https://gerrit.wikimedia.org/r/103095 (owner: 10Spage)
[12:12:26] <icinga-wm>	 PROBLEM - Puppet freshness on cp1065 is CRITICAL: Last successful Puppet run was Fri 20 Dec 2013 09:08:06 PM UTC  
[13:48:26] <icinga-wm>	 PROBLEM - Puppet freshness on analytics1021 is CRITICAL: Last successful Puppet run was Wed 18 Dec 2013 10:28:53 PM UTC  
[13:48:26] <icinga-wm>	 PROBLEM - Puppet freshness on analytics1022 is CRITICAL: Last successful Puppet run was Wed 18 Dec 2013 10:29:11 PM UTC  
[15:13:26] <icinga-wm>	 PROBLEM - Puppet freshness on cp1065 is CRITICAL: Last successful Puppet run was Fri 20 Dec 2013 09:08:06 PM UTC  
[15:35:46] <grrrit-wm>	 (03PS1) 10Andrew Bogott: Move lighttpd_config into mail.pp and rename. [operations/puppet] - 10https://gerrit.wikimedia.org/r/103104 
[16:31:50] <grrrit-wm>	 (03PS1) 10Yatinmaan: Added more resolutions to commons.ico [operations/mediawiki-config] - 10https://gerrit.wikimedia.org/r/103107 
[16:49:26] <icinga-wm>	 PROBLEM - Puppet freshness on analytics1021 is CRITICAL: Last successful Puppet run was Wed 18 Dec 2013 10:28:53 PM UTC  
[16:49:26] <icinga-wm>	 PROBLEM - Puppet freshness on analytics1022 is CRITICAL: Last successful Puppet run was Wed 18 Dec 2013 10:29:11 PM UTC  
[17:12:20] <grrrit-wm>	 (03CR) 10Qgil: [C: 04-1] "Your patch is wrong:" [operations/mediawiki-config] - 10https://gerrit.wikimedia.org/r/103107 (owner: 10Yatinmaan)
[17:15:46] <grrrit-wm>	 (03CR) 10Andrew Bogott: "Confirmed on Labs that this is a no-op." [operations/puppet] - 10https://gerrit.wikimedia.org/r/103104 (owner: 10Andrew Bogott)
[17:19:44] <grrrit-wm>	 (03CR) 10Odder: [C: 04-1] "I pulled your change to check the icon, and couldn't open it -- the file seems broken somehow, please improve." [operations/mediawiki-config] - 10https://gerrit.wikimedia.org/r/103107 (owner: 10Yatinmaan)
[17:43:42] <grrrit-wm>	 (03PS1) 10Faidon Liambotis: reprepro: import from elasticsearch/logstash apt [operations/puppet] - 10https://gerrit.wikimedia.org/r/103112 
[18:09:46] <mutante>	 jeremyb: not yet that i know, but we use http://git.wikimedia.org/blob/operations%2Fpuppet.git/5772d3726e576da11b3f1ed90f20c3ce3ddd08d5/files%2Fmisc%2Fscripts%2Fapache-fast-test
[18:14:26] <icinga-wm>	 PROBLEM - Puppet freshness on cp1065 is CRITICAL: Last successful Puppet run was Fri 20 Dec 2013 09:08:06 PM UTC  
[18:43:02] <manybubbles>	 jeremyb: I've never supported search.wikimedia.org before....  if it just uses apiopensearch like the regular prefix search on site then it should continue working and even benefit from any prefix search improvements that I make
[18:44:40] <Reedy>	 It's a hack!
[18:45:14] <mutante>	 https://wikitech.wikimedia.org/wiki/Search  vs..  https://wikitech.wikimedia.org/wiki/Search/New
[18:50:34] <grrrit-wm>	 (03CR) 10Manybubbles: "Sweet! I just wanted to confirm that we still have to take action to update our repository with new versions of their packages. I want t" (031 comment) [operations/puppet] - 10https://gerrit.wikimedia.org/r/103112 (owner: 10Faidon Liambotis)
[18:50:46] <grrrit-wm>	 (03PS1) 10Odder: Submit a new Apple Touch icon for MediaWiki.org [operations/mediawiki-config] - 10https://gerrit.wikimedia.org/r/103117 
[18:53:46] <grrrit-wm>	 (03CR) 10Nemo bis: [C: 031] "Nothing against sinning, but definitely better this way." [operations/mediawiki-config] - 10https://gerrit.wikimedia.org/r/103117 (owner: 10Odder)
[18:55:49] <grrrit-wm>	 (03CR) 10Bartosz Dziewoński: [C: 031] "I might have used stronger wording, but yes." [operations/mediawiki-config] - 10https://gerrit.wikimedia.org/r/103117 (owner: 10Odder)
[19:00:18] <grrrit-wm>	 (03PS1) 10Odder: Enable $wgImportSources for Hebrew Wikivoyage [operations/mediawiki-config] - 10https://gerrit.wikimedia.org/r/103118 
[19:09:46] <grrrit-wm>	 (03PS2) 10Aaron Schulz: [WIP] Make scap transport CDB files via JSON [operations/puppet] - 10https://gerrit.wikimedia.org/r/103080 
[19:29:02] <GEOFBOT>	 hello
[19:29:20] <GEOFBOT>	 is this the right channel for working on http://www.google-melange.com/gci/task/view/google/gci2013/5777530279690240
[19:33:59] <twkozlowski>	 GEOFBOT: #wikimedia-dev is better
[19:34:31] <GEOFBOT>	 twkozlowski: thank you
[19:50:26] <icinga-wm>	 PROBLEM - Puppet freshness on analytics1021 is CRITICAL: Last successful Puppet run was Wed 18 Dec 2013 10:28:53 PM UTC  
[19:50:26] <icinga-wm>	 PROBLEM - Puppet freshness on analytics1022 is CRITICAL: Last successful Puppet run was Wed 18 Dec 2013 10:29:11 PM UTC  
[20:11:03] <Ryan_Lane>	 AaronSchulz: that json patch looks interesting
[20:11:27] <Ryan_Lane>	 does that mean we can actually track the changes via git, rather than dealing with the cdbs?
[20:12:12] <Aaron|home>	 in theory you could checkin the json files and push them out with git
[20:12:40] <Ryan_Lane>	 maybe we could make this a submodule?
[20:13:13] <Ryan_Lane>	 then it would be relatively simple to deal with it (no dependency repos, etc)
[20:13:14] <Aaron|home>	 rebuilding json->cdb takes like 5 sec on my 4-core with cdb files twice the size of ours for 100 files \o/
[20:13:21] <Ryan_Lane>	 wow
[20:13:22] <Ryan_Lane>	 awesome
[20:13:23] <Aaron|home>	 possibly
[20:13:30] <Ryan_Lane>	 that definitely seems like it would solve some issues
[20:13:40] <Aaron|home>	 I assume that this json rdiffs well (at least as best as anything)
[20:13:58] <Aaron|home>	 it's just {key:value, key:value, ..., key:value}
[20:14:17] <Ryan_Lane>	 it'll likely diff well and almost definitely compress well
[20:14:23] <Aaron|home>	 making the json files is about the same, so that's a tiny bit of extra time for tin
[20:14:38] <Ryan_Lane>	 that's not a huge deal, though
[20:14:59] <Ryan_Lane>	 hm. I need to add hook support to trebuchet trigger
[20:15:06] <Ryan_Lane>	 so that we could have this as a sync hook
[20:15:40] <Ryan_Lane>	 for now we could just add this directly to the hook script
[20:17:15] <Ryan_Lane>	 anyway, this looks like an awesome change :)
[20:17:35] <Aaron|home>	 also thinking about killing the syntax check (except maybe for wmf-config)
[20:17:44] <Aaron|home>	 I mean isn't that what jenkins is for?
[20:17:50] <Aaron|home>	 it made more sense back in the day
[20:18:16] <Ryan_Lane>	 well, kind of
[20:18:17] <Aaron|home>	 unless people are hacking on tin directly, it just wastes time
[20:18:20] <Ryan_Lane>	 what about local commits?
[20:18:29] <Ryan_Lane>	 security and such
[20:18:37] <Ryan_Lane>	 oh, except for wmf-config
[20:18:42] <Ryan_Lane>	 yeah, that makes sense
[20:18:54] <Aaron|home>	 I mean if it wasn't so slow I wouldn't care
[20:18:55] <Ryan_Lane>	 if someone pushes in a bad syntax change for a security fix they should be slapped
[20:19:05] <Aaron|home>	 right
[20:33:28] <matanya>	 Ryan_Lane: do you still so git reiews, or had enough? 
[20:33:34] <matanya>	 *do
[20:33:45] <Ryan_Lane>	 well, I will. I'm actually on vacation right now :)
[20:33:51] <Ryan_Lane>	 which one is it?
[20:34:00] <Ryan_Lane>	 my gf is doing some work, so I am too
[20:35:05] <matanya>	 Ryan_Lane: https://gerrit.wikimedia.org/r/#/c/102629/
[20:35:52] <Ryan_Lane>	 ah
[20:35:54] <Ryan_Lane>	 it's linting
[20:36:05] <matanya>	 yes, it is :)
[20:36:09] <Ryan_Lane>	 I also don't want to do this right before the holidays :D
[20:36:40] <Ryan_Lane>	 I'll take a look at it afterwards, though
[20:36:54] <matanya>	 no need to merge, just some critic :)
[20:38:16] <Ryan_Lane>	 why break things into individual directives?
[20:38:25] <Ryan_Lane>	 is there some style guide that says not to do it?
[20:43:50] <grrrit-wm>	 (03CR) 10Ryan Lane: [C: 04-1] "Would be nice to fix scoping deprecations while fixing style. Otherwise just a question." (032 comments) [operations/puppet] - 10https://gerrit.wikimedia.org/r/102629 (owner: 10Matanya)
[20:44:56] <matanya>	 Ryan_Lane: i find it more readable, and iirc there is some style guide some where about it
[20:45:02] <Ryan_Lane>	 ok
[20:45:09] <Ryan_Lane>	 I don't have any major qualms with it
[20:47:02] <matanya>	 good, i'll fix the scope thingy and hope that is all. Thanks a lot Ryan_Lane !
[20:54:16] <Ryan_Lane>	 yw
[21:02:14] <grrrit-wm>	 (03PS1) 10Sn1per: Fix en.wiktionary favicon for GCI 2013 [operations/mediawiki-config] - 10https://gerrit.wikimedia.org/r/103183 
[21:15:26] <icinga-wm>	 PROBLEM - Puppet freshness on cp1065 is CRITICAL: Last successful Puppet run was Fri 20 Dec 2013 09:08:06 PM UTC  
[21:19:51] <grrrit-wm>	 (03PS1) 10Ebrahim: Use local Wiki.png for Central Kurdish Wikipedia [operations/mediawiki-config] - 10https://gerrit.wikimedia.org/r/103184 
[21:51:51] <grrrit-wm>	 (03CR) 10Calak: [C: 031] Use local Wiki.png for Central Kurdish Wikipedia [operations/mediawiki-config] - 10https://gerrit.wikimedia.org/r/103184 (owner: 10Ebrahim)
[22:51:26] <icinga-wm>	 PROBLEM - Puppet freshness on analytics1021 is CRITICAL: Last successful Puppet run was Wed 18 Dec 2013 10:28:53 PM UTC  
[22:51:27] <icinga-wm>	 PROBLEM - Puppet freshness on analytics1022 is CRITICAL: Last successful Puppet run was Wed 18 Dec 2013 10:29:11 PM UTC