Renders fine (with an error message) at https://test.wikidata.org/w/index.php?curid=959:

(Switching hats, sorry.)

(And as expected, it’s still trying to remove sh-latn.json in the next pull request.)

For the record, I just found another set of templates we want to update on most of the affected files (Cc-by(-sa)-layout should bypass the SDC_statement_exist template) and filed edit requests for them.

That’s great, thank you!

Currently, the number of links to Template:SDC statement has value (as counted by search – this lags somewhat behind the “real” number, as it depends on a further job, but it should be a decent approximation)

Per IRC discussion, marking as High priority. @AntiCompositeNumber reports that this results in category changes being slow to propagate (Category:Johann Baptist Hops not showing up in Category:Hops (surname) yet).

I request that the secrets not be removed in this case — the only sensitive secret is the Spur.us API key which is already expired per T380193

The export kept deleting the file through several re-exports; I’ve now manually restored it to unblock all the other translation updates for now.

Thanks for deploying!

(Placing the task back up for grabs because the rest is deployment and I have no idea how to do that.)

In T379340#10306370, @Aviator wrote:

Aviator here. The tool is indeed licensed under GPL. As for the binary, it was compiled from my own code that is written in C++ or Rust (I can't remember but I can dig my old files). I intended it to be in GPL as well. I just never released the source code.

Let me know if I should publish the code to ease the tool adoption process.

In T379452#10306396, @Stashbot wrote:

Mentioned in SAL (#wikimedia-cloud) [2024-11-09T12:38:43Z] <wmbot~lucaswerkmeister@tools-bastion-13> sed -i s/^web:/type:/ service.template # T379452

In T379452#10306395, @LucasWerkmeister wrote:

https://wikiloves.toolforge.org/ just shows me a 403, I don’t know if that’s correct or not.

kubectl describe pods showed

Last State:     Terminated
Reason:       OOMKilled

so I tried bumping the memory limit. (Bit annoying that the OOMKilled wasn’t shown in kubectl logs nor kubectl get events.) So far, the pod looks more stable:

tools.wikiloves@tools-bastion-13:~$ kubectl get pods
NAME                         READY   STATUS    RESTARTS        AGE
wikiloves-575bb94984-cp7sp   1/1     Running   1 (2m44s ago)   2m46s

https://wikiloves.toolforge.org/ just shows me a 403, I don’t know if that’s correct or not.

Reopening, as I’d respectfully ask you to reconsider installing mysqldump on the bastion directly. toolforge jobs does not support streaming the output, so to actually get an offsite backup I either have to put together an awful kubectl run command myself (I’m at least 15 minutes in and nowhere near anything usable yet – and even if I end up with something usable, I would be relying on a whole bunch of Toolforge internals, including how envvars map to k8s secrets) or use NFS (and we all love NFS). With mysqldump on the bastion, on the other hand, it’s very straightforward to stream the dump straight into another machine.

If you want to reimplement the tool (my very naive guess, without ever having seen the tool in action, is that it seems like a manageable task in principle – the existing source code I can see is some 200 lines of Python, 50 lines of CSS, and 120 lines of XML), I think we could still add you to the tool (after removing the old code), so that the rewrite can be reached under the same tool name. I can’t say whether this makes sense or not for this tool (whether a lot of users will want to continue using the same URLs, or whether it would be more confusing to users if a new implementation shows up there). Of course, you can also do a rewrite in a new tool.

In the meantime I’m holding off on merging that PR (unless you say I should merge it anyway).

Thanks! Do you know by any chance why that PR removes the sh-latn translations? (They still seem to exist on-wiki.)

The tool is currently offline, having been disabled as part of the grid engine deprecation about a year ago, so currently no external resources are being loaded there anymore. If @MichaelSchoenitzer plans to bring the tool back, it would be great to fix this; otherwise this task could also be closed, I think.

More to the point, plausible.io is an analytics service. While I commend the Humaniki team on not using Google Analytics, I’m still not sure we want this in Wikimedia Cloud VPS (though it’s hard to say for sure, because the Cloud Services Cross Site Policy, as linked from the Cloud Services Terms of use, is unfortunately still stuck in the draft stage). That is to say, I suspect the resolution for this task should not be “load the tracking JS from a wmcloud domain” but rather “do not load the tracking JS at all”.

Tool was apparently deleted / archived almost two years ago, nothing more to be done here:

lucaswerkmeister@tools-nfs-2:~$ ls -lh /srv/tools/archivedtools/activity.tgz 
-rw-r--r-- 1 root root 96K Jan 29  2023 /srv/tools/archivedtools/activity.tgz

In T378976: Lexeme-forms on Toolforge returns error, a webservice was dead for a few hours until I manually stopped and started it; might be related to this upgrade? (The startup probe continuously got connect: connection refused, apparently.)

Looks like that worked 🤷

The pod didn’t log anything else before it died, apparently:

No idea what’s wrong:

It’s happening again. https://gitlab.wikimedia.org/toolforge-repos/wd-image-positions/-/tree/twn?ref_type=heads currently has green CI, yet no merge request was created.

In T269232#6669181, @Lucas_Werkmeister_WMDE wrote:

@Lydia_Pintscher the hard-coded precisions have one value that doesn’t look like the others:

• (snip)
• 1/10000'

Should we make that last one translatable as well? Apparently it was added (in DataValues #99) because it can be auto-detected by the backend, but it’s not usually offered as a choice in the dropdown list. (The pull request description doesn’t say what input would make the backend detect that precision, and I haven’t found one yet, which makes this a bit more difficult to reason about.)

Yes, looks like it’s working again – thank you!

Yay, thank you!

That turned out to be a different problem (the “bad content format” pages at the bottom of https://quickcategories.toolforge.org/batch/7877/ used to make the whole background runner crash).

In my case, it turned out that I already signed the NDA but wasn’t added to the WMF-NDA project (see T375001); do you still want an email from me?

Alright, thanks – I’ve updated the translations on TWN now, so we should hopefully see some changes on Thursday.

That’s not how it worked in the past – https://gitlab.wikimedia.org/toolforge-repos/wd-image-positions/-/merge_requests/4 was initially created with CI errors according to the comments. And then I got a notification about the merge request, saw the CI errors, and fixed them. Without the merge request, that’s not going to happen, so if this is an intentional change, I’d like to revert it: a workflow where l10n-bot doesn’t create merge requests with failing CI doesn’t work for me at all.

The warning still appears, by the way – I guess someone™ still needs to deploy the new version? (I might technically have the required permissions but wouldn’t know how to do it…)

This is still happening, by the way, which means the Wikidata Image Positions translations are now over a month outdated :/

Oh wait, I totally forgot I signed an NDA for T314527 as well. (And indeed L3 tells me I’ve signed it.) That probably means this task is done?

Works for me now, thanks \o/

Still happening. I got redirected like this:

• https://quarry.wmcloud.org/login?next=/
• https://meta.wikimedia.org/w/index.php?title=Special%3AOAuth%2Fauthenticate&oauth_token=X&oauth_consumer_key=Y
• https://quarry.wmcloud.org/oauth-callback?oauth_verifier=Z&oauth_token=X
• http://quarry.wmcloud.org/

Though the error Firefox shows me is different:

For the record, I talked with @Dogu on Telegram about the specifics of the builder pattern, and some of the results we arrived at were:

Looks like it already restarted itself once:

Let’s close this for now, feel free to reopen if it comes back.

Do we have to be bound by Bash’s syntax limitations? . and - work just fine between env and Flask / Python, even if there is a Bash in between:

Alright, the background runner should now have a health check and hopefully restart itself if it gets stuck.

As mentioned in T370474#10098474, @Lucas_Werkmeister_WMDE has signed some kind of NDA already. I don’t know if that also covers me (same legal person, different social role) – I’m happy to sign anything if required, and will leave that decision to the Legal team.

I looked a bit through the Git history but didn’t find a lot more explanation for the pattern.

Something’s definitely running again:

If this sounds reasonable to the OAuth maintainers, I can try to implement it, but I would love to hear first whether people think it stands a chance of being merged or not ^^

Possible improvement to the error page: https://gerrit.wikimedia.org/r/c/operations/puppet/+/1071715

Well, apparently there were some random Wikimedia errors:

That read() seems to be happily blocking forever, by the way:

If we can’t figure out the underlying issue, I suppose I could:

I’m leaving the background runner in its current state for a bit in case someone else wants to take a look, but at some point I’ll restart it again to get the edits unstuck.

Note: I don’t know what the pipeline does and have no idea if pointing the script at the fork’s pipeline run would be enough. (E.g. maybe the original repo has some secrets that the pipeline run needs?)

I guess so :P since I already started looking into this after noticing the output (I’m guessing it’s due to the Kubernetes upgrade yesterday?)

(Kubernetes 1.31 apparently adds a --wait option again but who knows if it does the same thing.)

FWIW, according to the commit deprecating this and other flags, --wait had no effect (since at least 1.26, which is the version we’re running), so it should be safe to just remove. (I haven’t been able to find any old documentation that would tell us whether it used to do something or not, but if the --wait was ever needed for something then it probably already broke whenever an older k8s version made the flag have no effect.)

Feel free to reopen if you want to make the experimental highlighter plugin an optional dependency after all, but otherwise I think this is resolved.

Anyway, after installing the plugin, wbsearchentities works \o/