14:00:19 #startmeeting Fedora Flatpak Packaging SIG 14:00:19 Meeting started Mon Apr 3 14:00:19 2023 UTC. 14:00:19 This meeting is logged and archived in a public location. 14:00:19 The chair is kalev. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 14:00:19 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:19 The meeting name has been set to 'fedora_flatpak_packaging_sig' 14:00:19 #meetingname flatpak-sig 14:00:19 The meeting name has been set to 'flatpak-sig' 14:00:19 #topic Init process 14:00:47 it's time for another meeting! 14:00:48 .hello siosm 14:00:49 travier: siosm 'Timothée Ravier' 14:00:49 .hello rishi 14:00:51 .hello kalev 14:00:52 rishi: rishi 'Debarshi Ray' 14:00:55 kalev: kalev 'Kalev Lember' 14:01:26 .hello jgrulich 14:01:28 JanGrulich[m]: jgrulich 'Jan Grulich' 14:01:48 so, my main thing to discuss today is F38 status 14:01:59 does anyone have anything else they want to discuss today? 14:02:57 #topic F38 status 14:03:01 I would like to propose to use kiwi for flatpak building 14:03:20 sure, we can talk about that next 14:03:44 👍️ 14:03:45 .hello tpopela 14:03:46 tpopela[m]: tpopela 'Tomas Popela' 14:03:50 OK, so from my point of view, the most important thing to get done for F38 was to update Silverblue pre-installed flatpaks to the F38 versions 14:03:53 .hello2 14:03:54 defolos: defolos 'Dan Čermák' 14:04:19 this should now be done with https://bodhi.fedoraproject.org/updates/FEDORA-FLATPAK-2023-9a8818454b that went to stable a few days ago 14:04:38 kalev++ 14:04:38 travier: Karma for kalev changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 14:04:44 and I also updated pungi-fedora with the new runtime version after it went stable 14:05:12 travier: how does it looks for KDE flatpaks? are you guys going to ship anything on F38 Kinoite? 14:05:33 the final freeze starts tomorrow so there's not much time left to make changes :) 14:05:44 No Flatpak on Kinoite 38 14:05:49 too late to test 14:05:57 * kalev nods. 14:05:58 We'll add things for F39 14:06:13 makes sense, yep 14:06:27 ok, good, then we should have everything lined up that we needed for F38 14:06:38 👍 14:06:41 so next up is updating the rest of the flatpaks 14:07:16 hello 14:07:30 not sure how to best approach it, would be nice to do some kind of team effort 14:08:14 kalev: at least the LO will be handled by Stephan.. I made him aware of the F38 runtime last week.. 14:08:23 but at the same time, it's hard to coordinate and maybe it's easier to if craft a simple script and try to build and update as much as possible and then we could maybe look at remaining failures all together at the next meeting and try to do some kind of team effort there? 14:08:40 tpopela[m]: excellent! that's definitely the hardest flatpak to update 14:09:11 yselkowitz added some more hyphenation packages to the F38 runtime and would be nice to see if anything else is missing for libreoffice 14:09:15 kalev: I like that idea! 14:09:29 .hello yselkowitz 14:09:30 yselkowitz[m]1: yselkowitz 'Yaakov Selkowitz' 14:09:40 ok, good! I'll do a round of updates before the next then 14:09:43 hi yselkowitz[m]1 ! 14:10:22 another thing we should do now is sunset the F36 runtime 14:10:48 we need to do it before F36 is EOL'd because at that point we can't build anything any more :) 14:10:55 and can't therefore mark anything EOL 14:11:31 we have one single remaining flatpak using the F36 runtime, which is tilix 14:12:25 it's one that I've tried to keep going, but it's buggy and I haven't gotten it to work right with the latest versions 14:12:35 so unless someone else wants to help look into it, I think I'd just retire tilix 14:12:41 (the flatpak, not the rpm) 14:13:14 +1 for retiring if its that broken 14:13:47 * kalev nods. 14:13:58 yselkowitz[m]1: any blockers for the KDE runtimes for F38? 14:14:27 kde 6 runtime and apps are in testing: https://bodhi.fedoraproject.org/updates/FEDORA-FLATPAK-2023-3fd54f1d00 14:14:47 ah, nice! 14:14:48 kde 5 runtime is built, haven't had time to update apps yet 14:15:01 my time is quite limited for the next two weeks 14:15:07 yeah, no rush if it's not shipped on Kinoite ISO 14:15:32 that's why we have different runtime versions so that we can keep on using them and don't have to update everything at the same time 14:15:42 good news is we no longer need the systemd hack with f38 14:15:54 excellent, I was about to ask about that 14:16:30 thanks for the runtime generation script cleanups, yselkowitz[m]1 14:16:43 nice to have more eyes on it 14:17:12 np it's already helped find some missing packages and issues with existing ones 14:17:55 ok, I think that's all for the F38 status, let's move on to defolos's topic 14:18:00 #topic defolos would like to propose to use kiwi for flatpak building 14:18:28 defolos: the floor is all yours :) we don't seem to have OwenTaylor[m] today, sadly, but hopefully he reads the scrollback afterwards 14:18:44 yes, afaik the current fedora module builder needs some refactoring anyway as mbs is dying 14:19:06 and that's why I wanted to propose to use kiwi as a base for this 14:19:22 I am talking about this thing: https://github.com/OSInside/kiwi 14:19:56 it's primarily an image builder used by openSUSE/SUSE, but thanks to Conan Kudo and Igor Raits it works in Koji as well 14:20:21 it can not only build OS images, but also containers and that could be used in turn for flatpak building 14:20:32 big caveat: it cannot build flatpaks yet… 14:20:48 ah, nice 14:20:54 but I would really like to implement support for this for $dayjob 14:21:17 well, it can build OCI style Flatpaks 14:21:20 that's actually not hard to do 14:21:20 however, my knowledge is rather limited and I was hoping we could work on this together, for the benefit of all of us 14:21:38 right now we use MBS to rebuild rpms for the /app prefix, and then OSBS to build a container where all the rpms are installed and which gets exported as a flatpak container 14:21:51 yeah, we can cut out OSBS easily enough 14:22:07 the osbs part could be done by kiwi 14:22:27 the rebuilding of rpms not really, that would have to be done somewhere else 14:22:27 as for MBS, cutting that out would be possible if we can set rpm macros on side tags 14:22:50 then we can create a simple tool to orchestrate chainbuilds as needed for these components 14:23:04 yeah, that was one of the ideas we've had, and I think it's the most promising one so far 14:23:16 Conan Kudo: are most macros not provided by some other rpm package? 14:23:35 if we'd just rebuild that package providing the macros in the side tag, all other rpms should get it 14:23:42 one issue with it is that some packages, notably evolution-data-server, are built differently depending on which flatpak they go into 14:23:47 the way MBS works is that it creates a build tag on the fly, then generates a module-build-macros package to set all the build overrides, then it builds stuff in sequence in that tag 14:24:40 maybe tracker miners are also built differently depending on which flatpak they go into? I am not sure, yselkowitz[m]1 would know best 14:24:55 so anyway, MBS right now does 3 different things: 14:25:03 the MBS design predates Koji supporting rpm macro configuration in koji tags 14:25:12 yes tracker-miners too 14:25:40 which was an enhancement originally added to support Mageia adopting Koji several years ago 😅 14:26:28 1) MBS allows to rebuild packages with pulling in flatpak-rpm-macros, and through this redefine the prefix to /app. That case could nicely get replaced by a custom side tag that has flatpak-rpm-macros in the build root 14:26:30 anyway, this is a problem that needs solving as well, but that kiwi cannot solve either 14:27:13 2) MBS allows building packages differently depending on which module they are in (evolution-data-server, tracker-miners) - that would be harder to do without MBS. We might need to do a bunch of new packages to support that. 14:27:47 not necessarily 14:27:53 we might want to ask Koji to extend to put a macro with the name of the build tag in it 14:28:08 which we can then read and add logic in the spec itself 14:28:15 3) MBS helps put together flatpak runtime, which is built for /usr, and build some custom packages differently for flatpak use. custom packages are problematic again 14:28:28 ah, interesting 14:29:01 the difficulty in my prototyping my ideas is that I can't get a working Koji deployment up to test this with 😅 14:29:17 but I'm pretty confident we can gut OSBS and MBS from the Flatpak build infra 14:29:43 what does that mean for flatpak maintainers? 14:29:47 anyway, I think we need to decouple kiwi from the MBS issues. I don't think kiwi would solve any of these, but it might be nice to just replace OSBS with kiwi anyway :) 14:30:30 we need to do koji work to replace MBS, and kiwi would replace OSBS 14:30:59 OSBS is also unmaintained, iirc 14:31:12 I know nirik is sad every time I mention OSBS because it needs a full openshift deployment or something in the fedora infra and that makes things more complicated than they need to be 14:31:14 And another thing that Owen mentioned is that modules are actually saving us some resources - through flatpak-common module (so one doesn't have to really build everything).. 14:31:28 if kiwi would make things simpler for the infra side I think that would already be a big win 14:32:38 Conan Kudo: do you know if kiwi can be launched in a koji side tag? 14:33:03 koji side tags are just tags, so as long as the plugin is deployed and the command is allowed, yes 14:33:12 that's more of a Fedora Koji policy thing 14:34:07 tpopela: I think a way for us to solve this is to have a fXX-flatpak-common-build tag of some kind where everything gets built unless we need specific overrides for specific flatpaks 14:34:34 * kalev nods. 14:34:45 (we can bikeshed the name later, but conceptually, reuse is definitely possible) 14:36:07 maybe that's something we could try to do for F39? we don't need to replace all MBS use in one go, but moving the flatpak-common module to a custom side tag should be nice and self contained, I think 14:36:17 yup 14:36:55 OSBS is not unmaintained - there's a fairly major rewrite finishing up now, and then plans for more changes in the future. 14:36:57 what we'd basically do is have an independent hierarchy for flatpak builds... the runtime+sdk would be tagged in from the regular fedora builds, and then the rest is built up in a tag that inherits that 14:37:19 any ideas how to keep latest versions of packages built for the new common tag? use the ELN scripts? 14:37:28 I'd rather we concentrate any Fedora-side effort on replacing the MBS part, not on redoing container building. 14:37:33 OwenTaylor[m]: oh hi! good you are here :) 14:37:49 Just got here.. 14:38:25 kalev: the ELN scripts may be useful here, we'd want variants for just tagging in (for runtime+sdk+extensions) and building (for apps/appextensions) 14:38:37 * kalev nods. 14:39:25 Conan Kudo: Having a f39-flatpaks or whatever that builds with /app is basically my thinking too. But there's some definite nuance to it. 14:40:09 at some point, I need to sketch out what this looks like and think through what the feature gaps are 14:41:04 maybe we could all think about it a bit until the next meeting in two weeks, and see if we can come up with a plan how to move forward? 14:42:01 and we don't need to find all solutions from the beginning. it's enough to just move some things off MBS :) we can for example keep the runtimes using it, and keep app flatpak building using MBS, and only move flatpak-common to koji side tags 14:42:18 or some other part, if we figure something else would be easy to do 14:43:00 The biggest questions to me are a) having infrastructure for shadowing the builds that's proper and robust, and not random scripts running somewhere and falling over b) figuring out the relationship to Bodhi and the update flow - how do you release flatpaks that contain the rebuilt version of the released RPMs, not whatever happens to be in dist-git but hasn't yet been tested/released. 14:44:09 a) we could use ELN scripts that I think are fairly well battle tested now 14:44:51 b) if we just replace flatpak-common that would be basically the same as now - building random latest commits from dist-git and not dealing with releasing the packages at all 14:46:26 #info kiwi could replace OSBS for building the flatpak containers 14:47:15 #info Bigger pain point right now is MBS. One idea that most people agree on are using custom koji side tags. Still need to figure out the details. 14:49:19 I can see if I can figure out how the ELN shadowing scripts work and if they look useful for us 14:49:34 anything else on this topic? 14:50:06 well, about the kiwi thing itself, would anyone have free cycles to help me with that? 14:51:01 and even if no one has any, how would you like to be kept in the loop so that this is still useful for this SIG? 14:53:32 I personally think that it would make sense to do it if infra wants to change over from OSBS to kiwi 14:56:12 ok, let's move on then 14:56:16 if other container builds are moving to kiwi, I'd like flatpak to follow suite but I certainly don't want to switch if it would be just flatpaks using it :) 14:56:37 kalev any update wrt openh264? 14:56:54 yselkowitz[m]1: nope, nothing 14:57:40 defolos: if you want to ask questions, I think OwenTaylor[m] is the best person who knows how all the OSBS integration works 14:59:08 sorry for the lack of enthusiasm, it's just that flatpak building is full of issues right now and I think nobody really wants to spend time replacing OSBS that mostly works fine for us 14:59:17 ok, looks like we the time is up here - see you all in two weeks! thanks everybody for coming 14:59:30 #endmeeting