Other architectures appear to consistantly build reproducibly.
The diffoscope output appears to have identified "wrapNNN-procedure" where NNN is a different number in the two different builds.
FWIW, guile-gcrypt 0.2.x builds with guile 2.2, and guile-gcrypt 0.3.x builds with guile 3.0 in Debian, though the diffoscope output looks similar enough that that doesn't appear to matter.
I haven't yet tested if there are similar issues when building on armhf/aarch64 on GNU Guix, but that would be an interesting next step...
GNU Guix attempts to normalize the build environment as much as possible, while tests.reproducible-builds.org attempts to introduce as many variations as possible. For a list of changes between first and second build:
It seems that Debian's armhf (ARMv7) platform usually fails to build reproducibly:
https://tests.reproducible-builds.org/debian/history/armhf/guile-gcrypt.html
https://tests.reproducible-builds.org/debian/rb-pkg/experimental/armhf/diffoscope-results/guile-gcrypt.html
The arm64 architecture (ARMv8 64-bit) seems to have reproducibility issues as well:
https://tests.reproducible-builds.org/debian/rb-pkg/experimental/arm64/diffoscope-results/guile-gcrypt.html
https://tests.reproducible-builds.org/debian/history/arm64/guile-gcrypt.html
Other architectures appear to consistantly build reproducibly.
The diffoscope output appears to have identified "wrapNNN-procedure" where NNN is a different number in the two different builds.
FWIW, guile-gcrypt 0.2.x builds with guile 2.2, and guile-gcrypt 0.3.x builds with guile 3.0 in Debian, though the diffoscope output looks similar enough that that doesn't appear to matter.
I haven't yet tested if there are similar issues when building on armhf/aarch64 on GNU Guix, but that would be an interesting next step...
GNU Guix attempts to normalize the build environment as much as possible, while tests.reproducible-builds.org attempts to introduce as many variations as possible. For a list of changes between first and second build:
https://tests.reproducible-builds.org/debian/index_variations.html
Thanks for maintaining guile-gcrypt!
I noticed that as well and I believe the culprit is this old Guile issue, which as we can see now was in fact never completely fixed: https://bugs.gnu.org/20272 . The 'wrapNNN-procedure' symbols you mention come from the 'define-wrapped-pointer-type' macro (in Guile), which uses 'gensym'.
Thanks,
Ludo'.
Hi Vagrant,
I noticed that as well and I believe the culprit is this old Guile issue, which as we can see now was in fact never completely fixed: https://bugs.gnu.org/20272 . The 'wrapNNN-procedure' symbols you mention come from the 'define-wrapped-pointer-type' macro (in Guile), which uses 'gensym'.
Thanks,
Ludo'.
It seems that Debian's armhf (ARMv7) platform usually fails to build reproducibly:
https://tests.reproducible-builds.org/debian/history/armhf/guile-gcrypt.html
https://tests.reproducible-builds.org/debian/rb-pkg/experimental/armhf/diffoscope-results/guile-gcrypt.html
The arm64 architecture (ARMv8 64-bit) seems to have reproducibility issues as well:
https://tests.reproducible-builds.org/debian/rb-pkg/experimental/arm64/diffoscope-results/guile-gcrypt.html
https://tests.reproducible-builds.org/debian/history/arm64/guile-gcrypt.html
Other architectures appear to consistantly build reproducibly.
The diffoscope output appears to have identified "wrapNNN-procedure" where NNN is a different number in the two different builds.
FWIW, guile-gcrypt 0.2.x builds with guile 2.2, and guile-gcrypt 0.3.x builds with guile 3.0 in Debian, though the diffoscope output looks similar enough that that doesn't appear to matter.
I haven't yet tested if there are similar issues when building on armhf/aarch64 on GNU Guix, but that would be an interesting next step...
GNU Guix attempts to normalize the build environment as much as possible, while tests.reproducible-builds.org attempts to introduce as many variations as possible. For a list of changes between first and second build:
https://tests.reproducible-builds.org/debian/index_variations.html
Thanks for maintaining guile-gcrypt!
Hi Vagrant,
I noticed that as well and I believe the culprit is this old Guile issue, which as we can see now was in fact never completely fixed: https://bugs.gnu.org/20272 . The 'wrapNNN-procedure' symbols you mention come from the 'define-wrapped-pointer-type' macro (in Guile), which uses 'gensym'.
Thanks, Ludo'.