2023-11-20 15:36:47
<@kalev:fedora.im>
!startmeeting Fedora Flatpak Packaging SIG
2023-11-20 15:36:47
<@meetbot:fedora.im>
Meeting started at 2023-11-20 15:36:47 UTC
2023-11-20 15:36:47
<@meetbot:fedora.im>
The Meeting name is 'Fedora Flatpak Packaging SIG'
2023-11-20 15:37:00
<@kalev:fedora.im>
!meetingname flatpak-sig
2023-11-20 15:37:07
<@kalev:fedora.im>
!topic Init process
2023-11-20 15:38:17
<@yselkowitz:fedora.im>
!user hello
2023-11-20 15:38:18
<@zodbot:fedora.im>
Yaakov Selkowitz (yselkowitz)
2023-11-20 15:38:34
<@kalev:fedora.im>
I think we only have until the top of the hour today as the QA meeting should start then
2023-11-20 15:38:44
<@kalev:fedora.im>
!user hello
2023-11-20 15:38:45
<@zodbot:fedora.im>
Kalev Lember (kalev)
2023-11-20 15:38:51
<@siosm:matrix.org>
!user siosm
2023-11-20 15:38:52
<@zodbot:fedora.im>
**Usage:** !user <subcommand> [...]
● hello [username] - Return brief information about a Fedora user.
● info [username] - Return brief information about a Fedora user.
● localtime <username> - Returns the current time of the user.
2023-11-20 15:39:02
<@siosm:matrix.org>
!user hello siosm
2023-11-20 15:39:04
<@zodbot:fedora.im>
Timothée Ravier (siosm) - he / him / his
2023-11-20 15:39:05
<@kalev:fedora.im>
nice that we have a working meetbot again :)
2023-11-20 15:39:47
<@kalev:fedora.im>
soooo, what can we discuss in 20 minutes? maybe remaining F38 flatpak status and what work remains to be done to switch the last flatpaks over to F39?
2023-11-20 15:39:59
<@otaylor:fedora.im>
Hi everyone
2023-11-20 15:40:09
<@kalev:fedora.im>
Hi Owen!
2023-11-20 15:40:51
<@otaylor:fedora.im>
Yeah, I think probably concentrating on how we retire F38 (and let the infrastructure be retired) is most helpful
2023-11-20 15:41:32
<@kalev:fedora.im>
!topic F38 flatpak status - switching the remaining apps to F39
2023-11-20 15:42:13
<@kalev:fedora.im>
OK, so I am aware of libreoffice, yselkowitz do you know what else is there?
2023-11-20 15:42:20
<@yselkowitz:fedora.im>
we have four flatpaks left:
2023-11-20 15:42:44
<@yselkowitz:fedora.im>
ardour6, which I'll replace soon with "ardour" (ardour8)
2023-11-20 15:42:57
<@yselkowitz:fedora.im>
evolution
2023-11-20 15:43:01
<@yselkowitz:fedora.im>
libreoffice
2023-11-20 15:43:21
<@yselkowitz:fedora.im>
and prusa-slicer, which is waiting on a PR for NLopt
2023-11-20 15:43:30
<@kalev:fedora.im>
let's go one by one and discuss each quickly
2023-11-20 15:44:02
<@kalev:fedora.im>
1) ardour6: the way ardour is packaged in fedora is so that there are parallel installable ardour6, ardour7, ardour8 rpms
2023-11-20 15:44:29
<@kalev:fedora.im>
with flatpaks, someone created a similar repo structure, but used an unversioned flatpak ID
2023-11-20 15:44:59
<@kalev:fedora.im>
so that ardour4 shipped org.ardour.Ardour, and later ardour6 shipped org.ardour.Ardour again
2023-11-20 15:45:38
<@kalev:fedora.im>
I suggested to yselkowitz that this is weird repo setup and we thought it would make sense to just switch to shipping the latest ardour 8 as flatpaks/ardour with org.ardour.Ardour
2023-11-20 15:46:18
<@kalev:fedora.im>
are others ok with the plan? the other option I guess would be to do flatpaks/ardour6 with org.ardour.Ardour6 and flatpaks/ardour7 with org.ardour.Ardour7 and so on
2023-11-20 15:47:01
<@yselkowitz:fedora.im>
or org.ardour.Ardour//6, //7, etc., but I don't know what the value to multiple versions are
2023-11-20 15:47:03
<@otaylor:fedora.im>
evolution is really the most problematical here, because there's some work needed in evolution-data-server to adapt to the new scheme, and mcrha is not interested in doing it - he basically doesn't see much point in having a Fedora Flatpak of it and the old scheme works for Flathub. There was *some* discussion of using this as a test case for retiring a Fedora Flatpak in favor of Flathub (and mcrha is the GNOME Software maintainer too), but I don't think that's feasible on a F38-retirement timeline. So, maybe we just EOL with no replacement? I don't know. Or, we could go back to mcrha and his team and make the case that doing the EDS work might not seem useful but it's going to be really useful for Fedora.
2023-11-20 15:47:36
<@otaylor:fedora.im>
I don't see a reason to have a parallel installable Ardour. We don't do that for so many other apps. But I think we should consult with the Ardour packager on that?
2023-11-20 15:47:38
<@yselkowitz:fedora.im>
how many apps need a custom-built e-d-s?
2023-11-20 15:48:45
<@otaylor:fedora.im>
Upstream, I think Contacts might use a custom EDS, but we ship Contacts using the system EDS.q
2023-11-20 15:48:57
<@kalev:fedora.im>
good idea to consult with ardour packager - yselkowitz do you want to loop nphilipp into this?
2023-11-20 15:48:58
<@otaylor:fedora.im>
(And another one or two core apps, forget which one.)
2023-11-20 15:49:18
<@kalev:fedora.im>
Calendar?
2023-11-20 15:49:33
<@otaylor:fedora.im>
Yeah. In any case.
2023-11-20 15:49:53
<@yselkowitz:fedora.im>
do those include the full e-d-s or just the libs? where does the service customization get hardcoded?
2023-11-20 15:50:22
<@otaylor:fedora.im>
So ,basically, what needs to happen is that EDS needs to grow a config file that both the libs and the daemon read, that adds a prefix to it.
2023-11-20 15:50:53
<@kalev:fedora.im>
Ah, and that config file would be different for each of the apps?
2023-11-20 15:51:07
<@yselkowitz:fedora.im>
yeah, like we did with tracker-miners
2023-11-20 15:51:33
<@otaylor:fedora.im>
Contacts / Calender just have the libs, and the config file would be absent to be "OK, use the normal prefix", but Evolution would have a config file and the daemon, and modified service files.
2023-11-20 15:52:05
<@yselkowitz:fedora.im>
but right now, does the service name get hardcoded to the libs too (I suppose it must)?
2023-11-20 15:52:33
<@otaylor:fedora.im>
Yes right now it's hardcoded in the libs, hence the need for a config file that the libs read.
2023-11-20 15:52:38
<@kalev:fedora.im>
Sounds like a good plan to me, but I guess the hardest part is convincing evolution people that it makes sense to add this mechanism.
2023-11-20 15:54:02
<@kalev:fedora.im>
For what it's worth, I am not super convinced that it makes sense to retire evolution flatpak - if we continue doing fedora flatpaks, then in my opinion it would diminish the value a lot of some random apps suddenly go missing and users need to get them from elsewhere, together with yet another runtime etc.
2023-11-20 15:54:54
<@kalev:fedora.im>
I think it makes sense to have a large flatpak collection, or no collection of all. Anything in the middle is just confusing.
2023-11-20 15:55:18
<@otaylor:fedora.im>
I understand mcrha's perspective that there's a perfectly good Flathub Flatpak if you want that, Evolution won't be in RHEL 10 (I think I'm allowed to say that), so why put effort into it. But on the other hand, we have no way to know how many people have the Fedora Evolution flatpak installed, and no experience around what happens if we remove it, and certainly just fixing EDS is least effort for now.
2023-11-20 15:55:22
<@yselkowitz:fedora.im>
I don't like this attitude of dropping downstream packaging just because upstream says so either
2023-11-20 15:55:51
<@yselkowitz:fedora.im>
it's already in Content Resolver, so np saying it now
2023-11-20 15:56:02
<@kalev:fedora.im>
I understand mcrha's perspective as well, but I am not convinced it's the best approach for Fedora.
2023-11-20 15:56:37
<@otaylor:fedora.im>
yselkowitz: well, mcrha is basically singe handedly all of upstream and downstream for giant application whose glory days are behind it.
2023-11-20 15:58:38
<@otaylor:fedora.im>
Kalev Lember: I think I'd be fine with it *if* we have had a Fedora => Flathub replacement mechanism, but we have neither the mechanism nor the policies that would allow us to do that.
2023-11-20 15:59:37
<@yselkowitz:fedora.im>
continue in channel?
2023-11-20 15:59:40
<@kalev:fedora.im>
!info 4 flatpaks remaining to be ported to F39 runtime: ardour6, evolution, libreoffice, prusa-slicer
2023-11-20 16:00:01
<@kalev:fedora.im>
yep, I think we need to vacate the meeting channel now
2023-11-20 16:00:12
<@kalev:fedora.im>
!endmeeting