[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Status of Debian Installer Bookworm Alpha 1: 2 blockers

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.


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

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

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.


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
 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!

Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature

Reply to: