[00:11:45] sending a calendar invite right now, if Jerome can't make it we'll try and find another slot [00:25:33] DarTar: are you Dario Taraborelli? [00:30:05] bawolff: yes I am [00:30:16] ok cool :) [00:30:46] thanks for your help with DPL [00:30:51] no problem [00:32:10] just saw your response, I hadn't thought of the {{CURRENTHOUR}} trick [18:15:09] hi Reedy, other than the diff problem you pointed out, how are things on the RC front? [18:55:43] robla, I've been offline for most of the day. Diff problem is still the same. Might be worth asking if any of the other ops people have experience. IIRC apergos uses python for some of the dump stuff, and diff'ing is somewhat related... [18:56:15] ? [18:56:59] From the script used for creating the release tarballs, i uses subprocess.Popen (i think) to shell out to do a folder diff [18:57:08] diff -Nru -x messages -x *.png -x *.jpg -x *.xcf -x *.gif -x *.svg /home/reedy/build/mediawiki-1.18.0beta1 /home/reedy/build/mediawiki-1.18.0rc12diff failed, exiting [18:57:14] When we attempt to redirect STDOUT/STDERR it seems to get upset and not like it [18:57:25] Dropping those bits of redirection, the command works fine and just dumps the diff to console [18:57:46] (I'm watching the nyc cops raid the gathering in the park [18:57:57] the media can't get in, they've been blocked off too [18:58:08] reuters is streaming one of the ows folks' live streams [18:59:11] apergos: What park are they raiding now? [18:59:24] Zuccotti [18:59:31] gathering before a 5 pm action [18:59:37] Again? [19:00:35] yes again [19:00:38] that's what cops do [19:00:49] robla, the other thing is whether we care too much about this flapping test on 1.18 [19:00:51] (sorry notpeter, I know you have a different position, but this is the job they are paid to do) [19:01:05] Reedy: flapping test? [19:01:19] "ExifRotationTest::testRotationRenderingNoAutoRotate.testRotationRenderingNoAutoRotate with data set #1" [19:01:23] It seems to have decided to break itself [19:01:25] Fails intermittently [19:01:30] Always has I think [19:01:40] Or, well, not sure whether it fails on trunk [19:01:43] I know hashar fixed a flapping test on trunk [19:01:43] hexmode: ready in a bit...want to finish this convo [19:01:54] But I remember it flapping on trunk, then the rev was merged, then 1_18 started flapping too [19:03:10] (in case it wasn't noticed:) Can someone help me with the no-thumbnail problem I've described in #wm-tech? ;) [19:05:22] Reedy where is the actual script? [19:05:44] http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/make-release/ [19:05:50] ok lemme look [19:06:37] Reedy: flapping problem probably not an RC blocker, if I understand it properly [19:06:45] Indeed [19:06:52] It was more because hexmode mentioned it earlier [19:07:30] Lines 168 onwards of make-release [19:07:45] note I wasn't saying it was a blocker ;) [19:07:45] [19:08:01] Yup [19:08:04] Worth mentioning though [19:08:47] Reedy: any other blockers? [19:08:56] Nothing I'm aware of [19:09:01] Not checked BZ today [19:09:35] You might have seen that I deleted the tag to get in 1 more rev cause it caused fatals on the block list [19:10:43] I like bugs where you know what the problem is without looking at the code [19:11:49] I CCed you on the one blocker I saw today, and you fixed it [19:11:57] Yeah that oen [19:14:46] Reedy: I ran a standalone test based on the makePatch function and a couple files only [19:14:50] it worked fine [19:15:02] but wait you said something about redirects [19:15:25] diffProc = subprocess.Popen(args, stdout = subprocess.PIPE) [19:15:25] gzipProc = subprocess.Popen(['gzip', '-9'], stdin = diffProc.stdout, stdout = patchFile) [19:15:51] with the stdout line set on diffProc, it doesn't work for me [19:15:55] yes. that's what I have and it worked for me [19:16:03] right out of trunk [19:16:20] I did not try it on large dirs, I set up a couple simple dirs for a test case [19:16:38] yeah, the diff command works fine standalone, so I don't think it's the target at fault [19:16:43] no I mean [19:16:52] I ran maktPatch and fed it some boring args [19:16:56] *makePatch [19:17:04] and it worked fine as is, with the test args [19:17:49] have you tried giving it smaller subdirs to see if those work? [19:18:45] /home/reedy/build/mediawiki-1.18.0rc12/includes/specials and /home/reedy/build/mediawiki-1.18.0rc12/includes/speacials [19:18:49] er specials [19:18:51] for example? [19:19:24] Nope. But if i remove "stdout = subprocess.PIPE" from the command, the diff works fine, and just spews it all to screen/the console [19:20:53] Same thing on includes/specials [19:20:57] I just ran it against blahblah/includes/specials for two different versions. worked fine [19:21:01] then it's you [19:21:14] I tried it on 11.10 and 10.04 (ie formey) [19:21:17] it writes a compressed patch [19:21:18] Are you running the command as root? [19:21:27] no, I'm on my laptop [19:21:41] http://pastebin.com/mYsKH7mB is what I get [19:21:59] for http://pastebin.com/GCFrpArJ [19:22:34] gzip? [19:22:56] try giving a full path to gzip [19:23:46] on the open command? [19:24:37] what host are you on? [19:24:46] I'm doing it on a local VM [19:24:46] formey [19:24:50] meh [19:24:55] where is gzip in your vm? [19:25:06] cause it just doesn't find it, right [19:25:18] but I tried it on formey, just to check it wasn't anything simple [19:25:21] /bin/gzip [19:25:43] in the example I pastebinned, I'd tried entering that rather than just leaving it to $PATH [19:25:56] uh huh [19:28:05] with it working straight off for you, it almost seems like a missing dependancy (for python), or some other config esk issue [19:29:18] Back in a few [19:33:45] god typehead on fenari sucks right now [19:34:00] so I just ran it on fenari with the command being fed in as some other thing, it found gzip fine [19:34:55] steal the file /home/ariel/incoming/testit.py change the paths as you like, you're running "cat blot" and feeding it to the gzip so make sure there's some file blot with short-ish content you recognize [19:34:57] then try it [19:35:01] ( Reedy ) [19:58:14] apergos, ok, so that works fine on fenari, but doesn't locally [19:58:52] so now you get to find the missing piece locally [19:59:07] obviously you can cut out a lot of cruft if that helps [19:59:12] (form the script) [19:59:25] gzip is the same version.. python 2.7.2+ locally, 2.5.2 on fenari [20:01:25] If python is at fault, it's between 2.5.2 and 2.6.5 [20:02:52] greeeat [20:02:54] hmm wait a sec [20:03:21] Hopefully, you trying the same on formey will result in the same [20:03:36] annoyingly there is 2.6 packaged python for ubuntu, but no 2.5.. that'd have been a simpler workaround [20:05:47] it's not python [20:06:01] I'm on sn3 with python 2.5.2 [20:06:07] successful run of my test script [20:09:24] ran on formey (as root) [20:10:02] from /root ran python testitformey.py (after copying the script to incoming/blot so there was something to compress) [20:10:09] ran ok [20:13:25] hi ryan [20:13:30] howdy [20:13:33] hi there [20:13:40] how is new orleans? [20:13:49] great [20:13:57] Reedy: please ping me if it doesn't look like you'll be able to get the RC out today [20:14:06] Dario and I have been revamping the Oauth proposal at http://www.mediawiki.org/wiki/OAuth [20:14:23] robla, as per the email, I can do the diff manually and zip it, just be nice to get the automated way fixed [20:14:51] Reedy: did you get my mail re the API request limit issue? Are you the right person to handle this? [20:14:54] so what is your local vm missing? [20:15:06] Reedy: yup, understood. Go ahead and debug for a while, just don't let it stop you from getting done today [20:16:27] Ryan: maybe you can have a look at it and let us know what you think.... [20:16:40] lemme read it really quick [20:20:27] looks good to me [20:21:16] it would be useful to have your take on the data model and on the implementation (would this be core? extension?) [20:21:17] dvanliere, DarTar: now we just need to find someone to implement it :D [20:21:28] :D :D [20:21:29] extension, with hooks in core [20:21:32] imo [20:21:49] also, there are several PHP OAuth lib out there, I am not sure whether we should recommend building on a specific implementation [20:21:58] SAML also provides functionality like this, for instance [20:22:12] oauth2 functionality? [20:22:16] so hooks calling to an extension is better, so that we can support different authz implementations [20:22:27] yes [20:22:27] makes sense [20:22:36] oauth and openid are really kind of shitty protocols, overall :) [20:22:46] are there performance differences between core and extension? [20:22:48] SAML is better, but is more strict [20:22:55] not really [20:23:01] most things are implemented as extensions [20:23:12] i think oauth2 is a big step forward compared to oauth1 [20:23:19] yeah [20:23:31] oauth isn't bad, it's just not as good as shibboleth and saml :) [20:23:41] how many hours would it take to develop such an extension? [20:23:43] but saml isn't terribly appropriate for the internet [20:23:49] no idea. [20:23:54] (roughly) [20:24:07] I'd imagine 40-80 minumum [20:24:18] that's a total guess, thouh [20:24:20] plus we need to work with OAuth-ready client services, which I assume are still a majority? [20:24:35] well, if we provide the service, the clients will come [20:24:47] we have a number of internal projects that would *love* to have oauth [20:24:48] I would not want support oauth1, just skip it [20:25:02] oauth2 requires https, right? [20:25:08] I think so [20:25:08] I know a number of external projects that would also love it [20:25:16] but we are https :) [20:25:20] yeah [20:25:31] we don't *require* https for logged in actions, though [20:26:10] but oauth2 only requires that the token exchange happens through ssh i think [20:26:25] apergos, hmm, poking it further, it doesnt' seem to like doing the root of phase3 for some reason. But doing "diff -Nru -x messages -x *.png -x *.jpg -x *.xcf -x *.gif -x *.svg -x *.tiff /home/reedy/build/mediawiki-1.18.0beta1 /home/reedy/build/mediawiki-1.18.0rc1" works [20:26:28] so Ryan_Lane: other than making an estimate of the resources needed, what would it take to turn the proposal into an actual call for contractors? [20:26:30] yeah. for clients that don't support https, it could be problematic [20:26:43] DarTar: ah. hiring a contractor for this is a good ide [20:26:46] *idea [20:26:48] that is really bizarre [20:26:59] DarTar: I'd talk to robla about that [20:27:08] that'd be awesome [20:27:09] an SSH certificate does not cost that much these days [20:27:10] so if you run my little test script in your vm, it fails or it works? [20:27:10] this feature falls under his team [20:27:20] s/SSH/SSL/ :) [20:27:28] whoops [20:27:42] we already have SSL certs, so that's not a big deal [20:27:42] I think brion was also interested in this (he made one of the few early edits to the mw:OAuth page) [20:27:56] robla: are you around? [20:28:04] for 3rd party services, they can buy certs, yeah [20:28:14] authentication/authorization over http is just a bad idea [20:28:15] he just took off to grab lunch [20:28:25] people can get free ssl certs, in fact [20:28:35] thinking of that, I need to do that on my personal server :) [20:28:53] argggh [20:29:01] ? [20:29:58] slight overreaction that we just missed robla :) [20:30:08] brb [20:30:21] but i like the idea of hiring an external contractor [20:30:27] I think he'll be back soon [20:30:30] ok [20:32:08] dvanliere: "Can manage authorization to third parties from the OAuth provider (ie MediaWiki)" please fix it :p [20:32:48] ? [20:33:12] oh that is copy and paste from other doc :) [20:34:03] done [20:37:30] apergos, seems it hates something in the tests folder [20:37:45] so interesting [20:38:12] *.xmp [20:38:16] Bleugh [20:38:28] Right then [20:38:30] let's see [20:38:34] which file? [20:38:38] back [20:39:02] mediawiki-1.18.0rc1\tests\phpunit\data\xmp [20:39:11] dvanliere: good write up [20:39:16] on oauth, btw [20:39:25] we also need to consider extensions, though [20:39:41] like the api, extensions need a way to handle this too [20:39:56] ryan: can you expand on this? [20:39:59] since most of our functionality is actually handled via extensions [20:40:23] take openstackmanager extension, for instance [20:40:43] if I wanted to extend some capabilities via the api, I'd also like that to work with oauth as capabilities [20:40:50] good point [20:41:09] so, the extensions need to be able to advertise their capabilities, like the rest of the software [20:41:22] and need to be able to handle the authz portion as well [20:41:57] *DarTar wondering to what extent this will make it hard for the user to grant authorization [20:42:29] as each extension will have specific actions + resources + privileges attached to it [20:44:15] that's some food for thought [20:45:14] is that a must-have for V1? [20:45:24] so there would be complex usability/UI issues for the authorization screen, but does this also imply major changes in how extensions expose what they do in MW? [20:45:42] or something that we want to put on the roadmap? [20:46:07] ummmhhh how do extensions expose what they do? [20:46:16] well, if all the interesting functionality is handled by extensions you'd probably want to support this as soon as possible [20:46:29] yes. it's a must have for V1 [20:46:48] usually external applications request specific rights [20:47:08] so, as long as the extensions have some mechanism of advertising them, it shouldn't be terribly hard [20:47:35] but is there a standardized mediawiki way of advertising functionalities? [20:48:10] that was my point [20:48:17] huh I am going to have to try that file over here [20:48:26] is it the particular contents?? [20:48:26] https://labsconsole.wikimedia.org/wiki/Special:Version [20:48:52] notice that that page has information about extensions, and hooks, tags, etc [20:49:19] the core code portion of this should provide a means to list oauth capabilities [20:49:40] right [20:49:50] extension authors should also list these in their documentation, with explanations about what they are for [20:49:54] or it could be done in the code [20:50:08] where capabilities are listed with a description [20:50:15] I like the latter [20:51:20] like a table with: capability, where it's provided (core or the specific extension), description of capability, right needed for capability [20:53:04] Fucking computers [20:54:26] Reedy: :D [20:54:31] that sounds dangerous [20:54:43] Just stay away from fans etc [20:54:55] I still don't get how something that works on the shell directly, then doesn't work when wrapped up [20:55:04] Ryan: I like that as well (table etc) is that already a current practise or do some extensions do that and others not? [20:55:17] dvanliere: I mean in mediawiki itself [20:55:38] it could even be a table in special:version [20:55:53] though it would be *really* nice to be able to request that as a json object, too, though [20:56:03] that way clients can discover the capabilities of a specific wiki [20:56:26] ryan: sorry, just want to make sure that I understand, so an extension should tell mediawiki what capabilities it offers and what minimal rights are required? [20:56:45] well, mediawiki core should provide extensions with a way of doing so [20:56:53] extensions can already extend the api [20:56:58] it should likely live with that [20:57:34] and clients should be able to probe that information, so that they know if they are compatible with a wiki or not [20:57:44] hell, the api as a whole should do this [20:58:05] but we don't care about third party users, it seems [20:58:06] okay, and assuming that such a change to core will take a while, we need the oauth extension to be able to query the API for advertised capabilities and rights offered by the different installed extensions? [20:58:29] well, this oauth work should do the core work, and the extension work [20:58:44] both need to occur, so whoever writes this, should add that support [20:58:50] it's something that can be pushed to V2 [20:59:10] we can rely on people writing proper documentation or reading source code for V1 [20:59:22] it isn't terribly nice to do that, but it's better to get a product out than it be perfect [20:59:35] I'd actually love to just have pseudo-authentication in V1 [20:59:53] *Ryan_Lane nods [21:00:06] I think we should be more bold for V1 [21:00:10] I am more excited about this than allowing crazy ways to edit WP itself [21:00:17] heh [21:00:41] boldness = $$$ [21:00:52] boldness== attitude ;) [21:01:25] it's easier to get one time a budget than to get it twice [21:02:11] attitude is necessary but not sufficient for $$$ [21:03:07] and I think that a small investment of money for a proof of concept with a large ROI (hundreds of new apps popping up) could easily justify a larger investment at a second stage [21:03:31] s/hundreds/dozens [21:03:39] :) [21:03:43] hell, just 1 cool app would make me happy [21:03:54] but basically we are talking about a discovery mechanism for extensions [21:04:42] not needed for V0.1 (pseudo-authentication only) [21:04:53] but otherwise yes [21:05:07] *DarTar needs a sandwich [21:05:35] but I just asked if this was for V2 and then you guys said no this is a must have for V1 :D [21:06:10] that was assuming write access [21:06:23] *robla reads backlog [21:07:10] off to get some food ??? bbl [21:07:22] enjoy! [21:11:38] ryan: so we would need this to determine capabilities of extension: http://www.php.net/manual/en/class.reflectionclass.php#reflectionclass.props.name [21:12:40] umm [21:12:42] I dunno [21:12:53] mediawiki has methods of doing this for other things already [21:13:00] cool! [21:13:07] do you know where? [21:13:09] usually, the developer puts in some associations, and core exports them [21:13:20] I'm not really a hardcore mediawiki dev... [21:13:35] it would likely be good to talk to RoanKattouw or Reedy or ^demon about that [21:15:03] ok [21:15:13] If you think you need reflection, you're probably wrong [21:15:18] What are you trying to accomplish? [21:17:32] RoanKattouw: for oauth, extensions need some way of advertizing their capabilities [21:17:46] which basically means "here's the rights you need to perform this api action" [21:18:20] Oh [21:18:25] Hmm, OK [21:18:30] which also means that when an application requests these permissions on behalf of a user, they'll show up in the interface [21:18:43] Is the API action implemented by the same extension? [21:18:47] I'd imagine this could be an extension of how applications currently extend the api [21:18:52] I do see some calls to ReflectionClass in mw, so that just uses the PHP5 functionality [21:19:46] when the extension says "add this action", it can also say "this is the capability needed to use it" [21:19:54] and possibly also list the rights needed as well [21:20:28] RoanKattouw: yeah. the action would be implemented by the same extension [21:23:15] so, for instance, if openstackmanager has an action: action=createinstance, then it should also have: capability: create instance, rights required: sysadmin [21:23:30] or really, in this case, it should just have a callback [21:23:47] upload wizard triage in 7 min [21:23:56] etherpad here: http://etherpad.wikimedia.org/BugTriage-2011-11 [21:24:06] rights required: OpenStackNova::checkRights("sysadmin") [21:24:29] if we need to wait for the devs of all major extensions to change their code to have ext capabilities show up in the authorization interface this is going to take ages :-| [21:24:40] or not? [21:25:01] meh, we could expose all core capabilities, and then work on our own extensions [21:25:07] other authors can choose to do so or not [21:25:15] not all extensions even export api functions [21:25:47] so for a lot of extensions, we'd have to export the api actions too [21:26:12] the important part is adding the framework for doing so [21:26:27] and supporting oauth [21:26:42] the rest kind of comes naturally [21:28:03] discovery should actually be a pretty easy feature to add [21:28:30] it's just an abstraction of what's needed for the interface anyway [21:28:35] ok [21:29:08] discovery is a nice-to-have feature for clients, so that they can support more than just wikipedia [21:29:27] hell, it's even important to support us [21:29:35] not all of our wikis will have the same capabiltiies [21:29:44] since different wikis have different extensions installed [21:29:51] Ryan_Lane: can you summarize these requirements at: http://www.mediawiki.org/wiki/OAuth#Proposal ? [21:29:53] AzaToth: you're in the etherpad twice? [21:30:06] ryan, dartar: that would be really awesome! [21:30:09] hexmode: only one window [21:30:15] but I reloaded the page [21:30:20] might be a bug in etherpad [21:30:24] hi guys [21:30:24] I'm really low on time right now..... [21:30:33] ah just looked weird [21:30:39] if you guys can summarize it, I'll be more than happy to check it, and edit it [21:30:51] oh,look, triage time! [21:30:57] Saibo: hey! [21:31:08] dvanliere: wanna take a first stab? I gotta leave soon [21:31:50] smells the devs doesn't want this triage [21:31:59] Saibo: AzaToth: so I just found the top one [21:32:08] hey [21:32:10] shoot [21:32:20] raindrift: here for triage? [21:32:30] etherpad: http://etherpad.wikimedia.org/BugTriage-2011-11 [21:33:13] neilk_: could you pull up the etherpad? ^^ [21:33:53] AzaToth: even if they don't, I think we can at least get some input on these [21:34:12] I went through the first few before this to see what I could find [21:34:19] hexmode: I'm not knowledgeable about the campain thingi [21:34:28] anyone have an older browser? [21:34:34] AzaToth: me either ;) [21:34:55] could someone check http://bugzilla.wikimedia.org/32453 -- Upload wizard: doesn't support descriptions in languages of non-Latin alphabet on FF3? [21:34:56] FF 3.6 here :D [21:35:11] Saibo: ^^ [21:35:12] hexmode: is the latest version running somewhere? [21:35:31] hexmode: okay, you want me to try it, too? [21:35:38] AzaToth: I think testwiki, but maybe not [21:35:46] nein [21:35:58] the commons UW doesn't even have a back button.... [21:36:09] AzaToth: prototype? [21:36:26] back button should be highest priority, I agree [21:36:33] now, if only we can get them to [21:36:37] the commons UW is pretty close to the latest. The only real difference from trunk is the chunked upload support. [21:37:11] Saibo: yes, if you could test 32453, it would help [21:37:24] hexmode: I assume I need to create a new user on prototype (no SUL)? [21:37:25] I couldn't reproduce the report on ff 7 [21:37:47] raindrift: so back button isn't planned? [21:37:48] AzaToth: use testwiki, I think sul is there [21:38:43] back and maybe links in the progress bar would be really useful, indeed [21:38:56] hexmode: testwiki doesn't have UW [21:39:01] there's a bug for it (looking now), but it's a major change. i don't think it's on the immediate roadmap. [21:39:15] AzaToth: Special:UploadWizard [21:39:25] not Special:Upload [21:39:25] ah [21:40:08] https://test.wikipedia.org/wiki/Special:UploadWizard this wiki? [21:40:27] raindrift: even in my testing today, just playing around with it, I could have used a back button [21:40:30] Saibo: yes [21:40:36] k, will test it [21:41:00] back button tracking bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=30687 [21:41:26] raindrift: who is in charge of saying that is a priority ? [21:41:33] *hexmode wants to nag someone [21:41:58] sorry was talking to the new devs [21:42:07] hi all [21:42:22] neilk_: hey! [21:43:12] neilk_: raindrift: How much urgency can we put on getting a back button? [21:43:13] hexmode: in practice, I suppose that would be me or Erik. There aren't any product people assigned to this. I've focused on more basic issues, deferred that whole back button issue. [21:43:29] all steps between the initial upload, and the final save should allow for back navigation at least [21:43:30] neilk_: ok [21:43:34] I don't notice the back button issue as much since I know too much. [21:44:02] I might talk to erik, then. [21:44:27] neilk_: I think raindrift is taking over UW, right? [21:44:30] . [21:44:53] well, he might be looking at it in maintenance mode, but neither of us are supposed to work much on it [21:44:58] hi JeroenDeDauw! [21:45:13] however, Jeroen, who is kindly joining us at a late hour where he lives, is going to be contracted to do stuff [21:45:23] I think the big new features and high priority bugs could go to him [21:45:29] JeroenDeDauw: since you did campaigns, I found http://bugzilla.wikimedia.org/32462 [21:45:42]