15:03:20 #startmeeting Fedora Flatpak Packaging SIG 15:03:20 Meeting started Mon Mar 20 15:03:20 2023 UTC. 15:03:20 This meeting is logged and archived in a public location. 15:03:20 The chair is kalev. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 15:03:20 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:03:20 The meeting name has been set to 'fedora_flatpak_packaging_sig' 15:03:20 #meetingname flatpak-sig 15:03:20 The meeting name has been set to 'flatpak-sig' 15:03:20 #topic Init process 15:03:34 hi everybody 15:03:51 .hello otaylor 15:03:52 OwenTaylor[m]: otaylor 'Owen Taylor' 15:03:54 a bit of confusion due to the summer time changes as usual ... 15:04:46 high up on my list for today is to discuss the switch to F38. Does anyone have anything else? 15:06:30 .hello tpopela 15:06:31 tpopela[m]: tpopela 'Tomas Popela' 15:07:30 #topic Fedora 38 15:08:17 went ahead and did most of the preparations needed for building flatpaks for F38 over the weekend: 15:08:49 branched the runtime, flatpak-rpm-macros, flatpak-runtime-config, flatpak-common and did initial builds 15:09:37 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 so next we can move forward with actually building flatpaks based on the updated platform :) 15:10:35 oh, and the KDE platforms need updating still, I haven't touched them 15:11:15 GNOME 44.0 is getting upstream stable releases out right now and amigadave is busy updating the rpms for Fedora 15:11:53 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 so that we can switch the iso image over to shipping F38 based flatpaks as soon as possible 15:12:15 sounds great 15:12:33 thank you kalev ! 15:12:41 np! 15:13:31 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 kalev: that would be appreciated! :) 15:15:21 does anyone know about Kinoite plans for F38? is it already shipping KDE flatpaks? 15:16:15 AFAIK they ship without any Flatpaks.. 15:16:27 * kalev nods. 15:17:18 perhaps they are waiting for the switch to F38 first 15:17:40 yselkowitz[m]1 has lined up most of the flatpaks they wanted to ship so it should be close :) 15:18:42 ok, another thing that's in my mind is what to do with Qt in runtimes, but yselkowitz is not here 15:19:32 OwenTaylor[m]: what's your opinion, should we keep Qt 5 in the Fedora runtime for F38? 15:20:10 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 I don't have a strong opinion - I'm less inclined to keep it because of the splitty nature of Qt 15:21:28 there's sort of an artificial cut-off "this much Qt" that is a pain to maintain 15:22:28 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 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 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 and mediawriter does exactly the same: also Qt 6 and is building it all as part of the module 15:25:26 Also, if we have no plans to add Qt6, then the attractiveness of keeping Qt5 in there is less 15:25:42 agreed, I think we should treat them the same 15:26:09 How long does it take to build Qt6? 15:26:15 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 I am not sure. tpopela[m] do you know? you set up mediawriter to bundle Qt 6 15:27:21 kalev: Owen Taylor I really don't know.. let me check the module build time.. 15:27:25 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 do you know a better method, OwenTaylor[m] ? 15:28:18 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 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 that's not too bad for flatpak-common, but a bit too long for app flatpaks I'd say 15:30:43 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 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 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 kick off the module build, wait, kick off flatpak build, wait, submit to bodhi 15:33:46 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 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 thoughts? 15:37:26 Sounds reasonable to me. 15:38:09 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 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 and then an app flatpak got built against a newer Qt and broke because the runtime only had an older version 15:38:42 moving it to flatpak-common would eliminate that issue at least 15:39:39 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 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 so I went the easier route and added it to the runtime 15:41:13 moving qt5 to flatpak-common would eliminate that kind of issue as well 15:41:49 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 oh, yes, if it doesn't work like that then it could be the source of another set of weird issues 15:44:33 anyway, sounds like we are in an agreement here to drop Qt 5 from the runtime for F38 15:44:58 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 ah, nice 15:46:19 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 OwenTaylor[m]: do you know why jasper-libs is marked in package-notes.txt ? 15:47:15 https://paste.centos.org/view/af48818f would be the diff what gets dropped 15:49:25 another question I get from looking at the diff is what to do with qgnomeplatform and the adwaita theme 15:50:11 No memory of why the "empty" lines are in package-notes.txt - they don't have any effect as I recall. 15:50:37 the effect is that the scripts complain if they something marked like this goes missing 15:50:53 'make update' complains 15:50:58 That's just to catch typos or leftovers 15:51:08 ahh, ok 15:51:36 I guess it can just go then 15:51:41 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 Hmm - of course that's the https://pagure.io/fedora-workstation/issue/351 hairball 15:51:56 not sure how to best make it happen when qt is not part of the runtime 15:52:45 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 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 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 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 Since the same thing (as far as qgnomeplatform is considered) applies to Qt6 we aren't creating a new problem 15:55:25 The KDE platforms need qgnomeplatform too 15:55:25 * kalev nods. 15:55:31 ohh 15:55:51 But that is different since they can just pull it into the runtim 15:56:06 ah, true 15:56:55 ok, that's everything from me 15:58:10 #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 #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 thanks for the help, OwenTaylor[m] 15:59:12 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 my thoughts exactly :) 16:00:31 OK, see you all in two weeks. The meeting should be back in the regular time slot for US people then :) 16:00:34 #endmeeting