Do not rely on Q_DECL_EXPORT and the like. Since we support basically
only gcc and clang for the kinds of Linux targets Calamares gets used
on, use visibility-specifiers that those compilers understand.
When running a command in the chroot, don't set TMP (and similar)
variables because those directories might nog make sense in the
target (yet).
FIXES#2269
Use case would be customization of default modules, eg packagechooser requires compat/Variant.h and packages/Globals.h to compile in the calamares-extension repo
Signed-off-by: artoo <artoo@artixlinux.org>
All unknown-variants return None, but this only
happens in practice with an empty variant (e.g.
a configuration key that is empty in the YAML).
FIXES#2237
While this isn't useful in production, it makes tests a lot
simpler to write since you don't have to wrestle with
creating new GS objects in order to start fresh.
From inside Calamares, register libcalamares to the
interpreter by hand; from external Python processes
the regular extension library hooks are called.
Tested by running ./build/localmodule dummypython
(which means that the shared library is not present
in the current directory, so then `import libcalamares`
fails if the module is not already registered --
a test scenario that previous attempt at module
import missed).
bqi is one possible name of Luri / Lhur language,
as far as I can tell -- there is also Northern Luri,
which is supported by Qt and has code lrc.
ie is Interlingue, which Qt maps to C locale.
Work around that by mapping it to interlingua.
The Calamares Manager should not be a singleton; it is needed
in multiple threads (e.g. from QML). It can have a singleton
Private manager that caches and shares things, though.
- (syntax) errors in the pre-script or the module's script
should not trigger a fatal error in Calamares (i.e. terminate
called because of uncaught Python exception).
- Log more clearly where the error is being caught.
Add a target that resembles what you would get from "normal"
use of pybind11 when following the examples. Link with it.
Drop Boost:Python sources from libcalamares.
make kpmcorehelper usable for both kf5 & 6, though no section added yet dealing with set to NOT for Qt6
adjust CalamaresConfig to not be hardcoded to kf5
one more var needed in Variant.h, used in PartitionInfo.cpp
adjust QVariant & QtConcurrent use
- On FreeBSD, no KF6 was available
- On KDE Neon Unstable, there are somewhat wonky KF6 packages available
- Adjust CMake to find the KDE Neon versions, then fix the C++ code
This commit adds support for LUKS2 behind a new `partition.conf` key:
`luksGeneration`.
A bit of context, LUKS2 is the default encryption operating mode since
cryptsetup >= 2.1.0 (See [Arch
wiki](https://wiki.archlinux.org/title/dm-crypt/Device_encryption#Encryption_options_with_dm-crypt).
It is considered more secured and allows additional extensions. It also
comes with Argon2id as the default Password Based Key Derivation
Function (`--pbkdf` option). So it's important to provide this as an
option for Calamares in order to make Linux installs more secure, for
those who wish to encrypt their system.
This commit was tested on a custom Manjaro installer with:
- grub bootloader with the [argon patches](https://aur.archlinux.org/packages/grub-improved-luks2-git).
- [rEFInd](https://wiki.archlinux.org/title/REFInd) bootloader with
unencrypted `/boot` partition because rEFInd [doesn't support booting
from an encrypted volume](https://sourceforge.net/p/refind/discussion/general/thread/400418ac/)
**Important consideration for distribution maintainers**:
- You need to have compile flag `WITH_KPMCORE4API` on
- If you are shipping with grub by default please note that you need to
ship it with the Argon patches. Example on Arch Linux: [grub-improved-luks2-git](https://aur.archlinux.org/packages/grub-improved-luks2-git)
- If `luksGeneration` is not found in partition.conf, it will default to
luks1
- Please test this on your own distribution as this was only tested on
Manjaro installer (see above).
Since this CMakeLists.txt writes out a C program, the formatting
is a bit weird; just start the written TU with a blank line to
make gersemi happy and keep the C-code aligned.
- FileSystem.h depends on KPMcore and only compiles when
KPMcore is present; it can use KPMcore identifiers.
- Global.h doesn't.
- Move the few functions introduced into Global.h that need
KPMcore, to FileSystem.h instead.
When KPMcore is present, the calamares::kpmcore wraps that
and provides suitable API detection. If KPMcore is not
present, the same interface library provides -DWITHOUT_KPMcore.
