[13:09:39] Hello, I get the following problem when upgrading mediawiki 1.34.1 to 1.34.2: An error occurred: [13:09:39] Could not open "/maintenance/archives/patch-add-3d.sql" Does anyone know why this might be? [13:34:22] hamishtmb: Did you use 7zip to extract the archive? [13:34:27] (that file is not new in 1.34.2) [13:35:50] Reedy: No, I just used Engrampa (linux archive manager). I have checked and the file is where I would expect it to be (/multiwii/wiki/maintenance/archives) in this case [13:36:35] permissions wrong? [13:40:50] Question: is it possible to have the pages listed at Special:SpecialPages in a custom order, rather than alphabetical? [13:46:43] What should they be? [13:46:57] I have 775 [13:47:27] (and 775 for containing directory) [13:47:35] https://phabricator.wikimedia.org/T258947 [13:48:42] The best option is to create a new group [13:49:10] Okay. Can an extension change the group a core special page is in? [13:51:11] Makes me wonder if the upgrade script is looking in the wrong place for the files. Can I check somehow? [13:57:58] When my wiki mentions the paths... It does do them in full [13:57:59] ...ref_src_wiki in table flow_wiki_ref already modified by patch /var/www/wiki/mediawiki/extensions/Flow/db_patches/patch-increase-varchar-flow_wiki_ref-ref_src_wiki.sql. [13:58:07] But I'm not sure for core stuff [13:58:36] Hmm, maybe it is that then [13:59:12] I'm not sure why this would've suddenly been broken in 1.34.2 though [13:59:31] Someone else recommended I set $IP, but from what I gather at https://www.mediawiki.org/wiki/Manual:$IP I'm not meant to do that [13:59:40] It's probably my fault for not setting it up right. [13:59:53] I had to use SQLite at install time for a similar reason [14:02:51] Ah, you're talking about this thread https://www.mediawiki.org/wiki/Topic:Vozxj4enfde49gz2 [14:02:59] " Error 'Could not open "/maintenance/archives/patch-add-3d.sql"' when trying to update to 1.34.2" [14:04:27] Yes, that's the one [14:04:49] I figured everyone had forgotten about it, so I asked on IRC instead [14:14:49] Hmm, well setting $IP in LocalSettings.php didn't change anything. Setting it wrong deliberately definitely causes problems, but yeah, I'm really not sure where the install scripts are looking [14:16:11] if ( file_exists( "$IP/maintenance/$dbType/archives/$patch" ) ) { [14:16:11] return "$IP/maintenance/$dbType/archives/$patch"; [14:16:12] } else { [14:16:12] return "$IP/maintenance/archives/$patch"; [14:16:12] } [14:21:55] Okay, that aught to be fine then, as far as I understand it. I just relaxed the permissions of the files under maintenance/sqlite/archives too, but no difference [14:22:36] Seems to me like $IP isn't carrying through to the upgrade script then - it should be trying to use the maintenance/sqlite one. [14:28:12] I can't follow exactly how mw-config/index.php initiates the upgrade. What file is that from, rReedy:? [14:28:19] * Reedy:? [14:39:41] Okay, got past it. Had to manually set $IP in DatabaseUpdater.php. [14:39:54] Now, I get this after a bunch of database updating stuff: Purging caches... [14:39:54] An error occurred: [14:39:55] Invalid module info for "0": expected array, got NULL [14:43:29] Fixed that too, disabled $this->db->delete( 'objectcache', '*', __METHOD__ ); in DatabaseUpdater.php. [14:44:17] Now it's done, but I shouldn't have needed to do that, and I'm somewhat concerned that it will cause me problems. Any tips for how I can figure out why this happened? [14:47:37] [14:59:31] Someone else recommended I set $IP, but from what I gather at https://www.mediawiki.org/wiki/Manual:$IP I'm not meant to do that [14:47:42] I imagine that's a large amount of the issues [14:54:34] Could well be. [14:55:24] However, when $IP wasn't set (by me) the installer didn't upgrade it, and it still didn't work when I did set it, until I edited DatabaseUpdater.php and put it in there. Does anyone know why that would happen? [15:14:56] Could potentially be many things... Edge cases etc [15:15:05] If it was more widely broken, I'd imagine we'd have heard about it already [15:47:18] A bogus MW_INSTALL_PATH env var may also interfere with it [16:09:35] That's true, but I have no shell access so I can't check that sadly. [16:10:31] I agree though, this is probably not affecting many (or any) other people, or it'd probably already have been sorted. Thanks for the help anyway - my wiki is now up to date so that's all that matters :) [16:11:19] until the next time... :P [16:12:04] Yeah, I'll make a note of what I did so I can do it again XD [16:12:52] I wonder if the webserver config is making __DIR__ respond as is it's relative to whatever root it sets, rather than being as per the actual disk [16:30:21] That could definitely be a thing actually, good thought. I'll check the .htaccess stuff (I don't have access to anything else). [16:30:48] There's a whole lot of other stuff on the server too (Wordpress, phpBB, some other custom code I wrote) so it could be many things really [17:09:03] Reedy: how do you tell composer not to update unrelated indirect deps when updating mediawiki/vendor? [17:09:22] composer require? [17:09:27] I did `composer require wikimedia/html-formatter 2.0.0 --no-update` and ` composer update --no-dev --ignore-platform-reqs` but also getting an unrelated patch update to symfony/string [17:09:29] Or make sure everything is pinned [17:09:39] Krinkle: https://gerrit.wikimedia.org/r/c/mediawiki/vendor/+/615312 [17:09:42] I could partially stage but the hash won't match [17:10:31] If things aren't explicitly pinned, it's nearly always a mistake [17:10:56] hm.. even indirect ones? I thought we'd use lock for that and somehow tell it not to touch the rest [17:10:58] anyway, OK [17:11:04] * Krinkle CRs your stack first [17:11:47] Yeah, we do everything [17:12:05] Cause if sub-dependancies have non explicit dependancies, doing update will update everything [17:12:35] Reedy: right, I guess I was assuming there's a way to do that partally [17:12:48] I'd love to see the argument with composer [17:12:50] Reedy: so.. how I do figure out why certain dependencies exist in our vendor composer.json / know if they are still needed. [17:12:56] I imagine it wouldn't be fun [17:13:01] like why are we shipping symfony/polyfill-php80 [17:13:16] because symfony code depends onit [17:13:27] composer/yaml is the only core dep I see related to that [17:13:35] which doesn't afaik [17:13:57] https://github.com/wikimedia/mediawiki-vendor/blob/master/composer.lock#L3609 [17:14:05] https://github.com/wikimedia/mediawiki-vendor/blob/master/composer.lock#L3927 [17:14:13] https://github.com/wikimedia/mediawiki-vendor/blob/master/composer.lock#L4067 [17:14:13] "symfony/console" is suggested by yaml for the yaml CLI [17:14:18] but we don't use/need that [17:14:24] did we install it anyway? [17:14:35] psysh [17:14:36] https://github.com/wikimedia/mediawiki-vendor/blob/master/composer.lock#L3132 [17:14:45] ah psy/psysh also needs it [17:14:46] ok [17:14:48] * Krinkle shrugs [17:14:51] heh [17:14:56] so you want to update string also? [17:15:18] I can... I was just discussing it with cscott in #mediawiki-parsoid [17:15:27] The update came a few days after my patch [17:15:35] And has some kinda scary looking code [17:15:36] sticking with the version we have seems fine, but.. I can't easily tell now to what extent our version combination is expected/compatible. [17:15:46] although composer validates those constraints so I guess that's fine [17:15:47] composer would complain if it wasn't [17:15:51] yeah [17:15:55] OK, not needed now then [17:15:58] >if ('' === $c = (string) iconv('UTF-8', 'ASCII//IGNORE//TRANSLIT', $c[0])) { [17:16:20] and it doesn't need a core bump right? [17:16:23] cause its' all indirect [17:16:35] Yeah, nothing needed in core [17:16:52] Reedy: so should I C+2 your symfony/* patch as is, without symfony/string? [17:17:03] we can always do symfony/string as a follow up [17:17:22] just trying to figure out what to rebase my parsoid bump on [17:17:42] https://gerrit.wikimedia.org/r/c/mediawiki/vendor/+/615311/1 needs +2 to merge the symfony patch [17:17:53] I guess it depends if/how much of my stack of 3 get merged :P [17:18:04] oh, Krinkle just did both [17:18:11] cscott: now that it is pinned yours won't complain/dirty anymore [17:18:12] so it's fine [17:18:15] I had the same issue [17:18:41] Krinkle: are you doing to do the league/oauth2-server patch, though? [17:18:49] There's https://gerrit.wikimedia.org/r/c/mediawiki/vendor/+/615313/1 too to clear it all [17:18:56] I'm prepping an html-formatter bump [17:19:07] the annoying thing about composer is that the hash it uses will always make independent patches to mediawiki-vendor conflict. [17:19:31] eague/oauth2-server LGTM. [17:19:52] ok, cscott you can base your patch on top of that [17:19:55] I'll base my in yours then [17:20:48] cscott: you're doing parsoid 0.13.0-a2, right? [17:23:01] Krinkle: yes: https://gerrit.wikimedia.org/r/c/mediawiki/vendor/+/616335 [17:23:50] > Package guzzlehttp/ringphp is abandoned, you should avoid using it. No replacement was suggested. [17:23:50] > Package guzzlehttp/streams is abandoned, you should avoid using it. No replacement was suggested. [17:23:57] I don't suppose someone's on top of that already? [17:24:24] Nope [17:24:33] It's buried in the elastica stuff [17:24:45] They're dealing with it upstream (forking and replacing) [17:24:50] But until we bump stuff, we can't do anything [17:24:56] wonderful [17:26:29] I can't remember if it's ruflin/elastica or elasticsearch/elasticsearch [17:27:11] https://github.com/elastic/elasticsearch-php/issues/992 [17:27:27] >After some code review and since I'm going to refactor all the HTTP transport layer for elasticsearch-php 8.0.0, I decided to fork guzzlehttp/ringphp and guzzlehttp/streams and use this fork for elasticsearch-php 7.x [17:27:49] cscott: you have CR lined up for the parsoid bump and/or is it intended to go out this week? [17:30:19] Reedy: ah but they didn't properly fork, they have a clone of the repo using the same vendored name and override the package source in their composer.json. That's not gonna play well if you have non-zero other things in your stack using that. [17:30:35] unless they're identical in which case, why bother and not just take the warning shortterm [17:30:36] anyway [20:40:05] I've been troubleshooting Math extension issues over the past several weeks. A new error message appeared over the weekend; however, unlike the previous one it is not impacting the entire wiki. I'm quite confused. I've tried troubleshooting a few of the suggestions found online, but nothing has worked so far. Every time I've had an issue with this [20:40:05] extension, it's impacted the entire wiki. For example of extension working - https://wiki.seg.org/wiki/A_mathematical_review_of_the_Fourier_transform. And here is it not working - https://wiki.seg.org/wiki/Solving_equations. Any ideas would be much appreciated. [20:45:58] Huh weird, because that error looks like it should be global [20:46:00] Is the working page rednering using texvc? [20:47:22] How do you check that Reedy? I'm an amateur at this. [20:47:34] Its caching looks like [20:47:49] They are cached by md5 sum [20:48:11] So if you make trivial changes to the equation they start to fail [20:48:27] So the ones from before math broke continue to work [20:48:33] But new equations dont [20:49:38] If you enable mediawiki debug logging, it should tell you the exact shell command issued, which might help with your debugging [20:49:54] Also, somehow i thought texvc wasnt a thing anymore (?) [20:52:00] Thanks bawolff_. [20:53:04] The equations that aren't working aren't entirely new. They've been there for some months. But I will see if I can get some answers with the report. [20:58:17] It might be that cache was cleared at some point or the page just hadnt been viewed in a long time and there was no cache