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

[Simon McVittie]

On Mon, 26 Feb 2024 at 08:25:37 +0000, Gayathri Berli wrote:
> We are having a Debian unstable environment(sid) on s390x.. We think, it's
> better to reproduce the issue with git cloned repo instead of using “sbuild”
> method, so that we can get the commit history and see the code changes.

I see. In that case, you will still need to install the build-dependencies
of GTK 4 (or more generally, whatever package you're testing), and you will
need to either follow whatever steps Debian uses to run the tests, or make
your own build steps and workarounds that have similar behaviour.

> Can you please provide the exact steps to reproduce the bug?

If the bug you are referring to is #1057782, I didn't reproduce it myself
at first: our official autobuilders reproduced it, which they did by
building the package using sbuild.

When I reproduced it on the s390x porterbox 'zelenka', I followed steps
similar to these, which are the same for all Debian packages:

- create a new s390x unstable chroot
- install gtk4's build dependencies into it
- unpack gtk4 source and cd into it
- dpkg-buildpackage -us -uc -rfakeroot -B

> We cloned the gtk repo and built it with the following meson commands.. But we 
> see that almost all of the tests are failing.

If you have chosen to build from upstream source, then you're welcome to do
so, but the way that Debian packages are always built is to use
dpkg-buildpackage, and depending on the package, that might need to do
Debian-specific things as a result of the package's upstream design choices.
Those Debian-specific things should always be a good starting point for how
you can do a build from upstream source.

The debhelper tools log what they do, so if you look at the output from a
Debian build, you will see the exact commands that were used. For example,
in https://buildd.debian.org/status/fetch.php?pkg=gtk4&arch=s390x&ver=4.12.4%2Bds-1&stamp=1701103591&raw=0
you will find this command:

	cd debian/build/deb && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 meson setup ../../.. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir=lib/s390x-linux-gnu -Dpython.bytecompile=-1 -Dauto_features=enabled -Dbroadway-backend=true -Dx11-backend=true -Dcolord=enabled -Dman-pages=true -Dsysprof=enabled -Dwayland-backend=true -Ddocumentation=false -Dbuild-examples=true -Ddemos=true -Dinstall-tests=true -Dmedia-ffmpeg=disabled -Dcloudproviders=enabled

... which codifies exactly how Debian did the "meson setup" step for
that particular version of GTK. (In this case we're building in
debian/build/deb instead of _build, and we're setting a lot of options.)

Later in the log, you'll see the commands that were run instead of
"meson compile" and "meson test".

On Mon, 26 Feb 2024 at 11:01:07 +0100, John Paul Adrian Glaubitz wrote:
> Looking at the debian/rules of the gtk4 package, there is a dedicated
> script in the package that the Debian package uses to run the tests:
> 
> > https://salsa.debian.org/gnome-team/gtk4/-/blob/debian/latest/debian/run-tests.sh?ref_type=heads
> 
> It's reference from here:
> 
> > https://salsa.debian.org/gnome-team/gtk4/-/blob/debian/latest/debian/rules?ref_type=heads#L288

Yes, this.

This is partly because upstream expects that the test suite will be
invoked when you are already in a working X11 or Wayland environment,
but autobuilders and similar non-interactive or text-based systems
generally do not have that, so you have to run the tests under a mock
X11 environment (with xvfb-run) or under a mock Wayland environment
(we use weston --backend=headless-backend.so for this). In the Debian
packaging, this is encapsulated in debian/tests/run-with-display.

This is also partly because GTK can be either an X11 client or a Wayland
client. In Debian, we want to know that both of those work, so we run
the whole test suite twice: once under X11, and once under Wayland.

The debian/run-tests.sh script also skips some tests or adjusts the
thresholds used to to work around various issues:

- Some tests have slightly different rendering on i386 and other
  architectures with non-IEEE floating point. Upstream doesn't consider
  this to be a problem because they don't actively support non-x86_64
  architectures. There is a Debian-specific patch in the packaging that
  adds a mechanism by which we can tell the test suite to accept small
  rendering differences; I tried to upstream this, but upstream refused
  to apply it.

- Some tests have slightly different rendering with the versions of Pango,
  fonts and other dependencies in Debian. Upstream only really fully
  supports whatever exact versions they happen to have installed on their
  CI and development systems at the time (mostly Fedora).
  Again, there is a Debian-specific patch that adds a mechanism by which
  we can tell the test suite to accept small rendering differences.

- Sometimes tests fail because of architecture-specific issues (often bugs
  in Mesa or another dependency, rather than GTK), and are skipped on
  the affected architectures if we can establish that the impact on users
  of those architectures is likely to be non-release-critical.

> The problem seems to be that XDG_RUNTIME_DIR is not set:
> 
> 	Gdk-DEBUG: error: XDG_RUNTIME_DIR is invalid or not set in the environment.

That isn't actually a fatal error, only a debug message, despite having
the word "error" in it: XDG_RUNTIME_DIR is required for the Wayland
backend, but is not required for the X11 backend. But, if you are going
to run the tests with the Wayland backend forced (as we do in the Debian
packaging), then you will need working Wayland.

    smcv