https://upload.wikimedia.org/wikipedia/commons/thumb/8/81/Benjamin_Ola_Akande.jpg/120px-Benjamin_Ola_Akande.jpg

HTTP/2 200 OK 
date: Wed, 05 May 2021 15:00:58 GMT
content-type: image/jpeg
content-length: 7472
x-object-meta-sha1base36: pdif0f0ipygkgl5z3li416kx4x5v9bj
content-disposition: inline;filename*=UTF-8''Benjamin_Ola_Akande.jpg
last-modified: Sat, 08 Apr 2017 20:01:11 GMT
etag: 381e0ba55afc473e10f27a58e5f2004e
x-timestamp: 1491681670.44952
server: ATS/8.0.8
age: 22
x-cache: cp1088 miss, cp1076 hit/3
x-cache-status: hit-front
server-timing: cache;desc="hit-front", host;desc="cp1076"
strict-transport-security: max-age=106384710; includeSubDomains; preload
report-to: { "group": "wm_nel", "max_age": 86400, "endpoints": [{ "url": "https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0" }] }
nel: { "report_to": "wm_nel", "max_age": 86400, "failure_fraction": 0.05, "success_fraction": 0.0}
permissions-policy: interest-cohort=()
x-client-ip: ***
access-control-allow-origin: *
access-control-expose-headers: Age, Date, Content-Length, Content-Range, X-Content-Duration, X-Cache
timing-allow-origin: *
accept-ranges: bytes
X-Firefox-Spdy: h2

x-timestamp evaluates to 2017-04-08 20:01:10 UTC.
This sort of issue has happened before, I believe it's related to T206190. These sorts of tasks usually get closed as "fixed itself eventually", but it would be nice to actually get this cache invalidation problem fixed.

To clarify: Based on T280718, fc-list will directly relate to what fonts are available to Thumbor when thumbnailing PDFs without embedded fonts and SVGs.

The goal here wouldn't be to save disk space, but to make network transfers faster. The SVG optimization wouldn't affect the original file accessible on the file page, but what would be included inline on an article (instead of the current png thumbnails). I'd say the removal of non-rendering components (whitespace and comments) would be minimum expected.

For reference, https://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-MyUploads.js&oldid=195246328 is how it was done before the extension.

Doesn't look like it, though there is no EBNF grammar given for FuncIRI. https://www.w3.org/TR/SVG11/types.html#DataTypeFuncIRI

Yup, just to confirm that:

$ LANGUAGE=en LANG=es rsvg-convert -w 512 -h 360 -o result-2.png  Multilingual_SVG_example.svg

$ LANG=es rsvg-convert -w 512 -h 360 -o result.png  Multilingual_SVG_example.svg

Result with rsvg-convert version 2.50.4 (latest):

Definitely a font issue, probably not a librsvg issue. Debian doesn't package Noto Color Emoji until Buster, so we'd have to backport (unlikely) or wait for T216815.

The caching layer complains when requests take longer than 60s wall-clock time. To avoid tripping this log unnecessarily, Thumbor enforces a 59s wall-clock timeout for subprocesses (like shelling out to librsvg). If the limit is exceeded, it is killed and the request 500s.

There are a few hiccups, but nothing like the full tab lockup that occurred previously. I'd call this fixed.

In T280718#7031176, @JoKalliauer wrote:

In T280718#7023966, @akosiaris wrote:

[...] I propose we remove that file from mediawik-config repo altogether. It's already 3.5 years out of date, if anything relies on it, it's relying on very old data.

Some WMcommons-SVG-editors call phab a "black hole".
librsvg 2.40.X is over 4 years out of date (newer version exist) and 3,5 years depreciated end-of-life (announced that it would have been the last 2.40 version, which was deprecated effectively immediately.). And it is still used for rendering SVG by Wikimedia, see T193352 . I think (almost) no-one would propose to remove the (outdated) svg-renderer from commons (without replacement e.g. another library or client-side rendering). Even if some problematic SVGs get blocked during upload T279238, a outdated librsvg might be still a security issue since old svgs with such content sill exist.

The current version of Thumbor in https://apt-browser.toolforge.org/stretch-wikimedia/component/thumbor/ is python-thumbor-wikimedia: 2.9-1+deb10u1. Was this ever deployed to production? Looking at https://sal.toolforge.org/production?p=0&q=thumbor&d= it looks like it was, but this task never got closed.

https://www.mediawiki.org/wiki/Manual:Administrators#Rollback says that this is expected behavior for administrators using bot rollback. Normal rollbackers do not have the markbotedits right, but administrators, global rollbackers, and Stewards have this permission. While spot-checking, I was not able to find an instance where the edit was rolled back by a non-admin/steward/GR.

