SEE #1740
By processing each line in turn (and just counting is) rather
than collecting all of the lines of output from the tools,
we end up with lower memory usage.
- document a bit more of the methods
- provide convenience method enableOutputProcessing() alongside
an explicit setter; adjust tests to the changed API.
- add an executable() information method.
- this was an internal class for logging commands, let's lift
it up to the Logger framework where it might be more generally
useful (or not .. everything needs special-casing for actual
redaction).
This is an experiment in Python API that will allow a callback
function in the Python module to be called for each output line.
It builds on the run-a-process extensions that are being built
simultaneously.
The background idea is that, while CalamaresUtils::System::runCommand()
is a useful general API, it is
- still missing flexibility
- lacking a way to process output from the command "as it happens"
Waiting until the process ends, and then reading all stdout, is
inconvenient for processes that produce a **lot** of output,
and also makes it impossible to report progress. One module
in calamares-extensions has its own run-a-process implementation
for reading output, and this branch aims to introduce something
similar into Calamares core.
FIXES#1564FIXES#1817
Tested by doing an LVM installation from KDE Neon, as described
in #1817. Installation was successful, and machine booted
successfully afterwards.
- when (manually) using an existing LV, it shouldn't be closed
prior to formatting, since that kills the volume and then the
path (/dev/myvg/mylv) no longer exists. Then creating the
filesysytem on that device path fails.
- Strings were being used as logical values, and then logged
(which should be in English) and also used in the UI (which
should be localized). Replace with a MessageAndPath class,
used only locally, that defers the translation until called-
upon explicitly.
- Replace some VG stuff with similar calls to apply().
Returning partition full-paths instead of only the block-device-name
simplifies later code -- which would prepend /dev/ to the block-
device-name and umount that.
- the tryX() functions weirdly return a string that is used for
debug-logging. Document that. The untranslated string is
later used for user-facing messages. Mark that as FIXME.
- factor out the loop-over-names-and-append to news, because that
makes the overall story of what is happening hard to read.
- all calls to tryCryptoClose() called tryUnmount() first, so
put that call inside tryCryptoClose(), so the interface is simpler.
- improve descriptive-strings in logging ("set?" is not very
meaningful)
- log only the unsatisfied entries, since the preceding
log-message suggests that that is what is happening.
