Re-jig the module-weight calculations.
- modules can have a weight
- module instances can have a weight
- jobs, from the module, can have a weight
This is now configurable on a case-by-case basis, rather than having
C++ only as an option and a weird hack for unpackfs.
reflect changes from users/Config.cpp
corrected id missing capital
mirror UsersQmlViewStep.cpp/h with the users versions
connections are still not made
- if the user password is reused (or not) then check the
status of the passwords against the new reuse-setting
- if the allow-weak-passwords setting is changed, then
check the status of passwords (both of them) against
the new weakness setting
As explained by Kevin Kofler and abucodonosor, the
implementer line can carry a bunch of different values,
but none of them are actually interesting. Simplify
the code.
- the way isPasswordAcceptable was being used was buggy, leading
to test failures (now fixed)
- don't expose the function, anyway: it's an implementation
detail for passwordStatus() which in itself is an implementation
detail for status notifications.
- avoid update loops by checking values before emitting *Changed()
- check validity of user and root passwords when asked
- if root isn't going to be written, or re-uses the user password,
defer to those status checks.
- a handful of modules had an unused *requires* key in module.desc;
this is probably from previous intentions around
prerequisites-testing. Since the settings were empty anyway,
they have been removed.
- [unpackfs] Compacted the way *requiredModules* list is written
This module allows the generation of the initramfs in Alpine Linux based
systems (excluding postmarketOS). Very bare bones, but then again it
doesn't need much. It uses the Alpine Linux tool "mkinitfs" to do the
job.
module builds, installs and runs, connections are not working yet.
UserQmlViewstep.cpp/h are from PR https://github.com/calamares/calamares/pull/1356
sections are commented out to make the module build, but help is needed to get those 2 files corrected.
config names used in usersq.qml are guessed from users/Config.cpp
debug window shows correct entries in GS, and under the module tab, usersq.conf is read
as should too. Running shows most config used in users.qml are not registered/wrong,
many entries like: qrc:/usersq.qml:228:13: Unable to assign [undefined] to bool
It is understood not all needed from the users module has moved to Config.cpp yet,
but doing the PR now, since it runs, doesn't crash cala and help is needed to further implement.
- The TZ widget uses a different coordinate system (mapping lat and lon
to pixel locations, and then calculating Manhattan distance from
that), so needs a different distance function.
- Simplify code: there's just one "closest TZ" function.
- create directories for new tests ahead of the tests themselves;
this **can** still cause problems if a test is run standalone.
- if creating the grub-dir at runtime is necessary, be informative
if it fails.
- the default_dir was only stored in modify_grub_default() to
create the directory if needed; move that functionality to
the get_grub_config_paths() function (and drop the "s",
since it now returns just one).
Go over the locale module again:
- new models that avoid weird casts and inconvenient iteration
- shared timezone data
- simple sorting and filtering
- simplify the map / QML version
FIXES#1476FIXES#1426
- refactor into some free functions (out of the lambda's for connecting)
- introduce new method to call from onLeave(), matching previous
widget behavior
- we can do GeoIP and GeoNames lookups, **or**
- use Calamares's internal GeoIP lookup and country / city hints.
The online version is much more accurate, but costs more lookups;
in these examples, set it all to "offline" and document what needs
to change (code edit) to use the online version.
It's probably a good beginner job to introduce a bool in localeq.qml
to switch the behaviors.
- Config has suitable strings for displaying TZ information.
Use them and automatic bindings. Don't update the strings manually.
- Suggest online or offline TZ lookups based on what the distro wants.
Edit the QML to pick online lookups (needs access to the geonames
service, though).
- Drop the variables that point at config and geoip: the Config
object has a currentLocation, which is filled in by both the
configuration and any GeoIP lookup -- it doesn't have city
or country information though.
- status is a longer phrase
- name is a short human-readable name
- code is the internal code
Code that writes its own "Timezone set to" messages can use
the name, rather than the status.
- when no location has been set at all, there's no sensible TZ
to report; just leave it blank. In *practice* you won't hit this
code from the Calamares UI before a location has been set, because
the Config object is instantiated and then immediately configured,
but from tests or unusual UIs it could be.
- needs some massaging because Config otherwise depends on
ModuleManager which is a UI class (for the Reasons),
but we already have a BUILD_AS_TEST define for that purpose.
- demonstrate a nullptr deref.
- The Config object now uses the re-done models and timezone data
- most of the properties of the locale Config are unchanged
- much less complication in extracting data from the zones model
- there **is** another source of information about the CPU,
so in the test use that to cross-check what hostCPU() says.
NB: it's probably a good idea to fall back on the same file
in hostCPU() for better accuracy.
- get username, password etc. from the config object, not the page
- jobs now depend entirely on config
- handle logic of "what's the root password" in Config
- The configuration for writing the hostname (to /etc/hostname,
to /etc/hosts and possibly to systemd-hostname) is read-only,
because it comes from the config file and won't change after.
- add the "reuse user password for root" setting to Config,
make the UI page follow that setting.
- add the require-strong-password default and toggle settings to
Config; this is not well-checked yet.
On the widget / UI side, connect checkboxes only if they are
visible; refactor reuse-user-password-for-root settings.
The TODO said it was unused: it **is** used, but only in
a very limited scope. Drop it from jobs where it wasn't
useful (e.g. those that just return prettyName(), outside
of the partition module).
- The enum for install choice was copied into PartitionActions and
used in the Config object; its definition does not belong in the UI.
- Chase the renamings required.
- add an option to select what button should be selected when the
partitioning module is started; TODO: the actual functionality is
**not** implemented.
- drop the previously suggested name, which didn't get beyond the
comments-in-the-config-file stage (but which intended to do the
same things as this one)
- add option to schema already, even if it's not implemented.
See #1297
FIXUP conf
The encryption widget (passphrase for disk encryption) should show
ok / warning / error whenever the state changes; this avoids
it showing up first with **no** icon (it should show a warning
when both passphrases are empty).
Both the KPMCore and the ChoicePage -- asynchronously -- were connected
to the nextStatusChanged() signal. So if the core said next was true,
that could end up communicated to the ViewManager, enabling the *next*
button in the UI.
Changing to the *erase* page generally triggers a KPMCore reload,
which later emits a `hasRootMountPointChanged()` signal, once the
layout is applied and the disk gets a root mount point. So we'd
get a `true` from KPMCore, which -- because it was connected directly
to the signal to the VM -- would override any other considerations.
Hook up both signals to an intermediate slot that just recalculates
whether the next button should be enabled, based on the state
both of the Choice page and whatever else.
