Here's a quick update about my current plans regarding the installer and
regarding debian-cd dry runs.

(Trimming recipients; also, I'm using 12.0.0 below as I'm referring to
the version identifier on the debian-cd side, but that's hopefully
synonymous with Debian 12.0, i.e.  the initial Bookworm release.)

Cyril Brulebois <k...@debian.org> (2023-05-24):
> I might pick a last minute tasksel change as well (for lxqt); I think
> it would help, could break, but that would be trivially revertable
> (and there would be room to do so, see below).

I did that, didn't hear bad things about it, be it from users or

> Checked with Salvatore: still no upload planned before the release.

I've asked Salvatore to update me on this one, but I haven't heard of
any changes in that area at the moment.

> I think I'll go for this one, aiming for May 25 or May 26 unless some
> issues pop up.

Details disagreed so that ended up being May 27 instead, but close

> We know we have at least the apt vs. adduser issue that's going to get
> resolved, and I'd prefer not to wait for it, and also not to rush the
> update into testing…

That migrated after the release, and will be part of pseudo-RC 5 and
more importantly 12.0.0.

> Also, we might have other packages that directly (because they produce
> udebs) or indirectly (because they're installed on every system, like
> apt) affect the installer or the installation process… migrate to
> testing later on.

Last packages that migrated (that I know of) are openssl (CVE fixes) and
libselinux (+b6 to minimize ESO). I'd be happy to be kept explicitly in
the loop for any further updates to udeb-producing packages (it appears
unblock-udeb does the job, including for binNMUs…), or things that the
release team would identify as being part of a standard installation, so
that we keep as many eyes open as possible…

> Let's consider a last debian-installer(-netboot-images) upload once
> Bookworm is definitely frozen, maybe a few days before the release to
> minimize the chances of having to consider a last-minute critical
> bugfix. Once it's in testing, we could even build images like we would
> for “D-I Bookworm RC 5”, just to be on the extra safe side. Those could
> be fetched by testers, but wouldn't be signed or announced (keeping them
> in the “usual dot directory”, deleting them a few days later). That
> would give us some extra peace of mind for the actual 12.0.0 images
> build that will happen on release day.

I plan to work on that mid-week, sometime on Wednesday (ideally, unless
we know more packages need migrating…) or Thursday (as a fallback). I'll
check with other debian-cd members, but I might even try and see how a
full build would work, so that we have some kind of advance knowledge
regarding the following week-end.

At the moment I've spotted three uploads:
 - apt-setup (1:0.183), for ports architectures.
 - preseed (1.118), for Hurd, even if the changelog is not quite verbose
   about that part…
 - vte2.91 (0.70.5-1): new upstream (bugfix) release with no particular
   bugfixes identified.

Unless specifically requested, I don't plan on including the first two
before Bookworm because we don't need it for release architectures. I
/think/ hurd-i386 gets somewhat released from unstable, so that
shouldn't matter… not sure about ports architectures. Those /could/ be
considered but truth be told, my default setting is: only change what is
absolutely required before Bookworm. vte2.19 seems quite vague, and
ignoring it entirely should be fine.

Since there was good progress on the arm64 console thing (#1036952), and
considering the current results of the investigation as to where vt102
comes from, and why arm64 isn't quite the deciding factor (a busybox
limitation instead), I'd be happy to consider getting an updated
rootskel for migration before pseudo-RC 5 and 12.0.0. Such an upload
would need to happen quickly though… (ema bcc'd, as possible uploader,
no obligations though!).

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

Attachment: signature.asc
Description: PGP signature

Reply via email to