Bug#991300: 1:0.4.30-1 is FTFBS on s390x (bytes per pixel in header is 4096 instead of 16)

[Aurelien Jarno]

On 2021-07-20 13:11, Simon McVittie wrote:
> Control: forwarded -1 https://gitlab.gnome.org/GNOME/gegl/-/issues/289
> Control: severity -1 serious
> Control: tags -1 + ftbfs sid bookworm
> 
> On Tue, 20 Jul 2021 at 11:14:32 +0200, Christian Ehrhardt wrote:
> > I have reported the issue upstream at:
> >   https://gitlab.gnome.org/GNOME/gegl/-/issues/289
> 
> When opening new bugs, you can record this in a machine-readable way by
> mentioning it in the pseudo-header:
> 
>     Package: gegl
>     Version: 1:0.4.30-1
>     Forwarded: https://gitlab.gnome.org/GNOME/gegl/-/issues/289
>     (etc.)
> 
> I'm marking this as release-critical for Debian 12, but not for Debian
> 11, since testing has an older version which is unaffected.
> 
> This seems very likely to be endianness-related: s390x is the only
> big-endian release architecture remaining in Debian, but the powerpc and
> ppc64 ports (which are also BE) also failed to build this version.

Definitely. The problem is that the GEGL buffers are read and written in
machine endian format:

from gegl/buffer/gegl-buffer-load.c:89
|  ret = g_malloc (sizeof (GeglBufferHeader));
|  {
|    ssize_t sz_read = read(i, ret, sizeof(GeglBufferHeader));
|    if (sz_read != -1)
|      *offset += sz_read;
|  }

The tests used reference gegl buffers (in tests/compositions/reference)
which are in little endian format. And 4096 = bswap16(16).

I don't know GEGL to know if those buffers are designed to be portable,
or supposed to be used temporarily or just used for the tests.

Depending on that, one has to either define a big or little endian
format and update the read/write functions accordingly, or to provide
reference buffers for both endianness.

Regards,
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien at aurel32.net                 http://www.aurel32.net