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.