On Tue, Nov 03, 2026 at 04:51:15PM +0100, John Paul Adrian Glaubitz wrote: > While Skia does not officially big-endian targets, it definitely > works there. Oracle is shipping Firefox for Solaris SPARC with Skia > enabled and they're providing custom patches to make Skia work [1].
When this decision was taken, it definitely didn't work. Google is not supporting Skia in BE targets, the WebKitGTK team does not have the time or resources to do it either, and no one had shown interest in doing or funding that work. Like all other major web engines, WebKitGTK is affected by a constant stream of security bugs (more than 200 CVEs in the most recent advisory), and having security updates blocked because the package does not build in s390x is not a good solution for our users. I don't know what Firefox does, or whether whatever they do can be brought to WebKitGTK just like that. Having a look at the patches in [1], there seems to be easily 10 or more that deal with endianness issues. Also, when I had a look at what other projects were doing to patch Skia downstream, it did not look pretty: https://raw.githubusercontent.com/zeldin/chromium_be/refs/heads/master/chromium-146.0.7680.177/skia.patch This is not something that we can carry downstream and definitely not something that I, as a Debian maintainer, am in a position to evaluate. Also, Skia is updated frequently in WebKitGTK, so whatever patches we would have to apply would need to be kept up-to-date. So it's not enough to produce a patch that works, someone has to *own* that work, preferably upstream, in the WebKit repo. If this happens and there's a realistic effort to keep Skia working on BE targets then we'll have time to reconsider and revert this decision, but until then I would not like s390x to block the WebKit updates for other architectures. And then there's the Swift problem. > Also, Swift definitely supports more architectures than just x86_64 > and AArch64 as can be seen from the source code [2]. I talked to Apple about this, they told me that they focus on x86_64 and aarch64, and support for other architectures is limited. I also talked to the person who maintains swiftlang in Debian, and when he tried to build the package on other architectures he found a never-ending stream of problems, and that's the reason why only amd64 and arm64 are enabled. So I think that this is more complicated than flipping a configuration option. But again: if there is someone with the time and energy to make Swift work on other architectures, that will be very much appreciated and the whole project will benefit from that. > There was also no effort made to reach out to porters to ask for > help, it was just unilaterally decided that WebKit2Gtk disables the > build on big-endian architectures. I regret that I did not include you directly in the conversation, and for that I apologize, but please understand that this decision was not taken lightly, and that we'll always be able to revert it if there's a *realistic* effort to overcome the challenges that we have ahead of us. But to be frank at the moment I'm more worried about the upcoming Swift transition (which, last time I checked, didn't even have a stable ABI). Regards, Berto > [1] > https://github.com/oracle/solaris-userland/tree/master/components/desktop/firefox/patches
