app-misc/calamares-config-redcore : version bump

8 files changed, 4 insertions, 569 deletions

diff --git a/app-misc/calamares-config-redcore/files/modules/bootloader.conf b/app-misc/calamares-config-redcore/files/modules/bootloader.conf
index 789b7918..bad9c863 100644
--- a/app-misc/calamares-config-redcore/files/modules/bootloader.conf
+++ b/app-misc/calamares-config-redcore/files/modules/bootloader.conf
@@ -1,53 +1,14 @@
-# Bootloader configuration. The bootloader is installed to allow
-# the system to start (and pick one of the installed operating
-# systems to run).
 ---
-# Define which bootloader you want to use for EFI installations
-# Possible options are 'grub', 'sb-shim' and 'systemd-boot'.
 efiBootLoader: "grub"
 
-# systemd-boot configuration files settings, set kernel and initramfs file names
-# and amount of time before default selection boots
-kernel: "/boot/vmlinuz-5.10.11-redcore-lts"
-img: "/boot/initrd-5.10.11-redcore-lts"
+kernel: "/boot/vmlinuz-5.14.10-redcore"
+img: "/boot/initrd-5.14.10-redcore"
 timeout: "10"
 
-# Optionally set the menu entry name and kernel name to use in systemd-boot.
-# If not specified here, these settings will be taken from branding.desc.
-#
-# bootloaderEntryName: "Generic GNU/Linux"
-# kernelLine: ", with Stable-Kernel"
-# fallbackKernelLine:  ", with Stable-Kernel (fallback initramfs)"
-
-# GRUB 2 binary names and boot directory
-# Some distributions (e.g. Fedora) use grub2-* (resp. /boot/grub2/) names.
-# These names are also used when using sb-shim, since that needs some
-# GRUB functionality (notably grub-probe) to work. As needed, you may use
-# complete paths like `/usr/bin/efibootmgr` for the executables.
-#
 grubInstall: "grub2-install"
 grubMkconfig: "grub2-mkconfig"
 grubCfg: "/boot/grub/grub.cfg"
 grubProbe: "grub2-probe"
 efiBootMgr: "efibootmgr"
 
-# Optionally set the bootloader ID to use for EFI. This is passed to
-# grub-install --bootloader-id.
-#
-# If not set here, the value from bootloaderEntryName from branding.desc
-# is used, with problematic characters (space and slash) replaced.
-#
-# The ID is also used as a directory name within the EFI environment,
-# and the bootloader is copied from /boot/efi/EFI/<dirname>/ . When
-# setting the option here, keep in mind that the name is sanitized
-# (problematic characters, see above, are replaced).
-#
-# efiBootloaderId: "dirname"
-
-# Optionally install a copy of the GRUB EFI bootloader as the EFI
-# fallback loader (either bootia32.efi or bootx64.efi depending on
-# the system). This may be needed on certain systems (Intel DH87MC
-# seems to be the only one). If you set this to false, take care
-# to add another module to optionally install the fallback on those
-# boards that need it.
 installEFIFallback: true
diff --git a/app-misc/calamares-config-redcore/files/modules/displaymanager.conf b/app-misc/calamares-config-redcore/files/modules/displaymanager.conf
index 18250fd0..d82deb6a 100644
--- a/app-misc/calamares-config-redcore/files/modules/displaymanager.conf
+++ b/app-misc/calamares-config-redcore/files/modules/displaymanager.conf
@@ -1,52 +1,7 @@
-# Configure one or more display managers (e.g. SDDM)
-# with a "best effort" approach.
-#
-# This module also sets up autologin, if the feature is enabled in
-# globalstorage (where it would come from the users page).
 ---
-# The DM module attempts to set up all the DMs found in this list, in the
-# precise order listed. The displaymanagers list can also be set in
-# globalstorage, and in that case it overrides the setting here.
-#
-# If *sysconfigSetup* is set to *true* (see below, only relevant for
-# openSUSE derivatives) then this list is ignored and only sysconfig
-# is attempted. You can also list "sysconfig" in this list instead.
-#
 displaymanagers:
   - sddm
 
