[00:31:33] techy people! any clue why i am able to visit secure wikipedia but not regular wikipedia? pages won't load at all [00:32:08] Someguy1221, eww. Non-secure pages. [00:32:18] Who uses those anymore. [00:32:20] :p [00:32:23] lol [00:32:58] speaking of which, is there a script to automatically send me to the secure version of a page if i have followed a link to a non-secure page? [00:33:40] I think you can write one yes. Be aware that if you're not logged in, the script won't work. [00:33:56] https://www.eff.org/https-everywhere [00:34:14] in all seriousness, b4 assuming this is a global issue, Someguy1221, do reboot your Windows machine. It's TCP stack may have wedged on port 80 [00:35:02] marek: i always tell people to reboot their machine, but for some reason whenever i have a problme, i never do that [00:35:24] Reedy, oooh. Thanks Reedy [00:35:26] It's a great fixerer [00:35:27] it's the doctor who does not heal themselves or the shoemaker that goes barefoot syndrome [00:36:11] marktraceur: Someguy1221 is tim berners-lee? [00:36:26] er, that was at mareklug [00:37:20] ori-l I would not lay the Windows TCP stack implementation on Tim [00:42:53] restarting your browser can help sometimes, I've seen that happen [00:43:20] hey TimStarling [00:43:24] I've seen the connection pool be exhausted due to a resource leak [00:43:25] https://graphite.wikimedia.org/render/?title=Average%20Latency%20Of%20All%20PHP%20Requests%20-1day&from=-1day&width=1024&height=500&until=now&areaMode=none&hideLegend=false&lineWidth=1&lineMode=connected&target=color%28cactiStyle%28alias%28-total.tavg,%20%22Avg%20PHP%20Request%20Latency%20%28ms%29%22%29%29,%22blue%22%29&target=color%28cactiStyle%28alias%28-total.tp50,%20%2250%25%20PHP%20Request%20Latency%20%28ms%29%22%29%29,%22green%22%29 [00:43:26] hello [00:43:32] looks like 11am PDT [00:43:39] maybe if you were using IE you might need to log out to kill it properly [00:43:42] there's also the much worse week effect [00:43:42] https://graphite.wikimedia.org/render/?title=Average%20Latency%20Of%20All%20PHP%20Requests%20-1week&from=-1week&width=1024&height=500&until=now&areaMode=none&hideLegend=false&lineWidth=1&lineMode=connected&target=color%28cactiStyle%28alias%28-total.tavg,%20%22Avg%20PHP%20Request%20Latency%20%28ms%29%22%29%29,%22blue%22%29&target=color%28cactiStyle%28alias%28-total.tp50,%20%2250%25%20PHP%20Request%20Latency%20%28ms%29%22%29%29,%22green%22%29 [00:43:50] I've been telling binasher too [00:44:28] see with code deploys - [00:44:28] https://graphite.wikimedia.org/render/?target=alias(color(dashed(drawAsInfinite(deploy.sync-common-file)),%22c0c0c080%22),%22sync-common-file%22)&target=alias(lineWidth(color(drawAsInfinite(deploy.sync-common-all),%22gold%22),2),%22sync-common-all%22)&target=alias(lineWidth(color(drawAsInfinite(deploy.scap),%22white%22),2),%22scap%20deploy%22)&title=Average%20Latency%20Of%20All%20PHP%20Requests%20-1day&from=-1day&width=1024&height=500&until=now&area [00:44:29] =none&hideLegend=false&lineWidth=1&lineMode=connected&target=color(cactiStyle(alias(-total.tavg,%20%22Avg%20PHP%20Request%20Latency%20(ms)%22)),%22blue%22)&target=color(cactiStyle(alias(-total.tp50,%20%2250%25%20PHP%20Request%20Latency%20(ms)%22)),%22green%22) [00:44:39] have you got any theories? [00:44:44] not yet [00:45:57] this is from MW profiling? [00:47:19] yes [00:47:34] https://gdash.wikimedia.org/dashboards/datastores/ is fun too [00:47:49] ES gets spike [00:48:15] mysql over the past week too [00:49:25] binasher: I'm guessing "code deploys" is when the deploy finished, not started? [00:49:52] yeah, slave query count [00:50:19] if the slave query count has gone up by a factor of 4, that should be pretty easy to diagnose, by sampling the traffic [00:51:18] deployment calendar only has [00:51:19] re-add supported namespaces on enwiki for AFT (Matthias) [00:51:20] for today [00:51:26] doesn't look like memcached evictions / misses - http://ganglia.wikimedia.org/latest/stacked.php?m=mc_get_misses_rate&c=Memcached%20eqiad&r=week&st=1366332642&host_regex= [00:51:36] paravoid: the server admin log shows a lot of deploy action though [00:52:42] is memcached working? [00:53:15] yes. http://ganglia.wikimedia.org/latest/stacked.php?m=mc_get_hits_rate&c=Memcached%20eqiad&r=week&st=1366332778&host_regex= [00:53:17] which server? [00:53:29] haha, we got domas' attention [00:53:33] (example one) [00:53:59] https://graphite.wikimedia.org/render?from=-2days&until=now&width=1024&height=600&target=highestMax(query.SELECT.*.count%2C10)&uniq=0.46625182102434337&title=highestMax(query.SELECT.*.count%2C10) [00:54:03] ( need to run in few secs) [00:54:05] the queries [00:54:18] i should include that sort of graph on gdash :) [00:54:24] meh [00:54:58] binasher: you should! [00:55:10] https://graphite.wikimedia.org/render?from=-2days&until=now&width=1024&height=600&target=highestMax(query.SELECT.*.count%2C4)&uniq=0.46625182102434337&title=highestMax(query.SELECT.*.count%2C4) [00:55:41] that's awesome [00:55:44] domas hates getting information from pretty pictures ;) [00:55:58] I love that :) [00:56:27] those pictures don't tell lots of context [00:57:05] no, but they help narrow down what to look at next - at least for me [00:57:57] well, the spike in ES gets is pretty diagnostic [00:58:22] probably a slave query sample will just show Revision::getRevisionText() [00:58:27] or some related query [01:00:59] LinkCache::addLinkObj [01:01:11] is the query with the biggest spike (SELECT page_id, page_len, page_is_redirect, page_latest FROM `page` WHERE page_namespace = ? AND page_title = ? limit ?) [01:02:17] it's probably two separate events [01:04:36] https://ishmael.wikimedia.org/sample/more.php?host=db1050&hours=24&checksum=484571594445205663 [01:04:42] uncensored for the time being [01:07:22] yes, that spike is at the wrong time of the day [01:07:38] we want something that starts at around 18:15 and stays high until now [01:08:15] not something that starts at 14:25 and finishes an hour later [01:08:38] the time on that page isn't relevant [01:08:55] time is query time aiui [01:09:10] it's not number of queries [01:09:23] the spike on that page is still very negligible [01:09:39] it isn't like that query is what's causing the php run time increase [01:09:52] erm [01:10:22] Revision::getRevisionText() is indeed correlated [01:10:27] I'm guessing ishmael is smart enough that the reported query counts ignore the comments, right? [01:10:50] paravoid: right [01:11:19] paravoid: those counts are just from maybe 2 minutes of total sampling per hour [01:12:32] ok, Parser::braceSubstitution-loadtpl is also correlated [01:13:53] addLinkObj() is normally from template inclusion, that's why I thought of it [01:13:57] https://graphite.wikimedia.org/render/?title=10%20Most%20Deviant%20Parser%20Methods%20by%20Call%20Rate%20log(2)%20-1day&from=-1day&width=1024&height=500&until=now&areaMode=none&hideLegend=false&logBase=2&lineWidth=1&lineMode=connected&target=cactiStyle(substr(mostDeviant(10,maximumAbove(Parser.*.count,1)),1,2)) [01:14:53] hrm that didn't paste properly [01:15:16] Add two )) [01:15:23] http://bit.ly/17twpjo [01:15:30] there's no spike in Parser::parse() count [01:15:45] so Parser::braceSubstitution is probably as far up the stack as the count spike goes [01:16:25] further up, we'll just be looking for service time increases [01:27:29] not really helpful, but a udpprofile trace from a full request http://pastebin.mozilla.org/2318685 [01:32:22] binasher: I think it's just profiling changes [01:32:37] what do you mean? [01:33:09] cli scripts where added to profiling around 19:00 apr 17 using a cli- profile ID prefix (see report.py) [01:33:31] graphite is just collecting everything regardless of profile ID or anything, so it will include those [01:33:42] great [01:33:44] so it will seem like the site got slower even if it didn't [01:33:52] there's increased avg latency & SQL query spikes [01:34:15] what does cli include? [01:34:26] paravoid: according to what? I doubt much outside graphite [01:34:33] lots of long running shit [01:34:35] paravoid: refreshlinks jobs [01:34:43] job runners [01:34:44] oh, jobs too... [01:34:47] bleh [01:34:50] page, revision, es queries [01:35:18] the kind of stuff that went up on the graphs [01:35:36] and what about today's increase right after the deployment window? [01:35:50] also the sample ratio is different, so it's more distorted [01:36:08] any increase today would just be bad, yes :) [01:37:28] https://gdash.wikimedia.org/dashboards/totalphp/ etc. [01:37:45] there's a 2x increase in the graphite graphs apr 17, but a large increase today.. could still be job or cron related [01:38:04] there's no point in looking at any of this right now [01:38:12] binasher: would it be difficult for graphite to filter out those cli entries? [01:38:13] it could be, but it's right on the window [01:38:38] ideally they'd have their own graphs, though that would take more work [01:39:09] Aaron|home: that would be done in operations-software/udpprofile/profiler-to-carbon [01:39:34] as long as cli is on http://noc.wikimedia.org/cgi-bin/report.py that's probably enough to be useful without graphite [01:39:40] for now [01:40:05] dbs =('all', 'stats/all') [01:40:26] hmm, the others IDs have MW versions so they are moving targets [01:40:29] meh, if cli goes in all within the collector, it can't really be filtered [01:40:43] i don't like this [01:40:55] can we send cli stats to an entirely different collector instance? [01:41:12] are cli status also mw versioned? [01:41:18] yes [01:41:51] grr [01:42:06] the cli code sends stats without a cli prefix [01:42:16] binasher: http://noc.wikimedia.org/cgi-bin/report.py?db=cli-1.22wmf2 has all the profile IDs [01:42:20] cli-1.22wmf1 - 1 0.008001 0.000064 0.006228 0.000039 CommonSettings.php-ext-include1 [01:42:26] but also [01:42:27] stats/1.22wmf1 - 1 1 1 1 1 image_cache_hit [01:42:32] so that's broken imo [01:44:58] Aaron|home: https://gdash.wikimedia.org/dashboards/datastores/ shows today's issue, still unclear if it's a random cli that happened to run at that time [01:45:45] a CLI that spiked mysql from 250K to 1000K queries... [01:46:25] so, who should we tell for someone to take a look? [01:46:41] elseif ( PHP_SAPI == 'cli' || ( mt_rand( 0, 0x7fffffff ) % 50 ) == 0 ) [01:46:44] paravoid: though the sampling is fucked [01:46:50] the cli stuff is profiling 100% [01:46:53] why?? [01:47:22] binasher: it makes sense when it's by itself, but it can't be mixed [01:47:45] paravoid: I'm turning this off until it can go to its own thing [01:47:53] Aaron|home: do you mind if we revert Ic9869df24c0f4761ac3df171a78f4c032c83b754 and think about how to do this better? [01:49:04] hehe i like how StartProfiler.php has a "# WTF is this for?" comment [01:49:56] let's hear bets on whether stats will drop to pre-Apr 17th numbers [01:50:26] wow git log being annoying [01:54:38] i guess any running crons will need to finish and the runners too for it to take effect [01:55:04] for runners, that's like ~2 min [01:55:19] except maybe some TMH ones [01:56:22] binasher: anyway, the number of cli scripts run should be very modest compared to web requests, so doing 1:50 or something like that would make kind of useless [01:57:02] if only it could just affect report.py and not graphite [01:57:27] even for report.py, probably don't want it in the all view? [01:57:44] [[Tech]]; Killiondude; /* Classic skin and CSS */ reposition (they took away my monobookish editing bar....); https://meta.wikimedia.org/w/index.php?diff=5404800&oldid=5403537&rcid=4086386 [01:57:48] latency went down already [01:58:22] data stores too [01:58:32] binasher: not if the sample rates are different [01:58:50] I remember thumb.php used to have a different sampling rate for the longest [01:58:56] i think to the pre apr17 levels [01:59:08] domas was complaining how 50% of cluster time was spent on thumbnails one day ;) [01:59:32] "all" is kind of useless [01:59:42] Aaron|home: if you want to keep the sampling for cli > 1:50, we should either modify the collector to not include cli in all [01:59:58] or use a different instance [02:01:08] the stats will have to gain a cli prefix if we don't use a different collector instance [02:02:55] and Aaron|home was right [02:03:08] all this was a wild goose chase [02:03:21] :( [02:03:40] well, at least there was no real problem [02:03:41] there's that :) [02:03:59] yeah! heh [02:04:22] 5am, [02:04:24] that's my cue [02:04:25] how hard would another collector and report.py thing be? [02:04:31] goodbye :) [02:04:37] paravoid: O.O [02:04:46] man, graphite is both really neat in its ability to form interesting queries across the data but.. it would be nice if the underlying timeseries database had more features [02:04:53] night paravoid :) [02:05:53] it would be nice if each statdb could include arbitrary metadata for any time point and multiple dimensions [02:07:06] Aaron|home: not hard, but it might be cleaner to not have a different report.py and instead extend it to support polling multiple collectors [02:07:42] seems like lots of stuff will need tweaks [02:07:50] now i want to write my own tsd [02:08:15] binasher: anyway, the wikidata people would like some idea of how their cli stuff is doing [02:08:47] and in general, it would be nice to have the info...it's possible that some bug or something could slow it down and you might see one function call show up as taking forever [02:08:51] i'm not sure if report.py aggregating all cli stuff is going to help that much [02:08:54] right now it's all a black box [02:09:01] but i guess it's a start [02:09:50] i'd like us to have something that collects profiling data on a per trace basis [02:10:52] where we could both browse traces, and look at timing aggregates across traces filtered by various constraints.. uri search, script name or argument, etc [02:11:26] that would be fun [02:11:47] so they want profiling data that is specific to their crons or just certain job types? [02:12:25] I'd assume they'd at least want the dispatcher and ChangeNotification jobs profiled [02:13:30] if cli && jobrunner profiling prefix = jobtype? [02:13:37] instead of cli [02:15:24] well those jobs get run along with other jobs in the same script instance [02:15:39] I guess the profiler could keep turning on and off ;) [02:15:46] and we should come up with a way to provide graphite graphs for different db types.. probably on different hardware, the ui supports federated ts dbs across hosts [02:16:13] i think changing the prefix in a script mid-run multiple times should be ok and doable [02:16:19] oh [02:16:23] that would require some bigger changes [02:16:27] but still [02:16:55] i should go home, lets talk more tomorrow [02:17:07] * Aaron|home is home [02:17:28] lucky :p [02:17:29] binasher: "sorry about the mess" [02:18:09] :) [04:08:46] RD's a deletionist. [04:08:50] https://ganglia.wikimedia.org/latest/graph.php?c=MySQL%20eqiad&h=db1046.eqiad.wmnet&v=1.27&m=load_one&r=custom&z=xlarge&jr=&js=&st=1366344402&cs=04%2F19%2F2013%2003%3A35%20&ce=04%2F19%2F2013%2004%3A15&vl=%20&ti=One%20Minute%20Load%20Average [04:08:52] lol [04:08:54] https://ganglia.wikimedia.org/latest/graph.php?c=MySQL%20eqiad&h=db1048.eqiad.wmnet&v=1.27&m=load_one&r=custom&z=xlarge&jr=&js=&st=1366344402&cs=04%2F19%2F2013%2003%3A35%20&ce=04%2F19%2F2013%2004%3A15&vl=%20&ti=One%20Minute%20Load%20Average [04:08:56] Shhhhhh! [04:09:01] :-) [04:09:21] in otrs 3.2 we can bulk-forward emails ;-) [04:09:26] that's new, and potentially scary [04:09:42] we as in all agents [04:12:48] * jeremyb_ thought domas would like to see someone doing OTRS DB maint. :-) [06:42:54] apergos: ping [06:46:20] legoktm: ponnngggg [06:46:28] hi! [06:46:31] hello! [07:23:46] http://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&list=categorymembers&format=json&cmtitle=Category%3APhysics&cmprop=ids|title|timestamp&cmlimit=10&cmsort=timestamp&cmstart=2013-01-10%2000%3A00%3A00&cmend=2013-04-31%2023%3A59%3A59&generator=categories&gcllimit=10 why doesn't the generator list what categories each returned result page belongs to? thanks [07:30:51] I really wish it made an error of some sort instead of silently doing nothing ... [07:31:23] https://en.wikipedia.org/w/api.php?action=query&list=categorymembers&format=jsonfm&cmtitle=Category%3APhysics&cmprop=ids|title|timestamp&cmlimit=10&cmsort=timestamp&cmstart=2013-01-10%2000%3A00%3A00&cmend=2013-04-31%2023%3A59%3A59&generator=categories&gcllimit=10 [07:31:26] that's what i see? [07:31:41] gry: if i had a dollar for every time i thought that to myself [07:31:53] gry: oh i see your problem [07:32:09] you need to prefix the options with "g" [07:32:16] so cmtitle --> gcmtitle [07:33:16] erwait [07:35:49] bleh [07:35:49] https://en.wikipedia.org/w/api.php?action=query&generator=categorymembers&format=jsonfm&gcmtitle=Category%3APhysics&gcmlimit=10&gcmsort=timestamp&gcmstart=2013-01-10%2000%3A00%3A00&gcmend=2013-04-31%2023%3A59%3A59&prop=categories&gcmlimit=10 [07:35:54] i just fixed it too! [07:36:12] [02:36:05 AM] -MemoServ- gry's inbox is full :( [09:48:44] legoktm, thanks, I didn't realise generator gives pages -to- the main query, not takes from it [09:49:05] yup! [09:49:08] did you read the docs? [09:49:23] https://www.mediawiki.org/wiki/API:Query#Generators [09:51:18] well it's at the API sandbox page too, the "Get the list of pages to work on by executing the specified query module." bit but I totally missed it [09:52:07] I work in the Special api sandbox page, so the docs are present inline and usually are self explanatory but it was hard to assume that I got things the exact opposite of what they are [09:55:46] ah [09:56:01] well I tend to prefer just using the actual query and &format=jsonfm [10:07:47] legoktm: apisandbox is awesome :) [10:08:15] the one major useful thing I noticed it can do is make post requests when you want to test something [10:08:38] yup [10:30:50] "Some parts of the edit form did not reach the server; double-check that your edits are intact and try again. [10:30:58] damn connection [11:47:25] how do I find who created a page? I have its page id and I assume it likely was renamed at least once [11:47:32] (using the mediawiki api) [12:01:38] gry, get the list of revisions, showing at most one and sorted with earliest date first [12:04:00] [[Tech]]; DragonflySixtyseven; /* Classic skin and CSS */; https://meta.wikimedia.org/w/index.php?diff=5405889&oldid=5404800&rcid=4087658 [13:23:10] hey could anyone help me moving an image that has been flagged from wikipedia to commons? [13:26:34] help you how? [13:27:23] well the commons helper always shows me an error message: Achtung : Cannot get description from the text [13:27:49] which image? [13:28:08] http://en.wikipedia.org/wiki/File:Logo_Philipp_Plein.jpg [13:29:34] uhm, yeah don't move that to commons [13:30:15] it's a non-free file [13:31:35] well there was a discussion going on that it would qualify as PD-textlogo [13:34:30] http://en.wikipedia.org/wiki/Wikipedia:Media_copyright_questions#File:Logo_Philipp_Plein.jpg [13:40:16] so what do you think? reflag as text logo? [13:42:41] how can I check whether a page is sighted for a wiki that has flaggedrevs installed? [13:45:56] mauro2478: well then in that case you can revert me and replace all that non-free stuff with {{PD-textlogo}} and {{trademark}} [13:46:46] ok thanks [13:52:58] [[Tech]]; DragonflySixtyseven; /* Classic skin and CSS */; https://meta.wikimedia.org/w/index.php?diff=5406141&oldid=5405889&rcid=4087949 [15:04:53] Riley|Work: please check your bot, it floods the rc channels [15:05:07] which channel? [15:05:27] #cs.wiktionary [15:23:34] Danny_B there is no such a channel :o [15:44:04] petan: ? [15:44:18] jeremyb_ if he's talking about freenode [15:44:30] he's talking about the wikimedia irc network. not freenode [15:44:32] on wikimedia irc nobody cares, that network isn't really for humans [15:44:41] uhuh [15:44:47] he can set up ignore for join / part events [15:44:53] they are useless there [15:45:00] this is definitely not the first time i've heard a complaint about join/part spam there [15:45:09] but... who cares? [15:45:15] anyway, the point is the channel exists [15:45:15] it is irrelevant [15:45:21] ok, there it exist [15:45:28] but join part flood doesn't matter at all [15:45:43] you and Danny_B can decide that without me [15:51:28] Hi - http://en.wikipedia.org/wiki/Category:Wikipedia_files_lacking_a_description - Is there an issue with thumbnail generation? [15:53:39] Because I'm not seeing them [15:54:11] Qcoder00: where are you? [15:54:15] what are you seeing? what browser? [15:54:16] UK [15:54:20] Firefox [15:54:34] Qcoder00: and https://commons.wikimedia.org/wiki/special:newfiles ? [15:54:44] hit ctrl-shift-k and leave that open while loading stuff [15:54:56] Displays but slowly [15:55:54] OK getting a number of 503 errors [15:56:06] On image requests [15:56:09] click on one and give me the headers in a pastebin [15:56:14] dpaste.com [15:56:33] (the response headers) [15:57:25] Sample: http://dpaste.com/1065035/ [15:58:18] well that is interesting.... [15:58:43] It only started doing this a few miniutes ago [15:58:49] About 5-10 mins ago [15:59:00] I've already done a cache purge here [15:59:13] errrr, not formatted so great! /me reformats [15:59:27] http://upload.wikimedia.org/wikipedia/en/b/bd/Metplate.jpg itself is a 503 [15:59:39] not for me! [15:59:40] ahha, confirmed, esams upload varnish'es not grabbing that thumbnail [15:59:53] jeremyb_, try from Europe? [16:00:02] Platonides: buy me a ticket? :-) [16:00:13] wget -S -U Malyacko --header 'host: upload.wikimedia.org' 'http://upload.esams.wikimedia.org/wikipedia/en/b/bd/Metplate.jpg' [16:00:21] getting 404's and 503's [16:00:35] Something wrong on my side? [16:00:44] Qcoder00: no [16:00:50] just on your side of the pond :) [16:01:20] So it's localised to Europe OK [16:01:56] checking this out in the #wikimedia-operations channel [16:08:12] should be better now [16:24:02] so... we have a [[how to debug]] on mediawikiwiki. we need an equivalent telling people how to traceroute, use browser debug consoles, etc. [16:24:35] it was a happy coincidence that I happened to know what to do for the browser Qcoder00 was using [16:25:01] but i don't remember offhand for chrome and have no easy current access to IE [16:25:14] maybe such a page exists and i just don't know about it [16:25:50] jeremyb_: That seems simple enough, though it'll take some filling out from people with various browsers [16:25:57] right [16:26:03] jeremyb_: this seems like something that should exist *outside of the Wikimedia tech sphere* [16:26:17] sumanah: where's a good home for it? [16:26:27] because it is not Wikimedia-specific [16:26:35] I don't know. Wikihow? [16:26:44] a lot of [[how to debug]] isn't wikimedia specific [16:26:53] or even mediawiki [16:27:08] OK. Just my opinion. [16:27:18] jeremyb_: Her point, I think, is that we could link to existing resources [16:27:28] i'm not saying you're wrong... just trying to reconcile that with the status quo [16:27:42] marktraceur: does it exist already? [16:28:01] jeremyb_: We can probably link to browsers' own documentation for at least part of it [16:28:06] btw jeremyb_ this may be interesting to you or to people you know https://blog.mozilla.org/labs/2013/04/announcing-mozilla-hatchery/ [16:28:26] *click* [16:28:32] sumanah: btw, coming to SFC this weekend? [16:28:57] I am pretty worn out, jeremyb_, so I may cut my attendance to half a day or something like that, but I plan to at least show up for a little while [16:29:28] sumanah: k [16:31:15] anyway, i can't work on such a page today. maybe this weekend. was kinda hoping i just didn't know it already existed [16:31:26] I hear you [17:32:27] I just got a "[42bedf5c] 2013-04-19 17:29:41: Fatal exception of type MWException" when opening https://fr.wikipedia.org/wiki/MariaDB . The error didn't show up upon reload [17:32:44] page source didn't see more detailled information [17:36:56] DarkoNeko: still reproducible? [17:38:24] it's not, when I reloaded the pag ethe error was gone [17:38:26] alas [17:39:34] the full HTML code was http://pastebin.com/9u5Y67PZ ; not much to go with [17:44:04] DarkoNeko: no, you need to get a shell user to look up 42bedf5c in the log [17:44:12] oh, ok [18:11:06] * Moe_Epsilon waves and disappears [18:14:53] anyone familiar with the mediawiki api depoyed at en.wikiepdia.org? [18:15:03] en.wikipedia.org i mean [18:15:54] Yes edsu [18:17:22] i'm querying for images in pages [18:18:13] let me paste my example [18:19:19] OMG the Abuse Filter. It's... [18:19:25] loading really fast now. [18:19:35] :):):):):):) [18:22:34] so, i'm querying for images for a single page [18:22:54] curl "http://en.wikipedia.org/w/api.php?action=query&prop=images&format=json&titles=National%20Christmas%20Tree%20(United%20States)" [18:23:04] and i get some results: https://gist.github.com/edsu/5422178 [18:23:07] which is good [18:23:28] but when i try to query for two pages [18:23:53] curl --silent "http://en.wikipedia.org/w/api.php?action=query&prop=images&format=json&titles=Washington%2C%20D.C.|National%20Christmas%20Tree%20(United%20States)" [18:24:20] i get images for the first article [18:24:31] but not the second one, which i just saw i could get [18:24:32] https://gist.github.com/edsu/5422163 [18:24:36] edsu: use single quotes not double [18:24:50] *click* [18:25:43] jeremyb_: single quotes don't make the christas tree images show up like they do when i just query for that [18:25:58] jeremyb_: try it :) [18:26:05] i am trying... [18:26:27] single/double shouldn't make a big difference. but in this situation single are appropriate and double are not [18:26:36] it does make a difference sometimes [18:26:45] can you paste what you did? [18:27:11] i don't follow. /me has to finish reading API output... [18:27:31] jeremyb_: when i do this [18:27:42] curl 'http://en.wikipedia.org/w/api.php?action=query&prop=images&format=json&titles=Washington%2C%20D.C.|National%20Christmas%20Tree%20(United%20States)' | python -mjson.tool [18:27:50] i don't see any images for the christmas tree [18:27:59] just for Washington D.C. [18:28:09] * YuviPanda suggests Special:ApiSandbox [18:30:33] edsu, looks like a bug to me [18:30:46] yeah, i think so [18:31:57] looks similar in apisandbox: http://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&prop=images&format=json&imlimit=10&titles=Washington%2C%20D.C.%7CNational%20Christmas%20Tree%20(United%20States) [18:32:10] yeah, that's where I tested it :) [18:33:14] seems to be similar with simpler titles [18:33:55] huh, I somehow didn't have this on my auto-join list.... [18:35:46] thanks all for making me not go crazy :) [18:35:58] is the mediawiki-api the best place to email about this? [18:36:23] about the bug? no, should put it in bugzilla [18:36:37] edsu: https://en.wikipedia.org/w/api.php?action=query&prop=images&format=jsonfm&imlimit=100&pageids=8579601|108956 [18:37:09] also works with titles= [18:37:16] your limit= was too low [18:37:22] jeremyb_: oh! [18:37:50] * edsu tries [18:39:02] * greg-g waves to sumanah [18:39:09] wait, bad irc client [18:39:20] hehe, she's not here! [18:40:14] jeremyb_: I have this weird bug with irssi in wheezy/qauntal's gnome-terminal where long URLs cause text to be not cleared when I switch between channels sometimes. So... [18:40:36] greg-g: errrr, that happens in squeeze... [18:40:53] oh, you know what I'm talking about? [18:40:58] i does [18:41:08] unless it's 2 different but similar things [18:41:11] is it filed? [18:41:15] I was about to explain it more clearly, but it's kind of tough, so I'm glad you do ;) [18:41:16] i never bothered [18:41:22] jeremyb_: I've been bad about it, too [18:41:26] rock paper scissors? [18:41:30] hah [18:41:33] :) [18:43:41] Hashbreaking competition [18:43:58] zactly [18:48:46] jeremyb_: thanks much ; i didn't notice imlimit, and didn't understand it first even when you pointed me at it ; now i do :) [18:49:11] edsu: i'm not sure i pointed you at it at all? [18:49:19] but sure :) [18:49:22] jeremyb_: oh [18:49:46] jeremyb_: well you gave me a url where imlimit was used ... [18:49:54] jeremyb_: which was enough pointing for me [18:50:05] * edsu shrugs [18:50:36] heh [21:41:51] If you're constructing a special page that includes a lot of page links, but you know by the page's definition that all of the pages exist, is it still useful to put them all in a LinkBatch? I imagine so, but just want to check. [21:44:41] AaronSchulz: ^ [21:46:38] or is there some shortcut to create a LinkCache saying they all exist, without having to make LinkBatch check them all? [21:53:26] jdlrobson: I'm all finished with the Disambiguator updates. I added documentation for the API usage to the MediaWiki page and also added some LinkBatching to the special pages for good measure. [21:56:47] kaldari: there are knownLink function for this kind of thing. Would those not work? [21:57:20] the point of those functions is to always make blue links and avoid a page row query [21:59:40] That might be what I want. I wish there was some documentation on link batching/caching on mediawiki.org :P I'll look at knownLink though. [22:01:25] AaronSchulz: I can't find any function called knownLink. Am I looking for the wrong thing? [22:01:59] Linker::linkKnown() must be it [22:03:04] that looks like what I want :) [22:03:12] thanks Aaron! [22:03:51] kaldari: sweet [22:04:18] ah, right [22:41:24] AaronSchulz: created some documentation: https://www.mediawiki.org/wiki/Manual:LinkBatch.php [22:41:31] Would love a proofread if you have the time [22:55:31] So I hear we made SVG render more strict, should I start purging SVG and checking which are broken? Tim-away? [22:55:55] uhhh, no [22:56:29] you should either rsync the SVG or fetch by HTTP (maybe to labs) and then test it locally against your locally installed mediawiki [22:56:50] also, hi! [22:56:57] But...b... I love to purge [22:59:21] I guess I _could_ simply request at some un-cached size and build the list that way without purging [23:01:31] DarTar: I still want all yer filez [23:08:25] Dispenser: how would you know a size is uncached? [23:08:38] Dispenser: in any case my way is better :-) [23:26:45] jeremyb_: because 1317px or whatever is very unlikely cached. Even non-default standard sizes are not used, which lead me to write the script in the first place. [23:28:27] kaldari: seems fine [23:28:46] Dispenser: i prefer my way... [23:28:52] AaronSchulz: Thanks! [23:29:00] But mine's already running [23:42:30] Dispenser: so stop and do my way? [23:42:32] :-) [23:52:37] jdlrobson: had 1 comment about https://gerrit.wikimedia.org/r/#/c/59986/ [23:52:47] otherwise it seems fine [23:53:08] * jdlrobson looks [23:53:22] kaldari: haha [23:53:24] fix that now [23:54:07] kaldari: done! :) [23:55:40] +2