3.10.9 is out with the fix

3.10.9 is out with the fix

Primary git hosting is Gerrit (https://review.opendev.org/) with gitea used as a repo viewer.

In T407557#11285825, @jhathaway wrote:

deploy2002 is running bullseye, which has ssh 1:8.4p1-5+deb11u5, so it does not have any of the post quantum algorithms that were first added in 9.0.

gerrit1003 is also bullseye, but the issue is gerrit itself, rather than the openssh-server. I think gerrit uses, https://github.com/apache/mina-sshd, I'm not sure whether it supports any of the post quantum algorithms yet.

This was already fixed with https://gerrit.wikimedia.org/r/c/mediawiki/skins/Metrolook/+/1134366 just it wasn't in MW 1.43/MW 1.42 branches.

Shouldn't the status of this task be changed from stalled?

Thanks! That fixed it.

This didn't fix it. I filled https://phabricator.wikimedia.org/T405733.

Oh I think https://github.com/GerritCodeReview/gerrit/commit/3ffc3b13b6dea42079d1f98aa8c899df29832c6b fixes it.

This is fixed on gerrit @ master (I can reproduce on gerrit.wikimedia.orgbut not on gerrit-review). I dunno what fixed it.

Backported to https://gerrit-review.googlesource.com/c/gerrit/+/509464

I think https://gerrit-review.googlesource.com/c/gerrit/+/473627 may fix this.

the mobile UI has been further improved in Gerrit 3.13 (when released):

There's https://gerrit-review.googlesource.com/c/gerrit/+/436258 upstream. Although not much progress on pushing it forward.

it has since been merged and will be in gerrit 3.13.

This is causing https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CookieConsent/+/1187366/8 to fail with:

From your logged message, you added 11212 rather than 11211.

I think it's now https://we.phorge.it. https://we.phorge.it/book/phorge/article/cluster_notifications/

Thank you!

In T394708#10895930, @Mstyles wrote:

Thanks so much @KFrancis. @Paladox we will need you to add 2FA to your account before security issue access can be granted. Please set up 2FA.

In T394708#10868875, @KFrancis wrote:

Hi all, the NDA is out for signatures. I'll confirm when it's complete.

In T394708#10868675, @KFrancis wrote:

Sure, no problem! @Paladox , to process an NDA for you, I'll need the following information: Your legal name, your mailing/postal address, your email and please provide some information about the access you need. To protect your privacy, please send these items to kfrancis@wikimedia.org. Thank you!

I've done: https://gerrit-review.googlesource.com/c/gerrit/+/474382

It seems it is being added with https://github.com/GerritCodeReview/gerrit/blob/9a4495266202363e5ba92abddea72b5550f15dbd/resources/com/google/gerrit/server/documentation/flexmark-java.css#L3

thanks!

I can't seem to ping the ipv6 address:

In T391374#10750390, @thcipriani wrote:

@dduvall mentioned a couple updates here in the Release-Engineering-Team team meeting:

• that this new zuul is now listening to gerrit.wikimedia.org stream events
• that it is now limited to mediawiki/core

Further stuff worth mentioning:

• There's a new branch with the config for zuul in the integration/config project: zuul3
• The zuul-1001.zuul3.eqiad1.wikimedia.cloud is running zuul components via the upstream docker-compose.yaml example set up
• This is all on the zuul-1001 box in /usr/local/src/zuul/doc/source/examples
• Tennant config lives at /usr/local/src/zuul/doc/source/examples/etc_zuul/main.yaml (and includes mediawiki/core as a "untrusted-project")
• There are noop jobs for the check and gate pipelines (projects.yaml)
• The jobs should trigger on patchset-created (pipelines.yaml)
• It's not triggering...for some reason right now :)

---

Not triggering on new patchsets

docker compose logs scheduler in /usr/local/src/zuul/doc/source/examples shows the zuul debug log.

I found a patchset-created event

2025-04-16 22:20:18,973 DEBUG zuul.Pipeline.wikimedia.check: [e: fd992fbd3a57422ba499cd82a5b7e3a2] Event <GerritTriggerEvent patchset-created gerrit.wikimedia.org/mediawiki/core master 1137061,3> for change <Change 0x7fedec06d190 mediawiki/core 1137061,3> does not match <GerritEventFilter connection: gerrit types: patchset-created ignore_deletes: True> in pipeline <DependentPipelineManager check> because False

soooo because False :)

