On Wed, 26 Oct 2022 at 14:54, Luca Boccassi <bl...@debian.org> wrote: > It seems debuerreotype has an autopkgtest that rebuilds Stretch with a > new toolchain, compares it to a fixed version and fails if it doesn't > match. But I don't see how this can be supported - if the toolchain > changes, then the result is also not expected to be the same? > This is why for reproducible builds the toolchain is recorded in the buildenv? > > This is going to block debootstrap's migration to testing, so I will > bump the severity soon if we can't find a workaround. > > Example: > https://ci.debian.net/data/autopkgtest/testing/amd64/d/debuerreotype/27484986/log.gz
Yeah, this is the same issue as what I noted in https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/70#note_343328 -- I don't think the break in reproducibility of the output of debootstrap was _intentional_, but rather accidental (especially from xnox's comments there where it seems he does want to support *some* amount of reproducibility). I'm happy to adjust the debuerreotype test based on the updated debootstrap if the break was intentional, but IMO it's worth at least a _little_ root cause analysis first, right? (especially if there's any chance it might change back again) I'd have had the same break if I'd updated this autopkgtest to use bullseye or even bookworm (which I didn't do specifically to avoid the extra space of storing the originals on people.debian.org unnecessarily). Updating this over time is going to be a fact of the way debuerreotype works (necessarily), but it is the first time I can remember in the last five years of maintaining this tool that I've had such an instance that wasn't an intentional break (like merged-usr, for example, which is pretty easily manageable to maintain backwards compatibility with, unlike this break where I can't control debootstrap's behavior). Generally when I use this tool for generating the Docker images, I do now record the debootstrap version (https://github.com/debuerreotype/debuerreotype/pull/139) so that anyone looking to reproduce my results can match my environment if necessary (although I'm realizing that version number isn't included on https://docker.debian.net/ so I'll be updating that soon). ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