-# Enable the following settings to force a desktop environment
-# in your displaymanager configuration file. This will attempt
-# to configure the given DE (without checking if it is installed).
-# The DM configuration for each potential DM may **or may not**
-# support configuring a default DE, so the keys are mandatory
-# but their interpretation is up to the DM configuration.
-#
-# Subkeys of *defaultDesktopEnvironment* are (all mandatory):
-#  - *executable* a full path to an executable
-#  - *desktopFile* a .desktop filename
-#
-# If this is **not** set, then Calamares will look for installed
-# DE's and pick the first one it finds that is actually installed.
-#
-# If this **is** set, and the *executable* key doesn't point to
-# an installed file, then the .desktop file's TryExec key is
-# used instead.
-#
-
-#defaultDesktopEnvironment:
-#    executable: "startkde"
-#    desktopFile: "plasma"
-
-#If true, try to ensure that the user, group, /var directory etc. for the
-#display manager are set up correctly. This is normally done by the distribution
-#packages, and best left to them. Therefore, it is disabled by default.
 basicSetup: false
 
-# If true, setup autologin for openSUSE. This only makes sense on openSUSE
-# derivatives or other systems where /etc/sysconfig/displaymanager exists.
-#
-# The preferred way to pick sysconfig is to just list it in the
-# *displaymanagers* list (as the only one).
-#
 sysconfigSetup: false
diff --git a/app-misc/calamares-config-redcore/files/modules/finished.conf b/app-misc/calamares-config-redcore/files/modules/finished.conf
index 3c6ca4ff..d317c905 100644
--- a/app-misc/calamares-config-redcore/files/modules/finished.conf
+++ b/app-misc/calamares-config-redcore/files/modules/finished.conf
@@ -1,44 +1,6 @@
-# Configuration for the "finished" page, which is usually shown only at
-# the end of the installation (successful or not).
 ---
-# DEPRECATED
-#
-# The finished page can hold a "restart system now" checkbox.
-# If this is false, no checkbox is shown and the system is not restarted
-# when Calamares exits.
-# restartNowEnabled: true
-
-# DEPRECATED
-#
-# Initial state of the checkbox "restart now". Only relevant when the
-# checkbox is shown by restartNowEnabled.
-# restartNowChecked: false
-
-# Behavior of the "restart system now" button.
-#
-# There are four usable values:
-#   - never
-#       Does not show the button and does not restart.
-#       This matches the old behavior with restartNowEnabled=false.
-#   - user-unchecked
-#       Shows the button, defaults to unchecked, restarts if it is checked.
-#       This matches the old behavior with restartNowEnabled=true and restartNowChecked=false.
-#   - user-checked
-#       Shows the button, defaults to checked, restarts if it is checked.
-#       This matches the old behavior with restartNowEnabled=true and restartNowChecked=true.
-#   - always
-#       Shows the button, checked, but the user cannot change it.
-#       This is new behavior.
-#
-# The three combinations of legacy values are still supported.
 restartNowMode: user-unchecked
 
-# If the checkbox is shown, and the checkbox is checked, then when
-# Calamares exits from the finished-page it will run this command.
-# If not set, falls back to "shutdown -r now".
 restartNowCommand: "shutdown -r 0"
 
-# When the last page is (successfully) reached, send a DBus notification
-# to the desktop that the installation is done. This works only if the
-# user as whom Calamares is run, can reach the regular desktop session bus.
 notifyOnFinished: false
diff --git a/app-misc/calamares-config-redcore/files/modules/keyboard.conf b/app-misc/calamares-config-redcore/files/modules/keyboard.conf
index ff60ed60..fa205623 100644
--- a/app-misc/calamares-config-redcore/files/modules/keyboard.conf
+++ b/app-misc/calamares-config-redcore/files/modules/keyboard.conf
@@ -1,8 +1,4 @@
 ---
-# The name of the file to write X11 keyboard settings to
-# The default value is the name used by upstream systemd-localed.
-# Relative paths are assumed to be relative to /etc/X11/xorg.conf.d
 xOrgConfFileName: "/usr/share/X11/xorg.conf.d/00-keyboard.conf"
