15:00:13 <kalev> #startmeeting Fedora Flatpak Packaging SIG
15:00:13 <zodbot> Meeting started Mon Feb  6 15:00:13 2023 UTC.
15:00:13 <zodbot> This meeting is logged and archived in a public location.
15:00:13 <zodbot> The chair is kalev. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
15:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:13 <zodbot> The meeting name has been set to 'fedora_flatpak_packaging_sig'
15:00:13 <kalev> #meetingname flatpak-sig
15:00:13 <kalev> #topic Init process
15:00:13 <zodbot> The meeting name has been set to 'flatpak-sig'
15:00:37 <kalev> alright, time for another weekly meeting! let's give folks a few minutes to join
15:00:48 <kalev> .hello kalev
15:00:49 <zodbot> kalev: kalev 'Kalev Lember' <klember@redhat.com>
15:01:41 <JanGrulich[m]> .hello jgrulich
15:01:41 <tpopela[m]> .hello tpopela
15:01:42 <zodbot> JanGrulich[m]: jgrulich 'Jan Grulich' <jgrulich@redhat.com>
15:01:45 <zodbot> tpopela[m]: tpopela 'Tomas Popela' <tpopela@redhat.com>
15:02:07 <FelipeBorges[m]> .hello feborges
15:02:08 <zodbot> FelipeBorges[m]: feborges 'Felipe Borges' <feborges@redhat.com>
15:02:40 <travier> .hello siosm
15:02:41 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
15:03:41 <kalev> looks like most people are here now, so let's get started with announcements
15:03:46 <kalev> #topic Announcements
15:04:14 <kalev> I have a few things I've noted down that happened over the last two weeks, but feel free to add if you have anything
15:04:42 <kalev> first, yselkowitz added new gstreamer1-plugins-ugly-free and jxl-pixbuf-loader packages to the flatpak runtime
15:05:05 <kalev> #info gstreamer1-plugins-ugly-free and jxl-pixbuf-loader packages added to the flatpak runtime
15:05:28 <kalev> and then a bunch of new packages are pulled in as dependencies of existing packages: liba52, libmpeg2, opencore-amr, snappy, vo-amrwbenc, xvidcore, zvbi
15:05:45 <kalev> I think most of these are due to ffmpeg growing new deps and looks fine to me
15:06:08 <kalev> then I fixed a longstanding issue with cheese where it didn't detect any cameras
15:06:50 <bcotton> .hello2
15:06:50 <kalev> it turned out to be a gstreamer1-plugins-good issue in the flatpak runtime: gstreamer1-plugins-good needed to be built differently compared to a regular fedora installation to be able to detect devices
15:06:50 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:06:52 <OwenTaylor[m]> .hello otaylor
15:06:56 <zodbot> OwenTaylor[m]: otaylor 'Owen Taylor' <otaylor@redhat.com>
15:07:00 <tpopela[m]> thank you for fixing Cheese kalev!
15:07:17 <kalev> so I added build conditionals to gstreamer1-plugins-good and added it to the runtime as a modular build
15:07:27 <kalev> tpopela[m]: np! :) maybe we can add it to Silverblue now
15:07:56 <kalev> it was actually the first package we build diferently for flatpak, everything else in the runtime is just re-used rpms
15:08:09 <kalev> so it was exciting to try a new thing, but it turned out to just work (tm) :)
15:08:34 <kalev> then, sbergmann got a new libreoffice build out that had been stuck for a while due to a java build issue
15:08:50 <kalev> oh, I keep forgeting infos
15:09:23 <kalev> #info longstanding Cheese issue with camera detection fixed, was due to gstreamer1-plugins-good needing to be built differently in the flatpak runtime
15:09:51 <kalev> #info libreoffice update done that was blocked by a java build issue
15:10:06 <kalev> #info new flatpak packages currently in testing: klavaro, remmina, gtkhash, exaile, howl, exfalso, audacious
15:10:39 <kalev> I got this list from https://bodhi.fedoraproject.org/releases/F37F - would be useful if people could look at it from time to time and give karma and try out new flatpaks :)
15:10:55 <kalev> there have been more over the last 2 weeks but this is just what's currently in testing
15:11:08 <kalev> yselkowitz did 6 of these and pwalter 1
15:11:38 <kalev> and then I did a bunch of rebuilds to keep existing flatpaks updated
15:11:43 <kalev> probably time to do another round now
15:11:52 <kalev> #info would be useful if people could test new flatpaks and leave karma in bodhi and report any issues to bugzilla
15:12:21 <kalev> then we got the flatpak-sig group created, so we could start adding it to flatpaks now and adding people to it
15:12:33 <kalev> #info flatpak-sig group created
15:12:56 <kalev> and then we have the new bot in the irc channel. I think we should have a separate meeting topic about that, not sure how useful it really is
15:13:03 <kalev> #info new fedmsg bot in irc channel
15:13:35 <kalev> and last, I just noticed that flatpak 1.15.2 got release like half an hour ago, but I didn't spot anything that would be of particular interest to us
15:13:40 <kalev> #info flatpak 1.15.2 released
15:13:41 <kalev> https://github.com/flatpak/flatpak/releases/tag/1.15.2
15:13:45 <tpopela[m]> I had to "ignore" it as it was too verbose and I actually had hard times to follow any discussion..
15:13:46 <kalev> ok, that's all from me :)
15:13:49 <travier> From my perspective, it killed all communication in the channel. We should probably setup a tracker / project in Pagure / Gitlab to track longer issues
15:14:06 <kalev> yeah, I feel like that too
15:14:10 <kalev> #topic IRC bot
15:14:25 <kalev> it was nice to have it to see what's going on, but it really just took over
15:14:33 <travier> We can probably make a separated channel for the bot if folks find it useful
15:14:49 <AllanDay[m]> i have a few questions about testing, when there's a minute
15:14:53 <kalev> ah, that might be good, yes
15:15:11 <kalev> AllanDay[m]: sure, we can talk about after the bot
15:15:20 <FelipeBorges[m]> or an irc feed instead of the bot :)
15:15:23 <FelipeBorges[m]> rss*
15:15:42 <kalev> FelipeBorges[m]: do you know how to set it up? :)
15:16:08 <kalev> sounds like everybody is in agreement to remove the bot from the channel then :)
15:16:25 <kalev> I can take that as an action item
15:16:58 <kalev> #info most people find the fedmsg bot too verbose and effectively killed all communication in the channel
15:17:34 <kalev> #action Kalev to do an ansible PR to drop the bot from the channel
15:17:45 <FelipeBorges[m]> no, but I will research how doable that it.
15:17:52 <kalev> did anyone find it useful? should we have a separate channel for the bot?
15:18:00 <kalev> thanks, Felipe!
15:18:18 <travier> It's not useful for me as I can't choose what to track be notified about
15:18:41 * kalev nods.
15:19:07 <FelipeBorges[m]> fair enough. Let's not sidetrack the convo then. sorry.
15:19:10 <kalev> it is verbose in irc, but on matrix it seemed to be extremely annoying because matrix clients expand all of the links as well
15:19:13 <kalev> ok
15:19:21 <travier> My be useful for someone who want to have the full picture view of everything happening. Not sure we have someone doing that?
15:19:37 <travier> might*
15:20:16 <kalev> I try to keep an eye on things but I can also find things out from other places :)
15:20:21 <kalev> let's just kill it then
15:20:26 <kalev> ok, on to Allan's topic!
15:20:32 <kalev> #topic How to test Fedora flatpaks
15:20:53 <travier> Having a quick guide for that in the wiki would be nice indeed
15:21:02 <kalev> so, we have two remotes for fedora: one is called 'fedora' and the other one is called 'fedora-testing'
15:21:17 <AllanDay[m]> agree. a list of common things to look for would be great
15:21:35 <kalev> what would be a good place for it?
15:22:16 <kalev> anyway, both of the remotes are pre-installed for both workstation and silverblue, but only 'fedora' is enabled. 'fedora-testing' is in disabled state by default
15:22:32 <kalev> it's something like 'flatpak modify-remote --enable fedora-testing' or something along those lines to enable it
15:23:04 <kalev> and then there's the component of leaving regression testing feedback in bodhi for things that are in the testing remote
15:23:17 <kalev> and the bodhi link is https://bodhi.fedoraproject.org/releases/F37F
15:23:40 <travier> A small sub-package linked from the Flatpak SIG main page with that info would be great
15:23:48 <kalev> for regular fedora packages, we have the command line 'fedora-easy-karma' thing to help find out what's in testing and to leave karma (feedback), but we don't have anything like that for flatpaks
15:24:16 <kalev> I could copy-paste what I just wrote to a wiki page somewhere and get that started :)
15:24:25 <kalev> #action Kalev to start a wiki page with testing instructions
15:25:18 <travier> https://fedoraproject.org/wiki/SIGs/Flatpak/Testing
15:25:33 <kalev> nice! I'll fill that out a bit
15:25:59 <AllanDay[m]> so the usual karma process is used for graduating apps from fedora-testing to fedora?
15:26:02 <kalev> ok, let's move on. we have a bunch of topic in https://etherpad.opensuse.org/p/fedora-flatpaks-sig
15:26:07 <kalev> topics
15:26:27 <kalev> yselkowitz asked for a few, but I don't think he's here right now, so let's skip those
15:26:37 <kalev> #topic libmodulemd1
15:26:56 <kalev> so, I noticed that libmodulemd1 is about to get axed from Fedora because it's been FTBFS since F36
15:27:09 <kalev> it's a problem for us because fedmod uses it
15:27:29 <AllanDay[m]> the other question i had about testing was where to report issues...
15:28:54 <kalev> so, not sure what to do with libmodulemd1: I guess we should fix it to build since we don't have a replacement for it yet?
15:28:56 <tpopela[m]> :/ - so hopefully we will get rid of fedmod, but I don't know whether we will be able to get rid of libmodulemd1 as well.. Jan Beran is libmodulemd1 still required by the "new" code?
15:28:57 <travier> Issues should probably be reported as BZs? Not sure if we have something better
15:29:37 <travier> (and I'll have to go at the 30 min mark. See you next tie)
15:29:39 <kalev> there is the new libmodulemd package that most other things use, but it's not entirely trivial porting effort
15:29:39 <travier> time*
15:29:47 <kalev> travier: see you! thanks for coming
15:30:11 <AllanDay[m]> travier: would a flatpak packager see issues reported to bugzilla?
15:30:41 <travier> From my perspective, we should have a group / project in Gitlab / pagure to centralize things
15:33:03 <kalev> so, I guess we should fix libmodulemd1 for now until we have something better
15:33:59 <kalev> I could do that unless someone else wants to?
15:34:41 <travier> (I have no opinion here as I have no idea how this works)
15:34:53 <OwenTaylor[m]> Switching the fedmod code to current modulemd is certainly not a huge task - probably an hour or two.
15:35:38 <kalev> maybe we should do that instead then
15:36:35 <yselkowitz[m]> .hello yselkowitz
15:36:36 <zodbot> yselkowitz[m]: yselkowitz 'Yaakov Selkowitz' <yselkowi@redhat.com>
15:36:51 <OwenTaylor[m]> Presumably Jan Beran will be doing that to the parts of fedmod he's moving into flatpak-module-tools, but unless that is ready to go, sounds like we need something short term
15:37:24 <kalev> yeah, would be good to keep the existing tools working until we have a replacement
15:38:11 <kalev> OwenTaylor[m]: do you want to look into it or want me to? I could maybe do an initial porting cut and if I run into issues, maybe you can help?
15:38:29 <tpopela[m]> I will try to get a status update from Jan by the next week.. then we can decide which way we will go (whether to update the current fedmod codebase or the one in flatpak-module-tools)
15:38:54 <kalev> sounds like a plan
15:39:06 <kalev> I think libmodulemd1 is about get retired next week, if I remember it right
15:39:22 <kalev> but we can unretire it after that for 6 more weeks without needing a re-review of the package
15:39:23 * yselkowitz[m] can look into fixing it
15:39:48 <kalev> ah nice, thanks yselkowitz[m]
15:40:02 <kalev> #info yselkowitz[m] to look into fixing libmodulemd1 FTBFS
15:40:28 <kalev> #info Owen to talk to Jan to see how far along fedmod replacement is
15:40:53 <yselkowitz[m]> looks like valgrind's finding a memory leak, causing the testsuite to fail, probably just best to skip that for now
15:41:03 <kalev> yselkowitz[m]: I looked at it briefly a few weeks ago and it looked like it was using static keyword wrong
15:41:04 <OwenTaylor[m]> #action tpopela to to talk to Jan to see how far along fedmod replacement is :-)
15:41:18 <kalev> ha! and I thought it was you who said that!
15:41:35 <tpopela[m]> yes! :)
15:41:55 <OwenTaylor[m]> Certainly we want to drop libmodulemd1, but we shouldn't spend time porting parts of fedmod that we aren't using if we can avoid it
15:42:34 <kalev> yselkowitz[m]: if I remember it right, it was using static for functions that were used in a separate compilation unit
15:42:43 <kalev> and that caused the tests to fail :)
15:42:47 <tpopela[m]> https://koji.fedoraproject.org/koji/taskinfo?taskID=96366742 - btw. the build succeeded on aarch64..
15:42:57 <kalev> so unless I misread something, just killing the static keyword might fix the tests
15:43:05 <yselkowitz[m]> the testsuite is not run on aarch64
15:43:09 <kalev> ha!
15:43:43 <kalev> anyway, I think we have a plan of attack for this
15:43:46 <kalev> let's move on
15:44:14 <kalev> #topic place to track issues
15:44:45 <kalev> so, this came up in the last Workstation WG meeting and Allan already brought it up here as well today
15:45:07 <travier> A group on Gitalb.com/fedora would be my prefered choice but I'll be happy with a repo on pagure instead
15:45:15 <kalev> we don't really have a place to track flatpak specific issues: bug go to bugzilla, but they end up assigned to people who don't know how to deal with flatpak specific issues
15:45:53 <kalev> I don't really have a preference beyond just that we need something :)
15:46:04 <travier> https://gitlab.com/fedora/sigs
15:46:40 <kalev> not that much there yet
15:48:03 <kalev> pagure has most of the other Fedora related issue trackers right now and I think that would make it easier to link from one issue tracker to another
15:48:09 <travier> it's up to each sig to move so things have happened progressively
15:48:38 <travier> Pagure is the safe choice, but is less welcoming for external users
15:49:01 * kalev agrees.
15:49:04 <kalev> what do other people think?
15:49:11 <travier> (and Pagure does not link anything automatically either)
15:50:40 <AllanDay[m]> you need separate credentials for gitlab.com, presumably?
15:50:43 <bcotton> What, exactly, does Kalev agree with?
15:50:45 <yselkowitz[m]> who's going to think to look to gitlab to report issues?
15:50:57 <bcotton> Allan Day: there's a fedora sso
15:51:06 <AllanDay[m]> Ben Cotton (he/him): ah, cool
15:51:16 <kalev> bcotton: I agreed that "Pagure is the safe choice, but is less welcoming for external users"
15:51:55 <AllanDay[m]> yselkowitz: i think i see this primarily as a tool for testers and maintainers
15:52:05 <bcotton> It's not perfect, though, because you end up with things like "Ben is @funnelfiasco instead of @bcotton even those it is a fedora resource nominally"
15:53:21 <bcotton> I have a bunch of stuff on Pagure, but I'm not sure I'd start something new there
15:53:50 <bcotton> One other thing that Gitlab gets us that Pagure doesn't is the ability to use FAS groups for acls
15:54:51 <kalev> right now my thinking is that we'd just use it for tracking issues, but not code, so acls aren't that important
15:55:20 <AllanDay[m]> i think that it should be up to the people who are going to use it 🙂 having issue tracking is more important than exactly which platform is used
15:55:44 <kalev> indeed
15:56:02 <kalev> anyone want to take an action item to set something up?
15:59:03 <kalev> I think our booked time slot is up here but we can continue discussing it in the regular channel
15:59:36 <kalev> there are a bunch of topic we didn't get to already lined up in the etherpad, but hopefully next time
15:59:48 <kalev> thanks for coming, everybody!
15:59:50 <kalev> #endmeeting