Related to https://pagure.io/fedora-kde/SIG/issue/4

Can we focus on having 1 good set of apps packaged? It's already a considerable amount of work to maintain flathub, let alone telling our users that they have different experiences to choose from.

One of the issues we have is that we can't really ship stuff from Flathub on our media. There are some technical and legal issues that are difficult to resolve. This was something that Fedora Workstation ran into, and basically now each app has to be qualified as an app we can't ship and isn't encumbered for making it available by default.

I'm assuming these KDE apps will be shipped to the Fedora OCI registry. Like @apol mentioned if we can come up with a good list I'm happy to help get some flatpaks submitted.

Yes, those packages will be shipped from the Fedora OCI registry just like in Silverblue.

Here is a non-exhaustive list of KDE Apps that I think we should ship installed by default as Flatpak in Fedora Kinoite:

• Kcalc
• Ark
• Gwenview
• kwrite and/or Kate
• Okular
• Elisa
• Neochat
• Konversation / Telepathy (?)
• Kontact / KMail
• Dragon Player

Lesser priority, will not ship installed by default but would be good to have:

• KTorrent
• Marble
• KDevelop
• Okteta
• K3B

Can we focus on having 1 good set of apps packaged? It's already a considerable amount of work to maintain flathub, let alone telling our users that they have different experiences to choose from.

Also note that due to the way Flatpaks are built in Fedora, this is not duplicating the work done for RPMs nor a simple copy paste from Flathub.

The only portion that will required maintenance once the Flatpaks are published is the list of permissions allowed for each app which not something that changes regularly for most apps.

I'd like to suggest Kdenlive for the "low priority" list, too.

I'd like to suggest Kdenlive for the "low priority" list, too.

Sure, but I think we need ffmpeg for anything in Kdenlive to work and as far as I know kdenlive isn't even packaged in Fedora due to this issue.

Sure, but I think we need ffmpeg for anything in Kdenlive to work and as far as I know kdenlive isn't even packaged in Fedora due to this issue.

Oh, you're right. I was thinking I got it from the Fedora repos, but I did not. Nevermind. :-)

Sure, but I think we need ffmpeg for anything in Kdenlive to work and as far as I know kdenlive isn't even packaged in Fedora due to this issue.

Oh, you're right. I was thinking I got it from the Fedora repos, but I did not. Nevermind. :-)

One day, my friend... :persevere:

Hello, I was working on kcalc package for flatpak and did PR(s)

https://src.fedoraproject.org/rpms/kf5-kconfig/pull-request/2
https://src.fedoraproject.org/rpms/kf5-attica/pull-request/2

I disabled docs because as I understand "gnome" side did the something as well, so I decided to go disable them as well

Another thing about how did we handle user services ( _userunitdir) and looking in bugzilla and packages I found this : https://bugzilla.redhat.com/show_bug.cgi?id=1728303

Hopefully will be useful as well.

@thunderbirdtr Can we fix the doc location / macro so that we avoid changing every single kf5 package for Flatpaks?

Let's talk about this PRs at the meeting today.

Another option would be to not install the documentation for Flatpak builds similarly to what's done in https://src.fedoraproject.org/rpms/evolution-data-server/pull-request/4#request_diff

(Pagure UI got confused with tags)

I sent the request;

https://src.fedoraproject.org/rpms/flatpak-rpm-macros/pull-request/5

Flatpak module issue;
https://pagure.io/flatpak-module-tools/issue/14

Kde-settings PR;
https://src.fedoraproject.org/rpms/kde-settings/pull-request/4

kf5-kglobalaccel PR;
https://src.fedoraproject.org/rpms/kf5-kglobalaccel/pull-request/1

@siosm I pushed my changes to fork repo so this is my working version kcalc

https://pagure.io/fork/thunderbirdtr/travier_flatpaks/kcalc

I removed sgml-common and fedora backgrounds package from yaml also change ref update to fedora34 some of the refs are rawhide(basically branch name) because, that's changes I sent to src.fp.org

Also, thank you @rdieter for doc disable patch