-# The path to search for keymaps converted from X11 to kbd format
-# Leave this empty if the setting does not make sense on your distribution.
+
 convertedKeymapPath: "/usr/share/keymaps/"
diff --git a/app-misc/calamares-config-redcore/files/modules/machineid.conf b/app-misc/calamares-config-redcore/files/modules/machineid.conf
index 13ba17df..bf99e675 100644
--- a/app-misc/calamares-config-redcore/files/modules/machineid.conf
+++ b/app-misc/calamares-config-redcore/files/modules/machineid.conf
@@ -1,24 +1,8 @@
-# Machine-ID and other random data on the target system.
-#
-# This module can create a number of "random" things on the target:
-#  - a systemd machine-id file (hence the name of the Calamares module)
-#    with a random UUID.
-#  - a dbus machine-id file (or, optionally, link to the one from systemd)
-#  - an entropy file
-#
 ---
-# Whether to create /etc/machine-id for systemd.
 systemd: false
 
-# Whether to create /var/lib/dbus/machine-id for D-Bus.
 dbus: true
-# Whether /var/lib/dbus/machine-id should be a symlink to /etc/machine-id
-# (ignored if dbus is false, or if there is no /etc/machine-id to point to).
 dbus-symlink: true
-# this is a deprecated form of *dbus-symlink*
-symlink: true
 
-# Whether to create an entropy file
 entropy: false
-# Whether to copy entropy from the host
 entropy-copy: false
diff --git a/app-misc/calamares-config-redcore/files/modules/packages.conf b/app-misc/calamares-config-redcore/files/modules/packages.conf
index 52ef498e..71a1f4fe 100644
--- a/app-misc/calamares-config-redcore/files/modules/packages.conf
+++ b/app-misc/calamares-config-redcore/files/modules/packages.conf
@@ -1,167 +1,10 @@
 ---
-#
-# Which package manager to use, options are:
-#  - packagekit  - PackageKit CLI tool
-#  - zypp        - Zypp RPM frontend
-#  - yum         - Yum RPM frontend
-#  - dnf         - DNF, the new RPM frontend
-#  - urpmi       - Mandriva package manager
-#  - apt         - APT frontend for DEB and RPM
-#  - pacman      - Pacman
-#  - portage     - Gentoo package manager
-#  - entropy     - Sabayon package manager
-#  - apk         = Alpine Linux package manager
-#  - dummy       - Dummy manager, only logs
-#
 backend: portage
 
-#
-# Often package installation needs an internet connection.
-# Since you may allow system installation without a connection
-# and want to offer OPTIONAL package installation, it's
-# possible to have no internet, yet have this packages module
-# enabled in settings.
-#
-# You can skip the whole module when there is no internet
-# by setting "skip_if_no_internet" to true.
-#
-# You can run a package-manager specific update procedure
-# before installing packages (for instance, to update the
-# list of packages and dependencies); this is done only if there
-# is an internet connection.
-#
-# Set "update_db" to 'true' for refreshing the database on the
-# target system. On target installations, which got installed by
-# unsquashing, a full system update may be needed. Otherwise
-# post-installing additional packages may result in conflicts.
-# Therefore set also "update_system" to 'true'.
-#
 skip_if_no_internet: false
 update_db: false
 update_system: false
 
