Page MenuHomePhabricator

Update librsvg to ≥2.42.3 (2.44.10)
Open, Stalled, MediumPublic

Description

Steps to reproduce:

  1. Download this and go to its path with terminal
  2. ssh tools-dev.wmflabs.org rsvg-convert <001-grinning-face.svg >out.png
  3. xdg-open out.png (or open out.png on macOS)

Actual:
It is broken with Wikimedia's librsvg, rsvg-convert version 2.40.2 (ssh tools-dev.wmflabs.org rsvg-convert -v)

Expected:

My local librsvg, rsvg-convert version 2.42.2, the result of rsvg-convert <001-grinning-face.svg >out.png

Update: After looking into it, it looks like backporting ≥2.42.3 in Debian stretch brings a long list of dependencies. This task is blocked until we upgrade Thumbor to Buster

Related Objects

StatusSubtypeAssignedTask
OpenBUG REPORTNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
StalledNone
DuplicateNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
DuplicateNone
OpenNone
OpenNone
OpenBUG REPORTNone
OpenNone
OpenBUG REPORTNone
OpenNone
OpenBUG REPORTNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
StalledNone
ResolvedNone
OpenNone
OpenNone
Resolvedfgiunchedi
Resolved Gilles
Resolvedfgiunchedi
Resolvedjijiki
ResolvedNone
Resolvedjijiki

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

I've made this task a sub task of the "Migrate Thumbor to stretch" task, while not strictly related it makes sense to bundle those (as most of the time required by the migration is consumed by validating rendering differences, so we should directly move to 2.42 when migrating to stretch).

jijiki added a subscriber: jijiki.Nov 7 2018, 2:36 PM

paravoid explained to me that librsvg 2.44 was uploaded to sid on November 3. There was some consternation about the ports which are still missing, but it looks like the change will not be reverted. This upload to sid was the thing that was previously blocked by lack of architecture support.

@MoritzMuehlenhoff - Now that the Thumbor hosts are upgraded to Debian Stretch, and Cargo has been made available in Stretch, are there any remaining blockers to upgrading librsvg to ≥2.42.3? Do we need to create a task for upgrading Stretch to ≥9.4, or is that relatively trivial?

@kaldari Effie looked into that and my initial estimation that we could build librsvg 2.42 in Stretch didn't hold, it needs more recent versions of Rust and Cargo that what was backported for Firefox 60. T216815 tracks the upgrade to buster which will ship librsvg 2.44.10.

jijiki changed the task status from Open to Stalled.Feb 28 2019, 10:14 AM
jijiki updated the task description. (Show Details)

Most of the icons in the OOUI library, which are just simple black and white paths compressed by SVGO, won't convert correctly on the live servers:

They work fine for me locally with 2.44.14:

As SVGO is used in more and more tools and workflows this is only going to get worse.

AFAICT this entire task stack is the wrong way around? We can't do this upgrade until T216815 is done, and all of the "sub-tasks" are mostly different aspects of duplicates of this one, and so should be parents/blocked by this one, right?

@Esanders : Your bug is imho T217990 and can be fixed using https://tools.wmflabs.org/svgworkaroundbot/ (activate "run svgcleaner"). It is related to missing spaces between arc-to-flags. That is a common SVGO problem, you should try https://github.com/scour-project/scour and https://github.com/RazrFalcon/svgcleaner instead, which are imho less buggy and sometimes even offer woraounds for librsvg-bugs. (so they often repair svgs; and hardly break them)

That is a common SVGO problem

Is SVGO actually violating the spec, or is this just a bug in librsvg?

That is a common SVGO problem

Is SVGO actually violating the spec, or is this just a bug in librsvg?

SVGO removes spaces between flags, which are not necesarry since flags can only be 0 or 1, so it is imho a librsvg-bug, see https://github.com/svg/svgo/issues/822 for details. It is similar as removing spaces before dots (.) or minuses (-).

Inkscape, Chrome, Firefox, resvg can handle them imho without problems, but librsvg not. Also most software understand them, hardly anyone (except svgo) removes those spaces, also removing is imho allowed.

But I do not know the W3C-SVG-1.1-DTD-Specifications, so I might be wrong.

Esanders added a comment.EditedMay 4 2020, 11:23 AM

Thanks, sounds like this isn't an SVGO problem, but a librsvg problem. Those fixes are workarounds, but the correct fix here is to upgrade librsvg.

AFAICT this entire task stack is the wrong way around? We can't do this upgrade until T216815 is done, and all of the "sub-tasks" are mostly different aspects of duplicates of this one, and so should be parents/blocked by this one, right?

Agreed, fixed (I think).

toorich changed the task status from Stalled to Open.Jun 24 2020, 9:58 AM
toorich added a subscriber: toorich.

Because of a lot of thumbnail error, I think now can re-open this task.

This comment was removed by toorich.
Aklapper changed the task status from Open to Stalled.Jun 24 2020, 10:34 AM

@toorich: This has nothing to do with "lots of thumbnail errors". See previous comments that this is stalled on upgrading Debian versions on Wikimedia servers.

AntiCompositeNumber renamed this task from Update librsvg to ≥2.42.3 to Update librsvg to ≥2.42.3 (2.44.10).Wed, Oct 14, 5:26 PM

T154237: SVG image wikisyntax can't use "lang=zh-hant" has indicated that this update may introduce a regression in the handling of some languages in <switch>-translated SVGs.