It seems that Silverblue doc recommends using flathub in their doc. Couldn't we do the same and just add the minimum required list of software to the fedora flatpak repo? https://docs.fedoraproject.org/en-US/fedora-silverblue/getting-started/

Oh it seems we have the doc too https://docs.fedoraproject.org/en-US/fedora-kinoite/getting-started/ :)

The documentation will be adjusted as things are beefed up more. Additionally, we're working on a filtered Flathub view to preload by default, which means that we will eventually drop the recommendation to configure Flathub by default.

Flathub applications cannot be preloaded and we cannot rely on Flathub for apps that we will support.

Summary for those that want to get involved "upstream":

• List of in progress apps for Flathub (not for Fedora directly, but having them on Flathub makes Fedora packaging much simpler): see HackMD link in the next post.
• Upstream "master" Flatpaks for most apps that need some tweaking: https://invent.kde.org/packaging/flatpak-kde-applications
• Ping me (@travier) and the @flathub/kde team on PRs for review

Same list as the Google Doc converted to a HackMD: https://hackmd.io/NGP9BybWSre-juT6tI4c2A

Submitted that as a project idea for GSoC or Outreachy: https://pagure.io/mentored-projects/issue/126

Edit: it turned out that this was not a good idea for those programs as it is not coding related enough.

I'm removing myself as the assignee for this issue. Building Flatpaks in Fedora is a significant project, I don't have the time to do it and I would prefer to spend my time improving KDE Flatpaks published on Flathub.

This a list of what's required to be done to make that happen:

• Figure out how to ship a Platform with KDE libs included, either on the side or on top of the existing Fedora Platform: https://src.fedoraproject.org/flatpaks/flatpak-runtime
• Create Flatpak versions for apps listed in https://pagure.io/fedora-kde/SIG/issue/13#comment-721179 (at the minimum)
• Re-add the Platform and add the apps to Kinoite. See https://pagure.io/pungi-fedora/pull-request/1133.

But that alone won't make Fedora Flatpak interesting (compared to Flathub) and will require ongoing maintenance.

We should also look at options to improve Fedora's infra to build Flatpaks. It is currently using OSBS (https://osbs.readthedocs.io/en/latest/users.html#flatpak) and is not has well maintained as the rest. The goal would be to have Flapak builds happen automatically when an RPM build is triggered so that we avoid the work duplication.

This is happening thanks to a lot of good work from @yselkowitz from the Flatpak SIG:

• https://bodhi.fedoraproject.org/updates/FEDORA-FLATPAK-2023-066e37cd7f
• https://bodhi.fedoraproject.org/updates/FEDORA-FLATPAK-2023-aebc99859b

How do you feel about adding that to F38 even if it's a bit late? I could either draft a Self-Contained change or we just do it.

Just go and do it. :100:

I've made tables with the apps that we have installed by default and added remarks about what we should do with them in https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/2.

Let's discuss that in the next meeting.

Results of conversation about default apps to install / remove in KDE Spin and Kinoite:

Remove:

• Removing Krfb from KDE Spin & Kinoite (only works on X11)

Add:

• Add KFind to Kinoite (base image) (hard to Flatpak)
• Add Filelight to Kinoite (base image) & KDE Spin (hard to Flatpak)

Unchanged:

• Keep KWalletManager as a RPM in the base image in Kinoite although it's available as a Flatpak
  To investigate:
• KGpg: It was initially thought that KGpg was required for gpg support in kwallet but after investigation that's not the case. Gpg support in kwallet does not directly depend on it, only on keys being available. We have Kleopatra working as a Flatpak (https://github.com/flathub/org.kde.kleopatra) and KGpg could be setup similarly on Kinoite so we don't need to include it but we'll need to package it as a Flatpak.

Deferred:

• Neochat will replace Konversation once E2E support is in a good shape. Waiting for F39: https://pagure.io/fedora-kde/SIG/issue/28
• Kate discussion deferred (will be revisited once the Flatpak is in a good shape)
• Decision not taken for KDE PIM apps.

We will add to Kinoite, as a Flatpak:

