Bug#1038447: librsvg: FTBFS on big-endian architectures: multiple test regressions since September 2022

[Simon McVittie]

Source: librsvg
Version: 2.54.5+dfsg-1
Severity: serious
Tags: ftbfs help
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debia...@lists.debian.org, debian-...@lists.debian.org, ru...@packages.debian.org
Forwarded: https://gitlab.gnome.org/GNOME/librsvg/-/issues/972

librsvg 2.54.5+dfsg-2 failed to build on s390x, powerpc and ppc64 with
multiple test failures. At first glance, they seem to be the same test
failures, meaning this is about endianness rather than any specific
architecture.

2.54.5+dfsg-2 only contains packaging changes and no code changes,
so I strongly suspect (but have not actually proved) that rebuilding
2.54.5+dfsg-1 with current versions of its dependencies would also
exhibit the same test failures, similar to #1038252 on i386.
The specific tests that are failing here are not the same as #1038252.

The failing tests here are "reftests", which render a SVG image to PNG
and compare the result with a known-good PNG. These are difficult to
investigate in a buildd log, because they're very visual, but the librsvg
buildd logs export the output images using uuencode, and I have extracted
them from the s390x log and used them to open upstream bugs which show
the rendering issue visually:

- https://gitlab.gnome.org/GNOME/librsvg/-/issues/972
- https://gitlab.gnome.org/GNOME/librsvg/-/issues/973
- https://gitlab.gnome.org/GNOME/librsvg/-/issues/974
- https://gitlab.gnome.org/GNOME/librsvg/-/issues/975
- https://gitlab.gnome.org/GNOME/librsvg/-/issues/976
- https://gitlab.gnome.org/GNOME/librsvg/-/issues/977
- https://gitlab.gnome.org/GNOME/librsvg/-/issues/978
- https://gitlab.gnome.org/GNOME/librsvg/-/issues/979
- https://gitlab.gnome.org/GNOME/librsvg/-/issues/980
- https://gitlab.gnome.org/GNOME/librsvg/-/issues/981
- https://gitlab.gnome.org/GNOME/librsvg/-/issues/982
- https://gitlab.gnome.org/GNOME/librsvg/-/issues/983
- https://gitlab.gnome.org/GNOME/librsvg/-/issues/984

In all cases, the standalone steps to reproduce would be: render the SVG
to PNG; look at the SVG and its reference rendering side-by-side; and the
expected result is that they look the same.

The most likely trigger for regressions between September 2022 and now
would seem to be the upgrade of rustc from 1.61 to 1.63, since Cairo
has not had significant changes for a while, none of the rendering
differences involve text/fonts, and librsvg seems to do all its non-text
rendering using vendored Rust libraries or its own Rust code rather than
an external library like libpng.

smcv

[Simon McVittie]

On Sun, 18 Jun 2023 at 14:47:00 +0100, Simon McVittie wrote:
> I rebuilt librsvg in bookworm on the s390x porterbox zelenka, and can
> confirm that 2.54.5+dfsg-1 now fails in bookworm too. So something must
> have triggered a regression between September 2022 and now.

It would be helpful if someone with suitable hardware could put this
through debbisect or similar to find out which build-dependency triggered
this. I don't intend to do this myself, since emulating a big-endian
architecture on x86 is going to be a lot slower and more power-hungry, and
as far as I'm aware I don't have the ability to install older packages of
my choice on a porterbox (which don't allow unprivileged users to create
new user namespaces).

Thanks,
smcv

[John Paul Adrian Glaubitz]

> On Jun 18, 2023, at 3:53 PM, Simon McVittie <sm...@debian.org> wrote:

>
> On Sun, 18 Jun 2023 at 14:47:00 +0100, Simon McVittie wrote:
>> I rebuilt librsvg in bookworm on the s390x porterbox zelenka, and can
>> confirm that 2.54.5+dfsg-1 now fails in bookworm too. So something must
>> have triggered a regression between September 2022 and now.
>
> It would be helpful if someone with suitable hardware could put this
> through debbisect or similar to find out which build-dependency triggered
> this.

TIL about debbisect. I can try to bisect this on big-endian PowerPC, I have root on multiple big-endian machines.

Adrian

[Simon McVittie]

Control: severity -1 important

On Sun, 18 Jun 2023 at 14:52:18 +0100, Simon McVittie wrote:
> On Sun, 18 Jun 2023 at 14:47:00 +0100, Simon McVittie wrote:
> > I rebuilt librsvg in bookworm on the s390x porterbox zelenka, and can
> > confirm that 2.54.5+dfsg-1 now fails in bookworm too. So something must
> > have triggered a regression between September 2022 and now.
>
> It would be helpful if someone with suitable hardware could put this
> through debbisect or similar to find out which build-dependency triggered
> this.

