Hi folks,
As you might know, the installer is prepared this way:
- debian-installer YYYYMMDD uploaded to unstable;
- a debian-installer-images tarball (one per arch) gets generated
during the build and gets unpacked into installer-<arch>/ directories
for unstable (scripts/debian/byhand-di in dak.git);
- we ask the ftp team to copy-installer YYYYMMDD, to get those copied
for testing (dak/copy_installer.py in dak.git);
- debian-installer migrates to testing via britney.
Currently the last step is blocking. Britney reports two issues:
1. debian-installer unsatisfiable Build-Depends(-Arch) on ppc64el: grub-ieee1275-bin:ppc64el [ppc64el]
2. Built-Using: debian-installer u-boot
Let's dive in!
(1) cross building
I'd like to thank Frédéric and Samuel for being interested in cross
building, but it appears the directives introduced in the following
commit aren't supported by britney, and were considered inappropriate
when I asked about it on #debian-release. Johannes and Helmut suggested
contacting debian-cross@ to get better ideas.
https://salsa.debian.org/installer-team/debian-installer/-/commit/23e4451d7132e3bac7bd589747a44a776ea69834
Grepping around in Sources, I could only find u-boot using a similar
syntax, but only for Build-Depends that are annotated with a cross
profile, which might explain why britney hasn't considered that to be an
issue.
To get back on track with the release, I'm tempted to just revert that
commit right away, and to ask interested parties to submit a better
patch for consideration after the release. That would just mean a new
upload, that would be the easy topic…
(2) u-boot
debian-installer registers a number of packages via Built-Using, to help
keep source packages around (for license compliance mainly, I think, but
I'm definitely not an expert there). Since it's built in unstable, and
since it build-depends on u-boot, it ends up listing that particular
version.
Right now, u-boot looks like that:
u-boot | 2022.04+dfsg-2 | testing | source
u-boot | 2022.07+dfsg-1 | unstable | source
And there's an RC bug to prevent its migration to testing until it's
been tested on various boards. It's a critical component at boot-time so
I'm quite reluctant to even envision a severity downgrade, esp. since
first reports are not encouraging. Vagrant also mentioned that more
recent versions aren't looking better.
https://bugs.debian.org/1016963
What are the options at this point (forgetting about the first issue
for a moment)?
A. Force debian-installer into testing, breaking source compliance?
Looks like a rather bad idea, at the very least from a legal
standpoint. There might be other technical consequences, but anyway:
we would be using u-boot bits that are known to be bad for some
boards…
B. Go for a 2022.07+really+2022.04-like version in unstable? Looks
like extra work for Vagrant, and confusion for everyone.
C. Upload debian-installer via testing-proposed-updates (tpu)? I'll
focus on that option in the rest of this mail, but feel free to
propose anything else!
I think we discussed that possibility a few times, but a quick look
into dak acceptance notifications, we only used that to upload d-i
components via tpu, not the debian-installer package itself.
A few questions I can think of:
- Is that a good idea in the first place? I think so, sidestepping
temporary issues in unstable looks like a valid usecase? But
maybe option B would just be better?
- Do we have tpu set up dak-wise/chroot-wise/sbuild-wise already?
- Would dak be happy to accept the relevant tarball? A quick look
at scripts/debian/byhand-di suggests it should.
- Would dak make it possible to copy installer-<arch>/ from tpu
to testing? A quick look at dak/copy_installer.py's usage suggests
its takes source and destination parameters (defaulting to unstable
and testing respectively).
- Would it be OK to use a higher version in tpu than in unstable?
We have constraints on the version numbers (in dak), and I think
we should be able to use 20220914~deb12u1 but we're really
considering fixing 20220914 with 20220917 (or so) instead, and
relying on an extra/hopefully final prop-up (as done during point
releases…) might be more straightforward.
Thanks for reading up so far, and for any advice on the way forward!
Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature