Tagging with the same tags as T275319: Raise limit of $wgMaxArticleSize for Hebrew Wikisource. This will require approval from Performance-Team at least.

In T308879#7945368, @Xqt wrote:

This would be solved after deletion:
https://www.wikidata.org/wiki/Wikidata:Requests_for_deletions#Q112079466

In T305281#7933383, @Amire80 wrote:

In T305281#7932989, @Dcljr wrote:

Just FYI, the interlanguage prefix "kcg:" doesn't yet work (tested at the Meta-Wiki and the English Wikipedia). I can't remember which change enables this, but interlangs usually work by the time content importing is complete (at which point I announce the wiki creation at m:Wikimedia_News). I'm posting this in case something has been overlooked; if that's not the case, then just ignore this comment.

Actually, no, it takes a few... days until the interlanguage links begin to work properly. [...]

In T305280#7827935, @LSobanski wrote:

Thanks, let us know when the database is created, so we can sanitize it.

Wiki's up. Thanks for your patience.

In T171140#7912378, @Stang wrote:

@Urbanecm Thanks for point it out, so I wonder if this could be processed in a SWAT window and assistance from expert is required? If possible, please offer relevant support on it, thanks!

In that case, closing.

Sorry to keep this waiting for quite some time. I've scheduled the wiki creation for Monday May 16, 12:00 UTC.

Hello @Turkmen, I assume you're curious why this was not yet completed. This is because config patches follow a different workflow than MediaWiki patches. With MW patches, only submitting a patch for review is sufficient, but with config patches, they need to be also actively scheduled for deployment. Usually, this is done by their author. Sorry this felt through everyone's eyes -- it probably happened because the task is claimed.

Note that this will need someone experienced with Wikidata to work on this. Enabling Wikidata support is definitely not an easy task, and requires knowledge about the project's internals.

But file's live (and can be downloaded), so resolving. The thumbnailing infrastructure probably has issues with processing images of this size.

Downloading to the production cluster...

Fixed, but I had to run the script for all the wikis, rather than just the first one. Might be jobs not working at beta? Don¨t have the time/energy to investigate further ATM.

