[02:06:21] Krenair: After sending it I realized my response to you about legalwiki may have sounded snarkier then I meant it, it was not meant to be snarky ;) [02:06:33] (on bug 61222 ) [02:07:32] Jamesofur, it's fine, doesn't sound particularly snarky and makes sense [02:07:42] I would say we're just bikeshedding on the name really... :p [02:07:43] cool cool [02:07:46] heh yup [02:07:54] time honored tradition ;) [02:08:03] Except these names tend to be sort-of-permanent. So it's good to do it well first time [02:08:27] I mean it can be renamed, but.. yeah [02:09:09] * Jamesofur nods [02:11:30] Jamesofur, I would ask whether you guys discuss stuff that is private even to employees (who might have sysadmin access and therefore be technically able to read the wiki anyway), but I guess since you're moving away from Google Docs... [02:18:11] Krenair: I brought that up with the lawyers, and in general we can consider it protected at that level because sysadmin staff etc have access in a 'support' role for the servers [02:18:43] which is protected by privilege (and we can fire them etc if they decide to outright break their non disclosure agreements for example) [02:19:15] Jamesofur, oh and there are the volunteer sysadmin/shell users as well [02:19:17] similar to how, in theory, they have access to the boardwiki but shouldn't use it (and I have no reason to think they have) [02:19:19] yup [02:19:30] but still protected under a legal agreement [02:19:40] (confidentiality agreement) [02:19:53] and, yeah, better on our servers then google docs [02:19:54] Yeah okay, so it's fine as long as those who can access signed an NDA on it [02:20:13] where they could subpoena someone else to get stuff which is exactly what we don't want [02:22:09] Jamesofur, I just wanted to make sure this won't cause issues with volunteer shells (or their creation) [02:26:28] * Jamesofur nods [02:26:31] certainly [02:28:00] I offered them the possibility of a much more private wiki (one on a box in the office being used for another internal tool where only myself and the OIT ops person is on) and they don't think it will be necessary. [02:28:20] Which is good, I strongly prefer wikis on the cluster which I don't have to be the one making sure stays up :) [04:56:07] * sDrewthedoff shakes the servers [05:03:23] * sDrewthedoff pings admins, having problems applying xwiki userrights from meta to allow access at idwikibooks [05:03:46] PHP fatal error in /usr/local/apache/common-local/php-1.23wmf13/includes/specials/SpecialUserrights.php line 155: [05:03:47] Call to undefined method UserRightsProxy::clearInstanceCache() [05:04:34] not been a problem previously [05:05:14] and smae when I try to change params for mediawikiwiki [05:06:37] and afwiki, so it seems to be related to meta, not the receiving end [05:07:24] Reedy: what time did wmf13 rollout? [05:18:34] greg-g: ping? [05:24:06] I also get one [05:24:08] PHP fatal error in /usr/local/apache/common-local/php-1.23wmf13/includes/specials/SpecialUserrights.php line 155: [05:24:08] Call to undefined method UserRightsProxy::clearInstanceCache() [05:24:15] D: [05:40:42] I'm looking for someone willing to scan a dump for me. Can someone, please? (Specifically, I'm looking for all en.wiktionary template: namespace pages that include, in the wikicode, the string "interProject" (no quotes).) [05:42:04] mmmmmm, external store [05:42:09] dumps are available on labs [05:42:22] you can get an account there :) [05:43:56] jeremyb: Dumps are available at http://dumps.wikimedia.org without an account, but I don't have a good way to parse XML. [05:44:34] msh210: maybe etree? [05:44:52] (i.e. python) [05:46:13] jeremyb: Yes, I'm sure python or perl can parse XML just fine, but I'm hoping not to start writing a whole script to do so when there are numerous people who already have such scripts and parse dumps all the time and can do this very easily. [05:47:08] writing a 5 or 10 line script from scratch may be faster than finding someone? [05:47:57] msh210: Did you try Special:Search? [05:48:08] Or does it not search wikitext? [05:48:29] Gloria: it didn't use to. I understand that's changing... had it already?? That'd be great. [05:48:51] Not sure. [05:49:00] Gloria: I'll check. Thanks! [05:49:26] jeremyb: I'd need to figure out what the entries look like, then how to regexify the start and end of an entry and that it's a template, etc etc etc. [05:49:59] msh210: huh? i didn't say use regex. i said etree [05:50:39] jeremyb: You said "etree (i.e. python)". I'd never heard of etree, so assumed you meant python. ("I.e." means "which is".) [05:50:45] msh210: Yeah, I think you'll need to scan a dump. [05:51:01] One day we'll have fast wikitext searching. [05:51:03] Gloria: Right, special:search doesn't work. Thanks, though. [05:51:03] One day... [05:51:12] https://bugzilla.wikimedia.org/show_bug.cgi?id=43652 [05:51:12] Gloria: yeah. [05:51:18] Related bug. ^^ [05:51:27] Probably before the end of the year. [05:52:06] Gloria: IIRC, mako can calculate diffs from every revision to every other revision of the same article on enwiki in ~4 hours [05:52:33] All right. [05:52:53] part of the secret sauce is not having to do a lot of malloc. he just uses a preallocated pool with slots big enough that they are bigger than the largest ever revision [05:54:07] (i think he has a machine with something crazy like 500+ GB of ram) [05:54:21] That's a lot. [05:54:29] yarly [05:56:37] jeremyb: okay, etree looks promising. Thanks! [06:03:07] jeremyb: what's up? [06:03:51] greg-g: i think maybe legoktm / TimStarling got to 61252 [06:04:02] greg-g: there was another change that maybe was related to a deploy [06:04:34] greg-g: 61249 [06:04:40] greg-g: see -operations [06:04:42] but unclear how big a deal that is [06:07:11] well now closed WORKSFORME. we'll see what happens [06:07:33] * jeremyb waves superm401 [06:14:47] jeremyb: legoktm thanks, watching, not much to do now that Tim's on it [06:18:25] greg-g: well, it's already confirmed fixed by the people that noticed it [06:18:28] :) [06:19:21] even better [06:19:23] :) [07:51:49] Nemo_bis: made a bug-report regarding the tab-error we spoke about some time ago [07:55:15] thanks [08:03:46] Nemo_bis: thanks for helping me verify [08:46:43] Isarra: LOL "this is by design" http://code.google.com/p/gerrit/issues/detail?id=2458 [08:48:56] Nemo_bis: heh, didn't know gerrit had a 'design' [08:49:09] nastypanda [08:49:29] I think they're trying to make one with the new change view. :) [08:49:46] Nemo_bis: o_O [08:49:59] A bad one? [08:50:07] What's the point at that point? [08:52:03] The general idea behind it doesn't seem so bad. Most of the issues are rather atomic and can be fixed without too much effort: http://etherpad.wikimedia.org/p/new-gerrit-change-view-comments [08:53:01] For the whole "buttons" problems I'm waiting for hashar to come up with wonderful CSS we can then submit upstream, but the rest should just be reported, they seem rather helpful. [08:55:43] Hopefully. [08:57:51] Nemo_bis: sorry I am not going to play with CSS :/ [08:58:17] but I am sure some random folk will be able to tweak them easily [08:59:20] oh so many scroll bars in the new view [09:00:18] yet I don't have to take the whole page horizontally... [09:01:58] hashar: never ever? you said you were gong to give it a try at some point in the next N years [09:02:32] anyway, s/hashar/whoever/ in my sentence above :) [09:03:50] Nemo_bis: N tending to infinite :-D [09:04:04] Nemo_bis: I can't remember how we apply our own stylesheet [09:04:14] + it needs a few !important, figuring out the css id [09:04:24] and make sure the new style works in both old and new screen [09:04:42] potentially that can be done using the Stylish browser extension wich let you change style locally [09:04:50] then finis out the .css in puppet repo and propose a change [09:04:59] or it can be upstreamed :-] [12:31:03] applying for wikimania support... everything very lucid, very nice, hit submit button... [12:31:05] "Invalid request [12:31:05] The request that was submitted was missing the request forgery protection token. Please return to the form, reload the page and try again." [12:31:47] am I going to lose all the typing and ticking off and drop down box content selection by reloading? [12:50:48] Sir_Designer_: also depends on the browser you use, hence hard to tell. Try? :P [12:51:10] before I do, I ma busy copying all the precious work to Note (mac). :) [12:51:17] NOtes * [12:59:05] it was a spectacular lossage. glad I copied and pasted to a safe place. [13:23:30] Thanks! [13:23:30] Thank you for submitting your scholarship application for Wikimania 2014. Please contact wikimania-scholarships@wikimedia.org with any questions. [13:23:34] :) [13:23:39] see you in London! [13:30:26] :O [15:26:52] apergos: Hydriz had not told me he had stopped archiving incremental dumps from Toolserver, so we lost a couple months from November to January. I now resumed his scripts from Labs. https://archive.org/search.php?query=incr%20collection%3Awikimediadownloads&sort=-publicdate [15:27:09] ok [16:11:44] Sir_Designer_: Do you have any guess about how long you had been working on the form before you hit submit when you got the missing request token error submitting for a Scholarship? We see that error in the logs several times per day and my only guess so far is that PHP has garbage collected the server side session due to inactivity while the user is working on their answers. [16:12:33] I haven't had any reports of people not being able to submit on retry so I haven't worked too hard to reproduce the problem. It is annoying though. [16:14:00] bd808 20 minutes with onr back as i hit return inadvertently and it chided me that i did not finish [16:14:28] gotta run. [16:14:34] Thanks for the data. That matches my guess about session garbage collection. [16:14:46] I'll open a bug for next year :) [17:24:27] MaxSem: do you have any idea why mobile users keep adding images to the page https://www.mediawiki.org/wiki/Tarballs ? [17:26:39] insufficient amounts of grey matter between ears? [17:27:23] MaxSem: true, but what's special about the tarball page :/ [17:28:28] hmm, the only prominent backlink is from Manual:Upgrading [17:29:00] Maybe it's a false friend in some language and users think they know what it is while they don't [20:13:09] http://lists.wikimedia.org/pipermail/mobile-l/2014-February/006506.html [20:13:42] yurik: if we could decide on killing the 32px icons somewhere else than on a not-so-popular mailing list... [20:13:56] there's a lot of bugs about favicons in Bugzilla [20:15:13] twkozlowski, do you have links to them? i will take a look [20:17:45] yurik: in a moment... [20:17:54] brion: https://bugzilla.wikimedia.org/show_bug.cgi?id=19392#c12 for your PNG wish :-( [20:18:40] yurik: is 15K a lot for a favicon? I don't know [20:18:55] we serve 6K apple touch icons which are bigger than favs, but those come in three layers each, so [20:19:50] twkozlowski, if the request is about 100K, 15K is somewhat high - we can serve a medium quality image in 15-20K [20:20:02] a much much bigger image [20:20:18] https://bugzilla.wikimedia.org/show_bug.cgi?id=45036 was the bug I had in mind [20:20:44] yurik: we just went through a complete rehaul of favicons thanks to GCI [20:20:57] all are in 16px, 32px and 64px now [20:21:07] if you can kill their size, that's awesome :) [20:21:25] twkozlowski, yes, but that icon has very few colors, and yet its stored as true color uncompressed image :) [20:21:46] there is a reason we use compression you know :) [20:21:55] that icon [20:22:04] we have 12+ different icons [20:22:14] and btw, 15K on slow connection in the 3rd world could be a few seconds :) [20:22:25] yurik: but if you download it only once... [20:22:52] twkozlowski, true, but if the first impression is delayed by extra few seconds... [20:23:00] its a very bad first impression :) [20:23:17] anyway: yes for killing the size, no for killing any of the layers [20:23:34] look at all the tricks google does just to make the traffic a few bytes less [20:23:51] twkozlowski, but why do we need the 32? [20:24:04] it's used by Windows, I think [20:24:12] are you sure? [20:24:25] yurik: I think it is used for the taskbar icon [20:24:34] [citation needed] :) [20:24:45] http://msdn.microsoft.com/en-us/library/ie/gg491740%28v=vs.85%29.aspx [20:24:49] cited [20:25:08] also they say retina display use 32px [20:25:13] displayz [20:25:22] Recommended16x16, 32x32, 48x48 [20:25:29] Optimal16x16, 24x24, 32x32, 64x64 [20:25:36] To achieve the best experience in Internet Explorer 9, your icons should support the following image sizes: [20:25:39] yay us [20:26:23] i linked to Internet Explorer Dev Center.. ugh dirty.. [20:26:41] and of course they have to be icos because of IE [20:26:58] but I guess some clever people can limit the size of icos as well as for pngs [20:27:03] !ie [20:27:03] sadness. [20:28:40] lol [20:28:54] i just saw this -- http://imgur.com/pu1gk3E in the topic of valentine :) [20:29:24] hehee [20:29:50] let's slowly load all the resolutions, it won't take long until some tablet uses 128x128 [20:30:28] our Apple Touch icons are already 150-something [20:31:01] favicon.svg ..grmbl [20:31:28] https://gerrit.wikimedia.org/r/#/c/103117/ for example [20:34:14] next: it comes as a sync from gigapan.com/gigapans to meet the demands of https://en.wikipedia.org/wiki/List_of_largest_video_screens [20:34:48] hopefully they'll first implement SVG favicons in their software :) [20:35:06] yea, that's what you'd think.. SVG to the rescue [20:35:10] oh noe [20:35:26] our favicons are blurred on the Phoenix Island Daktronics screen! [20:35:31] :) [20:35:36] technically we can place a much smaller image for firefox and chrome, and link to it from html (there is some meta tag i think) [20:35:53] but we need to make sure that the browser won't download the default one [21:26:15] manybubbles: almost no results with Cirrus https://en.wikipedia.org/wiki/Special:Search?search=Mc+Cullough [21:27:02] hmm Lucene Did you mean: Mccullough Clough [21:27:19] how hard can it be to make it understand one means McCullough ? [21:28:10] Nemo_bis: easy but there might be side effects [21:28:31] we already have a thing for it called "aggressive splitting" [21:28:40] which is really for splitting camelCase words [21:28:46] but names like that work too [21:29:00] right, the aggressive splitting [21:29:16] I've found it can be trouble [21:29:20] but it is helpful on mw.org [21:29:28] I wonder if i can get it working everywhere but optionally [21:29:30] .... [21:29:32] hmmm [21:46:36] manybubbles: is search on beta labs known to be busted right now? [21:46:48] shouldn't be busted, no [21:47:15] looks pretty busted [21:47:27] ^d, can you look at this while I continue juggling elasticsearch shards around? [21:48:01] manybubbles: it's been like that for a while. I can pinpoint the exact date if you need it [21:48:11] that'd be great [21:50:50] actually manybubbles I take that back, looks like it just started very recently, like today, a few hours ago. my mistake [21:50:54] <^d> manybubbles: In meeting, will look after. [21:51:00] ^d: thanks! [22:35:36] could somebody update channel topic for Status: Bugzilla in scheduled maintenance [22:35:40] or similar [22:35:59] it's the normal one that bad been announced per banner, but still got questions [22:36:25] mutante: There you go [22:36:32] thanks hoo [22:36:38] just remember to remove that once BZ is ok again [22:36:53] yes,it will be new version too [22:37:07] we are currently on it with the dba, importing data etc [22:40:13] mutante: Remember, the topic in this channel is open for anyone to change [22:40:27] you could do it :) [22:40:52] oh, it's -t ? alright [22:40:56] nvm then [23:36:28] Gloria: re bz component: I'm a notorious Title Case typer :/