[00:21:42] tgr: Did something change in centralauth so that we don't autologin users to domains where they aren't attached? [00:22:22] Think that's just broken [00:22:38] but that's known, isn't it? Stewards are complaining for quite some time now [00:23:23] Hmm, I missed that. Just trying to work on master, and can't tell if centralauth is borked or sessionmanager is messing things up... [00:23:42] csteipp: pre-SessionManager, or on master? [00:23:56] Latest CA doesn't even work for me… I had to downgrade it, need to look into that once I have some time [00:24:02] tgr: master of both (master last Friday to be exact..) [00:24:42] it should work [00:24:59] but if you register a new user, it does not work immediately [00:25:30] that's an old bug that has been promoted to a feature by people who don't want user creation logs flooded [00:25:47] I'm registering lots of accounts, so that might be problem.. I'll see if I can get some basic cases up. If I open duplicate bugs, apologies in advance :) [00:26:17] tgr: Correct, we shouldn't autocreate-- but right now it's not setting a top-level cookie for the domain. [00:26:19] specifically, you need to be logged in on two different domains before it starts working, IIRC [00:26:50] registration does not set the cookies, the next login on a different domain should [00:27:02] or something like that, I might misremember the details [00:27:06] yeah... I'll try to work it out. [00:27:10] * csteipp runs to train. [20:02:25] Hm.. where in MediaWiki core does it handle redirect resolution for displaying content (e.g. at some point I expect Article or WikiPage or something to call Content::getRedirectTarget or a related method and decide to render a different revision instead. [20:04:01] Krinkle: apparently in MediaWiki::initializeArticle. (i grepped for 'redirectedfrom') [20:04:58] It calls Wikipage::followRedirect -> WikiPage::getRedirectTarget() [20:05:03] but that doesn't look at Content [20:05:07] and it only fetches 1 level deep [20:05:50] Or does the db table store the ultimate destination [20:05:55] why would it look at content? we record redirect status in the databases somewhere [20:06:26] Krinkle: The DB table stores the destination. Title::insertRedirect() is one place that populates it. [20:06:33] huh, there's even a 'redirect' table. [20:06:48] Of course [20:06:51] (i thought it's on the 'page' table, but that only has boolean 'page_is_redirect') [20:06:58] Yeah [20:07:02] it's a link table [20:07:16] Anyway, I mistakenly thought the sql table only stores the immediate destination [20:07:40] err, WikiPage::insertRedirect() I mean. [20:08:12] Ah, that one calls Content::getUltimateRedirectTarget [20:08:13] nice [20:10:16] hmm, by the way, did we drop php 5.3 yet? [20:10:26] because i again wanted to write fun()] [20:10:39] because i again wanted to write fun()[] and recalled that's a parse error on 5.3 [20:12:39] MatmaRex: not yet. still working on the CI changes that are needed [20:13:41] MatmaRex: watch this patch for the switch -- https://gerrit.wikimedia.org/r/#/c/266932/ [21:52:35] dapatrick: around? [21:53:06] Yep, what's up [21:53:28] dapatrick: hi! is there anything left to do with https://phabricator.wikimedia.org/T123558 ? [21:56:46] None with the code, per se. It looks fine. [21:57:43] The concern is more with the deployment process, and ensuring that the lm files have not been modified prior to inclusion. This is a concern for us if we deploy directly from Github. Less of a concern when deploying from WMF repos. [22:14:04] bd808: I don't get how would array_shift reverse the order of processors [22:14:25] but in any case, isn't that something that should be fixed in core? [22:16:12] tgr: array_unshift puts the new value at index 0. when you iterate the source array in order and then stick each value in a new list at [0] you end up with a reversed list. [22:16:54] Changing in core... maybe, but that would have been slower to roll out. [22:17:11] order sensitive Processors are not a common thing [22:17:55] for the general case it shouldn't matter. And the one we are caring about order for exists only in config where I have added a comment about the ordering need [22:22:52] ah, unshift, not shift [22:22:59] I always mix those two up [22:49:51] "fun" Huggle2 bug -- https://phabricator.wikimedia.org/T126357 [22:50:11] it pukes on the insecure-post warnings [22:52:04] bd808, we don't need no water... [22:52:24] ...let the mother fucker burn? [22:56:08] TimStarling: over at , paulbiss provided some additional information about the HHVM test that is failing with the output streaming patch: "we have a function for asyncronously dispatching an xbox server and awaiting the serialized return value. the test that's failing can't unserialize the return value because the response from the server contains a bunch of garbage". [22:56:14] paulbiss confirmed that fb_call_user_func_async() calls XboxServer::TaskStart() under the hood, so it looks like a matter of suppressing output in the right place in XboxRequestHandler or XboxTransport. Maybe XboxTransport::sendImpl() needs to have code similar to the one you added to ProxygenTransport::sendImpl() for suppressing body for HEAD requests. [22:57:33] the test failure looks a lot like [22:58:37] is that enough for you to go on? [23:09:23] yeah, it's something [23:10:05] at least I can test xbox return values and output