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.

queue runner seems to have crashed, based on https://grafana.wikimedia.org/d/GvuAmuuGk/mailman3?orgId=1&viewPanel=2&from=now-2d&to=now

All sounds good to me, agreed that there are better ways to do automatic deploys without doing git pulls and all the internal detection logic. I am not sure whether this is in your scope or not, but from what I recall with your usage of ZNC to front other IRC bots, that would be nice to have for wikibugs too.

Seems like it fixed itself after I went to sleep. I'm going to call this resolved, we're working on a plan to have someone properly take this over, see https://en.wikipedia.org/wiki/User_talk:Yapperbot#c-David_Tornheim-20240221203800-Legoktm-20240221190500

Hmm, something is wrong:

2024/02/21 06:30:40 Error editing user talk for Compassionate727 meant they couldn't be notified and were ignored. The error was badtoken: Invalid CSRF token.

Luckily these are all statically linked golang binaries, so moving them to the grid is straightforward:

tools.yapperbot@tools-sgebastion-10:~$ cat crontab.grid_stopped 
# m	h	dom	mon	dow	command
30      *	*	*	*	cd frs && jsub -mem 950m -once -cwd ./frs >/dev/null
0	18	*	*	1	cd pruner && jsub -mem 950m -cwd ./pruner
0	*	*	*	*	cd uncurrenter && jsub -mem 950m -once -cwd ./uncurrenter >/dev/null
0	*/12	*	*	*	cd wikidatable && jsub -mem 2g -cwd ./wikidatable >/dev/null
*/5	*	*	*	*	cd scantag && jsub -mem 950m -once -cwd ./scantag --sandbox >/dev/null

Ok, he said:

I moved over the Rust-looking jobs just now:

enterpriseybot-afc-backlog-graphs   schedule: 0 */12 * * *   Waiting for scheduled time
enterpriseybot-cat-track            schedule: 0 13 1,15 * *  Waiting for scheduled time
enterpriseybot-defcon-rs            schedule: 10 * * * *     Waiting for scheduled time
enterpriseybot-redirect-banners-rs  schedule: 5 */6 * * *    Waiting for scheduled time

Wanted to process T356586 but it's stuck again :(

Not sure what the issue was, but after noticing that nothing was being written to error.log, I tried webservice stop && webservice start and that fixed it. Maybe lighttpd died or something?

Can we just Puppetize the entire thing?

It should be fine to delete old logs, just use the sqlalchemy functions to delete them to make sure any foreign references are updated as appropriate.

I guess I didn't fully realize the implications of the MSRV policy when you brought it up, I think stable minus two is much simpler to manage. Or maybe we just adopt set the MSRV required by our dependencies (the status quo).

LibUp was turned off because there was some bug (which I don't remember but probably has a ticket somewhere) and because I was adding GitLab support (there's a branch on GitLab) and I thought I'd have it back running in a few days, which obviously didn't happen. So my apologies for not communicating that properly and then not being a responsible maintainer and adding backups and well, getting it back running. I've rectified the maintainer issue by giving @Ladsgroup, @Jdforrester-WMF and @Reedy access (you all are welcome to add others as well). The only thing I haven't shared is the Gerrit password + SSH passphrase, happy to do that over some secure channel (e.g. Signal) or y'all have access to the email address via Toolforge and can trigger a reset and add a new SSH key.

Unfortunately @Bearcat, if the tool maintainers aren't active, there's no one who is really going to respond to this Phabricator task either. You may be better off finding someone to re-implement the functionality (possibly via a forum like WP:VPT or Technical-Tool-Request), or find someone, possibly yourself(?), to adopt the tool. HTH.

Why are we not installing all the locales by default? Given that internationalization and language support are first-class priorities of the Wikimedia movement, I think it should be something supported out of the box. Asking every tool to maintain a list like this one seems like a huge waste and step backwards in making internationalized tools.

Done!

Thank you!

I think we should just remove the Rust images/jobs from Jenkins, I think I was the only one using them and I've moved all my Rust stuff over to GitLab and published https://gitlab.wikimedia.org/repos/mwbot-rs/rust-ci-pipeline for those.

I think so, there's still an issue that a job was skipped one day, but we can track that at T338006#9448777.

So I've seen what I suspect is the same issue, the potd tool's "send" job was never triggered on 2024-01-06 at 2:00; and the tfaprotbot tool's "tfasemibot" job was never triggered on 2023-12-28 at 23:00. If the problem is running on the hour, how much should I offset by? Is it likely to into issues if I have it run at, e.g. 22:59? I note that T338134: Use a higher `startingDeadlineSeconds` for less frequent jobs is still open - is that worth pursuing still? Should there be a subtask about non-scheduled jobs not sending any notifications as well?

Are you looking for action=paraminfo?

mwbot 0.6.1 has been released.

OK, stumbled upon my own need for this :) pushed https://gitlab.wikimedia.org/repos/mwbot-rs/mwbot/-/commit/d787e8631610e2a30d0089cc5eaea8c4d6cbda9a, will do a release shortly.