I started packaging KDE Apps for Flathub and I've been looking at doing the same for Fedora, similarly to how Silverblue currently has GNOME Flatpaks for GNOME Apps.
I tried to follow the Flatpak guide but so far I have not successfully created a Flatpak yet.
Work in progress:
I will post detailed error logs soon.
Related to https://pagure.io/fedora-kde/SIG/issue/4
Metadata Update from @ngompa: - Issue tagged with: flatpak
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.
Metadata Update from @siosm: - Issue tagged with: meeting
Metadata Update from @siosm: - Issue untagged with: meeting
Metadata Update from @siosm: - Issue set to the milestone: Fedora 35
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:
Lesser priority, will not ship installed by default but would be good to have:
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.
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.
Metadata Update from @ngompa: - Issue tagged with: meeting
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
Login to comment on this ticket.