Sort-of related to this, we've now got on enwiki both 188.8.131.52 and 184.108.40.206/32 blocked. If you go to https://en.wikipedia.org/wiki/Special:Contributions/220.127.116.11, you get:
Wed, Sep 8
Mon, Sep 6
Aug 23 2021
Aug 20 2021
Aug 16 2021
Aug 11 2021
Aug 9 2021
Jul 15 2021
@Jdlrobson I'm sorry, I didn't realize this was waiting on me for a response. I'm not entirely sure what to tell you. My involvement here was mostly noticing somebody else describing the problem on Village Pump and doing some initial troubleshooting.
Jul 12 2021
@Cryptic showed me how to do this on my own:
Jul 4 2021
There's been three different threads on the enwiki Village Pump today talking about changes to search behavior.:
Jul 1 2021
If you could generate the URLs for the other size images, I'd be happy to give them a try from here.
Could you please clarify what software (e.g. Firefox, Chrome, some other tool) you're using to access pages/images that is returning 429s?
Jun 30 2021
Jun 28 2021
My only concern here is that showing thumbnails in a larger size might be valuable for vision-impaired users. At the other end of the spectrum, showing them in a smaller size might be valuable to people on exceptionally slow links and/or small screen sizes such as wearable devices.
Jun 27 2021
Firing wikipage.content may however cause new issues as well. As far as I know, currently wikipage.content is always fired with the one and only content block on the page (although the documentation doesn’t state this). If it’s fired with the preview, this expectation is broken and this may cause undefined behavior regarding the rest of the page (as scripts may consider it to be removed from the DOM tree).
Jun 17 2021
I'm not sure who's supposed to be prioritizing phab tickets, but I've taken the liberty of marking this as high priority. One look at https://www.mediawiki.org/wiki/Talk:Talk_pages_project/Replying shows the lack of ping functionality is the run-away top item of discussion.
Jun 15 2021
Jun 7 2021
May 28 2021
Just got one:
May 26 2021
May 25 2021
Yup, thanks for your help.
No, I've been well-behaved lately. But, I'll be happy to nail a tmux session up on one of the bastions for as long as it takes to generate an example if you like :-)
May 24 2021
May 21 2021
I'm assuming the attached screenshot from https://en.wikipedia.org/wiki/Wikipedia:Deletion_review/Log/2021_May_10#Category:CS1_maint:_discouraged_parameter is another example of the same issue.
May 16 2021
Got another one today:
May 15 2021
Apr 29 2021
Apr 20 2021
Thanks for the quick response. That looks like it covers most of the questions I had.
Apr 19 2021
I agree with @DED in their May 24, 2020 comment. I stumbled upon this while exploring the dumps. Their estimate of half the data being incorrect seems accurate. As such, I would suggest that this dump is worthless and should be eliminated. I can't imagine anybody making use of this in its current form. Producing it is a waste of machine resources, but worse than that, it's a time sink for people like me who are trying to understand the dumps.
Apr 15 2021
Oh, never mind. PEBKAC. I had a ssh config file on my end which auto-mapped my local username (roy) to roysmith on the bastion. Everything is working now, thanks.
$ ssh -i $HOME/.ssh/id_rsa_wikimedia dev-buster.toolforge.org
email@example.com: Permission denied (publickey,hostbased).
Apr 13 2021
For my personal need, either option would be fine. I can't speak for other users, but my gut feeling is nobody's going to miss 24. It really is ancient history.
Is the apostrophe being used on iOS the one from the keyboard?
Cool, thanks. I see the file systems mounted now. I'm told today was a WMF holiday, so extra thanks for taking care of this on your day off. Very much appreciated.
Apr 12 2021
Could I get an update on this? Thanks.
Apr 7 2021
Hmmm, ok, I see what's going on. I started typing 'meta" in the url bar, and that's what Chrome auto-completed. I didn't really stop to think about it, just hit return.
Apr 5 2021
As a current example of a query which needs a dedicated compute resource, see this thread on enwiki Village Pump:
Apr 3 2021
Mar 29 2021
From an editor point of view, it's very much not a bad idea. We have broken cite templates all over the place because the automated tool incorrectly generates "cite web". The only way to fix them now is to delete the reference and create a new one manually. An automated process, even if it's "fundamentally lossy" would be a big help, because deleting the existing one and starting over is also "fundamentally lossy".
Mar 22 2021
Mar 18 2021
Feb 25 2021
Just noting that there's a thread about this on enwiki. I agree with the sentiment there; this should be triaged as high priority.
Feb 13 2021
Feb 11 2021
I would be happy to ask my questions in a better place. Can you point me to where that place would be?
There's not much more info to provide. A user observed that mw-reverted tags were missing. There's a thread on enwiki's village pump, but there's not really anything there beyond what I mentioned above.
Jan 25 2021
Jan 11 2021
Jan 9 2021
Dec 18 2020
Yeah, I can repro that here. On the command line:
Dec 16 2020
I'm still getting it. I can reproduce on any of:
Dec 15 2020
Dec 10 2020
Nov 26 2020
Nov 13 2020
User:Davidwr reports on the VP:T thread that this diff hits the limit, and I can reproduce that myself:
Nov 12 2020
Nov 9 2020
Oct 2 2020
Sep 22 2020
Sep 13 2020
Sep 1 2020
Aug 26 2020
+1 to implementing this functionality.
Aug 21 2020
Aug 8 2020
Jul 18 2020
Jul 11 2020
Oh, my bad. I thought that was something developed by MWF.
Jul 3 2020
I'm not getting how this is supposed to work. I've reconfigured my django app to log to stderr. That output is ending up in $HOME/uwsgi.log. When I run "kubectl logs", all I get is the error message mentioned above, and no additional output, no matter how long I wait.
Jul 1 2020
Ah, thanks for the explanation. I just assumed it was kubectl failing to start up properly.
Jun 30 2020
As I pointed out above (and opened T256482 for), kubectl logs doesn't run.
Any update on this? Any kind of workaround to get real-time logging?
Jun 26 2020
Yup, I can confirm that "watch tail" is significantly faster than "tail -f".