• Gwenview (removed from base image)
• Kcalc (removed from base image)
• KMahjongg
• KMines
• KoulourPaint
• KRDC
• Okular (removed from base image)
• Elisa

@apol told us that Krfb should work on Wayland and it indeed does. I'll add it to Kinoite and keep it in the KDE Spin.

Thanks!

I wonder if we should keep Okular in the base image because OEM preloads (if anyone winds up being interested in that) often require that they ship legal and customer documentation in PDF form.

Why? What difference does it make?

IMO, anything that must be always accessible are things I think belong in the base image as RPMs.

i'd say it should be fine. Firefox can open and display PDF too if there is nothing else available.

Filelight to comps: https://pagure.io/fedora-comps/pull-request/823

I've made a larger cleanup PR in https://pagure.io/fedora-comps/pull-request/824

Corresponding kickstart PR: https://pagure.io/fedora-kickstarts/pull-request/956

Next step: https://pagure.io/workstation-ostree-config/pull-request/367

F38 changes in https://pagure.io/workstation-ostree-config/pull-request/368

F37: https://pagure.io/workstation-ostree-config/pull-request/369

OK, we should now be ready to add Flatpaks to F39 for Kinoite. I'll likely wait for after the F38 release to do that.

Hi, this is my first comment here. If I understand it correctly, in Fedora Kinoite 39, Okular, kCalc and Gwenview will be removed from the base image and added as Flatpaks?

I would similarly suggest to remove Kate and KWrite from the base image. KWrite is available as a Flatpak so that Flatpak could be installed by default. If a user needs Kate it can be installed through rpm-ostree. Those users for whom KWrite is not enough and who need Kate's features are probably skilled enough to use the command line to install it.

This would then bring "Flatpak parity" with Silverblue and would only leave Firefox as the last user-facing application to be migrated to a Flatpak (see here: https://github.com/fedora-silverblue/issue-tracker/issues/288)

This would then bring "Flatpak parity" with Silverblue

This is not a goal of Kinoite. The goal of Kinoite is to provide a simple, reliable experience for basic usage and those who want to operate with container-centric workflows.

That does not imply that everything will be delivered as a Flatpak. Indeed, things that remain in the base image are intended to be core to the desktop in such a manner that they can be guaranteed to be available and working no matter what situation the user is in.

Agree with Neal. We don't have to match what Silverblue does (but we definitely try to match as much as possible) and we should ship Flatpaks were it makes sense.

Right now, Flatpaks can not be used to edit system files, such as configuration files in /etc. Kwrite as included in the base image lets the user do that safely in a graphical interface.

It's important to keep basic debugging option for users installed at all time in the image. A working text editor is part of that functionality.

Users are free to install any other version of their favorite text editor as Flatpak and use that.

Kate is not explicitly part of the default Kinoite installation. It has been included in the image in the pasts due to incorrect dependencies that should be resolved now.

This is not a goal of Kinoite. The goal of Kinoite is to provide a simple, reliable experience for basic usage and those who want to operate with container-centric workflows.

In that case would you consider including a flatpak based KDE media player? Out of the box there's no media player. I see Haruna Media player by KDE works great.

This is not a goal of Kinoite. The goal of Kinoite is to provide a simple, reliable experience for basic usage and those who want to operate with container-centric workflows.

In that case would you consider including a flatpak based KDE media player? Out of the box there's no media player. I see Haruna Media player by KDE works great.

+1 on this. I've been using Haruna for a bit for local testing and it seems like a great player. Not having a media player by default for local media is also a bit of an missing feature set.

Let's keep this ticket focused on the apps that we are moving to Flatpak to keep this easier to track.

Any app request should be a distinct ticket for discussion.

I've made one for that specific application: https://pagure.io/fedora-kde/SIG/issue/357

List of Flatpaks to pre-install (from https://pagure.io/fedora-kde/SIG/issue/13#comment-846461):

• Gwenview (removed from base image)
• Kcalc (removed from base image)
• KMahjongg
• KMines
• KoulourPaint
• KRDC
• Okular (removed from base image)
• Elisa