last 30 days

It will be useful to have option to show pageviews graph for last year, at least.

Create, at least, a link to https://commons.wikimedia.org/wiki/File:Ruwiki%27s_editors_by_month_(2018-2023).gif on some visible place of a page.

OK, let's assume it was one-time random error.

Why not allow to use external data? External data could easy be safe, for example if it's in JSON (and mediawiki API returns pageviews data in json and XML, also MW API couldn't return destructive data at all).

Why this is needed for recreation of pageviews? Graph worked without this magic word.

Could someone say, what exactly the problem to recreate PageViews charts, that worked on Graph? They can't be implemented by datatables on Commons (because this data updates every day), but what's the problem to got data from the source where Graph got this data? Ruwiki has had pageviews graph for every page on "About this page" special page and on many talk pages, and all of these graphs was destroyed by disabling Graph and wasn't restored even now. What. Exactly. The. Problem?

I'm sorry, but what measurement unit is m?

@TheDJ As far as I remebmer, I tried to convert my video to webm (using the same ffmpeg 7.1.1) before I converted it to mpg, but convertation to webm was extremely slow - several frames per second. Because video was 120fps and has length 7 minutes, it will take weeks to convert all of it to webm. Maybe there are settings to more fast convertation, but I don't know them, I just say "convert 1.mp4 -o 1.webm". Convertation to mpg was really fast.

Yes.

