Your message dated Mon, 16 Feb 2026 15:27:58 -0500
with message-id 
<caaajcmz-lgvksfkyavue-bdgpo4-jz2xyqddd2qr9-uz46l...@mail.gmail.com>
and subject line Re: Bug#1118963: gtk4: Please disable four more tests on 
sparc64
has caused the Debian Bug report #1081952,
regarding gtk4: FTBFS on powerpc: gtk:gtk / sorter test fails
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
1081952: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081952
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: gtk4
Version: 4.16.1+ds-2
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: [email protected]
User: [email protected]
Usertags: powerpc

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
> ================================== 163/692 ===================================
> test:         gtk:gtk / sorter
> start time:   22:08:07
> duration:     0.07s
> result:       killed by signal 6 SIGABRT
> command:      GTK_A11Y=test GDK_DEBUG=default-settings MESON_TEST_ITERATION=1 
> GSETTINGS_SCHEMA_DIR=/<<PKGBUILDDIR>>/debian/build/deb/gtk 
> G_TEST_BUILDDIR=/<<PKGBUILDDIR>>/debian/build/deb/testsuite/gtk 
> G_TEST_SRCDIR=/<<PKGBUILDDIR>>/testsuite/gtk GDK_BACKEND=x11 
> GSK_RENDERER=cairo MALLOC_PERTURB_=63 
> UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>  TEST_OUTPUT_SUBDIR=x11 LD_LIBRARY_PATH=/<<PKGBUILDDIR>>/debian/build/deb/gtk 
> MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1
>  GTK_DEBUG=css GTK_CSD=1 GSETTINGS_BACKEND=memory 
> ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 
> G_ENABLE_DIAGNOSTIC=0 /<<PKGBUILDDIR>>/debian/build/deb/testsuite/gtk/sorter 
> --tap -k
> ----------------------------------- stdout -----------------------------------
> TAP version 14
> # random seed: R02S6b2c8c0fedad0d1281925bd23a570430
> 1..19
> # Start of sorter tests
> ok 1 /sorter/simple
> ok 2 /sorter/string
> ok 3 /sorter/change
> ok 4 /sorter/multi
> ok 5 /sorter/stable
> # Start of numeric tests
> ok 6 /sorter/numeric/boolean
> ok 7 /sorter/numeric/char
> ok 8 /sorter/numeric/uchar
> ok 9 /sorter/numeric/int
> ok 10 /sorter/numeric/uint
> ok 11 /sorter/numeric/float
> ok 12 /sorter/numeric/double
> ok 13 /sorter/numeric/long
> ok 14 /sorter/numeric/ulong
> not ok /sorter/numeric/int64 - 
> ERROR:../../../testsuite/gtk/sorter.c:439:test_numeric_int64: assertion 
> failed (model == "1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20"): ("10 
> 12 18 19 13 7 5 3 6 9 16 15 20 1 11 4 2 17 14 8" == "1 2 3 4 5 6 7 8 9 10 11 
> 12 13 14 15 16 17 18 19 20")
> Bail out!

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

--- End Message ---
--- Begin Message ---
On Mon, Oct 27, 2025 at 3:33 PM John Paul Adrian Glaubitz
<[email protected]> wrote:
> On Mon, 2025-10-27 at 19:21 +0100, John Paul Adrian Glaubitz wrote:
> > After the last changes, the failures on sparc64 are actually now down to 
> > [1]:
> >
> > Summary of Failures:
> >
> >  26/755 gtk:gdk / dmabufformats                                             
> >          ERROR            3.28s   killed by signal 5 SIGTRAP
> >  21/755 gtk:gdk / memorytexture                                             
> >          ERROR            3.58s   killed by signal 5 SIGTRAP
> > 131/755 gtk:gsk / scaling                                                   
> >          ERROR            3.36s   killed by signal 5 SIGTRAP
> > 128/755 gtk:gsk / misc                                                      
> >          ERROR            3.82s   killed by signal 5 SIGTRAP
> >
> > Ok:                723
> > Fail:              4
> > Skipped:           28
>
> And we need to disable those tests plus another one on powerpc as well:
>
> Summary of Failures:
>
>  26/755 gtk:gdk / dmabufformats                                               
>        ERROR            4.57s   killed by signal 5 SIGTRAP
>  21/755 gtk:gdk / memorytexture                                               
>        ERROR            5.05s   killed by signal 5 SIGTRAP
> 131/755 gtk:gsk / scaling                                                     
>        ERROR            5.31s   killed by signal 5 SIGTRAP
> 128/755 gtk:gsk / misc                                                        
>        ERROR            5.45s   killed by signal 5 SIGTRAP
> 178/755 gtk:gtk / sorter                                                      
>        ERROR            4.37s   killed by signal 6 SIGABRT

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

--- End Message ---

Reply via email to