Note I have disabled the account in Gerrit.

@DLynch thank you for your comment! I am trying to avoid injecting VisualEditor whenever possible :]

Thank you very much and for referencing the task about CentralAuth not being in the gate.

Verifying the CI checkout. From the build log:

17:12:00 INFO:zuul.Cloner:Prepared mediawiki/core repo with branch master at commit 7a633cf8f02c0e16f697e70ab85d9dea796441c2
17:12:18 INFO:zuul.Cloner.mediawiki/extensions/CentralAuth:Prepared mediawiki/extensions/CentralAuth repo with branch master at commit 66e10f75115d4e60d18e7cbc6f273a184152d6fa

The series of patches I have made were to have the cldr extension name to have a lower case cldr name in extension.json. Most of the patches were to add have calls to ExtensionRegistry()->isLoaded() to be made against each of cldr and CLDR. That is a way to "fix" it when it is problematic for an extension.

@Soda I have deployed it because the same setting has been enabled on other wikis and there is a public RfC which showed it was low risk. Maybe I could have asked for a bit more discussions, then given it is low risk I choose to deploy it immediately to reduce the waiting time.

I can confirm the BarryTheBrowserTestBot account is now inactive in Gerrit. From the All-Users.git database:

$ git show
commit 94c67416a2c1adc8bde631e6c9e72701915e424f (HEAD -> users/53/2653, origin/users/53/2653)
Author: [BOT] Gerrit Code Review <gerrit@wikimedia.org>
Date:   Fri Oct 3 06:39:58 2025 +0000

As part of this task I found out that the logic to ban an account in Gerrit was not migrated from the wikitech-l MediaWiki hook to Bitu. Blocks were ineffective. I went to implement support for blocking users in Gerrit by porting the PHP code to Python. This was done via T390070

We had an outage yesterday related to the QoS limit, it was only reported on IRC/Slack. For the record:

16:25:38 <bearloga> Is anyone else experiencing Gerrit being so weird and not always loading today?
17:54 <aude> is it just me or is gerrit slow today and intermittently not loading? (and to lesser extent maybe phabricator too)
19:08:48 <James_F> Also specifically I'm getting "Plugin install error: https://gerrit.wikimedia.org/r/plugins/wm-motd/static/wm-motd.js load error from https://gerrit.wikimedia.org/r/plugins/wm-motd/static/wm-motd.js " errors.
19:42:33 <bearloga> My experience has been a mix of: Gerrit not loading at all, Gerrit loading after a while, Gerrit loading but blank and errors about a bunch of plugins

The REL1_39 patch took a bit longer because CI was failing:

/src/resources/dist/mobile.common.js
00:01:30.848 1:97 error Parsing error: Unexpected token >

That is a file generated by Webpack. It has ES6 arrow functions while the Eslint configuration is still relying on es5.

The WikiKube cluster was successfully upgraded yesterday, I am thus removing it is task T405703 from the list of subtasks, that confused some people earlier today.

As you have mentioned in chat, that sounds very similar to the Wikibase git project which hosts both the Wikibase client and the Wikibase repository (and who knows what else). From a CI point of view, I would like to not see this pattern used anywhere else, it is an operational challenge :-(

I ended up reverting it with https://gerrit.wikimedia.org/r/1193024 and that solved the spam. I have added a comment on the tasks that originated that deployment. Meanwhile, the log spam is gone and this is resolved as far as the train is concerned.

The same was forgotten again when deploying to more Wiktionaries T406185 :)

I have reverted the deployment of the Wikifunctions client mode on Incubator. The databases are missing the wikifunctionsclient_usage table (T406185).

I reverted the deployment of the Wikifunctions client mode on Wikitionaries. The databases are missing the wikifunctionsclient_usage table.

According to logs, the first entry was at Oct 1, 2025 @ 21:33:38.923.

On top of your wikitech-l announce, I have proposed a change to add a banner at the top of the Gerrit web UI that will looks like:

I have send patches to all extension to have them check either cldr or CLDR is loaded using:

$registry->isLoaded( 'CLDR' ) || $registry->isLoaded( 'cldr' )

I have removed two of the blockers:

We are blocking the train this morning due to a back compatibility issue in some of our rare private code (T406094). When that is sorted out, we will resume the train.

https://gerrit-review.googlesource.com/c/gitiles/+/514361 Tests: update path prefix in git urls
https://gerrit-review.googlesource.com/c/gitiles/+/514362 Fix edit link when base URL has a path

The link is missing the /r prefix in the path. The [edit] was introduced by https://gerrit-review.googlesource.com/c/gitiles/+/392465 (released in gitiles 1.5.0). It is implemented differently from the other urls.

I am pasting comments I have made on a Slack thread:

This has been fixed and backported.

I have rebased the security patch (T398636), the train-presync job failed overnight due to an erroneous throttling that was put in place on Gerrit (T406005) and it has been removed. I have started the train again on the deployment server (sudo systemctl start train pre-sync).

Well it failed again:

