The install-bits branch commit 83639b182b
dropped .so-versioning for libcalamares and the creation of the Python-
support symlink. This broke KDE Neon dev-unstable because the embedded
Python can no longer find libcalamares.
Installing unversioned .so's straight to LIBDIR is also not a good thing
(according to Debian), so revert to the original scheme with versioned
.so and a Python-support symlink.
Medium-term fix is to install unversioned straight into LIBDIR/calamares
and fix up the RPATH for the executable.
- Applies to libcalamares and libcalamaresui.so, install with no
version, just the bare .so. Since Calamares doesn't do versioning
anyway, and its plugins should be re-compiled for any change,
putting them in lib as unversioned .so's should make Calamares
happy and silence lintian.
- The Python testmodule script can end up calling in to System
methods (via System::instance()). This is unusual, and the
System instance has not been created at that point.
Now, create an instance and warn about it.
- ValueCheck shouldn't own the pointer, since it's just a QPair
and there are temporary copies made (e.g. in
ContextualProcessBinding::append() ) and we get double-deletes.
- Do deletion by hand; going full unique_ptr would be a bit overkill.
- Re-build the structures for doing value-checks, is now more tree-like.
- Document pointer ownership.
- Introduce wildcard matches ("*")
- Don't drop empty command-lists, since they can be used to avoid
wildcard matches. (E.g. "in this case, do nothing, but don't
fall through to wildcard").
- Since the image size isn't known a priori (due to sizing based on fonts),
load the image and then resize in all code paths.
- Use the right resizing flags.
- .. and actually use the resulting scaled pixmap.
Thanks to Jeff Hodd.
- If the next step will be an install-step (e.g. hit the optional
confirmation step) then change the text on the 'next' button to
'install'.
- Do a little refactoring to make that more pleasant.
FIXES#905
- Move logging-levels to an enum
- (re-)Order logging-levels so that the normal debug statement is
not the most-important (lowest level).
- Drop using namespace std;
These additional pointers were introduced for translations,
and needed their own tricks to get lupdate to recognize the
strings. Using QCoreApplication::translate() removes the
need to a QObject to provide context. Drop the now-unneeded
parameters.
Instead of using tr and some macro hacks to get lupdate to
recognize the translation, instead use QCoreApplication::translate()
which takes its own context for translation.
- For both shellprocess and contextualprocess, add a top-level key
"timeout" that defaults to 10 seconds (which it already did).
- Allows setting "global" timeout for command-lists, while still
allowing individual timeouts per-command.
- Setting timeout per global variable in contextualprocess is not
supported; that would restrict the possible space of comparisions,
while not supporting a global setting timeout seems reasonable enough.
Use instances if you need wildly variable timeouts and don't want to
set them individually.
- Replace plain StringList with a list of <String, timeout> pairs,
and run that instead. All code paths still use the default 10sec
timeout and there's no way to change that.
- Copy stdout from timed-out process into the output variable,
instead of just dumping it into the log file. This will
improve the user experience, too, because they will get some
feedback / explanation of what the process has done.
- add license file from libpwquality for provenance
- translate pwquality_strerror() into the PWSettingsHolder convenience class
- use Qt translations, since we'd otherwise also have to wire up, and
wire in, libpwquality gettext translations.
- Use shared_ptr and a helper class to hide away raw pointer use
from libpwquality. Provide a convenience C++ API.
- Simplify configuration through helper class.
Use the samegame example from the Qt Quick demos as a branding "slideshow".
Instead of watching slides go by, you can play samegame! Click on
"new game" to start, and then click on groups of same-colored balls to make
them go away -- at least two same-colored balls must be touching.
Once the exec step is done, the game vanishes automatically.
This is an additional example for #841
- Remove some superfluous intermediate defines
- baseFactory was not used (always Calamares::PluginFactory)
- Move DECLARATION and DEFINITIONS apart
- CALAMARES_PLUGIN_FACTORY_DEFINITION was redefined (identically)
- CALAMARES_PLUGIN_FACTORY_DECLARATION was redefined (identically)
- __VA_ARGS__ was constant
- Issue asks to make the setting more visible, which seems sensible to
me. It **is** kind of hidden away for those distro's that make
the setting visible (not everyone does).
- While here, add a tooltip explaining what it does.
FIXES#893
Allow running one or more commands based on the value of
a global configuration variable. This could, of course,
be done in a Python module with some custom code,
but for simple cases this is more straightforward
to configure through module instances.
Uses the CommandList developed for the ShellProcess
module to do the actual work.
FIXES#874
- Move CommandList so it can be used from more modules than
just ShellProcess
- Allow a CommandList to run itself. This centralizes
code for executing one or more commands and simplifies
the ShellProcess module.
Various small cleanups:
- mention instance id in log message
- code formatting / style
- This turns off the space-available check in the welcome module;
without libparted, always fail that check.
- Allows running the welcome module on OS without libparted.
- Also allow a single string instead of a list
- Add count() method to CommandList
- Drop over-engineering, add more logging
- Expand tests with some more examples
This is basically dummyprocess, except with an expanded configuration
interface so you can run 1 or more shell commands in the live
or target system with a suitable configuration file and instance
of shellprocess in settings.conf.
It can replace downstream modules that implement their own
process modules with a command, by an instance of shellprocess.
Back targetEnvCommand() with a more general runCommand()
that takes an argument selecting the location to run
the command in. This allows us also to use the same
API for running processes in the host during install,
as we do for running them in the target system.
One reason for this change is wanting to run (user-specified)
commands and independently from the global dontChroot setting,
run those commands in the live system or the target.
This changes the ABI of the DLL, since targetEnvCommand()
is no longer exported. Plugins will need to be recompiled.
- refactor targetEnvCommand() into more general runCommand().
- While here, allow host system commands to run even if
there is no global storage.
- provide convenience accessors for ProcessResult members
- Move explanation of process errors out of ProcessJob
- Move from ProcessJob to ProcessResult, so it can be
reused outside of ProcessJob (e.g. from ShellProcessJob).
- Add some convenience functions, too.
Make a function out of explaining-skipped-modules, and call it
not only after collecting all the modules, but also after
the feature summary, so that it's quite clear which modules
are skipped.
