In addition to verified publishers being indicated by a check-mark, we
now have starred publishers indicated with a circled star.
If unicode support is not available, for instance with serial
connections, we use a different number of stars to represent:
* verified publishers: 2 stars
* starred publishers: 1 star
* others: no star
Because our mechanism to substitute unicode characters with ascii
equivalents expect a 1:1 mapping, we cannot simply replace the circled
start by two stars. To workaround the issue, we added a narrow
non-breakable space.
When support of unicode is available, this character shows up as a
normal space.
When support of unicode is not available, it gets replaced by a star.
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The following commit added an unconditional return statement in the try
block of _move_screen, effectively making the associated else block
unreachable.
a7bcc7fa add a way to wait for something with notification after 0.1s
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
The make_ui() function / coroutine returns a BaseView (i.e., a
screen to display to the user).
That being said, when the application calls, make_ui(), it does not come
with a guarantee that the view returned will be displayed to the user
immediately.
One of the reason is that there are multiple await statements before the
we call the ui.set_body function. Therefore, tasks running concurrently
cannot reliably expect that they execute after the display is refreshed.
Perhaps more importantly, when the make_ui() function takes more than .1
second to execute, we display a "Progress" screen that stays visible for
at least one second. This can effectively delay a lot the moment when
the view returned by make_ui() is shown to the user. A lot can happen in
the meantime.
As the result, the view returned by make_ui can be outdated by the time
we show it on the screen.
One way to work around this problem is to store in the controller a
reference to the view that it returns in make_ui(). This way, the
controller can modify the view and keep it up-to-date until it gets
shown to the user.
Unfortunately, some controllers (e.g., the storage controller) do not
modify / mutate the existing view object when a modification is needed ;
but instead instantiate a new view object.
This patch introduces a level of indirection that can be used by these
controllers. Instead of returning a view object from make_ui(), the
controllers are now allowed to return a callback ; which in turn will
return a view object.
https://bugs.launchpad.net/subiquity/+bug/1968161
Signed-off-by: Olivier Gayot <olivier.gayot@canonical.com>
* locale - let it check interactive-sections again
* Turn Serial into a whole new screen
When in serial, first offer the rich/basic choice (or SSH button),
and only show the current welcome screen if we choose rich mode.
Add a back button on Welcome if we are on serial.
LP: #1919251
This fixes a problem where you drop to a shell and refresh subiquity
from that shell -- the client tries to restart but it is running in the
background and so crashes trying to modify the terminal settings. So
this kills the subprocess before restarting. This required the extremely
angry PR I sent before: forcefully killing the subprocess also crashes
the client before restart in a similar way.
Here is something you can try with a live server installer today: drop
into a subshell and type "kill -9 $$". The installer will crash with an
'Input/output error' from tcsetattr.
What's going on is some deep unix arcana: when the subshell exits via
signal somehow the shell's process group is still in the foreground
(even though there are no processes in it?) and calling tcsetattr() from
a background process is not allowed. So the fix for this is reasonably
simple (or at least: short): call tcsetpgrp() to put our process group
back into the foreground. A background process doing this gets sent
SIGTTOU, but if we ignore that, all is well.
Frankly this is all very strange and I would like a lie down now.
the point of this is to have the event loop running while loading
autoinstall commands, which means we do not have to start and stop the
event loop inside load_autoinstall_config if there are early-commands to
run.
Olivier Gayot