we set the parser here https://github.com/wikimedia/mediawiki-extensions-Cargo/blob/master/includes/formats/CargoGalleryFormat.php#L151

I'm not sure:

I'm not sure how to reproduce, just saw it in the log I think. Gonna close as resolved for now since your change should fix it I think.

This release also makes mobile nav more responsive. It's improved more in 3.13 though.

Seems an upgrade to cgroups v2 is a must in trixie. No way to get existing behaviour to work.

It seems that enabling SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE doesn't fix the issue

This is happening for us as well since upgrading to Mariadb 11.8:

In T372404#11551206, @TheDJ wrote:

@Paladox any idea if this ever made its way to gerrit ?

Hi, Is there any update on this? I see some *.wikimedia.org have ipv6 addresses which is useless if the host is ipv6 only. Since they can't query the dns as it's ipv4 only.

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).