this should bring it in alignment with the vacuum-v3 handling and fix
the sha256sums location coming out of that to match our expectation.
hopefully making the pipeline green again
These were formerly supported as encryption backends for Plasma Vaults.
Nowadays only gocryptfs is supported for new vaults, though the other two
remain supported for compatibility with older vaults, so it can be nice
to keep them around.
However anyone migrating to KDE Linux needs to do a re-install anyway,
and if they migrate their data, they'll have to do it manually. Thus
it's reasonable for anyone who's enough of an expert to accomplish this
to migrate any old vaults they have to the supported gocryptfs backend.
Thus, get rid of the two legacy backends.
---
Bonus commit: stop asking for gocryptfs explicitly, since it's a mandatory dependency of plasma-vaults and thus gets pulled in automatically
The openqa image will be mounted here, so systemd will have already created the directory. Add -p option and split so it doesn't fail if this is the case.
Our choice of the Zen kernel was a bit random and speculative. So far we
have a report that it hurts something, and no reports that it helps
anything.
Over time the differences between the Zen kernel and the vanilla one
have dwindled, and I can barely find an up-to-date list of the
differences without looking through source code.
I would consider the upstream vanilla sources to be safer and more
trustworthy, and I expect will be much easier to get through shim
review. Let's return to them.
This also adds vhba-module as it is required for cdemu-client;
apparently it was built into the Zen kernel, but it's separate for the
vanilla one.
Resolves#601
We don't need the userspace FUSE-based ntfs-3g driver because the kernel
includes one for reading and writing to NTFS. However we do need the
command-line NTFS tools for Partition Manager. So just keep those.
Because ntfs-3g was the last thing depending on fuse2, manually add it
back, because we don't want to break a bunch of old AppImages. Put that
as well as some other app-enablement-related packages to a new group in
Core.
vpl-gpu-rt is only needef tro specialized workloads using Intel's OneVPL
library, which almost nothing is.
This package requires intel-media-driver, which is what we actually
want, so specifically ask for that instead.
This will make us fail shim review.
I only added it in the first place to work around a driver issue on my
wife's laptop, but it was fixed upstream soon afterwards anyway — a
testament to the value of properly reporting issues rather then
empowering people to silently work around them.
It's a source of vulnerability, most recently the "Copy Fail"
vulnerability (CVE-2026-31431). That one is already fixed, but according
to Google crypto guy Eric Biggers [1], it's vulnerable by design. The
only significant things it's used for (iwd and non-default cryptsetup
algorithms) aren't supported in KDE Linux, so let's disable and remove
this functionality.
[1] https://news.ycombinator.com/item?id=47956312
Ours was 00-; Arch's is 10-; as a result Arch's config is taking
precedence over ours!
This mostly doesn't matter except for `fs.inotify.max_user_instances`,
which is set in both. Because Arch's file wins, the value is currently
stuck at 1024 instead of the 8192 value we intended.
If the user uses ssh-agent.service, everything will Just Work™. If they
don't, whatever online guide they're following will have instructed them
to set SSH_AUTH_SOCK in their rc file, and it will override this.
Related to #555
It's unclear why this was added and what use it has for normal users of
a general-purpose desktop OS. Until that can be re-established, remove
it from the image.
