Ah, those 107 pages are redirects :) if you filter redirects from the results, there’s nothing left to be done (Quarry 1, Quarry 2).

Okay, the Python script finished, and now there are only 107 lexemes without the page props left (Quarry 1, Quarry 2). Not sure why those few are still missing the page props… should I run the script again and see if that helps?

Perhaps you could also switch the sshd config to AuthorizedKeysFile and rebuild that file from the AuthorizedKeysCommand via a cronjob or similar? That would also let you test if it’s really the AuthorizedKeysCommand problem, without requiring a package rebuild. (Of course, it’s not a good permanent solution, since key changes wouldn’t become effective until the next file rebuild.)

The PAWS terminal died for some reason (I guess you can’t leave them running in the background?), so now I’m doing it with a separate Python script from a Kubernetes deployment. Source code is on GitHub; I can’t push it to Phabricator yet due to T224677.

I’m now running this on PAWS:

I looked into this a bit – a regular purge doesn’t refresh the page props, but apparently a link-update purge does. This is available via the API – for example, I just fixed the page props for L31883 with action=purge&titles=Lexeme:L31883&forcelinkupdate=1. So I think anyone could actually do this task :)

Why is this task still open? This was implemented, wasn’t it? (I just noticed that I don’t have to add SELECT NOW() AS as of`;` to my queries anymore ☺)

Note that the majority of pages are still missing these page props (see T199611, esp. T199611#5244691), so right now we wouldn’t have any data to show for those.

According to this Quarry query, almost 70% of all lexeme pages still don’t have this page prop. Is there really no way to populate it without an edit? As a tool author, I can’t really rely on it like this…

Note that, for WikibaseLexeme entities, these numbers include the statements on senses and forms as well – i. e. they count all the statements/identifiers on the page, not just those of its “main entity”. Also see T224844 for a similar WikibaseLexeme task.

I’m not sure if it’s related to this task, but a while ago I wrote changeslist-notify.js, a user script to turn new changes on RecentChanges or Watchlist into desktop notifications. Perhaps it’s useful to some of the people subscribed here.

Seems to be working now \o/ see this patrol log for some examples.

See T194767: Set up OpenRefine on Cloud VPS.

I don’t remember seeing it in other repos – I think I just added the tag assuming that it wouldn’t be restricted to OAuth if it looked like a CirrusSearch failure. Sorry for the confusion.

Same here, thank you <3

Demo screencast: https://commons.wikimedia.org/wiki/File:Toolforge_dologmsg_QuickCategories_demo.webm

(For bonus points, we could include the $SUDO_USER in the message – though that’s not trusted information, of course.)

@bd808 nice, thanks! I used the following script to generate the above message:

(but perhaps the other regression was more significant, I wouldn’t know about that)

Oh no :( in my opinion the recheck convenience was totally worth this small regression!

Wait, I’m confused now – do we need an ircecho or a tcpircbot? modules/profile/manifests/icinga/ircbot.pp seems to be for the Icinga alerts, logmsgbot is in modules/profile/manifests/tcpircbot.pp as far as I can tell (with a separate Python script, modules/tcpircbot/files/tcpircbot.py, and getting its password from a different source as well, the passwords::logmsgbot class in private.git/modules/passwords/manifests/init.pp).