16:28:50 <dustymabe> #startmeeting fedora_coreos_meeting
16:28:50 <zodbot> Meeting started Wed May 17 16:28:50 2023 UTC.
16:28:50 <zodbot> This meeting is logged and archived in a public location.
16:28:50 <zodbot> The chair is dustymabe. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:28:50 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:28:50 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:28:54 <dustymabe> #topic roll call
16:29:24 <quentin9696[m]> .hi all
16:29:28 <zodbot> quentin9696[m]: Something blew up, please try again
16:29:31 <zodbot> quentin9696[m]: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:29:34 <dustymabe> #chair quentin9696[m]
16:29:34 <zodbot> Current chairs: dustymabe quentin9696[m]
16:29:37 <dustymabe> .hi
16:29:41 <zodbot> dustymabe: Something blew up, please try again
16:29:44 <zodbot> dustymabe: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:29:53 <quentin9696[m]> .hi a;;
16:29:55 <dustymabe> oh fun - zodbot must be on vacation
16:29:57 <zodbot> quentin9696[m]: Something blew up, please try again
16:29:58 <quentin9696[m]> * .hi all
16:30:00 <zodbot> quentin9696[m]: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:30:03 <ravanelli> .hi
16:30:08 <zodbot> ravanelli: Something blew up, please try again
16:30:11 <zodbot> ravanelli: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:30:27 * dustymabe feels like that bot's administrator is going to have a lot of messages to look at
16:31:22 <dustymabe> #chair ravanelli
16:31:22 <zodbot> Current chairs: dustymabe quentin9696[m] ravanelli
16:31:37 <fifofonix> .present
16:32:07 <gursewak> .hi
16:32:09 <dustymabe> #chair fifofonix
16:32:09 <zodbot> Current chairs: dustymabe fifofonix quentin9696[m] ravanelli
16:32:10 <zodbot> gursewak: Something blew up, please try again
16:32:12 <dustymabe> #chair gursewak
16:32:12 <zodbot> Current chairs: dustymabe fifofonix gursewak quentin9696[m] ravanelli
16:32:13 <zodbot> gursewak: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:32:32 <jlebon> .hello2
16:32:33 <zodbot> jlebon: Something blew up, please try again
16:32:36 <zodbot> jlebon: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:32:39 <dustymabe> #chair jlebon
16:32:39 <zodbot> Current chairs: dustymabe fifofonix gursewak jlebon quentin9696[m] ravanelli
16:33:02 <marmijo[m]> .hello marmijo
16:33:03 <zodbot> marmijo[m]: Something blew up, please try again
16:33:06 <zodbot> marmijo[m]: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:33:07 <travier> .hello siosm
16:33:09 <zodbot> travier: Something blew up, please try again
16:33:12 <dustymabe> #chair marmijo[m] travier
16:33:12 <zodbot> Current chairs: dustymabe fifofonix gursewak jlebon marmijo[m] quentin9696[m] ravanelli travier
16:33:12 <zodbot> travier: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:33:30 <dustymabe> hope everyone is having a good week so far!
16:33:55 <dustymabe> i'll move into meeting topics soon
16:34:19 <dustymabe> #topic Action items from last meeting
16:34:24 <dustymabe> #info there were no action items from last meeting!
16:34:28 <dustymabe> 🎉
16:34:42 <dustymabe> #topic New Package Request: google-compute-engine-guest-configs-udev
16:34:47 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1494
16:35:05 <dustymabe> ravanelli: want to introduce this one?
16:36:11 <ravanelli> sure
16:38:21 <ravanelli> We need to add the GCP udev rules in FCOS and RHCOS, Google has this package where the rules are available since we don't need everything that is part of the package, we requested the creation of a subpackage only with the rules/scripts we need.
16:38:35 <ravanelli> In this way we don't need to add it in our overlay as it is now
16:38:53 <ravanelli> what make things hard to maintain
16:40:09 <bgilbert> .hi
16:40:09 <dustymabe> Another piece of context here is that we were/are already shipping these udev rules, but as part of our "overlay". Including this package and removing the files from our overlay will help us to not "maintain" them ourselves and passively pick them up from the Fedora RPM maintainer.
16:40:10 <zodbot> bgilbert: Something blew up, please try again
16:40:12 <dustymabe> #chair bgilbert
16:40:12 <zodbot> Current chairs: bgilbert dustymabe fifofonix gursewak jlebon marmijo[m] quentin9696[m] ravanelli travier
16:40:13 <zodbot> bgilbert: An error has occurred and has been logged. Please contact this bot's administrator for more information.
16:40:34 <travier> The package does not include the dracut module config :/
16:40:38 <travier> jsut realized that
16:40:45 <jlebon> travier: was going to mention this too :)
16:40:46 <travier> we'll have to make another PR for that
16:40:58 <dustymabe> travier: +1
16:40:59 <travier> we can carry it in the overlay
16:41:09 <travier> and the script is in lib, not libexec
16:41:15 <dustymabe> travier: but definitely prefer not to :)
16:41:17 <travier> we can sort that after
16:41:20 <ravanelli> PR for the upstream google repo?
16:41:24 <ravanelli> you mean
16:41:43 <travier> if upstream takes it great, otherwise it can land in the fedora one
16:41:56 <jlebon> yeah, they might not want a dracut module upstream
16:41:59 <travier> if upstream takes it, then that's great*
16:42:15 <dustymabe> right.. try to get it upstream in the google GH repo. If not then we can just carry it in the Fedora package (if the maintainer agrees)
16:42:25 <dustymabe> I happen to know the guy :)
16:42:26 <ravanelli> dustymabe: +1
16:43:08 <travier> but this is not blocking us from adding the package :)
16:43:11 <ravanelli> I can open a PR for the dracut case in upstream to see
16:43:11 <travier> +1 from me
16:43:37 <dustymabe> #proposed we will include the google-compute-engine-guest-configs-udev package because it includes udev rules and a script that we were/are already shipping in FCOS. Using the package instead allows for better shared ownership.
16:44:04 <jlebon> ack
16:44:10 <mnguyen> +1
16:44:36 <travier> I think we will include it because it enables something meaningfull for us in GCP but that works too :)
16:44:50 <travier> (+1)
16:45:34 <dustymabe> #agreed we will include the google-compute-engine-guest-configs-udev package because it includes udev rules and a script that we were/are already shipping in FCOS. Using the package instead allows for better shared ownership.
16:45:49 <bgilbert> +1
16:45:53 <dustymabe> anything else before moving on?
16:46:25 <travier> should be good
16:46:31 <jlebon> one thing
16:47:46 <jlebon> i'm working on another patch to upstream (unrelated to the main reason why we're discussing this)  which we might want. depending on if they take it quickly and the pkg can get bumped in fedora before adding to FCOS, that'd make it easier
16:48:11 <jlebon> but obviously, we can bump it post-adding it too
16:48:14 <dustymabe> so.. try to open the PRs at about the same time?
16:48:31 <jlebon> i guess if we want to hold adding it for the dracut module work too, that WFM
16:49:54 <jlebon> maybe we can chat in #fedora-coreos afterwards
16:50:04 <dustymabe> +1
16:50:11 <dustymabe> #topic increase size of our /boot partition for new installs
16:50:11 <ravanelli> +1
16:50:16 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1465
16:50:50 <dustymabe> I'm bringing this up again because I'm interested in the side-proposal that I mention in https://github.com/coreos/fedora-coreos-tracker/issues/1465#issuecomment-1543245937
16:51:11 <dustymabe> which is (I think) to essentially just have the ESP serve the purpose of /boot too
16:52:05 <dustymabe> am I understanding the side-proposal correctly?
16:52:31 <bgilbert> I think so
16:52:33 <dustymabe> and... are there clear reasons why that is a bad or good idea?
16:52:44 <bgilbert> does rpm-ostree have issues with VFAT /boot?
16:52:49 <jlebon> yes
16:52:52 <jlebon> it doesn't support symlinks
16:53:08 <jlebon> which is part of how we do transactional upgrades
16:53:09 <dustymabe> blast :)
16:53:32 <bgilbert> I suppose there's no way around that?
16:53:43 <dustymabe> ok ignore me then, was just thinking maybe that could be an interesting solution to the problem
16:54:05 <jlebon> i mean, if really all the big files are hosted in the ESP, then indeed we could make /boot tiny
16:54:18 <jlebon> that would require ostree changes though
16:55:07 <jlebon> bgilbert: not easily
16:55:18 <dustymabe> it would be a shame to have a separate /boot just for a few symlinks
16:55:52 <walters> this is https://github.com/ostreedev/ostree/issues/1951
16:56:29 <dustymabe> walters++
16:57:19 <dustymabe> walters: thanks for keeping your train of thought and new findings in the ticket
16:57:24 <dustymabe> it definitely helps
16:57:55 <dustymabe> I guess we can link to the ostree ticket from that comment in the fcos tracker ticket..
16:58:07 <dustymabe> should we voice support for such an idea for the rest of Fedora, though
16:58:26 <dustymabe> i.e. right now it's in the "this could be a cool idea, but does anyone else think so" phase on the mailing list
16:58:37 <dustymabe> if we voiced support then people may actually think about pursuing it
16:59:07 <walters> well, one thing here is makes the layout more different for platforms that don't have an ESP
16:59:20 <dustymabe> walters: true
16:59:38 <walters> that's not a problem necessarily but should be considered
16:59:44 <dustymabe> though.. maybe we could just make the ESP on those platforms too (just like we do for /boot today)?
17:00:19 <travier> as I readZbigniew's proposal, this is EUFI only?
17:00:38 <bgilbert> in practice, the problem on non-UEFI systems reduces to: what does petitboot want?
17:00:54 <travier> Should we start considering the BIOS and EFI cases differently?
17:01:03 <dustymabe> bgilbert: i.e. can petitboot read VFAT?
17:01:35 <bgilbert> yeah
17:01:39 <dustymabe> travier: correct I guess? but why shouldn't BIOS boot be able to read a VFAT FS to find the kernel/initrd?
17:02:02 <dustymabe> bgilbert: good question.. I'd hope since it's an even more simple FS than any of the others?
17:02:23 <bgilbert> ¯\_(ツ)_/¯
17:02:43 <dustymabe> indeed :)
17:02:59 <dustymabe> ok I'll try to capture some of this in the ticket
17:03:17 <dustymabe> should we add an entry to the mailing list thread (or start a new mailing list thread) about this topic?
17:03:36 <travier> In the end, if we truly want to share / get more space, we need the ESP & /boot partition to be the same
17:04:05 <dustymabe> travier: right, I just don't think we ever thought about combining them before (at least I didn't)
17:04:19 <travier> firmware updates, UKIs, GPU firmwares all need to be there and will only get bigger
17:04:37 <dustymabe> +1
17:04:45 <travier> yes, I alos only started thinking about it last week: https://github.com/coreos/fedora-coreos-tracker/issues/1465#issuecomment-1542559616
17:05:04 <dustymabe> ha travier
17:05:17 <dustymabe> I didn't read your comment (I think it because during the meeting and I missed it)
17:05:36 <dustymabe> ok cool I'll update the ticket and maybe start a mailing list thread
17:05:38 <bgilbert> travier: I don't see why BIOS would need a different layout
17:05:39 <travier> one "complex" option would be to keep making dual BIOS/EFI images but merge/rework the layout on first boot
17:06:11 <travier> BIOS does not, but EFI systems benefit from a larger ESP
17:06:23 <bgilbert> I'm saying, I think we'd just change the layout for both
17:06:28 <bgilbert> unified ESP + /boot
17:06:41 <dustymabe> 👆
17:07:22 * dustymabe moves on to next ticket soon
17:07:37 <travier> could work indeed and needs ostree work to support vfat partitions as mentioned above
17:08:17 <bgilbert> sorry, misplaced my brain
17:08:32 <bgilbert> what I'm trying to say is: whatever layout we use should presumably be the same on both BIOS + UEFI
17:08:59 <bgilbert> anyway, +1 to move on
17:09:05 <travier> +1
17:09:08 <dustymabe> 💯
17:09:09 <jlebon> bgilbert: that's what i understood you to say :)
17:09:18 <dustymabe> #topic tracker: Fedora 39 changes considerations
17:09:19 <bgilbert> :-)
17:09:24 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1491
17:09:33 <dustymabe> It's that time of half-year again
17:10:10 <dustymabe> A couple of us got together this morning to pre-screen some of these. We'll now go over the ones that we deemed needed action or further discussion.
17:10:26 <dustymabe> subtopic 106. Ostree Native Container (Phase 2, stable)
17:10:46 <dustymabe> Note from jlebon: This is being tracked at https://github.com/coreos/fedora-coreos-tracker/issues/1363
17:11:25 <dustymabe> IOW there is some action on our part for this one, but I think #1363 enumerates the issues
17:12:26 <dustymabe> next up is...
17:12:34 <dustymabe> subtopic 109. Make DNF5 The Default
17:12:48 <dustymabe> #link https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5
17:13:04 <dustymabe> Note from jlebon: This does not directly affect FCOS (we don't ship dnf), but is of interest as part of the discussions around layering and bootc. We also need to investigate switching rpm-ostree to use the latest libdnf.
17:13:36 <dustymabe> IIUC rpm-ostree uses a submodule to import libdnf.
17:13:49 <dustymabe> should we try to experiment switching that submodule to dnf5 version?
17:14:23 <jlebon> i'm not sure how much work that would be. if it's not a lot, sure. otherwise, i think it's worth fleshing out the other discussions first
17:14:36 <dustymabe> jlebon: good point.
17:14:49 <travier> I think it would be best to start that effort to get an understanding of how big the API differs
17:15:08 <dustymabe> maybe a new issue to track that investigation?
17:15:40 <dustymabe> I'd imagine there would be some sort of migration guide for breaking changes, but you never know
17:15:42 <walters> there's an intersection with the previous change in that hopefully, we start just being able to type dnf when doing derived FCOS builds
17:16:06 <jlebon> dustymabe: WFM. i'd consider that an rpm-ostree issue
17:16:17 <dustymabe> walters: noted
17:16:23 <dustymabe> jlebon: +1
17:16:33 <dustymabe> anyone want to volunteer to open that issue?
17:16:34 <jlebon> walters: indeed, and depending on how that's implemented, maybe we don't need to do this at all
17:16:48 <walters> but if we did that, then we would ship dnf on the client side too, unless it was explicitly removed at build time
17:16:54 <jlebon> dustymabe: i can do so
17:17:21 <dustymabe> #action jlebon to open issue for investigation dnf5 libdnf for rpm-ostree
17:17:23 <dustymabe> thanks jlebon!
17:17:29 <dustymabe> walters: +1
17:17:44 <dustymabe> subtopic 112. MinGW toolchain update
17:17:54 <dustymabe> #link https://fedoraproject.org/wiki/Changes/F39MingwEnvToolchainUpdate
17:18:09 <dustymabe> Note from travier: We build Windows binaries for Butane. Should be fine but a simple check would be nice.
17:18:23 <bgilbert> not with mingw though
17:18:34 <travier> ah! good point!
17:18:45 <travier> it's golang :)
17:18:45 <walters> there is one already in https://github.com/coreos/rpm-ostree/issues/2139
17:18:55 <dustymabe> #info we don't use mingw to build butane windows binaries
17:19:12 <dustymabe> walters: nice! thanks for the link
17:19:44 <dustymabe> subtopic 113. SPDX License Phase 2
17:19:51 <dustymabe> #link https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_2
17:20:02 <dustymabe> Note from travier: We need to ensure our packages are compliant
17:20:30 <travier> I vaguely remember seeing PRs to make sure they are but a quick check would be nice
17:20:31 * dustymabe wonders what happens if we don't. Does some bot ping us to tell us they aren't compliant?
17:20:39 <jlebon> walters: nice! totally forgot about that one
17:21:35 <dustymabe> should we open a ticket that lists our RPMs we control to track the investigation?
17:22:21 <travier> let's do that
17:22:31 <dustymabe> anyone want the action?
17:23:09 <dustymabe> #action dustymabe to open a ticket to make sure RPMs we control have SPDX Licenses
17:23:23 <dustymabe> subtopic 114. Changes of defaults in createrepo_c-1.0.0
17:23:30 <dustymabe> #link https://fedoraproject.org/wiki/Changes/createrepo_c_1.0.0
17:23:39 <dustymabe> Note from travier: Should not impact FCOS. Maybe check with rpm-ostree?
17:24:11 <travier> I think we'll notice this one quickly if it breaks
17:24:42 <dustymabe> true
17:24:55 <dustymabe> ok so maybe we just mark it as good with that note
17:25:12 <jlebon> yeah, we use it in our rpm-ostree tests. shouldn't be too hard to adapt if something needs tweaking
17:25:19 <dustymabe> +1
17:25:35 <dustymabe> subtopic 115. RPM 4.19
17:25:43 <dustymabe> #link https://fedoraproject.org/wiki/Changes/RPM-4.19
17:26:07 <dustymabe> of note here is: "Creating User and Groups from sysusers.d files including Provides and Requires or Recommends"
17:26:47 <dustymabe> is that something we've been waiting for?
17:27:50 <dustymabe> either way I think this is one where we'd notice breakage pretty soon too and adapt, so maybe no need for separate investigation ticket?
17:27:53 <travier> I don't think so
17:28:01 <travier> +1
17:28:06 <jlebon> i don't think so. i think actually we may want to disable that functionality
17:28:15 <dustymabe> oh yeah?
17:28:33 <jlebon> IIUC, it would create users/groups at compose time, instead of client-side
17:28:57 <dustymabe> "including Provides and Requires or Recommends" to me implies that rpms could require other rpms solely based on the fact that they "provide" a group
17:29:17 <jlebon> but it helps the cause in that more pkgs may now want to migrate to sysusers
17:29:17 <travier> isn't this what we do already?
17:29:20 <dustymabe> in which case I don't think we'd want to (or may not even be able to) disable it
17:29:24 <travier> we create users and groups at compose time
17:29:53 <jlebon> travier: right, but part of the idea of https://github.com/coreos/rpm-ostree/issues/49 is to stop doing that
17:30:17 <jlebon> we have a bunch of hacks in rpm-ostree to intercept calls and translate into sysuser dropins
17:30:49 <travier> hum, that's not how I was thinking about moving away from nss-altfiles
17:31:31 <jlebon> travier: it's possible things have changed. it's been a while since i've dug into this. :)
17:31:40 <travier> we'll re-sync on this one
17:31:44 <travier> :)
17:32:01 <dustymabe> ok i'll add a note and come back to it next time?
17:32:08 <dustymabe> #topic open floor
17:32:11 <travier> +1
17:32:13 <jlebon> WFM
17:32:17 <dustymabe> we'll get to the self contained changes next time
17:32:20 <dustymabe> for now let's go to open floor
17:32:25 <dustymabe> anyone with anything for open floor today?
17:32:37 <travier> I had this one https://github.com/coreos/fedora-coreos-docs/pull/538 but we can do it next time too, not urgent
17:33:03 <dustymabe> #info we're now shipping a a kubevirt image that can be run as a VM inside kubernetes/openshift: https://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-kubevirt/
17:33:20 <jlebon> travier: ahh right, forgot about that one. maybe we should create a tiny tracker issue just for the purpose of tagging with the meeting label
17:33:30 <dustymabe> travier: +1 - remind me at the beginning of next meeting and I'll bring it up first
17:33:37 <dustymabe> or what jlebon said :)
17:33:47 <travier> sure, next meeting is fine :)
17:34:17 <jlebon> dustymabe: awesome!
17:34:40 <dustymabe> jlebon: yep. Thanks gursewak for that work on getting Kubevirt enabled.
17:35:41 * dustymabe closes out the meeting soon
17:36:33 <dustymabe> #endmeeting