I have several bots that have bot flag in many wikis, and still don't use bot passwords due to severe issue, about which I created phab ticket ~5 years ago. I checked "apihighlimits" when creating botpassword, but after logging in under this botpassword, maximum number of rows in API answers to this bot's requests lowered from 5000 to 500, like any non-bot user. My ticket was completely ignored by developers (it's hard to even find it now, because I created many tickets).

Yes, you found my error. After second try a file was uploaded successfully, but it still can't be played in browser due to "Совместимые источники для этого видео отсутствуют" error: https://commons.wikimedia.org/wiki/File:Bobrovy_Log_rodelbahn.mpg Looks like we need to wait to encoding processes to be completed, but one of them (144p) is completed and a problem persists. (Why not to allow to upload to Commons in original mp4 format? I need to re-encode file on my PC locally (mp4 -> mpg), and after that file still needs to be re-encoded on Commons). Also Commons says that video's length is 0,2 s (really - 7 min), and has bitrate 3 kb/s (obviously wrong value too).

Works now, but could it be fixed at all?

This happens again, with the same error message.

Fixed.

I also can't log out from another account (user:Железный капут) on another browser (Firefox, main browser is Chrome) due to "Invalid CSRF token"

@dcaro is it possible to run one-off job with a high limit? I tried to add --mem:12Gi into toolforge jobs run request, but in doesn't work.

Yes, looks like everything works now.

Another question: in last month many of my jobs disappeared from my processes (and wasn't successfully completed) without any output to .err files. Is it how process manager kills outlimited processes, or such killing will create a record in .err file?

I thought, limits works not like

you can run a job only when it's possible to allocate you 12 GB right now

but

you can run a job in any time, if your job will request only 2 GB in certain run, it will be successfully completed even if jobs.yaml requires 12 GB for this job, but when your job will ask to allocate 12 GB + 1 byte of RAM, it will be killed by process manager

I doesn't thought that situation "server can't allocate you 12 GB of RAM" is possible at all, I thought Toolforge is a server system with terabytes of RAM in common use.

it might become really hard for your jobs to find a worker to run on

I know almost nothing about k8s, so I didn't think such a problem was possible (i don't even know what "worker" is). What happens if my process doesn't find the worker it needs? It will not run, or it will try to run in next hours?

On mbh tool another one-time job can't be started with this rationale:

ERROR: An internal error occurred while executing this command.
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 468, in _make_request
    six.raise_from(e, None)
  File "<string>", line 3, in raise_from
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 463, in _make_request
    httplib_response = conn.getresponse()
                       ^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/http/client.py", line 1374, in getresponse
    response.begin()
  File "/usr/lib/python3.11/http/client.py", line 318, in begin
    version, status, reason = self._read_status()
                              ^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/http/client.py", line 279, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/socket.py", line 706, in readinto
    return self._sock.recv_into(b)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/ssl.py", line 1311, in recv_into
    return self.read(nbytes, buffer)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/ssl.py", line 1167, in read
    return self._sslobj.read(len, buffer)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TimeoutError: The read operation timed out

@dcaro Let's start from 8 or, better, 12 GB, if you could set 12. I don't want to cause you any unnecessary inconvenience and will try to stay within these limits.

We could close this, no problem.

Works now with an old keyfile. I'm not closing this task because maybe someone could explain what was this?

I assumed that problem may be in old key. I have generated a new RSA key using PuttyGEN and uploaded a public key to https://toolsadmin.wikimedia.org/profile/settings/ssh-keys/. I tried to log in using new key file and the problem persists.

Yesterday.

I also can't login from my phone, using TotalCommander with SFTP plugin, it worked correctly before.

OK.

Only ruwikipedia namespaces could be options in search in ruwikipedia, it's just technical restriction.

So, maybe you'll convert it too?

Thank you. at the moment we use utf8mb3 across all tables - it isn't true at least for all wikiproject DBs, as far as I know. For many years I'm reading all of it using CharacterSet=utf8mb4; in my connection string and it works. Several years ago one ruwiki user had a username containing 4 byte utf-8 characters (it was first time my DB-reading tools got incorrect DB answer), I requested an advice here and taavi advised me to use CharacterSet=utf8mb4; in my connection string, see T257103.

Thanks for advices. I tried to read correspondence table "lang - shard" from meta table, but got this error: Character set 'utf8mb3' is not supported by framework using by me. Could you convert this table to utf8mb4? @bd808 @fnegri

@Rjwilmsi This is still not fixed. How to reproduce:

1. Log in as "MBHbot" in ruwiki (I could send you password).
2. Try to edit pages [[ru:Шаблон:Флаг Беларуси]] or [[ru:Шаблон:Lang-be]] under AWB.

Screenshot of error I got now:

@Rjwilmsi I assume you doesn't understand the issue. A correct error message could be:

• "Text wio.ru is blocked by spam blacklist"

or

• "The text you wanted to publish is blocked by spam filter. This is probably caused by a link wio.ru"

But not a contamination of two these messages:

• Text "The text you wanted to publish is blocked by spam filter. This is probably caused by a link wio.ru" is blocked by spam blacklist.

Looks like fixed.

@Q-bit-array says he reproduced this in ruwiki, so I pinged him.

As far as I understand,

• an admin enters "Москва" into text field in the blocking interface. Block doesn't work.
• an admin enters "москва" into text field in the blocking interface. Block works.

Cyrillic. Capital-first-letter is enabled, I think, in all wikipedias (and definitely enabled in Russian).

After clicking on bell icon, I redirected to https://ru.wikipedia.org/wiki/Special:Notifications and have the same issue

@Bugreporter I'm using many userscripts, so

See T383308

@matmarex The IP that they are connecting from has a reduced limit for security reasons. - shouldn't this be explicitly stated on a contributions page of this IP? Where this could be discussed by all users (not in closed ticket), appealled and revoked? I think, this shouldn't be something we learn about on random phab ticket, this shadow bans should be more transparent for users in local communities.

T380257 looks like similar issue.

It may be related to my mass upload task to Commons: https://commons.wikimedia.org/wiki/Special:Contributions/MBHbot

I have uploaded this file successfully. If I got this error again, I'll add SRE-swift-storage project and ping you.

@Scott_French Bawolff mentioned you in the last ticket, what we can do to fix this problem?

Now files are waiting ~10 minutes before publishing and doesn't published due to errors "Unknown server error" and "Incorrect CSRF token". Uploading (first UploadWizard step) was very slow too with the same behavior than in previous case: 3 files in queue and all other files waiting, after several minutes this 3 files uploaded and next 3 files in queue.

@Bawolff The problem described in T378276 is rised again. I have recorded a HAR file, please, give me an e-mail where should I send it. I will not clear any cookies because I don't know how to do it, I'll just seng you a raw file.

The problematic file is a file between

Also: looks like queue moving speed is heavy depends on "is browser window opened on the area of screen that is about files being uploaded now". I mean: there is experimentally obtained way to get uploading faster, and this way is "browser window should be opened on UploadMaster page AND (because we're uploading 250 files) page should be scrolled to the area with 3 files having inscriptions "wait your queue" - not higher (where files already uploaded), not lower (where files not even in queue)". If you wait several minutes for queue, but UploadMaster tab was inactive (another tab was opened in browser), uploading doesn't occur, but it occurs immediately after you switches to the UploadMaster tab in browser (and after that you need to wait new several minutes for another 3 files). I think it's because browser freezes JS execution on inactive tab, but earlier there was no such problem. Browser is Chrome.

@Bawolff

Is this constant, or does it happen to only some files. How often does it happen

On some days this was constant (on any file, uploaded using UploadWizard, all time of day), on other days it's less visible or doesn't occur.

Some timestamps and example file uploads that were slow. (e.g. what's an example of a file that was slow, how long did it actually take, how long would it normally take)

See "1418 Steps" upload strike on 27-28 October in my contribs [https://commons.wikimedia.org/w/index.php?title=Special:ListFiles&offset=20241027170959%7CInterior_of_%221418_Steps_to_Victory_-_Memory_Path%22_museum_178.jpg&user=MBH&ilshowall=1], it occurs constantly all time of this strike. I made this upload in 5-7 pieces, every piece was very slow. See timestamps on pic - every several minutes (sometimes 3, but on this upload - 6-8) was uploaded 3 files.

What stage is the slowness at. Is it during upload or during publish? Does it happen only when uploading a large number of files?

It is during upload AND during publish. I select a bunch of files in folder on my PC (it can contain 150-250 files, and on this summer I have uploaded such bunches without any delays) - I move it to browser window with UploadMaster start step window opened using mouse - files being uploaded with rate "3 files in queue - after several minutes they are uploaded, next 3 files in queue" - after uploading all files I describe every file, set categories and WD mark - files published with the same rate "3 files in queue - after several minutes they are published, next 3 files in queue".

UploadWizard.

@Dzahn ruwiki's oversighters are @DR @Leloiandudu @Q-bit-array and maybe @Tatewaki (I'm not sure this is his account, but he has this username in wiki). You can appoint them as admins of the list.

A mailing list just redirects all mail, sent to it, to all of its subscribers? We think a mailing list is preferable.

@Bugreporter I want to create an email address like oversight-en-wp@wikipedia.org, see https://en.wikipedia.org/wiki/Wikipedia:Oversight , https://de.wikipedia.org/wiki/Wikipedia:Oversight/Kontakt , https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Masqueur_de_modifications (privacy-fr-wp@wikimedia.org), https://es.wikipedia.org/wiki/Wikipedia:Supresores (oversight-es@lists.wikimedia.org), https://it.wikipedia.org/wiki/Wikipedia:Soppressori/Richieste (soppressori-it-wp@wikimedia.org)

@Pikne Now it happens definitely without previous opening of an image on page https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D1%81%D0%BA%D0%BE%D0%B2%D1%81%D0%BA%D0%B8%D0%B9_%D0%B0%D1%8D%D1%80%D0%BE%D0%B2%D0%BE%D0%BA%D0%B7%D0%B0%D0%BB

As far as I remember, it occurs without opening another images, but maybe, I don't remember this well.

https://ru.wikipedia.org/wiki/Project:Форум/Общий#Включение_тёмной_темы_во_всех_пространствах_имён
There is a summary on ruwiki's village pump: local community supports this proposal.

Thanks. I already used string indexation in other tools, but not this tool, because it's very old code.

It's a web tool.

@dcaro My tool reads data from DB replica. Less than hour earlier tool was working correctly, but now it returns this error (in 100% of all tries): Unable to connect to any of the specified MySQL hosts. ---> System.ArgumentException: The host name or IP address is invalid.

Yes, problem is fixed, thanks.

When I'm trying to build an image from my github repo, I got this strange issue:

Yes, it's a bug with files itself, not with its transclusion into pages.

@Pppery what do you mean by "FlaggedRevs no longer tracks files"? Files are still reviewable, and reviewing of files is enabled in ruwiki, and this bug persists.