Hi Andreas, On Thu, 9 May 2024 at 11:17, Andreas Rönnquist <[email protected]> wrote: > > Those fixes was obviously not enough, just see the repro reports.
Ok, yep - thanks for checking those. When I check the reports, most of the remaining problems seem to relate to duplicate definitions appearing in the documentation (for example, a definition for "al_color_cmyk" appearing twice). > The strange thing is that it according to the tests does seem to build > reproducible on arm64... Puzzling indeed. I'll have another read through the codebase soon. > One other detail is that on armhf the only change seems to be the > architecture which is included in the ALLEGRO_PKG_HOST_SYSTEM variable. > > Is there some magic like SOURCE_DATE_EPOCH to use that would avoid this > problem in this case? Not as far as I'm aware, no - for SOURCE_DATE_EPOCH, there is a range of possible integer values that are all equally valid, so it's straightforward to select one to make a package build reproducible. Specifiying an arbitrary but static architecture could be at-least challenging, and at-worst misleading or potentially compatibility-breaking. In this kind of situation I'd generally recommend working backwards to figure out whether -- and if so, how -- the nondeterministic value is used. I didn't find any search results for ALLEGRO_PKG_HOST_SYSTEM in Debian codesearch[1], so I'd recommend a reprotest build after removing it to see whether that succeeds (I'll try this soon). Regards, James [1] - https://codesearch.debian.net/search?q=ALLEGRO_PKG_HOST_SYSTEM [2] - https://salsa.debian.org/reproducible-builds/reprotest
