[02:39:35] Reedy: travis change ok to land? [02:39:50] Krinkle: Maybe not [02:39:56] Or not yet tested on gh? [02:40:04] ack [02:40:13] I think https://gerrit.wikimedia.org/r/c/mediawiki/core/+/670629 (or rather, the issue it's trying to fix), needs to land first [02:40:28] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/670629 [02:40:29] ffs [02:40:32] due to https://phabricator.wikimedia.org/T266419#6903125 [02:41:04] Aye, ok. I saw it come in just as I finished the end of today's queue [02:42:04] * Reedy rebases the travis patch ontop of it [08:22:55] Is there any way to split up the running of the database upgrader when upgrading your release version? I'm working with an almost 50GB database here and it tends to lock up the server if I leave the updater running. If I could split it into chunks and run them one by one, it would make this easier. [08:34:37] jfolv: the schema changes are .sql files you can run manually or with something like percona's online schema changes tool [08:34:46] the updater just has the list of them for each version [08:35:05] Oh wow, I didn't know that [08:35:12] That's definitely good to know, thanks! [10:06:39] How to set a license footer? [10:07:31] and also that it appears when editing [18:37:42] Can someone explain how AuthManger would get to https://github.com/wikimedia/mediawiki/blob/600f75010c27a53c967539c2622ce2e497360ed4/includes/auth/AuthManager.php#L535 [18:38:19] all primary providers return a PASS response [18:38:50] Our setup is CentralAuth SUL2 tgr_ [18:39:02] I can login fine but at least one user can't to that wiki [18:39:10] What's the cause in basic terms [18:39:43] typically you'd avoid by setting the authoritative flag on the provider, so it returns a FAIL instead of a PASS [18:39:55] (when the password does not match) [18:40:28] Yeah I'd normally see a username/password wrong message [18:41:41] If I got password wrong [18:44:12] since you can have a chain of providers trying to do something with that password, you have to tell one of them that it's the final one and it should consider failure the end of the road [18:44:28] There should only be CentralAuth [18:45:04] It's https://shekh.miraheze.org/w/index.php?title=%E0%A6%AC%E0%A6%BF%E0%A6%B6%E0%A7%87%E0%A6%B7:%E0%A6%AC%E0%A7%8D%E0%A6%AF%E0%A6%AC%E0%A6%B9%E0%A6%BE%E0%A6%B0%E0%A6%95%E0%A6%BE%E0%A6%B0%E0%A7%80_%E0%A6%AA%E0%A7%8D%E0%A6%B0%E0%A6%AC%E0%A7%87%E0%A6%B6&returnto=%E0%A6%AA%E0%A7%8D%E0%A6%B0%E0%A6%A7%E0%A6%BE%E0%A6%A8+%E0%A6%AA%E0%A6%BE%E0%A6%A4%E0%A6%BE&returntoquery=useformat%3Dmobile [18:45:17] Our ticket being https://phabricator.miraheze.org/T6946 [18:45:20] authentication providers are not aware of what other authentication providers are or are not installed [18:46:55] I doubt any others are installed though [18:47:02] Unless something is very wrong [18:47:16] Beyond CentralAuth + MediaWiki Core [18:54:17] that's rather beside the point [18:55:08] My point is I have a user that suddenly can't login and no understanding why [18:56:17] as I said, you have to set the authoritative flag for the login provider [18:56:44] They'll be set for every wiki [18:56:56] All wikis use the exact same CentralAuth configuration [18:57:13] well I guess it's broken for every wiki then [18:57:19] And no other wiki to my knowledge has reported the issue [18:57:32] Nor can anyone but that one user reproduce the issue on that wiki [18:58:07] it only happens when the credentials are incorrect [18:58:19] As far as I can tell it's 1 user on 1 wiki [18:58:30] or the login is blocked for some other complicated CentralAuth reason [18:58:33] Entering my wrong password gives me incorrect password on that wiki [18:58:45] tgr_: I think it's the complicated one [18:58:47] rename in progress or no account on the central wiki or whatever [18:58:53] Right [18:59:53] check the CentralAuth logic for when it returns a FAIL and when a PASS. This error is shown when the last provider in the chain returns a PASS. [19:00:44] They were renamed recently [19:00:51] So I guess that went bad [19:01:27] Even though they've logged in since rename [19:01:33] So something very weird [19:11:08] on the same wiki? [19:11:14] rename locks are per wiki [19:11:47] anyway check out https://wikitech.wikimedia.org/wiki/Stuck_global_renames [19:14:13] Rename shows as worked [19:14:22] So I'm betting on corrupt data somewhere [19:14:37] Will probably have to go diving into the database tonight [19:15:12] set log levels to debug and have them login, it should provide some details [19:15:29] That's a possibility [23:00:43] tgr_: CentralAuthSessionProvider::provideSessionInfo: username SHEIKH is not usable on this wiki [23:11:23] so that's User::isUsableName failing [23:11:36] probably rejected by some UserGetReservedNames hook handler [23:11:50] could be CentralAuth itself, could be something else [23:16:22] tgr_: that's most likely [23:36:56] tgr|away: https://github.com/wikimedia/mediawiki-extensions-HAWelcome/blob/master/HAWelcome.hooks.php#L122 [23:37:01] we fixed it [23:41:01] tgr, thanks for the help :)