In T355376#9670539, @Tgr wrote:

Apparently SpamRegex and MultiMail also make use of shared tables.

Unclaiming this until I actually get back to working on Mirage.

I tried to reproduce this locally, but it works correctly. @Aklapper do you have access to the error log, and/or can you get a stack trace?

Because that's what Phabricator does when viewing a file in a repository. I viewed ROADMAP.rst in rPWBC, and that file showed up on https://phabricator.wikimedia.org/file/query/all/ right after. When viewing those temporary files, in the Attached tab, it lists the repository it's attached to, which is the source repository.

In T294188#10435047, @CCiufo-WMF wrote:

Not sure how much of an interest there still is in updating this icon, but the Design System Team may revisit the icon set holistically some time this year, and we can take this icon into account (cc @DTorsani-WMF).

I don't remember if this was on buster or not. T319167#8945448 seems to imply it is. Given buster is going away for MediaWiki-Vagrant, I'm just going to close this task, as apparently I was the only one unfortunate to experience it.

Does --dbssl not work? I added that option in 914882.

Let's reflect the status quo with https://gerrit.wikimedia.org/r/c/mediawiki/tools/phan/SecurityCheckPlugin/+/989246 being merged (or does that completely resolve this task?)

Removed in rMW3f9d716653fd0ff123e624931fb3b3e6bb09f0d2.

Hmm, the reason BackupDumper (and by extension MediaWiki-extensions-DumpsOnDemand) uses newMainLB is because of rMW506a19b7af78: Cleanup live hack from wmf-deployment r53208 a bit: DB selection using load… (r56347), where it mentions that not doing this might "have caused problems when we were fetching other things from the local database in the middle of an export". For MediaWiki-extensions-DumpsOnDemand, the release for 1.41 uses IConnectionProvider, which performs as proposed. I'm not sure what the impact would be, but given that IConnectionProvider does not have special handling for this (and the underlying internals have been greatly overhauled since 2009), I suspect this should be harmless. I'll create a patch for DumpsOnDemand for MediaWiki 1.40, which I'll backport to 1.39 for posterity, as 1.41 has not yet been released.

As an example, use: https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/937192.

What is the value of the Foo message (MediaWiki:Foo)? If it doesn't exist, ⧼Foo⧽ will be shown to indicate that the message is missing.

Is the alternative in the third good thing T290932?

Looking at the error log the following line seems suspect:

RequestFromGlobalsTest has a setServerVars helper that modifies $_SERVER. It is not cleaned up after the test, which causes issues when MediaWikiTest tries to use it.

It didn't so much as stop as it never actually started. If you check the logs, then you will see the following:

Note that the Bugzilla phabricator mapping isn't 1 to 1, Bug 1 is T2001. Bug 666 would be T2666.

Is this about https://github.com/stanolacko/LinkAttributes/? If so, you should post the patch there (as a pull request or as an issue), as the extension doesn't use Gerrit for version control or Phabricator for tracking tasks.

MediaWiki-Vagrant Buster now has a separate role for phan that installs php-ast: T321987: Create a separate role for phan that also increases the memory limit, the scripts are no longer necessary.

In T321984#8354942, @Mainframe98 wrote:

If anyone wishes to do this themselves, these links might help you: https://wiki.debian.org/Teams/Cloud/VagrantBaseBoxes, https://developer.hashicorp.com/vagrant/docs/boxes/base

(https://salsa.debian.org/cloud-team/debian-vagrant-images too)

I split the patch into two parts, mostly because I'm not very familiar with node/npm in Vagrant. I think the complexity came from the whole, "node is outdated but things rely on outdated npm" debacle, so be sure to test if it actually works. It provisions at least.

I'm experiencing T338356: Vagrant fails to create apt.conf.d/01no-recommended during setup and couldn't find a fix. It turned out to be easier to just convert to bullseye. It would be great if we could get a separate branch to use while we wait for production to move to bullseye.

Somewhere along the introduction of run.php this appears to have been resolved. (Tested on rMW44504ffaff7933ff638f5bb0dd62bb253970f78b)

I0ce7c2cd3eed958bb99f1a2e7c4a45c51668869d takes a different approach: check the password before creation. This will only fail like mentioned in the description when the groups added have a different password policy than the default. That should be rare: most times those group changes happen on-wiki to record them in the logs.

I'd noticed that too. Maybe just print a warning then? Or generate a valid password and print that perhaps, although given the flexibility of password policy requirements, that might not be achievable.

For T21157, the description matches:

Is T335995 similar? I can't tell if here the repository suddenly travelled back in time like what happened to mediawiki/core in T335995.

It would be the first PHP extension that isn't bundled with PHP on Windows. Given that PECL doesn't offer new Windows DLL's anymore, this would (in the future) make using MediaWiki on Windows more difficult. The compilation process on Windows isn't easy either.

Exciting! I'll give that a try, thanks!

Using Late Static Binding is a solution for those cases, and what I used in 904876.

It shouldn't be removed. The static keyword does two things for closures: it prevents usage of $this, and prevents binding an instance to a closure.

Note that some providers would meet the requirements for auto fixing, but cannot be made static because they are an override of a non-static method defined in a parent class (e.g. HookRunnerTestBase).

This functionality is provided by the Stockphoto gadget. Issues with gadgets are not handled on Phabricator, they should be reported on the talk page.