Hi, 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 <kibi@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 maintainers. > 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 enough. > 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!). Cheers, -- Cyril Brulebois (kibi@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature