[00:13:19] Seahorse: I did a similar thing here for WMF replag [00:13:21] @replag [00:13:23] Krinkle: No replag currently. See also "replag all". [00:13:27] @info commonswiki [00:13:27] Krinkle: [commonswiki: s4] db31: 10.0.6.41, db22: 10.0.6.32, db33: 10.0.6.43 [00:13:36] @replag db24 [00:13:36] Krinkle: [db24] db24: 0s [00:13:43] @replag s7 [00:13:43] Krinkle: [s7] db37: 0s, db18: 0s, db16: 0s [00:13:44] etc. [00:13:49] @info db18 [00:13:49] Krinkle: [db18: s7] 10.0.6.28 [00:13:51] interesting [00:33:40] anyone here in europe? [00:34:30] Yep [00:34:38] but only for about 20 more minutes [00:34:49] (Ill still be in Europe, but not in this channel) [00:35:32] is this link working for you? https://upload.wikimedia.org/wikipedia/commons/thumb/f/ff/Viaduc_Saillard.jpg/691px-Viaduc_Saillard.jpg [00:35:54] or are you getting a 400? [00:36:54] a 400 :( [00:42:17] Krinkle: ok. can you try again? [00:42:21] I think it should be working now [00:43:08] works ehre [00:43:14] \o/ [00:43:16] :) [00:43:31] Via:1.1 amssq50.esams.wikimedia.org:3128 (squid/2.7.STABLE9), 1.0 knsq10.knams.wikimedia.org:80 (squid/2.7.STABLE9) [00:43:31] X-Cache:HIT from amssq50.esams.wikimedia.org, MISS from knsq10.knams.wikimedia.org [00:43:32] X-Cache-Lookup:HIT from amssq50.esams.wikimedia.org:3128, MISS from knsq10.knams.wikimedia.org:80 [00:43:44] yep [00:43:49] transparent nginx proxy in front [00:44:02] Server:nginx/0.7.65 [00:44:02] yeah [00:44:19] did bits and upload today :) [00:44:27] nice [00:44:29] http://toolserver.org/~krinkle/testswarm/user/MediaWiki/ [00:44:37] We made it to all green [00:44:48] even IE6 [00:44:57] sweet [00:44:58] congrats [00:45:20] thx, IE6 was being a bitch but I think in the end it caused the code to be cleaner/stricter/more effecient [00:45:34] Modern browsers are fairly loose. [00:46:12] aight, byebye [00:46:17] see ya [03:15:03] does anyone know why hexmode tagged a whole lot of pre-1.18 revisions with a 1.18 backport tag? [03:15:30] r56578 etc. [03:44:56] not just hexmode [03:45:22] also reedy, robla and brion [03:45:30] I don't get it [03:45:51] I'll explain in a sec [03:49:25] TimStarling: so....I think those revisions were revisions that we pulled out of the 1.17 branch prior to release [03:50:12] if so, nothing would need to be done to get them into 1.18 [03:51:13] if they're still "fixme", it means they probably need to be reverted now. e.g. 56578 [03:51:36] (or fixed, or whatever) [03:51:43] right... [03:56:01] the script that I was running ignored anything marked "1.18" [04:05:11] here's the list of revisions that I untagged: r79034, r67094, r81448, r81445, r70270, r76252, r70520, r66200, r81414, r77468, r73198, r73875, r74208, r59048, r74159, r56578, r72707, r77555, r89839 [04:05:29] I can retag them with some other tag if you like, I'd just have to figure out what to call it [04:06:31] "post1.17"? [04:06:55] ok [04:08:08] tagging them "1.18" did kinda serve the intended purpose, which was to remind us to revisit these revs before making the faulty assumption that they were part of 1.17 therefore already in production [04:08:56] I think anything marked "ok" doesn't need to be retagged...it's only the "fixme" revs that need looking at [04:10:57] I have no idea why r79034 was tagged 1.18 [04:13:15] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/post1.17 [10:36:58] hello [11:57:29] Reedy: I've been looking at a possible temporary fix for the failfunction issue, for 1.17 at least [11:58:22] it's very very ugly, really it needs a different solution for trunk [11:58:32] Typical [11:58:45] I'm still somewhat confused how it's actually broken anything [11:59:47] well, the general idea is that setting failfunction to 1 will cause it to "ignore errors" [12:00:23] I'm looking at the 1.16 source to make sure I'm not missing anything [12:00:56] ignoring errors means Database::reportConnectionError() doesn't throw, it just returns control back to open() [12:01:24] that means there's no exception and the construction of the object succeeds [12:01:53] then LoadBalancer does various things with the Database object which wraps the failed connection [12:02:25] it's not easy to do that if you throw an exception from the constructor, because then you don't have the Database object anymore [12:02:50] Sure [12:02:55] anyway, LoadBalancer::openConnection() returns a failed Database object to getReaderIndex() [12:03:10] then getReaderIndex() will mark it down and move on to the next possible slave [12:03:46] because your change causes it to throw instead, and there's no try/catch, it misses that logic in getReaderIndex() [12:04:14] so if you have a slave with a 30% load and it goes down, 30% of users will see a DB connection error message [12:04:23] instead of a silent failover to a working slave [12:06:10] hi [12:06:18] hi hashar [12:07:03] Right, so it was doing more than it obviously showed, with "fail function" being more like a specific error handler [12:07:55] yeah, I'm not saying it's pretty [12:09:00] I'll commit this temporary 1.17 solution if it decides to start working properly... [12:10:15] what I want in trunk is for database classes to take an associative array as the single constructor parameter [12:10:20] it makes so many things easier [12:10:34] Yeah [12:10:38] and very few extensions will be broken [12:10:55] and those that are will thank us for it anyway because the current system sucks so much [12:11:17] I was going to say, hasn't somoene started that, but it's another class family where they have... [12:11:40] Chad added a factory function [12:11:55] it doesn't go nearly far enough though [12:12:01] Ah, that's it [12:31:39] # All slaves lagged. Switch to read-only mode [12:31:39] $wgReadOnly = wfMsgNoDBForContent( 'readonly_lag' ); [12:32:08] doesn't really work if you have LocalisationCache in the DB, it just goes into infinite recursion [12:50:39] it worked, see r90266 [12:51:17] anyway I think the long-term solution is to have DBError objects not take Database objects as constructor parameters [12:51:41] then LoadBalancer will be able to construct a DBConnectionError without having to do this: [12:51:53] $conn = new Database; [12:51:53] // If all servers were busy, mLastError will contain something sensible [12:51:53] throw new DBConnectionError( $conn, $this->mLastError ); [12:53:18] also I'd like to have LoadBalancer::openConnection() return a better error status indication, like maybe the DBConnectionError object itself [12:53:44] there's a bit too much reliance on "last error" member variables, sometimes they get overwritten at inconvenient times and you end up with no error or the wrong error [12:54:03] so it's better to use return values [12:54:47] everything in LoadBalancer that refers to mLastError or mErrorConnection would need to be fixed [12:55:01] then we can have a relatively normal-looking try/catch block in reallyOpenConnection() [12:56:38] it's late [17:40:44] hello [17:40:46] who do i have to talk with? i'd like to find out whether and how it is possible to interact or import the wikimedia database for metadata about works [17:41:38] hi ya [17:41:45] I can help you [17:41:57] have you looked at the monthly data dumps, ya ? [17:41:59] there isn't actually a "wikimedia" database ;) [17:48:57] hello :) [18:02:00] sumanah: no? [18:02:06] sumanah: what is it [18:03:03] http://dumps.wikimedia.org/ [18:03:06] We do database dumps [18:53:05] kaldari: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=mediawiki!legacy!commonPrint|mediawiki!legacy!shared|skins!vector&only=styles&skin=vector [18:53:24] kaldari: https://upload.wikimedia.org/wikipedia/commons/thumb/f/ff/Viaduc_Saillard.jpg/691px-Viaduc_Saillard.jpg [18:53:26] oh, nice :) [18:53:34] just so you know, I'm actively working on it :) [18:53:40] swweeet! [18:53:46] geolookup won't currently workj [18:53:58] as bits will see the IP of the nginx server, and not the client IP [18:54:10] also, it will still deliver mixed content [18:54:22] need to push for protocol relative urls..... [18:54:28] understood. Looks like good progress though [18:54:40] we also need another node in esams [18:54:51] otherwise I wouldn't feel ok using it for fundraising [18:55:19] btw, have you met the fundraising ops person from craigslist? [18:55:31] I don't feel comfortable at all using secure for fundraising [18:55:41] I talked with him for quite a while, yes [18:55:45] cool [19:02:50] Ryan_Lane: I've written up some docs on protocol-relative URLs but I'm not gonna have time to do it. It's mostly just editing configs with caution though, so any ops person could do ti [19:03:06] RoanKattouw: I'm not comfortable doing it [19:03:40] kaldari: if you guys have this as a priority, you need to get a dev that's comfortable doing this assigned to do it [19:04:27] Ryan_Lane: I can do it, but not before July 1st or so. Probably best to defer until I'm in the office (July 6th or 7th) [19:04:46] that works for me, if it works for fundraising [19:05:10] The most laborious part is probably the logo URLs [19:05:17] Those can be done beforehand by someone else [19:05:17] *Ryan_Lane nods [19:05:39] You know, cause there's hundreds of custom ones and you have to check each one to see if it broke [19:05:44] yep [19:05:59] I don't really have time for that [19:05:59] (Should use that opportunity to do a tad of cleanup and maybe normalize some back to $stdlogo, maybe) [19:06:11] Don't you have minions now? ;) [19:06:20] *I* don't :) [19:06:38] also, I've been told https is now a high priority [19:06:44] so.... [19:07:03] if it's a high priority. a dev with some extra time that is familiar with this stuff should likely do it [19:07:16] It's *way* more likely I'll break mediawiki config than a dev [19:07:46] there's a ton of things I need to take care of infrastructure wise to meet the deadline they want [19:07:51] which apparently is right now [19:09:09] Yeah [19:09:22] Well, most of it is sensitive and definitely needs an experienced dev [19:09:35] URLs for the Commons config for instance [19:10:03] But the logo things are kind of brainless and mind-numbing, TBH [19:10:20] yeah [19:10:41] And way low on the sensitivity scale [19:10:52] *Ryan_Lane nods [19:16:21] kaldari: we'll be doing protocol relative urls around July 8th. I'll try to have the geolookup stuff in varnish done by then too [19:16:28] kaldari: this ok timeframe wise? [19:43:57] Ryan_Lane: that works [20:02:52] NERDS. http://dis.4chan.org/read/prog/1295544154 [20:03:19] *click* [20:05:24] oh come ON [20:05:29] I am not going to read this whole thread [20:05:31] or am I? [20:15:26] i think that thread was MADE for you, apergos. [20:15:47] :-D [21:24:48] kaldari: So about the jQuery-in-hthe-head stuff, when would you want that done by? [21:24:55] It's gonna be some time in July [21:25:19] Hmm, let me confer with jalexander on it.... [21:25:48] Your choices are the week of Jul 4 or the week of Jul 18, basically. I prefer the latter [21:25:56] 18 can become 11 if Ryan wants to trade with you [21:26:07] depends on which one he wants [21:26:15] I'm doing the https stuff for him :) [21:26:39] Oh, haha [21:26:53] Well then it's a question of what kaldari wants to happen first [21:27:01] well, that's the push for it happening quickly, anyway [21:27:46] The jquery in the head is more time sensitive than the https stuff [21:28:07] OK [21:28:11] Then we do that first [21:28:17] ok, so email from me should say week of July 18th? [21:28:23] Yes [21:28:28] It may or may not be earlier [21:28:32] Best say 11th or 18th [21:28:51] so 11th is the plan for deploying jquery in the head? [21:29:10] gah. my subject said protocol urls instead of protocol relative urls :) [21:29:16] glad I caught that before hitting send [21:29:27] is that just going to be deployed to wikimediafoundation.org or all the wikis? [21:29:38] protocol relative urls? [21:29:44] no, sorry, jquery [21:29:47] ah ok [21:29:49] Both will be deployed everywhere [21:29:53] ok [21:29:56] did you need https on wikimediafoundation.org too? [21:30:03] nah :) [21:30:06] ok. good [21:30:12] that would require money too ;) [21:30:24] Wait, why would we not have HTTPS there? [21:30:34] It's a wiki like all others [21:30:36] I told you I'm not giving you any more money :P [21:30:39] A private wiki, too [21:31:21] well it would be nice, but it isn't needed for the fundraiser [21:31:24] :D [21:31:38] RoanKattouw: we'd need to buy a star cert for it [21:32:01] Right [21:32:07] it's in the plan, but we haven't purchased any yet [21:38:36] Alright so [21:38:41] I'm shuffling my schedule a bit [21:38:47] jQuery in the head will now happen on July 7th