Awesome! I just switched over my bot and in my limited testing it works the same. I'll look into updating documentation tomorrow.

In T334238#10112457, @MSantos wrote:

I agree with you, it hasn't been properly communicated yet and that's why a formal communication with guidelines for migration hasn't been published, that's my fault and I apologize for the lack of movement here.

What's the replacement API module for this? Is there documentation?

There's now T373716: Reroute RESTbase Parsoid endpoints to core's REST endpoints, which is another attempt at solving this problem and hints that the progress of having callers move isn't meeting the necessary timeframes. I'll echo what @Chlod said and that IMO the biggest issue has been a lack of communication to clients/library authors on what we should be doing, as well as a lack of replies to questions, e.g. T354037.

In T367625#9965960, @daniel wrote:

Right... But that's not what the code actually does. I I'll try to come up with a better explanation to put into the docs.

In T370203#10095575, @BTullis wrote:

In T370203#10092682, @Legoktm wrote:

...I'm genuinely shocked that it's doing so for the purpose of better tracking of users.

I would just like to add a small note here, for the purposes of clarity in how Matomo is used at the Foundation.
This plugin does not change the user tracking behaviour of Matomo at all. It just enables creating reports based on filtering our existing data by different parameters.

Yeah, that's reasonable, I think those 3 platforms will cover like 99% of issues. I think if we could run the more obscure platforms on a tag push instead of every commit, that would be ideal. We could also drop MSRV testing for said obscure platforms and not really lose anything.

In T370203#10074258, @odimitrijevic wrote:

Hi @elukey , @joanna_borun, the reason the plugin was chosen is because there are no other equivalent open source options. The plugin underwent an internal security review and signoff as part of the provisioning process which should provide sufficient assurances wrt to the security concerns above.

There was just one attempt? I think this is still a relatively straightforward task.

@WDoranWMF the linked "initial decision brief covering licensing issues" doc is private - can it be made public?

This was reverted as part of T371376: Linter related error on PCS tests: Cannot use object of type stdClass as array, the Linter extension was expecting it to be an array so need to rethink how to implement this.

In T370624#10027452, @Ladsgroup wrote:

Yeah, grep for partitioned_jobs_config in helm deployment charts.

Sorry, my bad. I've proposed a revert and I can redo it properly when I have a bit more time.

Should this be done in the job queue? Or is there something we can do inside RecordLintJob? Is there an example of other jobs that are sharded by section?

I'm not sure what the best solution is here. The number is wrong and is probably going to be wrong going forwards. We can remove/hide it along the lines of T209899#6656593, but removing it is also an API breaking change and this seems a little trivial to trigger that.

It is useful to see which entries on this list are automated by bots and user scripts, and which entries are done manually.

At least for me, trying to kick off 64 processes all at once just causes my development VM to lock up. Is it possible to automatically determine and scale the value based on the number of CPUs/threads available?

Related to / duplicate of T330725: Merge Linter extension into MediaWiki core?

The problem I ran into with a LintError class is that you'd expect it to look something like (abbreviated):

php

I started writing this (congrats on the successful nerd snipe), but I think we might get just as much value by just changing the signature of recordLint to take in the various elements and does the construction of the lint error internally. I'll upload a patch for consideration shortly.

