In T352792#9383947, @taavi wrote:

taavi@tools-sgebastion-11:~ $ kubectl sudo delete cm -n tool-steinsplitter maintain-kubeusers
configmap "maintain-kubeusers" deleted

starting a run
Homedir already exists for /data/project/steinsplitter
Wrote config in /data/project/steinsplitter/.kube/config
PodSecurityPolicy tool-steinsplitter-psp already exists
Namespace tool-steinsplitter already exists
Role tool-steinsplitter-psp already exists
Provisioned creds for user steinsplitter
finished run, wrote 1 new accounts, disabled 0 accounts, cleaned up 0 accounts, renewed 0 accounts, updated 0 quotas

This has now been fixed. Migration done.

In T265568#6548353, @Legoktm wrote:

In T265568#6546816, @Steinsplitter wrote:

@Legoktm If you provide a e-mail address to me, then i can grant you access to the mailman interface.

[email protected] please

In T265568#6547888, @Dzahn wrote:

ah, no it's antispam indeed:

F=<[email protected]> rejected after DATA: This message scored 6.1 spam points.

see https://wikitech.wikimedia.org/wiki/Mailman#Spam_scores

Oof. I suppose we can disable that anti-spam setting because the tools.potd@ email should be the only one allowed to send mails to the list.

In T265568#6546814, @Steinsplitter wrote:

@Steinsplitter did you change anything on the mailman side?

Nope.

In T122220#6471256, @Krd wrote:

Please consider that OTRS admins may not have enough resources for assistance at the moment.

In T240182#5825579, @Masumrezarock100 wrote:

Just to note, @Natuur12 and @Steinsplitter are Commons admins, they likely use this channel to track vandals, LTAs etc. RxyBotLT is a bot operated by @Rxy, a Wikimedia steward. I assume he uses this channel to track and lock a LTA called ISECHIKA. No idea who is the operator of BanBot but it apparently posts (non)abusive and (non)trollish usernames to #wikimedia-stewards channel.

In T219569#5079252, @Gilles wrote:

It's an error coming from vips, about an ICC profile this file contains:

CommandError: (['/usr/bin/vips', 'shrink', '/srv/thumbor/tmp/thumbor@8818/tmpE_GnDj', '/srv/thumbor/tmp/thumbor@8818/tmpQUoG4w/vips_result.png', '20', '20'], '', 'vipspng: profile \'icc\': 0h: PCS illuminant is not D50\nvips2png: unable to write "/srv/thumbor/tmp/thumbor@8818/tmpQUoG4w/vips_result.png"\n', 1)

This seems relevant: https://github.com/libvips/libvips/issues/1248

It does sound like the image could be tweaked (eg. convert to a different ICC profile) to avoid this, though.

In T232992#5632739, @Superbass wrote:

I would like to add that we now regularly receive complaints in OTRS about this manipulation. It's a bit embarrassing that nothing has changed effectively so far.

In T228526#5411494, @Daimona wrote:

In T228526#5406810, @Daimona wrote:

I cannot reproduce the problem locally. Could you please test once again on commons?

I did it by myself. I tried to restore Alexis Reggae's version (which previously didn't match the filter) and I got warned. So this is now working as expected.

As a side note, the warning display is broken, see below:

The warning message should probably be fixed.

In T228073#5333799, @Urbanecm wrote:

@Steinsplitter This task isn't about _deleting_ this group from our wikis. This is just about removing the group from extension.json (=stuff defined there is applied on all wikis that make use of UploadWizard, unless they override it in LocalSettings.php), in favour of redefining this in Wikimedia wikis configuration. The redefining has been already done for commons btw, since the group is now called image-reviewer internally, while it was Image-reviewer previously. There will be no change for Commons, and filter 70 will work just as it works now.

(accidentally deleted)

In T226672#5293283, @Jdforrester-WMF wrote:

Emergency-deployed and seems to now be working.

@WMDE-leszek There is now a backlog of +500 files, growing and multiple onwiki complains. This task is assigned to nobody, is actually someone at WMDE working on this? Thank you! :)

The current backlog of open file move requests can be seen here: https://commons.wikimedia.org/wiki/Category:Media_requiring_renaming (374 open requests), and it is growing.

