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

Kind regards,
Luca Boccassi

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

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

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

Control: severity -1 serious
Control: justification -1 breaks autopkgtest in testing

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

Sorry, this was my miscommunication!  I'm totally fine with this bug
being RC if that allows debootstrap to transition and unblocks others
(I probably used the wrong terms in my previous email).  Thanks for
following up!

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

I'm sorry, but I must admit to being a little bit confused by this --
why was this a whole new bug instead of just a comment on #1022854?

(and why wasn't there any attempt to communicate about why it's urgent
for you before the NMU, especially with such a short delay?  is there
a particular reason you're doing this?  I can guess at your
motivations, but it sure helps if they're written somewhere 😅)

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Given the timezone differences, I've dcut cancel'd the upload for now
(assuming that gets picked up correctly and I didn't mess something
up).

I'm not opposed to the change (or even it being an NMU), but doing so
without a discussion doesn't seem right and I'd like to understand
what the end goal is better and why it's urgent enough for you to
upload with a DELAYED/1 NMU. 🙇

Thanks!

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

That was my fault when submitting it, I was not closing the bug
(since it is only workarounded) so "nmudiff" created a new bug.

The urgency is the freeze deadline, I am currently going through
packages that would miss bookworm if they aren't fixed.

cu
Adrian

Thank you for explaining!  I don't love disabling the test just for
transition, but I suppose it's reasonable.  I've re-uploaded the NMU
changes for now (and committed them to Git).

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4