-#
-# List of maps with package operations such as install or remove.
-# Distro developers can provide a list of packages to remove
-# from the installed system (for instance packages meant only
-# for the live system).
-#
-# A job implementing a distro specific logic to determine other
-# packages that need to be installed or removed can run before
-# this one. Distro developers may want to install locale packages
-# or remove drivers not needed on the installed system.
-# Such a job would populate a list of dictionaries in the global
-# storage called "packageOperations" and that list is processed
-# after the static list in the job configuration (i.e. the list
-# that is in this configuration file).
-#
-# Allowed package operations are:
-#  - *install*, *try_install*: will call the package manager to
-#       install one or more packages. The install target will
-#       abort the whole installation if package-installation
-#       fails, while try_install carries on. Packages may be
-#       listed as (localized) names, or as (localized) package-data.
-#       See below for the description of the format.
-# - *localInstall*: this is used to call the package manager
-#       to install a package from a path-to-a-package. This is
-#       useful if you have a static package archive on the install media.
-#       The *pacman* package manager is the only one to specially support
-#       this operation (all others treat this the same as *install*).
-# - *remove*, *try_remove*: will call the package manager to
-#       remove one or more packages. The remove target will
-#       abort the whole installation if package-removal fails,
-#       while try_remove carries on. Packages may be listed as
-#       (localized) names.
-# One additional key is recognized, to help netinstall out:
-# - *source*: ignored, does get logged
-# Any other key is ignored, and logged as a warning.
-#
-# There are two formats for naming packages: as a name or as package-data,
-# which is an object notation providing package-name, as well as pre- and
-# post-install scripts.
-#
-# Here are both formats, for installing vi. The first one just names the
-# package for vi (using the naming of the installed package manager), while
-# the second contains three data-items; the pre-script is run before invoking
-# the package manager, and the post-script runs once it is done.
-#
-# - install
-#   - vi
-#   - package: vi
-#     pre-script: touch /tmp/installing-vi
-#     post-script: rm -f /tmp/installing-vi
-#
-# The pre- and post-scripts are optional, but you cannot leave both out
-# if you do use the *package* key: using "package: vi" with neither script
-# option will trick Calamares into trying to install a package named
-# "package: vi", which is unlikely to work.
-#
-# The pre- and post-scripts are **not** executed by a shell unless you
-# explicitly invoke `/bin/sh` in them. The command-lines are passed
-# to exec(), which does not understand shell syntax. In other words:
-#
-#     pre-script: ls | wc -l
-#
-# Will fail, because `|` is passed as a command-line argument to ls,
-# as are `wc`, and `-l`. No shell pipeline is set up, and ls is likely
-# to complain. Invoke the shell explicitly:
-#
-#     pre-script: /bin/sh -c \"ls | wc -l\"
-#
-# The above note on shell-expansion applies to versions up-to-and-including
-# Calamares 3.2.12, but will change in future.
-#
-# Any package name may be localized; this is used to install localization
-# packages for software based on the selected system locale. By including
-# the string `LOCALE` in the package name, the following happens:
-#
-# - if the system locale is English (any variety), then the package is not
-#   installed at all,
-# - otherwise `$LOCALE` or `${LOCALE}` is replaced by the 'lower-cased' BCP47
-#   name of the 'language' part of the selected system locale (not the
-#   country/region/dialect part), e.g. selecting "nl_BE" will use "nl"
-#   here.
-#
-# Take care that just plain `LOCALE` will not be replaced, so `foo-LOCALE` will
-# be left unchanged, while `foo-$LOCALE` will be changed. However, `foo-LOCALE`
-# **will** be removed from the list of packages (i.e. not installed), if
-# English is selected. If a non-English locale is selected, then `foo-LOCALE`
-# will be installed, unchanged (no language-name-substitution occurs).
-#
-# The following installs localizations for vi, if they are relevant; if
-# there is no localization, installation continues normally.
-#
-# - install
-#   - vi-$LOCALE
-#   - package: vi-${LOCALE}
-#     pre-script: touch /tmp/installing-vi
-#     post-script: rm -f /tmp/installing-vi
-#
-# When installing packages, Calamares will invoke the package manager
-# with a list of package names if it can; package-data prevents this because
-# of the scripts that need to run. In other words, this:
-#
-# - install:
-#   - vi
-#   - binutils
-#   - package: wget
-#     pre-script: touch /tmp/installing-wget
-#
-# This will invoke the package manager three times, once for each package,
-# because not all of them are simple package names. You can speed up the
-# process if you have only a few pre-scripts, by using multiple install targets:
-#
-# - install:
-#   - vi
-#   - binutils
-# - install:
-#   - package: wget
-#     pre-script: touch /tmp/installing-wget
-#
-# This will call the package manager once with the package-names "vi" and
-# "binutils", and then a second time for "wget". When installing large numbers
-# of packages, this can lead to a considerable time savings.
-#
 operations:
   - remove:
     - app-admin/calamares
