[00:53:53] 3MediaWiki / 3Uploading: File extensions should be automatically decided by MIME type at upload - 10https://bugzilla.wikimedia.org/40479#c16 (10Adam Cuerden) My only suggestion here is that, if a filename has a different MIME type to its suggested extension, surely that should be enough for an "are you sure?... [01:17:37] does rillke use irc? [01:18:17] nm, dumb question... [01:32:38] neilk_: He does! [01:32:50] * marktraceur helpful in the face of any question [01:32:57] marktraceur: I left a note on their talk page [01:33:01] Coolio [01:33:06] marktraceur: do we even know if anyone is using Firefogg? [01:33:21] Uhhh, probably not. [01:33:38] yeah. looking at that massive review, that was a question in my mind [01:33:49] Ah [01:33:55] Thinking of just destroying it? [01:33:59] Wait, is it a preference? [01:34:01] rillke made the last substantial edit to Commons:Firefogg ... in 2013 [01:34:27] marktraceur: If I remember correctly it just notices if Firefogg is active (it's a Firefox plugin) [01:34:51] marktraceur: so if you had an mp4 on your desktop that could be converted by Firefogg, in your browser, to something more open. [01:35:03] Ah, right [01:35:09] That's sort of awesome. [01:35:18] I can't believe nobody mentioned that during the MP4 RFC [01:35:26] marktraceur: Firefox only [01:36:19] Actually only three mentions. [01:36:27] neilk_: Firefox only is still pretty good [01:36:38] Given the probability of our uploaders using Firefox [01:36:42] Or being able to. [01:38:46] (03PS1) 10MaxSem: Remove WebVideoJobRunner.php [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/148307 [01:39:50] 3MediaWiki extensions / 3TimedMediaHandler: WebVideoJobRunner silently fails to pick up transcode jobs under HHVM - 10https://bugzilla.wikimedia.org/67973#c3 (10Max Semenik) 5RESO/WON>3RESO/FIX (In reply to Brion Vibber from comment #2) > or might just kill the script. ;) https://gerrit.wikimedia.org/r... [02:34:37] marktraceur: Well, Firefogg seems to still work. My upload stalled at the publishing stage though. [02:53:23] ok, actually the upload totally succeeded the first time. Dunno why it stalled at publish. Perhaps commons is doing a synchronous transcode or something. [04:03:51] marktraceur: re: c68835, this seems like it could be broken up into 4 or 5 changes. The big new thing is UploadWizardUploadList and promises, and then there's a lot of other random stuff that I could approve quickly. [04:04:12] Is it possible to break up a change in gerrit? Or perhaps reduce the scope and submit others? [04:05:40] marktraceur: I can send you the list of stuff to group together [04:05:58] basically I'm looking for gerrit add -p [06:09:11] (03PS6) 10Gergő Tisza: Use image title in history [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/147392 (https://bugzilla.wikimedia.org/67008) [06:09:34] (03CR) 10Gergő Tisza: "Just carelessness, should be fixed now." [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/147392 (https://bugzilla.wikimedia.org/67008) (owner: 10Gergő Tisza) [06:13:51] (03CR) 10Gergő Tisza: "This got merged accidentally (I forgot to restore the -1); Pau is away for a while so Fabrice will ask Jared to do a quick review." [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/146992 (owner: 10Gergő Tisza) [06:27:39] (03CR) 10Jaredzimmerman: "I'm out of office without computer for the next two days then on vacation can you please upload screen shots or send url of test server to" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/146992 (owner: 10Gergő Tisza) [06:51:41] (03CR) 10Gergő Tisza: "Can be tested on the beta site:" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/146992 (owner: 10Gergő Tisza) [06:58:42] (03CR) 10Gergő Tisza: "In theory, neither domready and onload are really the "right" metric since what we are interested in is when the main image finishes loadi" [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/148021 (owner: 10Gergő Tisza) [07:29:09] (03CR) 10Jaredzimmerman: "Doesn't seem to work consistently,…" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/146992 (owner: 10Gergő Tisza) [07:44:21] (03PS4) 10Gergő Tisza: Track loading time for MediaViewer and the file page [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/148021 [07:45:47] (03CR) 10Gergő Tisza: Track loading time for MediaViewer and the file page (031 comment) [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/148021 (owner: 10Gergő Tisza) [07:49:42] (03PS5) 10Gergő Tisza: Track loading time for MediaViewer and the file page [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/148021 [07:53:08] (03PS2) 10Gergő Tisza: Track loading time for MediaViewer and the file page [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/148024 [08:19:56] gi11es: I need stat1001 access to fully deploy dashboard changes, right? [08:26:17] (03CR) 10Gergő Tisza: "Yeah, looks like we don't check the metadata position when switching images. I can fix that; do you think the whole expand-on-open behavio" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/146992 (owner: 10Gergő Tisza) [09:31:53] 3MediaWiki extensions / 3UploadWizard: Sometimes, Learn > Upload .. headings are incorrectly centered - 10https://bugzilla.wikimedia.org/37109#c20 (10Andre Klapper) 5ASSI>3NEW a:5Nischay Nahata>3None (In reply to Nischay Nahata from comment #19) > Not working on this anymore. Resetting assignee very... [10:31:37] 3MediaWiki extensions / 3GWToolset: GWToolset silently wraps some fields into MediaWiki templates, which is problematic - 10https://bugzilla.wikimedia.org/64060 (10Jean-Fred) 5PATC>3RESO/FIX [10:31:37] 3MediaWiki extensions / 3GWToolset: GWToolset silently wraps some fields into MediaWiki templates, which is problematic - 10https://bugzilla.wikimedia.org/64060#c9 (10Jean-Fred) Yes, the GWToolset now gives the option to not wrap. Closing as fixed. [10:52:08] 3MediaWiki extensions / 3CommonsMetadata: License template of the artwork is treated as if it were license template of the image - 10https://bugzilla.wikimedia.org/57465#c3 (10Jean-Fred) (In reply to Tisza Gergő from comment #2) > Probably [[commons:Template:Copyright_information/row]] should add some > mach... [10:52:41] 3MediaWiki extensions / 3CommonsMetadata: License template of the artwork is treated as if it were license template of the image - 10https://bugzilla.wikimedia.org/57465 (10Jean-Fred) [10:52:41] 3MediaWiki extensions / 3MultimediaViewer: MultimediaViewers not crediting Photographer of {{Object photo}} - 10https://bugzilla.wikimedia.org/67860#c4 (10Jean-Fred) Somehow related to bug 57465 [11:21:37] 3MediaWiki extensions / 3MultimediaViewer: The URL should include the special characters like we usually do - 10https://bugzilla.wikimedia.org/68372 (10Gerard Meijssen) 3NEW p:3Unprio s:3normal a:3None the MediaViewer has gives us https://en.wikipedia.org/wiki/Milutin_Dostani%C4%87#mediaviewer/File:M... [12:22:21] 3MediaWiki extensions / 3MultimediaViewer: Media Viewer ignores EXIF rotation - 10https://bugzilla.wikimedia.org/68320#c5 (10Gilles Dubuc) I'm more in favor of the ability to request thumbnails that are the same size as the original. Clearly thumbnail != original even at the same size because of the rotation... [12:27:35] 3MediaWiki / 3Uploading: Generate thumbnails based on buckets - 10https://bugzilla.wikimedia.org/67525#c10 (10Gilles Dubuc) Ah yes, I'll look into PNG closer. If PNG resizing doesn't do any sharpening, that might be the explanation. [13:28:20] (03CR) 10Gilles: Track opt-out ratio (031 comment) [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/143501 (owner: 10Gergő Tisza) [13:31:14] (03CR) 10Gilles: [C: 031] "My only remaining concern before +2ing is the lack of index." [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/148021 (owner: 10Gergő Tisza) [13:49:03] (03CR) 10Gilles: Don't check description validity on keyup (031 comment) [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/148222 (https://bugzilla.wikimedia.org/33607) (owner: 10MarkTraceur) [13:49:53] (03CR) 10Gilles: [C: 031] Remove WebVideoJobRunner.php [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/148307 (owner: 10MaxSem) [14:05:13] (03CR) 10Gilles: [C: 04-1] "Small regression: if you add N files at once, only the first one will have the spinner, until one of the file completes (and suddenly all " [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/68835 (https://bugzilla.wikimedia.org/39746) (owner: 10MarkTraceur) [14:07:54] (03CR) 10Gilles: "I think it might simply be because $.grep has counter-intuitive expectations about the function signature (element first, index second):" [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/146140 (owner: 10MarkTraceur) [14:11:44] (03CR) 10Gilles: [C: 032] Use image title in history [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/147392 (https://bugzilla.wikimedia.org/67008) (owner: 10Gergő Tisza) [14:12:24] (03Merged) 10jenkins-bot: Use image title in history [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/147392 (https://bugzilla.wikimedia.org/67008) (owner: 10Gergő Tisza) [14:14:20] 3MediaWiki extensions / 3MultimediaViewer: Change page title to image name - 10https://bugzilla.wikimedia.org/67008 (10Gilles Dubuc) 5PATC>3RESO/FIX [14:50:41] * marktraceur works from home [15:15:46] (03CR) 10MarkTraceur: "Sorry about that, tgr. In the future, where can I see the discussion that would have led you to -1 the latest patchset?" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/146992 (owner: 10Gergő Tisza) [15:17:02] neilk_: Where did you want to send the list of stuff to split out? [15:17:17] marktraceur: I don't know [15:17:27] (though I'm not convinced that effort is worthwhile, if you're not comfortable pushing this through then I suspect someone else will be) [15:17:35] Hrm [15:17:40] marktraceur: I guess I'll just do it piecemeal [15:17:49] How do you mean? [15:18:29] marktraceur: I'll approve some files. Like, in a few you're just changing docs or whitespace or things unrelated to the big promise/UploadWizardUploadList refacor. [15:18:34] Oh, sure [15:18:34] s/refacor/refactor [15:18:42] anyway review coming this morning [15:18:47] Awesome. [15:19:07] neilk_: Is the big promise-UWUL thing not ready to go, or is it just big enough that you need more time to digest? [15:19:19] marktraceur: it was just really big and I wanted to understand it [15:20:00] marktraceur: one thing that bugs me which is kind of out of scope for a review - the use of $.Deferred [15:21:17] marktraceur: I never tried to use jQuery promises myself as I had heard they were inadequate, so yesterday I delved into why. It seems that there are major issues with it - they basically only work in the "happy" cases [15:21:35] marktraceur: if you want to recover from a failure, it flat out doesn't work [15:22:05] marktraceur: I haven't identified if there are any places in UWUL where we even want that, though, but it seems like one might [15:22:25] Hm. [15:22:32] neilk_: I'm not sure I know what you mean, but OK [15:22:38] marktraceur: here's the shortest example I could find http://jsfiddle.net/jdiamond/raWVh/ [15:23:23] marktraceur: it's four scenarios - one is success/success, that works. However, an exception thrown during success causes a problem; attempting to succeed in recovery from another failure doesn't work [15:23:44] and also "rethrowing" an exception doesn't work [15:23:53] if you want to change the error [15:24:19] Right [15:24:33] anyway the alternative is going to a whole new promises library, which I realize is very difficult. [15:24:45] neilk_: I think I don't throw exceptions, I only reject promises...and yeah, that's not really an option at the moment [15:24:54] We could start the discussion, maybe. [15:24:57] the basic problem is that jquery mutates promises, and every other library creates new ones [15:25:01] maybe it's an issue for a later date. [15:25:29] we can go with this for now. If the issue comes up maybe it can trigger opening a discussion for other promise libs. [15:25:40] should be a drop in replacement [15:25:51] Yeah [15:26:03] I mean, tgr has complained about jQuery's promise implementation before. [15:26:36] We've definitely wanted something different, but given MediaWiki uses jQuery's AJAX libraries, we're stuck interfacing with them until we replace that too [15:27:05] marktraceur: No, that's not an issue [15:27:44] marktraceur: people who use promises a lot are wrapping or transforming promises all the time. The whole pattern is to keep making new ones in your handlers, I don't think we would notice. [15:28:02] Right. [15:28:28] neilk_: I guess the thinking is maybe that loading two separate promise libraries, one for jQuery's AJAX and another for our own stuff, is a bit overkill [15:28:43] anyhow let's somehow put a note in UW's docs that we're aware of the issues with jQuery promises and um... deferring the decision to use a new lib, if ever :) [15:29:24] return promiseLibReplacementDeferred.promise() [15:29:40] marktraceur: yyyeah, that's kinda my issue with the whole promise thing too. Inevitably you end up doing that unless you write all your own code. :( I have been through three libraries over the past year with a node project -- Q, then when, finally bluebird (which is still the fucking bomb IMO) [15:30:29] *nod* [15:30:47] until promises land in a version of JS we can use client-side, in other words, never, we're stuck with that. [15:31:54] ok i am still at home, need to get to the coworking space. ttyl [16:22:01] (03PS2) 10MarkTraceur: Don't check description validity on keyup [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/148222 (https://bugzilla.wikimedia.org/33607) [16:22:45] (03CR) 10MarkTraceur: Don't check description validity on keyup (031 comment) [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/148222 (https://bugzilla.wikimedia.org/33607) (owner: 10MarkTraceur) [16:51:01] (03CR) 10Gilles: [C: 032] Don't check description validity on keyup [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/148222 (https://bugzilla.wikimedia.org/33607) (owner: 10MarkTraceur) [16:51:08] Huzzah [16:51:29] The super fun thing is I can't verify the fix! [16:53:36] (03Merged) 10jenkins-bot: Don't check description validity on keyup [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/148222 (https://bugzilla.wikimedia.org/33607) (owner: 10MarkTraceur) [16:56:17] (03PS1) 10Gilles: Fix length shown in description validation message [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/148410 [16:57:05] marktraceur: what fix? [16:57:35] gi11es: The long description one [16:57:40] I've never been able to reproduce the issue [16:58:09] ah, I didn't realize there was a bug linked to it [16:58:28] seemed like a reasonable thing to do in general for this form [16:58:54] marktraceur gi11es : Do either of you know what’s up with our beta site? I have been trying to log in since yesterday, without success: https://en.wikipedia.beta.wmflabs.org/wiki/Lightbox_demo [16:59:10] Yeah [16:59:20] Uh [16:59:23] * marktraceur looks at beta [16:59:35] "Firefox can't establish a connection to the server at en.wikipedia.beta.wmflabs.org" [16:59:35] fabriceflorin: http://en.wikipedia.beta.wmflabs.org/wiki/Lightbox_demo [16:59:43] DNS issue over SSL, reporting now [17:01:36] marktraceur: Thanks! The Http address works for me on Firefox, but not on Chrome or Safari. http://en.wikipedia.beta.wmflabs.org/wiki/Lightbox_demo [17:01:51] ...weird [17:01:55] I'm debugging in -labs. [17:02:45] fabriceflorin: Maybe your Chrome/Safari try to redirect to https? [17:04:05] If you have HTTPS Everywhere installed, for example. [17:05:03] marktraceur: Chrome does try to redirect to https, then says ‘This webpage is not available [Reload]’. Safari takes me to a partial view of the page, without any of the wiki chrome for Beta Labs (missing nav bars, sidebar, etc.). I can access Media Viewer on both Safari and Firefox. [17:05:18] Weird. [17:05:28] fabriceflorin: Do you in fact have HTTPSE? [17:05:44] marktraceur: I have no idea. What’s HTTPSE? [17:05:51] HTTPS Everywhere. [17:06:04] It's a plugin that forces HTTPS on known sites [17:06:20] I am not aware of setting this plugin on any of my browsers. But it could have been set for me. [17:06:33] OK, probably not, but if you checked that would be nice [17:06:41] Removing one possible culprit [17:06:44] Sure. How can I check? [17:06:54] *shrug* look at your list of browser extensions [17:07:51] I don’t see HTTPS Everywhere in my Chrome extensions. [17:08:00] OK! [17:08:21] Then it's probably not your fault. fabriceflorin, where did you get the link to beta? [17:08:59] marktraceur: It’s the same link I have been using for months now. It stopped working yesterday. Gergo couldn’t get it to work on his machine either. [17:09:16] Weirder. [17:09:29] fabriceflorin: Was it on a wiki page? Just a bookmark? [17:10:09] marktraceur: It’s bookmarked on my browser. [17:10:20] Hrm [17:11:14] fabriceflorin: I'd correct your bookmark, but I'll keep on -labs. [17:11:27] Sure. What’s the correct URL then? [17:11:44] The HTTP one that I gave you [17:12:18] OK, I set that URL on Chrome, but it still doesn’t work on that platform, as reported above. [17:12:20] http://en.wikipedia.beta.wmflabs.org/wiki/Lightbox_demo [17:12:35] Yeah, that's part of my report, we're working on it [17:13:26] fabriceflorin: I'm curious, does http://multimedia-metrics.wmflabs.org/ also forward you to HTTPS? [17:14:00] Cool. Keep me posted. I would like to share a link with the design team, to address gi11es comment about the truncation feature. I also would like to accept your progress bar, but that can wait. [17:14:31] You can just give them the HTTP one [17:14:36] You're the only one with the Chrome issue [17:14:45] AFAIK. If they have trouble too, maybe it's a Mac thing. [17:16:14] Clicking on the metrics link above doesn’t forward to Https for me on any of my browsers. It shows me a blank screen and remains on the link address I clicked on: http://multimedia-metrics.wmflabs.org [17:16:26] K. [17:16:54] Let’s check with tgr when he comes in. He also couldn’t access the beta site last night. [17:17:59] Hm. [17:25:20] fabriceflorin: Can you try clearing your browser cache in Chrome, and loading the HTTP link again? [17:28:19] (03CR) 10MarkTraceur: [C: 032] "Thanks, good catch." [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/148410 (owner: 10Gilles) [17:28:45] (03Merged) 10jenkins-bot: Fix length shown in description validation message [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/148410 (owner: 10Gilles) [17:29:40] * marktraceur tries to fix the bloody removeItem thing [17:29:58] gi11es: I *think* that object equality is broken somehow by passing the array into $.grep [17:30:19] (03CR) 10Gilles: [C: 04-1] Do not run `navigator.getUserMedia()` when not supported (031 comment) [extensions/PronunciationRecording] - 10https://gerrit.wikimedia.org/r/148067 (owner: 10Rillke) [17:30:28] It magically works in a for loop. Not sure if it will magically work in an $.each loop...checking [17:31:14] OK, I just cleared my cache on Chrome, then quit the app and restarted. I still cannot access the https address, but I can access the http address. Note that I obliterated cached images and files, cookies and site plugins, as well as browsing and download history for the last 4 weeks. [17:31:49] You probably could have left the history... [17:32:06] Anyway, I think you got a cached version of a redirect from HTTP to HTTPS, which used to exist [17:32:15] So now I have a workaround. [17:32:23] Chris is investigating WTF happened to HTTPS on betalabs. [17:32:44] fabriceflorin: marktraceur I'm not sure when beta labs stopped listening for HTTPS, but do use HTTP for now. [17:33:12] marktraceur and chrismcmahon : Thanks, I will use HTTP going forward. Much appreciated :) [17:34:43] https is broken for long time on beta and the ssl certificate too (a bit, wrong cert domain) - but it's only beta :) [17:35:52] (03PS6) 10MarkTraceur: Remove UploadWizardUtil, replace with other things [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/146140 [17:36:21] (03CR) 10MarkTraceur: "Oh, duh, that would certainly explain it." [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/146140 (owner: 10MarkTraceur) [17:37:31] (03PS7) 10MarkTraceur: Remove UploadWizardUtil, replace with other things [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/146140 [17:37:38] I hate computers, gi11es [17:37:56] that's the conclusion of the UW refactor? [17:38:07] ah, the $.grep one [17:38:08] No, just the grep signature business [17:38:15] But also yes [17:38:15] yes that's a terrible choice on their part [17:38:26] Gorram it, Krinkle. [17:41:05] I understand the rationale, i.e. most of the time you don't care about the index [17:41:26] but it's the opposite of what's seen in more commonly used functions [17:41:27] Sure, but the same is true of $.each [17:41:47] fabriceflorin: beta labs may be not very usable right now, we have a database issue we're working through besides whatever is going on with HTTPS. just FYI... test2.wikipedia.org might be useful instead... [17:42:29] and now that grep is that way you can't switch it back without a breaking change [17:42:39] Of course. [17:44:52] (03CR) 10Gilles: Remove UploadWizardUtil, replace with other things (031 comment) [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/146140 (owner: 10MarkTraceur) [17:56:57] (03CR) 10Gergő Tisza: "It's my fault, should have at least removed the card from awaiting code review." [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/146992 (owner: 10Gergő Tisza) [17:58:33] (03CR) 10MarkTraceur: "Oh, K. There wasn't even a -1 before, so I was not terribly worried about the prior comments. Hopefully we get it all sorted out :)" [extensions/MultimediaViewer] - 10https://gerrit.wikimedia.org/r/146992 (owner: 10Gergő Tisza) [18:00:33] marktraceur: gi11es: any objections to me trying the hack described in https://gerrit.wikimedia.org/r/#/c/148009/ comments? [18:01:00] None here [18:01:01] go ahead [18:01:04] Hacks on hacks on hacks [18:01:40] I'll see if it can be added to limn properly once I get hold of millimetric [18:02:37] (03CR) 10MarkTraceur: Remove UploadWizardUtil, replace with other things (031 comment) [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/146140 (owner: 10MarkTraceur) [18:04:20] (03CR) 10Gilles: Add a maintinance report about TimedText pages that don't have a file (031 comment) [extensions/TimedMediaHandler] - 10https://gerrit.wikimedia.org/r/147749 (owner: 10Brian Wolff) [18:09:37] (03PS2) 10Gergő Tisza: Remove generated files from source control [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/148009 [18:17:06] 3MediaWiki extensions / 3MultimediaViewer: The URL should include the special characters like we usually do - 10https://bugzilla.wikimedia.org/68372#c1 (10Tisza Gergő) Can you clarify what result you would expect? The MediaViewer URL hash contains the exact same string as the file page URL, so I'm not sure h... [18:22:08] (03PS8) 10MarkTraceur: Remove UploadWizardUtil, replace with other things [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/146140 [18:22:39] (03CR) 10jenkins-bot: [V: 04-1] Remove UploadWizardUtil, replace with other things [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/146140 (owner: 10MarkTraceur) [18:22:43] Oh ffs [18:23:16] (03PS9) 10MarkTraceur: Remove UploadWizardUtil, replace with other things [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/146140 [18:58:07] wow, grep the source for fromURL and there's 17 times where it's tested or set. This looks a lot like it should be refactored. [18:58:27] the source of UploadWizard that is [18:58:40] fromURL is the flag that basically says if we got it from Flickr [18:58:57] The Flickr work is pretty nasty [18:59:07] yeah. we'll get there [18:59:18] I basically just don't touch it [18:59:29] If we change how the wizard works...I guess I'll have to. :( [18:59:45] well, it's just an epic number of 'if fromURL do this, if not do that', which means it really should be a whole other kind of upload, maybe. [18:59:57] i think it's doable with a subclass [18:59:58] Maybe yeah [19:04:50] 3MediaWiki extensions / 3MultimediaViewer: The URL should include the special characters like we usually do - 10https://bugzilla.wikimedia.org/68372 (10Andre Klapper) 5NEW>3UNCO [19:09:50] 3MediaWiki extensions / 3CommonsMetadata: License template of the artwork is treated as if it were license template of the image - 10https://bugzilla.wikimedia.org/57465#c4 (10Tisza Gergő) bug 57259 should now be fixed to the extent that we never mix elements of different licenses into a single fictional lic... [19:14:31] (03CR) 10Neilk: "Logic looks good. Verified it's fine with minDescriptionLength of 0, too." [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/148410 (owner: 10Gilles) [19:17:53] 3MediaWiki extensions / 3GWToolset: Fatal error: Call to a member function getText() on a non-object in php-1.24wmf14/includes/OutputPage.php on line 1296 - 10https://bugzilla.wikimedia.org/68394 (10Sam Reed (reedy)) 3NEW p:3Unprio s:3normal a:3None [2014-07-22 19:14:37] Fatal error: Call to a membe... [19:18:43] stupid question - I can't find the +1 button any more on a particular change. I assume that's b/c the changed was merged into master. [19:18:47] s/changed/change [19:18:50] 3MediaWiki extensions / 3MultimediaViewer: Media Viewer ignores EXIF rotation - 10https://bugzilla.wikimedia.org/68320#c6 (10Tisza Gergő) I suppose tho goal was to save storage space when the thumbnail and the original would be exactly the same. It makes the URL-as-API behavior of the 404 thumbnail handler v... [19:19:27] neilk_: Yeah, that change is in [19:19:38] whatevs [19:24:00] marktraceur: ah, it seems flickr has been disabled for everyone but image-reviewers and admins [19:24:07] Yeah, it always was [19:24:36] marktraceur: nm, it's all a voyage of discovery for me :) [19:25:12] Understandable [19:37:55] 3MediaWiki extensions / 3MultimediaViewer: The URL should include the special characters like we usually do - 10https://bugzilla.wikimedia.org/68372#c2 (10Gerard Meijssen) Try the URL, you will find that what Bugzilla also shows does NOT show like shit from the Commons URL; it has a special c.. Thanks, G... [19:39:27] (03PS6) 10Gergő Tisza: Track loading time for MediaViewer and the file page [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/148021 [19:40:26] (03CR) 10Gergő Tisza: "Forgot to filter NavTiming on action = view." [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/148021 (owner: 10Gergő Tisza) [19:42:29] marktraceur: where is the fabric executable on limn1? I did a find / but it didn't yield anything [19:42:58] Uh [19:43:05] * marktraceur doesn't know [19:45:51] 3MediaWiki extensions / 3MultimediaViewer: The URL should include the special characters like we usually do - 10https://bugzilla.wikimedia.org/68372#c3 (10Tisza Gergő) I'm afraid I have no idea what you are saying. Can you describe how expected and actual behavior differs? See [[mw:How to report a bug]]. [19:46:09] so how do you update it? [19:46:28] "fab xxx" just gives an error for me [19:51:15] I just do manual pulls [20:02:06] 3MediaWiki extensions / 3MultimediaViewer: The URL should include the special characters like we usually do - 10https://bugzilla.wikimedia.org/68372#c4 (10Andre Klapper) No clue either. Please provide clear exact output, screenshots, browser information. For future reference, https://bugzilla.wikimedia.org/e... [20:18:50] tgr: Oh, fabric is meant to run on your machine. Sorry, I totally forgot about that. [20:23:52] 3MediaWiki extensions / 3MultimediaViewer: Special characters in target of mmv url are hex encoded in url bar - 10https://bugzilla.wikimedia.org/68372#c5 (10Bawolff (Brian Wolff)) per discussion on irc: *Go to https://en.wikipedia.org/wiki/Milutin_Dostani%C4%87#mediaviewer/File:MilutinDostani%C4%87.jpg Exp... [20:24:08] tgr: https://gerrit.wikimedia.org/r/#/c/148009/2/post-merge,unified if this is moved to .git/hooks, how is generate.py in the path? [20:24:51] is it just run by default at the root of the git checkout? [20:25:51] 3MediaWiki extensions / 3MultimediaViewer: Special characters in target of mmv url are hex encoded in url bar - 10https://bugzilla.wikimedia.org/68372#c6 (10Mark Holmquist) Is this a Chromium bug, then? [20:26:32] marktraceur: gi11es: And best of all $.grep and $.map have different signatures. [20:26:43] Of course they do. [20:26:43] and $.each and $.map [20:27:02] It's kind of a PHP like dick move. [20:27:24] I expect better from jQuery. Oh well, backwards compatibility and bad decisions in 2009? [20:27:29] 2006 I think [20:27:38] Krinkle: Wait, how are grep and map different? [20:27:58] marktraceur: grep is array_filter, map is array_map. [20:28:21] No, the signatures [20:28:28] key,value vs value,key [20:28:32] I think [20:28:40] http://api.jquery.com/jQuery.map/ [20:28:43] http://api.jquery.com/jQuery.grep/ [20:29:16] right, it's $.each that is different [20:29:21] 3MediaWiki extensions / 3MultimediaViewer: Special characters in target of mmv url are hex encoded in url bar - 10https://bugzilla.wikimedia.org/68372#c7 (10Bawolff (Brian Wolff)) > > * [on chrome] This only happens in path part of url, not fragment, giving a > url like > https://en.wikipedia.org/wiki/Milu... [20:29:25] Mmhmm [20:29:37] proper each, not each(), but jQuery.each [20:29:50] map/grep: Object elementOfArray, Integer indexInArray [20:29:58] each: Integer indexInArray, Object value [20:30:17] Yeah [20:34:14] (03CR) 10Gilles: [C: 04-1] Remove generated files from source control (031 comment) [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/148009 (owner: 10Gergő Tisza) [20:35:41] gi11es: documentation on git hooks is pretty scarce, so I'll have to try and see [20:35:55] but usually they are run from the repository root, yeah [20:36:12] I was goign to, but then saw that the script is still in php [20:36:29] the python script in the other repo should have most of the code you need to convert it [20:36:57] it was converted to python for the same reason [20:40:21] (03CR) 10Gilles: [C: 032] Remove UploadWizardUtil, replace with other things [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/146140 (owner: 10MarkTraceur) [20:40:53] (03Merged) 10jenkins-bot: Remove UploadWizardUtil, replace with other things [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/146140 (owner: 10MarkTraceur) [20:56:35] 3MediaWiki extensions / 3MultimediaViewer: Special characters in target of mmv url are hex encoded in url bar - 10https://bugzilla.wikimedia.org/68372#c8 (10Tisza Gergő) 5UNCO>3RESO/WOR Thanks for the explanation! This should be a bug/feature request for non-firefox browsers. Closing as worksforme since... [21:28:30] (03PS3) 10Gergő Tisza: Remove generated files from source control [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/148009 [21:30:00] (03CR) 10Gergő Tisza: "Ported to python." [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/148009 (owner: 10Gergő Tisza) [21:31:25] alright, let's give this a try [21:31:49] (03CR) 10Gilles: [C: 032 V: 032] Remove generated files from source control [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/148009 (owner: 10Gergő Tisza) [21:33:39] seems to have worked, well done tgr [21:33:58] cool [21:34:16] are you running fabric on limn1? or how does the deploy work? [21:34:32] actually some graphs are broken, but I didn't check before running the deploy [21:34:44] the generated files are definitely there anyway [21:34:57] I'm running fab on my machine [21:35:07] ah, ok [21:35:19] that's how you're supposed to do it, with ssh configured correctly [21:35:28] and it deploys on limn1 via ssh, I get it [21:35:44] yep [21:36:27] the actions graph is definitely broken [21:36:40] netowkr performance is fine [21:37:19] gi11es: What error did you induce in the description step to get that screenshot? [21:37:56] marktraceur: I just picked the 1923 license and it broke by itself that way [21:38:01] Heh. [21:38:16] Fantastic [21:38:23] I'll try naming one of them in a conflicting way maybe [21:39:12] apparently read(10000) was too short [21:39:12] tgr it looks like the actions json files are cut off [21:39:14] I did get an error, but it just re-enabled the description div for that file...and then didn't give me the buttons, lol. [21:39:18] yep [21:39:51] OK, checking. [21:40:42] (03PS1) 10Gergő Tisza: Fix generate.py [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/148511 [21:41:05] (03CR) 10Gergő Tisza: [C: 032] "Self-merge, trivial fix." [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/148511 (owner: 10Gergő Tisza) [21:41:25] gi11es: FWIW I didn't see the spinner issue [21:41:42] 'twas on firefox [21:41:50] Me too [21:42:03] gi11es: Can you check your concurrent uploads preference? [21:42:08] (03CR) 10Gilles: [C: 032 V: 032] Fix generate.py [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/148511 (owner: 10Gergő Tisza) [21:42:27] marktraceur: they'd be the default, I reset my devwiki very recently [21:44:05] tgr: actions graph is back. one thing that bothers me is that these graphs needlessly go back all the way to march 30th, with mostly empty data. was it this way before the changeset? [21:44:20] yes [21:44:28] Hrmmm. [21:45:12] I was wondering about that when I wrote the duration query and looked at other boards to see where they cut off [21:45:22] the action queries don't have a date clause at all [21:45:46] well, the data is clearly cut off at the last 30 days it seems [21:45:48] just not the graph [21:47:26] ah, you're right, the tsv contains a bunch of empty/low values [21:47:28] looks like one of the terms in the union all is not date-delimited [21:47:33] maybe because of that? [21:47:36] yep [21:47:39] that's the cause [21:47:58] I'll fix [21:48:12] the optout stuff, right? [21:48:18] yes [21:51:05] (03PS1) 10Gergő Tisza: Add missing date limit to one of the action UNION ALLs [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/148518 [21:51:46] (03CR) 10Gilles: [C: 032 V: 032] Add missing date limit to one of the action UNION ALLs [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/148518 (owner: 10Gergő Tisza) [21:54:07] gi11es: I think https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/735 is good to go then [21:54:20] it was blocked on the JSON generation issue [21:57:11] https://gerrit.wikimedia.org/r/#/c/148006/ and https://gerrit.wikimedia.org/r/#/c/143501/ ? [21:57:52] yes [22:19:56] (03CR) 10Gilles: [C: 032 V: 032] Track opt-out ratio [analytics/multimedia] - 10https://gerrit.wikimedia.org/r/143501 (owner: 10Gergő Tisza) [22:20:31] tgr: https://gerrit.wikimedia.org/r/#/c/148006/ needs rebasing, it modifies generate.php [22:24:26] (03PS3) 10Gergő Tisza: Track opt-out ratio [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/148006 [22:32:31] (03CR) 10Gilles: [C: 032 V: 032] Track opt-out ratio [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/148006 (owner: 10Gergő Tisza) [22:42:06] 3MediaWiki extensions / 3TimedMediaHandler: ?embedplayer=yes videos broken (again) - 10https://bugzilla.wikimedia.org/66143#c20 (10Tilman Bayer) (In reply to Bawolff (Brian Wolff) from comment #18) > > > > Yes, it was changed as a workaround for this bug last week. But that's > > actually the way we most of... [23:06:44] (03PS1) 10Gergő Tisza: Fix JSON breakage [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/148538 [23:07:42] (03CR) 10Gergő Tisza: [C: 032] "Self-merge, trivial fix." [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/148538 (owner: 10Gergő Tisza) [23:08:02] how I hate JSON comma syntax [23:09:35] +1 [23:15:51] 3MediaWiki extensions / 3MultimediaViewer: Special characters in target of mmv url are hex encoded in url bar - 10https://bugzilla.wikimedia.org/68372#c9 (10Gerard Meijssen) Created attachment 16007 --> https://bugzilla.wikimedia.org/attachment.cgi?id=16007&action=edit expected URL [23:18:36] 3MediaWiki extensions / 3MultimediaViewer: Special characters in target of mmv url are hex encoded in url bar - 10https://bugzilla.wikimedia.org/68372#c10 (10Gerard Meijssen) Created attachment 16008 --> https://bugzilla.wikimedia.org/attachment.cgi?id=16008&action=edit The URL with a malformed string Thi... [23:18:50] 3MediaWiki extensions / 3MultimediaViewer: Special characters in target of mmv url are hex encoded in url bar - 10https://bugzilla.wikimedia.org/68372 (10Gerard Meijssen) 5RESO/WOR>3REOP [23:21:32] (03CR) 10Gergő Tisza: [C: 032] Fix JSON breakage [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/148538 (owner: 10Gergő Tisza) [23:21:56] (03CR) 10Gergő Tisza: [V: 032] Fix JSON breakage [analytics/multimedia/config] - 10https://gerrit.wikimedia.org/r/148538 (owner: 10Gergő Tisza) [23:24:25] does anyone else find mediawiki-vagrant to be very slow? Like, tens of seconds to respond to anything. I'm wondering if there's some cache that it's waiting for, but is not active. [23:25:11] neilk_: are you using linux? [23:25:17] tgr: yes [23:25:33] it works OK for me [23:26:07] tgr: I'll fiddle with cache settings, maybe this will help. Posted something on Ori's page for now. [23:26:45] in my non-mediawiki-related experience, when it is slow, that's usually caused by the folder sharing between host and guest [23:27:15] but for linux/linux that's NFS and shouldn't be that bad [23:27:57] tgr: Oh, my host OS is Mac OS X. [23:28:12] tgr: I was wondering why you would ask when it comes to vagrant. [23:28:18] no clue about that [23:28:31] but you could check how the sharing is set up [23:29:01] if NFS does not work, vagrant falls back to some virtualbox-specific method which has horrible performance [23:29:09] tgr: I doubt that's the issue as it's super quick when I'm sharing files in the shell. It would be impossible to ls -la if that were the case [23:29:58] tgr: but, it's a reasonable suspicion. I'll see if I can tell [23:30:54] neilk_: Tried profiling? [23:31:01] mediawiki that is [23:31:53] bawolff: that's probably the thing I should be doing [23:32:16] bawolff: you mean $wgDebugToolbar or real profiling? :) [23:32:44] I was just thinking the former [23:33:34] (Or I was actually thinking the thing where it just dumps profiling info in an html comment, as that's what I use as I set it up years ago before $wgDebugToolbar was a thing. $wgDebugToolbar is probably nicer) [23:33:52] tgr: I have actually seen the same issue with databases shared in virtualbox, but AFAIK this shouldn't be an issue since logging and dbs are in /var (which was the fix I applied to my other projects) [23:34:23] but this is more like wait, wait, wait, wait, suddenly everything is fast. [23:34:29] feels like a cache miss [23:34:49] s/miss/timeout/ [23:35:10] redis down, maybe? [23:36:21] tgr: that was my first guess but it's there [23:36:34] is redis the new memcache? :) [23:37:12] only for vagrant ;) [23:39:05] 3MediaWiki extensions / 3MultimediaViewer: Special characters in target of mmv url are hex encoded in url bar - 10https://bugzilla.wikimedia.org/68372#c11 (10Tisza Gergő) Again, you should report this to your browser vendor. The URL follows the standard method of encoding non-ASCII bytes, and including them... [23:43:35] 3MediaWiki extensions / 3MultimediaViewer: Special characters in target of mmv url are hex encoded in url bar - 10https://bugzilla.wikimedia.org/68372#c12 (10Gerard Meijssen) Why then is there a difference between how Commons does things and how the Multi Media Viewer does it... Consistent behaviour may be e... [23:45:53] 3MediaWiki extensions / 3MultimediaViewer: Special characters in target of mmv url are hex encoded in url bar - 10https://bugzilla.wikimedia.org/68372#c13 (10Tisza Gergő) Because some browsers treat percent-encoded characters differently in the path/query part and the fragment part of the URL. As can be seen... [23:46:26] neilk_: One thing I changed in my vagrant setup that seemed to make things faster is moving the message cache to APC. `$wgMessageCacheType = CACHE_ACCEL; $wgLocalisationCacheConf['store'] = 'accel';` in a file like settings.d/10-apc-messages.php [23:47:27] bd808: thanks, I'll check it out. At the moment I've determined that load.php (the resource loader thing) is taking 11 seconds to do its thing, every time. [23:47:43] yuck [23:47:45] bd808: doesn't explain why API calls are problematic too but maybe it's related [23:47:49] If you set $wgCacheDirectory to somewhere writable, localization cache will use that, and it should make things faster [23:48:09] 3MediaWiki extensions / 3MultimediaViewer: Special characters in target of mmv url are hex encoded in url bar - 10https://bugzilla.wikimedia.org/68372#c14 (10Gerard Meijssen) As can be seen by the screenshots (from the same browser & the same session) this is not the case. Thanks, GerardM [23:49:20] bawolff: huh, oddly, there is a /var/cache/mediawiki set up but it's not being used. [23:51:09] hah, I think I've even seen this before, in production. :) [23:51:42] once upon a time, ResourceLoader had problems with a very large javascript bundle called UploadWizard. Would time out on bundle compilation, every time, and then every invocation of the page failed. [23:51:50] 3MediaWiki extensions / 3MultimediaViewer: Special characters in target of mmv url are hex encoded in url bar - 10https://bugzilla.wikimedia.org/68372#c15 (10Bawolff (Brian Wolff)) (In reply to Gerard Meijssen from comment #14) > As can be seen by the screenshots (from the same browser & the same session) >... [23:51:51] so, a huge waste of CPU and everyone's time. [23:52:15] bawolff: I think that did it. It took two tries for resourceloader to cache everything though. [23:54:36] 3MediaWiki extensions / 3MultimediaViewer: Special characters in target of mmv url are hex encoded in url bar - 10https://bugzilla.wikimedia.org/68372#c16 (10Bawolff (Brian Wolff)) Could media viewer just not urlencode the fragment? I suspect that's allowed in html5, and chrome seems to handle it fine.