I guess this is almost a duplicate of T168365: Use new standard MediaWiki error reporting with Wikibase API and/or T168367: Disable custom error reporting in the API if new error format is requested. – I hadn’t seen those tasks before.

It looks like it’s possible to get similar information out of Kubernetes:

Maybe we can work on this during the hackathon? I’ve heard a few interested people will be there :)

Yeah, it feels like the sort of tool it could be quite useful for.

I’ve squashed the above change into the Gerrit change that introduces the class; moving to peer review in case someone wants to take a look, but I don’t think it needs a lot more time spent on it :)

Easy enough to fix:

In T362653#9722788, @Stashbot wrote:

Mentioned in SAL (#wikimedia-operations) [2024-04-17T15:04:21Z] <Lucas_WMDE> lucaswerkmeister-wmde@mwmaint1002:~$ mwscript namespaceDupes mlwiki --fix # T362653: 0 pages to fix, 0 were resolvable; 82 links to fix, 82 were resolvable, 0 were deleted.

I actually can’t reproduce this at all anymore. Let’s just chalk it up to the WIP-ness of the previous patches (which are now less WIP – I’m testing Wikibase 1ff1c5334f and EntitySchema 8f0596f2f1) and close it as invalid. If the problem comes back we can reopen the task or create a new one.

This is probably a side effect of us not having a real “expert” yet (T362004). I’ll see if I can hack together a sham expert to confirm this theory.

In T354597#9722424, @gerritbot wrote:

Change #1015295 merged by jenkins-bot:

[operations/mediawiki-config@master] WikimediaEvents: Set IPoid URL and enable ip_reputation/score

https://gerrit.wikimedia.org/r/1015295

It looks like the above three changes are enough to make PHP 8.2 and 8.3 pass \o/

Previous bastions had (due to the grid) all the locales which I'd like to avoid.

I also get a locale error (“manpath: can't set the locale; make sure $LC_* and $LANG are correct”) when connecting to toolforge-dev with normal SSH:

Is this still an UBN? I’m not really sure how the above two patches relate to this.

There are a bunch of additional failures in this build (for this change) (from this video); some of them look like they don’t really require separate tasks, so let’s attach some fixes directly here, I think.

Prio Notes:

Prio Notes:

Prio Notes:

It’s documented here, by the way: https://www.mediawiki.org/wiki/Manual:Collapsible_elements#Custom_toggle_link_placement

Okay, I see. Anyway – we should definitely be able to document the props (even if there’s just one of them at the moment) – see the query+info docs for comparison: MediaWiki supports adding a documentation message for each supported value.

Apparently this was still open and assigned to me… let’s assume it’s fixed, feel free to reopen otherwise. (There’s been some movement in these browser tests anyways, e.g. they’ve been ported to async mode in T300807.)

@thiemowmde can you see if it works better now?

In T362505#9712645, @gerritbot wrote:

Change #1019691 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] DataBridgeReferenceFormatter: Use message as text

https://gerrit.wikimedia.org/r/1019691

Yeah, I think the other test failure in the linked CI build (“Expectation failed for method name is "addCategory" when invoked 1 time(s).”) also would make some sense with a broken message cache – in that case, TrackingCategories might resolve the tracking category to an empty / disabled category, and therefore not call addCategory() on the ParserOutput.

Wikibase’s own CI seems to be working at least, https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1019064 was merged just an hour ago.

Scratch all that, my Cite was just outdated. After updating it I can’t reproduce the error anymore.

Yeah, splitting the job also sounds fine to me.

(why would you pass an empty value?)

Locally, git bisect says the first bad commit is Deprecate use of dynamic properties attached to Parser (T343227). However, it fails with an error Use of MediaWiki\Parser\Parser::$extCite was deprecated in MediaWiki 1.42. that I don’t see in the linked CI output.

In T362412#9710114, @Lucas_Werkmeister_WMDE wrote:

• make those jobs run on PHP 8.1 on all branches (After all, we still have other CI jobs to cover PHP 7.4 compatibility while we need it for production.)

(Probably not a blocker for the release, just related to it.)

Potential options:

In T352109#9457290, @thcipriani wrote:

In fact, we're adding a new branch called ARCHIVED and setting the HEAD of the repo to point to the new branch. Very reversible if we want to revert.

I'll not do this today—the Friday before a long (U.S.) weekend since there's some trepidation. But is this fine to do next week?

I think this is actually done \o/

To make use of the new mechanism implemented in the patch from the Product Platform team

I would expect the datavalue {"value":{"id":"E1"},"type":"wikibase-entityid"} to work, when property is set to the property ID of a property with data type EntitySchema. (For comparison, for item properties, {"value":{"id":"Q1"},"type":"wikibase-entityid"} works.)

In T62828#3174937, @hoo wrote:

In T62828#3174922, @Fomafix wrote:

I can restore the U+202F and it is not possible to remove or edit this value with the GUI.

Sure, so just don't restore it. Restoring old revision is (partly) bypassing validation, that is known and expected here (yet, probably doesn't happen in the real world).

(While change_object_id belongs to a WikibaseRepo table, it’s still part of the change dispatching system, so we expect that this whole task belongs with the Wikidata Integrations Team.)