Source: buildd.debian.org Severity: wishlist User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath toolchain X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Thanks for maintaining buildd.debian.org, which consistently cranks out countless builds of packages that I and many others use! We had a bit of a discussion in in the #reproduciblebuilds channel about build paths, and it occurred to me that if buildd.debian.org used a predictible build path. Build paths are one of the larger sources sources of reproducibility issues(~10% of the archive are still affected), and while the workaround is relatively simple (build in a chroot with the same build path), not having to do so would be very helpful! For example, a build of 0ad uses a randomized string in the Build-Path: https://buildinfos.debian.net/buildinfo-pool/0/0ad/0ad_0.0.26-3_i386.buildinfo Build-Path: /build/0ad-al23I5/0ad-0.0.26 If this were instead a build path such as: Build-Path: /build/0ad-0.0.26-3_i386 I understand that the build path is randomized a bit in order to avoid collisions with concurrent builds of the same package version. Just the fact that it is recorded in the .buildinfo is certainly helpful and makes it possible to reproduce a build after the fact, but being able to predict the used build-path would allow performing builds concurrently (assuming they were pulling from the same package mirrors). At least some sbuild backends (unshare mode) can provide an independent /build directory for each build, avoiding the risk of collisions. My understanding is buildd.debian.org uses a variant of sbuild? I think I could probably come up with a way in sbuild to configure a unique /build directory using bind-mounts to a randomized directory, if that would be helpful. Other approaches might involve using mount namespaces? live well, vagrant
signature.asc
Description: PGP signature