Kinoite, a KDE (and now XFCE) version of Fedora Silverblue

Project Discussion
,
1

Hi!

This is proof of concept project to build a KDE based version of Fedora Silverblue. I called it Kinoite because it had to start with a ‘K’ and Kinoite is a blue mineral.

The resulting desktop only has Firefox and Konsole as main applications installed by default (the minimum for easy Flatpak/Flathub usage).

This has only been tested inside a virtual machine for now, so use at your own risk!

Instructions to try it out on an already installed Fedora Silverblue system:

curl -O https://tim.siosm.fr/downloads/siosm_gpg.pub
sudo ostree remote add kinoite https://siosm.fr/kinoite/ --gpg-import siosm_gpg.pub
sudo ostree admin pin 0
sudo rpm-ostree rebase kinoite:fedora/28/x86_64/kinoite

Instructions to build your own:

git clone https://pagure.io/fork/siosm/workstation-ostree-config
sudo rpm-ostree compose tree --repo=ostree_repo --cachedir=ostree_cache workstation-ostree-config/kinoite.json

The changes are available in the following repositories:

https://pagure.io/fork/siosm/fedora-comps (master)
https://pagure.io/fork/siosm/workstation-ostree-config (f28-kinoite branch)

Unfortunately, the current configuration layout makes it hard to switch base packages without duplicating the entire config tree. Thus the Kinoite config is simply a copy of the Silverblue one and is not integrated at all.

Thanks a lot to all of you! The Fedora & Silverblue projects are looking great!

Hope you like it!

27 Likes
2

Thanks for working on this! Supporting something like this was actually part of the rpm-ostree design from the very start; especially now that package layering works as well as it does, being able to rpm-ostree rebase between the different base images I think makes so much more sense than the “sea of packages” approach.

Do you want to try factoring out something like “base desktop bits” in the workstation-ostree-config repo?

7 Likes
3

I was indeed planning to work on that.

As the base package lists are currently based on Fedora comps groups, I had to make various changes to them to make my variant. Should I submit them as pull request to the comps pagure repo or is there a more formal process to make changes to them?

Thanks.

4

@walters I also noticed that rpm-ostree/ostree server side operations (install, compose) are single core CPU bound as rpm-ostree seems to be single threaded. Profiling using perf quickly pointed out zlib as the main culprit for most time spent during the compose step. Using a parallel algorithm like lz4, zstd or snappy might significantly improve performance without losing on the compressed size side.

Edit: or maybe zchunk as support is going to be included in dnf?

5

@walters I reworked most of the treefiles in the workstation-ostree-config repo to split out the list of packages common to all desktop variants. I pushed a new version of the changes required to support multiple desktop variants at https://pagure.io/fork/siosm/workstation-ostree-config (f-28 branch). I dropped the changes I made to the Fedora comps for now.

I will reproduce those changes in master and will submit a pull request if this looks good to you. Edit: I’ve pushed those changes to master too: https://pagure.io/fork/siosm/workstation-ostree-config (master).

Moreover, there is now an additional variant to try out, with an XFCE desktop!

And finally, I pushed all the trees I built on my server, thus one may try them out those using:

$ sudo rpm-ostree rebase kinoite:fedora/28/x86_64/silverblue  # GNOME version
$ sudo rpm-ostree rebase kinoite:fedora/28/x86_64/kinoite  # KDE version
$ sudo rpm-ostree rebase kinoite:fedora/28/x86_64/fedora-xfce  # XFCE version

Again, this has only been tested inside a virtual machine and not on a real system. But the desktops looks good and are properly working as far as I have tested.

4 Likes
6

That is pretty awesome, I hope we’re able to push this onwards to make it an official thing. Great job, thanks for that!

3 Likes
7

Yeah, let’s do a PR. You’ll need to rebase though, I did it locally and the conflicts weren’t too bad.

One thing I noticed is you pushed forward with dropping apps by default; I think this is the right call, but people will notice when rebasing.

Also, locally I added a small commit on top:

