User Details
- User Since
- Sep 17 2017, 8:24 AM (371 w, 4 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Incnis Mrsi [ Global Accounts ]
Aug 2 2021
Oct 13 2019
And this, of course, is not a duplicate of T59264.
Oct 12 2019
“paragraphs, categories, templates…” – no way, Ī̲ don’t propose to fit MediaWiki with AI. Only several checks based on a dumb (sub)section tree-like model of the page.
Sep 7 2019
How certain is that the attack—if it was noticeable at all—was the root cause of the esams outage? My analysis of Grafana plots and personal experience led to following conclusions:
Aug 5 2019
Aug 3 2019
It is pointless to discuss these Phase IVIVIVI in detail before consensus on how namely may IPs be encrypted, and whether they should be at all. If the address encryption is expected to pulverize each /64 IPv6 block—leaving the end user without an option to see all edits from the same 2hhh:hhhh:hhhh:hhhh: (with possible differences in the lowest 64 bits)—then the proposal should be dismissed and a homework of learning actual IP-editing practices has to be assigned to the author.
Jul 29 2019
May 15 2019
Thanks for a prompt reply, but the way PdfHandler treats this error is disrespectful. Can a sensible error message be generated, please?
May 7 2019
Second this – noted the sudden change on https://commons.wikimedia.org/wiki/File:FlowRoot_and_flowRegion.svg . Moreover, when I purged https://upload.wikimedia.org/wikipedia/commons/thumb/3/35/Bayesian_Calculus_Summary.svg/1051px-Bayesian_Calculus_Summary.svg.png , black billets disappeared (were present in the cached version). Does this new rsvg making {{SVG 1.2}} obsolete?
Apr 11 2019
… because the Phabricator application relays mail having no Message-ID header of its own to a local Exim MTA. Unlikely Exim would replace an existing ID with crap. IMHO not a good practice, to send Emails lacking Message-ID.
Apr 6 2019
P.S. the same should be done for DjVu (which AFAIK lies in the MediaWiki core) and perhaps for TIFF as well.
Apr 4 2019
For a huge site like Wikimedia? Some thousands (or even myriads) of gs(1) invocations? Insignificant.
Apr 3 2019
The only “work” to do was to change the value of [[ https://www.mediawiki.org/wiki/Extension:PdfHandler#Configuration | $wgPdfOutputExtension ]] from jpg to png – in this case, perhaps, noone would remember about the possibility of PDF → JPEG transformation, as PNG is universally supported in browsers since c. 1998, and no “huge impact on wikisource” would ever occur but disappearance of dirt. Instead, certain users opted to argue about “wide-color images”, increasing JPEG quality from 75% to 95%… how often do Wikimedians wrap color photography or painting into PDF?
Apr 2 2019
Mar 30 2019
Ī̲ don’t expect admins to proceed with the desired change in any foreseeable future, but fortunately a simple DHTML tweak can bring PNGs – see https://meta.wikimedia.org/wiki/User:Incnis_Mrsi/PDF-PNG.js
Dec 15 2018
In the context of Unicode discussions “characters” is an ill-advised term because some code points—such as U+FFFE—are explicitly defined as “non-characters” .
Dec 1 2018
Found this crap myself trying to feed an interwiki prefix to importScript – see https://commons.wikimedia.org/wiki/File:Cross-site_importScript_resulted_in_HTTP_403.png
Nov 30 2018
So?
Where is that JPEG lover among Wikimedia techs who obstructs fixing the bug for 4 years?
Look at https://commons.wikimedia.org/w/index.php?title=File%3AResourceLoader_Wikimania_2011.pdf&page=3 for example – several respected guys have their produce presented on par with miscellaneous rubbish from Wikimedia Commons, excretions of such users of Microsoft Paint or Adobe Photoshop who know nothing about formats.
Nov 29 2018
The most suspicious development in this story is that these are Wikimedia users—some not even sysops on any wiki where a revision is missing—try to trace causes of the bug, whereas all people having shell access to Wikimedia servers are silent. Are files really missing from directories or only unreadable for some reason (permissions, file-system damage, I/O error… )? For files which are missing, how recently did they exist in the past? Which procedures (such as moving files from one storage to another) could potentially cause the data loss?
Sep 29 2018
Of course, it isn’t my job to make bot edits manually. Nor anybody here should hire professional engineers at own expense, and Ī̲’m astonished that such sophistry is encouraged here. At the end, Ī̲ could manage such software myself, but it is full of PHP. Nowadays an Internet dweller may have impression that half of the world is coding PHP – can’t the Wikimedia Labs community co-opt some of these guys for this task?
Sep 27 2018
Can’t “regexes not being escaped properly” be used—at very least—for injection of arbitrary data into the edit? As for Wikimedia stewards, how many of them have necessary access to the Toolforge platform? Of course, any of the stewards can globally lock the account of CommonsDelinker, but the bot software could be used—while running—for making harm in other ways.
Not to Steinsplitter – we don’t communicate due to personal reasons. Other Wikimedia Commons guys AFAIK don’t support this software. Moreover, edits by CommonsDelinker threaten all Wikimedia, not Commons specifically.
Aug 23 2018
Oops, from https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29/Archive_167#Transparent_png_files and other discussions this is irrelevant to SVG at all, but something with Web typesetting by MediaWiki. Missed the point.
Sorry, can anybody explain why images from https://commons.wikimedia.org/wiki/Category:Transparent_squares are not affected? Look e. g. at https://upload.wikimedia.org/wikipedia/commons/thumb/0/02/Transparent_square.svg/512px-Transparent_square.svg.png – the SVG⇒PNG conversion occurred today, the PNG wasn’t cached from þe olde goode times, and it is fully transparent. Some essential conditions appear to be missing from description of the bug.
Apr 26 2018
Apr 23 2018
Mar 13 2018
Special:Log for the stuff several months old becomes painfully slow, where remains usable at all. Nowadays it fails with Wikimedia\Rdbms\DBQueryTimeoutError as explained in T180919 instead of a blunt 504, but it is seemingly the only improvement since 2015.
Feb 5 2018
Possibly related.
[WngdQApAME8AABNjd-cAAACR] 2018-02-05 09:01:48: Неустранимое исключение типа «Wikimedia\Rdbms\DBQueryTimeoutError» on https://commons.wikimedia.org/w/index.php?title=Special:Log/JackPotte&offset=20170819222910&limit=500&type=&user=JackPotte
[WngetQpAIC8AACoGlesAAACK] 2018-02-05 09:08:01: Неустранимое исключение типа «Wikimedia\Rdbms\DBQueryTimeoutError» on https://commons.wikimedia.org/w/index.php?title=Special:Log/JackPotte&offset=20170819201205&limit=500&type=&user=JackPotte
(yet another error on the same spot as above, forgot its ID)
[WnglJApAICoAAE-2J0cAAAAO] 2018-02-05 09:35:28: Неустранимое исключение типа «Wikimedia\Rdbms\DBQueryTimeoutError» on https://commons.wikimedia.org/w/index.php?title=Special:Log/JackPotte&offset=20170819195933&limit=320&type=&user=JackPotte
[WngowgpAIC0AAIqzxiAAAACT] 2018-02-05 09:50:55: Fatal exception of type "Wikimedia\Rdbms\DBQueryTimeoutError" on https://commons.wikimedia.org/w/index.php?title=Special:Log/JackPotte&offset=20170819195238&limit=320&type=&user=JackPotte&uselang=en
[WngulwpAAEAAAH@uMrUAAABR] 2018-02-05 10:15:47: Неустранимое исключение типа «Wikimedia\Rdbms\DBQueryTimeoutError» on https://commons.wikimedia.org/w/index.php?title=Special:Log/JackPotte&offset=20170819195238&limit=320&type=&user=JackPotte – exactly the same place as above (without uselang only), and after as much as 25 minutes
Jan 13 2018
Perhelion is right, Wikimedia volunteers shouldn’t spent efforts on compatibility kludges helping Adobe to promulgate their Illustrator and other house products. Better to design a bot fixing such font specification anomalies; it’s this consistent with Wikimedia mission to produce a reusable content, not a kludge envisaged.
Sep 17 2017
Do I understand correctly that, after fulfilling the task, <includeonly>__NOINDEX__</includeonly> will behave intuitively?
With the present software, it has no effect.