From a user perspective, having something like fc-list is useful. rOPUP modules/mediawiki/manifests/packages/fonts.pp is the list of font packages that are installed. That's enough for some uses, but it won't really tell you exactly what fonts are available unless you're already familiar with Debian font packaging.

<text y="1050">EB Garamond Initials</text><text x="300" y="1050" font-family="EB Garamond Initials">ADFGLNOQTXo</text>
<text y="1075">EB Garamond Initials Fill1</text><text x="300" y="1075" font-family="EB Garamond Initials Fill1">AFGLNOQTXo</text>
<text y="1100">EB Garamond Initials Fill2</text><text x="300" y="1100" font-family="EB Garamond Initials Fill2">AFGLNOQTXo</text>

is probably why EB Garamond Initials is only rendering ADFGLNOQTXo.

Oh it's fine on Commons and other multi-language wikis for some reason. But if you look at https://translate.google.com/translate?sl=auto&tl=en&u=https://ja.wikipedia.org/wiki/Template:Sakujo or https://translate.google.com/translate?sl=auto&tl=en&u=https://fr.wikipedia.org/wiki/Manic_GT you can see the problem.

Ah, it's a watchlist notification.

I should have been more specific. What type of action are the email notifications notifying you about? Could you attach a screenshot or include the text of a message?

What kind of notifications (talk page messages, mentions, etc)?

In T244567#6941834, @Sreejithk2000 wrote:

One more. Unable to restore https://commons.wikimedia.org/w/index.php?title=File:Zholtovsky_tarasov_house.jpg

Nope nope nope, land of 10,000 nopes.

It's sent as a header, visible in the Network panel of your browser's developer tools.

It seems to be working correctly now. The thumbnail has a last-modified date of Sun, 14 Mar 2021 19:37:22 GMT, which means it was generated soon after you filed this task.

It's March again, and this is still very broken.

That is an extremely high upload rate that will flood Special:RecentChanges and Special:NewFiles with unpatrolled new files. Aside from users qualifying for and being granted autopatrolled status in accordance with https://commons.wikimedia.org/wiki/Commons:Autopatrolled, I don't know of a way to exempt a particular tool from the upload limit, and I would be opposed to the creation of one.

Is there a reason you need to be uploading files every 11 seconds?

This has come up again at https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals#Commons_should_support_JP2_file_format

There have been no errors since the fix was deployed...until now.

2021-03-04 03:05:24 pywiki ERROR: Retrying failed OAuth authentication for commons:commons: The authorization headers in your request are not valid: Nonce already used: 146...

