gtk4 passes most of its test suite on powerpc, but fails one test: https://buildd.debian.org/status/fetch.php?pkg=gtk4&arch=powerpc&ver=4.16.1%2Bds-2&stamp=1726438341&raw=0 I don't know whether this is a bug in the test, or a bug in the part of GTK that is being tested. It might be a problem with pointers or varargs or something (powerpc is 32-bit big-endian, which is unusual these days). The same test fails on hppa, which I think might also be 32-bit big-endian? That test does succeed on ppc64 and s390x, which are 64-bit big-endian. The Debian GNOME team is unlikely to prioritize investigating this, because our focus is the release architectures where GNOME is most commonly used, but tested patches (ideally sent upstream) would be appreciated. Thanks, smcv
Hello, Yes, both hppa and powerpc are 32-bit big-endian. in total failing on powerpc and we should ignore all of those: Summary of Failures: 26/755 gtk:gdk / dmabufformats ERROR 0.25s killed by signal 5 SIGTRAP 21/755 gtk:gdk / memorytexture ERROR 1.32s killed by signal 5 SIGTRAP 131/755 gtk:gsk / scaling ERROR 0.26s killed by signal 5 SIGTRAP 128/755 gtk:gsk / misc ERROR 0.97s killed by signal 5 SIGTRAP 178/755 gtk:gtk / sorter ERROR 0.10s killed by signal 6 SIGABRT Ok: 722 Fail: 5 Skipped: 28 I have been trying to figure out how to skip those, but I have not been able to figure out the mechanism behind that and no matter what I try, the tests are still run. Anyone got any idea? Adrian
Hi, I looked into this issue and found that the entries for these tests are present in testsuite/gdk/meson.build, testsuite/gtk/meson.build, and testsuite/gsk/meson.build. Can we skip these tests conditionally based on the architecture in meson.build so that they are not run on powerpc? Thanks, Trupti.
Hi Trupti Thanks a lot for looking into this. Having more eyes looking at a problem helps localizing it more quickly. The tests are run from debian/rules which invokes debian/run-tests.sh. The run-tests.sh script has a mechanism to skip tests or give them more tolerance. But I have not exactly figured out how to skip any tests which are not reftests. Adrian
Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran, Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun. Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie für weitere Details.
On Mon, Oct 27, 2025 at 3:33 PM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote: Sorry for the delay responding. I think what the Debian GNOME team would like to see before skipping additional tests is some assurance that gtk4 actually works well on these platforms. None of us have access to a physical machine for these ports. If you have access to a machine like that, could you confirm that gtk4 is working despite these bugs? There is a binary package gtk-4-examples that install gtk4-demo you can use to manually test a wide variety of gtk4 UI elements. Alternatively, and I know it's a lot of work, but someone could identify and fix the code (or the tests) to correct the assumption that isn't true for these architectures. Thank you, Jeremy Bícha
Hello Jeremy, Oracle ships Gtk on Oracle Solaris for SPARC and Gtk applications worked fine last time I tested them on my Powerbook G4, so I have no doubt that Gtk actually works on these platforms. However, I can test the gtk4-demo package if you let me know what to test. Adrian
Control: reopen 1081952 I think selecting Application Class in the gtk4-demo app and clicking Run and then clicking around the UI is a good start. That particular demo is broken in 4.21.5 but works in earlier versions. I just reported that issue upstream. Thank you, Jeremy Bícha