XPost: linux.debian.maint.boot, linux.debian.devel.release, linux.debian.kernel

Hi all,

Current status
==============

Some of you might have read bits and pieces here and there, but I
thought I'd share my plans a little more formally with some teams.

As anticipated, it seems the last bits from the release team on dda@ got
some attention, and we've been receiving many more installation reports
than previously. Some of those reports are directly actionable, and
various fixes are flowing in a bunch of components; some of them trigger
some kind of chain reaction, and might end up leading to fixes via a
point release instead.

Installation reports have been mostly positive, and I'm not aware of any critical bug that would jeopardize the proposed timeline. \o/

For those who want to follow at home, I have a list of things I'm
tracking and that might be fixed or at least considered before 12.0.0;
nothing is mandatory in there!
https://salsa.debian.org/installer-team/debian-installer/-/issues/1


Proposed plan
=============

I think it'd make sense to have at least 2 releases:
- 1 around mid-May;
- 1 around end of May.

The first one would bundle a bunch of the fixes or improvements being
worked on these days, making sure everything works as intended. The
second one would be an “everything is frozen, we upload d-i one last
time” release, which could include a few last-minute fixes or
improvements if required or desired.

This means we should be able to pick whatever linux kernel is in testing
for the first release, while the kernel team prepares the final linux
upload on their own accord, which we'll pick up with the second release.

Communication and dynamics between the installer and kernel teams are well-established and give good results, see earlier discussion:
https://lists.debian.org/debian-kernel/2023/05/msg00031.html
https://lists.debian.org/debian-kernel/2023/05/msg00043.html

Salvatore had good questions about how to best handle possible critical
fixes (security or otherwise) during the last few days, and whether bookworm-security would make sense if that happened. On the installer
side I'm happy to work with whatever ends up in testing (via unstable or t-p-u), but we don't currently support building or running d-i against
security suites (the former is probably trivial, the latter might be
very tricky). I'm also not sure how going through security would factor
in when it's time to build final images (12.0.0). But maybe we can think
about it if and when we actually encounter such problems.

I'm happy to touch base with the release team again when we approach end
of May, to see what would be considered best for the (hopefully) final
d-i upload (and d-i-n-i, at least a dinstall afterward). It might make
sense not to wait too much before doing so, in case we end up having to
fix a package or two, and re-upload…

Regarding the final release, I'm happy to perform a final d-i upload if
some packages needed an update since RC 4… but hopefully the last build
can be reused without any changes.


Interactions with other teams
=============================

You might have noticed the `dak copy-installer` step that copies the `installer-<arch>/` directories from unstable to testing is now
something that I can trigger on my own, which gives us some appreciated flexibility: contrary to point releases that are planned and frozen in
advance, testing keeps evolving (less so with the freeze progressing)
and I couldn't really set fixed dates in advance so that various teams
would be on stand-by…

The other major team involved is debian-cd, and Steve and I usually come
up with a set of days where both of us are available, and image building
starts whenever the right bits have reached testing (the d-i package via britney, the `installer-<arch>/` directories via dak).

I've been in the debian-cd group for a long while, but I've only been
taught a crash-course recently on how to operate a d-i release and I
should be able to operate one or two on my own.

[ In the context of debian-cd, I'm calling a “d-i release” one of the “D-I $CODENAME Alpha|RC $N” releases; as opposed to initial stable
releases (e.g. 12.0.0) or point releases (e.g. 11.7.0), which involve
more work, lots of testers, the press team, etc. I wouldn't call myself
ready for those just yet… ]

This gives me a little more work but also some more flexibility as to
when RC 3 and RC 4 happen.