diff --git a/app-misc/calamares-config-redcore/files/modules/users.conf b/app-misc/calamares-config-redcore/files/modules/users.conf
index 8a1addc0..a94d71ca 100644
--- a/app-misc/calamares-config-redcore/files/modules/users.conf
+++ b/app-misc/calamares-config-redcore/files/modules/users.conf
@@ -1,18 +1,4 @@
-# Configuration for the one-user-system user module.
-#
-# Besides these settings, the user module also places the following
-# keys into the globalconfig area, based on user input in the view step.
-#
-# - hostname
-# - username
-# - password (obscured)
-# - autologinUser (if enabled, set to username)
-#
-# These globalconfig keys are set when the jobs for this module
-# are created.
 ---
-# Used as default groups for the created user.
-# Adjust to your Distribution defaults.
 defaultGroups:
     - lp
     - lpadmin
@@ -32,120 +18,14 @@ defaultGroups:
     - messagebus
     - smbshare
 
-# Some Distributions require a 'autologin' group for the user.
-# Autologin causes a user to become automatically logged in to
-# the desktop environment on boot.
-# Disable when your Distribution does not require such a group.
-# autologinGroup:  autologin
-# You can control the initial state for the 'autologin checkbox' here.
-# Possible values are:
-#  - true to check or
-#  - false to uncheck
-# These set the **initial** state of the checkbox.
 doAutologin:     true
 
-# When *sudoersGroup* is set to a non-empty string, Calamares creates a
-# sudoers file for the user. This file is located at:
-#     `/etc/sudoers.d/10-installer`
-# Remember to add the (value of) *sudoersGroup* to *defaultGroups*.
-#
-# If your Distribution already sets up a group of sudoers in its packaging,
-# remove this setting (delete or comment out the line below). Otherwise,
-# the setting will be duplicated in the `/etc/sudoers.d/10-installer` file,
-# potentially confusing users.
-# sudoersGroup:    wheel
-
-# Setting this to false, causes the root account to be disabled.
-# When disabled, hides the "Use the same password for administrator"
-# checkbox. Also hides the "Choose a password" and associated text-inputs.
 setRootPassword: true
 
-# You can control the initial state for the 'reuse password for root'
-# checkbox here. Possible values are:
-#  - true to check or
-#  - false to uncheck
-#
-# When checked, the user password is used for the root account too.
-#
-# NOTE: *doReusePassword* requires *setRootPassword* to be enabled.
 doReusePassword: false
 
-# These are optional password-requirements that a distro can enforce
-# on the user. The values given in this sample file set only very weak
-# validation settings.
-#
-# - nonempty rejects empty passwords
-# - there are no length validations
-# - libpwquality (if it is enabled at all) has no length of class
-#   restrictions, although it will still reject palindromes and
-#   dictionary words with these settings.
-#
-# Checks may be listed multiple times; each is checked separately,
-# and no effort is done to ensure that the checks are consistent
-# (e.g. specifying a maximum length less than the minimum length
-# will annoy users).
-#
-# The libpwquality check relies on the (optional) libpwquality library.
-# Its value is a list of configuration statements that could also
-# be found in pwquality.conf, and these are handed off to the
-# libpwquality parser for evaluation. The check is ignored if
-# libpwquality is not available at build time (generates a warning in
-# the log). The Calamares password check rejects passwords with a
-# score of < 40 with the given libpwquality settings.
-#
-# (additional checks may be implemented in CheckPWQuality.cpp and
-# wired into UsersPage.cpp)
-#
-#  - To disable specific password validations:
-#    comment out the relevant 'passwordRequirements' keys below.
-#  - To disable all password validations:
-#    set both 'allowWeakPasswords' and 'allowWeakPasswordsDefault' to true.
-#    (That will show the box *Allow weak passwords* in the user-
-#    interface, and check it by default).
-# passwordRequirements:
-#    nonempty: true
-#    minLength: -1  # Password at least this many characters
-#    maxLength: -1  # Password at most this many characters
-#    libpwquality:
-#        - minlen=0
-#        - minclass=0
-
-# You can control the visibility of the 'strong passwords' checkbox here.
-# Possible values are:
-#  - true to show or
-#  - false to hide  (default)
-# the checkbox. This checkbox allows the user to choose to disable
-# password-strength-checks. By default the box is **hidden**, so
-# that you have to pick a password that satisfies the checks.
 allowWeakPasswords: true
