[02:58:10] What's the code review backlog status? [17:55:53] robla: about? [17:56:16] hi there....on a call right now [17:56:41] robla: sorry, completely lost track of time as I ended up going to my parents... [17:56:52] Just about to have dinner [17:57:35] I should really calendar this [18:00:07] robla: I'll be back in half an hour... Not sure when is going to be best for you. I can stay here and talk, or if you want to leave it till a bit later, I'll probably head back to uni (about an hour) [18:00:26] robla: If you drop me an email with what's best, I'll hopefully speak to you later [18:02:11] morning Roan [18:02:27] Morning [18:02:55] We were supposed to deploy 5 mins ago, right? [18:03:18] yes, we're scheduled to deploy now. Not timed to the second though ;) [18:03:44] s/Morning/Evening/; [18:04:46] Crap, the dishwasher's leaking [18:04:52] Lemme handle that real quick [18:05:15] no worries. [18:08:01] OK, back now [18:08:17] The dishwasher's drainage is leaking, can't figure out where until it drains water again [18:08:23] In the meantime, let's roll [18:09:25] flipzagging: OK, so trunk of extensions/UploadWizard ? [18:10:24] Hey [18:11:14] You might already know but I'm seeing an error on wikipedia mobile site :(http://www.flickr.com/photos/10293570@N00/5204831354 [18:11:29] ^screenshot [18:11:44] Hah Ryan_Lane mentioned that [18:11:49] Including the strange path in the error message [18:12:03] Glad you are aware [18:12:15] I'll call Hampton [18:12:22] It worked okay earlier [18:12:29] Thanks [18:12:59] RoanKattouw: sorry, talking to Guillaume about last minute stuff [18:13:18] RoanKattouw: yes, we want trunk of extensions/UploadWizard, and a corresponding include in LocalSettings.php [18:13:31] OK, any settings needed other than the require_once() ? [18:13:59] nope, on commons.prototype.w.o/uwd/ that's all we have [18:14:15] Resource Loader is not available in any way on our live site, I assume? [18:14:21] Or actually, maybe someone else should call Hampton, I'm busy now [18:15:54] Nope, no RL on the live site [18:16:06] ok, I assumed as much [18:16:28] if it is there, UW automatically switches over to use it, unless another boolean flag is set. [18:22:29] flipzagging: window.mediaWiki is undefined in window.mediaWiki.addMessages( .. ); [18:22:49] Although... that might be my fault, hang on [18:22:50] again. [18:23:00] Sorry, I didn't solve that issue last night. :( [18:23:36] Yeah, ignore that [18:23:45] It's 404ing on combined.min.j [18:23:47] s [18:25:23] huh [18:25:46] Not any more [18:25:48] That was my fault [18:25:53] God ms4 (thumbs server is slow) [18:26:03] It was serving me the licensing tutorial at a few kB/s [18:26:12] And that's a 250K file [18:26:33] that's special [18:26:38] flipzagging: Next button above licensing tutorial? :P [18:26:48] DId someone add this? [18:26:53] What's special? [18:27:12] 250K at a few kB/s I mean [18:27:31] Maybe I was just hitting it at its worst moment [18:27:34] RoanKattouw: re: the next button, that's marked as an enhancement, but they may lynch us if I don't add that [18:27:36] ms4 had issues in the past [18:27:51] RoanKattouw: can we see this? what's the URL? [18:28:06] http://upload.wikimedia.org/wikipedia/commons/thumb/b/bb/Licensing_tutorial_en.svg/720px-Licensing_tutorial_en.svg.png [18:28:10] May load faster for you though [18:28:18] RoanKattouw: I mean the whole page [18:28:23] Thinking about it, the upload Squids in AMS could be responsible [18:28:35] http://test.wikipedia.org/wiki/Special:UploadWizard [18:30:26] ruh roh, this is not working. [18:30:34] I'm getting a perpetual spinner [18:30:55] yes, the API call to get info about the file fails. [18:31:00] Did you fix the duplicate-upload-causes-perpetual-spinner bug yet? [18:31:02] and I guess I'm not catching that error properly. [18:31:12] I haven't fixed that but that's not the issue this time. [18:31:22] BTW, scroll to top is annoying with the Jimbo banner up there [18:31:33] Yes [18:31:47] I'll fix that to scroll to top of wizard div [18:32:23] The API call isn't failing: http://pastebin.com/CLcaa1kH [18:32:29] Exactly what are you using to decode JSON? [18:32:44] I'm noticing a trailing \n in the JSON output, it could be that JSON parsing chokes on that [18:32:51] (Decode JSON for the API action=upload return I mean) [18:32:58] Are you talking about bug 26076 ? [18:33:07] RoanKattouw: I know what the error is [18:33:14] (since you're talking about perpetual spinner and failing to get file info) [18:33:16] or rather I know the KIND of error it is [18:33:41] hey roan. isn't it, like, your birthday or something? [18:33:44] I removed all path info from errors, but it's complaining that there's a "bad path" in the session. [18:33:55] jorm: Tomorrow [18:33:56] I just don't know what that bad path is. [18:33:58] Okay. [18:34:13] RoanKattouw: you have some trick to snoop on the contents of sessions? [18:34:20] flipzagging: Of course :) [18:34:27] Can you tell me what's in mine? [18:34:30] guillom: Probably, except we were never able to reproduce that on the prototype server [18:34:41] I can if you PM me the contents of your testwiki_session cookie [18:35:00] Ok; 'cause I can reproduce it every time I try :) [18:35:07] And I couldn't [18:35:20] Although I haven't tried this week [18:37:18] guillom: by reproduce you mean if you upload a new file you get that problem, or the same one? [18:37:27] reuploading is broken, I know that [18:37:41] I get that problem even with new files. [18:37:53] (new content, new name) [18:37:59] okay, I may want to examine your computer and see what's going on [18:38:03] ok [18:38:08] actually, we should do that later today. [18:38:56] flipzagging: http://mediawiki.pastebin.com/Wd4YT1HJ [18:39:13] That's $_SESSION['wsUploadData'] [18:40:11] RoanKattouw: ok, so can you figure out where LocalRepo temp images are stored? [18:40:18] in general they are in $IP/images/temp [18:40:43] Yes, I know where they are [18:41:11] Need me to examine a given file? [18:42:32] So do we have a file that corresponds to temp/e/e6/20101124183211!phpO2cZaD ? [18:42:42] be careful there's a bang in that path, use single quotes [18:43:12] /mnt/upload6/wikipedia/test/temp/e/e6/20101124183211!phpO2cZaD [18:43:17] Yup that's there [18:43:23] all right. [18:43:31] /mnt/upload6/wikipedia/test/temp/e/e6/20101124183211!phpO2cZaD: JPEG image data, JFIF standard 1.01 [18:43:46] I don't know what the issue is then, and I've arranged things so it's not possible to know from the client side exactly what file is causing this. [18:43:55] Let me see if I was smart and added something to debug log [18:44:50] Could it have to do with the file being extension-less [18:44:52] ? [18:44:56] no. [18:46:00] okay, it happens on thumbnail creation, that's the issue. [18:46:23] OK, do you have a file path to the thumbnail? [18:46:52] no [18:46:58] it throws that away. [18:47:12] I'm going to add a quick fix, can you read the debug log on test? [18:47:15] OK well that shouldn't matter anyway [18:47:24] You mean wfDebug() ? [18:47:27] I can derive the thumb path [18:48:06] let's just debug what the computer is doing, not what we imagine it to be doing [18:48:24] OK the thumbnail definitely isn't there [18:48:43] Ooooh and I think I may know why [18:48:56] Deferred thumbnail generation through a 404 handler, dammit [18:49:01] Why didn't I think of that before [18:49:05] ...? [18:49:15] I explicitly say to generate the thumbnail now [18:49:22] at least I used to, maybe I got lazy [18:50:03] yup, $flags |= self::RENDER_NOW; [18:50:25] Ah yes [18:50:34] OK so [18:50:38] What is the *exact* error you see [18:50:43] Exception type plus any message [18:50:52] Cause there are BadPathExceptions with different messages [18:50:58] Roan. [18:51:02] I am way ahead of you here ;) [18:51:08] I am already debugging the right part. [18:51:12] anyway [18:51:14] {"error":{"code":"siiinvalidsessiondata","info":"Bad path: path doesn't exist"}} [18:51:29] the problem occurs because it tries to transform the file, with a RENDER_NOW. [18:51:42] it returns a ThumbnailImage, but the path in that ThumbnailImage doesn't exist. [18:51:50] or, perhaps something else is wrong with it. [18:52:22] Well the thumbnail isn't there, I can tell you that [18:53:06] okay I have a fix which will dump more data to debug log. [18:53:14] let me test it and then I'll commit it and you can check it out? [18:53:17] Lemme see if I can access that [18:53:52] hah, I can [18:56:20] flipzagging: Yes, go for it [18:57:33] RoanKattouw: svn up [18:57:46] I see it [18:58:28] you mean you already tried uploading? [18:58:57] anyway this should dump a debug message prefixed with UploadStash in two cases -- where it can't stash the file, and whenever we generate a thumbnail [18:59:10] the thumbnail will generate a big dump so if you could pastebin that it would be the awesome. [19:02:42] OK sorry, got distracted [19:02:45] Will put that code in now [19:03:32] sure [19:09:43] afk for a few mins [19:12:24] RoanKattouw: how's that going? [19:13:51] Almost done [19:13:59] wow, merging is painful [19:17:41] Nah, helping my brother with math in the meantime [19:20:01] I am now finally running svn up [19:20:12] OK [19:20:25] I'm following the test.wp debug log, hit it [19:21:24] flipzagging: ---^^ [19:21:39] ok [19:21:47] is there any way I can do that with you? [19:21:58] oh I see you want me to upload something [19:22:04] Yes, reproduce the error [19:22:10] And I'll get you the debug log exceprt [19:22:46] RoanKattouw: ok, done [19:23:04] Got it [19:23:09] Lemme archive that into my ~ [19:24:46] AHA: Error creating thumbnail: /home/wikipedia/common/wmf-deployment/bin/ulimit4.sh: line 4: /usr/bin/convert: No such file or directory [19:24:53] You can't do RENDER_NOW on a non-scaler machine [19:25:12] ok [19:25:38] so, what would you recommend here -- actually it might work with RENDER_NOW since there is also code to render on 404 [19:25:46] s/work with/work without/g [19:26:03] oh wait though... [19:26:03] There is code to render on 404 but not for Special:UploadStash URLs [19:26:06] hm [19:26:17] no, I wrote code to render on 404 for Special:UploadStash [19:26:28] ^ [19:26:33] Yeah I think I saw that code once [19:26:35] but it would rely on convert being installed, or the iMagic lib. [19:26:43] Still, that'll only work on a scaler [19:26:44] which is the same thing, just deferred. [19:26:48] all right [19:26:55] The way it currently works is there's a 404 handler on upload.wm.o [19:27:09] right [19:27:34] ok, the current problem is that there is no convert or Imagick lib on regular commons.w.o server. [19:27:48] obvious problem in retrospect, should have documented the dependency. [19:28:06] is there a way to get a file scaled but not stored via the scalers? [19:28:20] or, is there a way to get convert or Imagick installed? [19:28:56] Not right now [19:29:03] I need to pull Ariel into this discussion [19:30:18] are you messaging? [19:30:55] if your brother needs help with math again, I can do that [19:30:57] :) [19:31:02] haha [19:31:04] I'll poke Ariel [19:32:35] all right, so, RoanKattouw [19:32:58] are there any good odds of installing convert on our commons servers? [19:33:08] if not, this deploy is toast [19:33:50] the other option might be to write something for the scalers whereby one could (for instance) POST data to it and receive a scaled image back as response [19:34:04] Well we'd tell it to create the thumb [19:34:27] *RoanKattouw wonders whether the temp dir is exposed on HTTP [19:34:59] or, the other other option is to store all this stuff in the same way as everything else, so thumbnails work in that way too, but then we abandon the entire strategy of keeping it private. [19:35:10] hah! http://upload.wikimedia.org/wikipedia/test/temp/e/e6/20101124183211!phpO2cZaD [19:35:20] Not so private now :P [19:35:28] yeah, but the user doesn't know what the filename is. [19:35:34] (Granted it serves the wrong content type, but well) [19:35:38] True [19:36:14] but, it does suggest that we could somehow tell the scaler what that URL is, to fetch data. [19:36:19] scale-by-URL. [19:36:29] But the whole restricted-to-session thing.. hm [19:36:32] Yes [19:36:34] We totally could [19:36:49] it's based on obscurity, these filenames (should be) impossible to guess [19:37:01] But.... these files need to no longer be extensionless [19:37:03] and you never see the ids that the server is managing [19:37:07] That's true [19:37:10] yeah [19:37:12] The user has no way of guessing the URL [19:37:28] the extensionless thing is just for consistency [19:37:29] ...until we give them the thumb URL :P [19:37:35] Yeah well the web server doesn't like it [19:37:47] It needs the .jpg ext to serve it with Content-Type: image/jpeg [19:38:07] previously these files were only served via UploadStash which added the right headers. [19:38:08] I know.