[00:29:19] hi guys! is there any real issue with running a bot faster than 6epm during non peaks times especially if it check maxlag each edit? [00:29:53] *checks [00:29:54] no, it just depends on local wiki policy [00:30:07] there's no technical problem with it [00:30:12] okay :) [00:30:26] obviously if the wiki policy says "don't do more than 10 edits per minute", then don't [00:34:45] yep :) [02:53:17] Heh, off-hand IRC comments end up setting global bot policy. [02:53:48] I got asked the same question the other day. I said it depended on what kind of edits are being done. [02:54:09] 80 redirect edits in a minute is different from 80 edits to [[w:en:Barack Obama]]. [02:55:01] And there are certain null edits that cause way more strain than it appears to the user. [02:58:56] I did a few million edits in the span of a few days the other week on en.wiki. [02:59:05] Nobody seemed to notice or care. [03:11:18] gn8 folks [04:32:06] !log updating luasandbox to version 1.2, with profiler bug fixes [04:32:08] Logged the message, Master [09:20:19] Susan: null edits to test bugs, as you proposed some time ago on wikitech? [09:21:04] Somewhat. [09:21:08] I didn't just propose. [12:49:34] Wait, Patrick *and* Svetlana have left? :( [12:50:44] hm? [12:51:06] Svetlana left? was there an email I missed? [12:51:07] https://office.wikimedia.org/wiki/Special:Log/block [12:51:43] Wait, why is Brandon in there too [12:52:02] I know he uses Jorm (WMF) for work? [12:52:17] Ah [12:53:21] <^demon> You know what's funny, when office it gave me a username I'd never possibly use for my officewiki account :p [12:53:23] no, on the office wiki, he uses Jorm, but that series of blocks was for only 2 hours. Weird. [17:09:10] Like there weren't enough channels I was on. :-) [17:09:59] i have... 105 irc windows open atm [17:10:40] mark: Okay, so my situation isn't that bad. That said, I'm not sure I see yours as a desirable objective either. :-) [18:52:33] hmm can someone go to https://wikimediafoundation.org/wiki/Tax_Deductibility/en logged out for me please? [18:52:50] the mediawiki logo in the bottom right doesn't show for me, it's linked to https://bits.wikimedia.org/static-1.21wmf2/skins/common/images/poweredby_mediawiki_88x31.png [18:53:13] whereas if I do it logged in I get https://bits.wikimedia.org/static-1.21wmf9/skins/common/images/poweredby_mediawiki_88x31.png loading in the bottom right [18:54:04] but if I go https://wikimediafoundation.org/w/index.php?title=Tax_Deductibility/en&action=edit (logged in or logged out) it loads https://bits.wikimedia.org/static-1.21wmf9/skins/common/images/poweredby_mediawiki_88x31.png [18:55:12] hmm, purging cache with ?action=purge fixed it, but should that be necessary? [18:55:42] * Thehelpfulone pokes Krinkle as the most recent person in here ^ [18:59:03] Thehelpfulone: I know, and it's known, [18:59:10] Thehelpfulone: Fetching bug report now [18:59:46] Thehelpfulone: https://bugzilla.wikimedia.org/show_bug.cgi?id=44570 [18:59:51] Just purge the page and move on ;) [19:00:43] Reedy: Can't we just re-create them from 1.21wmf1 onwards for now? [19:00:48] Should be simple, right ? [19:00:53] yeah that would be the simple solution [19:01:30] Reedy: Then, as soon as we have a reliable max() value, we can start scheduling their removal, but don't remove any until we know that max() value. [19:02:15] Given that bits caches stuff regardless of the backend, getting a hit once should make it good for another 30 days. [19:02:39] And similarly, removing it too soon.. [19:05:44] "too soon" [19:06:52] Noting wmf3 was fully in production 7th November [19:07:01] we're now 3.5 months later [19:09:35] and moving to a 2 slot system doesn't fix the problem, it's only a workaround [19:15:34] sumanah, guillom: that block thing was a mistake. [19:15:44] got it [19:15:53] I figured it was either a mistake or a test [19:16:05] Reedy: how goes the deploy? [19:16:12] Not started [19:16:38] Reedy: blocked, or just haven't gotten to it? [19:16:46] Eating ;) [19:17:24] gotta be nourished to deply [19:17:28] +0 [19:17:33] er, wow, o [19:17:34] depl0y [19:17:40] w3rd [19:17:45] hi greg-g and folks [19:17:52] hi there aude [19:18:02] I can imagine the signpost breaking news "deployment blocked because of developers needing to eat" [19:18:09] bon appétit Reedy ! [19:18:10] * aude glad reedy has more help now [19:18:20] aude: More help? They're all just spectators ;) [19:18:30] * greg-g is eating popcorn [19:18:31] heh [19:18:38] * robla hovers menacingly [19:18:45] Krinkle: tbh, it mostly seems to be foundation wiki with this issue. We should just drop the parser cache time for foundationwiki. It's a small enough wiki [19:19:06] * ^demon hovers in a completely non-threatening way [19:19:28] Though, I'm still slightly confused as to what's been cached.. [19:19:29] Reedy: eh, I bet there's a million pages on other wikis that haven't been edited for a month either [19:19:30] # Purge entries older than 30d * 86400s/d = 2592000s [19:19:31] http://code.creativecommons.org/issues/issue1043 [19:19:37] They are likely less visible [19:19:41] Indeed [19:19:43] So no one complains [19:19:51] Squid cache is supposed to be around 30 days too [19:20:04] wmfwiki is probably the least edited high visible wiki, but I don't think that is a valid argument here to be honest. [19:20:13] It fixes the problem [19:20:15] It is cheap to keep those clones around, right? [19:20:21] It's clutter [19:20:25] No, it fixes (or evades) the problem on 1 wiki [19:20:32] => problem solved [19:20:34] Welcome to Wikimedia [19:20:37] And then parser cache is supposed to be purged every 30 days too [19:20:37] unless we evade it everywhere, it doesn't fix it. [19:21:04] Krinkle: Also, follows prescedent [19:21:04] 'wgSquidMaxage' => array( [19:21:04] 'default' => 2678400, // 31 days seems about right [19:21:04] 'foundationwiki' => 3600, // template links may be funky [19:21:05] ), [19:22:39] We need to confirm which cache is at fault first.. [19:22:49] Yep [19:22:51] Krinkle: Reedy: what is the problem you're debating? [19:23:02] Stale resources on wmfwiki [19:23:04] robla: https://bugzilla.wikimedia.org/show_bug.cgi?id=44570 [19:23:07] err, foundationwiki [19:23:23] robla: Something somewhere is being cached, and likely not just on wmfwiki, that's just the most visible of them [19:23:25] Doesn't need the bug link [19:23:29] He's familiar with the problem [19:23:36] k [19:25:14] actually, bug link is helpful [19:25:21] I saw on the git about scribunto that the mw.title part exists [19:25:48] but testing on test2 or fr it is not present. Is it for the next release? [19:26:07] I thought master was deployed by Tim? [19:26:33] mw.title == nil on this both wikis [19:26:45] anomie: ^^ [19:26:51] it would be nice not to use frame:preprocess("{{PAGENAME}}") :) [19:27:14] (if I understand well what I read on the git) [19:27:50] The Git would be a good newspaper [19:27:56] Reedy: Krinkle: is there a particular user facing problem we're experiencing right now as a result of this, or is this a general concern we're trying to address? [19:28:15] robla: Just Thehelpfulone brought it up again [19:28:19] Having noticed an issue [19:28:25] an/the [19:28:30] k.... is there a recent wikitech-l thread on this? [19:28:42] pesky me :) [19:28:43] something else not clear to me: does Lua uses for its internal function the locale? I mean string.format() is said to use C "printf()" behind, but the C printf() is supposed to use locale to format numbers, which is not the case on fr: [19:29:12] robla: It means any page not edited for (time ago we removed the wmf branch of when the last edit was made) will have 404 errors for all referenced resources in the page (most visibly: search icon and powered-by logo) [19:30:02] Krinkle: robla it seemed earlier that the sul icons were missing [19:30:16] when i tried again, maybe another server and they were there [19:30:17] :| [19:30:25] They are pretty static [19:30:29] huh [19:30:32] could be a fluke [19:30:46] the sul icons are likely unlikely to be related as post-login page is not cached. [19:30:51] hmmm [19:31:02] hexasoft- mw.title is not merged yet [19:31:04] !g 47913 |hexasoft [19:31:04] hexasoft: https://gerrit.wikimedia.org/r/#q,47913,n,z [19:31:05] Oh, wait [19:31:09] a problem nonetheless, but not the same (not sure if you were implying that it was) [19:31:10] They might not be static. [19:31:19] no idea [19:31:33] anomie: ah ok! thanks [19:31:39] I was thinking of the /usr/local paths [19:31:50] when not used with it, git pages are not very clear :) [19:32:11] anomie: will wait for next(s) release(s) [19:32:48] anomie: whatever, for functions that are planed (maybe) to be added, it would be nice to provide an stable interface whatever the way it is done. [19:32:57] hexasoft- In gerrit, look in the box on the upper left for "Status: Merged" [19:33:47] I mean, #ifexist function is not present, but if it will a day people will have to rewrite modules. if an existing mw.parserfunctions exists (even just performing a frame:preprocess(args)) it would prevent that, maybe [19:33:52] anomie: ok. [19:35:41] hexasoft- Yeah, it would have been nice if mw.title were merged so we don't wind up with people using "frame:preprocess( '{{#ifexists:...}}' )". [19:36:32] not still very important: few modules exists (at least on fr:), and all are in "busy testing" state [19:37:43] so they will not be used in "production" for a while. people are rather playing with possibilities at this time. Apart for few of us that make heavy devel on test2 since a long time. [19:38:07] * robla asks greg-g irl to document all of the caches and their timeouts somewhere on https://wikitech.wikimedia.org [19:38:43] we try to make IRL "Lua learning" at fr@france [19:39:03] oh really! [19:39:12] hexasoft: are you using https://www.mediawiki.org/wiki/Lua_scripting/Tutorial ? [19:39:30] no [19:40:23] we created http://www.mediawiki.org/wiki/Extension:Scribunto/We_use_Lua with user Rical [19:41:05] and I also created a "Project Lua" on fr:, with something more developped than this tutorial (and I translated in french the reference manual on mediawiki) [19:42:26] hexasoft: would you mind private messaging me your email address so I can communicate more with you about this? [19:42:26] Thanks [19:42:48] sumanah: yup [19:49:24] thanks hexasoft -- done. [19:49:31] subject line: helping people on French Wikimedia sites learn to use Lua [19:50:53] ok [19:51:09] got it [19:51:36] Thank you :-) I want the volunteer product adviser who is working on this to know of your work so he can help other communities replicate it [19:52:13] sumanah: I'm writing back an answer with more detailled stuff [19:53:17] ok :-) [20:11:41] btw their is still a strange behavior in Lua with parameters that come protected by or

