Bug#953105: gtk-update-icon-cache does not produce reproducible results on 32-bit architectures

[Daniel Kahn Gillmor]

On Thu 2020-03-05 16:43:53 +0000, Orians, Jeremiah (DTMB) wrote:
> [dkg wrote:]
>> If i'm understanding you correctly, this suggests that the results created by gtk-update-icon-cache do not belong in any arch-independent package.
>> Is this correct?
>
> Partially, as the requirements for reproducibly cross-platform are a lot more strict than just being reproducible or just being cross-platform.
> I learned that the hard way when I ported https://github.com/oriansj/M2-Planet to a big-endian architecture and had to get it to have identical little-endian behavior too.
> So you can either admit that the code behaves differently on different architectures and be different or fix the code to behave exactly the identically across different architectures.

I'm not asking about reproducibility here; i'm asking about bugginess.

I know nothing about the gtk icon cache data format, but it appears to
be "something mmappable" from the docs i've read.

But if the different arches assume different memory data structures once
the file is mmapped, then shipping such a file in an arch:all package
might be dangerously wrong.

For example, consider building the arch:all package on amd64, and part
of that is building an updated gtk icon cache that we will ship.  When
it is subsequently installed and mmapped on s390x (change of endianness)
or armhf (change of pointer size), will the data still look the same to
the application?  (not to mention alignment, int size, etc.)

>> Is there some magic that a tool like lintian could use to identify an icon-cache file shipped in an arch: all package?  libmagic just identifies them as "data"
> There is no magic in IT; only sweat, blood and tears.

ha ha, but there is indeed a libmagic, the result of years of blood,
sweat and tears.  I was asking a serious question about what the
contents of a gtk icon-cache is supposed to be, and how we might
recognize it.

I'm used to generating arch:all cross-platform "binary" optimization
files (e.g. psl-make-dafsa).  Those are structured in a well-documented
way, and libmagic can even detect them.  Can we do the same for a gtk
icon cache?

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20200305/ab4bcb8d/attachment.sig>