Sep 30 09:29:17 deploy2002 scap[711190]: Cloning into '/srv/mediawiki-staging/php-1.45.0-wmf.21/extensions/FundraiserLandingPage'...
Sep 30 09:29:17 deploy2002 scap[711190]: error: RPC failed; curl 35 gnutls_handshake() failed: Error in the pull function.
Sep 30 09:29:17 deploy2002 scap[711190]: fatal: expected flush after ref listing
Sep 30 09:29:17 deploy2002 scap[711190]: fatal: clone of 'https://gerrit.wikimedia.org/r/mediawiki/extensions/FundraiserLandingPage' into submodule path '/srv/mediawiki-staging/php-1.45.0-wmf.21/extensions/FundraiserLandingPage' failed
Sep 30 09:29:17 deploy2002 scap[711190]: Failed to clone 'extensions/FundraiserLandingPage' a second time, aborting
Sep 30 09:29:17 deploy2002 scap[711190]: Cloning into '/srv/mediawiki-staging/php-1.45.0-wmf.21/extensions/Wikidata.org'...

Train blocker task is an Unbreak Now! priority. I am pretty sure this was a off by one transient issue and it is not worth looking deeper, but we shall see.

Per @ABran-WMF:

The upgrade to Bookworm upgrade was blocked by the need to fix throttling to deter scrapers, it should resume after https://gerrit.wikimedia.org/r/c/operations/puppet/+/1189386 is merged.

A similar one:

1) WikibaseManifest\Test\SpecialPageOAuthUrlTest::testGetValue
ArgumentCountError: Too few arguments to function MediaWiki\Extension\OAuth\Frontend\SpecialPages\SpecialMWOAuthConsumerRegistration::__construct(), 3 passed in /workspace/src/extensions/WikibaseManifest/tests/phpunit/SpecialPageOAuthUrlTest.php on line 26 and exactly 4 expected

I have started another run against the extensions that previously failed:

I have confirmed my use case (CodeMirror + VisualEditor without TemplateData) has been fixed.

Paladox has let me know Gerrit maintainers have announced support for Gerrit 3.10 will stop on November 10th.
https://gerrit-review.googlesource.com/c/homepage/+/510701

Regarding the old wmf/ branches, we went to delete them since T244368 and I have fixed the deletion again last winter via T303828 (which took me several weeks overall :] ).

Copy pasting my comment from Slack

See:

# T363639 - WebAuthn won't run on REL1_XX because of library issues
# T390754 - Just don't load WebAuthn at all if it's not master, or it's Parsoid
if (
    'WebAuthn' in ext_deps and (
        not (params['ZUUL_BRANCH'] == 'master' or params['ZUUL_BRANCH'].startswith('wmf/'))
        or params['ZUUL_PROJECT'] == 'mediawiki/services/parsoid'
    )
):
    ext_deps.remove('WebAuthn')

This is for a patch to patch targetting WebAuthn with branch REL1_43.

Thank you for the additional details @DLynch

In T398224#11182958, @Daimona wrote:

For CLDR, yeah. But there are more extensions that would suffer from the same bug, unfortunately. At the very minimum, everything whose name includes spaces, and there's a lot of them. In the installer, and perhaps other parts of the code, there's confusion between directory name and extension name, so we should do something about it. I'm just not sure what...

I think this can be addressed by simply changing the name to the all lower case cldr in the mediawiki/extensions/cldr extension.json.

I think the reason composer fails is due to WebAuthn extension being pulled as a dependency. It requires web-auth/webauthn-lib ~3.3.12 which does not work with php 8.2. T363639

I have the issue on https://gerrit.wikimedia.org/r/c/mediawiki/extensions/BlueSpiceVisualEditorConnector/+/1187412. The php 8.1 job does pass but the 8.2 or 8.3 failed.

Thank you for having tracked it upstream!

We did some fixes such as:

I have updated the cl_category in the schemas to have cl_target_id to be inserted (it is required now):

In T404346#11172854, @Ladsgroup wrote:

I really don't think CI failure of a random unmaintained and not-deployed extension where even the maintainers are not willing to fix the issue (see T403196) should be considered a blocker for T299951: Normalize categorylinks table. I'm removing the parent-child relation.

And I got another one that fails https://gerrit.wikimedia.org/r/c/mediawiki/extensions/BlueSpiceFoundation/+/1187441:

There was 1 failure:

In T404346#11172717, @DAlangi_WMF wrote:

Also see T403196: Disable meaningless, never green CI jobs for BlueSpice (Hallo Welt! GmbH) extensions where @thiemowmde started a discussion relating to the way forward on this.

I found the same issue with BlueSpiceFoundation @master. The function comes from https://github.com/hallowelt/mwstake-mediawiki-componentloader/blob/master/bootstrap.php which is the composer package mwstake/mediawiki-componentloader.

I think the faulty code is:

		$oDbw->insert(
			'categorylinks',
			[
				'cl_to' => "Dummy test",
				'cl_timestamp' => $oDbw->timestamp()
			],
			__METHOD__
		);

CookieConsent composer.json has:

{
  "scripts": {
    "test": "composer phpunit tests/"
    "phpunit": "php ../../tests/phpunit/phpunit.php -c phpunit.xml.dist",
  }
}

1124783 is an 1.44.0-wmf.18 backport. 1121797 was merged to master sufficiently long ago that it's now included in 1.44.0-wmf.18. Not a big deal but it would be nice if scap could figure that out.