@Jdforrester-WMF flagged that this is very widely used in production (c.f. https://codesearch.wmcloud.org/search/?q=tideways&files=&excludeFiles=&repos=).

tidways_xhprof was removed in Debian today so I noticed this as well and submitted a patch. I don't know how actively people are using tideways_xhprof, and whether it's premature to remove support if it still works on e.g. Debian stable.

(This isn't under the control of the Docker-Hub-MediaWiki maintainers, sorry!)

Unless it's too slow performance wise, I do think using Shellbox is the easiest path to production in that it's already compliant with the SRE requirements and integrated into MediaWiki. And I think it would be relatively straightforward to switch to a proper service later on if needed.

https://gitlab.wikimedia.org/repos/mwbot-rs/delinter/-/commit/17305d6a6a584c26d3d114c257a8613789750b7f is the workaround I've applied for now.

However, the Chart extension's use case would involve shelling out to a Node.js script, which would need to install dependencies from NPM (we could keep the set of dependencies pretty limited, we probably just need echarts and commander). We're not aware of any existing Node.js-based use cases for Shellbox, so we thought we would raise this issue early.

I just want to flag that this is an issue on talk pages, and maybe should be in Parsoid-Read-Views Phase 1 for DiscussionTools because it causes links to break.

Given multiple configuration sources, ImageMagick always uses the lowest specified limit. So setting a higher limit by adding a configuration file, setting an environment variable, or calling the relevant API has no effect.

Merged both MRs and switched the checkouts in the tool over to GitLab.

Yeah, let's do it, and the source code too.

Feel free to remove the CI jobs, I'll take care of moving the two repos to GitLab soon enough.

Fixed in https://gitlab.wikimedia.org/toolforge-repos/logo-test/-/commit/210df3f7cff6173b1d2e22505a4a044bec8defc3 (sorry I didn't see this task until just now).

So far I've integrated this into https://streaks.toolforge.org/ and wrote a blog post: https://blog.legoktm.com/2024/07/12/making-it-easier-for-toolforge-tools-to-surface-replag.html

Just to clarify, despite being disclosed and announced today, Gadgets is a bundled extension, so the fix was released as part of MediaWiki 1.39.8 / 1.40.4 / 1.41.2 / 1.42.1.

In T363314#9945859, @Legoktm wrote:

We could also download the rasterized PNG version via the thumbnails 🤔

We could also download the rasterized PNG version via the thumbnails 🤔

Yeah, https://github.com/mastodon/mastodon/issues/6569 is the upstream ticket about not supporting SVG. We can handle this better in the tool though to display a better error.

I finally got around to doing this after the high s1 replag earlier this week. Unfortunately the problem with iframes is that they don't dynamically size based on the contents (as far as I know - would love to be wrong!). So when there's no lag (the majority of the time), you have to have empty space where the banner would go.

In T367988#9910314, @thiemowmde wrote:

I know this is probably to much to ask for. But personally I'm not a fan of such inverted "say yes when you meant to say no" checkboxes. I find these unnecessarily confusing. It's almost a dark pattern in some situations. Do you think we can do something about this?

In T365298#9886304, @Tgr wrote:

The user will see something like https://sso.wikimedia.org/en.wikipedia.org/wiki/Special:Userlogin which is potentially confusing or suspicious ("wikimedia.org" has limited brand recognition compared to "wikipedia.org", technically sophisticated users will maybe think the presence of en.wikipedia.org (used to identify from which wiki the user started the login process) is a phishing trick).

https://github.com/42wim/matterbridge/issues/2033 is the upstream bug report.

Thank you!

According to https://docs.gitlab.com/ee/user/markdown.html#gitlab-specific-references, using double bracket syntax in a markdown file is supposed to link to a wiki page in that repository's GitLab wiki. However since we have wikis disabled, I suspect some "security" feature is attempting to hide the title since we don't have permissions to see the wiki (again, since it's disabled). I think the best/reasonable thing to do is either escape the double bracket syntax, e.g. [[User:Foo]] or just use a proper markdown link, e.g. [User:Foo](https://meta.wikimedia.org/wiki/User:Foo).

RESTBase is going away so this isn't needed anymore.

In T363190#9752982, @Xqt wrote:

https://test.wikipedia.org/wiki/Wikipedia:Requests/Permissions/Pywikibot-test

In T366767#9868576, @bd808 wrote:

Per https://github.com/42wim/matterbridge/wiki/Section-Matrix-%28basic%29#example-with-pantalaimon it looks like we will also need to add https://github.com/matrix-org/pantalaimon to the Bridgebot stack to implement this.

CI is green so I think this is resolved (re-open if not) :)

@taavi you should have an invite for owner permissions on the wikimedia_ciutils pypi project.

In T361426#9674806, @bd808 wrote:

The bot seems to be actively editing (https://en.wikipedia.org/wiki/Special:Contributions/Yapperbot) which means the tool is not obviously meeting the "The tool must have been nonfunctional (no webservice/offline) for 14 days." qualification criteria.

https://github.com/wikimedia/mediawiki-docker/pull/140

Great, glad you were able to figure it out!

Thanks both for working on this!!

+1 from me.

In T360584#9647966, @Frostly wrote:

Maybe consider https://www.dragonflydb.io/replace-redis

Great! You both should have invites to join the mwbot-rs organization

I've taken this opportunity to write up some documentation at https://www.mediawiki.org/wiki/Mwbot-rs/Releasing and created a mwbot-rs org/team on github to hold the ACL for all the crates so new owners can be added in one place.

The problem is actually mw.text.jsonDecode():

=mw.logObject(mw.text.jsonDecode('{"0": "zero", "00": "two zeroes"}'))
table#1 {
    [0] = "zero",
    ["00"] = "two zeroes",
}

In T357949#9566576, @Joe wrote:

I don't see a good solution for than other than maintaining separate branches and backporting changes to the main branch to a wmf branch, which would come with its own inconveniences of course.

Not easily, the same Pending status as reported by kube-state-metrics seems to also include things pods where the image configured does not exist and other user errors.