[13:38:41] @seenrx [Tt]hehelpful.*
[13:38:42] Base: Last time I saw Thehelpfulone they were talking in the channel, they are still in the channel. It was in #wikipedia-en-helpers at 10/2/2013 11:07:07 PM (4d14h31m34s ago) (multiple results were found: Thehelpfulone_, Thehelpfulone2)
[13:39:28] good point, yes
[14:17:16] @seenrx ([Oo]dder.*|[Tt]wkozlowski.*)
[14:17:17] Base: Last time I saw odder they were leaving the channel #wikimedia-commons at 9/30/2013 8:03:55 PM (6d18h13m21s ago) (multiple results were found: odder_, odder__, twkozlowski, SniperFodder, twkozlowski_)
[14:17:39] @seenrx [Tt]wkozlowski.*
[14:17:40] Base: Last time I saw twkozlowski they were talking in the channel, they are still in the channel. It was in #wikimedia-commons at 10/7/2013 11:40:47 AM (2h36m52s ago) (multiple results were found: twkozlowski_)
[15:31:00] apergos: hi, we haven't talked in a while, what's the current status of incremental dumps?
[15:31:07] hello!
[15:31:22] I have a couple bugzilla bugs for you, small things 'todo'.
[15:31:52] coren is going to help me to look at the nfs issue (where we see a lot of wio when running the 'convert to xml' job
[15:33:14] where exactly can i find them?
[15:33:18] ah
[15:33:58] https://bugzilla.wikimedia.org/show_bug.cgi?id=54633
[15:34:02] feel fre to take ownership
[15:34:05] *free
[15:34:44] I've also got another possibility for a c++ reviewer (in our team even , which is good)
[15:35:08] bblack (not in this channel right now)
[15:36:42] ok
[15:43:06] apergos: regarding the non-positional command line options: with the current code, you can for example create pages-history and pages-current dumps at the same time; how do you imagine it would work with the system you proposed?
[15:44:13] would you want different options for them on the same run?
[15:44:59] or, in other words, if i have something like "idumps u enwiki 20131007 php /var/www/maintenance/dumpBackup.php /var/www/maintenance/fetchText.php ph ph.id pc pc.id", how would you want to write it?
[15:46:07] i guess not, but i think that's more a question of what you (as the one who will be actually running the dumps) need
[15:46:08] hmm that's another thing the php stuff oughta be in a config file and
[15:46:15] it's got to work with mwscript
[15:46:46] anyways,
[15:49:03] --update (or -u) --date 20131007 --configfile somethingorother (read location of php) --dump full-history or --dump full-current or --dump articles-current etc (taking multiple --dump args)... and let the uer specify --dumpfile and some formatstring that would be expanded
[15:49:14] as one idea
[15:50:10] one approach the php code takes is to parse the options in order in the sense that the user would put the output file after the corresponding dump type, and also optionally namespace filters... then a new dump type arg and its options afterwards
[15:50:15] so order free but not completely
[15:52:25] ok, that makes sense
[15:52:46] if that would make you happier (so that we give the user more freeom) that's fine too, or any other idea that uses standard style options without arg1 must be X
[15:52:54] *freedom
[15:54:49] i don't actually care about the format of the parameters, i just wrote what made sense to me at the time (and was simple to implement)
[15:55:05] right
[16:03:57] do you know how can i set up bugzilla to send me an email when a new bug in Datasets is created? i can't find anything like that anywhere
[16:07:23] svick: "default CC list" and I'm not sure how to set it ;)
[16:08:06] svick: you usually ping andre__ and tell him? :)
[16:08:12] or file a bug in the bugzilla component on bugzilla
[16:08:20] YuviPanda: ok, thanks
[16:15:11] filing a bug is required
[16:16:27] Nemo_bis: i just did that: https://bugzilla.wikimedia.org/show_bug.cgi?id=55413
[16:17:39] apergos: regarding the XSD bug: i think dumps from DB don't need a special treatment, the output from dumpBackup (which is what I use) contains the XSD URL
[16:19:02] great, just don't hard code that in to the program
[16:19:15] it's in xmlwriter and sqlwriter
[16:24:33] hi. I think Mediawiki is lying to me:
[16:24:43] Asking for this page: https://meta.wikimedia.org/wiki/List_of_Wikipedias_by_language_group I get --
[16:24:49] Sorry, the servers are overloaded at the moment.
[16:24:51] Too many users are trying to view this page. Please wait a while before you try to access this page again.
[16:24:58] Timeout waiting for the lock
[16:25:14] I find it very hard to believe that "Too many users are trying to view this page.", for this particular page.
[16:26:31] apergos: you mean don't have the URL hardcoded in my code? right; though i think that if the XSD changes, i will have to change my code too
[16:27:27] then again, that page has a bunch of crazy template transclusion, #expr arithmetic, etc.
[16:29:27] abartov: I believe that error is poolcounter related
[16:29:37] I mean don't have the url hardcoded in there
[16:29:43] (the too many users one)
[16:29:50] you need to be able to handle different xsds
[16:30:11] say another site wants to use this, and they are running mw 1. dunno 19 or something earlier
[16:30:17] Reedy_ - thanks. I don't particularly care about reaching that page right now, but thought I'd check if this is a known bug before I file a new ticket.
[16:33:47] apergos: then i think my code wouldn't work, because i expect the export-0.8.xsd format on input and i write it in that format on output; simply storing the XSD version won't fix that
[16:34:30] (though i'm not sure how big the changes between the versions are)
[16:36:03] most of it is about fields that were added later
[16:36:27] but not quite all, I believe there's one change where the order of two fields changes, really quite annoying
[16:36:57] Reedy_, so, should I file a bug?
[16:39:15] apergos: my parsing shouldn't depend on the order of fields and i guess added fields shouldn't be a problem either
[16:39:49] though the output might contain something like empty if the input was in the old format (assuming was added recently)
[16:40:25] i think i'll look at the exact behavior when fixing the bug
[16:40:27] that's gonna be a problem later but for now we'll live with it (please document that as an isue)
[16:40:29] *issue
[16:41:48] ok
[16:41:54] bug filed.
[17:46:14] brion: omg
[17:46:16] this is so evil
[17:46:37] >:)
[17:46:46] you're crazy
[17:46:48] in a good way
[17:47:01] hehehe
[17:48:19] paravoid: is that the ogg in js thing?
[17:48:32] yes
[17:48:39] yeah
[17:48:40] :D
[17:49:03] wow
[17:49:11] it actually works
[17:49:36] brion: btw, http://allievi.sssup.it/techblog/?p=831 was on my blog feed the other day
[17:49:39] emscripted alternative
[17:49:56] paravoid: yeah i'm keeping an eye out for that as well
[17:49:58] but it's not open source yet
[17:50:11] and they sometimes use vague language about 'patent-pending techniques' which scares me :D
[17:50:16] yep
[17:50:27] that blog post says something about dual licensing it
[17:50:33] remains to be seen
[17:50:43] emscripten does some .... weird stuff to simulate the C memory model but it works and it's totally open :D
[17:51:08] i may as well sign up for their demo though and check it out :D
[17:52:28] s/demo/beta
[18:17:14] I keep getting 504 gateway error on https://it.wikipedia.org/wiki/Speciale:Registri/Caulfield
[18:17:28] Don't visit it then
[18:18:09] QueenOfFrance: should be fixed, wait for next deploy
[18:18:41] added you to https://bugzilla.wikimedia.org/show_bug.cgi?id=54876
[18:19:16] helpful Reedy is helpful
[18:19:35] he's helpful by definition ;)
[18:20:08] PHP Warning: mysql_query() [function.mysql-query]: Unable to save result set in /usr/local/apache/common-local/php-1.22wmf19/includes/db/DatabaseMysql.php on line 38
[18:20:20] uh
[18:20:25] QueenOfFrance knows I'm being very helpful
[18:20:47] Reedy's always helpful :)
[18:21:01] :-) indeed
[18:22:40] o/~ Here I come to save the day! o/~
[18:23:46] * greg-g waits
[18:24:22] jeremyb seemed to have expected my presence here. :-)
[18:25:48] * Reedy kicks jeremyb
[18:26:00] hah
[18:26:05] i do!
[18:26:25] csteipp: Coren: not sure who to ping exactly: your forced passwd reset don't work @ loginwiki
[18:26:54] i guess you need to grant the right to change passwd?
[18:26:55] 07 02:46:14 < jeremyb> > You do not have permission to edit your private information, for the following reason:
You are not allowed to execute the action you have requested.
[18:27:19] jeremyb: csteipp is probably your best bet -- he's the one who implemented the ugly hack.
[18:27:33] Oooo. loginwiki has all sorts of black magic, true enough.
[18:27:41] * Coren ponders.
[18:27:48] Did you change your SUL password?
[18:27:56] jeremyb: Correct, we weren't planning on people trying to login to loginwiki to change their password. No one should be logging in there, honestly
[18:27:59] i did after i got the error
[18:28:17] csteipp: really? i've been logging in there by default
[18:28:22] I expect it's a non-issue then -- your old hash probably lingers in that DB but is now quite meaningless.
[18:28:34] jeremyb: That's a very safe place to login :)
[18:29:28] But it's not currently intended to have people go there directly. All the local wikis still handle the initial logins. Loginwiki then also gets logged into, so it can log you in when you hit another wiki.
[18:30:37] right. but how about actually promoting it as a place for people that are techy and really care about security to login?
[18:30:45] i.e. the crowd that would have used secure.wm.o
[18:31:44] jeremyb: That's a potential direction... although part of the security there is revoking pretty much all user rights.. which is the issue you're hitting
[18:32:12] We probably can allow that one, but it will never be a place where we run translations, or user content
[18:32:49] csteipp: https://bugzilla.wikimedia.org/show_bug.cgi?id=55435 Special:CentralAutoLogin is causing an abuse filter related fatal
[18:33:15] Possibly enwikibooks specific
[18:34:43] Reedy: I'm looking..
[18:36:06] Nope, that's all AF...
[18:37:03] awesome we got the stack trace though, that's been a huge pain to track down...
[18:37:08] anomie: ^
[18:37:36] They seem to be more frequent since moving more wikis over to 1.22wmf20
[18:37:47] 6/1000 log lines
[18:37:50] So not too frequent
[18:37:59] GAH
[18:38:00] 674 PHP Fatal error: Unsupported operand types in /usr/local/apache/common-local/php-1.22wmf20/thumb.php on line 429
[18:38:07] The trick is what do we set it back to if it was null originally
[18:38:07] Reedy: We can revert that one change in AbuseFilter
[18:38:10] It only affects autocreates
[18:38:45] And the previous bug that was fixed with that, they were redirected to Special:AbuseFilter when they were autologged in.. which was better than a fatal
[18:39:53] Yeah, Reedy, want me to revert https://gerrit.wikimedia.org/r/#/c/86707/, and you can repush it?
[18:40:54] More interested in the big thumb breakage on commons atm ;)
[18:41:06] uh?
[18:41:25] [07-Oct-2013 18:39:53] Fatal error: Unsupported operand types at /usr/local/apache/common-local/php-1.22wmf20/thumb.php on line 429
[18:41:32] oh no. not working now. grrr. must.. not... get involved
[18:41:34] * Reedy suspects bawolff
[18:41:41] http://p.defau.lt/?wKovZUyLudQ66WkyOcckMw
[18:42:03] https://gerrit.wikimedia.org/r/#/c/69027/
[18:42:06] * Reedy files a bug for tracking
[18:44:47] $extraParams = $handler->parseParamString( $paramString );
[18:44:47] if ( $handler !== false ) {
[18:44:48] I spy bug
[18:47:17] csteipp: what do you mean translations? it won't get i18nupdate?
[18:47:25] or whatever that thing is called
[18:47:30] l10nupdate
[18:49:50] i think i don't want it to have user content. just want it to look reasonable. i.e. not have a redlink just because that's the mediawiki (or WMF) default for a new instance
[18:50:08] csteipp: Grr. "The trick is what do we set it back to if it was null originally" is exactly the problem. I'm tempted to remove the type hinting from RequestContext::setTitle, or else we need a RequestContext::resetTitle().
[18:50:09] Reedy: bug number?
[18:50:09] errr, s/i\.e\./e.g./
[18:50:24] greg-g: Which?
[18:50:30] commons thumb
[18:50:38] https://bugzilla.wikimedia.org/show_bug.cgi?id=55437
[18:50:44] thanks
[18:50:59] anomie: I was just thinking about setting it to Main_Page, just to be super hacky... but yeah, not a great solution
[18:51:31] csteipp: Then we'd just be getting random redirects to Main_Page instead of random redirects to Special:AbuseFilter. Less likely to surprise people, but still not so good.
[18:52:29] anomie: Yeah, but if $oldContextTitle is null, that means $wgTitle was null when $context->getTitle() was called
[18:53:18] csteipp: Exactly. I think allowing RequestContext::setTitle to take null is the solution.
[18:53:59] anomie: Yeah, let me see if we can find out why we type hinted that
[18:54:58] csteipp: Probably because type hinting is usually a good idea, except when you need to be able to pass null.
[18:57:23] anomie: Yeah, doesn't look that that was for any particular reason
[19:02:39] csteipp, Reedy: https://gerrit.wikimedia.org/r/88189
[19:24:56] anomie: what about setting $oldContextTitle = new FakeTitle() if it's null?
[19:26:19] csteipp: I'm guessing an error in includes/Wiki.php line 577, if not sooner.
[19:28:48] anomie: Wouldn't that be in the past, by the time AbuseFilter runs? I'm guessing the hook would be under performRequest()..
[19:29:14] csteipp: If that was in the past, then $wgTitle wouldn't have been null.
[19:30:25] anomie: So I'm thinking another extension is setting wgTitle to null, which is why bug 53498 only happened in production
[19:31:03] But yeah, I could certainly be wrong on that
[19:31:36] And yeah... I am
[19:32:04] Grr
[19:32:08] thedj: what to do about a tif which (on purge) fails thumbnailing, then succeeds, then fails again etc.
[19:32:41] ie R eedy> Importing Karrotter,_ett_par_med_rechaud-Deep_-_Hallwylska_museet_-_30774.tif...Redis server error: protocol error, got '�' as reply-type byte
[19:41:20] anomie|brb: Actually, another fix would be to move Wiki.php lines 514-555 (redirect you if you have the forceHTTPS cookie) to after where getTitle is called on line 573. That would actually solve the AbuseFilter issue in most (all?) cases...
[19:50:05] csteipp: That would probably work around the identified issue. But there's at least one other code path that's getting us into AbuseFilter before $wgTitle gets set (because the mystery redirect was sometimes happening when the account already existed), and I don't know what that one might be.
[19:50:28] anomie, throw an exception?
[19:52:37] Platonides: For that matter, we could hack a log statement with backtrace into AbuseFilter.
[19:53:57] that's a more crafted hack :)
[19:55:49] So if we did https://gerrit.wikimedia.org/r/#/c/88203/, it would still cause an exception in the non-autocreate case... which might be a good thing to track down why it's happening
[19:56:49] Although we should probably grep the logs and see if that case has been hit since sam deployed this branch
[20:00:52] csteipp_afk: That's a good idea. I just did so, and the only hits for setTitle(NULL) were from the SUL account creation code path.
[20:16:59] anomie: dodnt yo have a wiki where you could reproduce the issue with your account?
[20:17:31] burrito-type fail.. "didn't you..."
[20:18:24] csteipp: No, I was reproducing it on the production wikis.
[20:19:10] anomie: yeah, but wasn't that for a non-autocreate case?
[20:19:23] Or was that actually autocreating?
[20:20:48] csteipp: I was reproducing it on production wikis, including for the non-autocreate case. But I can't seem to reproduce that anymore; it seemed like it was somehow once per wiki, and I seem to have used up all the wikis my account was on that would do it.
[20:24:42] csteipp: usually I reliably reproduced it on any special.dblist wiki
[20:24:49] if I understand what you're talking about
[20:25:41] (but I needed at least one en wiki without my account locally)
[20:28:16] Nemo_bis: We're talking about the mysterious redirect to Special:AbuseFilter, when it's not involved with SUL auto-creating a local account.
[20:29:28] ah right that one
[20:50:07] Isarra: hasharCall brion I only noticed https://bugzilla.wikimedia.org/show_bug.cgi?id=53741 right now
[20:50:25] should we close this bug, since that's a feature that still waits to be improved?
[20:51:10] I'm not sure what we'd do with the bug, indeed.
[20:51:40] I'd say we should do things the other way round, ie. make sure that favicons provide as many versions as possible.
[20:51:53] twkozlowski: I am not sure what to do with favicons
[20:52:10] https://bugzilla.wikimedia.org/show_bug.cgi?id=45036#c4 was some sort of a summary, but it was done in April
[20:52:11] twkozlowski: we should probably standardize them in some way or another and make sure we provide whatever is expected by nowadays devices
[20:52:31] hasharCall: yes, 45036 is aiming at that precisely
[20:52:57] twkozlowski: nice catch :)
[20:53:07] twkozlowski: just mark 53741 as a duplicate of 45036 so
[20:53:10] I guess that is fine
[20:53:33] The problem is we don't necessarily know what is expected by devices because they keep changing.
[20:53:41] twkozlowski: I was wondering whether we had to ship several icons instead of one standard size
[20:53:54] Well, that's a question.
[20:54:05] We definitely want the 16 and 32px versions, but beyond that it's up in the air.
[20:54:06] I have no idea, frankly, there are so many systems that use various sizes...
[20:54:25] we can find out :)
[20:54:55] there is even a big to vectorize them: https://bugzilla.wikimedia.org/show_bug.cgi?id=52019 ;D
[20:55:14] twkozlowski: thank you for the bug cleanup :)
[20:56:09] hasharCall: that's for project logos, not favicons :)
[21:05:51] Coren: on a related subject, I think I wanted to fix https://bugzilla.wikimedia.org/show_bug.cgi?id=49350 but didn't know where to submit the new logo.
[21:07:19] twkozlowski: As long as it's on Wikitech, I can link to it.
[21:32:50] * paravoid read about the new attribute
[21:51:21] I envy mozilla's bugzilla theme
[22:00:18] as predicted!