15:03:20 <kalev> #startmeeting Fedora Flatpak Packaging SIG
15:03:20 <zodbot> Meeting started Mon Mar 20 15:03:20 2023 UTC.
15:03:20 <zodbot> This meeting is logged and archived in a public location.
15:03:20 <zodbot> The chair is kalev. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
15:03:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:03:20 <zodbot> The meeting name has been set to 'fedora_flatpak_packaging_sig'
15:03:20 <kalev> #meetingname flatpak-sig
15:03:20 <zodbot> The meeting name has been set to 'flatpak-sig'
15:03:20 <kalev> #topic Init process
15:03:34 <kalev> hi everybody
15:03:51 <OwenTaylor[m]> .hello otaylor
15:03:52 <zodbot> OwenTaylor[m]: otaylor 'Owen Taylor' <otaylor@redhat.com>
15:03:54 <kalev> a bit of confusion due to the summer time changes as usual ...
15:04:46 <kalev> high up on my list for today is to discuss the switch to F38. Does anyone have anything else?
15:06:30 <tpopela[m]> .hello tpopela
15:06:31 <zodbot> tpopela[m]: tpopela 'Tomas Popela' <tpopela@redhat.com>
15:07:30 <kalev> #topic Fedora 38
15:08:17 <kalev> went ahead and did most of the preparations needed for building flatpaks for F38 over the weekend:
15:08:49 <kalev> branched the runtime, flatpak-rpm-macros, flatpak-runtime-config, flatpak-common and did initial builds
15:09:37 <kalev> the package set was in a surprisingly good state, the only issue I ran into with wrong dependencies was https://src.fedoraproject.org/rpms/samba/pull-request/31 that was easy enough to fix
15:10:12 <kalev> so next we can move forward with actually building flatpaks based on the updated platform :)
15:10:35 <kalev> oh, and the KDE platforms need updating still, I haven't touched them
15:11:15 <kalev> GNOME 44.0 is getting upstream stable releases out right now and amigadave is busy updating the rpms for Fedora
15:11:53 <kalev> I think I'd like to wait until he gets to the point where 44.0 is in updates-testing and then start by building the flatpaks that are part of Silverblue
15:12:12 <kalev> so that we can switch the iso image over to shipping F38 based flatpaks as soon as possible
15:12:15 <AllanDay[m]> sounds great
15:12:33 <tpopela[m]> thank you kalev !
15:12:41 <kalev> np!
15:13:31 <kalev> fedmod needs a new upstream release to update the dataset definitions to F38. I can take care of that as well. it also has some nice fixes from tpopela[m] in the pipeline :)
15:14:59 <tpopela[m]> kalev: that would be appreciated! :)
15:15:21 <kalev> does anyone know about Kinoite plans for F38? is it already shipping KDE flatpaks?
15:16:15 <tpopela[m]> AFAIK they ship without any Flatpaks..
15:16:27 * kalev nods.
15:17:18 <kalev> perhaps they are waiting for the switch to F38 first
15:17:40 <kalev> yselkowitz[m]1 has lined up most of the flatpaks they wanted to ship so it should be close :)
15:18:42 <kalev> ok, another thing that's in my mind is what to do with Qt in runtimes, but yselkowitz is not here
15:19:32 <kalev> OwenTaylor[m]: what's your opinion, should we keep Qt 5 in the Fedora runtime for F38?
15:20:10 <kalev> we don't ship anything pre-installed that makes use of it, so it's a bit of space hog because of that
15:21:14 <OwenTaylor[m]> I don't have a strong opinion - I'm less inclined to keep it because of the splitty nature of Qt
15:21:28 <OwenTaylor[m]> there's sort of an artificial cut-off "this much Qt" that is a pain to maintain
15:22:28 <OwenTaylor[m]> But the question is really how many common Qt-only apps are we enabling with it? And what percentage of users will end up with the KDE runtime?
15:24:11 <OwenTaylor[m]> Basically, if it allows people to install, say, stelllarium without a 1.5GB KDE runtime download, that's a win - but if everybody already has the KDE runtime, then it's not a win :-)
15:24:59 <kalev> so, stellarium in particular has already switched to Qt 6, which is _not_ included in the runtime. It just builds all of the Qt 6 as part of the stellarium flatpak module
15:25:22 <kalev> and mediawriter does exactly the same: also Qt 6 and is building it all as part of the module
15:25:26 <OwenTaylor[m]> Also, if we have no plans to add Qt6, then the attractiveness of keeping Qt5 in there is less
15:25:42 <kalev> agreed, I think we should treat them the same
15:26:09 <OwenTaylor[m]> How long does it take to build Qt6?
15:26:15 <kalev> one other option would be to add both Qt 5 and Qt 6 to flatpak-common and switch apps over to that instead. It should be totally seamless from app flatpak perspective, I'd imagine
15:26:40 <kalev> I am not sure. tpopela[m] do you know? you set up mediawriter to bundle Qt 6
15:27:21 <tpopela[m]> kalev: Owen Taylor I really don't know.. let me check the module build time..
15:27:25 <kalev> re the question of how many apps use it, I don't really know. my proposal in an earlier meeting was to temporarily drop it and run 'fedmod rpm2flatpak' for all apps and see where qt5 appears
15:27:40 <kalev> do you know a better method, OwenTaylor[m] ?
15:28:18 <kalev> I copied latest f37 flatpak-runtime reports directory to https://kalev.fedorapeople.org/reports/ but I think it doesn't answer that question exactly, does it?
15:28:31 <tpopela[m]> so it's 3.5 hours in total for the media writer module - https://release-engineering.github.io/mbs-ui/module/16097
15:29:24 <kalev> that's not too bad for flatpak-common, but a bit too long for app flatpaks I'd say
15:30:43 <tpopela[m]> it depends on how often the applications are built.. if (bi-)weekly, then sure.. if monthly, then I don't think that it's too much..
15:32:15 <tpopela[m]> I have to leave in a minute, but I forget to share https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/13 in the beginning of the meeting.. it lists the current missing pieces in the Firefox Flatpak on Fedora/RHEL..
15:32:43 <kalev> if it takes a long time it's annoying because the updating consists of 3 manual steps and have to wait for each one to complete first:
15:33:02 <kalev> kick off the module build, wait, kick off flatpak build, wait, submit to bodhi
15:33:46 <kalev> anyone, my proposal would be to drop Qt 5 from F38 runtime and add both Qt 5 and 6 to flatpak-common
15:35:24 <kalev> and if it backfires in some way, then we can just add it back, or keep the apps using F37 runtime that has Qt 5 until we sort things out
15:36:43 <kalev> thoughts?
15:37:26 <OwenTaylor[m]> Sounds reasonable to me.
15:38:09 <kalev> ah, one additional thing I forgot to mention: we have had a few occasions where Qt was bumped in build roots, but we hadn't had a runtime build for a while
15:38:25 <OwenTaylor[m]> tpopela: Long app build times aren't bad when you know they are going to work, but long failures are painful, especially since MBS doesn't have working resume-from-failed.
15:38:27 <kalev> and then an app flatpak got built against a newer Qt and broke because the runtime only had an older version
15:38:42 <kalev> moving it to flatpak-common would eliminate that issue at least
15:39:39 <kalev> and another issue I've run into was back when stellarium was still on Qt 5 and it added a dep on a new module, qt5-qtcharts or something that we didn't have in the runtime
15:40:38 <kalev> but it turned out to be near impossible to build just one module for /app when the rest was in /usr due to how qt rpm builds are set up in Fedora
15:40:55 <kalev> so I went the easier route and added it to the runtime
15:41:13 <kalev> moving qt5 to flatpak-common would eliminate that kind of issue as well
15:41:49 <OwenTaylor[m]> I'm not positive what's going to happen if the buildroot has a newer Qt than flatpak-common - I think it will prefer the one in flatpak-common.
15:43:01 <kalev> oh, yes, if it doesn't work like that then it could be the source of another set of weird issues
15:44:33 <kalev> anyway, sounds like we are in an agreement here to drop Qt 5 from the runtime for F38
15:44:58 <OwenTaylor[m]> There's something in MBS to handle "Filter out base module RPMs that overlap with the RPMs in the buildrequired modules" - I think it probably does the right thing.
15:45:33 <kalev> ah, nice
15:46:19 <kalev> let's see how it goes - it should be fairly painless because we can keep apps on F37 runtime as long as needed
15:47:07 <kalev> OwenTaylor[m]: do you know why jasper-libs is marked in package-notes.txt ?
15:47:15 <kalev> https://paste.centos.org/view/af48818f would be the diff what gets dropped
15:49:25 <kalev> another question I get from looking at the diff is what to do with qgnomeplatform and the adwaita theme
15:50:11 <OwenTaylor[m]> No memory of why the "empty" lines are in package-notes.txt - they don't have any effect as I recall.
15:50:37 <kalev> the effect is that the scripts complain if they something marked like this goes missing
15:50:53 <kalev> 'make update' complains
15:50:58 <OwenTaylor[m]> That's just to catch typos or leftovers
15:51:08 <kalev> ahh, ok
15:51:36 <kalev> I guess it can just go then
15:51:41 <kalev> re qgnomeplatform, I missed the Workstation meeting where it was discussed, but as I understand it, qgnomeplatform is supposed to stay for Workatation, so I guess we should make an effort to keep it for the flatpak runtime as well?
15:51:54 <OwenTaylor[m]> Hmm - of course that's the https://pagure.io/fedora-workstation/issue/351 hairball
15:51:56 <kalev> not sure how to best make it happen when qt is not part of the runtime
15:52:45 <OwenTaylor[m]> We haven't gotten to the end of that but yeah, where we're sort of heading is maybe get rid of adwaita-qt as the default theme, but we need qgnomeplatform for things like shadows and that uses adwaita-qt as a library
15:53:27 <OwenTaylor[m]> If we drop qt from the runtime, I think we need it flatpak-common and pull it in for each Qt-based app that isn't using the KDE runtime.
15:54:28 <kalev> maybe we could add a conditional dep to one the qt modules that does something like "if building for flatpak-common, require qgnomeplatform"
15:55:00 <kalev> I know yselkowitz[m]1 did separate common modules for the KDE platforms so we could safely key on flatpak-common I think
15:55:18 <OwenTaylor[m]> Since the same thing (as far as qgnomeplatform is considered) applies to Qt6 we aren't creating a new problem
15:55:25 <OwenTaylor[m]> The KDE platforms need qgnomeplatform too
15:55:25 * kalev nods.
15:55:31 <kalev> ohh
15:55:51 <OwenTaylor[m]> But that is different since they can just pull it into the runtim
15:56:06 <kalev> ah, true
15:56:55 <kalev> ok, that's everything from me
15:58:10 <kalev> #agreed Drop Qt 5 from the Fedora runtime (we never had Qt 6 in the runtime) for F38, and move both Qt 5 and Qt 6 to flatpak-common for F38
15:58:59 <kalev> #info Still need to figure out how to best make qgnomeplatform get installed when Qt is built as part of flatpak-common and is not part of the runtime
15:59:10 <kalev> thanks for the help, OwenTaylor[m]
15:59:12 <OwenTaylor[m]> kalev: making qt require: qgnomeplatform when build in flatpak-common sounds like it would work to avoid complicating the module definitions for all the apps
15:59:24 * kalev nods.
15:59:31 <kalev> my thoughts exactly :)
16:00:31 <kalev> OK, see you all in two weeks. The meeting should be back in the regular time slot for US people then :)
16:00:34 <kalev> #endmeeting