On 2020-12-28, Nick Black wrote: > Hey there Reproducible Builds team! > > I'd like to make my package "notcurses" reproducible. First off, > I love the interface at > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/notcurses.html, > the clearest output I've seen yet from diffoscope(?). > > All my differences seem to be due to small changes in dynamic > symbol sizes. See for example data.tar.xz's 'readelf --wide > --dynamic {}' output: > > 18 ·0x000000000000000a·(STRSZ)··············3446·(bytes) > 18 ·0x000000000000000a·(STRSZ)··············3450·(bytes) > > What might be causing these symbol sizes to change?
Since it seems to historically consistently build reproducibly in bullseye, my first guess would be that it is build path related; build paths are not tested in our infrastructure on bullseye. In unstable and experimental we do test build paths, but also pass DEB_BUILD_OPTIONS=reproducible=+fixfilepath, which passes the -ffile-prefix-map=BUILDPATH=. argument, stripping the build path, but sometimes leaves traces; the length of the build path is different (e.g. /1/2/3 vs. /1/2/3/4), so it leaves a different amount of padded/empty space. Does notcurses use __FILE__ macros anywhere (either directly in the source code, or indirectly via some other build system)? Something along those lines would be needed to completely fix the issue. > I also have some _NT_GNU_BUILD_ID changes, but I think I can > handle those myself. Thanks! The build id will most likely be a result of any differences, such as those above. Thanks for asking about reproducible builds in notcurses! live well, vagrant
signature.asc
Description: PGP signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