The usual procedure to establish identity of devaccount owner is via SSH keys (https://wikitech.wikimedia.org/wiki/Password_and_2FA_reset#For_users has details). Since your current dev account is fully unprivileged (no toolforge access, no ldap group membership, etc.), it might make more sense to create another one.

@LoganDark Dev account logandark does not have toolforge access as-of today, and does not appear to have any SSH public keys. That said, https://wikitech.wikimedia.org/wiki/User_talk:LoganDark strongly indicates the account used to have toolforge access (and your home directory exists too). That's weird, and almost looks like both SSH keys and the group membership suddenly disappeared for no apparent reason.

In T306878#7880198, @dom_walden wrote:

@tstarling Could it possibly be due to this change? https://gerrit.wikimedia.org/r/c/mediawiki/core/+/778684

Not 100% sure if this is introduced with wmf.9, but since editing is broken at beta ATM, promoting to a train blocker to err on the side of caution.

Thanks for the task (and ping). Indeed, this feature broke. Fixing patch uploaded, I'll try to deploy it later today.

In T303004#7847579, @SBisson wrote:

In T303004#7847530, @RhinosF1 wrote:

[...]
Are you able to complete next steps or do you need support?

We would need code review of the 2 config patches below. (Should they be combined into a single patch?) Then I can list it for a config deployment.

Done. Script was stopped in the middle, so output is split in half: P24464, P24465. Let me know if anything else's needed.

Hello @Zabe, I can help here. Can we pair on this sometime this week? It'd be helpful if you can be around the time the script is started, so you can a) confirm the changes are correct b) help me should the script throw/otherwise break. Feel free to PM me over IRC to coordinate :).

To me, this looks like a request for the wmf LDAP group (https://ldap.toolforge.org/group/wmf), which grants +2 on the repos WMF employees usually have +2 (including the one you need). That level of access would be requested via LDAP-Access-Requests.

After a long debug session at IRC, the rootcause of this issue was determined as cookie-based autoblocks. At one point, the tool receives a Set-Cookie for enwikiBlockID=XXX. Because IABot apparently uses a single cookie jar for MW cookies shared with all tool users, it then started to send the enwikiBlockID cookie to the server together with all user requests, which in turn means everyone was considered blocked.

In T303888#7808476, @Ladsgroup wrote:

I looked at the default templates (in modules/mailman3/files/templates) and couldn't find anything advertising subscription via email. Can you tell me exactly where and what is being said?

In T303888#7805113, @Ladsgroup wrote:

Yup, this is something we carried over from mailman2 given the history of abuse with mass subscription via email. Where is it being advertised?

In T303727#7805176, @Raymond wrote:

Update of the interwiki cache is necessary. Interwiki guw is not working, see https://de.wikipedia.org/wiki/Wikipedia:Projektneuheiten#23._M%C3%A4rz_2022

In T304529#7805220, @Ladsgroup wrote:

Suggestion: In order to make things work for the new wikis, run /usr/local/bin/mwscript extensions/WikimediaMaintenance/dumpInterwiki.php and commit the output to the php file manually for now and fix this before the next wiki creations.

In T304314#7805242, @Hooman_Mallahzadeh wrote:

@Urbanecm Under the same file name, I uploaded a new version of that picture that is modified on scale and is thus a square. I think this new version one is appropriate.

In T304314#7804973, @Hooman_Mallahzadeh wrote:

Following a discussion in https://web.libera.chat/?channel=#wikimedia-tech if anyone disagrees with this logo for Nowruz please write his objection here: https://commons.m.wikimedia.org/wiki/File:Persian_Wikipedia%27s_Featured_Nowruz_Logo_(2022)-3.svg

In T304314#7804459, @Huji wrote:

@Urbanecm given the above discussion and the reference made to https://meta.wikimedia.org/wiki/Logo#Temporary_logo_variants is there a reason you decided to go ahead with this request?

First, thank you @RhinosF1 for bringing this task to my attention. I do not think this needs to be declined, considering it has valid community consensus.

In T304529#7800549, @dancy wrote:

Noting for the record that scap update-interwiki-cache simply calls /usr/local/bin/mwscript extensions/WikimediaMaintenance/dumpInterwiki.php.

In T294995#7800322, @Jdlrobson wrote:

@Urbanecm that patch apparently didn't merge so isn't deployed.

In T294995#7798534, @Jdlrobson wrote:

We were still setting the skin preference inside onGetPreferences for backwards compatiblity. This has just been removed by https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/755813 after which this issue should be impossible.

The wiki's live.

The wiki's live now.

In T303761#7776629, @Marostegui wrote:

Whoever creates this wiki, let us know when it is done so it can be sanitized.

In T302798#7744418, @LSobanski wrote:

Thanks, let us know when the database is created, so we can sanitize it.

In T303376#7792402, @jbond wrote:

@OTichonova you are already part of the WMF ldap group which should give you access to all the services you are requesting. are you seeing an error?

Should now be fixed -- sorry for the inconvenience.

I don't see anything else either.

Creation of this wiki was scheduled for Wednesday March 23, 2022, 15:00 UTC.

Creation of this wiki was scheduled for Wednesday March 23, 2022, 15:00 UTC.

Rule deployed (active for the full day of May 15, 2022, UTC-4).

In T296085#7756986, @dom_walden wrote:

[...]
I believe that only bureaucrats can grant users this right. I was not able to grant it as any other type of user. Nor is it listed in an "Add group" in Special:ListGroupRights.

Boldly closing this as declined, as this is not actionable anymore. If there are any deployers on the team who are not in the gerrit group, I think a new task should be created.

Yeah, me too. Didn't expect it to be enforced in the extension code itself.