Control: severity -1 serious Control: justification -1 breaks autopkgtest in testing
On Thu, 27 Oct 2022 at 13:31, Luca Boccassi <bl...@debian.org> wrote: > > 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. Hi, I have asked the release team to nudge the migration, but they rejected the request and instead said to bump the severity. Sorry about that. We need debootstrap to be unblocked. IRC log of the conversation: (13:16:45) bluca: hello release team, may I ask for a migration hint override for debootstrap, please? debuerrotype's autopkgtest has an issue that is being looked at (#1022854) - TIA <...> (18:20:58) elbrus: bluca: I'm not aware of a need to rush debootstrap. what's the urgent need? (18:22:49) elbrus: normally we wait until the autopkgtest regressing test is autoremoved, but I see that the bug you filed isn't even RC yet (18:23:45) elbrus: (urgency of the uploads is even below the default, so it can't be in that much of a rush; no Debian bugs being closed even) (18:24:09) bluca: it is blocking josh work on mmdebstrap (18:24:22) bluca: and it brings a fix I'd really like to get backported to stable releases (18:24:47) bluca: there is no indication the debuerrotype issue will be solved any time soon - it is unrelated to any of my work, I'm not even maintainer of either packages (18:25:23) bluca: urgency was set to low to be extra careful and see if there were any issues (18:28:05) elbrus: ack, raise the debuerrotype's bug to RC (18:28:12) elbrus: and it will be autoremoved (18:28:19) elbrus: unblocking the migration (18:28:25) elbrus: that's the usual process (18:32:13) bluca: the debuerrotype maintainer explicitly asked not to, and instead to ask for a migration hint (18:32:46) elbrus: we'll not do that (18:32:58) elbrus: as the autopkgtest regression in testing is RC Kind regards, Luca Boccassi