A side-effect, with regular d-i builds and live builds being started
together when building images for a d-i release, is that I'll have to
keep an eye on the live images as well. As mentioned to Jonathan earlier
this week, my focus has only ever been on d-i itself (which keeps me
busy already, and I'm not trying to wear yet another hat), and that
shouldn't change in the near future, but I'm more than happy to keep an
eye on debian-live needs, and wait for an extra package or an extra
commit in live-setup.git before starting building images for a d-i RC
(see things like #1035360 and #1035560).

I don't think I'll be actively polling debian-live for input though; I'm
more than happy to be told what is important (so that it can be tracked
via the Salsa issue mentioned above, or one of the “point release variations”, see issues 2 and 3). I'm usually sharing progress towards a
d-i release on IRC on #debian-boot, before moving to #debian-cd. I know
at least Jonathan is present in both channels so we should be good; I'm
happy to consider alternatives if needed though.

Back to d-i, we have the release announcements going to dda@ and to the website, and I'm autonomous on both counts as usual. For the final
release, I'll step back (even if d-i gets a final upload), and let you
folks organize the Bookworm announcement.


Conclusion
==========

I'm happy to answer any questions you might have, and to amend my plans
if you'd like some things to be done differently. Thanks for your time
and attention, that's quite a long mail… With the release approaching,
I thought it'd make sense to be as explicit as possible to make sure
everyone is on the same page.


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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmRV2YYACgkQ/5FK8MKz VSAtUBAAo0sLQJVsaiQYWRKfvIXOXfUk/JGeX9L2q6ZTiHY68EgPA81NYY124wwI 2312x6kJtPk0KvZGfEVVPrqlHP06u7hAlMeAG8S7jZ0LCUnAeZcoP+AW1Bass/e/ cY9o6HLWC077B04DBZDHJEgT5DRMGZYcEVPVR3uwTAQsFp1Ab8BO1xFDQYJ8qrcV 0MMtsuVyA/je+IuqsRqR3O9grDyaXkBD4EhdnjzPtv88G01ZZQZ6rvxI/ihLnE/q QUnKbXiSDdHJ7f4aMsIn6LeEtAyEh70HwwT1AvT+S5BpdErVzaG5Nrq3hsGDzEHI YvEkGQebN4jcwAZGIxg5IxYSlVP2IJ0wKJ6L32gzILJSEm8O8uw2AvIi9HXmyfSV WYyxiHgxbB04zopnGQ23VQObDbUwMUXnhXcxcS1zplmgsLUZ5SiXVwVIu9jzf1sy 7HUFfk2dz4o7AZiydzVPeaXamJgXxUy9SUVUvZ/4pjYWDwgEz2CwtIHNPAqMLL4A KoG7Dy0jHstCvCK/GDcWCysSm16JTf0M9hf7wiSeZeF/s+E24QeQpdlhwCTGWjji HcGIE7L8xaCqeICXgdsRaR0iYcWMx/GjkzyEXSklgjzUUXTBEZsLYbBPqUY578YV zEc2bjrm6jbtM+TSBM+i6FavYekQJizOpo4eC58Xzw52jypGLDY=
=jcQp
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

XPost: linux.debian.maint.boot, linux.debian.devel.release, linux.debian.kernel

Hi all,

Cyril Brulebois <kibi@debian.org> (2023-05-06):

I think it'd make sense to have at least 2 releases:
- 1 around mid-May;
- 1 around end of May.

The first one would bundle a bunch of the fixes or improvements being
worked on these days, making sure everything works as intended.

This part has happened as planned.

The second one would be an “everything is frozen, we upload d-i one
last time” release, which could include a few last-minute fixes or improvements if required or desired.

And that part I'd like to plan a little more.

I'm happy to touch base with the release team again when we approach
end of May, to see what would be considered best for the (hopefully)
final d-i upload (and d-i-n-i, at least a dinstall afterward). It
might make sense not to wait too much before doing so, in case we end
up having to fix a package or two, and re-upload…

Dates that have been announced[1] so far:
- 2023-05-24: full freeze
- 2023-05-28: last moment to file unblock requests
- 2023-06-03: bookworm totally frozen
(per “last week prior to the release”)

1. https://lists.debian.org/debian-devel-announce/2023/04/msg00007.html

On the d-i side, we'll have a round of translation updates[2], along
with some last tweaks, before RC 4.

As far as I understand, at least at the moment, we aren't expecting a
new linux upload before the release. But if the need arises, we should
be able to deal with it.

2. https://lists.debian.org/debian-boot/2023/05/msg00250.html


I'm not sure what the best timeline would be for RC 4. Let's consider
two options:
- After the full freeze is in effect: we would have RC 3 and RC 4
roughly two weeks apart, which matches what I had in mind initially,
but we might have a few more changes coming in via late unblock
requests, that could impact the installer.
Example: May 25.
- After a green light from the release team, i.e. once all unblock
requests have been considered, and once it's expected there should
be no changes in the archive.
Window: May 28 - June 3.

In the first case, we would have a little more time to sort incoming installation reports, and to react if needed. We might need a final
upload of debian-installer(-netboot-images).

In the second case, we would have a little less time, but the message
in the release announcement could be a clear “there are no more pending changes for bookworm, this is the closest thing to the release, please
test extensively” (better wording welcome). We would probably not need a final upload of debian-installer(-netboot-images), with debian-cd
picking up the exact same files that were used for RC 4, for the final
release.

Both options seem equally reasonable to me, please let me know whether
you have a preference. I don't need an answer right away, that can be
discussed during the upcoming release team meeting.

(If we go for “d-i/d-i-n-i are the last packages changing in bookworm”, please keep in mind we need at least 1 britney run and 1 dinstall run
between the d-i upload and the d-i-n-i one.)

Regarding the final release, I'm happy to perform a final d-i upload
if some packages needed an update since RC 4… but hopefully the last
build can be reused without any changes.

No changes there, I'll be on stand-by for anything d-i related until the (tentative) release date.

Interactions with other teams
=============================

[ kibi does dak copy-installer ]

That was confirmed to be working fine while preparing RC 3.

[ kibi does debian-cd ]

That was also confirmed to be working fine while preparing RC 3.


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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmRpy7UACgkQ/5FK8MKz VSAOzhAAgpTEwOk0tp46WZTRMqFrjLizp0cnM8wuawiO7utlMzUgR4xuND1PYnp3 1+Mn5BwAsZEVzoUpqB3YwKMaWLHSlz6oits94UzQhr82KQo1BMQBl/7d192r6SgO i1laKkuSulPNxNcSgmmexz1VUBPXH25+X7S1BhGWscLQgB0KS7YTeWANBozZ4mj8 5SpRWyjXH19Mtzf1wXUCi3JJbekiS9XOAMIEsoC5MmkQHpyMzvGBq+V9zkHLtNcs eGqgFyhxiGNCXOz9zopLaKjmzSK98F46luxQFxhhlbgbdSl7hPqnx/IkZrYeFCXu H4COJ8Miva65tbAoc3WpyzizUJG3fziLsLKAk+QpEzndiV1BO82H+dUSQiM5O42T QovTsqEnKeXugD8FtveMK6gmS0jGSiKjlwnKSpzxW04HOkd4TpZVk/Qn+8zAV6Wi NR4crPiyB1jawGxYRxBctpGQRdyZA+JMxc0Cp0QdXGrZYJ137ULq/73HKvuvgTBA 4ZwfkPSYP8jQjRSl9JeujYQloLemctLNst0/vR+MwyFCTfuGRUwJxK9MNVbEmAVm 8lvey6GdcU/vs8r7/172+vxGCCR3/Q25U5nHw6+xAIWJ0Xbd19/7Cns5i9/qOMzW Kj5NpRXi2G2mxLgn1uwe+OW2FsEq4a7PeRk4zyJxBkeVcnedyzU=
=H1tX
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

XPost: linux.debian.maint.boot, linux.debian.devel.release, linux.debian.kernel

Hi all,

Cyril Brulebois <kibi@debian.org> (2023-05-21):

Dates that have been announced[1] so far:
- 2023-05-24: full freeze

[x] ← You are here!

- 2023-05-28: last moment to file unblock requests
- 2023-06-03: bookworm totally frozen
(per “last week prior to the release”)

1. https://lists.debian.org/debian-devel-announce/2023/04/msg00007.html

On the d-i side, we'll have a round of translation updates, along
with some last tweaks, before RC 4.

We should be all done in a few hours.

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).

As far as I understand, at least at the moment, we aren't expecting a
new linux upload before the release. But if the need arises, we should
be able to deal with it.

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

I'm not sure what the best timeline would be for RC 4. Let's consider
two options:
- [Soon] Example: May 25.
- [Later] Window: May 28 - June 3.

No preferences have been expressed by the release team during today's
meeting.

In the first case, we would have a little more time to sort incoming installation reports, and to react if needed. We might need a final
upload of debian-installer(-netboot-images).

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

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…

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.

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.

It looks to me this would combine the best of two worlds:
- Not wait too much before RC 4, leaving us some more days to deal with
incoming reports;
- Minimize risks of merging final changes in Bookworm, by having this
“canary” RC 5 release.


Notes:
- This would be different from what we did for Bullseye, where we had
an RC 3 built using debian-installer 20210731, which was then reused
as is for the 11.0.0 images build.
- This would be different from what we did for Buster, where we had
an RC 3 built using debian-installer 20190702, which was then reused
as is for the 10.0.0 images build.
- Given each D-I release is “lighter” than a full release build (be it
for an initial release or a point release), it seems to me going for
RC 4 plus pseudo-RC 5 is cheap enough to buy us peace of mind than
delaying RC 4 until we think (but still aren't sure) nothing is going
to change in Bookworm.
- Release early, release often! (even if late in the release cycle…)
- I'm doing most of the work anyway…


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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmRuekkACgkQ/5FK8MKz VSDBwg//aOEvR0KIsleDGpBHkEHqG/Zl/39/mLFmgKAlj5I6o3KDOL6Hqieiqxqq F2QqRCQPhEHNoq+8oO+uCHWIn4HRP7j+hxxdepq65/LyiAM/ZM7zJKpfqGOM5biS BINmd0Cx5El0/XxBba+LviK1e8+5gAy3PIEk+G49RLcn6baPqL93C7vFzd5+IW/M fv5kbhpcXjA0O23YaaP/qubNV/vC54IeW1f1Ppk/FLKWDgWeI7DCzN6xxF7XGFzS 0xUXjc4qbGG4EliKsnd1rWEnvYjmjDMFFkOptxlS5dUmu/7jC+Ar076wVqgn32IH mZozMle/DDLM0dRRg9KXH+61SzCi09CF8z71rfa7yx2AQRkIG9aH3mr+exjp5yfU LyTfRjz5d5vWZ6ttf/enTfDRwg8hSzVdXM4SBCdithg2rudEKGd/tT0JGGrMm3vq ckGdwbEQ5M6OrgmSJzm7IAOyoPzoFdTy6LPD64nBHmgORksvZ5g8CLE3bTTXBaph XmDrJaNJhcmXvEFWsKtS/4Mz3v4cCjAWZSCJWlWJlGp+CkGfQVz6Uk+pHQI8dGRb YT0ZxrU9YQO/pr8Uc9FJLv5Op4b+4dqb4nOQRQGzEW2Kxm+6X/DZ4/2XXZQ7D+TT cDNLbrk4B2B9Gow2UegjNYa8TZhXRd4w+7j/uBnnmFhPtHU2GPQ=
=fjKB
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

XPost: linux.debian.maint.boot, linux.debian.devel.release

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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmR7gUUACgkQ/5FK8MKz VSCUGQ/+Ki3tGQFILELc2H5ulMfkYSdEKZFFvpexxEvMmkMgN5N5LBpS4tt5cw5P YS+MbyvUhMQCKHaJ7WNjcf7dWK78F8FfqyakN0p/d9xNtVnc/4R5GlARLrcUd6Cx MtVI9X51EUVCD7jyueZCzI69Lf8B91W0xs1JkYWKpXyqoQAHM8vKqbnliSJ5HzW9 mCWIDku1vfW6IB5hh+B2cEmfdsTJp61GxPacW6wFvHpO/oO0UKB3pf6FzCKpnno1 EuvezO/3GA0Zd9mRxBVOtgezvAPDhmiudLtFCyN4AjcUFe9Rf9SBlQ6nYLogFFf+ M64QHVKSS3+v2HYYQNw5LsRJ1621yqvcEEfFc7ZF/eKMcc3xk2UJLRW97xGXdnBg azvMmg8VRKndAO8E9/Lv5ixoCJ7tNXw+aMnmLUD+iEYFFZDB9y9dAO4rKSHerWbt L+dJutdDc2ECyTEZ8FFueAHFxiEYCeDTCkjYH+C+kCfbBzfyTijzwCIXsndT57Gz 1+9ty+t0y82BDk869WOuL/wORp4WffuHOfcxYkaGgqct4YWzo6LVKiUZlrZrr8Ko OwxAkzAJ8phSFo9SevViYtNvYF8UoZAv05ICCeSY6yfHltooc9f2/P0WAoztjX8w lGSOgWxRqoO3fk3/m0qLChvoJ4Amo6R0JdvfNgSfMcV9j4pVRi4=
=xh5O
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

XPost: linux.debian.maint.boot, linux.debian.devel.release

Hi,

Cyril Brulebois <kibi@debian.org> wrote (Sat, 3 Jun 2023 20:07:05 +0200):

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.

I have just uploaded grub-installer 1.194, which completes Croatian and Ukranian translation.
Feel free to include it in bookworm, if possible.


Holger

--
Holger Wansing <hwansing@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.maint.boot, linux.debian.devel.release

Cyril Brulebois, le sam. 03 juin 2023 20:07:05 +0200, a ecrit:

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…

Yes.

not sure about ports architectures.

Ports don't have a testing either.

Samuel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.maint.boot, linux.debian.devel.release

Hi,

On 2023-06-03 08:07, Cyril Brulebois wrote:

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

I see that Samuel took care of the rootskel upload. Thanks!

ema

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)