User Details
- User Since
- Oct 26 2015, 4:00 PM (343 w, 1 d)
- Availability
- Available
- IRC Nick
- Urbanecm
- LDAP User
- Urbanecm
- MediaWiki User
- Martin Urbanec [ Global Accounts ]
Yesterday
Sat, May 21
Tagging with the same tags as T275319: Raise limit of $wgMaxArticleSize for Hebrew Wikisource. This will require approval from Performance-Team at least.
Wed, May 18
Tue, May 17
Mon, May 16
Wiki's up. Thanks for your patience.
Sat, May 14
In that case, closing.
Thu, May 12
Sorry to keep this waiting for quite some time. I've scheduled the wiki creation for Monday May 16, 12:00 UTC.
Wed, May 11
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.
Sun, May 8
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.
Sat, May 7
Wed, May 4
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.
Fri, Apr 29
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.
Tue, Apr 26
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.
Apr 22 2022
Apr 21 2022
Apr 20 2022
Thanks for the task (and ping). Indeed, this feature broke. Fixing patch uploaded, I'll try to deploy it later today.
Apr 18 2022
Apr 12 2022
Apr 11 2022
Apr 10 2022
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 :).
Apr 7 2022
Apr 5 2022
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.
Mar 30 2022
Mar 29 2022
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.
Mar 28 2022
Mar 26 2022
Mar 25 2022
Mar 24 2022
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.
Mar 23 2022
The wiki's live.
The wiki's live now.
Mar 21 2022
Mar 19 2022
Should now be fixed -- sorry for the inconvenience.
Mar 17 2022
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).
Mar 15 2022
Mar 11 2022
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.