[00:02:14] robla: where are we in the rollout? [00:02:29] hexmode: see #wikimedia-tech [00:02:31] all wikinews' are on 1.19 [00:02:37] robla: also, a bunch of the new bugs today were imports from huggle [00:04:01] also https://wikitech.wikimedia.org/view/Server_admin_log [00:04:04] :) [00:09:03] Hi [00:10:11] robla: are we still doing 20% checkin today ? [00:54:23] robla: i totally forgot about the 20% check-in but reading the scrollback??? it doesn't look like it happened anyway? [00:54:38] yeah, we're mid deploy right now [00:54:45] k [00:55:31] awjr: rmoen: keep an eye out for site bugs ....lots of discussion in #wikimedia-tech to follow [00:56:39] awjr: rmoen: another thing to look for is #wikinews* or on-wiki bug reports [00:57:50] awjr: rmoen: about to do wikisource, it looks like if you want to help watch for proofreadpage bugs :) [01:14:52] TimStarling: So someone just noticed that on pages with e.g. {{CURRENTTIME}}, we set the parser cache expiry to one hour, but this does not propagate to the s-maxage header. I'd swear it was intended to propagate that way (i.e. send s-maxage=3600 instead of 30 days when there's a magic word on the page) but it's not happening in production [01:15:11] ok [01:15:27] This would be one line of code, to the tune of $this->setSquidMaxage( $parserOutput->getCacheTime() ); in OutputPage::addParserOutput() [01:15:41] (or whatever the exact names are) [01:48:38] Is there any way we could have a script visit all wikis and see which mainpage views are loading http on https etc? [02:03:51] Reedy: ^ that's a good thing to request from chrismcmahon tomorrow [02:05:14] agreed [02:07:11] You can get a request, get all the scripts/styles that includes, and pull those aswell [02:07:15] seems inefficient [02:07:18] Must be a nicer way :) [02:09:46] a bot! [02:13:57] chrismcmahon: do you want me to log a bug for you? [02:16:00] Reedy: sure, or send email. I'm about done for tonight. [02:18:01] Pfft [02:18:04] It's 2am here ;) [02:18:37] Reedy: you're a better man than I, Gunga Din :) [02:19:47] we haven't entirely figured out when Reedy sleeps [02:19:52] ...or if [02:19:56] Neither have I [02:23:45] AaronSchulz: https://bugzilla.wikimedia.org/34659 -- why was this changed? Seems like this sort of change should be announced. [02:24:04] or at least made available for discussion [06:12:01] Someone dropped a Gunga Din reference in here? Nice. [08:33:06] Reedy, hoo has switched about 3000 MediaWiki messages (with CSS, JS, whatever) to protocol-relative URLs and this should have fixed most of it on most wikis [08:33:50] except evil JS which produce HTTP links with string manipulation [09:11:16] Nemo_bis: if there is any mass work to be done in mediawiki space, let me know :) [09:11:38] petan|wk, ok ;) you weren't given the flag to slack :p [09:11:46] heh [09:12:00] well, of course you already know Krinkle's big JS plan [09:12:06] not really [09:12:19] no? I think I linked it on your request? [09:12:31] oh, let me check maybe I did [09:13:25] petan|wk, https://meta.wikimedia.org/wiki/User:Krinkle/Le_Tour_de_Wik%C3%AD/2011_Resource_Walker [09:14:18] petan|wk, first thing to do would be to fix protocol-nonrelative URLs if any is left around [09:15:10] petan|wk, hoo used just this silly script: https://meta.wikimedia.org/wiki/User:Nemo_bis/HTTPS [09:17:42] sure [09:20:11] yes I recently fixed some of these on czech projects [09:20:32] how do I update the toolserver tracker? [09:20:42] petan|wk, there's a table on wiki [09:20:52] petan|wk, https://meta.wikimedia.org/wiki/User:Krinkle/Le_Tour_de_Wik%C3%AD/2011_Resource_Walker/log [09:21:19] did you follow all Krinkle's instructions? if you skip even a single step he removes you projects from the "done" list :p [09:22:20] ok [09:24:50] btw I don't need to inform local community of the wiki that we change the code of their interface? [09:25:33] petan|wk, naaah [09:25:46] just use a clear edit summary and avoid changing the result [09:25:50] ok [09:26:08] If you remove or break something they won't be happy. :p [09:26:42] Enabling email notifications for talk and maybe watchlist on those small wikis usually helps [09:27:58] yes, I started with cs they know me there [09:28:21] I work on huggle so I have some crosswiki experience :) [09:28:35] sometimes I have to fix it on other langs [10:41:41] is there a git command to get the fetch the code as it was on say may 12th 2010 so I can test a patch [10:44:04] OrenOf: "git log --until=2010-05-13" to get the SHA number, and then "git checkout" that number? [10:45:08] 10x [10:45:26] np=p [15:08:23] Nemo_bis: cheeers! [16:46:22] I am new to mediawiki development , can any one tell me about hooks? [16:51:32] !hooks | bharath [16:51:32] --elephant-- bharath: I don't know anything about "hooks". You might try: !hook [16:51:37] !hook | bharath [16:51:37] --elephant-- bharath: http://www.mediawiki.org/wiki/Manual:Hooks/`e1 [16:51:46] elephant is borked. [16:51:49] see http://www.mediawiki.org/wiki/Manual:Hooks [17:03:15] I'd beat the elephant but I'm not sure I want to die today. [17:22:47] who is should I talk to about fundraiser bugs? [17:32:18] hi all [17:33:18] gah...once again I didn't drop this on the cal [17:33:20] oh well [18:06:34] robla: http://etherpad.wikimedia.org/119triage [18:28:14] hexmode: can you send an email out to wikitech-l asap based on http://etherpad.wikimedia.org/119triage ? [18:28:33] robla: Was already composing one :) [18:29:21] robla: is there anything in particular i should be focussing on around the 1.19 release for my 20% day? [18:29:40] awjr: https://bugzilla.wikimedia.org/show_bug.cgi?id=34653 [18:29:58] that one looks pretty straight-forward [18:30:37] awjr: also, if anything on this list looks more up your alley and isn't assigned, assign one to yourself: https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&list_id=91536&resolution=---&target_milestone=1.19wmf%20deployment&known_name=1.19%20deploy%20blockers&query_based_on=1.19%20deploy%20blockers [18:30:54] kk thanks guys [18:32:42] robla: cleaned up your query on the etherpad... is there a secret to why I don't see you on the etherpad? [18:33:18] I have no idea. I see me. :) [18:33:34] the invisible man can see himself [18:33:39] :) [18:43:36] *hexmode wants a village pump bot to help with the monitoring [18:43:46] maybe I should just use RSS [18:56:58] robla: I need some clarification before I make any (more) stupid statements: What is the status of Swift right now? [18:57:35] Swift is deployed for thumbnails. Originals are still served out of NFS [18:58:03] robla: could you look at the latest on this bug: https://bugzilla.wikimedia.org/34611 [18:58:04] hexmode: what context is the status of Swift coming up? [18:59:05] (I got my dates from the SAL, fwiw) [19:00:16] *robla is commenting now [19:00:38] im trying to get file uploads working on a local wiki for testing. when i try to upload an image, i get the following warning "Could not create directory "mwstore://local-backend/local-public/7/78"." anybody know what might be going on? (this is at head of phase3) [19:03:50] hexmode: the SAL? [19:03:59] Server Admin Log [19:04:18] https://wikitech.wikimedia.org/index.php?title=Server_admin_log [19:50:43] This is how I feel while writing javascript: http://knowyourmeme.com/photos/234739-i-have-no-idea-what-im-doing [19:51:37] puppy!! [19:52:09] hehe [19:54:14] sumanah: https://www.mediawiki.org/w/index.php?title=Git%2FWorkflow&diff=503560&oldid=503559 [19:54:25] Also, ZOMG TEHE EDITZ on that history paeg [19:54:33] You've edited it like 20 times in the past 2h [19:54:36] Thank you RoanKattouw [19:55:01] RoanKattouw: yes, I have a pretty iterative style of editing when it comes to this stuff [19:55:15] That's actually quite appropriate given the subject matter [19:55:23] ha! [19:55:28] RoanKattouw: first screenshot is up [19:55:37] yay [19:55:48] OK I'm leaving for lunch now, see you at 1 [19:55:50] it doesn't reflect the branching [19:55:51] thanks [19:55:52] (I'm being summoned) [19:56:04] "Topic" will be different [19:56:19] You could try out my instructions and create a new screenshot, two birds in one stone [20:57:34] 3 min to a triage on http://etherpad.wikimedia.org/119triage [20:58:15] About 14 1.19 bugs to triage. [21:01:11] yes, gross [21:01:17] robla: you're here? [21:01:27] yeah [21:02:08] k, So I put my goals at the top of the etherpad... feel free to update if you think they need it, but I'm pushing on now [21:02:25] http://bugzilla.wikimedia.org/34508 -- [Regression] IRC string output for log messages no longer compatible [21:02:45] Reedy: you around? [21:02:49] I meant to talk to reedy about this, but didn't get a chance yet. [21:03:04] AaronSchulz: ping? [21:03:16] well...no, let's not rope him in on this one [21:03:34] I'll send Reedy an email [21:03:50] next: http://bugzilla.wikimedia.org/34538 -- DOM modification at module execute versus $wgResourceLoaderExperimentalAsyncLoading [21:05:04] this one we can lower the priority and make a 1.20 thing [21:05:04] Tim seems most familiar with this. I'll assign him. Which point do we want this fixed for? [21:05:08] k [21:05:15] no....lemme explain first [21:05:27] *hexmode waits [21:05:46] so...Roan disabled $wgResourceLoaderExperimentalAsyncLoading earlier this week [21:05:55] it's still probably Roan's bug to fix [21:06:05] ...and we will probably want to make sure this works for 1.20 [21:06:18] Roan's at lunch IIUC [21:06:22] ...since we plan to reenable [21:06:35] I'm back now [21:06:41] Trevor's gonna be in in 5-10 [21:06:48] RoanKattouw: http://bugzilla.wikimedia.org/34538 [21:06:55] Oh, yeah [21:07:17] It just needs someone to go over all the extension JS and check that they're all being good boys and girls and not manipulating the DOM outside of document ready handlers [21:07:33] ok to copy robla's irc chat, change it to "normal" and mark for 1.20wmf milestone? [21:07:56] acutally...quick irl convo with Roan [21:08:30] kk I'll wait [21:08:46] looks like we should keep it on the list [21:09:08] $wgResourceLoaderExperimentalAsyncLoading exacerbates the problem, but turning it off doesn't make the problem go away [21:09:13] for 1.19? for monday or later? [21:09:52] I'm trying to convince Roan that it's important irl :) [21:09:56] or better: cleanup work or pre-enwiki? [21:09:58] :) [21:10:31] evening [21:10:41] Nikerabbit: hey [21:10:46] evening [21:10:57] hexmode: let's keep it on the blocker list and move on [21:11:11] url for those that just joined http://etherpad.wikimedia.org/119triage [21:11:27] (I'm around for a little while as a volunteer) [21:11:35] next: http://bugzilla.wikimedia.org/34542 -- mw.loader.load calls document.write from asynchronous scripts [21:11:42] sumanah: So, LWN article? [21:11:49] Oh, is there a meeting going on here [21:11:51] hexmode: My comment on that bug: it breaks scripts on pl.wikisource which load tons of js from pl.wikipedia using mw.loader.load, any alternatives? [21:11:56] RoanKattouw: there is. [21:11:59] OK [21:12:00] who and when on #34542 [21:12:03] Yeah that bug is annoying [21:12:05] RoanKattouw: let me extract myself from another conversation and I'll join you. [21:12:09] I gotta think about how to engineer a fix for that [21:13:12] It's sort of a hard problem, because we have competing b/c interests [21:13:50] One the one hand, mw.loader.load() needs to still work from Squid-cached HTML [21:14:09] One the other hand, it also needs to still work from user scripts and Gadgets [21:14:22] We *could* tell the user script people to "just change all the calls" but that's not nice [21:14:49] RoanKattouw: so we keep it and you and krinkle basically need to handle it, right? [21:14:51] RoanKattouw: do you know any workarounds? I need to patch those scripts... [21:14:53] Hi [21:14:56] brb [21:15:01] Reedy: ! [21:15:05] Beau_: The workaround is mw.loader.load( 'http://example.com/url', 'text/javascript', true ); [21:15:26] Reedy: http://bugzilla.wikimedia.org/34508 status? [21:15:36] hexmode: Yeah other people than me or Krinkle are not going to be fixing this one [21:15:44] RoanKattouw: thanks, I'll try that [21:16:06] RoanKattouw: is it something that should be fixed before enwiki, dewiki see it? [21:16:12] Yes [21:17:04] next: http://bugzilla.wikimedia.org/34604 -- [mw.config] wgActionPaths should be an object instead of a numeral array JavaScript [21:17:39] didn't Krinkle fix that or was it something else? [21:18:05] He did [21:18:07] *robla is back [21:18:10] And Reedy deployed it [21:18:15] so it can be closed? [21:18:27] Yeah [21:18:34] It's definitely fixed in the code, I've seen the rev [21:18:38] \o/ [21:19:08] next: http://bugzilla.wikimedia.org/34609 -- jQuery UI Datepicker div visible [21:19:16] is that really something for 1.19? [21:19:49] robla: ^^ [21:20:44] well, I *think* what that means is that the datepicker is broken in upload wizard [21:21:01] looks like a basic styling issue [21:21:16] but if it just means there's an annoying artifact, that's *probably* not an issue, except.... [21:21:39] ...it's possibly a minor symptom associated with much more major problems [21:21:49] robla: I'm going to take it off of 1.19 and say we can put it back if rainer's clarification says it is a major thing, is that ok? [21:22:04] a bit vague report, has anybody tried to reproduce it? [21:22:08] we're having lots of CSS issues in UploadWizard, some of which cause breakage [21:22:39] ...because the javascript is moving elements around with jquery using css attributes [21:23:15] I'd like to leave it on our list, but leave it "normal" priority [21:23:20] k, will I've asked rillke to join us here in case he is watching -commons [21:23:27] k [21:23:35] I agree [21:24:22] next: http://bugzilla.wikimedia.org/34653 -- Logs corrupt or have big delays [21:24:42] awjr is working on this one [21:24:47] that looks like having two different issues [21:25:16] one might be caused by the fact that log_params are serialized in new logs, no idea about the "big delays" issue [21:26:02] robla, oh, I forgot: is 34609 cleanup work or pre-enwiki? [21:26:32] same with #34653 [21:27:21] *hexmode listens to jeopardy muzak [21:28:03] sorry...pulled away for a sec [21:28:10] :) [21:28:36] 34609 is cleanup work [21:28:47] I'd like to get it associated with our other upload wizard bug, though [21:29:44] let's see where Arthur gets with 34653 [21:29:50] leave it on the list [21:30:39] *robla has to multitask here, so please don't block on me [21:30:42] hexmode: ^ [21:30:48] robla: k [21:31:12] next, pretty sure this is one that needs to block enwiki deploy: http://bugzilla.wikimedia.org/34659 -- Special:Contributions/Newbies lists contributions by user "Newbies" instead of new account edits [21:31:26] hexmode: Hello! [21:31:43] hexmode: that one remember something [21:31:44] rillke: hey, we were just talking about your bug [21:32:01] I am pretty sure we raised the issue during 1.19 developpement [21:32:15] hashar: which one? [21:32:25] 34659 / the newbies thing [21:32:34] hashar: there is discussion on the rev to make the change [21:32:39] AaronSchulz is working on this one [21:32:59] so skip? [21:33:03] yeah [21:33:11] kk [21:33:25] rillke: could you help with #34609? [21:33:34] https://bugzilla.wikimedia.org/show_bug.cgi?id=34609 [21:33:53] rillke: we wanted to see if date picker wasn't working as a result [21:34:09] or if it is just a symptom of the CSS problems with UW [21:34:47] hexmode: No not just UpWiz; it's a problem of the datepicker [21:34:59] hexmode: But it works correctly. [21:35:14] k, so we'll leave it as cleanup work [21:35:18] ty rillke :) [21:35:34] next [21:35:35] http://bugzilla.wikimedia.org/34664 -- Javascript errors in firebug and page flash on commons when debug=true [21:35:49] pretty sure that one doesn't block 1.19 and is just cleanup [21:36:00] anyone disagree? [21:36:43] agreee [21:36:52] RoanKattouw: agree? [21:37:06] would be great to send one of our dutch one to look at the bug though [21:37:13] I mean Timo / Roan [21:37:16] heh [21:37:34] I looked a bit at that bug today but that is not my league :-] [21:37:40] yes, but we have other things to do right now [21:37:45] next: http://bugzilla.wikimedia.org/34667 -- drop image file sometimes creates no thumb and does not complete [21:37:59] bug 34664 is just bad site JS [21:38:26] 34667 is not nice, and affects a power user [21:38:26] rillke: if you're still listening ^^ 34667 ... any thoughts? [21:38:53] chrismcmahon: you are a power user? ;) [21:39:14] reported by Matthew Roth [21:39:28] chrismcmahon: sorry, just teasing. I knew. [21:39:47] drop a file onto the UW page and basically the browser opens the file directly without ever engaging UW [21:39:57] or so it seems [21:40:00] putting as pre-enwiki thing for urgency sake [21:40:59] ok, just found out about this one: http://bugzilla.wikimedia.org/34698 -- "accept" button isn't greyed out if the rev is already accepted [21:41:57] who is maintaining flagged revs [21:41:59] ? [21:42:04] Aaron? [21:42:34] AaronSchulz: http://bugzilla.wikimedia.org/34698 -- "accept" button isn't greyed out if the rev is already accepted [21:42:34] [21:42:40] Aaron [21:42:57] cleanup, right? [21:43:08] no...let's get it fixed [21:43:13] k [21:43:16] high priority, plwiki blocker [21:44:25] k, let me look at 34538 and 34508 and make sure they're properly scheduled [21:44:51] Reedy: since you're here: http://bugzilla.wikimedia.org/34508 -- [Regression] IRC string output for log messages no longer compatible [21:45:17] Reedy: what is the status, and when do you think it will be fixed? [21:45:36] I haven't touched it since earlier in the week [21:46:15] k, sounds like something we want to get fixed before it hits the *pedias, though, right? [21:46:29] I can get a look at 34508 [21:46:48] We'd also want to make sure there is someone who can find out what isn't still working [21:47:03] hashar: can you do that? [21:47:04] let's reassign this to hashar [21:47:13] will poke it tomorrow [21:47:15] k pre-plwiki? [21:47:28] Nikerabbit: I will probably end up writing a basic test suite for the IRC logs hack [21:47:55] hashar: it's been mostly guess work and replicating 1.18 as closely as we can [21:48:12] hexmode: let's put it pre enwiki [21:48:31] k, done [21:48:35] Nikerabbit: that last comment from Krinkle in the bug is a little alarming [21:48:50] let me read [21:49:02] it looks like the plaintext call might not be made correctly in a spot or two [21:49:38] robla: I've seen that before, but never paid attention to it [21:49:42] [Special:Log/patrol]] patrol * Tiptoety * marked revision 3486813 ???. [21:49:44] wonderful! [21:50:00] robla: it's related but looks like a different bug [21:50:07] Did someone use Linker::link() in the IRC log line there? [21:50:12] hashar: tip comes from linker class [21:50:43] RoanKattouw: it shouldn't, that's the bug I guess [21:51:30] k, 9 more min [21:51:39] what about this one? http://bugzilla.wikimedia.org/34504 -- [Regression] There should not be a mismatch between html and stylesheet version [21:51:44] WONTFIX now? [21:51:57] (see robla's last comment) [21:54:01] RoanKattouw: wontfix? http://bugzilla.wikimedia.org/34504 [21:54:21] Yes [21:56:21] Krinkle: RoanKattouw: this needs to be fixed before Monday? http://bugzilla.wikimedia.org/34450 -- Probable Javascript loading issues (navigation and tabbing issues, multiple browsers) [21:57:15] Oh that's the omnibus bug still? [21:57:41] RoanKattouw: No, I think that's bug 34538 [21:57:49] although this one is a bit of an omnibus also [21:58:04] Maybe https://bugzilla.wikimedia.org/show_bug.cgi?id=34450#c26 is a fix? [21:58:48] maybe [21:59:13] I haven't tried it yet, but looks like a good thing. Although I'm not sure that bug fix is related to the bug number it's commented on [21:59:14] hey, I'll have to give helder.wiki a big "THANK YOU" :) [21:59:57] yeah, may just be a single issue on a multi-issue bug [21:59:59] ugh [22:00:02] It's probably *a* fix for *a* bug [22:00:16] *AaronSchulz looks at $( 'mw-fr-submit-accept' ).prop( 'disabled', 'disabled' ); [22:00:17] *chrismcmahon regrets not breaking 34450 into different issues. [22:00:41] AaronSchulz: Missing . or # ? [22:00:52] up :) [22:00:54] chrismcmahon: oh, well. [22:01:19] it's served a purpose, but in hindsight was a bad idea. [22:01:27] I'm about to leave, bug I think we've got the work scoped out [22:01:52] but [22:01:54] heh [22:02:01] anyway, tyvm [22:02:30] yay [22:02:33] zZZ time [22:03:03] *AaronSchulz slaps TSVN 1.7 [22:03:22] you cannot commit to dir X if anything there is outdated, not just the effected files [22:04:00] well, with git you cannot push to repo X if anything there is outdated (if I've understood correctly) [22:05:47] That's true [22:05:52] But you can just stick it in a branch and then merge [22:08:05] RoanKattouw: I hate it when I have to svn up a few times in a row if people beat me to it :) [22:21:51] Reedy, RoanKattouw: it seems you both have done some work on the query log event api. there are some weird things going on with it in 1.19, like not properly handling serialized params (https://bugzilla.wikimedia.org/show_bug.cgi?id=34653) [22:22:28] poking around though, it seems that logging.log_params does not always necessarily contain a serialized object [22:22:49] Then it's probably DB corruption and the API is just exposing it? [22:22:53] do either of you know when it's safe to assume that logging.log_params will be serialized vs when it will not? [22:22:55] Or someone changed the format and didn't update it? [22:23:02] Maybe this has to do with Nikerabbit's logging rewrite work? [22:23:15] *RoanKattouw is busy and would like either Nikerabbit or Reedy (or both) to look into this [22:23:21] no worries RoanKattouw [22:23:25] thanks [22:23:48] pending response from Nikerabbit or Reedy i'll just keep poking and see what i can figure out on my own [22:24:09] was? [22:24:20] hi Nikerabbit [22:24:37] awjr: only new log entries of log types using new logging code have serialized stuff [22:24:49] awjr: logentry should abstract that for you [22:24:59] Does ApiQueryLogEvents use that correctly? [22:25:13] Nikerabbit: what is 'logentry'? [22:25:18] awjr: a class [22:25:42] it doesn't appear that ApiQueryLogEvents is making use of that class anywhre [22:25:57] it probably should [22:26:27] heh [22:26:37] Nikerabbit is there documentation i can look at somewhere? [22:26:52] awjr: what kind of? [22:27:25] Nikerabbit: something to help me wrap my head around how logging works and how to do things like determine when i'll need to handle serialized log params or not [22:27:55] or at least help me get this resolved: https://bugzilla.wikimedia.org/show_bug.cgi?id=34653 [22:27:56] the theory goes that you do LogEntry::newFromRow( $row ) and call ->getParams on that [22:28:47] getParameters* [22:28:52] cool [22:29:07] getParameters handles the serialized vs. not/ [22:29:08] ? [22:29:08] The Laxstr??m Theory [22:29:12] and DatabaseLogEntry::newFromRow... [22:29:23] awjr: yes [22:29:29] in very ugly way, but yes [22:29:40] heheh ok [22:29:56] thanks i'll keep poking it [22:30:28] and there is still problem that the key names are bit different, so if somebody is relying on the exact names, you need to convert x:y:z into just z [22:30:55] Nikerabbit: there appear to be places in the Api code that already deal with that [22:31:02] or at least sort of deal with that [22:31:36] for instance: [22:31:36] case 'rights': [22:31:36] $vals2 = array(); [22:31:36] list( $vals2['old'], $vals2['new'] ) = $params; [22:31:37] LogFormatter::extractParameters might help understand what happens with the parameters [22:32:00] awjr: argh ugly exceptions! I hate them [22:32:12] heh [22:32:51] awjr: I'm heading to bed soon, but feel free to ping me on irc or send email [22:33:07] put your laptop on your bed [22:33:20] I'm unlikely to do any actual work until next week though, I've reached my weekly hour limit [22:33:46] AaronSchulz: who says it isn't already? [22:33:50] ;) [22:34:31] Nikerabbit: thanks. one last quick question - im looking over the different cases that the log event query api will handle and im not sure how to generate log entires for a couple of them, like 'patrol' or 'rights' as i don't really know what those actually map to [22:35:08] Nikerabbit: You're entitled to your weekend :) [22:35:30] awjr: for the log types I have converted, you can find out the ugly parameter handling in includes/logging/LogFormatter [22:35:39] awesome thanks [22:35:49] there is class like PatrolLogFormatter [22:36:39] I had to do quite a bit of detective work for that, and unfortunately I didn't documentat that very well [22:36:58] for other log I haven't converted, the parameters should be exactly the same [22:39:24] AFTv5 is noisy on fatalmonitor atm [22:39:34] Yeah [22:39:51] I'll look at that eventually, I promise [22:40:29] it probably just makes more sense to copy paste them into a bug and make whatever they're called deal with them