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 (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature