15:00:33 <kalev> #startmeeting Fedora Flatpak Packaging SIG
15:00:33 <zodbot> Meeting started Mon Jan 23 15:00:33 2023 UTC.
15:00:33 <zodbot> This meeting is logged and archived in a public location.
15:00:33 <zodbot> The chair is kalev. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
15:00:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:33 <zodbot> The meeting name has been set to 'fedora_flatpak_packaging_sig'
15:00:40 <kalev> #meetingname flatpak-sig
15:00:40 <zodbot> The meeting name has been set to 'flatpak-sig'
15:00:48 <kalev> #topic First Meeting
15:01:00 <yselkowitz[m]> .hello yselkowitz
15:01:01 <zodbot> yselkowitz[m]: yselkowitz 'Yaakov Selkowitz' <yselkowi@redhat.com>
15:01:02 <kalev> hi and welcome to the first meeting! :)
15:01:47 <tpopela[m]> .hello tpopela
15:01:48 <zodbot> tpopela[m]: tpopela 'None' <tpopela@redhat.com>
15:01:53 <travier> .hello siosm
15:01:54 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
15:02:06 <kalev> I guess most of you joining have already read my emails on the devel mailing list and know what this is about -- packaging flatpaks in Fedora context
15:02:08 <OwenTaylor[m]> .hello otaylor
15:02:09 <zodbot> OwenTaylor[m]: otaylor 'Owen Taylor' <otaylor@redhat.com>
15:02:30 <kalev> I thought that we should maybe do a round of introductions, I see some people have already started with this
15:02:41 <kalev> #topic Introductions
15:02:44 <kalev> .hello kalev
15:02:45 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
15:02:55 <JanGrulich[m]> .hello jgrulich
15:02:55 <zodbot> JanGrulich[m]: jgrulich 'Jan Grulich' <jgrulich@redhat.com>
15:03:01 <travier> Are we going to use https://etherpad.opensuse.org/p/fedora-flatpaks-sig?
15:03:05 <travier> https://etherpad.opensuse.org/p/fedora-flatpaks-sig ?*
15:03:34 <kalev> my name is Kalev Lember and I've been helping out getting the flatpak packaging started. I maintain the fedora flatpak runtime and try to keep the packaged flatpaks up to date
15:03:56 <kalev> travier: yes, let's do the topic from there after introductions
15:04:06 <travier> 👍
15:04:36 <AllanDay[m]> sorry i'm late
15:04:42 <kalev> anyone else want to say one sentence about themselves?
15:04:54 <kalev> no worries, we are just getting started
15:05:11 <travier> Hi, I'm Timothée Ravier, I maintain Silverblue & Kinoite and I'm part of the team maintaining KDE Apps as Flatpaks on Flathub
15:05:36 <yselkowitz[m]> my name is Yaakov Selkowitz, I've been adding some new flatpaks recently, filing spec file changes to allow for more, and proposing improvements to the existing ones
15:05:55 <tpopela[m]> my name is Tomáš (Tom) Popela and I'm the Product Owner at the Red Hat's Desktop Team - in the past I was working on updating some Fedora Flatpaks and I bootstrapped the Fedora 36 runtime which was not a pleasant experience :D.. I'm also involved with Silverblue and also a member of Fedora Workstation Working Group..
15:06:08 <JanGrulich[m]> My name is Jan Grulich, I'm a member of Fedora KDE SIG, maintaining Qt packages in Fedora. I also do some work around portal integration into KDE/Qt.
15:06:24 <OwenTaylor[m]> Hi, Im Owen Taylor - I've been working mostly on the infrastructure side of RPM-based Flatpaks for around 5 years - Kalev has amazing keeping the content going.
15:06:32 <JanBeran[m]> Hello everyone, my name is Jan Beran, I am maintaining several Fedora flatpaks.
15:06:52 <AllanDay[m]> my name is Allan Day. i'm on the Fedora Workstation Working Group. i'm mainly a designer but i sometimes do docs and organising :) i've done some work around flatpak and flathub previously
15:07:40 <kalev> excellent! welcome everybody
15:07:57 <travier> 👋
15:07:59 * rishi[m] waves
15:08:20 <rishi[m]> Sorry, it seems like Fractal didn't scroll the window and somehow there's nothing in my IRC client.
15:08:39 <travier> We just did introductions
15:08:42 <rishi[m]> So, I was beginning to get worried.  :)
15:08:48 <kalev> :)
15:09:23 <kalev> ok, let's move on with our topics from the etherpad
15:09:26 <kalev> #topic Announcements
15:09:42 <rishi[m]> I am Rishi.  I work on Fedora Silverblue and Workstation.  I have been involved in various other projects over the years, like GNOME and Flatpak.  These days I am mostly working on Toolbx.
15:10:16 <kalev> #info yselkowitz has added ~20 new flatpaks over the last two weeks and got flatseal packaged -- awesome work!
15:10:26 <travier> nice
15:10:58 <kalev> any other announcements? :)
15:11:12 <yselkowitz[m]> there's a lot more coming once spec file changes get merged
15:12:47 <kalev> I wonder if we could somehow do a team effort to help get them reviewed and merged? I know several people here are provenpackagers and should be able to help merge stuck PRs
15:13:14 <yselkowitz[m]> I'm a provenpackager too fwiw but I'd prefer cooperation here
15:13:28 <kalev> yes, same here
15:14:15 <kalev> maybe we could give them two more weeks and if nothing happens in the mean time, we could do a team review of the PRs at the next meeting and just go and merge them?
15:15:09 <kalev> I know there's a PR that's blocking libreoffice flatpak updates, which is a fairly prominent package
15:15:10 <travier> Before we dwelve into specific app issues, could we discuss the general topic of Flatpaks in Fedora?
15:15:14 <tpopela[m]> Jan Beran works on getting rid of fedmod in the Fedora Flatpak tooling by moving relevant parts of it into flatpak-module-tools which should help us in the long term (as the fedmod tool is abandoned anyway)
15:15:33 <kalev> ah, awesome, I dind't know that!
15:15:48 <kalev> yes, let's do the general flatpaks in Fedora topic
15:15:51 <tpopela[m]> kalev: the flatpak-sig might help if we are talking about PRs under the flatpaks/ dist-git namespace.. then we wouldn't have to rely on provenpackagers..
15:16:11 <kalev> tpopela[m]: no, we are talking about PRs to rpms/ that yselkowitz[m] wants to package as flatpaks
15:16:22 <kalev> #topic Why do we need Fedora Flatpaks?
15:16:46 <kalev> OwenTaylor[m]: do you want to take this one?
15:16:55 <OwenTaylor[m]> Yikes ... maybe we don't go there? I don't think that's a finite discussion :-)
15:17:06 <travier> So I've understood that we can not pre-install Flathub Flatpaks for legel reasons (they do not only include free software)
15:17:19 <travier> we have to adress this
15:17:32 <travier> write things clearly
15:17:40 <travier> legal*
15:17:47 <travier> is this still correct?
15:17:54 <tpopela[m]> Fedora Flatpaks were started so we have something to preinstall in Silverblue and we don't have to put it into the base image..
15:18:38 <tpopela[m]> and we were not able to point to Flathub - this actually might change, but it won't help to those that don't enable third-party repositores in Fedora
15:19:04 <tpopela[m]> and also there isn't a way to preinstall Flathub Flatpaks through Anaconda on Silverblue..
15:19:15 <kalev> another goal with Fedora Flatpaks was to try to see if we can improve on the packaging format in Fedora, so that we'd slowly start migrating from rpms to Flatpaks
15:19:19 <travier> What's the state of the infra used for building Flatpaks? Is OBS still maintained?
15:19:45 <travier> How much do we really want to invest in Fedora Flatpaks when most users will pick Flathub ones?
15:20:04 <OwenTaylor[m]> But the brief of it is a) so that we can ship Flatpaks preinstalled b) To get to a more Flatpaks future - because some users and packagers feel strongly in the value of Fedora infrastructure, and forcing people to stop making packages in favor of Flathub that Fedora has no control over is really hard politically.
15:20:47 <tpopela[m]> kalev: true - I would really like to see i.e. Firefox maintainers to produce one Flatpak instead of doing builds per all supported release (from resources point of view)
15:21:09 <AllanDay[m]> tpopela[m]: i wonder about this goal to be honest. how many apps do you need to be able to provide a viable experience?
15:22:16 <OwenTaylor[m]> Unfortunately, I have to leave in about 5 minutes. I will mention that the MBS team has some time this month to review more of my local build patches - with luck maybe we can get the improved logging and restarting local builds parts merged - definitely the logging parts - the download caching parts are not likely to land soon.
15:22:21 <tpopela[m]> AllanDay[m]: We wanted to get to the same level as with Workstation..
15:23:34 <travier> If we trylly want to makes Fedora Flatpaks replacement for RPMs then we need the builds to be synced with RPMs one
15:23:39 <AllanDay[m]> tpopela[m]: that seems like both a) a lot of apps and b) not enough apps :D
15:24:12 <rishi[m]> Umm... we at least need a web browser, no?
15:24:18 <kalev> travier: indeed, I that's the big thing that we are missing
15:24:59 <travier> From an upstream developer and Flathub packager perspective, maintaining Flatpaks in Fedora is painful for me
15:25:25 <OwenTaylor[m]> travier: In the end, we need to move past modularity - and probably a replacement would be "more automated" - but it's a hole unresourced pile of work :-(
15:25:26 <travier> I have Fedora knowledge, Flatpak & app knowledge and it is painful for me
15:25:29 <tpopela[m]> rishi[m]: Firefox is still shipped as an RPM in Silverblue, but I hope that this year we will be able to change that..
15:25:29 <OwenTaylor[m]> whole
15:25:43 <travier> We really need to improve if we want other people to contribute
15:26:19 <kalev> I very much agree with that and I think that's one of the things we need to work on if we want the fedora flatpaks story to get better
15:27:08 <travier> Do we trully need to rebuild everything?
15:27:20 <travier> I mentionned that in the channel and the reply was about /app
15:27:21 <yselkowitz[m]> as I've been trying to add a lot more flatpaks, I'm starting to see common pitfalls, I could try to write these down and see if they could be addressed, or at least better documented, in a future meeting
15:27:25 <travier> how mandatory is that?
15:27:41 <travier> If we could pick RPMs and install them in Flatpak that would make things much easier
15:27:45 <kalev> yselkowitz[m]: that would be nice
15:28:04 <yselkowitz[m]> the runtime isn't rebuilt iiuc
15:28:28 <OwenTaylor[m]> travier: Making RPMs relocatable is truly hard, and particularly hard on packagers. Extending Flaptak to allow layering on top of /usr is massive hard work on the Flatpak side...
15:28:58 <travier> ok :/
15:29:03 <kalev> no easy way out :(
15:29:18 <travier> Then we need to talk about the runtime and the KDE / GNOME split
15:29:26 <kalev> for what it's worth, I personally also think that it's sad that we have so much duplicated work going into Fedora and Flathub
15:29:31 <OwenTaylor[m]> the runtime / app split is one of the "basic principles" of Flatpak, and while it's orthogonal to other basic principles like the portal system, ostree storage, etc, it's not going to be easy to convince upstream that it's even a good idea - and then it's a lot of work.
15:29:33 <travier> we should probably split the same way the Flathub runtime are split
15:30:21 <OwenTaylor[m]> Sorry, have to go now. Will review the log. Made one note in the etherpad about a KDE runtime for informational purposes.
15:30:38 <travier> Oh, I'm not speaking about ditching runtimes. But having a way to generate either the apps or the runtimes from RPMs would make things much faster
15:30:38 <kalev> but I don't think we can avoid the duplicated work - as sad as it is, and as much as I personally feel I belong to both communities, I think we just have to live with two different packaging spheres
15:31:29 <kalev> I think we have all said what we had to say about the general flatpaks in Fedora topic. Let's move on to something less depressing :)
15:31:42 <travier> ok
15:31:44 <kalev> #topic openh264
15:32:15 <kalev> so, one of the big missing pieces from fedora's firefox flatpak is video playback
15:32:32 <travier> If we could figure out a way to have that shipped by Cisco as an extension that would unlock usage for the Firefox Flatpak and would make it a much better story for Silverblue/Kinoite switching to the Flatpaks
15:32:41 <kalev> in the rpm world, we have the cisco hosted open264 rpms and the way it works is:
15:33:12 <kalev> fedora builds openh264 in koji, signs the rpms, sends the rpms to cisco, cisco uploads them, and then fedora users download the rpms directly from cisco
15:33:28 <kalev> so they are produced by the fedora koji build system, but downloaded directly from cisco
15:33:46 <kalev> and what we are missing is something similar for flatpaks
15:34:05 <kalev> I spent some time looking into this and came up with the following idea:
15:35:00 <kalev> flatpak has the extra data system in its manifest, which can be used to instruct flatpak on the client side to download extra files
15:35:45 <kalev> so we could set up a flatpak runtime extension that includes the metadata that tells flatpak to go and download the same rpms that cisco hosts
15:36:28 <travier> 👍
15:36:38 <kalev> the downloads would all be done on the client side, would download the same rpms that were built in koji and everything would still be hosted by cisco :)
15:36:42 <travier> Then dynamically extract it in the right place?
15:36:45 <kalev> yep
15:36:52 <travier> looks good
15:36:58 <yselkowitz[m]> prefix?
15:37:13 <kalev> /usr - it's a runtime extension so it's all in /usr
15:38:21 <kalev> I actually already have it working locally and it seems to work fine, with the exception that I haven't figured out how to have different metadata for x86_64 and aarch64
15:38:51 <kalev> I think we may need to extend the container yaml somehow, but I think it's a nice step forward if we get only x86_64 working in the initial cut as well
15:39:22 <kalev> and with this, I think we should be able to switch to shipping firefox flatpak in silverblue soon
15:39:36 <kalev> that was my report :)
15:40:49 <kalev> #info Kalev has a plan how to do the openh264 flatpak runtime extension using Cisco hosted openh264 rpms
15:40:54 <kalev> ok, let's move on
15:40:55 <tpopela[m]> kalev: the switch won't be that easy.. we won't be able to automatically install the Firefox Flatpak for our users.. we can do that only for clean installations :/.. we will have to come up with a migration plan..
15:41:06 <kalev> ah, true :( grr
15:42:24 <travier> yes, we need a lot of things still
15:42:29 <travier> a story for extension maangement
15:42:35 <travier> U2F devices
15:42:55 <kalev> What's U2F?
15:43:05 <kalev> 2 factor auth?
15:43:14 <travier> FIDO (yubikey, etc.)
15:43:15 <travier> yes
15:43:17 <travier> https://github.com/fedora-silverblue/issue-tracker/issues/288
15:43:17 * kalev nods.
15:43:18 <tpopela[m]> travier: GNOME Shell extension management should be resolved this year as well..
15:43:31 <travier> I've started a tracker issue to trace things
15:44:13 <tpopela[m]> for reference https://github.com/flatpak/xdg-desktop-portal/pull/705
15:45:14 <kalev> nice, that last one seems to be moving along
15:45:29 <kalev> OK, let's move on - we only have 15 minutes left
15:45:43 <kalev> #topic flatpak-sig Fedora group and access to flatpaks/ namespace in dist-git
15:45:49 <tpopela[m]> yes, I'm really positive about Firefox in Flatpak on Fedora..
15:46:38 <kalev> should we do group access, so that everybody in the sig is in the flatpak-sig Fedora group, and we add flatpak-sig commit access to all flatpaks/ packages?
15:47:35 <kalev> it's not super important to me personally because I'm provenpackager, but may be useful for other people
15:47:57 <tpopela[m]> yes, that's what I had in mind.. also it might be handy to look for pending PRs and others (if we will use the Fedora Packager Dashboard)
15:47:58 <JanGrulich[m]> I think that would make sense. That's what we do in KDE SIG. All KDE/Qt related packages have kde-sig with commit access and everyone from the SIG can do stuff.
15:48:06 <kalev> I know that rust and go have similar sigs where there is a releng script that periodically goes and adds rust-sig / go-sig to all of the rust-* / go* packages
15:48:21 * kalev nods.
15:48:33 <JanGrulich[m]> * have kde-sig group added with commit
15:48:52 <kalev> makes sense to me - I can take the action item to set it up
15:49:21 <kalev> #action Kalev to set up flatpak-sig pagure group for flatpaks/ namespace
15:49:35 <rishi[m]> Makes sense to me too.  Also, if someone wants to become a provenpackager, then I am happy to vote for you.  :)
15:49:37 <travier> 👍
15:49:54 <kalev> ok, next topic!
15:49:55 <TheEvilSkeleton> Sorry for being ultra late. I was supposed to join 40 minutes ago but had a little emergency 😐️
15:50:05 <kalev> no worries! nice you are here now
15:50:23 <travier> 👋
15:50:45 <TheEvilSkeleton> o/
15:50:46 <TheEvilSkeleton> I'll read since the beginning
15:50:55 <kalev> #topic KDE/Qt runtime?
15:50:56 <TheEvilSkeleton> .hello theevilskeleton
15:50:57 <zodbot> TheEvilSkeleton: theevilskeleton 'Hari Rana' <theevilskeleton@riseup.net>
15:51:21 <kalev> so, right now we just have a single runtime - should we have another one that has all the KDE libs?
15:51:36 <travier> we definitely need that for KDE Apps in Feodra
15:51:42 * kalev nods.
15:51:42 <yselkowitz[m]> I think we have to
15:51:46 <travier> otherwise the builds time are just not manageable
15:52:12 <tpopela[m]> This is what Owen Taylor wrote about it into etherpad:
15:52:13 <tpopela[m]> [otaylor] Shared files will be de-duplicated for local storage, but not on initial download or delta updates.
15:52:22 <yselkowitz[m]> not to mention koji builder resources
15:52:27 * kalev nods.
15:52:27 <travier> I had started doing one from the existing runtime but it's not really developer friendly
15:52:28 <rishi[m]> Does the current Fedora runtime map closely to the upstream GNOME runtimes?  Or are they very different?
15:52:40 <JanGrulich[m]> +1 for KDE/Qt runtime. It doesn't make sense to include KDE frameworks and all the other Qt modules in the base runtime or have apps to bundle KDE frameworks or missing Qt modules themself, We will end up in hell as many times KDE frameworks need rebuilds for Qt update.
15:53:05 <travier> The current runtime has more than the Flathub GNOME runtime
15:53:16 <travier> Qt at minimum
15:53:24 <kalev> rishi[m]: the fedora runtime ships basically the same things that the GNOME runtime in Flathub, but adds a few things on top of it - in particular, Qt 5 is added on top
15:53:27 * kalev nods.
15:53:33 <tpopela[m]> rishi[m]: they're similar - the upstream one is taken as a base for the Fedora one..
15:53:44 <travier> So there would be a bit duplicated but I don't think that's a big issue
15:53:46 <rishi[m]> I see.
15:53:54 <JanGrulich[m]> also Qt modules need to be in sync so if the base runtime has newer Qt, all apps bundling other Qt modules will need rebuild
15:53:59 <kalev> so my proposal here is that if someone is interested in trying to package KDE apps, we could add a second runtime and keep the current one as is - not take Qt out for now
15:54:28 <rishi[m]> Maybe we could split the Fedora runtime in the same way as the upstream GNOME and KDE runtimes?
15:54:30 <travier> I'm OK with that. I can work on that but I need help and docs update
15:54:41 <travier> I may* work on that
15:55:09 <kalev> I'd be happy to give a helping hand with this
15:55:41 <yselkowitz[m]> I'm interested too
15:55:41 <JanGrulich[m]> kalev: same here
15:56:09 <kalev> awesome - if we have people interested in building a second runtime and maintaining it, I think it makes a lot of sense
15:56:41 <TheEvilSkeleton> Hold on, aren't we just turning into Flathub 2.0? Like, we should be collaborating them instead of competing...
15:56:42 <JanGrulich[m]> I think we can take the KDE/Qt runtime under KDE SIG umbrella
15:56:58 <kalev> I know I personally wouldn't want to take care of two runtimes, but if we can get two groups, like let's say the Workstation WG taking care of one runtime and the KDE sig taking care of the other
15:56:59 <yselkowitz[m]> TheEvilSkeleton: see the earlier discussion
15:57:19 <TheEvilSkeleton> Can you link? I can't follow through on Element because it always scrolls back and forth
15:57:33 <travier> I think it's going to be hard not having two different runtimes
15:57:35 <TheEvilSkeleton> It probably skipped a huge chunk without me realizing it
15:57:47 <yselkowitz[m]> we're almost done, the minutes should be published afterwards
15:58:04 <kalev> TheEvilSkeleton: we are pretty much done with the meeting soon. let's stay on track here and not go back to the depressing topic. I'll send meeting minutes with the full discussion
15:58:56 <kalev> #info The KDE SIG is interested in taking the KDE/Qt runtime under KDE SIG umbrella
15:59:19 <travier> From my perspective, we'll likely not package all apps, only the ones that we need installed by default
15:59:31 <travier> at least that's my goal
15:59:32 <kalev> makes sense to me
16:00:15 <kalev> if you guys want, I could come to a KDE sig video meeting and try to explain how the runtime packaging works
16:00:33 <kalev> anyway, we are over time here!
16:00:33 <travier> I think we should schedule something at another time
16:00:37 * kalev nods.
16:00:41 <travier> for training
16:00:52 <kalev> we made good progress here! thanks everybody for coming and see you all in 2 weeks
16:00:55 * adamw taps feet, looks at watch
16:00:58 <kalev> #endmeeting