Since nobody seems to have had a chance to do this, and this FTBFS is now
blocking a fix for a security vulnerability (#1041810, CVE-2023-38633),
I'm going to disable the relevant tests, which lowers the severity of
this bug to important (verified to be sufficient to avoid the FTBFS on
the s390x porterbox, zelenka).

The result is that there are known mis-renderings for certain SVG
files on s390x, powerpc, ppc64 and other big-endian architectures,
some of which could be highly visible in desktop enviroments like GNOME
if icons happen to use of the relevant features. This is unfortunate,
but seems less of a disservice to our users than preventing a security
fix on the more widely-used little-endian architectures.

Help would still be appreciated from the porting teams for big-endian
architectures. This is probably not actually a librsvg bug, because the
same librsvg source code worked in September 2022 but failed in June 2023,
which would point to this being a regression in some other component (but
I don't know which one, and I don't have the hardware to run debbisect).

Thanks,
smcv

[Simon McVittie]

On Sun, 18 Jun 2023 at 15:58:10 +0200, John Paul Adrian Glaubitz wrote:
> TIL about debbisect. I can try to bisect this on big-endian PowerPC,
> I have root on multiple big-endian machines.

Were you able to do this?

Thanks,
smcv

[Simon McVittie]

On Mon, 28 Aug 2023 at 06:05:57 +0000, Gayathri Berli wrote:
> Unfortunately, we are encountering an issue with the chroot as followed.
> [an attached screenshot of some text]

For reference, the attached image was a screenshot of a terminal with
approximately this text (might contain mistakes, I am transcribing it
by hand):

root@<machine>:~# schroot -n librsvg -c sid —begin
E: --session-name is not permitted for the specified action
I: Run “schroot --help” to list usage example for the specified action

When discussing a technical issue, particularly involving command-line
tools, please try to send text as copy/pasted text, rather than as
images of text. Images are not easily available in all contexts, and
some developers who rely on screen readers and other accessibility
technologies cannot see them at all.

> We
> tried the best to resolve it, but nothing helped us move forward. Could anyone
> has faced the same issue/solution of it please let us know. If any other steps
> might be needed to reproduce the same, please confirm.

Sorry, I have too many responsibilities other than librsvg, and I am not
able to provide you with a detailed tutorial on how to use schroot. The
instructions I provided assume basic familiarity with the schroot tool,
and a chroot template named "sid" already set up with Debian unstable.

As an alternative to using Debian-specific tools, you could try building
librsvg according to its normal upstream build procedure: you might
find that easier if you are unfamiliar with Debian tools. There is an
upstream development guide available:
https://gnome.pages.gitlab.gnome.org/librsvg/devel-docs/index.html

Or, if you have a preferred container or virtual machine technology, you
could use that instead of schroot, set up a Debian unstable environment,
and run something like this as root in that environment instead of
using schroot:

apt-get -y update
apt-get -y dist-upgrade
apt-get -y install ccache git quilt git-buildpackage
apt-get -y build-dep librsvg

and then do the build in that environment. If you would prefer to use
schroot, please consult schroot documentation or ask a colleague who
already knows how to use it.

In the text in your screenshot, you seem to be using "—begin" (starting
with U+2014 EM DASH) instead of the correct "--begin" (starting with two
copies of U+002D HYPHEN-MINUS) which is probably part of the problem that
you are having.

smcv

[Simon McVittie]

Control: reassign -1 libpixman-1-0 0.42.2-1
Control: affects -1 + librsvg
Control: tags -1 + upstream
Control: forwarded -1 https://gitlab.freedesktop.org/pixman/pixman/-/issues/78

On Mon, 29 Jan 2024 at 05:13:59 +0000, Gayathri Berli wrote:
> After a lot of debugging, by upgrading librsvg and its dependency packages one
> after another like libcairo, libpixman and libpango, we found out that while
> upgrading libpixman (libpixman-1-0:s390x) package from version 0.40.0-1 to
> version 0.42.2-1, the test suites failed in the librsvg.
>
> I built these packages ( i.e. cairo, pixman & pango) manually from their
> respective sources by resolving all the version dependencies and ran the
> librsvg tests to make sure that the test suites failed while upgrading pixman
> package from 0.40.0-1 to version 0.42.2-1..
>
> By doing git-bisect on pixman package commits, I figured out the below
> mentioned commit which has changes w.r.t. big-endian architectures, introduced
> the regression.. But I checked the main line repo of pixman and I see that the
> test suites are passing. I will check further on this and post my updates...!
>
> commit b4a105d77232a87304b7b621e2f99e699a8eebd3
> Author: Jocelyn Falempe <[1]jfal...@redhat.com>
> Date: Wed Jun 29 10:55:43 2022 +0200
>
> Fix inverted colors on big endian system
>
> bits_image_fetch_separable_convolution_affine() didn't take care
> of big endian system
>
> Signed-off-by: Jocelyn Falempe <[2]jfal...@redhat.com>
>
> There is one open issues in pixman regarding to this commit changes which
> effecting the big-endian systems.
>
> [3]https://gitlab.freedesktop.org/pixman/pixman/-/issues/78
>
> [4]https://gitlab.freedesktop.org/pixman/pixman/-/issues/72

Thanks, reassigning the Debian bug from librsvg to pixman.

smcv