[11:21:21] Vector 2022 seems to disable ClearType™ making reading much displeasing on lower DPI displays than on the older Vector. Something like Minerva Neue should be the default, since it does keep ClearType enabled, and limits the page width to readable length. [11:26:31] Hmm, scratch that. Seems to only happen on SeaMonkey, and is “fixed” by removing position: relative on .vector-feature-zebra-design-disabled .vector-body [11:28:12] I incorrectly thought there would be transform: translate() somewhere [15:17:12] Could someone with appropriate rights merge/review https://github.com/wikimedia/mediawiki-docker/pull/132? [15:32:17] Reedy: thanks! ^_^ [16:28:41] I have attempted to install the mediawiki Debian package (version 1:1.35.6-1). When I run the web based installer I see the following error message when I get to the "Welcome to MediaWiki!" page. I cannot find any information anywhere on this error: [79343226836f31473ac535f7] /mediawiki/mw-config/index.php?page=Welcome Error from line 151 of /usr/share/mediawiki/includes/shell/FirejailCommand.php: Undefined constant "MediaWiki\Shell\M [16:28:41] W_CONFIG_FILE" [16:33:23] I would not install a broken Debian package but follow instructions on mediawiki.org [16:33:43] MW_CONFIG_FILE should imply the file LocalSettings.php [16:33:58] But why is it showing like it's looking for it namespaced? [16:34:17] * Reedy loads salsa [16:34:27] https://salsa.debian.org/mediawiki-team/mediawiki HTTP 500 [16:34:27] gj [16:34:39] https://github.com/wikimedia/mediawiki/blob/REL1_35/includes/shell/FirejailCommand.php#L150-L152 [16:38:22] Generally the debian package is decent these days, and not usually broken [16:38:44] andre: I prefer Debian packages because they are much safer than installing into /usr/local and not having it tracked by the system package manager. [16:39:14] I guess whatever MW_CONFIG_FILE is, it's not defined. So the question then is probably what defines MW_CONFIG_FILE? [16:39:43] probably Setup.php i would guess [16:39:56] The package does install a /usr/share/mediawiki/LocalSettings.php and /var/lib/mediawiki/LocalSettings.php [16:40:17] bawolff: There is also a /usr/share/mediawiki/includes/Setup.php [16:40:51] huh, is MW_CONFIG_FILE not a thing anymore? [16:41:56] * KombuchaKip shrugs [16:41:59] helps if i don't typo my grep command [16:42:46] Do I need to manually edit Setup.php? [16:43:13] KombuchaKip: is it not present in your setup.php, it is present in the official version of 1.35 [16:43:53] Line 141 [16:44:15] oh i see, if MW_CONFIG_CALLBACK is defined it might not be [16:44:20] bawolff: L141: define( 'MW_CONFIG_FILE', "$IP/LocalSettings.php" ); [16:45:55] And I'm going to guess debian uses MW_CONFIG_CALLBACK to customize setting loading (That's kind of what the point is), so they probably have a code path that isn't as tested as the normal one [16:46:08] So maybe this is FirejailCommand's fault after all [16:46:35] * KombuchaKip shrugs [16:47:21] bawolff: This is the full stacktrace: https://pastebin.com/uqrLZjT8 [16:47:29] All that's to say, this is probably a bug in mediawiki, for a codepath that would happen in the debian distribution but not vanilla mediawiki [16:48:25] bawolff: Is there a temporary workaround so that I can get it installed and start populating it? [16:49:10] oh, this is happening in the installer? [16:50:22] you could try adding define( "MW_CONFIG_FILE", "" ); to mw-config/index.php (second line after the I don't know for sure if that will work, but worth a shot if you just want to try and make it work [16:55:36] * bawolff trying to go through the debian package. I don't even see anything here that would trigger something like this [16:56:10] KombuchaKip: what OS are you running? jammy? [16:56:52] the Ubuntu packages are outdated and don't get security updates, use the Debian ones instead [16:57:59] legoktm: Yeah, jammy package. [16:58:17] bawolff: Yes, this is happening during the installer. Haven't done anything to it other than install the vanilla package on Jammy. [16:59:48] huh, jammy is on 1.35.6 (!). That seems silly, what even is the point of ubuntu packaging it if they don't backport security updates? [17:00:11] exactly ._. [17:00:33] basically, just use Debian [17:01:08] (installing the debs from Debian onto an Ubuntu system will mostly just work fwiw) [17:09:27] legoktm: I'm a little wary to do that unless I'm absolutely certain it's safe. [17:10:13] as the Debian package maintainer I think it's safe :p [17:10:26] I haven't tried it with jammy yet but another wiki I help run was doing that on focal [17:12:08] on the flip side, I'd say running the stock Ubuntu packages is definitely unsafe [17:48:24] * bvibber kicks the tires [17:48:34] ah, just like old times [17:48:48] somebody registered my nick though so i had to change ;_; [17:49:44] legoktm: For the Debian package, do you mean just the mediawiki package and no others that I should install? [17:50:16] you'll need "mediawiki" and "mediawiki-classes" [17:50:25] but yeah, source the other packages (PHP, etc.) from Ubuntu [17:50:29] o/ bvibber [17:50:41] \o [17:55:16] Wb bvibber [17:55:29] :) thx [17:57:42] legoktm: Ok it seems to work. I'm on the "Connect to database" page in the installer, but now seeing: Cannot access the database: :real_connect(): (HY000/1698): Access denied for user 'root'@'localhost'. [17:58:22] did you give it the right username/password? [17:58:29] also maybe try 127.0.0.1 instead of localhost [18:00:44] legoktm: I was wondering about that and wasn't sure if the installer was suppose to setup the DBMS backend already. [18:00:58] no, you need to do it manually [18:01:19] https://www.mediawiki.org/wiki/Manual:Installing_MediaWiki#Set_up_the_database [18:03:03] ugh, that sucks. Kind of defeats the whole purpose of having an installer. [18:14:02] You expect the mediawiki installer to install mysql for you? [18:15:55] I think most people would be very surprised if the mediawiki installer started doing things like `apt install mysql` [18:16:20] It should be an unnecessary step if it would default to using sqlite as the db engine for distro packages [18:17:01] I mean, probably a bad default. Our sqlite support isn't very well optimized [18:18:07] I doubt a default mysql install would be "optimized" either... [18:18:10] Last i checked, we weren't even using WAL mode for sqlite, which is almost like passing a "be extra slow" option [18:19:11] idk, i think most of the mysql defaults are pretty reasonable [18:20:10] so Debian has this system called "dbconfig", which is basically you configure DB stuff once, and then each application can use that config [18:20:20] we have an open request to consider supporting it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051382 [18:21:53] In sqlite, we do this thing where we begin a write transaction basically every transaction whether or not we need it, which probably increases the risk of contention a lot (although i think there is some code that changes this depending on if request was GET vs POST). I think it'd make a lot my sense if we had like replica vs master for if we pre-emptively start a write transaction [18:23:23] I mean, i've never really done performance testing of it, but sqlite locking is not fine grained but instead locks the entire DB, so i imagine that sort of thing would matter pretty quickly if your website is even moderately busy [18:29:41] I’m guessing some people have worked a bit on our sqlite performance with the goal of speeding up CI [18:29:47] but that’s optimizing for a different use case than a real wiki [18:30:30] * Lucas_WMDE waves at bvibber [18:33:55] bawolff: Yes, that's exactly what I expected it to do. It would simply list a DBMS in the Depends stanza in d/control, perhaps multiple with only one being necessary, and then perform setup and teardown in the maintainer scripts. Lots of packages do that. [18:34:14] legoktm: Yup. dbconfig is the way to go. [18:37:11] heyyyy [18:37:41] Lucas_WMDE: i think if anything its more optimized for the simplest possible way to prevent deadlocks during CI, without worrying about speed [18:38:27] oh right, those deadlocks [18:41:32] One weird consequence of sqlite, is if you read something in a transaction, then write something later in the same transaction, it can deadlock very easily (Maybe deadlock isn't quite the right word. It is impossible to upgrade the transaction to a write transaction if anything has written anything at all to the db in the time between the first read operation in the transaction and the first write [18:41:38] operation in the same transaction) [18:42:06] so the solution in mediawiki was to make every single transation a write transaction [18:42:25] which to me seems like a bad solution to the problem, at least if its a real wiki and not just unit tests [20:17:35] Looks like the installer also raises the following warning. If this is simply a chmod issue it's good to handle that in the Debian postinst script: Warning: Your default directory for uploads /usr/share/mediawiki/images/ is vulnerable to arbitrary scripts execution. [21:18:21] It's too much work with the Debian package to setup mediawiki. Unfortunately I don't have time to manually setup the DBMS. Hopefully the package maintainer scripts are fixed to do this automatically via dbconfig.