#meeting:fedoraproject.org log

<@kalev:fedora.im>

15:32:25

!startmeeting Fedora Flatpak Packaging SIG

<@meetbot:fedora.im>

15:32:26

Meeting started at 2023-12-04 15:32:25 UTC

<@meetbot:fedora.im>

15:32:26

The Meeting name is 'Fedora Flatpak Packaging SIG'

<@kalev:fedora.im>

15:32:34

!meetingname flatpak-sig

<@kalev:fedora.im>

15:32:41

!topic Init process

<@kalev:fedora.im>

15:33:03

Who's around for a flatpak SIG meeting?

<@kalev:fedora.im>

15:33:24

nice!

<@kalev:fedora.im>

15:35:21

the bi-weekly meeting dates are all confused up now, but I think it makes sense to go with what you proposed: Dec 4, Dec 18, Jan 8 and continue from there every two weeks

<@yselkowitz:fedora.im>

15:36:40

.user hello

<@yselkowitz:fedora.im>

15:36:45

!user hello

<@zodbot:fedora.im>

15:36:47

Yaakov Selkowitz (yselkowitz)

<@kalev:fedora.im>

15:37:19

hi Yaakov

<@kalev:fedora.im>

15:37:41

!info next meetings are on Dec 18, Jan 8 and continue from there every two weeks

<@kalev:fedora.im>

15:38:29

OK, so I guess we have all the usual suspects here now :)

<@kalev:fedora.im>

15:38:52

!topic F38 flatpak status

<@kalev:fedora.im>

15:39:31

I think we still have libreoffice and evolution as the main struggling points that need fixing, right?

<@yselkowitz:fedora.im>

15:39:47

afaik those are the only two left on f38

<@yselkowitz:fedora.im>

15:39:59

libreoffice is blocked by https://src.fedoraproject.org/rpms/javapackages-tools/pull-request/20 which has stalled

<@yselkowitz:fedora.im>

15:41:03

Owen Taylor update on evolution?

<@kalev:fedora.im>

15:41:14

ah, should maybe just ping again in the ticket

<@yselkowitz:fedora.im>

15:41:24

just did

<@otaylor:fedora.im>

15:42:17

evolution - Have agreement with @mcrha on patches to be carried downstream for evolution-data-server and eds, just need to be (in one case) rebased and merged, and evolution built. I'd guess we can get that done in the next few days.

<@kalev:fedora.im>

15:45:11

Owen and I and a few other people had an internal meeting about evolution flatpak last week, but mcrha sadly couldn't make it. The rest of us decided the best course of action is to carry the downstream patch and as I understand it, mcrha is OK with the plan too.

<@kalev:fedora.im>

15:46:23

I'm thinking and maybe it would be worth trying to do a EOL build of F38 flatpak runtime already and leave it in updates-testing until we get evolution and libreoffice updated.

<@kalev:fedora.im>

15:46:32

I'm thinking that maybe it would be worth trying to do a EOL build of F38 flatpak runtime already and leave it in updates-testing until we get evolution and libreoffice updated.

<@kalev:fedora.im>

15:46:58

This way, if MBS decides to stop working or something we have the EOL build done.

<@kalev:fedora.im>

15:48:33

yselkowitz: do you want to do the EOL build this time if you already have it ready?

<@yselkowitz:fedora.im>

15:48:50

sure

<@kalev:fedora.im>

15:50:19

awesome! the module manifest probably needs updating for latest rpm dependency changes to be able to do the container build

<@yselkowitz:fedora.im>

15:50:56

already included in my patch

<@kalev:fedora.im>

15:51:07

excellent!

<@kalev:fedora.im>

15:51:24

ok, next up I promised to bring up documentation

<@kalev:fedora.im>

15:51:36

!info Documentation for new flatpak build infra

<@kalev:fedora.im>

15:51:39

err

<@kalev:fedora.im>

15:51:43

!undo

<@kalev:fedora.im>

15:51:59

!topic Documentation for new flatpak build infra

<@kalev:fedora.im>

15:52:35

So we have everything working and almost all flatpaks converted, but we don't have any documentation that we could point people at

<@kalev:fedora.im>

15:53:04

Has anyone already looked at updating the docs or should I give it a stab?

<@yselkowitz:fedora.im>

15:53:46

not me

<@smooge:fedora.im>

15:54:03

hello

<@smooge:fedora.im>

15:54:10

i finally made a meeting

<@kalev:fedora.im>

15:54:18

welcome!

<@otaylor:fedora.im>

15:54:40

welcome!

<@kalev:fedora.im>

15:55:41

I'll try to get the docs updated and send some notes to the devel list, maybe we can get a few more people involved through this.

<@otaylor:fedora.im>

15:56:07

Kalev Lember: If you want to take a stab, that woudl be great. I think the first thing would be to just make it correct, and then we can see what's missing. I'd write it against flatpak-module head as if 'flatpak-module init' was released.

<@kalev:fedora.im>

15:56:27

alright!

<@kalev:fedora.im>

15:56:35

!action Kalev to update docs

<@kalev:fedora.im>

15:59:08

anything else we need to discuss today?

<@yselkowitz:fedora.im>

15:59:31

!topic openh264

<@kalev:fedora.im>

15:59:34

I'm a bit unsure how much time we have - is it still half an hour because of an openqa meeting?

<@kalev:fedora.im>

16:00:14

so the latest there is that noopenh264 package is imported, and we need to add obsoletes for that to the openh264 package that Cisco distributes

