[00:09:08] !log asher synchronized wmf-config/db.php 'returning watchlist queries to db12' [00:09:42] We trying to get lag back? [00:27:58] AndrewN: maybe. call it an experiment :) [00:29:50] Oh great... Doing science? This scares me. :P [00:29:56] jk jk [02:23:09] !log LocalisationUpdate completed (1.20wmf3) at Thu May 24 02:23:09 UTC 2012 [12:51:55] hi [12:52:15] my IP was banned because (I think) I used the API too much, I fixed that in my software, is there a way to get unbanned ? [12:52:37] when was it banned? [12:53:21] 1 or 2 days ago [12:53:32] what's the ip (feel free to pm)? [12:55:05] yes, that's the ip [12:55:30] what were you doing and how did you change your code so you don't do that now? [12:56:12] fwiw. afaik we should always use the maxlag= parameter when making API calls [12:57:03] rguillebert: [12:57:07] I was collecting users and the edits they did in parallel (because that's how my scrapper is configured by default, I changed that) [12:57:44] so now it does them one at a time? [12:57:50] yes [12:58:00] does it use the replag parameter as well? [12:58:05] er maxlag [12:58:21] http://readthedocs.org/docs/scrapy/en/latest/topics/settings.html#concurrent-requests I set that to 1 [12:58:27] no it doesn't [12:58:36] you need to fix your code so it does this [12:58:51] maxlag=5 [12:58:53] http://www.mediawiki.org/wiki/Manual:Maxlag_parameter [12:59:29] when you have done that you can open a bugzilla request, explain what you had done, that your ip got banned, what and what you fixed. [13:00:00] then let folsk in #wikimedia-operations know that you filed a bug etc about this [13:00:17] ok [13:00:21] thanks [13:03:28] you're welcome [13:04:10] I apologized I didn't know it would use so much resources [13:05:44] most of what we do is cached [13:05:51] page views and such [13:06:07] things that get passed through to the back end are a much smaller percentage [13:06:49] we are optimized for the former rather than the latter so we ask people to take some care when doing anything automated [13:08:57] but I don't care if I get stuff that's a day old there's no cache for that ? [13:10:19] no, not for these [13:11:30] ok [13:11:39] caching something likethis isn't so helpful: someone else would have to make the same query to get the cahced pag, and how likely is that, [13:11:52] if you're crawling all the user contribs, as these same users edit [13:12:03] *cached page [13:12:33] anyways, just do what everyone else does: one query at a time, respect db lag, and you're all set [13:13:30] I supposed it's better if I publish my code ? [13:17:31] that's always nice [13:17:54] we encurage people to make their code reusable (and improvable) by others [13:18:00] *encourage [13:18:44] rguillebert: maybe you are interested in using wikimedia labs, publishing your code, and letting it run on an instance there [13:22:39] I'm already running the code on my university's server [13:22:53] (this is for research in my university) [13:24:12] if you are not already on the wikimedia research list maybe you would want to join it [13:24:34] https://lists.wikimedia.org/mailman/listinfo/wiki-research-l [13:25:03] great thanks [13:25:08] sure [13:28:08] another question, is it better to set the aulimit at the highest possible number (500) if I'm sure to use every single user ? [13:28:41] what's the aulimit, the number of results returned at once? [13:30:34] because I think we are applying to the "researcher" status to get the 5000 limit it would probably be nicer [13:30:57] it will be nicer and you should use it if you get it. [13:47:21] hello. Everytime I open Wikimedia Commons in Chrome, I get a message that there's insecure content on the page, and i'm being asked whether i really want to load that content [13:47:34] but when I load it, I don't see much of a difference with when I don't [13:50:09] hmm [13:50:14] Does it tell you the URL of the insecure content? [13:50:31] effeietsanders: Also, does this still happen if you log out? [13:51:07] Cause I can't reproduce this in Chromium, even when logged in [13:52:12] no, the content [13:52:38] hmm, but it doesn't happen always [13:53:08] RoanKattouw: try this page: https://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_2012/Progress [13:53:13] some script issue maybe? [13:53:26] I don't get it logged out [13:53:39] so might be indeed script caused [13:54:46] effeietsanders: I think I know what it might be [13:54:52] I only have https://commons.wikimedia.org/wiki/User:Effeietsanders/vector.js active [13:55:05] effeietsanders: Well duh [13:55:12] effeietsanders: mw.loader.load('http://meta.wikimedia.org/w/index.php?title=User:Krinkle/RTRC.js&action=raw&ctype=text/javascript'); [13:55:14] http [13:55:19] ah [13:55:21] fixed [13:55:41] effeietsanders: your monobook has the same issue, if you use it at all [13:55:56] I don't any more, but thanks :) [13:56:29] fixing it just in case [13:56:46] *and another happy customer leaves the building [13:56:48] * [13:58:45] effeietsanders: you might want to simply delete both of those and move to common.js, which is used by both vector and monobook [13:58:53] RoanKattouw: i found an existing page without any existing revision: http://kv.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%B8_%D1%80%D0%B5%D1%81%D0%BF%D1%83%D0%B1%D0%BB%D0%B8%D0%BA%D0%B0%D0%BB%D3%A7%D0%BD_%D0%BA%D0%B0%D0%BD%D0%BF%D0%B0%D1%81?redirect=no [13:59:18] Merlissimo: https://kv.wikipedia.org/w/index.php?title=%D0%9A%D0%BE%D0%BC%D0%B8_%D1%80%D0%B5%D1%81%D0%BF%D1%83%D0%B1%D0%BB%D0%B8%D0%BA%D0%B0%D0%BB%D3%A7%D0%BD_%D0%BA%D0%B0%D0%BD%D0%BF%D0%B0%D1%81&action=history claims there is a revision [13:59:24] Merlissimo: I see a revision https://kv.wikipedia.org/w/index.php?title=%D0%9A%D0%BE%D0%BC%D0%B8_%D1%80%D0%B5%D1%81%D0%BF%D1%83%D0%B1%D0%BB%D0%B8%D0%BA%D0%B0%D0%BB%D3%A7%D0%BD_%D0%BA%D0%B0%D0%BD%D0%BF%D0%B0%D1%81&action=history [13:59:28] oh, roan beat me to it [13:59:50] Snowolf: can you edit it? [13:59:54] Although https://kv.wikipedia.org/w/index.php?title=%D0%9A%D0%BE%D0%BC%D0%B8_%D1%80%D0%B5%D1%81%D0%BF%D1%83%D0%B1%D0%BB%D0%B8%D0%BA%D0%B0%D0%BB%D3%A7%D0%BD_%D0%BA%D0%B0%D0%BD%D0%BF%D0%B0%D1%81&action=edit&uselang=en freaks out [14:00:06] output at kv.wikipedia.org/w/api.php?action=query&prop=revisions&titles=Коми_республикалӧн_канпас is different [14:00:31] Snowolf: nah, too easy ;) (and who knowws, maybe some day I actually *want* to try out another skin without krinkle's stuff ;) ) [14:00:47] effeietsanders: heresy, don't let him hear you :P [14:00:47] Merlissimo: I see the same single revision there [14:01:27] Snowolf: I doubt he reads any of what I say ;) [14:01:40] RoanKattouw: i am getting no revision [14:01:40] [14:01:40] [14:01:40] [14:01:40] (Served by srv194) [14:01:45] The-all-reading-Krinkle [14:02:57] Merlissimo: That's because you set rvprop=content . It's showing a single revision with empty content, that's the tag. Try again without an &rvprop= parameter [14:04:13] so the content ist lost? [14:04:23] There's no content there no [14:04:28] Does deletedrevs show anything? [14:04:55] history shows 23:18, 9. Mär. 2009‎ Yufereff (Diskussion | Beiträge)‎ . . (88 Bytes) - so there must be 88 bytes [14:05:08] and according to database it should be a redirect [14:05:28] Looking at the DB now [14:06:06] page_len is also 88 [14:06:53] select * from redirect where rd_from = 5195; [14:06:53] +---------+--------------+------------------------------------------------------+--------------+-------------+ [14:06:53] | rd_from | rd_namespace | rd_title | rd_interwiki | rd_fragment | [14:06:53] +---------+--------------+------------------------------------------------------+--------------+-------------+ [14:06:53] | 5195 | 0 | Коми_республикалӧн_канпасыс | NULL | NULL | [14:06:53] +---------+--------------+------------------------------------------------------+--------------+-------------+ [14:08:38] | 18933 | | | DB://cluster20/0 | [14:08:56] The text table entry for the revision is invalid [14:09:16] It tells MW to look in the blobs_cluster20 table for the row with blob_id=0 [14:09:23] But blob_id starts counting at 1 [14:12:53] the easiest solution would be to delete that page and recreate it with a redirect to http://kv.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%B8_%D0%A0%D0%B5%D1%81%D0%BF%D1%83%D0%B1%D0%BB%D0%B8%D0%BA%D0%B0%D1%81%D0%B0_%D0%BA%D0%B0%D0%BD%D0%BF%D0%B0%D1%81 Can you do it? or Snowolf? [14:13:26] I can do it [14:13:41] unless roan wants/needs to do stuff server-side with it [14:14:13] RoanKattouw: is it okey for me to delete it and fix it? [14:14:17] Yeah go ahead and fix it [14:14:28] the page was found by a bot fixing double redirects [14:14:38] It's a weird DB corruption issue, but the corruption probably occurred in 2009 [14:14:48] Or during one of the recompression runs [14:16:18] Merlissimo: deleted and redirected, also moved the talk page that for some reason was never moved [14:17:09] thx Snowolf [14:17:13] and RoanKattouw [14:18:19] Toolserver finds only one row on kvwiki that was corrupted in this way [14:28:46] !log catrope synchronized wmf-config/CommonSettings.php 'Removing 'version' override for AFTv5 bucketing config' [14:38:20] hmm, Snowolf , I still have the problem on nl.wikimedia - and I don't think I have a vector.js or anything running there. I don't have it logged out. I'm logged in as user:Lodewijk . [14:38:33] any idea what it might be? [14:57:32] effeietsanders: lemme see [14:57:41] I imagine it could be people on common.js not using // [14:58:35] Snowolf: just delete the http: everywhere/ [14:58:37] ? [14:58:49] effeietsanders: lemme see, no this stuff should be fixed [14:59:42] effeietsanders: ugh the images for the donate button are http:// :( [15:00:05] would it help to just delete the http: ? [15:00:13] or should I get them to put it on https first? [15:00:15] effeietsanders: nope, http://donations.wmnederland.nl/ has not https [15:00:19] ok [15:00:21] So there's no way for me to fix it :( [15:00:34] well [15:00:46] we could import the images on nl.wikimedia.org [15:01:08] hmmm wait [15:01:19] the image is already protocol neutral [15:01:21] o_O [15:01:54] apergos, is https://bugzilla.wikimedia.org/ the bug tracker I should post to ? [15:02:25] yes. that's the one [15:02:50] effeietsanders: I really can't tell what the problem is, maybe the tracking script at https://nl.wikimedia.org/wiki/MediaWiki:Common.js ? [15:04:18] i dont know :) [15:04:28] I think it's that tracking script [15:04:47] But I don't speak any js so I'm not really sure, but it seems really likely [15:07:35] ok, I'll take it up with the people who set that up :) [15:11:44] Yes, the tracking part is definitely problematic, it loads an http URL [15:23:17] apergos: sorry to bother you again, but can you put http://dl.dropbox.com/u/8768784/Wikipedia-v1.2RC1.apk into dumps.wikimedia.org/android [15:23:17] ? [15:24:52] done [15:27:53] apergos: thanks much :D [16:30:27] is there any special page to perform the same thing has robots.txt ? [16:35:04] Alchimista: see http://www.mediawiki.org/wiki/Noindex [16:35:27] Alchimista: If you want help with a local MediaWiki install, see #mediawiki [16:35:43] this channel is for the wikimedia foundation technical stuff [16:36:05] well, it's about a wikimedia project ;) [16:36:53] oh okay then [16:37:27] as far as I know, robots.txt isn't accessible through mediawiki [16:37:55] but there is noindex, as T3rminat0r mentioned [16:38:15] if you want robots.txt changed for a project I think you need to file a bug in bugzilla [16:38:53] so to exclude subpages there is only the option of using __NOINDEX__ ? [16:39:50] i mean, there is a case like rfd, where all subpages should be not be indexed [17:26:54] !log awjrichards synchronized php-1.20wmf3/extensions/MobileFrontend/javascripts/application.js 'MobileFrontend bug fix for bug 37059' [17:28:39] !log awjrichards synchronized wmf-config/CommonSettings.php 'Bumping MobileFrontend resource version' [17:30:17] !log preilly synchronized php-1.20wmf2/extensions/ZeroRatedMobileAccess 'changes for zero needed for carrier testing' [17:30:53] !log preilly synchronized php-1.20wmf3/extensions/ZeroRatedMobileAccess 'changes for zero needed for carrier testing' [18:52:22] !log catrope synchronizing Wikimedia installation... : Deploying ArticleFeedbackv5 updates [19:06:32] sync done. [20:11:04] !log awjrichards synchronized php-1.20wmf3/extensions/CentralNotice/ 'Updating CentralNotice 8309819' [20:11:16] pgehres ^ [20:11:50] where is morebots???? [20:12:07] http://wikitech.wikimedia.org/view/Server_admin_log does not show the latest changes :/ [20:17:46] !log awjrichards synchronized php-1.20wmf3/extensions/LandingCheck/ 'Updating LandingCheck 2836d75' [20:21:15] !log awjrichards synchronized php-1.20wmf3/extensions/ContributionTracking 'Updating ContributionTracking c3d8969' [20:36:51] !log awjrichards synchronized wmf-config/CommonSettings.php 'Enabling ContributionTrackingUTMKey' [20:53:24] !log awjrichards synchronized php-1.20wmf3/extensions/ContributionTracking/ 'Updating ContributionTracking 50d89c8' [21:01:09] !log awjrichards synchronized php-1.20wmf3/extensions/ContributionTracking/ 'Updating ContributionTracking 50d89c8 again - appears to have not taken on donate and foundation wikis the previous time' [21:05:21] looks like morebots is dead [21:05:31] * p858snake|l pokes ^demon with a stropwaffle [21:05:56] <^demon> I can do nothing about morebots. [21:11:52] !log awjrichards synchronizing Wikimedia installation... : Attempting to pick up changes for LandingCheck and ContributionTracking that did not appear to sync properly to donatewiki and foundationwiki using sync-dir [21:23:20] sync done. [21:24:50] awjr: are there i18n changes? [21:25:14] awjr: Special:Version looks correct now [21:28:41] AaronSchulz: no i18n changes [21:28:45] !log synchronized payments cluster to DonationInterface 221a36a00c1b [21:29:10] RoanKattouw: scap ocompleted (no log msg tho?) and appears to have picked up the changes [21:29:15] so i wonder if something is busted with sync-dir [21:29:36] yay [21:38:56] !log aaron synchronizing Wikimedia installation... : Updating UploadWizard [21:40:15] RoanKattouw: morebots, if you can >.> [21:47:49] * AaronSchulz should make the pre scap-2 state log a msg [21:48:06] brion: UW should be updated now [21:48:18] scap is justing futzing with texvc now [21:48:31] heh [21:48:38] AaronSchulz: just merged in one more bugfix ;) [21:48:52] of course if I commit that change to scap it will take ages to get approved [21:49:16] ah texvc [21:49:35] compiling is such fun [21:49:48] ohi brion [21:50:01] domas: yo yo [21:50:31] brion: I can see you! [21:50:36] well, I can see some SF downtown [21:50:38] :) [21:50:41] :D [21:50:57] sync done. [21:52:29] !log Restarted morebots [21:52:33] Logged the message, Mr. Obvious [21:52:43] p858snake|l: ---^^ [21:52:52] snarkybot [21:53:55] !log aaron synchronized php-1.20wmf3/extensions/UploadWizard 'deployed 144b58854e38d910210ccd23402225e5b1d2d62d' [21:53:59] Logged the message, Master [21:54:29] brion: anything else? [21:54:47] AaronSchulz: should be the last of em [21:55:36] nice, it's doing the auto-upload now [21:55:41] should we feed morebots what it missed? [21:56:06] https://commons.wikimedia.org/w/api.php?action=uploadcampaign \o/ [21:56:17] now i can start using that in wiki loves monuments mobile woot [22:08:10] gn8 folks [23:12:05] !log awjrichards synchronized wmf-config/CommonSettings.php 'Enabling 'technical feedback' link on mobile feedback form to disable feedback form' [23:12:09] Logged the message, Master [23:17:00] !log awjrichards synchronizing Wikimedia installation... : Picking up changes to hide feedback form to prevent spamming of mobile feedback page - f6ed8ba [23:17:04] Logged the message, Master [23:30:32] sync done. [23:32:27] !log awjrichards synchronized wmf-config/CommonSettings.php 'Updating technical feedback email address for mobile feedback' [23:32:31] Logged the message, Master [23:34:51] !log awjrichards synchronized wmf-config/CommonSettings.php [23:34:55] Logged the message, Master [23:36:38] binasher: https://bugzilla.wikimedia.org/show_bug.cgi?id=31306 lol [23:42:15] maplebed: I should assign https://bugzilla.wikimedia.org/show_bug.cgi?id=34717 to you :D [23:42:58] AaronSchulz: umm.. . if you want. I'm not going to do anything about it (besides what I'm already doing). [23:43:36] also, that bug is complaining about two different things. which is the one it's acutally about? [23:43:41] the slow or the reverted twice? [23:44:06] slowness [23:44:32] reverting a file is just a re-upload, which does a purge [23:47:03] I don't have an opinion on who the bug should be assigned to. if it makes you (or someone else) happier to have it assigned to me than you, go right ahead.