Hi, On 2023-04-14 15:06, Vagrant Cascadian wrote: > 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
This indeed corresponds to the default path used by sbuild. > If this were instead a build path such as: > > Build-Path: /build/0ad-0.0.26-3_i386 This does not seems to be possible to include _i386, but /build/0ad-0.0.26-3 is something possible. > I understand that the build path is randomized a bit in order to avoid > collisions with concurrent builds of the same package version. Yes, that's indeed the reason for the default configuration of sbuild, and I guess also in case the same build is ran multiple time consecutively and the build directory hasn't been cleaned. That said we don't do concurrent buildds nor mount the /build partition on the official buildds. This means it is perfectly fine to use a non randomized path. > 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? The official buildds use the sbuild from stable, just with the configuration tweaked a tiny bit to use a big tmpfs for building. > 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? I have tried adding a simple .sbuildrc defining $build_path to '/build' to zandonai.d.o. Unfortunately while it more or less does what you want for the build path, it completely clutter the logs, as any text matching "build" is now replaced by "<<BUILDDIR>>": https://buildd.debian.org/status/fetch.php?pkg=gnome-keyring&arch=s390x&ver=42.1-1%2Bb2&stamp=1681671508&raw=0 I guess one option is to use a build path unlikely to match any string from a build log, like with the randomized directory. Something like "/build/reproducible-path/"? Cheers Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
signature.asc
Description: PGP signature
