On 2023-04-16, Aurelien Jarno wrote: > On 2023-04-14 15:06, Vagrant Cascadian wrote: >> 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
... this would make aspects of reproducible builds easier to verify. >> 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. That sounds good enough to me! (or even without the Debian revision) >> 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. Excellent news; glad to hear this may be very doable! :) >> 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. Ok. >> 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/"? Just for clarity, then the the PKGBUILDIR would end up being /build/reproducible-path/PACKAGE-VERSION ? That works! Or something even shorter ... e.g. /build/path/PACKAGE-VERSION or /build/debian/PACKAGE-VERSION ? Really, the 2nd directory matters little, as long as it is predictible. :) We have noticed various packages (for better or worse) do tend to derive information from the top-level build directory by assuming it is PACKAGE-VERSION; probably good to cater to that assuption. Anything along the above lines sounds good, really! Although once a particular bikeshed is chosen, ideally we should commit to it for the forseeable future! :) Thanks for the quick responses! live well, vagrant
signature.asc
Description: PGP signature