<@kalev:fedora.im>

16:01:09

I wanted to add the obsoletes to the package at the same time as updating to 2.4.0, but then the 2.4.0 upstream release took several weeks and now I found some regressions when doing the builds

<@kalev:fedora.im>

16:01:45

in hindsight, I should have just done a new 2.3.1 builds that only added obsoletes, but I wanted to avoid the overhead that's with sending the rpms to cisco and asking them to upload them

<@kalev:fedora.im>

16:02:05

anyway, I tracked down one of the regressions, https://github.com/cisco/openh264/pull/3704

<@kalev:fedora.im>

16:02:28

and doing a bisect for the other that appears to break the gmp plugin

<@kalev:fedora.im>

16:03:09

it makes it possible to put the gstreamer plugin in the runtime and swap out the stub library at runtime, exactly like it's done in the freedesktop runtime

<@kalev:fedora.im>

16:05:19

anyway, that's my update, hopefully we'll have more bits in place next time

<@kalev:fedora.im>

16:07:24

anything else for today?

<@yselkowitz:fedora.im>

16:08:17

Owen Taylor any updates on https://pagure.io/flatpak-module-tools/issues ?

<@otaylor:fedora.im>

16:09:33

Not really - hopefully I can fixup some of the easier ones this week and do another snapshot, so we get 'flatpak init' out there.

<@otaylor:fedora.im>

16:09:50

yselkowitz: what would you consider highest priority - what is blocking things?

<@yselkowitz:fedora.im>

16:10:02

#29 affects all kde apps

<@otaylor:fedora.im>

16:11:36

OK, that's not an easy one, but maybe it won't be too bad in practice. :-)

<@kalev:fedora.im>

16:11:58

and I run into #34 like every other time when doing a firefox flatpak update, because nss is in the runtime and firefox is in the app flatpak

<@kalev:fedora.im>

16:12:18

I know how to work around it so it's not so bad, but I keep running into it :)

<@otaylor:fedora.im>

16:14:59

Should we change the koji metadata to look for runtimes in f39-flatpak-updates-testing-pending ?

<@yselkowitz:fedora.im>

16:16:06

does -pending inherit -testing?

<@otaylor:fedora.im>

16:16:45

Yes.

<@otaylor:fedora.im>

16:17:31

Just doing 'f39-flatpak-updates-testing' would be painful, since you'd have to wait for the nightly compose (for no good reason for containers/flatpaks), but testing-pending would allow building against a runtime as soon as an update was created.

<@kalev:fedora.im>

16:18:17

Would it be possible to look for runtimes in both f39-flatpak-updates-testing-pending and f39-flatpak-updates-candidate?

<@kalev:fedora.im>

16:19:27

For firefox, it's either one of the two cases: 1) runtime update is created first, and then firefox built, or 2) runtime is built, followed by firefox build immediately and then both submitted together to bodhi

<@kalev:fedora.im>

16:19:45

If we just change it to f39-flatpak-updates-testing-pending I think it would make the second case not work

<@yselkowitz:fedora.im>

16:20:34

correct but filing an update doesn't seem onerous, it's equivalent to creating a buildroot override for RPM builds

<@otaylor:fedora.im>

16:20:42

Yeah, you'd have to file a bodhi update (would that break firefox in -testing?) then update it to include the firefox build.

<@kalev:fedora.im>

16:21:04

Ah, I guess that could work, yes

<@otaylor:fedora.im>

16:21:33

Looking in both places is possible, would require koji-flatpak and flatpak-module-tools updates and a builder update.

<@otaylor:fedora.im>

16:22:36

The flatpak.runtime_tag koji metadata is currently defined as a single tag, making it multiple would require code chanes. Alternatively, we could have a tag that inherits both, and point the koji-metadata to that.

<@otaylor:fedora.im>

16:23:35

THe updates-testing-pending thing makes some sense to me (matches our source tag setting for /usr => /app rebuilds) - maybe we try that for simplicity and you can report back on how painful it is for firefox?

<@kalev:fedora.im>

16:24:30

For rpm builds, nothing inherits from testing or pending, but instead there's an override tag. I wonder if something similar would make sense to for overriding flatpak runtimes? People are already used to that setup.

<@yselkowitz:fedora.im>

16:25:29

ugh that seems a bit much

<@otaylor:fedora.im>

16:26:51

I guess the advantage of that approach is that it makes it harder to accidentally push an app update in front of a runtime update that it requires, someone will hav eeo think "this runtime update is needed to rebuild app X, maybe app X will require it at runtime", but otherwise seems a bit clumsy.

<@kalev:fedora.im>

16:28:12

anyway, +1 to me to change it to inherit from f39-flatpak-updates-testing-pending, let's give it a try and see how well it works in practice

<@kalev:fedora.im>

16:28:19

anyway, +1 for me to change it to inherit from f39-flatpak-updates-testing-pending, let's give it a try and see how well it works in practice

<@kalev:fedora.im>

16:28:30

anyway, +1 from me to change it to inherit from f39-flatpak-updates-testing-pending, let's give it a try and see how well it works in practice

<@otaylor:fedora.im>

16:29:21

Kalev Lember: do you want to file a releng ticket? This will need a make-koji-release-tags script update as well as the direct change.

<@kalev:fedora.im>

16:29:50

sure, let me do that

<@kalev:fedora.im>

16:30:55

OK, and I think the meeting time is up as well now - see you all on Dec 18

<@kalev:fedora.im>

16:31:37

!endmeeting