#meeting-1:fedoraproject.org log

<@kalev:fedora.im>

15:30:13

!startmeeting Fedora Flatpak Packaging SIG

<@meetbot:fedora.im>

15:30:13

Meeting started at 2024-01-22 15:30:13 UTC

<@meetbot:fedora.im>

15:30:13

The Meeting name is 'Fedora Flatpak Packaging SIG'

<@kalev:fedora.im>

15:30:18

!meetingname flatpak-sig

<@kalev:fedora.im>

15:30:22

!topic Init process

<@kalev:fedora.im>

15:31:23

Welcome to another Flatpak SIG weekly meeting! I've started it in fedora-meeting-1 this time to avoid running into the QA meeting that starts at the top of the hour in the main meeting channel.

<@kalev:fedora.im>

15:31:54

Hopefully I got https://calendar.fedoraproject.org/meeting/10431/ right as well.

<@kalev:fedora.im>

15:32:00

Who's around for the meeting today?

<@kalev:fedora.im>

15:37:08

Anyone know if Location: fedora-meeting-1@irc.libera.chat is the way to go to book meeting rooms on matrix?

<@kalev:fedora.im>

15:38:23

Seems a bit weird to use irc.libera.chat, but it seems like almost all other meetings are still doing that and it's hard to check if rooms are free if some suddenly switch to a different room ID

<@smooge:fedora.im>

15:38:25

no sorry don't know

<@smooge:fedora.im>

15:38:51

i am not sure this has been looked at very much

<@smooge:fedora.im>

15:39:24

I am not sure if people are knowing they should have updated fedora-calendar or not beyond saying "Its in matrix now."

<@yselkowitz:fedora.im>

15:40:59

!hello

<@zodbot:fedora.im>

15:41:00

Yaakov Selkowitz (yselkowitz)

<@kalev:fedora.im>

15:42:22

!hello

<@zodbot:fedora.im>

15:42:23

Kalev Lember (kalev)

<@kalev:fedora.im>

15:43:22

Looks like it's just us 3 today

<@kalev:fedora.im>

15:44:17

What do we have for topics? I've been travelling and offline and not very up to date

<@kalev:fedora.im>

15:44:29

sure :)

<@kalev:fedora.im>

15:44:43

!topic When can we turn off the old flatpak build infra?

<@yselkowitz:fedora.im>

15:46:32

I've been too busy with ELN to work on the issues with the libreoffice flatpak

<@yselkowitz:fedora.im>

15:46:36

any update on evolution?

<@kalev:fedora.im>

15:47:28

I haven't heard anything and we don't have Owen here to ask

<@kalev:fedora.im>

15:47:39

Looks like https://src.fedoraproject.org/rpms/evolution-data-server/pull-request/6 is still unmerged and no recent updates there

<@yselkowitz:fedora.im>

15:49:38

maybe this then: we make one final build of the f38 runtime, LO, and evo now to buy us some more time, and then let releng shut it down, and either we get them migrated to f39 (or early f40) or worst case we EOL them?

<@nirik:matrix.scrye.com>

15:49:43

I want to give time to get everything done, but I really want to shut it off too. ;)

<@kalev:fedora.im>

15:50:10

I'd be fine with the plan, but let's make sure Owen is on board with it as well

<@yselkowitz:fedora.im>

15:50:40

evo seems really close, LO has some issues but they *should* be solvable, I just haven't found the right combination of changes yet

<@kalev:fedora.im>

15:52:06

I can take on doing the final builds for evo and LO for F38, do you want to do the runtime? And then we can maybe discuss sunsetting once they've moved to stable and seem to actually work.

<@kalev:fedora.im>

15:52:29

... and when Owen is around :)

<@yselkowitz:fedora.im>

15:52:34

I can do the runtime

<@nirik:matrix.scrye.com>

15:52:52

thanks. Just let me know. ;)

<@kalev:fedora.im>

15:53:01

will do!

<@kalev:fedora.im>

15:53:09

excellent, then we have a plan here

<@yselkowitz:fedora.im>

15:53:16

sorry this has taken so long, it's always that last 1%

<@yselkowitz:fedora.im>

15:53:25

even less, really

<@nirik:matrix.scrye.com>

15:53:46

yeah, often turns out that way. :)

<@kalev:fedora.im>

15:54:57

!info We are going to do final F38 builds of LibreOffice and Evolution, and one final build for the F38 flatpak runtime. That should hopefully buy us enough time so that we can sunset the old build infra and move them to the F39 runtime.

