[00:07:33] TimStarling- I just tried a Scribunto module on my localhost test wiki, and since you used Parser::fetchTemplateAndTitle to fetch the module code, TemplateSandbox works without either extension having to know about the other. Awesome. [00:11:24] excellent [00:12:45] is it possible to allow the user to give some wikitext to test in the sandbox environment, instead of a page name? [00:13:15] maybe a radio button that unhides a textarea? [00:15:17] that is one feature I would like, another feature I would like is to have hooks which call Scribunto to allow logs from mw.log() to be displayed on the page [00:16:39] TimStarling- It would be possible to add such a text field, yes. [00:16:54] * robla ponders user interface [00:17:50] The other thing I guess would embed the same debugger that you have on edit pages now. I'll have to look at how that's done. [00:26:37] Here's a thought for the UI [00:27:34] let's say that, in the Template: and the Module: normal editing interface, we add a little bit at the bottom [00:27:57] so....you edit the template, and, instead of hitting "preview", like you would with a normal wiki page: [00:28:30] there's a separate button + field titled "Preview in page" and a field to put the page name [00:29:42] when you hit "Preview in page", it does the same trick that the special page is using, but pulls the text from the preview text. [00:30:23] TimStarling: thoughts on that? [00:31:16] could do [00:31:45] we do need a better way to test modules before they are saved [00:33:09] maybe we only enable it for the module space first, get the bugs ironed out there, and then enable it in the template space after that [00:34:34] mmm [00:35:33] (just the UI part....whatever special page gets called wouldn't be conditional on namespace) [00:35:47] anyway, that's probably a minor rollout detail [01:53:42] kaldari, https://gerrit.wikimedia.org/r/#/c/32486/ - is this supposed to fix a bug? [01:54:40] not a live bug, but a potential future bug due to https://gerrit.wikimedia.org/r/#/c/32091/ [02:05:33] kaldari, it doesn't actually work for me at all after that change [02:05:58] you have to update core as well [02:08:30] kaldari, the core change is the issue [02:09:21] it was working for me, but let me check again... [02:12:57] hmm, I must have broken something... [02:17:55] oops, I accidently deleted a line in jquery.badge.js... [02:20:19] Krenair: https://gerrit.wikimedia.org/r/#/c/32489/ [02:22:39] kaldari, still bugged. [02:22:52] When you keep running $('#pt-notifications a').badge(8, true); it updates the numbers but keeps appending the badges [02:23:11] instead of keeping one and updating it's number [02:24:07] ah, missing an else [02:24:14] this is just sloppy :) [02:25:48] ok, fixed now [05:04:28] New patchset: Stefan.petrea; "Added statically built binary udp-filter-static" [analytics/udp-filters] (master) - https://gerrit.wikimedia.org/r/32493 [15:20:34] Krinkle|detached: https://gerrit.wikimedia.org/r/#/c/32475/ [15:21:08] Change merged: Krinkle; [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/32475 [17:09:24] https://bugzilla.wikimedia.org/show_bug.cgi?id=41919 [17:09:54] Pretty sure there's more bugs about these pages not being updated for performance reasons, but I can't find them [17:29:39] gwicke: there's still some root@parsoid-roundtrip7-8core.pmtpa.wmflabs and also 1? 3? through 6 that send pretty frequently enough when you add them all up.... if you wouldn't mind... [17:29:42] also, good morning :-D [17:30:44] apergos: good morning [17:31:33] let me set up the MAILTO thing [17:31:37] sweet [17:31:49] if you know other folsk on labs projcts, please pass that tip on [17:32:00] I don't hang out in that channel so I'm a bit out of that loop [17:32:39] ok, will do [17:32:46] apergos: What is this? (I ask, having several labs instances) [17:32:47] thanks! [17:32:52] do you get mail from any in particular? [17:33:05] so marktraceur, if your cron job produces output (either by plan or cause something's broken) [17:33:15] it comes to everyone in ops. as often as it breaks [17:33:23] gwicke: I saw 3 throgh 7 [17:33:24] Oh excellent. [17:33:35] * marktraceur didn't set up any cron jobs to his knowledge [17:33:35] I dunno if I deleted 1 and 2 earlier or they just don't produce [17:34:01] ( gwicke ) [17:34:06] No wait! There is the backup script for orgcharts. apergos, do you get mail from orgchart-dev.pmtpa.wmflabs? [17:34:11] lemme see [17:34:34] yep there's one [17:34:45] Database ready. [17:34:45] Default Username guest [17:34:45] Default Password [17:34:48] apergos: Well, one is hardly worth the worry. [17:34:49] and some stuff I shouldn't put in there [17:34:58] well I have been doing cleanup of my inbox [17:35:03] so I tossed a lot of old mail [17:35:22] apergos: The guest password is fine, it's the admin password that shouldn't get shared :) [17:35:25] if thes ereally run once an hour I'll get 24 a day [17:35:40] (guest has zero permissions by default, so it's like being logged out but without a login button) [17:35:47] hopefully puppet does not remove the MAILTO [17:35:47] anyways it's a good policy for people to just use mailto at the top of their crontab [17:35:56] so they do get notifications if something changes and breaks [17:36:09] how do you add jobs to cron? [17:36:15] just add the mailto the same way [17:36:41] this assumes that mailto is actually sending mail where you specify (is it, gwicke? ) [17:36:49] I'm a bit unclear on the mail setup in labs [17:37:01] marktraceur: ok, well that's cool [17:37:03] apergos: no idea- the labs environment is all puppetized.. [17:37:29] so things don't always work as expected, or are reverted behind your back [17:37:44] ok well someone must have set up the existing cron jobs that run, maybe poke them about it [17:38:00] yeah puppet is a great revert behind your back kinda guy, I've notices that [17:38:06] *noticed [17:39:09] enabling public key root logins for example only works until puppet reverts the authorized_keys file [17:39:16] hahaha [17:39:38] so I constantly get to type my password in an untrusted environment [17:39:43] you need a cron job that copies it back right after each puppet run [17:39:46] which is very secure of course ;) [17:40:41] apergos: I had that for a while, but it did not work too well [17:40:44] gwicke: SSH'd via public key is an untrusted environment? :/ [17:41:04] marktraceur: VMs with other roots is [17:41:34] *nod* makes sense--though I'm sure subbu and I have little reason to want your labsconsole password :) [17:41:37] once a minute, check if the auth key file is different, if so copy the new one in place [17:41:46] a bit wasteful but whatever, it's only a few cpu cycles :-D [17:42:19] apergos: I was told that might be supported at some point, so I am waiting for that- maybe not the wisest idea ;) [17:42:25] hahaha [17:42:30] well it depends on yer patience! [17:44:09] alright, after typing my password six times all client crontabs should now be updated [17:44:23] aww :-( [17:44:27] thank you for fixing though! [17:45:37] apergos: thanks for letting us know and absorbing the cron spam ;) [17:45:55] :-D [18:00:46] thedj[work]: About? [21:19:48] petan: jsi? [21:31:14] Reedy: around? [21:40:26] yes [21:43:24] 64 bytes from Reedy: icmp_seq=0 ttl=55 time=9 mins [22:08:54] RoanKattouw: Bug filed as https://bugzilla.wikimedia.org/show_bug.cgi?id=41935 for post-December release. :-) [22:13:21] Thanks [22:16:20] RoanKattouw: And the breaking-change-now thing as https://bugzilla.wikimedia.org/show_bug.cgi?id=41936 [22:16:31] RoanKattouw: ... for the code you just submitted. :-) [22:17:21] Thanks for retrobugging that [22:17:54] :-P [22:35:48] Hi Danny_B|backup. [22:36:13] Danny_B|backup: are you sure really want to include the "easy" keyword to configuration bugs? [22:37:18] I understand the "easy" keyword as an outreach possibility to tell new people "hey, we've something easy to do here, try that, you'll discover our codebase" [22:38:37] Then the new developer reads your bug, without explanation and have a config. Yes, it's easy to edit InitializeSettings.php and copy/paste it, but... well... we've to know this file exists first. [22:39:16] andre__: by the way, could you clarify in one document what constitutes a good 'easy' bug? [22:48:45] clarify the doc for easy kw then [22:50:09] copypaste seems to be easy for me [22:51:34] or you may like to have two separate kw's [22:52:13] some as "newbie-able" some as "nothing-difficult-to-do" [22:56:14] Dereckson: I've just discussed that with Brooke a couple days ago [22:56:22] look in #wikimedia-tech logs [22:56:44] (I agree with you) [22:56:50] Oh, we're back to that. [22:56:58] * Nemo_bis hides [22:57:10] I'm not [23:13:17] Danny_B|backup: this seems a good idea, but maybe should we use the "trivial" sev. level for easy as "nothing-difficult-to-do" [23:14:08] andre__: how would you define the "trivial" severity level? [23:32:25] kaldari: Getting the flickr stuff merged soon? :) [23:32:37] I think so [23:32:47] I don't see any more obvious problems [23:32:58] YAY [23:33:12] I just finished a really messy rebase :) [23:33:14] I hope I am there when you do so I can buy you cake and hat trimmings [23:33:24] it was starting to code-rot [23:33:42] kaldari: Next up, MediaGoblin integration :P [23:34:22] By the way, if you haven't seen, the last day of the MediaGoblin campaign is today: http://mediagoblin.org/pages/campaign.html [23:34:29] I'm thinking about pushing it out to production, but keeping the feature turned off for now, so we can make sure the code doesn't break any of the existing functionality first. [23:35:18] kaldari: chris and zeljkof might be able to help with that! [23:35:28] RoanKattouw: if I want to run something as soon as resourceloader has loaded it (and all modules it depends on); how might I do that? [23:36:10] isn't that the default behavior? [23:36:29] I mean once it's included in the page output [23:36:52] maybe? :p [23:37:34] mwalker: You could do an mw.loader.using on the resourceloader module [23:38:13] mwalker: I feel like there's no difference, but if you wanted to be _extra_ sure.... [23:38:49] well; the code that'll be running is inside the module that's just been loaded, so... everything should be peachy... [23:39:09] are you wanting to change where it's output in the page? [23:40:33] no; I just need to call mw.centralnotice.initialize() after it's been loaded [23:40:37] Oh [23:40:41] That bug [23:40:44] yep :) [23:40:54] mwalker: How is the centralnotice module loaded currently, and where is that initialize() call located? [23:41:22] looks like it's currently injected via skin hook [23:41:23] it's located in the #siteNotice div in the body [23:41:59] oh; RoanKattouw; centralnotice is a RL module -- but that initialize call is injected via skin hook [23:42:05] via SiteNoticeAfter hook [23:42:25] actually [23:42:25] I see [23:42:31] unless you guys changed it [23:42:34] nope [23:42:43] mwalker: Does the centralnotice RL module have 'position' => 'top' in its definition? [23:43:07] yep [23:43:11] OK [23:43:31] How much of that module is wrapped in a $(document).ready( ... ) wrapper? [23:43:48] Specifically, is the mw.centralNotice object created from within a document ready handler [23:43:58] I don't think any of it is [23:44:07] no, it's actually in a mw.loader.using('mediawiki.util') block [23:44:24] Ah, I see [23:44:34] That's a messed-up set of priorities then [23:44:51] So you're expediting the loading of the centralNotice code, only to have it wait around for the util code [23:45:17] it doesn't actually seem to use the util code... (unless mw.config is part of mw.util) [23:45:21] It's not [23:45:29] If it doesn't use util, then get rid of the using wrapper [23:45:32] That'll save you the delay [23:45:42] and replace it with document.ready? [23:45:44] NOOO [23:45:55] I asked about document ready because that's another delaying factor [23:45:58] aah [23:45:59] I see [23:46:10] It's needed if you want to modify the document in most cases [23:46:13] it doesn't look like we're even using mw.util anymore [23:46:20] so we can probably axe that [23:46:29] But things like creating the mw.centralNotice object and its methods shouldn't be in a document ready handler [23:46:45] should that skin JS call be in a document ready handler? [23:47:52] What skin JS? [23:48:05] the bit that calls mw.centralnotice.initialize [23:48:31] the skin js is the part that loads the bannerController [23:48:36] Depends on what initialize itself does [23:48:43] Does it modify the DOM? [23:48:45] yep [23:48:56] yes, but... [23:49:22] it only modifies the siteNotice div which is why it's inserted in the SiteNoticeAfter hook (or at least it used to be) [23:49:58] hopefully that's still how it's set up [23:50:00] kaldari / mwalker: do you guys have a link to the JS? which repo is it in? [23:51:12] the skin JS isn't in document.ready and shouldn't be, since the initialize function needs to be available when the siteNotice div loads [23:51:43] what's the problem we're trying to solve anyway? :) [23:52:13] ori: it's the CentralNotice extension -- modules/ext.centralNotice.bannerController/bannerController.js [23:52:21] kaldari: https://bugzilla.wikimedia.org/show_bug.cgi?id=41937 [23:53:29] * ori-l takes a look [23:53:38] sounds like some random JS is failing somewhere and bannerController.js is not being loaded (or completely loaded) [23:54:00] probably a reserved JS word or comma somewhere [23:54:51] well, we had a report of this happening to someone on chrome with a slow internet connection as well [23:55:01] useful snippet: $.grep(mw.loader.getModuleNames(), function (module) { return mw.loader.getState(module) === "error"; }); [23:55:10] I would get rid of the mediawiki.util dependancy and see if that helps [23:57:08] ah; actually; what if we get rid of that util; and wrap the skin JS in mw.loader.using( 'ext.centralNotice.bannerController')? [23:57:28] that way we make sure we don't execute it until RL has actually loaded it [23:57:43] extra comma line 144 of bannerController.js [23:57:52] kaldari: sounds right [23:57:55] ie will choke on that [23:58:09] also line 162 [23:58:59] ... srsly... that's something I didn't know [23:59:40] mwalker: your idea would also be good [23:59:43] mwalker: unrelated, but change line 86 from window.setTimeout( 'mw.centralNotice.waitForCountry();', 100 ); [23:59:58] to: window.setTimeout(mw.centralNotice.waitForCountry, 100);