With the GPU shortage, I had been waiting for prices to come back to reasonable levels before buying a new GPU. So far, I had always bought NVIDIA GPUs as I was using Windows to run games and the NVIDIA drivers had a better “reputation” than the AMD/Radeon ones.
With Valve’s Proton seriously taking off thanks to the Steam Deck, I wanted to get rid of the last computer in the house that was running Microsoft Windows, that I had kept only for gaming.
But the NVIDIA drivers story on Linux had never been great, especially on distributions that move kernel versions quickly to follow upstream releases like Fedora. I had tried using the NVIDIA binary drivers on Fedora Kinoite but quickly ran into some of the issues that we have listed in the docs.
At the time, the Universal Blue project did not exist yet (Jorge Castro started it a bit later in the year), otherwise I would have probably used that instead. If you need NVIDIA support today on Fedora Atomic Desktops (Silverblue, Kinoite, etc.), I heavily recommend using the Universal Blue images.
Hopefully this will be better in the future for NVIDIA users with the work on NVK
So, at the beginning of last year (January 2023), I finally decided to buy an AMD Radeon RX 6700 XT GPU card.
What a delight. Nothing to setup, fully supported out of the box, works perfectly on Wayland. Valve’s Proton does wonders. I can now play on my Linux box all the games that I used to play on Windows and they run perfectly. Just from last year, I played Age of Wonders 4 and Baldur’s Gate 3 without any major issue, and did it pretty close to the launch dates. Older titles usually work fairly well too.
Sure, some games require some little tweaks, but it is nothing compared to the horrors of managing a Windows machine. And some games require tweaks on Windows as well (looking at you Cyberpunk 2077). The best experience is definitely with games bought on Steam which usually work out of the box. For those where it is not the case, protondb is usually a good source to find the tweaks needed to make the games work. I try to keep the list of tweaks I use for the games that I play updated on my profile there.
I am running all of this on Fedora Kinoite with the Steam Flatpak. If you want a more console-like or Steam Deck-like experience on your existing computers, I recommend checking out the great work from the Bazzite team.
Besides Steam, I use Bottles, Cartridge and Heroic Games Launcher as needed (all as Flatpaks). I have not looked at Origins or Uplay/Ubisoft Connect games yet.
According to protondb, the only games from my entire Steam library that are not supported are mostly multiplayer games that require some specific anti-cheat that is only compatible with Windows.
I would like to say a big THANK YOU to all the open source graphics and desktop developers out there and to (in alphabetical order) AMD, Collabora, Igalia, Red Hat, Valve, and other companies for employing people or funding the work that makes gaming on Linux a reality.
Happy new year and happy gaming on Linux!
]]>chsh
is a small tool that lets you change the default shell for your current
user. In order to let any user change their own shell, which is set in
/etc/passwd
, it needs privileges and is generally setuid
root
.
I am of the opinion that
setuid
/setgid
binaries are a UNIX
legacy that should be deprecated. I will explain the security reasons behind
that statement in a future post.
In this “UNIX legacy” series of posts, I am looking at classic setuid
binaries and try to find better, safer alternatives for common use cases. In
this post, we will look at alternatives to changing your login shell.
People usually change their default shell because they want to use a modern alternative to Bash (Zsh, fish, Oils, nushell, etc.).
Changing the default shell (especially to a non POSIX or Bash compatible one) might have unintended consequences as some scripts relying on Bash compatibility might not work anymore. There are lots of warnings about this, for example for the fish shell:
On Fedora Atomic Desktops (Silverblue, Kinoite, etc.), your preferred shell may not always be available, notably if you have to reset your overlays for an upgrade, and could lead to an unusable system:
So overall, it is a bad idea to change the default login shell for interactive users.
For non-interactive users or system users, the shell is usually set by the system administrator only and the user itself never needs to change it.
If you are using
systemd-homed
,
then you can change your own shell via the
homectl
command without needing setuid
binaries but for the same reasons as above, it
is still not a good idea.
If you want to use another shell than the default one, you can use the functionality from your graphical terminal emulator to start it by default instead of Bash.
I recommend using the freshly released Prompt (sources) terminal if you are running on Fedora Silverblue or other GNOME related desktops. You can set your preferred shell in the Profiles section of the preferences. It also has great integration for toolbox/distrobox containers. We’re investigating making this the default in a future version of Fedora Silverblue (issue#520).
If you are running on Fedora Kinoite or other KDE related desktops, you should
look at Konsole’s
profiles features. You
can create your own profiles and set the Command
to /bin/zsh
to use another
shell. You can also assign shortcuts to profiles to open them directly a new
tab, or use /bin/toolbox enter fedora-toolbox-39
as Command
to directly
enter a toolbox container for example.
This is obviously not an exhaustive list and other modern terminal emulators also let you specify which command to start.
If your terminal emulator does not allow you to do that, then you can use the alternative from the next section.
If you want to change the default shell for a user on a server, then you can
add the following code snippet at the beginning of the user’s ~/.bashrc
(example for fish
):
How to set this up was not really well documented so this post is an attempt at that.
First we will look at how to setup a GitHub workflow using GitHub Actions to build multi-architecture container images with buildah and push them to a registry with podman. Then we will sign those images with cosign (sigstore) and detail what is needed to configure signature validation on the host. Finally we will detail the remaining work needed to be able to do the entire process only with podman.
If you just want to get going, you can copy the content of my
github.com/travier/cosign-test repo
and start building and pushing your containers. I recommend keeping only the
cosign.yaml
workflow for now (see below for the details).
You can find those actions at github.com/redhat-actions.
Here is an example workflow with the Containerfile in the example
sub
directory:
This should let you to test changes to the image via builds in pull requests and publishing the changes only once they are merged.
You will have to setup the BOT_USERNAME
and BOT_SECRET
secrets in the
repository configuration to push to the registry of your choice.
If you prefer to use the GitHub internal registry then you can use:
You will also need to set the job permissions to be able to write GitHub Packages (container registry):
See the Publishing Docker images GitHub Docs.
You should also configure the GitHub Actions settings as follow:
redhat-actions/*,
In the “Workflow permissions” section, you can select the “Read repository contents and packages permissions” and select the “Allow GitHub Actions to create and approve pull requests”.
We will use cosign to sign container images. With cosign, you get two main options to sign your containers:
We will choose the the “self managed keys” option here as it is easier to setup for verification on the host in podman. I will likely make another post once I figure out how to setup keyless signature verification in podman.
Generate a key pair with:
Enter an empty password as we will store this key in plain text as a repository
secret (COSIGN_PRIVATE_KEY
).
Then you can add the steps for signing with cosign at the end of your workflow:
2024-01-12 update: Sign container images recursively for multi-arch images.
We need to explicitly login to the container registry to get an auth token that will be used by cosign to push the signature to the registry.
This step sometimes fails, likely due to a race condition, that I have not been able to figure out yet. Retrying failed jobs usually works.
You should then update the GitHub Actions settings to allow the new actions as follows:
redhat-actions/*,
sigstore/cosign-installer@*,
First, we copy the public key to a designated place in /etc
:
Then we setup the registry config to tell it to use sigstore signatures:
And then we update the container signature verification policy to:
If you do not plan on using container from other registries, you can even be stricter here and only allow your containers to be used.
/etc/containers/policy.json
:
See the full man page for containers-policy.json(5).
You should now be good to go!
Using this workflow, there is a (small) time window where the container images are pushed to the registry but not signed.
One option to avoid this problem would be to first push the container to a “temporary” tag first, sign it, and then copy the signed container to the latest tag.
Another option is to use podman to push and sign the container image “at the same time”. However podman still needs to push the image first and then sign it so there is still a possibility that signing fails and that you’re left with an unsigned image (this happened to me during testing).
Unfortunately for us, the version of podman available in the version of Ubuntu used for the GitHub Runners (22.04) is too old to support signing containers. We thus need to use a newer podman from a container image to workaround this.
Here is the same workflow, adapted to only use podman for signing:
This uses two additional workarounds for missing features:
redhat-actions/push-to-registry
Action does not support signing yet
(issue#89).
I’ve implemented support for self managed key signing in
pull#90.
I’ve not looked at keyless signing yet.You will also have to allow running my actions in the repository settings. In the “Actions permissions” section, you should use the following actions:
redhat-actions/*,
travier/push-to-registry@*,
The next steps are to figure out all the missing bits for keyless signing and replicate this entire process in GitLab CI.
]]>sudo
(a setuid binary) by using
SSH over a local UNIX socket.
I am of the opinion that
setuid
/setgid
binaries are a UNIX
legacy that should be deprecated. I will explain the security reasons behind
that statement in a future post.
This is related to the work of the Confined Users SIG in Fedora.
The main benefit of this approach is that it enables root
access to the host
from any unprivileged toolbox / distrobox container. This is particularly
useful on Fedora Atomic desktops (Silverblue, Kinoite, Sericea, Onyx) or
Universal Blue (Bluefin, Bazzite) for example.
As a side effect of this setup, we also get the following security advantages:
sudo
as a setuid
binary for privileged operations.Create the following systemd units:
/etc/systemd/system/sshd-unix.socket
:
/etc/systemd/system/sshd-unix@.service
:
Create a dedicated configuration file /etc/ssh/sshd_config_unix
:
Enable and start the new socket unit:
Add your SSH Key to /root/.ssh/authorized_keys
.
Install socat
and use the following snippet in /.ssh/config
:
Test your setup:
Let’s create a sudohost
shell “alias” (function) that you can add to your
Bash or ZSH config to make using this command easier:
2024-01-12 update: Fix quoting and array expansion (thanks to o11c).
Test the alias:
We’ll keep a distinct alias for now as we’ll still have a need for the “real”
sudo
in our toolbox containers.
As-is, this setup is basically a free local root for anything running under
your current user that has access to your SSH private key. This is however
likely already the case on most developer’s workstations if you are part of the
wheel
, sudo
or docker
groups, as any code running under your user can
edit your shell config and set a
backdoored alias for sudo
or run arbitrary privileged containers via Docker.
sudo
itself is not a security boundary as commonly configured by default.
To truly increase our security posture, we would instead need to remove sudo
(and
all other setuid
binaries) and run our session under a fully unprivileged,
confined user, but that’s for a future post.
To make it more obvious when commands are run as root, we can setup SSH authentication using U2F with a Yubikey as an example. While this, by itself, does not, strictly speaking, increase the security of this setup, this makes it harder to run commands without you being somewhat aware of it.
First, we need to figure out which algorithm are supported by our Yubikey:
If the value is 5.2.3
or higher, then we can use ed25519-sk
, otherwise
we’ll have to use ecdsa-sk
to generate the SSH key-pair:
Add the new sk-based SSH public key to /root/.ssh/authorized_keys
.
Update the server configuration to only accept sk-based SSH key-pairs:
/etc/ssh/sshd_config_unix
:
You can also further restrict the access to the UNIX socket by configuring classic user/group UNIX permissions:
/etc/systemd/system/sshd-unix.socket
:
1
2
3
4
5
6
7
8
...
[Socket]
...
SocketUser=tim
SocketGroup=tim
SocketMode=0660
...
Then reload systemd’s configuration and restart the socket unit.
Now that we have a working alias to run privileged commands, we can disable
sudo
access for our user.
Make sure that you have a backup and are able to boot from a LiveISO in case something goes wrong.
Set a strong password for the root
account. Make sure that can locally log
into the system via a TTY console.
If you have the classic sshd
server enabled and listening on the network,
make sure to disable remote login as root
or password logins.
wheel
/ sudo
groupsOpen a terminal running as root
(i.e. don’t use sudo
for those commands)
and remove you users from the wheel
or sudo
groups using:
You can also update the sudo
config to remove access for users that are part
of the wheel
group:
# Comment / delete this line
%wheel ALL=(ALL) ALL
To fully benefit from the security advantage of this setup, we need to remove
the setuid
binaries (sudo
and su
).
If you can, uninstall sudo
and su
from your system. This is usually not
possible due to package dependencies (su
is part of util-linux
on Fedora).
Another option is to remove the setuid
bit from the sudo
and su
binaries:
You will have to re-run those commands after each update on classic systems.
Setting this up for Fedora Atomic desktops is a little bit different as /usr
is read only. This will be the subject of an upcoming blog post.
Like most of the time with security, this is not a silver bullet solution that
will make your system “more secure” (TM). I have been working on this setup as
part of my investigation to reduce our reliance on setuid
binaries and trying
to figure out alternatives for common use cases.
Let me know if you found this interesting as that will likely motivate me to write the next part!
Fedora Onyx is a new variant using the Budgie desktop, with a (nearly) stock experience. It follows up on the Fedora Budgie Spin which has been introduced in Fedora 38.
The experience is similar to other Fedora Atomic Desktops (what’s that? see below 🙂): ships toolbx out-of-the-box and access to Flatpaks.
We will hopefully re-brand it from “Onyx” to “Fedora Budgie Atomic” and later aspire at having the Atomic variant be the “Fedora Budgie” and have the “mutable” spin be re-branded.
We have created a new Special Interest Group (SIG) focused on (rpm-)ostree based desktop variants of Fedora (Silverblue, Kinoite, Sericea and Onyx). The “Fedora Atomic Desktops” name will also serve as an umbrella to regroup all those variants under a common name.
Note that the new name is still pending approval by the Fedora Council. A Fedora Change Request has been opened to track that for Fedora 40.
We will progressively centralize the work for this SIG in the fedora/ostree GitLab namespace. We already have an issue tracker.
Silverblue comes with the latest GNOME 45 release. Loupe replaces Eye of GNOME (EOG). For now, the new Flatpaks are not automatically installed on updates so you will have to replace EOG by Loupe manually.
Fedora Flatpaks are now available ppc64le and included in the installer.
For more details about the changes that comes with GNOME 45, see the What’s new in Fedora Workstation 39 on the Fedora Magazine.
Kinoite stays on Plasma 5.27. Plasma 6 is coming for Fedora 40.
A subset of KDE Apps is now available as Flatpaks from Fedora. They are built from Fedora RPM source and build options and are also available for all releases (not just the latest) and even other distributions due to the nature of Flatpaks.
Thanks a lot to Yaakov Selkowitz and the Flatpak SIG for making this happen!
With the Flatpaks being available in the Fedora remote, we have removed some apps from the base image: Okular, Gwenview, Kcalc. The Flatpaks are not installed on updates but you can install them from the Fedora Flatpak remote or from Flathub.
Fedora Flatpaks will be installed by Anaconda by default for new installations in Fedora 40.
No major changes this release.
Ostree commits are now built via rpm-ostree unified core mode. The main benefits are cleanups and stricter build constraints (that sometimes surface bugs in RPMs). This is also how Fedora CoreOS is being built right now.
This change should be completely transparent to users.
This is needed to get bootupd support and a step towards moving to ostree native container images (discussed below).
Adding bootupd support to Atomic Desktops will finally let users easily update their bootloader on their systems (issue#120). We needed the commits to be built using rpm-ostree unified core mode, which is a change that landed in Fedora 39.
We are now waiting on Anaconda installer fixes that are in progress. This should hopefully land in Fedora 40.
The idea behind Ostree Native Containers is to package ostree commits as OCI containers. The main benefits are:
You can take a look at the following examples that take advantage of this functionality:
Work is currently in progress to add support to build those images via Pungi. Initially, they will be built alongside the current ostree commits. This is currently planned for Fedora 40 (the change page needs to be updated / rewritten).
We will be looking at fully transitioning to containers in a future release.
Those projects build on the in-progress support for the Ostree Native Containers format and the Fedora Atomic Desktops images. All the changes that are included are made via Containerfiles/Dockerfiles.
They include lots of options, offer a wide choice of images, include additional fixes, enable more platform support, UX fixes, etc.
Universal Blue is the general project, Project Bluefin is the developer focused one and Bazzite is focused on gaming, including on the Steam Deck and other similar devices.
Check them out!
Help us make that happen! One notable missing part is support in Kiwi (issue#38) to build the images. See Fedora Asahi Remix for more details.
We are looking for contributors to help us make the Fedora Atomic Desktops the best experience for Fedora users.
Update: We’ve merged KDE 6 / Plasma 6 packages to Rawhide so Kinoite Nightly builds will be paused again. You can follow the progress in Kinoite via the Rawhide container images or the classic ostree refs.
How to switch back to Rawhide:
Thanks to the packaging efforts of the members of the KDE SIG (especially Alessandro Astone, Justin Zobel and Steve Cossette), we now have enough updated packages in Fedora to create Fedora Kinoite nightly images with KDE Plasma 6.
KDE Plasma 6 is currently in Alpha and those images are based on Fedora Rawhide, which is the development stream of Fedora and may include bugs or breaking changes at any time.
So this should be obvious but in case it needs to be said: This is pre-release software that may include major bugs. Only use this on systems where you are confident you will be able to rollback and have backups of your collection of favorite cat pictures. You’ve been warned!
If you find bugs, you are welcomed to report them to KDE developers on bugs.kde.org or to the KDE SIG tracker. See also the upstream known issues page.
We currently do not have installation ISOs or pre-installed images available. To try it, you can follow those steps:
1. Install Fedora Kinoite 39.
2. Update to the latest version and reboot:
3. Pin your current deployment to make sure that you will be able to rollback if something fails:
4. Switch to the Fedora Kinoite Nightly Plasma 6 image:
5. Test and report bugs!
You can find all tags for those images at quay.io/fedora-ostree-desktops/kinoite-nightly.
Feel free to drop by the Fedora KDE Matrix room.
]]>While this talk is focused on KDE software and Fedora Kinoite, most the concepts described here also apply to other Flatpak’ed applications (notably GNOME ones) and other rpm-ostree based desktops (Silverblue, Sericea, Onyx, etc.).
Software has bugs! One way to find bugs is to have users test changes.
To make that possible, we need to deliver pre-release versions of our software in a way that is accessible to our users which are usually not developers.
Remember that even as a developer, you are always the user of someone else’s project. The technology stack is now so complex that it is mostly impossible to understand every single projects included in a modern desktop environment, even if it is fully open source.
Testing pre-release software also has to be reasonably safe regarding user’s data, as it’s often not practical to ask users to backup everything all the time and testing a small fix for an application should not have your entire system crash.
Users must also be able to go back to state where their system is running only “stable” software again, after they have completed testing a change or a fix.
Ideally, we would let users test all changes before they are commited to a repo, during the merge request process. But sometimes this is too difficult and we should then enable them to test those changes as soon as possible after they are commited.
We’re now publishing most of KDE Apps as Flatpaks on Flathub. We track the latest stable releases. Updates are directly shipped to users.
See Albert Astals Cid’s talk (Flatpak and KDE) for more details about Flatpak, how they work and how we use it for KDE Apps.
On Flathub, the pull-request workflow is enforced. Each PR will build a “test” Flatpak. This Flatpak is installed using a single command.
This let’s developer create Flatpaks with fixes for users to test on top of stable releases.
Below is a demo of testing a Flatpak fix from Flathub:
Transcript of the video:
# Go to PR: https://github.com/flathub/org.kde.gwenview/pull/97
# Download Flatpak:
$ flatpak install --user \ https://dl.flathub.org/build-repo/35177/org.kde.gwenview.flatpakref
# Run Flatpak
$ flatpak --user run org.kde.gwenview
# Run Gwenview from the host to compare versions
$ gwenview
# Cleanup
$ flatpak --user uninstall org.kde.gwenview
We are progressively setting up the same infrastructure in KDE GitLab instance (invent.kde.org) using GitLab CI.
Flatpak manifests are directly stored in application’s repos. Every pull request creates a Flatpak bundle to try out.
This let’s user test fixes and features before the change is merged.
Below is a demo of testing a Flatpak from GitLab CI:
Transcript of the video:
# Go to PR: https://invent.kde.org/graphics/gwenview/-/merge_requests/208
# Download the artifact:
$ curl -O https://invent.kde.org/graphics/gwenview/-/jobs/1041125/artifacts/download?file_type=archive
# Unzip and install the Flatpak bundle
$ unzip Flatpak_artifacts.zip
$ flatpak --user install --bundle ./gwenview.flatpak
# Run the Flatpak
$ flatpak --user run org.kde.gwenview
# Cleanup
$ flatpak --user uninstall org.kde.gwenview
Flatpak content is stored in an ostree repo. Similarly to a Git repo, you can fetch any previous build to test regressions or compare behavior. This works with Flatpaks from Flathub.
Note that apps strictly tied to Qt versions will also need an older Runtime.
Below is a demo of bisecting a Flatpak from Flathub:
Transcript of the video:
# Install a Flatpak from Flathub
$ flatpak --user install org.kde.kcalc
# Look at the log of versions (ostree commit log)
$ flatpak --user remote-info --log flathub org.kde.kcalc | less
# “Checkout” an older version
$ flaptak --user update --commit=... org.kde.kcalc
# Run the older version
$ flatpak --user run org.kde.kcalc
# Reset to latest version (note: operation canceled)
$ flapak update
# Skipping updates for a Flatpak
$ flatpak --user mask org.kde.kcalc
# Testing updates again
$ flapak update
# Removing the mask
$ flatpak --user mask --remove org.kde.kcalc
# Listing masks
$ flatpak --user mask
# Cleanup
$ flatpak --user uninstall org.kde.gwenview
Fedora Kinoite is a Fedora variant featuring the KDE Plasma desktop. It follows the latest upstream KDE releases. It is stable and based on an up to date software stack from Fedora: Wayland, Pipewire, systemd user sessions, etc.
Fedora Kinoite brings the concept of an immutable desktop operating system, which means that you control when your system is changed.
The system is focused on Flatpak and container based workflows.
See my previous talk at Akademy: Akademy 2021: Kinoite, a new Fedora variant with the KDE Plasma desktop (slides, video).
The system is shipped as a single consistent image. The updates are performed atomically: either fully applied or not, thus there are no broken updates and your system is always in a working state.
System updates (rpm-ostree) keeps all your data and Flatpak apps as-is. It makes it easy to rollback to a previous known good version.
You also have access to package diff between versions.
rpm-ostree is now capable of delivering operating system images as a container images. This lets you manage operating system versions with containers tags.
You can store each version of your operating system inside a container registry and rebase your system to almost any version.
Below is a demo of rebasing to a container on Kinoite:
Transcript of the video:
# Looking at current state
$ rpm-ostree status
# Find the version to rebase to in the repo on Quay.io:
https://quay.io/repository/fedora-ostree-desktops/kinoite?tab=tags
# Rebase to this version
$ sudo rpm-ostree rebase \
ostree-unverified-registry:quay.io/fedora-ostree-desktops/kinoite:38.20230710.xyz
$ reboot
# Package diff
$ rpm-ostree db diff
# Cleanup and rollback
$ rpm-ostree cleanup
$ rpm-ostree rollback
See Introducing Kinoite Nightly (and Kinoite Beta).
The builds for those images are currently paused (waiting for Plasma 6).
We’re working on it! We’ll make Fedora Kinoite Nightly images, with Plasma 6 packages, on top of stable Fedora.
Hopefully coming soon!
Could we do pre-merge checks? Testing with OpenQA?
Running OpenQA tests for each Plasma PR is likely to create too much overhead, but maybe we can do daily or weekly checks?
Bringing RPM specfiles to Git Repos and building then in GitLab CI would significantly help with Fedora Kinoite Nightly and Beta efforts for testing.
Happy testing!
]]>Note: This checklist may not be fully exhaustive and I’ll likely update it as needed. Feel free to send me suggestions.
First, you should figure out what packages should be installed in your image. To do that, you can start from the base container image that already includes the packages common to all variants. You can then add packages from the comps group corresponding to your desktop in Fedora.
At this point, you should consider which apps are going to be shipped by default, included in the image, and which ones are going to be installed by default as Flatpaks.
Take a look at the Universal Blue project for examples on how to do container based variants.
Once you’ve got something working, reproduce that in the workstation-ostree-config repo using the comps group, the exclude list and the filter and sync script. Look at other variants for example.
Always start from Rawhide, or use the latest stable Fedora release to test but submit the PR to Rawhide. I’ll likely review it then.
Once the PR is merged, we’ll enable test builds in the unofficial CI hosted on GitLab.com in the fedora/ostree namespace.
This will get you container images in the fedora-ostree-desktops quay.io organization. With those, you can start building uBlue images and ISOs and test things more (including the installation).
When things are in good shape, you can move to the next step!
Then, let’s make it official!
Now you need to submit a change request to Fedora to request this new variant to be added to the official Fedora composes. Follow the steps to make a Fedora Change Request.
You can use the last three change requests as example:
You will have to pick a name for your variant and request legal review for it. You can not reuse existing names or call your variant “Silverblue FooBar”.
Once your change as been accepted, you can move to the next steps.
fedora-release
You then have to create a new sub package as part of fedora-release
to give
your new edition a distinctive identity in /etc/os-release
.
Once the new sub package is merged and built, you can add it to the rpm-ostree manifests.
To get official builds of your variant, you will have to add the confirmation to enable them in Rawhide. It’s mostly copy pasting and tweaking the existing configuration for other variants. See:
fedora-pungi
config repo:
You’ll want to make sure that the apps that you want to install by default as Flatpaks are available as Fedora Flatpaks. Reach out to the Flatpak SIG if you need help. You can not use Flatpaks from Flathub. See the Fedora Flatpak and SIG FAQ.
Then you’ll have to make a docs repo. You can start from the Silverblue
one and then make a PR
to the docs website
repo
(start with stg
then prod
once released) to have it built and hosted on the
Fedora docs site.
Finally, you can add a page for your variant to the new Fedora website. Use the Silverblue, Kinoite and Sericea pages as example.
Happy composing and rebasing!
]]>Since the last “State of Fedora Kinoite” post was a while ago, here is a summary of the changes in this release and a look at what is coming in the next releases.
See my longer post on the topic (with lots of screenshots!). This is also included in Fedora Kinoite 37 so you can update to the latest Fedora Kinoite 38 release using Discover.
If you prefer to do it manually, you can follow the commands from the How to
rebase to Fedora Linux 38 on
Silverblue
article, replacing silverblue
with kinoite
. Make sure to fully update your
system before rebasing.
We have added Filelight, KFind and Krfb directly to the base image as they either not useful as Flatpaks or their functionality is too limited by the sandbox.
We removed initial-setup
and anaconda
from the base image as it was causing
weird error messages on the first boot. In the future, a more KDE native
replacement should let us do OEM installations for Kinoite. See the Fedora
change for more
details.
We have included the latest version of the Plasma desktop (5.27.4), the latest version of KDE Gear (22.12.3) and the second to last KDE Frameworks release (5.104.0, soon updated to the latest release).
This includes the new Flatpak KCM which lets you configure the permissions that are granted your Flatpak applications. This is the result of a Season of KDE and GSoC project completed by Suhaas Joshi that I co-mentored with Aleix Pol i Gonzàlez.
With the work done upstream in SDDM to support using a Wayland based greeter and the introduction of SimpleDRM to fix the broken fallback when platform drivers are unavailable, it is now possible for the Fedora KDE variants (the regular spin and Kinoite) to move to Wayland for the login manager, which effectively completes the switch to Wayland for these variants.
See the Fedora change for more details.
Those are other under-the-hood changes that come from Fedora:
A notable bug resulting in an unusable desktop when selecting the UTC/GMT timezone was fixed a while back in Fedora Kinoite 36.
KDE Apps have been available primarily from Flathub for now and if that works well for you then there is no need to change anything.
We however can not include applications from Flathub as pre-installed applications in Fedora. We thus need Fedora Flatpaks for that. The newly formed Flatpak SIG and Yaakov Selkowitz in particular did a lot of work to make that happen for KDE Apps. We will thus likely be able to add those applications to the default installation of Fedora Kinoite in the Fedora 39 release.
If you are interested in using those Flatpaks, we are looking for maintainers. Note that this is a different process than maintaining applications on Flathub or RPMs and requires less effort. Hopefully it will be automated in the future.
We want to make it easier to use the new unfiltered Flathub view by adding it in Plasma Welcome and Discover. See issue #295 for details.
We have started working on Plasma 6 builds and once this reaches a working state, we will have Kinoite Nightly builds to try it out. Kinoite Nightly is thus temporarily not updated until this happens. See issue #13 for details.
With the rpm-ostree support in good shape in Discover, we are now looking at enabling auto-updates by default for Flatpaks and the system in Discover. See the draft Fedora change and issue #342 for details.
Those are core changes that will let us to things more easily in the future:
With the new Fedora website now live, we want to merge the currently independent Fedora Kinoite website to benefit from the new design and offer a coherent layout across all Fedora variants.
This is a good way to help us if you have Javascript or HTML/CSS knowledge.
Here are two good issues to get started in KDE development that will benefit Fedora Kinoite:
Feel free to reach out to me if you need mentoring.
Feel free to drop by the Fedora KDE channel, the Fedora Kinoite channel, asks questions or start a development discussion in the Fedora forums, or open an issue in the KDE SIG tracker.
]]>Update: Kinoite Nightly & Beta images are temporarily paused while we work on making Kinoite image with Plasma 6 content available.
As announced during the Fedora Kinoite “Hello World!” talk (slides) last year at the Fedora 35 release party, one of the goals for Fedora Kinoite is to make it easier for everyone to try and test the latest KDE Plasma desktop and Apps, without having packaging, compiler or development knowledge.
We are now much closer to that goal with the introduction of Kinoite Nightly, an unofficial variant of Fedora Kinoite based on stable Fedora plus nightly packages for KDE software (Plasma desktop and a base set of apps).
Alonside Kinoite Nightly, we are also introducing Kinoite Beta, which is also an unofficial variant of Fedora Kinoite, also based on stable Fedora but with KDE Plasma Beta packages. This variant is based on fresh release of KDE Plasma 5.27 Beta.
While the Nightly variant will be built daily and will always be available, the Beta variant will only be built and available during KDE Plasma Beta testing phases.
All of this is only made possible by the very good work of the Fedora KDE SIG members that maintain KDE packages for Fedora, including those nightly packages.
Those variants are built daily and published as a container image hosted in repos on Quay.io:
Warning: This should be obvious but in case it needs to be said: This is pre-release software that may include major bugs. Only use this on systems where you are confident you will be able to rollback and have backups of your collection of favorite cat pictures.
Additionaly for Kinoite Nightly: The functionnality, features, bugs might change at any time and there is no guarantee of compatibility or stability.
If you find bugs, you are welcomed to report them to KDE developers on bugs.kde.org or to the project on GitLab.
We currently do not have installation ISOs or pre-installed images available. To try it, you can follow those steps:
1. Install the latest official Fedora Kinoite release.
2. Update your system to the latest version and reboot:
3. Pin your current deployment to make sure that you will be able to rollback if something fails:
4. Switch to either Kinoite Nightly or Kinoite Beta:
5. Test and report bugs!
Note: This mostly applies to Kinoite Nightly as Kinoite Beta is made from released Beta sources.
You can figure out exactly which commit is included in the image by looking at
the Git short hash included at the end of the package versions (right before
-1.fc37.x86_64
which is the revision, major release and architecture):
As the images are rebuilt daily, you can also fetch a version that was built on a specific date. You can see all builds (tags) in the repos on Quay.io:
To do that, you need to specify the tag referencing the container image to
fetch with the rebase
command:
This should make it much easier to bissect regressions that impact a lot of components, either in KDE packages themselves or in their dependencies.
You can also diff the list of package between two versions with:
Or override a specific package with another version or your own build with custom patches for example:
Just like Fedora Kinoite, most applications should run just fine as Flatpaks, and we’re working on making most of them available on Flathub (we’re really close now). To be able to test development versions of those apps, you can try them via the Nightly Flatpak repo hosted by KDE.
This single repo might go away or be reworked once we are able to fully move to GitLab CI based builds for Flatpak apps. You’ll be able to get Nightly Flatpak builds for applications directly from the KDE Invent GitLab instance.
See also my post about the future for Flatpak support and integration in KDE.
Feel free to drop by the Fedora KDE channel or to open an issue if you have feedback, suggestions or questions.
]]>