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

[Chris Lamb]

Hi Simon,

> Chris Lamb wrote:
>
> > I haven't checked the build history but assuming this is not in-of
> > itself a nondetermistic distinction (in which I would blame the hash
> > table usage) then this is likely due to filesystem ordering. Indeed if
> > you look at gtk/updateiconcache.c src:gtk+3.0 then, after a quick
> > skim, both of these things are apparent in this file.
> 
> Yes, it's both. The order of directory entries is in readdir() order,
> the order of insertion of per-file entries into a hash table is also
> influenced by readdir() order, and the contents of the hash table
> are written into a hash-table-on-disk data structure in arbitrary hash
> table iteration order.

Your email arrived at a good time as I had just written a reply to the
previous thread to say that we were overly hasty in coming to an
architecture-dependent conclusion given the evidence we had in front
of us at the time.

(As this email has a wider audience, as an obiter dictum I will note
that there are a few other variations between our "i386" and "amd64"
builders unrelated to the architecture itself which can lead to
misleading deductions.)

Furthermore, I fixed some nondeterminism in a separate GTK cache (?)
in 2018 or so which lent some circumstantial weight to my
equivocation. Indeed, Simon: shall I try and dig this out for you?
Your fix to GTK is certainly superior and thus there may be parallel
changes to be made to my past work across the codebase.


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby at debian.org 🍥 chris-lamb.co.uk
       `-