Marked as disabled on https://toolsadmin.wikimedia.org/tools/id/catmonitor

Marked as disabled on https://toolsadmin.wikimedia.org/tools/id/digitaltmuseum

Migrated in https://github.com/danmichaelo/arkivbot/commit/623cef07dcfeea8b6dda08df2e37a2811cb12201

This tool needs PHP and a few additional packages (djvulibre, imagemagick and ghostscript). I tried migrating it to Kubernetes in July 2022, but had to give up since the prebuilt images are too limited and there was no support for bringing your own. See chat at https://wm-bot.wmcloud.org/logs/%23wikimedia-cloud/20220721.txt and https://phabricator.wikimedia.org/T313550 . I haven't followed the latest developments closely, so let me know if there are new options available!

Note: I ended up moving back to the Grid Engine backend for now. Hope there will some solution for this before Grid Engine is deprecated though.

@Aklapper @Dylsss Sorry that I missed this, have been on a wikibreak and missed the notifications!

Indeed. The language name is correct in the desktop version:

Thanks, it is indeed working again now, so I'm closing this issue.

Today I ran into a new incompatibility:

WikibaseImport is no longer compatible with the latest wikibase/data-model, and pull requests to fix it (https://github.com/filbertkm/WikibaseImport/pull/45) are not processed, so it's becoming more pressing to get the repo moved. @Lydia_Pintscher , do you know if someone has reached out to Katie already to clarify license?

@Alicia_Fagerving_WMSE: The last response I got from Hilde was this one:

Sorry @Aklapper for not noticing your question! Also, the file I originally referred to turned out to be one from the TranslateWiki repo, so not related to this issue at all. I've updated the issue description now.

Thanks for reminding me about this, sent them an e-mail and asked about CC-0 use now.

This fix broke archiving at nowiki and sewiki, where I included the namespace in the bot call:

You mean that https://www.mediawiki.org/wiki/API:Edit should be updated to state that the client must either run JavaScript (which most bots cannot do) or speculatively try to time the editing frequencey in order not to accumulate too many cookies (which sounds quite crazy)?

Can confirm that it looks good now:

The uwsgi documentation is rather confusing, but I got it working without the --http-websockets flag, so I'm closing this issue for now. If anyone else is interesed, my uwsgi.ini is here: https://github.com/danmichaelo/UKBot/blob/master/uwsgi.ini

Note that CropTool was down for 20 hours today, causing 322 failed crop attempts, because an autoblock happened to include the Toolforge IP used by CropTool. Luckily, this doesn't happen often, I think the last time was in 2014, but as a maintainer it's frustrating when it happens.

Just for the sake of record, it was this issue: https://github.com/danmichaelo/croptool/issues/132 . Which is now fixed.

As pointed out by @Chicocvenancio, this was also mentioned in http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-cloud/20190322.txt :

[18:01:56] <bd.808>     pin.toch: we have a python3.5 Kuberentes container built, but it is not exposed for use yet. I expect to make it available in the first week of April

This also affects CropTool (hosted on Tool Labs), I'm getting reports about problems at https://github.com/danmichaelo/croptool/issues/123

Funny thing is that it works fine to remove aliases as long as you leave at least one alias left for the given language. But trying to remove all aliases for a given language will not work:

Users already familiar with the Random Article feature of Wikipedia will for sure get it. But new users? All of them? Not so sure.

No, I restarted it

And again: https://github.com/danmichaelo/croptool/issues/116

Happened again today, but doesn't seem to exactly the same issue: https://commons.wikimedia.org/wiki/Commons_talk:CropTool#Croptool_down_again

I've created T198503 to track this.

As the author of Croptool, I see that the tool hangs from time to time and I don't really understand why. If a user requests a very large image to be cropped, it will naturally cause high CPU usage for some time, but I would expect that the PHP process eventually would be killed / time out. Let me know if there are settings I should try changing!

Created an issue at https://github.com/danmichaelo/croptool/issues/111 . This seems to be an issue with older versions of ImageMagick, but I think I found a workaround.

Now it seems to work for the first file too.

It's there: https://github.com/danmichaelo/croptool/issues/95

Restarted the server yesterday, and again today.

@jeblad : You have already made your points very clear, but when a fix causes great harm it's always an option to revert it until a better fix has been found (one that can handle both the "nowikipedia" case and the "nowiktionary" case) or until a wiki renaming is possible.

Agree with @Orland and @Nsaa above: This is too dramatic a change to be made just on technical grounds.

Thanks for providing the replacement links!