Discussion:
live-installer update for Bookworm?
(too old to reply)
Roland Clobus
2023-04-10 08:00:01 UTC
Permalink
Hello images-team,

I've wondered why the installation still takes a long time after it has
finished installing from a live image, as seen on openQA [1].

It turns out that the package 'live-installer' (which is a udeb-only
package) in Bookworm still is at version 57 [2], while the fix was
released at version 58.

Could the package be unblocked? (And/Or will there be an installer RC2?)
The new version of live-installer is working correctly, as can be seen
by a sid build of the live image on openQA [4].

With kind regards,
Roland Clobus

[1] https://openqa.debian.net/tests/139702#step/complete_install/44
[2] https://packages.debian.org/search?keywords=live-installer
[3]
https://salsa.debian.org/installer-team/live-installer/-/commit/ccda07e77f6f2071156941a3c53fd100dcbf5440
[4] https://openqa.debian.net/tests/138478/video?filename=video.ogv
See the movie at 0:50-0:56
Cyril Brulebois
2023-04-10 08:20:01 UTC
Permalink
Hi Roland,
Post by Roland Clobus
It turns out that the package 'live-installer' (which is a udeb-only
package) in Bookworm still is at version 57 [2], while the fix was
released at version 58.
Could the package be unblocked? (And/Or will there be an installer RC2?)
(Yes to RC2, maybe even RC3.)
Post by Roland Clobus
The new version of live-installer is working correctly, as can be seen
by a sid build of the live image on openQA [4].
I asked Jonathan on IRC while preparing RC1 (slightly edited):

[ kibi] highvoltage: I don't think you answered my live-installer question?
[ highvoltage] kibi: I didn't think it warranted an unblock
[ highvoltage] kibi: but if it did for roland's changes then he could file one
[ kibi] highvoltage: ok, ta

Besides the obviously missing `dch -r` call (“Mon, 15 Apr 2019” was
quite surprising for something uploaded in March 2023), there are lots
of changes that are nowhere suitable at this stage of the release
process.

That plus Jonathan's answer triggered my deciding against unblocking the
package on my own (with my d-i release manager hat). That being said, if
the release team is willing to unblock the package as is, that'd be fine
with me. I suppose it'll be suggested to cherry-pick the desired
change(s) and to upload 57+deb12u1 via tpu, or to back out the undesired
changes and proceed with 59 via unstable. (Both are fine from a d-i
point of view, as long as the package reaches testing in the end.)


Cheers,
--
Cyril Brulebois (***@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Cyril Brulebois
2023-04-10 09:30:01 UTC
Permalink
Aside from Janitor, modernisation and lintian corrections, my change was the
only functionality change in four years (as seen by diffoscope, see below).
Maybe, but one shouldn't have to resort to diffoscope to figure this out
at this stage of the release cycle.
There is no autopkgtest, but the openQA run for sid shows that the change
has its intended effect.
If I had known that I would need to file an unblock request, I would have
done so, but the timing (patch, merge, release) was rather unfortunate.
OK.
It is certainly not a release critical issue, but I personally find it quite
annoying to have to wait about 30 minutes for the installation, and then to
read 'Installation is complete, so it is time to boot into your new system',
press a key and then wait another 2-3 minutes before the reboot is actually
performed, while the additional waiting time could have been incorporated
into the longer non-interactive phase.
Looks like unacceptable/silly delay to me, esp. if a fix is already
available and has been confirmed to have the right effects. Please get
in touch with the release team to get that fixed in Bookworm.

(This reminds me of avoiding one update-initramfs call for each firmware
package installation, meaning 1+ minutes instead of 10-15 seconds): I
didn't file a bug report for it, so I'm not sure whether I would have
called that serious or important or something else, but that's definitely
something that's annoying enough and easy to fix that I'm happy to fix
even if it doesn't exactly follow the letter of the freeze policy. But
several minutes? Even stronger feeling towards getting the fix merged.)

Disclaimer: I haven't looked at the diff.


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