[20:12:10] 	 their?
[20:12:12] 	 well
[20:13:24] 	 the string (or ustring) lib just see the part that is outside the protected part, plus the internal tag representation (the \127UNIQxxxxxx-nowiki-000XXXXQINU\127)
[20:14:01] 	 and string length is silly (length of outside part + size of the tag)
[20:14:14] 	 and no access to the part inside the tag
[20:15:39] 	 but returning the string still generates the correct output. That mean that we can't detect without "tricks" that we recieved a string with a protected part, and that we can't access to this protected part in order to analyse it.
[20:16:51] 	 btw the first xxxxxx looks like an hexadecimal code, maybe an internal reference?
[20:18:27] 	 Those are strip markers
[20:18:47] 	 yep
[20:19:10] 	 can print them by string.gsub(str, "\127", "_") :)
[20:19:47] 	 the problem is different: we don't control the parameters writers put in templates
[20:21:10] 	 let say that someone wants to put a "title" that contains special caracters, it will call {{mytemplate|...|{{TOTO}}|...}} and we will not be able to read this part
[20:22:36] 	 we will get a string that is of a non-sense length, and any manipulation on this string will probably destroy the real content
[20:25:55] 	 hexasoft: btw are you on https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors ? if not you should try to get on there
[20:25:58] 	 back in a few hours
[21:51:13] 	 sbernardin you will wanna work with DaBPunkt
[21:51:21] 	 on when amaranth can come offline for the memory swap
[21:52:04] 	 DaBPunkt: He would check with you on when he wants to take amaranth offline for memory swap right?
[21:52:49] 	 Whenever he has time and I'm online
[21:55:45] 	 cool, he is checking on our onsite spares
[21:55:50] 	 if we are lucky, we'll have it there
[22:20:28] 	 Hello techies.
[22:20:32] 	 When I went to this page:
[22:20:34] 	 http://en.wikipedia.org/w/index.php?title=Special%3ARevisionDelete&target=Special%3ALog&type=logging
[22:20:39] 	 I got this error:
[22:20:41] 	 [633827c2] 2013-02-20 22:13:38: Fatal exception of type MWException
[22:20:45] 	 Let's see
[22:21:18] 	 2013-02-20 22:20:38 mw1086 enwiki: [5fcb83c4] /w/index.php?title=Special%3ARevisionDelete&target=Special%3ALog&type=logging   Exception from line 1883 of /usr/local/apache/common-local/php-1.21wmf9/includes/db/Database.php: DatabaseBase::makeList: empty input for field log_id
[22:21:38] 	 I'll log a bug for that one
[22:22:17] 	 Thanks.
[22:22:22] 	 Surely that's not valid either way?
[22:22:28] 	 Yes, I know it shouldn't fail like that
[22:22:35] 	 What isn't, the link?
[22:22:53] 	 Yeah, trying to revision delete Special:Log?
[22:23:07] 	 That's how what I tried to do.
[22:23:14] 	 I mean.
[22:23:17] 	 That's now what I tried to do.
[22:23:20] 	 NOT
[22:23:21] 	 Sorry.
[22:23:25] 	 I don't know why I can't type.
[22:23:30] 	 heh, right
[22:23:57] 	 https://bugzilla.wikimedia.org/show_bug.cgi?id=45211
[22:24:10] 	 I actually can't remember what it was that I was trying to do.
[22:24:30] 	 I want to say that I was just trying to view the suppression log but now when I try that it gives me a different URL and consequently works.
[22:24:55] 	 Aha, I've got it.
[22:25:07] 	 I went to http://en.wikipedia.org/wiki/Special:Log/Deskana
[22:25:29] 	 If you click on the button "Show/hide selected log entries" with nothing selected, then you get that error.
[22:25:48] 	 Well, I do.
[22:26:07] 	 So what probably happened was that I thought I was clicking "Go" to view the suppression log but I clicked that instead.
[22:26:19] 	 heh
[22:28:27] 	 Anyway, thanks for your help.
[23:42:19] 	 Reedy: Okay, so why are bits resources using versioned URLs?
[23:42:32] 	 Haven't they always?
[23:42:39] 	 I don't know.
[23:42:41] 	 It seems silly.
[23:43:00] 	 Oh, Krinkle responded.
[23:43:04] 	 why would they not?
[23:43:32] 	 https://bugzilla.wikimedia.org/show_bug.cgi?id=44570#c18
[23:43:42] 	 That explains most of the issue.
[23:43:51] 	 Susan: Any link from the html to something from mediawiki needs to have either a mediawiki version or something that can derive that
[23:44:02] * AaronSchulz  nods
[23:44:14] 	 so it is either bits.wm.o/en.wikipedia.org/load.php (the hostname -> dbname -> multiversion -> mwversion)
[23:44:20] 	 "en.wikipedia.org"
[23:44:38] 	 and for non-resourceloader stuff it references bits.wm.o/static-{mwversion}/skins etc.
[23:44:56] 	 Okay.
[23:45:26] 	 The static-{mw-version} part is what I'm not sure about.
[23:45:27] 	 this has been needed since we got into HET-deploy where we run wikis on one of two different versions of MediaWiki. 
[23:45:50] 	 it is not to invalidate cache, but to distinguish it from other other
[23:46:19] 	 they could also be called A and B where we alternate which is which, but that doesn't work well in this case because bits caches things "permanently" by url alone.
[23:46:35] 	 No more cache.
[23:46:40] 	 Problem solved.
[23:46:43] 	 so that would mean if we go from v10 > v11  > v12 within 30 days, we'd be screwed.
[23:47:03] 	 as static-A would still be cached and based on v10
[23:47:06] 	 so we version it instead
[23:47:23] 	 it all works fine really, the problem here is mostly with our workflow, not with the technology
[23:47:45] 	 we started purging out old versions from the servers before they were no longer referenced.
[23:48:25] 	 and by we I mean a human being, not a scheduled script or automated response
[23:48:34] 	 .. that "we" wrote.
[23:48:38] 	 But they can and are referenced for years.
[23:48:44] 	 can be *
[23:49:38] 	 Susan: So first, see my "Long term" ideal. Which I wrote because yes they can indeed be referenced beyond our own cache control
[23:49:49] 	 So I see how that can happen, but a lot less likely than you may think. What is your scenario?
[23:50:11] 	 Remember that these links only appear inside the html of the output of certain UI elements. Not in public urls or stylesheets.
[23:50:43] 	 Hmmm.
[23:50:47] 	 Okay.
[23:51:10] 	 Thinking about caching gives me a headache.
[23:51:14] 	 No more cache.
[23:51:21] 	 It's basically the same like we had a long time ago
[23:51:33] 	 bits.wikimedia.org/live-1.5/skins/image.png?123
[23:51:46] 	 then at some point we deleted image.png and introduced new.png
[23:51:52] 	 bumped the style version to 124
[23:52:00] 	 live-1.5 also seemed silly to me.
[23:52:01] 	 deployed all wikis at once to MW 1.15
[23:52:03] 	 I don't like URLs like that.
[23:52:15] 	 that's not a MW version, not anymore anyway. Ignore that
[23:52:23] 	 bits.wikimedia.org/skins/image.png?123
[23:52:29] 	 Right.
[23:52:33] 	 That's the structure I like.
[23:52:33] 	 then from 1.15 onwards it would be new.png
[23:52:39] 	 and image.png was deleted in 1.15
[23:52:53] 	 so that'd be a 404 error, naturally. The image was renamed or deleted from the source code
[23:53:03] 	 and no longer referenced anywhere
[23:53:50] 	 Point being that it is fine to have urls to UI resources not work for ever. One day we'll get rid of skins/common/wikibits.js
[23:54:19] 	 whether the 404 will be on bits.wikimedia.org/skins/common/wikibits.js or bits.wikimedia.org/skins-1.27/common/wikibits.js doesn't matter
[23:54:26] 	 it is going to go away at some point
[23:54:41] 	 but only after we make sure it is no longer referenced from any of our cache
[23:54:59] 	 if someone is linking to it outside our control, that's their mistake for doing something silly like that.
[23:55:19] 	 that's like linking to github's minified stylesheet
[23:55:31] 	 view-source:https://github.com/
[23:55:36] 	 https://a248.e.akamai.net/assets.github.com/assets/github-2869fdd700237f10adaf1d01acc6faa615805273.css
[23:56:07] 	 after every deployment, github re-builds their stylesheet and 30 days later the cdn will probably purge ^ cache url and it'll no longer work
[23:56:18] 	 our urls are more readable, but doesn't make them less "internal" oriented
[23:56:22]