<@kalev:fedora.im>

15:55:26

!info openh264

<@kalev:fedora.im>

15:55:29

err

<@kalev:fedora.im>

15:55:31

!undo

<@kalev:fedora.im>

15:55:36

!topic openh264

<@kalev:fedora.im>

15:55:59

Nothing really from my side here: I've been travelling and offline. https://pagure.io/releng/issue/11823#comment-891833 is still waiting on releng/Cisco.

<@otaylor:fedora.im>

15:56:04

(around now)

<@kalev:fedora.im>

15:56:28

Oh hey! Can you see the scrollback and the infra question from Kevin?

<@yselkowitz:fedora.im>

15:56:31

Kalev Lember last time we discussed that we should NOT wait on cisco

<@kalev:fedora.im>

15:57:04

right, but like I said, I haven't looked at it more in the mean time

<@otaylor:fedora.im>

15:58:12

I don't have an update on evolution - not because there has been any holdup, but just because I haven't gotten to looking at it ... let me see if I can coordinate with mcrha this week to make things happen.

<@kalev:fedora.im>

15:59:33

Awesome! Thanks, Owen

<@otaylor:fedora.im>

16:00:05

It's all straight forward - I had working test builds here months ago.. no engineering at this point, just landing changes, making builds.

<@kalev:fedora.im>

16:01:12

should I still do last F38 based Evolution builds like yselkowitz suggested, or hold off on that for now?

<@otaylor:fedora.im>

16:02:12

I think you can hold off - let's try and just get this moved to F39.

<@kalev:fedora.im>

16:02:36

Alright!

<@kalev:fedora.im>

16:03:48

What else do we have to discuss today?

<@yselkowitz:fedora.im>

16:05:14

review open tickets?

<@otaylor:fedora.im>

16:05:28

I think I'm going to push off doing anything with automation of rebuilds until the next cycle... I'm pretty swamped with other stuff.

<@otaylor:fedora.im>

16:07:15

There's basically two parts to that - setting up the ELN rebuild infrastructure to work for flatpaks- that should be pretty easy (?) - but actually rebuilding the Flatpaks and filing updates is straight up new code. I don't think it will be hard, but maybe needs some care about failure notifications, etc.

<@kalev:fedora.im>

16:07:39

do you by any chance have fixes for the flatpak-status page so that we could easily see what's missing?

<@otaylor:fedora.im>

16:08:16

There might be a middle ground of semi-automation - once we have the rpm rebuilds automated, have a simple script run fro the command line that checks whether rebuilds are needed.

<@otaylor:fedora.im>

16:09:14

Hmm, that's going to require some changes for the new stuff, but it definitely is worthwhile to have. Let me try and find at least time for that in the short term.

<@kalev:fedora.im>

16:09:57

Thanks - I used that previously and it was really helpful. I even had a local copy of it running as your page stopped updating at some point :)

<@otaylor:fedora.im>

16:11:29

The RPM rebuild stuff is less interesting to me than it was originally, since I made 'flatpak-module build-rpms' work nicely, but I think it's still useful to have a rebuild service, so that if a maintainer breaks the flatpak build, that bubbles up immediately rather than when we try to rebuild the flatpak.

<@yselkowitz:fedora.im>

16:12:15

we definitely should automate it, because otherwise flatpaks will lag rpms unless someone is on top of them all the time

<@otaylor:fedora.im>

16:12:18

I guess 'fedpkg' wrapping is also useful in the short term for maintainer friendliness and documentation friendliness

<@yselkowitz:fedora.im>

16:12:41

e.g. over break I updated dozens of flatpaks to match f39-updates

<@kalev:fedora.im>

16:13:49

For the last 6 months, I've been on top of GNOME flatpaks and building them together with GNOME package updates, but now amigadave is going to be building GNOME rpm updates for the next 6 months and I'm going to lose track of what needs building for flatpak.

<@kalev:fedora.im>

16:14:05

How do you know what needs building for KDE flatpaks, yselkowitz ?

<@otaylor:fedora.im>

16:14:31

tjhe sooner we get things automated, the better, definitely - just don't want to overpromise here.

<@yselkowitz:fedora.im>

16:15:05

most KDE flatpaks are from "gear", meaning they are shipped together on a regular cadence.

<@kalev:fedora.im>

16:15:29

Ah ok, so you just build everything after the release has landed?

<@yselkowitz:fedora.im>

16:16:01

basically

<@yselkowitz:fedora.im>

16:16:26

~115 currently fall into that category

