- The mitigations are slightly intrusive, and may clash
with other, similar mitigations (especially for initramfs,
the recommended solution is to configure the system with
the snippet outside of Calamares).
- These tests exercise the createTargetFile() logic,
which is essential for creating a safe initramfs
configuration snippet.
- Could be moved into libcalamares instead, since the tests
are not really initramfs specific.
- In tests, a System object might be created without first
setting up a JobQueue. In that case, there's no instance,
so no GS to insert into. Avoid crash here.
- Calamares may need to create files in the target system;
provide a convenient API for doing so.
- This is mostly intended for small files with constant contents.
- This is a simple variation on the theme of things-that-call-a-
initramfs-updater, so the code is mostly a copy of initramfs/
module. I didn't even bother to strip out the configuration-
handling (I figure it might be good for *something*) so now
"" and "$uname" are valid kernel names as well.
- Fixes security issue where the initramfs ends up readable
by all, and that includes the cryptfile for LUKS.
SEE #1190
- Rename classes and functions to be more descriptive
(a LuksDevice is .. information for a LUKS device, for instance).
- Move the smarts of unpacking a QVariantMap to LuksDevice.
- Apply code formatting
- Having an int timeoutSec is suggestive -- it's probably a number
of seconds -- but having an explicit type that says it's seconds
is better.
- Doesn't compile, because the implementation and consumers have
not changed.
- Use 120 seconds for update-initramfs, instead of 10. Previous
Python code had no timeout at all, which wasn't so hot either.
10 seconds, though, is too short for slow CPU & slow disk.
- Give each check a name (based on the module it runs for, so
there might be overlaps when there are multiple module instances).
- Log the remaining checks each time the timeout fires, to help
figure out which one is hanging.
- new implementation handles blank (maps to "all") configuration,
- allows specifying "$uname" as kernel name, to use `uname -r`,
- allows specifying a specific kernel.
- updateButtonLabels() knows all the special cases for
buttons, so use it when the language changes instead
of setting up some possibly-wrong values.
- One edge case that this fixes is: have **just** the welcome
page before the first exec section in sequence. Then the
*next* button label was *next* instead of *install*.
- Minimal tests just check that all the availableTranslations()
entries have a reasonable language setting.
- Checks that Esperanto is still broken as a locale in Qt.
- The component isn't ready immediately, so instatiate
once it is fully loaded and ready
- Edge case if the execution view step is already visible, then
start the show (because a previous call to onActivate() will
have missed it).
- Just translate two simple strings, to avoid burdening translators,
- Add Dutch translation already.
These translations are not yet processed by ci/txpull and push.
- By instantiating only on activation, an ugly "white" gap
appears where there is no widget at all. So instantiate
earlier so that the widget already exists and is painting
by the time the slideshow part is visible.
- This makes the net effect of this branch so far zero:
the slideshow is still loaded and started when Calamares starts.
- From an exec section, next() is called automatically when
all the jobs in that section are done.
- If there **is** no next section (e.g. there's no finished
page to show after the exec), then m_steps.at() would assert
on an out-of-range index.
- Introdcuce a helper predicate isAtVeryEnd() which handles both
out-of-range and normal at-the-end scenarios.
- If there's no page following the exec section, stay with the
slideshow but update buttons to match the normal last-page
behavior, and don't ask about cancel (since we're done).
- This avoids processes that wait on stdin, and e.g. improves
reaction to having just "cat" (no file) in a command, or
a package manager that asks for input.
- JobQueue is only needed to get global settings, which are needed
when running in the target; for host commands, allow running
without a queue.
- Settings is needed for the value of debugsettings; assume if
there's no settings object, that we're in a test and should
print debugging information.
- This is the same as EFAIL: a block is indented as if it's a multi-
line else block. This isn't Python though, and the return always
applies.
- Add the necessary braces.
- Apparently noone uses this code path (until ProcessJob was re-
factored to do so).