-# You can control the initial state for the 'strong passwords' checkbox here.
-# Possible values are:
-#  - true to uncheck or
-#  - false to check (default)
-# the checkbox by default. Since the box is labeled to enforce strong
-# passwords, in order to **allow** weak ones by default, the box needs
-# to be unchecked.
 allowWeakPasswordsDefault: true
 
-# Shell to be used for the regular user of the target system.
-# There are three possible kinds of settings:
-#  - unset (i.e. commented out, the default), act as if set to /bin/bash
-#  - empty (explicit), don't pass shell information to useradd at all
-#    and rely on a correct configuration file in /etc/default/useradd
-#  - set, non-empty, use that path as shell. No validation is done
-#    that the shell actually exists or is executable.
-# userShell: /bin/bash
-
-# Hostname setting
-#
-# The user can enter a hostname; this is configured into the system
-# in some way; pick one of:
-#   - *None*, to not set the hostname at all
-#   - *EtcFile*, to write to `/etc/hostname` directly
-#   - *Hostnamed*, to use systemd hostnamed(1) over DBus
-# The default is *EtcFile*.
 setHostname: EtcFile
-
-# Should /etc/hosts be written with a hostname for this machine
-# (also adds localhost and some ipv6 standard entries).
 writeHostsFile: true
diff --git a/app-misc/calamares-config-redcore/files/settings.conf b/app-misc/calamares-config-redcore/files/settings.conf
index 713af9e0..c17ae61c 100644
--- a/app-misc/calamares-config-redcore/files/settings.conf
+++ b/app-misc/calamares-config-redcore/files/settings.conf
@@ -1,89 +1,5 @@
-# Configuration file for Calamares
-# Syntax is YAML 1.2
----
-# Modules can be job modules (with different interfaces) and QtWidgets view
-# modules. They could all be placed in a number of different paths.
-# "modules-search" is a list of strings, each of these can either be a full
-# path to a directory or the keyword "local".
-#
-# "local" means:
-#   - modules in $LIBDIR/calamares/modules, with
-#   - settings in SHARE/calamares/modules or /etc/calamares/modules.
-# In debug-mode (e.g. calamares -d) "local" also adds some paths
-# that make sense from inside the build-directory, so that you
-# can build-and-run with the latest modules immediately.
-#
-# Strings other than "local" are taken as paths and interpreted
-# relative to wherever Calamares is started. It is therefore **strongly**
-# recommended to use only absolute paths here. This is mostly useful
-# if your distro has forks of standard Calamares modules, but also
-# uses some form of upstream packaging which might overwrite those
-# forked modules -- then you can keep modules somewhere outside of
-# the "regular" module tree.
-#
-#
-# YAML: list of strings.
 modules-search: [ local ]
 