From e8b688ca6a34858bc105e2881f114b9d898b7653 Mon Sep 17 00:00:00 2001
From: Colin Walters <walters@verbum.org>
Date: Sat, 28 Jul 2018 19:08:26 +0000
Subject: [PATCH] Keep "workstation" branding for now

Changing this is going to require coordinated changes to
https://pagure.io/pungi-fedora
---
 fedora-atomic-workstation.json | 1 +
 silverblue.json                | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 120000 fedora-atomic-workstation.json

diff --git a/fedora-atomic-workstation.json b/fedora-atomic-workstation.json
new file mode 120000
index 0000000..f615e78
--- /dev/null
+++ b/fedora-atomic-workstation.json
@@ -0,0 +1 @@
+silverblue.json
\ No newline at end of file
diff --git a/silverblue.json b/silverblue.json
index adcb7b7..5990275 100644
--- a/silverblue.json
+++ b/silverblue.json
@@ -1,5 +1,5 @@
 {
-    "ref": "fedora/rawhide/x86_64/silverblue",
+    "ref": "fedora/rawhide/x86_64/workstation",
     "repos": ["fedora-rawhide"],
     "automatic_version_prefix": "29",
     "mutate-os-release": "29",
-- 
2.17.1
8

One thing I’d say related to all of this is that I’d like for Silverblue to use rojig mode by default. I’ve been doing some prep work around that that I can land after we merge your PR - I think it will make it substantially less maintenance burden for rel-eng to have more variants.

9

And if you have a bit of time to play with rojig it should make it easier for you (or others) to host derivatives, testing builds etc. as you can just have people reuse the base packages from the primary repo mirrors. See the spec file in fedora-atomic, then the bit "ex-jigdo-spec": "fedora-atomic-host.spec", in the treefile, and the rpm-ostree compose tree --ex-rojig-output-set option.

But that said I’d like to soon add this to the Silverblue default configs and that will make it all more obvious how it works. (And make it not-experimental fairly soon)

10

OK, I merged this to master and made some more fixups on top. Whether we add these variants to releng is another story, but at least it’s easier for people to build locally. We’re going to have to do some comps pruning to make this more sustainable. Thanks for the patches, let me know if master works well for you, and keep the patches coming!

1 Like
11

Great! I’m working on various fixups and I’ll push them soon.

12

Is there any update on this? I couldn’t find a KDE Plasma branch for F29 or Rawhide, thanks.

1 Like
13

As far as I know there is no official support. I will update & upload a fresh version on my server soon (no promise), and I will try to automate it. Otherwise, you should be able to build your own using the instructions from the first post.

1 Like
14

Thanks, I’ll test and try to build :slight_smile:

15

Maybe there is some Fedora infrastructure already available for this?

16

I’ve (finally!) updated my mirror (now comes with branches for 29, 30 and rawhide) and I’ve added a LXQt variant (see PRs: 138, 139, 140).

Again, this has only been tested inside a virtual machine for now, so use at your own risk! Moreover this time, I pushed 12 refs (3 versions x 4 variants) so I have not tested them all! (I think rawhide is broken right now).

I’ve automated most of the work so I should be able to produce updates regularly. I am still learning the details of ostree management thus bare with me while I sort out version history handling and naming logic.

I have published the scripts I am using to build all those variants and I am planning on automating tests using Packer & Vagrant.

2 Likes
17

Just in time for Fedora 30 Beta, I have added DeepinDE & Patheon Desktop variants (see PRs 144 & 145) to try out and test before the final release!

I have also updated my mirror and added those branches if you want to try them out.

2 Likes
18

@siosm can this be installed by terminal as usual?

19

Yes. See those updated commands:

curl -O https://tim.siosm.fr/assets/siosm.gpg
sudo ostree remote add kinoite https://siosm.fr/kinoite/ --gpg-import siosm.gpg
sudo ostree admin pin 0
sudo ostree remote refs kinoite
sudo rpm-ostree rebase kinoite:fedora/30/x86_64/deepin

And I’ve just realized I forgot to sign the latest update :sweat_smile:. I’ll fix it this evening.

2 Likes
20

Cool thx a lot
Okay I’ll wait for it - but actually it’s going to update :slight_smile: therefore it’s alright