1 files changed, 0 insertions, 117 deletions
diff --git a/app-misc/calamares-config-kogaion/files/settings.conf b/app-misc/calamares-config-kogaion/files/settings.conf
deleted file mode 100644
index f67f4daf..00000000
--- a/app-misc/calamares-config-kogaion/files/settings.conf
+++ /dev/null
@@ -1,117 +0,0 @@
-# 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 LIBDIR/calamares/modules with settings in SHARE/calamares/modules or
-# /etc/calamares/modules.
-# 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 instance name, a module 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, which loads a configuration file named "owncloud.conf" from
-# any of the configuration file paths, including the webview module directory.
-# This instance key can then be referenced in the sequence section.
-# For all modules without a custom instance specification, a default instance is
-# generated automatically by Calamares. Therefore a statement such as "webview" in
-# the sequence section automatically implies an instance key of "webview@webview"
-# even without explicitly defining this instance, and the configuration file for
-# this default instance "<modulename>@<modulename>" is always assumed to be
-# "<modulename>.conf".
-# For more information on running module instances, run Calamares in debug mode
-# and check the Modules page in the Debug information interface.
-# 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.
-# WARNING: when upgrading from Calamares 1.1, this section requires manual
-# intervention. There are no fixed prepare/install/postinstall phases any more,
-# and all limitations on the number of phases, number of pages, and number of
-# instances are lifted.
-# YAML: list of lists of strings.
-sequence:
-- show:
-  - welcome
-  - locale
-  - keyboard
-  - partition
-  - users
-  - summary
-- exec:
-  - partition
-  - mount
-  - unpackfs
-  - machineid
-  - fstab
-  - locale
-  - keyboard
-  - localecfg
-  - luksbootkeyfile
-  - dracutlukscfg
-  - users
-  - displaymanager
-  - hwclock
-  - dracut
-  - packages
-  - grubcfg
-  - bootloader
-  - umount
-- 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: kogaion_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.
-# 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 is considered experimental, and it
-# 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.
-# Packagers beware, here be dragons.
-# Default is false.
-# YAML: boolean.
-dont-chroot: false