[10:53:16] Hello and Big thanks for the MediaWiki, highly valuable for my pro-bono pursuits [11:01:01] I have noticed there is 5.5GB of thumbnails in w/images/thumb on one wiki. From manually sampling the filenames I can tell, that most of the thumbnails are of images that have never been added to the wiki proper, yet there are the 5.5 GB of the thumbnails. [11:01:42] This is likely a configuration issue and if someone has some pointers as to what I should do to 1. clear the thumbnail "spam" and 2. stop it from accumulating in the future, it would be much appreciated. Thank you. [11:39:48] Do you mean they're images loaded from Commons etc? [11:42:48] Reedy: they seem to be loaded via Instant Commons. I do not recall ever enabling pulling images from just any site [11:43:15] I think it's on by default [11:43:39] pulling images from any site? [11:43:53] instant commons [11:44:16] !wg AllowExternalImages [11:44:16] https://www.mediawiki.org/wiki/Manual:%24wgAllowExternalImages [11:44:18] oh, this wiki was founded in February 2003 so Instant Commons didn't even exist [11:45:17] $wgAllowExternalImages" not found [11:45:25] in my LocalSettings.php [11:45:42] oh yeah, but it was on by default, right [11:46:18] Reedy: My guess is that some seedy types of internet users have noticed that my wiki isn't cleaning up the thumbnails it creates [11:55:19] I made a change to the config in 2022: [11:55:23] $wgGenerateThumbnailOnParse = true; # changed to this on 2022-05-28 [11:57:34] it does seem like some users are / were able to create thumbnail images without actually adding the images themselves to the wiki and now I have 5.5 GB of questionable thumbnails [12:10:27] If you preview an edit, but don't save it... [12:10:38] Are you running a recent version of MW etc? [12:10:46] You can just nuke the thumbnails folder if it's causing you issues [12:22:42] I'm running 1.39.10. I'm in the process of upgrading to 1.39.11 and then to 1.43.0 [12:23:14] Reedy: so by nuke you must mean delete or empty. and the thumbnails will be rebuilt? [12:23:19] Yeah [12:23:29] Ok. thanks Reedy [12:23:30] If they're needed, they should be regenerated [16:22:01] Ok, the upgrades to 1.39.11 are done, but I'm running into issue on the first wiki I'm trying to upgrade to 1.43: [16:22:39] When trying to run "composer update --no-dev" I get error "found wikimedia/at-ease[v2.0.0, v2.1.0] but it conflicts with your root composer.json require (3.0.0" [16:23:50] wikimedia/css-sanitizer requires that wikimedia/at-ease and css-sanitizer would be happy with version 2.0, but the composer.json in the /mediawiki/ really does require version 3.0.0. What to do? Thanks in advance [16:31:01] Hi, I am trying to upgrade a wiki from 1.29 to 1.35.14 (to later update to 1.43) and got stuck. The wiki uses sqlite. [16:31:03] When I run "php maintenance/update.php", it fails with "Renaming index cl_from into PRIMARY to table categorylinks ...PDOException from line 367 of /srv/quakewiki/w/includes/libs/rdbms/database/DatabaseSqlite.php: SQLSTATE[HY000]: General error: 1 index cl_sortkey already exists" [16:31:28] full traceback https://dpaste.org/fynDH [16:33:54] hannes_: you'll need to do some manual cleanup of the db; it seems there has been some drift between what you have and what mediawiki expects you to have [16:37:04] i'd probably be able to do that, any pointers how i can find out what i will have to edit? [16:40:18] does the updater maybe recreate all indexes if necessary? then i could just drop them all :D [16:41:45] well that one is complaining " index cl_sortkey already exists" [16:41:55] so try making a backup of your db and then dropping that index [16:42:14] then re-run update.php and see if it works or if it blows up somewhere else [16:42:21] iterate until it all works :P [16:42:50] I wouldn't rely on the updater recreating all missing indexes, it's more likely to complain that an index it's expecting doesn't exist and then fail [16:43:39] the MW schema update process is by far the most fragile piece of the entire update process [16:52:33] i can imagine [16:53:08] dropped ~20 indexes, now it is doing "Beginning migration of revision.rev_comment to revision_comment_temp.revcomment_comment_id". let's see if it proceeds [17:40:16] I looked at the search results for "wikimedia/at-ease" https://phabricator.wikimedia.org/search/query/c34Ge_DWlwV3/ and it seems the composer.json would need to have "wikimedia/at-ease": "^2.0.0 || ^3.0.0" for the upgrade from old LTS to new LTS could complete, yet the composer.local.json-sample I moved to composer.json has only ^3.0.0 and it was that way in the repo a couple of hours ago [17:44:37] Reedy: I'm having a dependency definition mismatch with 1.43 I just git cloned a couple of hours ago, as I'm describing above. [17:44:57] I could try to edit the composer.json, but that would fix the dependency mismatch only for me in 1.43, so should I bug report and wait on it or what would be the best course of action? [17:54:06] is there... a good reason for this inconsistency? https://codesearch.wmcloud.org/core/?q=%28%28lower%7Cupper%29.%3Fcase.%2Aheader%7Cheader.%2A%28lower%7Cupper%29.%3Fcase%29&i=fosho&files=.%2Aphp%24 [17:55:00] yuker: delete your composer.lock file and rm -rf your vendor/ dir, then composer install --no-dev [17:56:18] in https://phabricator.wikimedia.org/rEWBAbd5848ec0669ad256c2497a2883bfa7a5de60c64 the line is "wikimedia/at-ease": "^2.0.0 || ^3.0.0", but perhaps that has not made its way to the composer.local.json-sample ? [17:56:53] Generally you should not be overwriting composer.json with composer.local.json-sample [17:57:20] yes, the sample is meant to create a composer.local.json that coexists side-by-side with the composer.json shipped by mediawiki [17:57:46] ahh, I have moved the file to the wrong filename it seems? [17:57:49] if you modified composer.json reset it back to what exists in git [17:58:12] * yuker goes back to bash history to check what I did [17:58:23] (then do the same thing about removing .lock and vendor, and doing a fresh composer install) [17:59:50] Thank you everyone, this is starting to clear in my head [18:05:56] I did not modify the composer.json, instead I moved composer.local.json-sample to composer.local.json, which is what I want so that the composer.json in the extension directories get included [18:06:24] yep [18:06:28] that all sounds correct [18:09:04] yuker: other thing to check, did you update all of your extensions to be compatible with 1.43 as well? [18:10:28] if you use git, a number of extensions are bundled as submodules but those don't get updated by default (need --recurse or the various git submodule * commands). If you have extensions outside of the bundled ones, those need to be updated separately [18:10:59] Here is a paste of me running 'composer update --no-dev' and there is a clear version number mismatch problem https://pastebin.com/9W9W3tm5 [18:14:01] the only extension that did not come with the MediaWiki is MatomoAnalytics [18:20:09] MatomoAnalytics should work fine with 1.43 [18:20:17] Thanks RhinosF1 [18:20:46] Hmm [18:20:54] I'm surprised by that error [18:21:58] I am doing the clean install + copy files + upgrade route for these 1.39.11 -> 1.43.0 upgrades [18:22:07] I don't think that's Matomo related tbh [18:23:09] I have a thought [18:23:11] I used 'git clone https://gerrit.wikimedia.org/r/mediawiki/core.git --branch REL1_43 mediawiki' to get the code 4 hours ago. [18:24:24] Hmm [18:25:47] Not sure then [18:27:28] to me it looks like that if wikimedia/css-sanitizer required 3.0.0, and not 2.0.0, then the composer command could complete without problems [18:32:43] Or the root composer.json required 2.0.0 [18:32:55] What's in your composer.json [18:33:14] I have fresh clones of REL1_43 as part of my internal mw build/scripting and composer succeeds without issue there, so it does seem specific to your env [18:36:20] RhinosF1: in composer.json is "3.0.0" [18:36:40] Did you make that or get it from core [18:36:52] get it unmodified [18:39:12] Ok [18:45:41] Composer version 2.8.5 2025-01-21 15:23:40 [18:45:41] PHP version 8.2.26 (/usr/bin/php8.2) [19:24:18] update.php is still stuck at "Beginning migration of revision.rev_comment to revision_comment_temp.revcomment_comment_id", with 100% cpu. i wonder if it is missing some indexes =) [19:25:15] how big is your wiki? [19:27:11] tinyish, ~1000 pages [19:31:51] it is updating the sqlite file, probably just super slowly [19:47:51] yeah, sqlite will be super slow [20:06:05] i guess it is not using a transaction? [20:09:25] Anyone have a eli5 or a link to how to install a template? specifically looking to install this one https://www.mediawiki.org/wiki/Template:Key_press [21:48:35] I found the culprit .. my tiny script that git clones the needed extra extensions had a hardcoded branch value in it, so my bad, apologies for noise [21:59:02] Not sure if this is the correct channel for asking this, but how do I fix merge conflicts of a dependent commit? I just uploaded a changeset (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1113875) to gerrit which depends on another commit. However, the other commit was done before a third commit that has been merged since and now conflicts with [21:59:03] the one I just uploaded. I tried updating the branch as described at https://www.mediawiki.org/wiki/Gerrit/Troubleshooting#Build_failed_due_to_merge_conflict but git review attempts to update the patchset my new one depends on ("cannot add patch set to 1113225") which I neither have permission for nor am I intending to update. Is there any way to [21:59:03] fix the merge conflicts and update the branch of the new patchset without updating the one it depends on, or do I have to wait for the one it depends on to be merged? [22:59:20] serp: a typical way to copy a template from one wiki to another would be to use Special:Export to make an XML dump of the template and it's dependencies and then Special:Import on the target wiki to load the dump. [22:59:22] https://www.mediawiki.org/wiki/Help:Export [22:59:34] https://www.mediawiki.org/wiki/Help:Import#Upload_import [23:00:17] oh! https://www.mediawiki.org/wiki/Help:Templates#Copying_from_one_wiki_to_another [23:40:33] SomeRandomDev: The "stack" of patches needs to be rebased and have edit conflicts fixed. I assume you are getting the error from gerrit because your account is not yet marked as a trusted contributor. In that state you can upload your own patches, but CI won't run automatically and you cannot modify patchsets uploaded by others. [23:44:51] SomeRandomDev: you could leave a message on the ancestor changeset asking for a rebase, or potentially you could break the relation chain by rebasing your changeset on origin/master directly instead of on Bartosz's changeset. It at least doesn't look to me like your change is actually structurally dependent on that parent. I may certainly be wrong about that. [23:44:54] bd808: I am on the CI allowlist, I don't think that allows me to modify other contributor's patchsets though. I don't want to edit the other patchset anyway since it will (hopefully) be merged soon, I was just wondering whether there was a solution to the problem by just rebasing my own changeset. I guess I'll just wait for the other changeset to [23:44:54] be merged, mine can't be merged before that happened anyways [23:49:06] hmmm... maybe a person has to have +2 to upload new patchsets to an existing change? [23:50:40] yeah, that is apparently sort of the deal. More technically you need the "Add Patch Set" right and we grant that in the mediawiki/* repos to the same user group that we grant the +2 right to. [23:51:30] TIL because I have always been in that group so I never stumbled on this before [23:52:26] Makes sense, it could cause some problems if anybody could just modify other people's changesets which can happen accidentally as well for people who are not too experienced with git