15:00:22 <kalev> #startmeeting Fedora Flatpak Packaging SIG
15:00:22 <zodbot> Meeting started Mon Feb 20 15:00:22 2023 UTC.
15:00:22 <zodbot> This meeting is logged and archived in a public location.
15:00:22 <zodbot> The chair is kalev. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
15:00:22 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:22 <zodbot> The meeting name has been set to 'fedora_flatpak_packaging_sig'
15:00:22 <kalev> #meetingname flatpak-sig
15:00:22 <zodbot> The meeting name has been set to 'flatpak-sig'
15:00:22 <kalev> #topic Init process
15:00:28 <kalev> .hello kalev
15:00:29 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
15:00:49 <rishi[m]> .hello rishi
15:00:50 <zodbot> rishi[m]: rishi 'Debarshi Ray' <debarshir@redhat.com>
15:01:07 <kalev> it's a holiday in the US so maybe not a lot of people are around today
15:01:29 <tpopela[m]> .hello tpopela
15:01:31 <zodbot> tpopela[m]: tpopela 'Tomas Popela' <tpopela@redhat.com>
15:01:36 <travier> .hello siosm
15:01:37 <AllanDay[m]> ./
15:01:37 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
15:01:43 <AllanDay[m]> * o/
15:01:47 <sberg_> .hello sberg
15:01:48 <zodbot> sberg_: Sorry, but user 'sberg' does not exist
15:02:03 <sberg_> .hello sbergmann
15:02:04 <zodbot> sberg_: sbergmann 'None' <sbergman@redhat.com>
15:02:10 <kalev> nice to see you here, sberg_!
15:02:30 <sberg_> yeah, I accidentally missed the first two meetings :(
15:03:01 <kalev> no worries
15:03:22 <kalev> we have a etherpad to keep a track of topics, https://etherpad.opensuse.org/p/fedora-flatpaks-sig if you want to add something for a future meeting
15:03:47 <kalev> #topic Announcements
15:03:51 <kalev> Let's try to keep the announcements short this time. I think I managed to spend 15 minutes of the previous meeting typing them out so this time I've prepared a copy-paste :)
15:03:58 <kalev> #info 15 new flatpaks added over the last two weeks, thanks to yselkowitz (14) and pwalter (1)
15:04:01 <kalev> I did a round of new builds to keep dependencies up to date for existing flatpaks
15:04:04 <kalev> https://bodhi.fedoraproject.org/releases/F37F has all the updates
15:04:06 <kalev> #info xberry has a fork of flatpak-module-tools to merge in the parts of fedmod we need
15:04:09 <kalev> https://pagure.io/fork/xberry/flatpak-module-tools/c/1f7eeb562a72aae60e53babc3935ddb6eca54043?branch=master
15:04:12 <kalev> #info Allan created a gitlab repo where we can track flatpak-specific issues: https://gitlab.com/fedora/sigs/flatpak
15:04:15 <kalev> EOF from me - anyone else want to add something?
15:04:54 <travier> Good discussions already in the tracker
15:05:12 <AllanDay[m]> Yeah, I was about to say - some things we might want to pick up from the issues
15:05:24 * kalev nods.
15:05:43 <kalev> should we take something from the tracker or continue from the etherpad?
15:05:51 <tpopela[m]> #info xberry will also work on porting the "to be bundled" fedmod from libmodulemd to libmodulemd v2
15:06:27 <kalev> nice
15:06:49 <AllanDay[m]> https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/7 is blocking a few apps
15:07:24 * kalev agrees.
15:07:27 <kalev> #topic Policy for app id discrepencies
15:07:30 <tpopela[m]> I also have (as of now) internal list of issues that are affecting Firefox Fedora Flatpak, I will move them over to GitLab in the following days
15:07:30 <kalev> https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/7
15:08:23 <kalev> nice, good that we are already making good use of the new issue tracker
15:08:49 <AllanDay[m]> i anticipate that this will stand in for a mailing list
15:09:34 <kalev> yeah, I'd like it to at least, I think it's easier if there are fewer places to discuss stuff
15:10:23 <ssmoogen> hello
15:10:36 <kalev> hello!
15:10:47 <kalev> so, reading through the comments there, I am not sure there is a lot to add
15:11:18 <kalev> I added support for the eol and eol rebase things to fedora flatpaks a few cycles ago
15:11:19 <AllanDay[m]> it sounds like the policy for id mismatches should be: 1. try to get the upstream id changed, 2. if that fails after X weeks, follow the Flathub ID ?
15:11:45 <kalev> so even if we get the ID wrong, it's still possible to rename it
15:12:26 <kalev> I think that's a good policy
15:12:59 <kalev> I would maybe also add that if we have a mismatch, we should add a provides line to appstream to provide the other app IDs
15:13:12 <kalev> that way gnome-software knows that they are the same app and knows to de-duplicate them in the UI
15:13:20 <ssmoogen> I like how consistency in upper-casing the final name is inconsistent
15:13:54 <AllanDay[m]> where would we document the policy? https://docs.fedoraproject.org/en-US/flatpak/tutorial/ ?
15:14:43 <ssmoogen> sounds like a good first place.
15:14:46 <kalev> I think so. I would maybe rephrase it less like a policy and more like guidelines how to choose the app ID, maybe
15:14:55 <ssmoogen> if it turns out it needs to go elsewhere it can be iterated later
15:15:14 <AllanDay[m]> cool. i'll add that plan to the ticket
15:15:23 <kalev> the packaging guidelines use SHOULD and MUST to indicate how strong the language is
15:15:36 <kalev> if we want to write a policy document maybe it would make sense to use the same kind of style
15:16:09 <AllanDay[m]> adding it as a guideline makes sense to me
15:16:40 <kalev> https://docs.fedoraproject.org/en-US/packaging-guidelines/ is the packaging guidelines that I refer to
15:17:52 <travier> Do we all agree on
15:17:52 <travier> 1. Try to get upstream to to use the ID used by Flathub
15:17:52 <travier> 2. If that fails, patch
15:17:52 <travier> 3. Update existing Flatpak to use the one used by Flathub
15:17:58 <travier> ?
15:18:17 <kalev> what do you mean by "patch" ?
15:18:24 <travier> patch the ID in Fedora
15:18:36 <kalev> as in, in the rpm packaging or in flatpak packaging? we have two places to do that :)
15:18:58 <travier> Can this be done in the Flapak packaging?
15:19:14 <travier> I'd say RPM so that things are in one place
15:19:25 <kalev> yes, see e.g. https://src.fedoraproject.org/flatpaks/firefox/blob/stable/f/container.yaml
15:19:56 <kalev> it's renaming the appdata and desktop and icon files from firefox to org.mozilla.Firefox
15:20:11 <kalev> so far this is what has been done in almost all cases, mostly because it's easier like that
15:20:11 <travier> indeed
15:20:17 <travier> agree
15:20:20 <travier> seems easier
15:20:32 <travier> Then 2. Rename in Flaptak config
15:21:10 <travier> 1. Try to get upstream to to use the ID used by Flathub
15:21:10 <travier> 2. If that fails, rename the App ID in Fedora's Flaptak config
15:21:10 <travier> 3. Update existing Flatpak to use the one used by Flathub
15:21:58 <kalev> maybe 2. should be rename in flatpak or rpm spec file and leave it up to the packager to choose where they want to do it
15:22:31 <yselkowitz[m]> .hello yselkowitz
15:22:31 <travier> Note that this is not set in stone. I think Flathub should change the names if it makes sense and it's not just a capitalization change
15:22:31 <zodbot> yselkowitz[m]: yselkowitz 'Yaakov Selkowitz' <yselkowi@redhat.com>
15:22:44 * kalev nods.
15:22:58 <kalev> I'd like to point out that in this case we had firefox flatpak first and then flathub chose to go with a different name :(
15:23:11 <kalev> I pointed it out then but they didn't want to use org.mozilla.Firefox, sadly
15:23:46 <kalev> anyway, at this point I think it makes sense for us to rename it to lower case to match flathub
15:24:10 <travier> +1
15:24:25 <chromebittin> hello :)
15:24:27 <kalev> I can talk to stransky and xhorak and get it changed
15:24:44 <kalev> hello chromebittin and yselkowitz[m]!
15:24:54 <travier> Are we confident that users will get the one if we change the name?
15:25:42 <kalev> I believe so, but I want to test it first to make sure it works
15:26:02 <kalev> I'm not confident that flatpak knows to install the new thing from the same repo, for example
15:27:42 <kalev> sounds like gnome-software handles eol-rebase, but not eol, if I understand https://gitlab.gnome.org/GNOME/gnome-software/-/issues/572#note_1333705 right
15:28:10 <chromebittin> oh Fedora Flatpak meeting (is here early waiting for the QA meeting) sorry
15:28:16 <tpopela[m]> kalev: but we will need only eos-rebase, no? because we have a replacement (with the "fixed" ID)
15:28:27 <travier> 1. Try to get upstream to to use the ID used by Flathub
15:28:27 <travier> 2. If that fails, rename the App ID in Fedora's Flaptak config or RPM spec file
15:28:27 <travier> 3. Update existing Flatpaks to use the one used by Flathub (to be confirmed/validated)
15:28:27 <kalev> exactly
15:28:36 <tpopela[m]> not eos, but eol, sorry..
15:28:38 <kalev> +1 from me
15:28:52 <tpopela[m]> +1
15:28:54 <ssmoogen> +1
15:29:00 <travier> Writting that in the ticket
15:29:14 <kalev> excellent, thanks travier
15:29:25 <kalev> anyway, if we end up renaming things, it's easiest to do at the same time as switching to a new runtime version
15:30:00 <kalev> we have to request a new branch and ... I can walk people through this if yselkowitz[m] or anyone else wants to rename something
15:30:31 <yselkowitz[m]> e.g. https://src.fedoraproject.org/flatpaks/dosbox/pull-request/1 ?
15:30:32 <kalev> it's a bit awkward because we don't have repo names that match flatpak app IDs
15:31:01 <kalev> oh, yes
15:31:22 <kalev> ok, that's the simple case because dosbox and dosbox-staging have different git repos
15:31:41 <kalev> the rename is awkward when it's the same repo name but the ID changes
15:32:12 <kalev> yselkowitz[m]: in the case of dosbox, I am not sure we can actually add the rename keyword, because we need to build the container for it to take effect
15:32:21 <kalev> and dosbox has been retired for a while now and doesn't build any more
15:33:51 <kalev> so we need to be able to build something in order to rename / retire it, which is annoying :)
15:34:12 <kalev> would be nice if we could inject the metadata in some other way, but I don't know if it's possible
15:35:13 <kalev> maybe we could build a dummy empty dosbox flatpak that adds the rename keywords, hm
15:35:43 <kalev> anyway, should we move on?
15:35:55 <travier> +1
15:36:19 <kalev> #topic timeframe for migrating to f38
15:36:51 <kalev> f38 has branched now so we could start building the runtime now and start switching flatpaks over
15:37:13 <travier> Do we want this to land in the Beta?
15:37:24 <yselkowitz[m]> last I tried, fedmod -s f38 fetch-metadata didn't work yet?
15:37:26 <travier> Can we hold things in testing until the release?
15:37:37 <kalev> so this is the awkward part
15:37:48 <travier> If we update the packages now, F37 users will get them
15:37:53 <travier> Flatpaks*
15:38:00 <kalev> yeah, exactly, was just typing that
15:38:14 <travier> (well, everybody will get them)
15:38:28 <kalev> because of that limitation, I think it would make sense to wait a little bit until at least GNOME has had a final 44.0 release out
15:38:46 <travier> +1
15:38:54 <kalev> so my idea would be to push out GNOME flatpaks only once 44.0 is out
15:39:24 <kalev> at the same time, it would be nice to get 44.0.beta flatpaks for F38 silverblue, but I don't think we can do that because F37 users would get them as well
15:39:47 <kalev> it would be nice if we could have different channels, like a stable channel and beta channel, but we don't right now
15:40:01 <kalev> so maybe something like this:
15:40:02 <travier> We would have to create a special remote to push them tp
15:40:03 <travier> to*
15:40:10 <tpopela[m]> yes, let's do what we've been doing previously..
15:40:58 <kalev> I can request branches for the runtime and sdk and flatpak-common and flatpak-runtime-config and flatpak-rpm-macros today and try to get a first build out this week
15:41:35 <kalev> and then we see if any issues come up, like sometimes packages that are part of the runtime have added bad deps that we don't want in the runtime
15:41:47 <kalev> so we need to fix those in the spec files to get a good build and that can take time
15:41:47 <chromebittin> kalev: while i have you here any plan for when the Gnome 44 Beta is in F38 beta ?
15:42:14 <kalev> chromebittin: yes, amigadave is doing the builds this cycle, not me, and he said he has everything built in a side tag and is going to merge it later today
15:43:16 <chromebittin> ah alright thanks for the info :)
15:43:28 <kalev> so anyway, once runtime is built we can start migrating things over to it on as needed bases, but maybe we could leave the flag day when doing a mass migration for when 44.0 is released
15:43:39 <kalev> yselkowitz[m]: what do you think?
15:44:48 <kalev> ah another thing, regarding Silverblue
15:45:29 <yselkowitz[m]> go ahead
15:45:30 <kalev> silverblue pungi config hardcodes the flatpak runtime version that's pre-installed
15:45:36 <travier> yes
15:45:51 <travier> we need to update all apps at onc
15:45:52 <travier> e
15:45:54 <kalev> so we need to update it at the same times as when the flatpaks switch to the new runtime
15:46:02 <kalev> yeah, or add two flatpak runtimes to silverblue for a short while
15:46:16 <travier> all apps shipped in the ISO
15:46:23 <travier> that's going to make it much bigger
15:46:35 <yselkowitz[m]> sounds like flag day for stable then
15:46:39 <kalev> yeah, so probably best to do it as a flag day and switch everything over at once
15:47:35 <kalev> https://wiki.gnome.org/FortyFour has the gnome schedule and 44.0 is March 18
15:48:04 <kalev> so yeah, I'll get the runtime prepared and we can discuss how to switch apps over at the next meeting in two weeks or so
15:48:53 <kalev> somewhat related, how would people feel if we leave Qt 5 out of the runtime as an experiment for f38?
15:49:15 <chromebittin> last i read was 22th March for the release of 44
15:49:34 <kalev> ah, yes, chromebittin is right of course
15:49:48 <kalev> March 18 is only the tarball date
15:49:55 <yselkowitz[m]> how many apps use qt5 right now?
15:49:57 <chromebittin> ah
15:50:24 <kalev> yselkowitz[m]: that's a question I have too and it's hard to know the answer if qt 5 is part of the runtime :)
15:50:49 <kalev> the package generation scripts leave out anything that's part of the runtime so I can't easily look at flatpak yaml files
15:51:07 <kalev> in any case, we don't pre-install anything on silverblue that uses qt 5
15:51:36 <kalev> we used to have mediawriter, but that has since switched to qt 6 and it bundled the qt 6 libraries and doesn't use them from the runtime
15:51:43 <travier> It's used by the fedora media writer that is shipped by default AFAIK
15:51:47 <yselkowitz[m]> I've been working on kde 5/6 runtimes, a draft of 6 is buildable but untested, but 5 had problems with deps on systemd etc.
15:51:50 <kalev> so we'd get a net reduction of silverblue installer if we drop qt 5
15:51:51 <travier> hum ok
15:52:10 <rishi[m]> I remember jgrulich was saying something about qt5  in the first meeting.
15:52:34 <rishi[m]> Won't it make sense to drop it when we have the separate KDE runtime?
15:52:47 * rishi[m] goes back to his cave :P
15:53:10 <travier> I'd argue we should mirror the Flathub layout to make this simpler for developers targeting the runtimes
15:53:12 <kalev> not sure what to do wrt silverblue and mediawriter if it ends up switching to a second runtime
15:53:36 <kalev> should silverblue then come with both the GNOME and KDE runtimes to support GNOME apps + mediawriter?
15:53:42 <travier> (mirror "as much as possible")
15:53:47 <yselkowitz[m]> I've been going back and forth on this, now wondering if the main runtime -- at least for a bit longer -- should have core qt5 and qt6 components to avoid two runtimes in silverblue for mediawriter, but then what would happen with kinoite?
15:54:15 <kalev> yes, indeed, that's the other part of the equation
15:54:19 <travier> I'd say media writer should keep bundling
15:54:39 <travier> We should aim for a single runtime for each variant
15:54:47 <yselkowitz[m]> but make that the sole exception (once we sort out kde runtimes)?
15:55:41 <travier> +1
15:55:53 <kalev> or maybe have only KDE apps target the KDE runtimes and everything else would use the other runtime?
15:56:05 <kalev> not sure, it's a balance question
15:56:52 <kalev> anyway, my proposal wrt qt5 is to drop it temporarily from the f38 runtime so we get a clearer picture how many apps use it and if it's even possible to build it as bundled
15:57:01 <kalev> and we can revisit it next week to see if we should add it back
15:57:24 <kalev> how does that sound?
15:57:59 <kalev> right now we don't even know if qt5 builds cleanly for /app as it being part of the runtime makes all the experiments harder
15:58:40 <yselkowitz[m]> I'd like to see how many of my flatpaks would be affected
15:58:54 <travier> everything else pre-loaded on Silverblue is GNOME apps so +1 from me
15:58:54 <yselkowitz[m]> not sure if any before my involvement use qt5 or not
15:59:32 <kalev> there are some, but I don't know how to figure out which exactly until we drop them from the runtime and re-generate the module files with fedmod
15:59:54 <kalev> anyway, we are over time here and the QA meeting is starting
15:59:56 <yselkowitz[m]> time
16:00:07 <kalev> thanks for coming everybody!
16:00:10 <kalev> #endmeeting