#1020873 xserver-xorg-video-glide: reproducible-builds: build path embedded in glide_drv.so #1020873
- Package:
- src:xserver-xorg-video-glide
- Source:
- src:xserver-xorg-video-glide
- Submitter:
- Vagrant Cascadian
- Date:
- 2025-04-04 20:15:01 UTC
- Severity:
- normal
- Tags:
The build path is embedded in /usr/lib/xorg/modules/drivers/glide_drv.so: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/xserver-xorg-video-glide.html /build/1st/xserver-xorg-video-glide-1.2.2/build/src/../../src/glide_driver.c:244 vs. /build/2/xserver-xorg-video-glide-1.2.2/2nd/build/src/../../src/glide_driver.c:244 The attached patch to debian/rules fixes this by passing the default CFLAGS to dh_auto_configure. Alternately, updating to a newer debhelper compat level might resolve this as well. According to my local tests, with this patch applied xserver-xorg-video-glide should build reproducibly on tests.reproducible-builds.org! Thanks for maintaining xserver-xorg-video-glide! live well, vagrant
Dear Maintainer, Because Debian builds packages from a fixed build path, neither the 'reprotest' utility in Salsa-CI, nor the Reproducible Builds team's package test infrastructure for Debian[1] currently check for equivalent binary package output from differing source package build paths. This means that your package will pass current reproducibility tests; however we believe that source code and/or build steps still embed the build path into the binary package output, making it more difficult than necessary for independent consumers to check the integrity of those packages by rebuilding them themselves. As a result, this bugreport will remain open and be re-assigned the 'wishlist' severity[2]. For more information about build paths and how they can affect reproducibility, please refer to: https://reproducible-builds.org/docs/build-path/ Thanks, James [1] - https://tests.reproducible-builds.org/debian/reproducible.html [2] - https://www.debian.org/Bugs/Developer#severities
A correction for a mistake in my previous message: Currently the 'reprotest' job in Salsa-CI does in fact continue to exercise variations of the build-path, and will fail if it builds binary packages that contain different contents as a result.
Remove tag patch since the patch does not fully solve the problem