.de64336c-fddc-49e2-8009-234606717897{fill:#00af6f;} is a class selector, not an id selector.

Thank you. I purged the files and see the error now.

I don't see any issue with the rendering of those files. Can you attach screenshots of what is incorrect and what the correct rendering should be?

In T274050#6862681, @Josve05a wrote:

@DeltaQuad Seems to have blocked the IP on enwp https://en.wikipedia.org/w/index.php?title=Special:Log/block&page=User%3A185.15.56.1

The transition to an OTRS fork would be much the same as any other OTRS upgrade. They're time-consuming, especially when database upgrades are concerned, and have some pitfalls, but they're not too difficult.

Radiant's is out, see section 4 or https://github.com/RadiantSystem/radiant.

Logs from testing locally:

2021-02-16 02:36:43 thumbor:DEBUG METRICS: inc: response.count:1
2021-02-16 02:36:43 thumbor:DEBUG Format specified: jpg
2021-02-16 02:36:43 thumbor:DEBUG METRICS: inc: storage.miss:1
2021-02-16 02:36:43 thumbor:DEBUG [HTTPS] load_sync: https%3A//upload.wikimedia.org/wikipedia/commons/5/50/Bronx%2C_V._12%2C_Double_Page_Plate_No._262_%28Map_bounded_by_Clinton_Ave.%2C_E._180th_St.%2C_Honeywell_Ave.%2C_Southern_Blvd.%2C_Crotona_Park_North%29_NYPL2001520.tiff
2021-02-16 02:36:43 thumbor:DEBUG [HTTPS] Loading normalized URL: https://upload.wikimedia.org/wikipedia/commons/5/50/Bronx%2C_V._12%2C_Double_Page_Plate_No._262_%28Map_bounded_by_Clinton_Ave.%2C_E._180th_St.%2C_Honeywell_Ave.%2C_Southern_Blvd.%2C_Crotona_Park_North%29_NYPL2001520.tiff
2021-02-16 02:36:50 thumbor:DEBUG [HTTPS] return_contents: /tmp/tmpnYxNj6
2021-02-16 02:36:50 thumbor:DEBUG METRICS: inc: original_image.status.200:1
2021-02-16 02:36:50 thumbor:DEBUG METRICS: inc: original_image.response_bytes:4096
2021-02-16 02:36:50 thumbor:DEBUG [Proxy] Looking for a tiff engine
2021-02-16 02:36:50 thumbor:DEBUG [ExiftoolRunner] command: ['/usr/bin/exiftool', '-ImageSize', '-s', '-s', '-s', '/tmp/tmpnYxNj6']
2021-02-16 02:36:50 thumbor:DEBUG [ShellRunner] Command: ['/usr/bin/timeout', '--foreground', '59', '/usr/bin/exiftool', '-ImageSize', '-s', '-s', '-s', '/tmp/tmpnYxNj6']
2021-02-16 02:36:50 thumbor:DEBUG [ShellRunner] Stdout: 8973x6724

I've found some information that may or may not be helpful. When the prompt opens, if I open the Firefox debugger and hit pause, it identifies https://gerrit.wikimedia.org/g/mediawiki/extensions/EventLogging/+/a5ccd5e9eb696d5ce7e97d74ecfebbe9763286ac/modules/ext.eventLogging/BackgroundQueue.js#103 as the currently-running line.
I've not been successful in reproducing the error with the debugger already open.

This also occurs with the block log displayed in Special:Contribs and Special:Block, https://commons.wikimedia.org/wiki/Special:Contributions/109.126.196.166 is an example

Still occurring for me. The rate is subjectively a bit slower, but it has definitely not been fixed.

I've reuploaded the rest of the files as well.

In T273741#6814266, @Shizhao wrote:

Rename to a new filename?

Testing locally, it appears that vips doesn't like this file:

$ vips shrink "LOCK_VIEW._CONTROL_STATION_ON_RIGHT._LOOKING_SOUTHEAST._-_Illinois_Waterway,_Thomas_J._O'Brien_Lock_and_Control_Works,_East_130th_Street,_Chicago,_Cook_County,_IL_HAER_IL-164-I-3.tif" vips_result.png 3 3

Any role where 2FA is required should be excluded.

On Wikimedia sites, thumbnailing (including of animated GIFs) is handled by Thumbor, independently of MediaWiki. While Thumbor's MAX_ANIMATED_GIF_AREA and MW's $wgMaxAnimatedGifArea are currently the same, they are configured independently.

Confirming that this happens to me occasionally. I usually notice it when opening a file and immediately clicking the delete button. When it occurs, most of my scripts and gadgets haven't changed the page (adding buttons, portlet links, etc) yet.

They're being correctly parsed now, and I've re-run the report so the bulk lists should be correct as well.

It wasn't the characters themselves that was the problem, it was people using HTML entities like &.

Elastic does not announce release dates in advance.

That is, essentially, how I would fix it on the Thumbor end, if ImageMagick is working as expected. It would make sense to ask them if this is expected behavior first.

Amazon has announced plans to fork Elasticsearch and Kibana under the original Apache 2.0 license (starting from ES 7.10)
https://aws.amazon.com/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/

The "garbled" interface text comes from https://en.wikipedia.beta.wmflabs.org/wiki/Template:Protected_page_text via https://en.wikipedia.beta.wmflabs.org/wiki/MediaWiki:Protectedpagetext That template uses a table for layout and uses position:relative. This is fine on a desktop-size display, but doesn't work well on mobile. Similar effects occur opening the desktop site at a smaller size or high zoom level:

Testing locally (ImageMagick 7.0.10-58 Q16 x86_64 2021-01-16; libjpeg-turbo 2.0.6-1), this appears to be an issue with chroma subsampling.

$ convert -define tiff:exif-properties=no -define jpeg:size=224x240 -resize 112x120^ -gravity center -extent 112x120 -quality 87 -sampling-factor 4:2:0 -interlace Plane Smileyface.jpg 112px-Smileyface.jpg

$ convert -define tiff:exif-properties=no -define jpeg:size=224x240 -resize 112x120^ -gravity center -extent 112x120 -quality 87 -interlace Plane Smileyface.jpg 112px-Smileyface.jpg 

I believe pywikibot uses OAuth 1, not OAuth 2. Docs are https://www.mediawiki.org/wiki/Manual:Pywikibot/OAuth

We have https://commons.wikimedia.org/wiki/Template:Not-PD-US-expired-min-year and https://commons.wikimedia.org/wiki/Template:PD-US-expired-max-year for this exact purpose. They are used by the license templates themselves, and if they start giving the wrong year we have much bigger problems.

In T272201#6753694, @Jidanni wrote:

That means it wouldn't be easy to fix this bug by just comparing filenames.

Well all I know is in the two cases I posted a filename comparison, done at the very last stage, would have avoided the duplicate link being added to the page.

This is something that also annoys me. I usually end up downloading the file and using exiftool to look at the metadata. https://anticompositetools.toolforge.org/filearchive/ is capable of reading the metadata from the filearchive table (example), but it's not nicely formatted like proper MediaWiki output.