On Mon, 28 Oct 2024 at 10:24:04 +0100, Chris Hofstaedtler wrote: > b) various packages already ignore s390x (gnome? others?)
GNOME is currently buildable on s390x, but we have to ignore a lot of test failures related to incorrect endianness of colour channels in image data (for example in GTK 3, GTK 4, librsvg) and investigating those issues tends to consume a much larger amount of maintainer time than we can really justify. We did temporarily remove high-level parts of GNOME (GNOME Shell and friends) from s390x in a previous release cycle, because the mozjs JavaScript engine was known-broken on s390x at the time, but in current versions it appears to be working mostly as intended. However, I'm reasonably sure that GNOME Shell has never been genuinely useful on IBM mainframes: there is a not-entirely-hypothetical use-case for running GTK/GNOME *apps* on one of these machines via X-forwarding or some similar mechanism, but running a full Wayland compositor on a mainframe seems really unlikely to be useful, particularly one like GNOME Shell that is designed to make use of a GPU. > I acknowledge that s390x is the last big-endian release arch. > While this fact may be the cause of interest for curious people, > in general it seems to cause more problems than we need. I believe the latest status from porters outside Debian is that the GTK and librsvg issues are believed to be caused by a regression in src:pixman, and not actually the GNOME libraries' fault. The regression in pixman appears to have been caused by a well-intentioned porter trying to solve some other endianness bug but instead working around it in the wrong layer, and last time I looked, it was believed to have been fixed upstream but not yet fixed in Debian. Based on fixes I've contributed to graphics-related libraries like GTK and SDL, I've come to believe that the only way to solve endianness issues without regressions is for each layer of the stack to have clear documentation about the byte-order that is intended, for example https://github.com/libsdl-org/SDL/commit/3698630bbc8e2ac501127c9c522cc0463a6c1565 which explains the meaning of each of SDL's pixel formats. Otherwise, it's very easy for porters for a big-endian architecture to "fix" an endianness-swap by reversing the endianness at the wrong layer of the library stack, resulting in the correct result via "compensating errors" for the particular library stack they are currently looking at, but with the side-effect of regressions in a different library stack. For example, if GTK is handling endianness wrongly, and a porter tries to solve that by swapping the endianness in a lower-level library that is used by both GTK and Qt, then they'll make GTK work as intended but break Qt. Instead, the correct fix is to make each library work according to its documentation (or, if documentation is missing, first document the behaviour it was designed to have, and then fix any deviations from that). > Maybe, motivated porters will show up and maintain the architecture and > its key packages (like s390-tools). Another factor that is relevant to s390x is that many newer architectures like aarch64 and riscv64 are converging on some common architecture properties (such as booting via EFI from an NVMe, SATA or SCSI disk, having USB connectivity, having a VGA-compatible GPU and/or a serial console, and generally behaving a bit like a PC), but because s390x is a mainframe architecture, it has various s390x-specific quirks such as its own special disk and terminal devices. This means that it will tend to need special-cased code paths in infrastructure tools like autopkgtest-build-qemu[1], which makes it harder for a typical Debian developer to investigate failures even if they are willing to spend time on it. Also, unlike typical newer ports like riscv64, the minimal s390x machine is a large, power-hungry, expensive mainframe: an interested developer can't simply set up a dev board on their desk like they can for embedded or "PC-like" ports. smcv [1] https://lists.debian.org/debian-devel/2024/10/msg00284.html
