Bug#1058740: gtk4, librsvg: big-endian support is at risk of being removed

[John Paul Adrian Glaubitz]

Hello Simon!

On Fri, 2023-12-15 at 11:35 +0000, Simon McVittie wrote:
> gtk4 had a recent test failure regression on s390x and other big-endian
> architectures like ppc64 (#1057782). I sent this upstream to
> https://gitlab.gnome.org/GNOME/gtk/-/issues/6260 and proposed a patch in
> https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6653, but upstream is
> reluctant to apply the patch because they think it is the wrong solution:
> 
> > I would rather people fix the actual issue, which is the large table
> > mapping GdkMemoryFormat to the corresponding GL format (and I bet the
> > one for dmabufs is broken, too, but we don't have tests for that).

Is there someone working on that?

> librsvg also has long-standing unsolved endianness-related issues, most
> likely in one of its dependencies (#1038447, which has affected bookworm
> since September 2022).

The fact that librsvg isn't fixing these issues is surprising to me.

Back when the library was converted to Rust, I was raising concerns
that this will reduce portability which was dismissed by the main
author as unjustified.

> The GNOME team does not have big-endian hardware where we can run manual
> tests, so we do not know how much of an impact this has on practical
> usability of GTK and librsvg on big-endian architectures: it's entirely
> possible that they have always been misrendered or broken on big-endian,
> but the bug was never reported because there were no users, and we
> are only noticing this now as a result of wider test coverage being
> introduced.

There are both QEMU-based solutions available as well as big-endian machines
in the GCC Compiler Farm [1]. There is also the OpenPOWER Openstack platform
which has both little- and big-endian targets available [2]. So, I don't think
the argument there is no way to test on big-endian targets is justified.

> If porters are interested in having GTK and librsvg continue to be
> available on big-endian, please work with upstream to get them to a point
> where endianness-specific bugs can be taken seriously in the upstream
> projects. I do not consider doing this downstream-only to be a solution.

Looking at both Fedora [3] and openSUSE [4], tests aren't executed on s390x
for these distributions either.

> If endianness-specific issues become a blocker for the Debian release
> process at some point in the future, then it is likely that I will have
> to start the process of doing architecture-specific removals for these
> packages and their reverse dependencies. For s390x this is likely to
> have little user-visible effect, because I find it unlikely that there
> are genuinely users running GUI applications on IBM mainframes, but for
> -ports architectures this will probably be a larger regression.

Well, removing librsvg will certainly disable quite large number of packages
on s390x. Maybe someone should CC an engineer from IBM on the bug report
and ask for help to fix the testsuite issues.

Adrian

> [1] https://portal.cfarm.net/machines/list/
> [2] https://osuosl.org/services/powerdev/request_hosting/
> [3] https://src.fedoraproject.org/rpms/librsvg2/blob/rawhide/f/librsvg2.spec#_153
> [4] https://build.opensuse.org/package/view_file/GNOME:Next/librsvg/librsvg.spec?expand=1

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913