On Thu, 27 Oct 2022 at 00:33, Tianon Gravi <tia...@debian.org> wrote: > > 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. ❤
I am afraid I will not have the time to debug this, it is not my change and I am not a debootstrap maintainer, sorry. Adjusting the tags to let debootstrap migrate sounds fine to me, but I wanted to ensure the debuerreotype maintainers are aware of this. Kind regards, Luca Boccassi
