See my mediawiki.org userpage.
User Details
- User Since
- Sep 19 2014, 7:30 PM (495 w, 3 d)
- Roles
- Administrator
- Availability
- Available
- IRC Nick
- legoktm
- LDAP User
- Legoktm
- MediaWiki User
- Unknown
Sat, Mar 2
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.
Fri, Feb 23
The problem is actually mw.text.jsonDecode():
=mw.logObject(mw.text.jsonDecode('{"0": "zero", "00": "two zeroes"}')) table#1 { [0] = "zero", ["00"] = "two zeroes", }
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.
Thu, Feb 22
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
Wed, Feb 21
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
Feb 16 2024
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
tools.legobot@tools-sgebastion-10:~$ crontab -r tools.legobot@tools-sgebastion-10:~$ crontab -l no crontab for tools.legobot
tools.legobot@tools-sgebastion-10:~$ toolforge jobs list Job name: Job type: Status: ---------------- -------------------- -------------------------- afdrelists schedule: 3 * * * * Waiting for scheduled time hbcai schedule: 23 2 * * * Waiting for scheduled time mfd-rs schedule: 2 * * * * Waiting for scheduled time rfc schedule: 1 * * * * Waiting for scheduled time scotus-redirects schedule: @weekly Waiting for scheduled time
Feb 5 2024
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?
Feb 4 2024
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).
Feb 1 2024
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.
Jan 29 2024
Jan 23 2024
Jan 15 2024
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.
Jan 13 2024
Done!
Jan 10 2024
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?
Jan 9 2024
Are you looking for action=paraminfo?
Jan 8 2024
Jan 7 2024
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.
Jan 6 2024
Jan 5 2024
Jan 4 2024
Started poking at this today, there's some Python stuff and some Rust things. The Rust stuff is statically linked with musl, so it should be trivial to move to k8s. I'll try to start there first.
tools.afdstats@tools-sgebastion-10:~$ webservice status Your webservice of type php7.4 is running on backend kubernetes
Thanks @Ahecht! We've moved the Git repository to https://gitlab.wikimedia.org/toolforge-repos/afdstats/ - I'm going to port over your pull request and get it deployed.
Manually fixed a few issues and sent out today's mail, will see that it works tomorrow before closing it.
Here are the issues I see so far:
- rust-toolchain has a different format now, as a TOML file (and often called rust-toolchain.toml too)
- No way to set a different target, i.e. to compile with musl
- Installs full Rust toolchain, which is unnecessary, instead of just the limited toolchain that contains cargo + rustc
- Copying the binary to a different location won't work if the tool needs templates or CSS/JS that isn't embedded in the binary
- Hardcoding things for diesel seems inappropriate too and also unnecessary
Jan 3 2024
I didn't realize the view only surfaces linktarget rows if there's a corresponding *links row, that feels weird to me but makes sense. I'm not sure why it's fluctuating either, but I think we can partially/mostly chalk this up to a busted/nonsensical query, which I've now fixed to not do that.
On a few production setups I've used these branches so I'm in favor of not removing them. I also don't see what we gain by deleting them, given...
Sorry for the late response. What @Peachey88 linked to is basically still up to date on the lack of API access inside the prod network. I would suggest that said onboarding tool publishes a list of stewards/email addresses somewhere, and then a script that runs on the lists100X server can fetch said list and make the necessary changes.
Thanks!!! I skimmed through https://gitlab.wikimedia.org/repos/cloud/toolforge/rust-buildpack/-/blob/move_to_api_0.10/target/bin/compile?ref_type=heads and had a few suggestions on things to fix. I'll file some bugs in the next few days when I have time to play with this.
I've commented out the crontab and:
I think we're probably ready to go on this. I flipped the list configuration to allow HTML mails to go through untouched (i.e. not converted to plaintext). FYI @Platonides that I'm changing the script to send over SMTP, run using toolforge-jobs and send HTML email. :)
Jan 2 2024
Dec 31 2023
Note that the main reason for this is that the Translate extension creates pages of the form Translations:Full_Title/ID/lang, and Full_Title would be the fully formatted title of the page being translated, using the namespace name instead of its ID
Dec 29 2023
Thanks! It's deploying right now. I audited the rest of the .unwrap()s, I see one other potential issue, which is a group that has no members. While unlikely, I'll add a fix for that.
Dec 28 2023
I assume there is also an ldap/wmf group, but I can't find any hint of it in gerrit.
Dec 27 2023
Dec 26 2023
Dec 25 2023
Dec 24 2023
Dec 22 2023
Dec 21 2023
Thanks for filing this, it's definitely something I want to work on soon. I looked around for Rust i18n libraries like 3-4 months ago and was pretty disappointed by what I saw, so we might need to write one ourselves.