-# Instances section. This section is optional, and it defines custom instances
-# for modules of any kind. An instance entry has an module name, an instance
-# name, and a configuration file name. The primary goal of this mechanism is
-# to allow loading multiple instances of the same module, with different
-# configuration. If you don't need this, the instances section can safely be
-# left empty.
-#
-# Module name plus instance name makes an instance key, e.g.
-# "webview@owncloud", where "webview" is the module name (for the webview
-# viewmodule) and "owncloud" is the instance name. In the *sequence*
-# section below, use instance-keys to name instances (instead of just
-# a module name, for modules which have only a single instance).
-#
-# Every module implicitly has an instance with the instance name equal
-# to its module name, e.g. "welcome@welcome". In the *sequence* section,
-# mentioning a module without a full instance key (e.g. "welcome")
-# means that implicit module.
-#
-# An instance must specify its configuration file (e.g. `webview-home.conf`).
-# The implicit instances all have configuration files named `<module>.conf`.
-# This (implict) way matches the source examples, where the welcome
-# module contains an example `welcome.conf`.
-#
-# For more information on running module instances, run Calamares in debug
-# mode and check the Modules page in the Debug information interface.
-#
-# A module that is often used with instances is shellprocess, which will
-# run shell commands specified in the configuration file. By configuring
-# more than one instance of the module, multiple shell sessions can be run
-# during install.
-#
-# YAML: list of maps of string:string key-value pairs.
-#instances:
-#- id:       owncloud
-#  module:   webview
-#  config:   owncloud.conf
-
-# Sequence section. This section describes the sequence of modules, both
-# viewmodules and jobmodules, as they should appear and/or run.
-#
-# A jobmodule instance key (or name) can only appear in an exec phase, whereas
-# a viewmodule instance key (or name) can appear in both exec and show phases.
-# There is no limit to the number of show or exec phases. However, the same
-# module instance key should not appear more than once per phase, and
-# deployers should take notice that the global storage structure is persistent
-# throughout the application lifetime, possibly influencing behavior across
-# phases. A show phase defines a sequence of viewmodules (and therefore
-# pages). These viewmodules can offer up jobs for the execution queue.
-#
-# An exec phase displays a progress page (with brandable slideshow). This
-# progress page iterates over the modules listed in the *immediately
-# preceding* show phase, and enqueues their jobs, as well as any other jobs
-# from jobmodules, in the order defined in the current exec phase.
-#
-# It then executes the job queue and clears it. If a viewmodule offers up a
-# job for execution, but the module name (or instance key) isn't listed in the
-# immediately following exec phase, this job will not be executed.
-#
-# YAML: list of lists of strings.
 sequence:
 - show:
   - welcome
@@ -115,73 +31,11 @@ sequence:
 - show:
   - finished
 
-# A branding component is a directory, either in SHARE/calamares/branding or
-# in /etc/calamares/branding (the latter takes precedence). The directory must
-# contain a YAML file branding.desc which may reference additional resources
-# (such as images) as paths relative to the current directory.
-#
-# A branding component can also ship a QML slideshow for execution pages,
-# along with translation files.
-#
-# Only the name of the branding component (directory) should be specified
-# here, Calamares then takes care of finding it and loading the contents.
-#
-# YAML: string.
 branding: redcore_branding
-
-# If this is set to true, Calamares will show an "Are you sure?" prompt right
-# before each execution phase, i.e. at points of no return. If this is set to
-# false, no prompt is shown. Default is false, but Calamares will complain if
-# this is not explicitly set.
-#
-# YAML: boolean.
 prompt-install: true
-
-# If this is set to true, Calamares will execute all target environment
-# commands in the current environment, without chroot. This setting should
-# only be used when setting up Calamares as a post-install configuration tool,
-# as opposed to a full operating system installer.
-#
-# Some official Calamares modules are not expected to function with this
-# setting. (e.g. partitioning seems like a bad idea, since that is expected to
-# have been done already)
-#
-# Default is false (for a normal installer), but Calamares will complain if
-# this is not explicitly set.
-#
-# YAML: boolean.
 dont-chroot: false
-
-# If this is set to true, Calamares refers to itself as a "setup program"
-# rather than an "installer". Defaults to the value of dont-chroot, but
-# Calamares will complain if this is not explicitly set.
 oem-setup: false
-
-# If this is set to true, the "Cancel" button will be disabled entirely.
-# The button is also hidden from view.
-#
-# This can be useful if when e.g. Calamares is used as a post-install
-# configuration tool and you require the user to go through all the
-# configuration steps.
-#
-# Default is false, but Calamares will complain if this is not explicitly set.
-#
-# YAML: boolean.
 disable-cancel: false
-
-# If this is set to true, the "Cancel" button will be disabled once
-# you start the 'Installation', meaning there won't be a way to cancel
-# the Installation until it has finished or installation has failed.
-#
-# Default is false, but Calamares will complain if this is not explicitly set.
-#
-# YAML: boolean.
 disable-cancel-during-exec: false
-
-# If this is set to true, then once the end of the sequence has
-# been reached, the quit (done) button is clicked automatically
-# and Calamares will close. Default is false: the user will see
-# that the end of installation has been reached, and that things are ok.
-#
-#
+hide-back-and-next-during-exec: false
 quit-at-end: false