Could not reproduce on Firefox 89.0. In any case not a Thumbor problem, as the background pattern is done by MediaWiki. I do believe there is some Commons-specific customization though, so that might be a factor, but haven't looked further.

Current OAuth consumer appears to be https://meta.wikimedia.org/w/index.php?title=Special:OAuthListConsumers/view/3de8990ba210b127fea3ab8d866a9f09. I'm not seeing anything obviously missing there.

It looks to me like this is a CMYK problem. When you passed File:Sc cmyk pos claim.tif through Gimp, you exported it as RGB. Filesize savings aren't unexpected converting from unoptomized CMYK[A] to sRGB[A] with a colormap.

Many IRC links are expressed using templates. When you view a previous version of a page, the current version of any templates or files is displayed, not the version that would have been displayed at the time of that revision.

I'll use https://commons.wikimedia.org/wiki/File:Bookbinder%27s_Logo.webp as a sample image.

• 380x116px (original resolution): transparent
• 370px: transparent
• 360px: transparent
• 355px: transparent
• 354px: transparent
• 353x108px: opaque
• 350px: opaque

Issue was with the nginx configuration, not MediaWiki.

In T279036#6988933, @Awesome_Aasim wrote:

Yep, that disappeared as well for me.

After doing a reset of Global Preferences, everything was back to normal.

I guess someone could include that information on MediaWiki.

Current search-related projects:

• Wikidata person search
  • https://orator-matcher.toolforge.org/sparql.php?names=Alexis+Figueroa%0D|Pablo+Rumel+Espinoza%0D|Ignacio+Fritz
• Template discovery

For those with access, see also https://otrs-wiki.wikimedia.org/wiki/Administrator_requests#IRC

It's worth noting that we don't have project cloaks yet, so freenode access control lists likely won't work. The inbobot db and other channel configuration should mostly be able to be copied over.

It looks like a website for hosting non-free files (with non-commercial or no-derivatives restrictions). It isn't hosted on Wikimedia Foundation infrastructure or supported by the WMF. I'd consider it out of scope because it's outside of the Wikimedia projects and it deals in non-free software.

[snitch] (snerk@wikispecies/snerk): snerk, which per https://meta.wikimedia.org/wiki/IRC/Bots is operated by @MZMcBride, also needs to be migrated.

Yeah, ACLs are just going to be a mess for a bit until we get WM cloak infrastructure up.

Organizing by category is better in this situation, because Wikimedia-SVG-rendering has been used as a bit of a catchall for SVG-related tasks. Some of what you have categorized as "MediaWiki" would actually fall under Thumbor, while others fall under MediaWiki-File-management or other MediaWiki components. I don't know how useful separating these two would be on this board however, and they're already identified by tags.

It looks like everything is working as intended here, though there is a potential for confusion. The last version of librsvg available in Debian Stretch was, for a while, 2.40.16. We were able to backport and run 2.40.20, which was packaged in the stretch-wikimedia/component/thumbor/binary-amd64 APT repo. Debian has now released 2.40.21-0+deb9u1 as a security backport, and Wikimedia servers were updated accordingly.

Most recent entry in the tool's error.log:

2021-05-10 16:50:44: (mod_fastcgi.c.2543) FastCGI-stderr: PHP Warning:  PDOStatement::execute(): Error reading result set's header in /mnt/nfs/labstore-secondary-tools-project/guc/labs-tools-guc/src/Main.php on line 283
2021-05-10 16:50:44: (mod_fastcgi.c.2543) FastCGI-stderr: PHP Stack trace:
2021-05-10 16:50:44: (mod_fastcgi.c.2543) FastCGI-stderr: PHP   1. {main}() /mnt/nfs/labstore-secondary-tools-project/guc/labs-tools-guc/index.php:0
2021-05-10 16:50:44: (mod_fastcgi.c.2543) FastCGI-stderr: PHP   2. Guc\Main->__construct() /mnt/nfs/labstore-secondary-tools-project/guc/labs-tools-guc/index.php:41
2021-05-10 16:50:44: (mod_fastcgi.c.2543) FastCGI-stderr: PHP   3. Guc\Main->reduceWikis() /mnt/nfs/labstore-secondary-tools-project/guc/labs-tools-guc/src/Main.php:70
2021-05-10 16:50:44: (mod_fastcgi.c.2543) FastCGI-stderr: PHP   4. Guc\Main->doBigUnionReduce() /mnt/nfs/labstore-secondary-tools-project/guc/labs-tools-guc/src/Main.php:223
2021-05-10 16:50:44: (mod_fastcgi.c.2543) FastCGI-stderr: PHP   5. PDOStatement->execute() /mnt/nfs/labstore-secondary-tools-project/guc/labs-tools-guc/src/Main.php:283

Though less than ideal in this case, this is expected behavior.

# The ^ + gravity + extent trick is necessary to ensure that we get a thumbnail
# of exactly the width we've requested. In some edge cases a tiny fraction
# of the image might be cropped out. This is unavoidable with ImageMagick
# See http://www.imagemagick.org/Usage/resize/ for details

This effect is most prominent in high aspect-ratio files at lower resolutions like this, because there is no way to fit the image into the requested size. Doing the math, height = 20 / 235 * 200 = 18.7. Can't have a .7 of a pixel, so we round to 19. However, there's no way to fit a 235x20 image in a 220x19 box without stretching, cropping, or changing the size of the box, and cropping usually produces the best result.

Looks to be a duplicate of T282122: Frequent 504s while using logevents API on Commons

Please don't set priorities on tasks unless you plan to work on them.

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