[10:28:54] If I set $wgMainCacheType to CACHE_MEMCACHED and leave the other $wgXyzCacheType variables unset, they use the main one, right? [10:29:31] I just noticed the docs for $wgParserCacheType saying that if you set the main one the memcached, it's recommended to set the parser one to CACHE_DB explicitly. Why is that? [15:52:22] anyone aware of any alternatives for https://skins.wmcloud.org/#/explore ? [15:52:37] I'm really trying to not have to deal with installing a ton of skins [15:52:58] what do you mean by alternative? [16:07:35] Reedy: something that does the same but is not broken [16:14:09] I believe Jdlrobson maintains that [16:14:14] Have you asked him to fix it [16:22:18] I have [16:22:24] here, via email and via Twitter [16:22:33] I'm guessing he is unavailable temporarily [16:22:38] he's not responded anywhere [16:22:43] perhaps he has a cold or something [16:22:58] wat [16:29:43] Vulpix: why wat? I'm confused [16:32:13] What about a phab task [16:37:14] Bert: making up random diseases for people is out of line [16:38:37] Vulpix: I didn't mean it like that, it's just cold season here, lots of people are unavailable because they have a cold, so it's perhaps a reason why he might not be available [16:39:23] RhinosF1: I'm not sure how official or unofficial the skins lab is, so no idea if that's the right way forward or not [16:42:01] It's hosted on cloud services [16:42:16] afaik it's a project done in volunteer time, the repo is https://github.com/jdlrobson/skins.wmflabs.org [16:42:20] Unless there's another known bug tracker then use phab [16:42:39] I see it has issues on github though [16:42:43] oh, I could file a github bug in that case, good catch AntiComposite! [16:43:09] seems this has happened before https://github.com/jdlrobson/skins.wmflabs.org/issues/20 [16:43:12] how weird [18:07:56] I'm upgrading to 1.41.0 from 1.40.0 and there is an error in the database pertaining to OAuth, "oathauth_users table does not contain secret field" and then ending with the error "No such service: OATHAuthDatabase" [18:09:01] Is this a known issue when upgrading from an install that used the OAuth extension? [18:12:32] Did you run update.php? [18:12:45] Did you ensure all extensions were up to date? [18:12:55] Also OAuth and OATHAuth are different extensions [18:17:06] I'm using OATHAuth, according to the name in the extensions directory. [18:18:01] They do completely different things, you probably have both. [18:18:13] But that's mostly pointless [18:18:31] UFFR: have you ran update.php? [18:18:44] And did it complete successfully? [18:19:06] I ran it but it gives an error. [18:19:10] Let me copy it. [18:19:35] Wikimedia\Rdbms\DBConnectionError from line 1149 of /var/www/html/ntmwiki/w/includes/libs/rdbms/loadbalancer/LoadBalancer.php: Cannot access the database: No database connection (localhost) [18:20:01] I also only have OATHAuth, if the extension list is accurate. [18:21:29] Okay [18:21:37] Erm [18:21:51] No database connection means it won't have ran the migrations [18:22:08] And they are a lot for OATHAuth between 1.40 & 1.41 [18:22:56] It should run them again though if you run update.php and it succeeds [18:23:01] UFFR: ^ [18:23:56] Command [php run.php update.php] in the maintenance directory just keeps throwing the same error. [18:24:16] Unless it's supposed to be ran from the root directory? [18:24:46] UFFR: is your database definitely up and able to accept connections on localhost? [18:26:49] I can't imagine it not being up, the wiki was running normally before I started the upgrade, I'll try to check with the shell. [18:29:10] My other thought is a query is causing it the database crash / become unresponsive so I'd wonder if it always fails at the same point. An immediate fail would make that unlikely though. [18:31:09] I set the wiki to be read only before upgrading, so it'd have to be a read query. [18:31:24] Then again, I restricted access to the site entirely after a point. [18:33:00] I'm also completely inept at SQL, so there's not a lot I can help you with there. [18:33:47] If you followed the upgrading guide, I believe it sets read only for web users only [18:33:49] Not CLI [18:33:55] So that's not true [18:34:09] And a migration crashing the database isn't an impossible theory [18:34:23] UFFR: basically, paste the full output of update.php [18:34:27] .schema in SQLite shell isn't showing anything. [18:34:34] Give me a second to put it in a paste. [18:34:38] Does it say it's done anything before it fails [18:35:14] Although I am a bit confused because I wouldn't expect SQLite to give that error [18:35:37] https://dpaste.org/pp59n [18:35:39] It's effectively a flat file database, it doesn't need a running service that can fail to my knowledge [18:35:56] So I have a new theory [18:36:07] Did anything change about config for connecting to the db? [18:36:45] Shouldn't be, I just ran the script in the web interface. [18:37:26] Is your LocalSettings.php file still there? It's not been reset for any reason? Can you paste the bit about database config without any password? [18:39:42] https://dpaste.org/wSLPs [18:39:53] RhinosF1: As far as I'm aware, it has not changed. [18:40:09] Unless that's what the problem is. [18:44:16] UFFR: try removing $wgDBServer/user/password [18:44:22] And then run update.php again [18:50:15] RhinosF1: Same error again. [18:50:52] Okay, I'm lost then [18:56:38] Yesterday in #atheme I was troubleshooting another weird issue and it turned out to be the stupidest thing ever with the simplest solution, maybe (hopefully) it's the same thing here. [18:56:52] But probably not. [18:57:30] Maybe I can downgrade to a backup and see if it works then? [19:00:32] https://dpaste.org/93q9a#L [19:00:41] Added some blocks also referencing SQLite. [19:27:10] Listing the databases in the SQLite shell only shows "main", maybe the issue is that? [19:32:28] Chances are you'll want \\ not \ in those FQN [19:33:14] Ok, it seems the issue was that the database files were restricted to the www-data user and group, running under that loaded the database. I guess it really was a stupid issue. [19:33:30] Though it also seems that the read-only setting affects the CLI as well. [19:36:18] If you follow the guides, it should show you how to make read only apply to only the web and not CLI [19:36:39] And yes, always run maintenance scripts under the web user [19:39:05] $wgReadOnly = ( PHP_SAPI === 'cli' ) ? false : 'This wiki is currently being upgraded to a newer software version. Please check back in a couple of hours.'; [19:39:09] UFFR: ^ [19:40:25] I see.