I note that the GerritEventFilter is not what I'd expect given what's in the zuul3 branch of integration/config.

This should fix T355816 and I think this will fix T355259

FYI the api is changing for WikiDiscover - https://github.com/miraheze/WikiDiscover/pull/88

This is fixed now. You can re-run your script.

https://phabricator.wikimedia.org/F58932052 has nothing to do with this. It's to do with the wikimedia checkers plugin.

In T355816#10676426, @hashar wrote:

@Paladox you are really a jewel to the wikis movements. Thank you!

The fix is backported to 3.11 by https://gerrit-review.googlesource.com/c/gerrit/+/463081

https://github.com/GerritCodeReview/gerrit/commit/6f8e72e0e818740136415dd163ebc2bd330b5ab5 is in stable-3.10 now.

Fixed with https://gerrit-review.googlesource.com/c/plugins/codemirror-editor/+/462842

Gerrit isn’t using web sockets for this I believe. It uses service workers https://github.com/GerritCodeReview/gerrit/blob/master/polygerrit-ui/app/services/service-worker-installer.ts

You can use the tab key. Although it should probably default to tab when you press enter to go onto a new line.

I filed https://github.com/highlightjs/highlight.js/issues/3995 but was closed without a fix.

I fixed it locally. An extension had a newer http-message version. We use a tool to deploy mw. So the version I was looking at was different to the one on another server. I eventually found the cause. And re-deployed the extension with the correct version.

Fixed with https://gerrit-review.googlesource.com/c/gerrit/+/459881

Other users have said it broke for them (unrelated to us).

I wonder if it’s because of https://github.com/GerritCodeReview/gerrit/commit/c937746515032313ec25d3aba8f3ae2c490cdce5

In the jobrunner getOutput could be null.

I'm not entirely sure how to fix it. I see this:

I think MediaWikiServices::getInstance()->getParser() alone doesn't set an output? (I'm not sure what will fix this)

We now run MW 1.43.

This seems to still occur.

Fixed with https://github.com/GerritCodeReview/gerrit/commit/689e240425f06b233c9641212af2a9a5fa0154ad

Bug caused by https://gerrit-review.googlesource.com/c/gerrit/+/300007/ at least according to https://gerrit-review.googlesource.com/c/gerrit/+/300007/14/java/com/google/gerrit/server/patch/PatchFile.java#56

A upstream issue was filed that I think is related to this: https://issues.gerritcodereview.com/issues/387440281

In T382728#10422372, @Reedy wrote:

I've deleted the tag

I presumed this was used in an extension CI test but it wasn't. I can close this out if this isn't feasible (or wanted).

Can this be closed as resolved?

It's properly fixed with https://gerrit-review.googlesource.com/c/gerrit/+/444763

In T380791#10355323, @SomeRandomDeveloper wrote:

This was added in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Translate/+/1071145 . The hook was added recently for 1.43 so the version requirement of Extension:Translate probably needs to be raised to 1.43.

There's no project for OpenLayers tho.

In T216508#8808277, @Yaron_Koren wrote:

@Paladox - sorry for the extremely long delay on this; OpenLayers is now already up to version 7, I believe. Is this an issue for the Page Forms extension, though, or for the OpenLayers extension?

This was fixed 5 months ago. Closing as resolved.

Just gonna decline as I guess it's expected extensions handle this?

Think I fixed HAWelcome with https://gerrit.wikimedia.org/r/c/mediawiki/extensions/HAWelcome/+/1095303 which I guess makes it a extension problem?

Or we can wrap https://github.com/wikimedia/mediawiki/blob/master/includes/title/Title.php#L906 in sanitizeIP.

I'm not entirely sure what the fix would be. We can either remove that piece of code or we could do use prettifyIP()?

This is our ip I'm using to demonstrate the problem but it's HAWelcome that was having the problem with some users ip. I cannot share that ip for gdpr reasons, hence why I'm using our ip to demonstrate.

https://github.com/wikimedia/mediawiki/blob/master/includes/title/MediaWikiTitleCodec.php#L556 seems to be the cause.

Nvm, it's correct