The gadget has currently no maintainer and is very old. :( Maybe something is deprecated or some kind of caching issue.

Aklapper changed the task status from Stalled to Open.

In T226297#5275652, @Marostegui wrote:

It is because labsdb1010 is serving (temporarily while we do some maintenance on 1011) analytics but still has the query killer set to 300 seconds instead of 14400 (14400 is the one we use for the long query hosts). I have changed it and it is now set to 14400 so it should not be killing those small queries anymore.

I temporary disabled the banner, there are some fixes needed. See what DerHexer wrote in this request: https://meta.wikimedia.org/wiki/CentralNotice/Request/Technical_Wishes_survey_2019_on_dewiki Thank You :)

I can confirm this bug. Exactly the same thing happened to a few weeks ago. Seems to be a issue with the javascipt "pop-up" confirm dialog.

In T190988#5180524, @Krinkle wrote:

Over 6,000 files have been permanently damaged, lost without recovery, and without the user's being informed about this or aware during the upload.

In T223106#5178195, @Multichill wrote:

Line refers to https://github.com/addwiki/mediawiki-api-base/blob/master/src/MediawikiApi.php#L376 I think. Without a stack trace this is a bit hard to debug. Might be related to https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2019-April/000145.html

I mad the necessary changes today, confirming it works. :-)

In T89131#4804968, @AlexisJazz wrote:

@kaldari @Steinsplitter

@Slowking4 is not actually in the extended uploaders group. I suspect he has the "Share images from Flickr" button because he is in the "GWToolset users" group.

In T89131#4804758, @kaldari wrote:

@Steinsplitter - I fixed the AbuseFilter filter. You forgot to exempt the extended-uploader user group when you added the {{FlickrVerifiedByUploadWizard.*}} template. To be added to the extended-uploader user group, you have to be vetted for knowledge of the licensing policies, and be trusted to import files from Flickr that aren't Flickrwashed, so those users are trusted should be exempted from the AbuseFilter.

First of all: Thanks for reporting the issue and sorry for the late reply - i am actually busy with other stuff!

In T204017#4586627, @MarcoAurelio wrote:

Well, code-style fixing and deprecated functions removal is important as well I'd say. If the only issue is with duplication, I'd say we can have a look at it. However I cannot test this on my own because I suspect that, for the bot to work we need some other config files that ain't in the public repo, right?

In T204017#4585891, @MarcoAurelio wrote:

@revi Mind pinging @Steinsplitter also on IRC and point him to this task so he can try and test? Thanks.

In T202829#4533116, @Reedy wrote:

Run in prod

MariaDB [centralauth]> select gu_home_db from globaluser WHERE gu_name ="Amitaharon10" limit 1;
+------------+
| gu_home_db |
+------------+
| NULL       |
+------------+
1 row in set (0.00 sec)

It's the same. The green + isn't the "home wiki"

Maybe CN should ony work for CN- & Meta-Admins if 2FA is enabled.

@eranroz Okay, will setup later. My bot is not approved there, was just temporary when sorting out stuff a while ago. Is that a problem?

In T190233#4511904, @eranroz wrote:

@Steinsplitter, would it be possible that your bot will output the report also to hewiki in addition to commons, or would it fit better to Commons Deletion bot?

@Legoktm Yepp :) Sorry for the late reply.

The banner is not loading content from enwiki, so this is likely not related. I cannot reproduce the issue in FF (no content loaded from en.wiki). Maybe it is caused by a user script but not related to the banner in question.

In T194505#4318262, @Lea_WMDE wrote:

Hi @Steinsplitter we are using these files for the replacement, and they can be edited for any changes you want to make.
For now, we are not including regex, since this has higher risks of exploitation, and deep diving into this topic is something we keep for future versions :)

There should probably be a onwiki regex replace list in the MediaWiki namespace which can be edited by admins, in order to allow easy maintenance of the replacement stuff.

In T138284#2494482, @Bawolff wrote:

centralnotice-summary needs to be added to $wgForceUIMsgAsContentMsg on meta (Or changed to be not a content message in general depending on which is more appropriate).

The bot is no longer operating because:
https://commons.wikimedia.org/wiki/User:CategorizationBot#Why_isn't_the_bot_running?

There is https://commons.wikimedia.org/wiki/User:CategorizationBot but it is inactive for long time :(

Related to https://github.com/wikimedia/mediawiki/commit/ddfb4817b59ec10fa928c4059066f2ef39110ad5#diff-7103a37b72435c9b3e8cebe2eccfba7f @matthiasmullie ?

In T122220#3988921, @Scoopfinder wrote:

@Josve05a : I did as mentioned, but still can login without 2FA or with a random 2FA. Did you try to check this too? (maybe I am the one doing sth wrong)

In T653#3941576, @Tgr wrote:

The mainpage designs created for the old RfC (in 2012!) are pretty nice, what would it take to actually start using them?

In T183848#3865590, @Umherirrender wrote:

Summary messages of special pages are always shown in content language.

If Wikimedia Commons want the user language shown, the $wgForceUIMsgAsContentMsg setting for wikimedia commons must be set. Than this task is a Site Request.

Current config shown under https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php - Search for wgForceUIMsgAsContentMsg

See also T177306