[00:04:49] <^demon|away> sumanah: Sorry was running a few minutes late. [00:04:54] hi ^demon|away [00:04:59] got a few minutes to do some code review? [00:05:10] <^demon|away> Yeah let me call in. [00:05:33] ^demon|away: call's over [00:05:39] <^demon|away> Ah ok [00:05:55] ^demon|away: (Tim had a hard stop at 8pm our time) [00:06:31] <^demon|away> Which ticket #'s do you want me to look at? [00:06:45] will pm [02:02:27] is tfinc still in teh office? [02:02:33] guess not. [13:13:43] folks from enwp asked me how to edit moodbar feedback items, no clue why they asked me, but someone knows? [13:14:11] related to http://en.wikipedia.org/wiki/Special:FeedbackDashboard/5853 [13:18:32] jorm: around? [13:18:40] you should probably know that, since you are author :) [13:35:35] It's a bit early for jorm. [13:40:46] petan|w: You can't edit feedback items once submitted [13:43:04] RoanKattouw, I think they have a valid point, though; edits, edit summaries, and usernames can be hidden if they contain copyvios, attacks or libel; Feedback items should provide this feature too. [13:45:06] Oh you can *hide* them, yes [13:45:36] Sysops should have a hide link [13:45:43] I believe that's deployed already [13:46:08] I don't think so from what I've seen in source code [13:46:59] I reviewed the code that implements the hiding feature [13:47:07] I am quite certain that the feedback dashboard has administrative hiding [13:47:16] I am not 100% sure it's deployed yet, but there's a deployment tonight [13:49:49] (link to here) [13:49:51] (hide feedback) [13:50:03] Is what I saw after I +sysopped myself and refreshed the feedback dashboadr [13:50:10] okay [13:51:05] Weird, I don't see it with the staff bit. [13:51:15] Anyway. [13:53:35] No, staffs don't have that right apparently [13:53:48] Up until recently, sysadmins didn't have the block right [13:55:54] I guess I am just used to having every possible right everywhere since until recently I was a steward =) [13:58:19] Ah [13:58:33] Yeah that'll do it [16:44:52] It's a known thing that the moodbar right doesn't pass to +staff (neither, by the way, does +reviewer, i believe) [18:10:35] jorm: around? [18:10:54] yes. [18:11:04] I was thinking of splitting moodbar-admin to moodbar-hide and moodbar-unhide so that it would be more customizable [18:11:28] as I started on wikitech-l, there was a question if it was possible to give that permission on enwp to more than just sysops [18:11:49] i don't think splitting it into two groups is wise. [18:11:53] permission bloat and all. [18:11:57] True [18:12:00] But '-admin' is a bad name [18:12:04] yes. [18:12:14] i agree. i think "feedback-moderator" is probably best. [18:12:24] .. [18:12:29] How about just feedback-hide [18:12:34] and have it imply unhide too [18:12:34] right, I meant for instance some might want to give permission to hide it only to let say rollbackers, while unhide should be left only to sysops [18:12:34] <^demon> +1 to Roan [18:12:41] <^demon> hide implies unhide. [18:12:41] Rights should be an action [18:12:48] <^demon> Just like watch implies unwatch. [18:13:46] i'm leery of granting rights that are one-way. [18:14:20] to be honest, I am too, but I know how the folks from enwp like stuff complicated :) [18:14:40] <^demon> feedback-hide would be fine, and it would imply unhide. [18:15:30] but, renaming it is also good idea... [18:16:14] one of the goals is to DECOMPLICATE things. [18:16:21] ok [18:17:00] <^demon> I don't understand what's complicated here. [18:18:33] two user rights versus one. [18:18:58] probably yes [18:19:26] <^demon> Roan and I both said just making it one would be best :) [18:19:35] <^demon> But a nice action-specific name and not moderator|admin [18:19:42] when it comes to that, is there some reason why certain rights on testwiki are granteable by crats but not revokable? [18:19:56] I though it was some mistake in config, but maybe not, especially translateadmin etc. [18:20:00] that's a normal permissions model, actually. [18:20:06] you can grant rights you own, but not remove them. [18:20:21] no [18:20:38] <^demon> That's totally configurable, which groups a group can add/remove. [18:20:42] I mean I can grant translateadmin even if I am not that, but can't revoke it [18:20:55] on test.wikipedia [18:21:07] <^demon> Yes, this is similar to how it's used on enwiki too. [18:21:12] <^demon> (or at least was) [18:21:14] aha [18:21:32] <^demon> You can say "bcrats can grant +sysop and +foobar, but can only revoke foobar" [18:21:51] <^demon> Or "sysops can grant other people +sysop, but can't revoke it" [18:21:55] <^demon> Totally configurable. [18:21:56] that makes sense [18:22:09] <^demon> Or anonymous users can grant people +bcrat ;-) [18:22:13] I mean you can grant +sysop + foobar +crat but only revoke crat [18:22:14] <^demon> If you were crazy. [18:22:17] that doesn't make sense [18:22:32] uh wrong example [18:22:38] <^demon> I'm saying you configure it by group :) [18:22:40] <^demon> * is a group [18:23:04] I just didn't know why that translateadmin can be only granted, not revoked, that's all :) [18:23:21] <^demon> It'd be in InitialiseSettings. [18:23:41] the reason? [18:23:46] I didn't see it there [18:24:03] <^demon> Somebody configured it that way :) [18:24:10] <^demon> It's testwiki, so it's no big deal. [18:24:14] sure [18:37:17] IIRC there was some bug causing IE to crash in 1.18, correct? [18:37:32] At some point there was one yeah [18:37:40] do you remember the root casue? [18:38:26] we have a form crashing IE and I'm hoping that it is the same/similar problem [18:38:43] pgehres: 1s [18:38:51] I think I can find you one [18:39:29] pgehres: http://bugzilla.wikimedia.org/31673 # not crashing [18:40:25] hexmode: hmm, this is a 1.17 wiki and, literally, iE7 and IE8 crash and close [18:40:27] *hexmode pasted "pgehres: list of bugs" at http://paste2.org/p/1754694 [18:40:37] hrm... 1.17 [18:40:57] didn't hear 1.17 [18:41:14] yeah??? [18:41:22] we still run a few of those around here (wmf) [18:42:00] ^demon: will you be around for the next 80 min or so? [18:42:15] pgehres: https://bugzilla.wikimedia.org/show_bug.cgi?id=31424 1.18 IE crash [18:42:26] <^demon> I can be, although I don't know how much help I'll be. I know diddly other than mysql and sqlite. [18:42:54] hexmode: awesome thanks [18:43:07] will check the jquery version [18:43:44] pgehres: what is the URL for this wiki? [18:44:08] test-payments.tesla.usability.wikimedia.org [18:44:29] pgehres: excellent... was looking for a WMF wiki to test regressions on [18:44:49] its pretty hacked up [18:44:54] its the dev ground for payments [18:45:05] thanks ^demon I think that'd be helpful [18:45:24] wish Tim could be around, but that's basically nearly impossible to schedule [18:46:40] hexmode: its jQuery 1.4.2, so not the dreaded 1.6.2 [18:46:45] hmm [18:48:42] ^demon: guillom is publishing this tomorrow: http://www.mediawiki.org/wiki/Wikimedia_engineering_report/2011/October ....should we put any sort of call for the unknown committers in there? [18:49:31] <^demon> Not a bad idea. I'll make a second etherpad and put just the unknowns in it. [18:53:08] <^demon> robla: I made http://etherpad.wikimedia.org/Unknown-committers [18:55:44] great! guillom, I see you're in that pad already. do you want me to craft some wording for the report, or are you already on it? [18:55:59] Heh, Mystery Committers [18:56:12] robla, if you can just write a sentence about it, I'd appreciate it; otherwise I'll do it [18:56:23] *robla goes to scribble [18:56:34] ^demon: I somewhat know rfrisar [18:56:48] I would've been able to give you their full name if I had still had my pre-2008 e-mail archive [18:56:49] <^demon> Then fill it in :) [18:56:55] did so [18:57:21] <^demon> Ah, I've got him. [18:57:34] <^demon> wikitech-l from '09 [18:57:38] Right [18:57:40] I was gonna say [18:57:46] yay [18:57:47] wikitech-l archives should turn up most of these people [18:57:48] yeah, I was thinking of searching in the wikitech archive [18:57:57] I probably have looxix's email somewhere [18:58:10] or I can find it in the archives of wikifr-l [18:58:26] and I'm pretty sure kelson42 is Emmanuel Engelhart [19:00:06] Yes [19:00:08] Would have to be [19:00:18] OK, who all is here for the non-MySQL database bug triage? Etherpad: http://etherpad.wikimedia.org/database-bug-triage please speak up [19:00:27] *MaxSem [19:00:36] <^demon> Added a few more that I have names but no e-mail addresses. [19:01:08] sumanah: Hi, I am here [19:01:12] Ah, I can dig up shaihulud as well [19:01:19] Greg__, hexmode ^demon Nikerabbit, MaxSem [19:01:47] ^demon, do you need the name, the email, or both? [19:02:17] <^demon> Preferably both. In the worst case scenario of people we just absolutely can't find, I'll fall back on username + dummy e-mail address. [19:02:23] <^demon> But really we want proper attribution. [19:02:32] ok [19:02:39] I figure we will start off by validating & prioritizing some Postgres bugs, since G_SabinoMullane is here [19:02:43] this is better. was in the wrong room :( [19:02:51] sumanah: I'm here but have to leave in 15min to pick up my daughter [19:02:53] blobaugh: where's DJ? do you know? [19:02:55] ok, hexmode [19:02:57] blobaugh: welcome! [19:02:58] I just can't promise the email addresses will work [19:03:17] hi brian_swan [19:03:20] OK, I'm here. [19:03:31] Are you happy now, Sumanah? [19:03:33] brian_swan: please open http://etherpad.wikimedia.org/database-bug-triage to follow along [19:03:33] ARE YOU HAPPY NOW? [19:03:40] Sheesh. [19:03:46] sumanah: brian_swan is not here yet, i joined him. this is his first time IRCing [19:03:53] oh! welcome to IRC, brian_swan [19:04:08] I have the bug triage open, too. [19:04:13] I figure we will start off by validating & prioritizing some Postgres bugs, and then move on to SQL Server, Oracle, & SQLite [19:04:14] Although I haven't looked at the tickets at all. [19:04:24] Etherpad line 21: https://bugzilla.wikimedia.org/show_bug.cgi?id=30787 PostgreSQL 9.0 default 'mediawiki' schema causes failure, use 'public' instead. [19:04:31] I'm going to give everyone a minute to read it [19:04:58] hi djbauch -- we are starting off by validating & prioritizing some Postgres bugs, and then will move on to SQL Server, Oracle, & SQLite. first is https://bugzilla.wikimedia.org/show_bug.cgi?id=30787 PostgreSQL 9.0 default 'mediawiki' schema causes failure, use 'public' instead. [19:05:14] I don't think there's a way to set a default schema, other than search_path. [19:05:54] (yes, the Etherpad scrollbar doesn't work. Sorry. Try clicking the lefthand column of row numbers; then you can use pgup/pgdn or up/down arrow keys.) [19:06:41] Not sure what the issue is here. Nobody else has complained about this. [19:06:51] G_SabinoMullane and others: do you agree with alester? [19:07:01] The user they use should already have the search_path changed. [19:07:17] G_SabinoMullane: I'd love to see whether anyone can reproduce this error; if not, I'm happy to close it. [19:07:21] It would be nice to have some more work done on the multi-schema idea. but the basics are pretty sound. [19:07:46] I think it's reasonable to say "get it reproduced by $SUNSET_DATE or we close it" [19:07:53] I'm going to guess that they are connecting with the wrong Postgres use in their LocalSettings.php [19:07:54] But I don't know the MW style of bug handling. [19:08:23] Oh, and hi Greg! [19:08:50] hi [19:08:53] alester: G_SabinoMullane: I take it that neither of you is volunteering to try to reproduce this. [19:09:08] sumanah: You take correctly. :-) [19:09:22] Oh, I can reproduce - just use the wrong user :) [19:09:27] hahaha [19:09:35] The installer should be doing an ALTER USER to set the default search_path [19:09:37] In which case I shall note in the bug "please try as Greg suggests -- can you still repro?" [19:09:51] and also note the "are you on the wrong user" [19:09:55] But without knowing the exact steps they did, it's impossible to know if its a true bug or user error. [19:09:59] <^demon> "ALTER ROLE $safeuser SET search_path = $safeschema, public" [19:10:21] ok [19:10:24] <^demon> Line 469 of PostgresInstaller [19:10:26] I shall reply to the reporter [19:10:27] and move on [19:10:32] One down [19:10:35] next: https://bugzilla.wikimedia.org/show_bug.cgi?id=20475 SpecialExport producing corrupt output (PostgreSQL errors) [19:10:37] N-1 to go [19:10:50] /j djbauch is your sql stuff ready for prime time except for the - thing? [19:10:56] alester: 9 to go, just fyi [19:11:21] ^demon, I've added a few names and addresses; it's probably all I can do. robla , I'll add a sentence in the report and a link to the etherpad [19:11:55] sumanah: are we working through the list of bugs before we talk about the idea section? [19:12:00] guillom: I added something. feel free to wordsmith [19:12:09] <^demon> guillom: Thank you though! I'm finding everyone knows like 1 or 2 names, which helps. [19:12:20] robla, ah, edit conflict! Thanks [19:12:29] yes, blobaugh [19:12:30] The MSSQL stuff is almost there. (in response to Ben) I expect to be able to resolve the strangeness and then it would be ready to go. [19:12:49] I think OverlordQ summed it up well. Yet more fun with the loadbalancer [19:12:59] robla, looks great. Thanks. [19:13:10] One of the unfortunate aspects of pg_query() is that it doesn't require a first parameter of a connection if it's been called before. [19:13:28] It lets you call pg_query( $conn, $sql ) the first time , and then pg_query( $sql ) thereafter. [19:13:46] <^demon> What silly behavior. [19:13:47] and I'm guessing that somewhere before 1.17.0 which I'm looking at now, there were pg_query() calls that relied ont hat behavior incorrectly. [19:14:00] *^demon adds that to the list of reasons he dislikes pg. [19:14:04] ^demon: PHP is all about silly dangerous shortcuts. [19:14:22] <^demon> php's so stupid. [19:14:49] Praise the Lord and pass the ammunition. [19:14:54] *blobaugh glares at ^demon [19:15:29] mysql_query does something similar (but not exactly similar, of course, because after all, this is PHP) [19:15:31] Anyway, I'm looking in DatabasePostgres.php and I don't see anywhere it's calling pg_query() without a connection object. [19:16:00] It's pg_connect() that's the issue, no? [19:16:07] But I don't have the 1.16-svn source in front of me. [19:16:22] G_SabinoMullane: mysql_query takes it as an optional second parameter, it does not change the expected param types between calls [19:16:27] ok, so, what is the next step here? can one of you quickly try to repro with 1.17.0 right now? [19:16:43] Sounds like a job for someone who knows LoadBalancer well [19:16:43] Not me, but yes. [19:16:44] or can I ask you to do so sometime soon and report back to Bugzilla? [19:16:45] ok, I'm off :) [19:16:52] G_SabinoMullane: not necessarily [19:17:12] it should be easy to test, make some jobs and make sure they are run after call to Special:Export [19:17:45] Really, anyone should be able to test this against 1.17.0 [19:17:52] not just me or GSM [19:18:05] *hexmode steps out for a few [19:18:26] anyone having postgre installed? :) [19:18:53] Postgres? Never heard of it! [19:19:06] I do, and my company wiki is on it. [19:19:10] I should probably install it at some point and test how my extension works (or not) with it [19:19:24] Can I just go to Special:Export? [19:19:33] so, alester, since you already have postgres installed, can I ask you to test for repro and get back to us, maybe later this week? [19:19:47] alester: you should also have non-zero jobqueue [19:19:59] I don't know about "jobqueue" [19:20:00] I've exported pages just fine before (but never tried to specifically duplicate this bug) [19:20:06] Nikerabbit, I have: Notice: unserialize() [function.unserialize]: Error at offset 0 of 53 bytes in D:\Projects\MediaWiki\includes\objectcache\SqlBagOStuff.php on line 381 [19:20:19] MaxSem: context? [19:20:30] who has PG :P [19:20:30] Wow, is that a "D:" drive. Flashbacks! : [19:20:34] testing it now [19:20:46] MaxSem: but for that error? :) [19:21:14] alester: if you have some commonly used template, you could edit that just before [19:21:15] I just now ran an export on all the pages in [[Category:Development]] on my company wiki and it ran fine w/o errors. [19:22:01] I wouldn't be surprised if it is really fixed, it's been many changes since 2009 [19:22:04] alester: ok, I'm ok with closing the bug [19:22:08] I'd make this a "see if you can reproduce with 1.17.0" [19:22:16] next: https://bugzilla.wikimedia.org/show_bug.cgi?id=22579 PostgreSQL Schema option ignored [19:22:17] or close it. [19:22:19] alester: ok [19:22:36] 22579 is the same as the first ticket we looked at [19:23:20] Does not seem the same, but does claim to be fixed. [19:23:26] ok, so I will tell the user to please check that s/he used the correct Postgres user [19:23:38] Unfortunately nobody left a revision [19:23:43] next: https://bugzilla.wikimedia.org/show_bug.cgi?id=32118 test special pages SQL queries against all supported databases [19:24:18] so this is a feature request and I hope that I could get some of you to pitch in on this [19:24:19] throw some test data at it, then call internally via the API? [19:24:31] MaxSem: for bug 32118? (just checking) [19:24:36] yup [19:25:29] without having the test know how to access the db itself you could do that. insert via api and retrieve via api, compare [19:25:41] djbauch: blobaugh: alester: brian_swan: G_SabinoMullane: perhaps you'd be willing to write a few unit tests? ^demon can help you learn your way around our unit testing framework [19:25:48] Not me. [19:25:54] alester: :P [19:26:01] I don't know how you guys do testing. [19:26:09] alester: we are happy to show you! [19:26:13] just write the test and turn it in ;) [19:26:17] "just" [19:26:20] http://www.mediawiki.org/wiki/Testing_portal [19:26:27] *alester puts fingers in ears [19:26:36] o/` la la la la I can't hear you o/` [19:26:54] alester: https://www.mediawiki.org/wiki/Manual:Unit_testing & https://www.mediawiki.org/wiki/Fixing_broken_tests & ^demon, the human manual :-) [19:27:08] alester: earlier in the North American day, hashar is around on IRC (he lives in France) [19:27:09] I have no tuits on my plate for that. [19:27:11] ok. [19:27:14] anyone else? [19:27:23] djbauch? [19:27:44] sumanah: i can work with djbauch to make sure the MSSQL driver is fully tested [19:27:53] blobaugh: cool, maybe design some tests? [19:28:06] vvv, do you ever work with non-MySQL databases? wanna help write some tests? [19:28:23] sumanah: I don't have any experience with them :( [19:28:24] Yeah, I can work with Ben on all the required MS SQL tests. [19:28:25] is there any docs about SQL gotchas that are not supported on some databases? [19:28:27] (btw, ^demon, is it fine for us to upload to Commons the recording of your "how to write unit tests" talk from New Orleans?) [19:28:59] ok, djbauch, blobaugh, I will put you down for that, then -- thanks! [19:29:19] <^demon> sumanah: If you must :\ [19:29:29] sumanah: is there no specification for test for dbs right now? [19:29:40] ^demon: I don't HAVE to but I think some folks would find it helpful. So if you don't mind. [19:29:48] Nikerabbit: I don't think so. [19:29:56] blobaugh: I don't know. I can follow up with you separately to help develop one? [19:30:01] blobaugh, first, you have to get normal tests to work on your backend [19:30:04] <^demon> sumanah: It was just audio, right? [19:30:07] yes ^demon [19:30:12] <^demon> Then fine :) [19:30:28] ^demon, are you shy? =) [19:30:32] next: https://bugzilla.wikimedia.org/show_bug.cgi?id=28172 wfGetDB called when it shouldn't be [19:30:37] WORKSFORME [19:30:45] djbauch: you wrote in the etherpad: "I see this happen when an install fails to complete for some reason (on SQL Server in my case) and then tries to resume. Restarting the install from scratch after fixing whatever caused the failure works around the problem that the load balancer has been turned off and never turned back on." [19:30:50] <^demon> MaxSem: Not in front of people, I just hate the sound of my own voice recorded :) [19:30:55] never was able to repro it outsiide of one page [19:30:58] Nikerabbit: We tend to break those into methods, e.g. implicitGroupBy() [19:31:26] lost that cryptic skill long ago [19:31:49] brrr [19:32:01] that was intended for a different bug [19:32:02] alester: can you repro this? [19:32:15] I dug into 28172 quite a bit, but finally gave up after swimming in the sea of LoadBalancer objects and DB calls. [19:32:20] MaxSem: so your "never was able to repro it outsiide of one page" -- bug 28172? [19:32:22] G_SabinoMullane: but one thing are the actual sql files [19:32:24] <^demon> I've never managed to repro it after I fixed it for mysql/sqlite. [19:32:42] G_SabinoMullane: I got the impression that I need to duplicate the files for each typ [19:32:44] Would be nice if all the LB stuff was documented somewhere [19:32:49] sumanah, no:P it was prepared for the next bug:P [19:32:49] No, I can't. [19:32:53] and I have no LB [19:32:54] aha :-) [19:33:11] *MaxSem needs to sleep [19:33:16] Yes, my comment on the etherpad was for the next bug. Special pages are working OK for me now on SQL Server. Even the GROUP BY stuff [19:33:52] MaxSem: no sleep for you [19:33:55] djbauch: I move your comment to bug 22010 then [19:34:02] *blobaugh hands back the unit tests [19:34:06] I think Chad H or Tim need to take a look at 28172 [19:34:21] OverlordQ and I are stumped :) [19:35:06] <^demon> G_SabinoMullane: I have looked at 28172. [19:35:12] <^demon> And have never been able to repro it. [19:35:13] thanks djbauch sorry for misunderstanding [19:35:21] "next" is sadly ambiguous in these meetings :/ [19:35:42] djbauch: "Special pages are working OK for me now on SQL Server. Even the GROUP BY stuff" is re which bug? 28172? [19:36:15] *hexmode is back [19:36:31] so, G_SabinoMullane, you & OverlordQ can reliably reproduce 28172, right? [19:36:57] ^demon: Odd. I can dupe quite easily [19:37:07] Well I've not tried lately, but yes [19:37:25] G_SabinoMullane: if you could try against HEAD sometime this week or next, that'd be great -- could I ask you to do that & report back on the bug? [19:37:37] <^demon> It shouldn't differ by dbms, since that code is shared. [19:37:50] hmm, and Overlord's repro was like 3 days ago [19:37:51] <^demon> And I haven't been able to replicate on mysql or sqlite. [19:37:51] I think the key is here: #2 /var/www/thedarkcitadel.com/w/includes/User.php(2858): wfGetDB(-1) [19:38:00] <^demon> Yes I know that. [19:38:06] Meant for 32118 (Special Pages) [19:38:10] <^demon> After the db has been initialized the LB is re-enabled. [19:38:23] <^demon> And then User can do its thing. [19:39:52] ok, so, perhaps we can take this discussion back to the bug & I can ask Tim to poke his head in when he has a moment [19:39:55] on to the next item? [19:40:20] ^demon: Why is the LB being disabled there? [19:40:54] e.g. to prevent you from creating a user when you shouldn't :) [19:41:05] <^demon> The LB code automatically does things like connect to the database and such. [19:41:10] =when DB is not ready yet [19:41:15] any SQLite users around? [19:41:23] <^demon> Right, it's to keep you from breaking things accidentally. [19:41:25] Work emergency, biab [19:41:54] *MaxSem coughs quietly [19:41:58] well, let's move on to non-Postgres stuff [19:42:10] MaxSem: you use SQLite ever? https://bugzilla.wikimedia.org/show_bug.cgi?id=31696 update.php fails with SQLite [19:42:44] <^demon> He's our sqlite maintainer. [19:42:45] other than maintaining its support, you mean? :P [19:43:02] MaxSem: um duh, sorry. [19:43:20] I would love to see a repro for this bug [19:43:37] looks like the connection is getting closed somewhere [19:44:44] anyone other than MaxSem want to try to repro this? [19:45:17] I may try to reproduce since I probably face similar / same issues with MSSSQL [19:45:38] ok, djbauch, can I ask you to do that offline, and we'll move on? [19:45:50] OK [19:45:51] back [19:45:57] nxt: https://bugzilla.wikimedia.org/show_bug.cgi?id=28512 SQLite installation via CLI fails to expand ~paths [19:46:00] next* [19:46:21] again with the SQLite. Whadday tryin' to do to us? :-) [19:47:01] alester: well, this is a "databases that aren't MySQL" triage and I figure sometimes the MySQLisms will hit multiple DBs at once... I asked ahead of time what bugs people wanted to cover! [19:47:15] I know, I am just kiddin' [19:47:20] That's what I do. :-) [19:47:24] oh ok [19:47:26] *bashful* [19:47:27] <^demon> Rather than trying to jump through hoops to figure out where the path is, why not just error out when a ~ path is given and say "give a full path please" [19:47:29] I see for bug 28512 that hexmode reported it in April [19:47:32] <^demon> ^ bug 28512 [19:47:34] That's some hacky code there. Why are we not just disallowing ~ ? [19:47:37] *dopey* [19:47:41] *hexmode checks [19:47:52] <^demon> G_SabinoMullane: Exactly. It's easier just to say "don't do that" than anything else. [19:47:58] gah. [19:48:08] i svn upped and now my localhost is throwing sql errors. [19:48:17] Message? [19:48:38] om within function "Revision::fetchFromConds". Database returned error "1054: Unknown column 'rev_sha1' in 'field list' (127.0.0.1)". [19:48:42] 28512: low-priority, someone should fix this eventually, installer issue, move on? [19:48:42] query hidden. [19:48:47] <^demon> jorm: Run update.php [19:48:50] Oh [19:48:52] Run update.php [19:48:52] how do i do that? [19:48:54] <^demon> Like you always should after svn up :) [19:48:58] php maintenance/update.php [19:49:06] ^demon: Oh come on, no one does that :) [19:49:14] *^demon does [19:49:18] I only run update.php if my wiki breaks [19:49:26] ok, I'm moving on [19:49:37] https://bugzilla.wikimedia.org/show_bug.cgi?id=28281 Differentiate between MySQL and MySQL forks (ie MariaDB) [19:49:54] <^demon> RoanKattouw: I've got a script called 'svnup' that does lots of fun things for my working copies :) [19:50:09] Chad says: " Low priority enhancement -- someone will get to this eventually? Not that big a deal." agreed. Is this in any way *easy* (for newbs) or something the MariaDB people might want to fix themselves? [19:50:09] I have update-repos but that just svn ups various path [19:50:11] s [19:50:28] as PR [19:50:53] I invited MariaDB's Colin Charles here but sounds like he didn't make it. [19:50:59] <^demon> I dunno what MariaDB would need to do. [19:51:02] *Platonides has mwup which is basically 'cd && svn up | color' [19:51:04] sumanah: that looks like an issue on the MariaDB side? [19:51:11] <^demon> Presumably we'd like to have some way in php to differentiate the two. [19:51:22] the only way to fix that is to contribute the patch to them [19:51:25] blobaugh: I mean, MariaDB people would donate a bit of time to fix it in MediaWiki. [19:51:31] <^demon> Again... [19:51:37] <^demon> I'm not sure what MariaDB needs to do? [19:51:58] <^demon> We assume it's mysql because we're using mysql_* functions [19:52:07] ^demon: it looks like just change the link on the Special:Version page [19:52:09] getSoftwareLink() currently returns a static string [19:52:19] (DatabaseMysql class) [19:52:28] <^demon> Platonides: Right. Because we assumed DatabaseMysql would only ever refer to mysql. [19:52:43] the work is to somewhow differenciate between the two [19:52:49] so to fix it a new class would need to be made? DatabaseMariaDb? [19:53:03] <^demon> Platonides: But other than a software link, do we need to differentiate at all? [19:53:16] <^demon> ie: Would the subclass be anything other than overriding getSoftwareLink()? [19:53:17] Not in the code, yet [19:53:18] make mysql family servers add a command 'SELECT UPSTREAM_LINK();' :) [19:53:24] ha [19:53:28] I don't think so [19:53:30] tell you what [19:53:36] I will write to Colin and ask whether they care [19:53:38] and we can move on [19:53:40] ^demon: afaik you are correct [19:53:51] if we switched to it, perhaps we would begin optimizing some edge cases [19:53:53] next: https://bugzilla.wikimedia.org/show_bug.cgi?id=26273 Database layer should automagically add GROUP BY columns on backends that need them [19:54:04] I thought MariaDB was meant to be super transparent with regards to working MySQL code? [19:54:05] but it's similar enough to mysql that I don't think we would make any change in the class [19:54:15] <^demon> For that, we need to file upstream bugs so all the other DBMSs act like Mysql. [19:54:21] <^demon> ^ bug 26273. [19:55:49] There is a related bug to 26273 but I don't know where it is offhand. Tim and I made some hand-waving solutions for this. [19:55:49] man. it is taking FOREVER to rebuild the ar localization cache. [19:55:53] <^demon> sumanah: I was kidding :) [19:55:57] hexmode: love your comment on this one [19:56:07] I know ^demon :) [19:56:08] heh [19:56:09] "You know what would be really nice for this bug? Some examples!" [19:56:18] Basically, we need to have MW gather the list of columns from the tables and create the GROUP BY on the fly. [19:56:33] <^demon> jorm: The annoying thing is if you re-run update.php 30 seconds after you finish it'll rebuild all the L10n caches again :) [19:56:51] jorm: are you using multiple threads? [19:56:54] it's been doing this for 5 minutes. just the one language. [19:56:56] no. [19:57:08] but my hard drive is dying on this thing, so who knows. [19:57:26] maybe that would only crash your comp then :o [19:57:32] it shouldn't take more than 10 seconds per language [19:57:36] re https://bugzilla.wikimedia.org/show_bug.cgi?id=26273 -- is this a longterm project for some interested developer, then? [19:57:59] like, GSoC level? or intractable? or what? [19:58:27] G_SabinoMullane: why not have a var that lists, per table, the correct group by? [19:59:16] not sure if it is worth full GSoC, but looks like non-trivial amount of work indeed [19:59:40] This bug (26273) used to rear its ugly head a lot. Not so much any more. It was just one special page the last time I checked. Staying away from GROUP BY 1,2,3, etc. and sticking to the more stringent rules enforced by SQL SERVER (e.g., making sure to name the fields by name rather than by alias) has helped a log. [19:59:42] blobaugh: Because schema changes (new columns) would break it [20:00:36] G_SabinoMullane: could this be a global that gets updated on schema changes manually? [20:00:36] ...helped a lot [20:00:54] djbauch: do you think it would be fairly easy to generate a list of the places in MediaWiki that name fields by alias? [20:01:18] <^demon> blobaugh: We can barely keep people updating all the proper places when they do a schema change anyway...a global they'd have to keep in check too would be impossible. [20:01:35] ^demon: fair enough [20:02:01] I'm ok with spending like 10 more minutes together talking about non-MySQL database support, and as long as people want in #mediawiki [20:02:13] sorry that this is running over the hour I mentioned [20:02:37] I kept the # of bugs to about 10 to try to keep the bug portion short; I guess hexmode can run a triage faster than I can [20:02:50] blobaugh: That seems like a lot of work compared to simply reading the db cols directly [20:02:55] I am still interested in determining how the unit tests are going to be run. Is WMF running each db server or should the db module dev be responsible? [20:03:17] G_SabinoMullane: maybe, but it would make the system much faster than needing another db call [20:03:23] I think wmf _should_ provide test runners [20:03:33] Sumanah: Yes, there were only two places that caused a problem that I found. One special page and one obscure place. [20:03:42] those labs VM that supposedly are available for everything [20:03:58] Ryan_Lane: ^^ [20:04:05] Platonides: ok, so how do we get things like Oracle going? Is there a good free version? [20:04:23] I can help get licenses for SQL Server, but that is only one db [20:04:42] Hey, before we get going on that, in the larger "how to improve non-MySQL db support" discussion, let's address djbauch's MSSQL encoding issue? http://mediawikiworker.blogspot.com/2011/10/struggling-with-inexplicable-issue.html [20:05:17] blobaugh, free edition of MSSQL is not enough for tests? [20:05:24] I think this problem must be of my own creating? I just don't see it yet. I thought maybe somebody may have seen something similar. [20:05:55] MaxSem: I am trying to determine that now, but if MS is willing to donate SQL Server why say no? [20:06:30] Is it a good idea to try to stick to NVARCHAR rather than VARCHAR columns for just about everything? [20:06:57] <^demon> Most everything in mysql is varchar. [20:07:02] blobaugh, there's a free version which could be used [20:07:32] <^demon> Same with Oracle. [20:07:40]