On Wed, 26 Oct 2022 at 16:03, Tianon Gravi <tia...@debian.org> wrote: > 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)
Also, just to be extra explicit, I have no problem with you adjusting tags however necessary to get debootstrap to migrate in spite of debuerreotype -- I don't want to hold anything up unnecessarily. ❤ ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
