[13:31:46] for some reason hexchat fails to auto-join this cahnnel. and i get kicked out every now and then. why is that? do I need a different cloak? [13:31:58] KateChapman: hey, I'm on now. [14:05:49] duesen I'm not sure. I know Evan was having some weird issue where he was specifically getting kicked from this channel as well [14:19:59] duesen: I see this channel has mode +r, meaning only users who're identified to services can join. Is it possible you have a race condition between identification and the auto-joining? [15:02:12] anomie: that would explain the issue with auto.joining, but not the one with being kicked out. except perhaps if that happens on re-connect. [15:03:21] i'll try /set irc_join_delay 15 [15:07:39] <_joe_> duesen: or configure SASL auth, which is more secure and also happnes at connect time [15:07:51] <_joe_> avoiding such race conditions if your client is not smart enough [15:08:16] <_joe_> https://freenode.net/kb/answer/hexchat [15:12:58] +1 for SASL, I set that up a long time ago (before I started using a bouncer) and it works well. [15:41:06] SMalyshev: did my changes to https://gerrit.wikimedia.org/r/c/mediawiki/core/+/454346 address your concerns (thank you for that review, BTW!). If so, can you indicate that on the change? [15:45:35] _joe_: seems to work, thanks :) [15:45:51] <_joe_> wy [15:45:53] <_joe_> *yw [15:47:54] bpirkle: I'm around, let me know if you have any questions re getKnownCurrentRevision [15:49:05] anomie: do you have time to help me out with an issue related to postgres and sqlite? [15:49:07] see https://gerrit.wikimedia.org/r/c/mediawiki/core/+/443608/#message-dc61ffbc0551b071e915cf05a6fc6edc55368856 [15:50:09] basically, I introduced code into MediaWIkiTestCase that allows a second connection to be set up with the unittest_ prefixed fake tables, but it's broken in postgres and sqlite. [15:50:56] ...and I don't have them set up to test. I seem to recall that you do, so if you have time to have a brief look, that would help me a lot! [15:52:47] * anomie looks [16:17:18] duesen_: Two different causes here. For postgres, MediaWikiTestCase::listOriginalTables() is broken and only happens to work on MySQL because the undocumented listTables() method doesn't return temporary tables on that DB (while it does on postgres). For sqlite, you're running into the same problem described at https://phabricator.wikimedia.org/T191863#4130112. [16:18:35] duesen_: TL;DR for sqlite: if you do open the same database twice and do schema changes on one connection, the other will notice that and reset itself, losing the temporary tables. [16:21:58] Probably all the creations of temporary tables for sqlite are ok, but unittest_searchindex can't be temporary so that's probably the one screwing it up. [16:24:34] * anomie copied that to the gerrt change too. [16:26:53] anomie: so how is unittest_searchindex handled for other unit tests? [16:27:13] thank you for investigating, by the way! [16:27:38] duesen_: Most unit tests don't open a second connection to the DB. [16:28:17] anomie: no, but they all create a temp clone for all tables [16:28:36] so, they#d have to somehow create a temp version of searchindex [16:29:29] duesen_: They create a non-temporary unittest_searchindex table. If there's an old one, they drop it first. [16:29:48] anomie: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/491686#message-3ccd30cb957ff4cca8af1ec769edb7a591e9d333 [16:29:48] that would do it. Thanks. Not sure if allowLogin is descriptive enough. What about checkOnLogin or runOnLogin? [16:30:15] anomie: huh, ok. if it's non-temp, then there is no need to copy. I'll try to make a patch. but i'm not sure how to teste it... [16:30:25] dmaza: Sure, I'm not picky about the name, or particularly good at naming. [16:30:30] what'S the magic incantation for testing other databases in CI? [16:30:38] check postgresql? [16:31:28] anomie: cool.. I'm terrible at naming, taht's why I asked. I'll go with checkOnLogin [16:31:30] thanks [16:37:03] duesen_: Looks like "check php", "check php5", "check zend", "check sqlite", and "check postgres" all do the same thing. But not "check postgresql". https://gerrit.wikimedia.org/r/plugins/gitiles/integration/config/+/master/zuul/layout.yaml#762 [16:49:12] bpirkle: will review [20:26:36] legoktm: Are you still wanting to backport T183211, or should we close it? [20:29:49] Hmm, stashbot didn't post a link to the task. [20:41:40] anomie: stashbot thinks that is a security bug... which is probably a bug in stashbot [20:42:22] bd808: It was at one point, but it was reset to public in December 2017. [20:44:45] the conduit api response still has std:maniphest:security_topic:security-bug set. That keeps stashbot from talking about the bug even if it can read it. [20:46:40] "normal" tasks report std:maniphest:security_topic:default -- I have no idea what if anything can be dome from the phab UI to clear that security-bug topic [20:46:45] *done [20:47:59] this protection was added to stashbot because of T180081 (also security bug) [22:15:11] Any comments on https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/486206/ ? [22:36:18] oops, I was planning to merge that after a week and forgot [22:36:22] will do that today