<@yselkowitz:fedora.im>

16:18:05

hopefully f40 will be the last that needs a kde5 runtime, and that just for some stragglers, but no promises

<@kalev:fedora.im>

16:19:29

!topic Open Floor

<@yselkowitz:fedora.im>

16:19:53

so this is a "bigger" issue, but you may have noticed that e.g. in gnome software some apps have multiple listings

<@kalev:fedora.im>

16:20:33

is that because of app IDs differing?

<@yselkowitz:fedora.im>

16:20:34

I haven't fully debugged it, but my current guess is that's because of differing app-id between rpms, fedora flatpaks, and flathub

<@otaylor:fedora.im>

16:20:53

yselkowitz: yes, I think that's the case.

<@kalev:fedora.im>

16:21:17

We could do something to fix it on the fedora flatpak side - whenever we rename an app ID, we could automatically add <provides> or whatever the tag was to provide the _old_ app ID

<@kalev:fedora.im>

16:21:34

This way, gnome-software should know how to map them together, hopefully :)

<@yselkowitz:fedora.im>

16:21:50

don't we need to fix these in the RPMs themselves?

<@otaylor:fedora.im>

16:21:52

Kalev Lember: is there code for that?

<@kalev:fedora.im>

16:21:57

no, just an idea

<@yselkowitz:fedora.im>

16:22:40

my thought is that we just need to fix the RPMs to use a real app-id (usually instead of $%name.desktop)

<@yselkowitz:fedora.im>

16:22:47

my thought is that we just need to fix the RPMs to use a real app-id (usually instead of %name.desktop)

<@kalev:fedora.im>

16:22:55

I mean, there is code in gnome-software that looks at compatibility provides and tries to map them together. We just don't populate the data for that in appstream data.

<@otaylor:fedora.im>

16:23:16

Kalev Lember: Probably woudl be good to automate some data collection across the Fedora Flatpaks to see how many issues there are - and see if we can just fix the RPMs

<@otaylor:fedora.im>

16:23:51

That was what I was asking about compatibility provides - whether there is code for that - I ididn't even know compatibility provides was a thing

<@yselkowitz:fedora.im>

16:23:51

the fedora flatpaks generally use ids which match flathub, with firefox and thunderbird being exceptions

<@otaylor:fedora.im>

16:24:13

(gnome-shell once upon a time had a hard-coded list of apps where the ID changed)

<@yselkowitz:fedora.im>

16:24:13

but the rpms otoh are often just %name.desktop

<@kalev:fedora.im>

16:25:24

Firefox desktop file is already renamed to match flathub in rawhide, so hopefully we can update the flatpak packaging to match it once we update it to F40

<@yselkowitz:fedora.im>

16:25:41

if there is support for provides, that would help solve a few cases where flathub isn't really correct

<@kalev:fedora.im>

16:27:30

I can look into adding a container.yaml field to pass the provides down to appstream compose, so that we can at least add them manually where needed

<@yselkowitz:fedora.im>

16:28:13

but openh264 first please

<@otaylor:fedora.im>

16:29:12

Note that a flathub / fedora mismatch also causes problems for switching back and for between the two (assuming that we *want* app config/data to migrate) - in a way that provides/id will not help with

<@kalev:fedora.im>

16:29:48

ah, yes. I think it really makes sense to try to keep the two matching as much as possible.

<@yselkowitz:fedora.im>

16:31:35

well if we fix ff/tb during the f40 migration then we're basically there iirc

<@otaylor:fedora.im>

16:32:42

Kalev Lember: do you think rename-desktop-file should do an *automatic* provides.id ?

<@kalev:fedora.im>

16:33:00

Yes, that was my idea - what do you think of it?

<@otaylor:fedora.im>

16:34:01

I think I'd want us to do some testing to make sure that it actually works as expected - that you get a single entry in gnome software, and that you can switch between the rpm and the flatpak through the dropdown

<@otaylor:fedora.im>

16:36:54

Beyond that, I think it's probably a good idea. While fixoing the desktop file upstream is the best option, it's a lot to ask of someone packaging the Flatpak.

<@kalev:fedora.im>

16:37:51

Yep, my thinking exactly.

<@kalev:fedora.im>

16:38:46

We are out of time now - anything else urgent or should we end the meeting?

<@otaylor:fedora.im>

16:39:17

Nothing else urgent I know of.

<@kalev:fedora.im>

16:39:29

Alright! See you all in two weeks then.

<@kalev:fedora.im>

16:39:34

!endmeeting