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
