<@jbrooks:matrix.org>
15:01:02
!startmeeting fedora_bootc_initiative
<@meetbot:fedora.im>
15:01:05
Meeting started at 2025-06-03 15:01:02 UTC
<@meetbot:fedora.im>
15:01:05
The Meeting name is 'fedora_bootc_initiative'
<@walters:fedora.im>
15:01:08
.hi
<@jbrooks:matrix.org>
15:01:09
!topic roll call
<@jbrooks:matrix.org>
15:01:22
!hi jasonbrooks
<@zodbot:fedora.im>
15:01:23
Jason Brooks (jasonbrooks) - he / him / his
<@jeckersb:fedora.im>
15:01:29
!hi
<@zodbot:fedora.im>
15:01:30
John Eckersberg (jeckersb)
<@jlebon:fedora.im>
15:01:33
!hi
<@zodbot:fedora.im>
15:01:37
None (jlebon)
<@nimbinatus:matrix.org>
15:01:44
!hi
<@zodbot:fedora.im>
15:01:47
No Fedora Accounts users have the @nimbinatus:matrix.org Matrix Account defined
<@jbrooks:matrix.org>
15:02:38
nimbinatuszodbot tries to associate your matrix handle w/ your fas id
<@nimbinatus:matrix.org>
15:03:33
I'm reading about it now; no worries
<@jbrooks:matrix.org>
15:03:48
How's everyone doing? Who has topics to discuss? :)
<@walters:fedora.im>
15:05:01
One thing that might be good is to write up features targeted for the fedora 43 timeframe
<@rsturla:fedora.im>
15:05:17
!hi
<@zodbot:fedora.im>
15:05:18
None (rsturla)
<@jbrooks:matrix.org>
15:05:21
!topic features for fedora 43
<@jbrooks:matrix.org>
15:06:06
Colin WaltersDo we have a start on this list?
<@walters:fedora.im>
15:06:19
One thing we're actively working on is https://github.com/bootc-dev/bootc/issues/1350
<@snthrailkill:matrix.org>
15:07:15
!hi
<@zodbot:fedora.im>
15:07:20
Sean Thrailkill (snthrailkill)
<@walters:fedora.im>
15:07:20
Also it's really likely that we end up with some improvements to the rechunker
<@jlebon:fedora.im>
15:08:32
could add https://github.com/coreos/fedora-coreos-tracker/issues/1861 as well (which i've just retitled)
<@rsturla:fedora.im>
15:09:54
Curious - do you have a rough estimate for the Composefs backend implementation? I appreciate it likely won't be considered "stable" for quite some time, but I'm just curious :)
<@walters:fedora.im>
15:09:56
Yeah, it's not a directly user-visible thing but should produce nice synergy
<@rsturla:fedora.im>
15:10:03
Curious - do you have a rough estimate for the Composefs backend implementation? I appreciate it likely won't be considered "stable" for quite some time, but I'm just interested :)
<@walters:fedora.im>
15:11:40
Robert Sturla: We'll keep https://github.com/bootc-dev/bootc/issues/1190 updated but the main person working on it is/was out, hope to continue momentum though
<@jbrooks:matrix.org>
15:13:35
Do we have prospects for the atomic desktops to be fedora-bootc based in f43?
<@walters:fedora.im>
15:13:39
The other main thing top of mind for me is https://gitlab.com/fedora/bootc/tracker/-/issues/2 which I think we may have a new person joining to work on, I'll try to ensure that's the case and have them update there
<@walters:fedora.im>
15:14:22
Jason Brooks: I think the canonical tracker is https://gitlab.com/fedora/ostree/sig/-/issues/26
<@walters:fedora.im>
15:14:53
Though it gets nuanced, there's deriving on the build side (like FCOS is) and that's mixed in with some client work
<@rsturla:fedora.im>
15:15:21
Is there anything stopping Atomic Desktops for example, from switching over to being fedora-bootc based, while still relying on rpm-ostree for the cases where local layering is required?
<@snthrailkill:matrix.org>
15:15:54
So its more likely we get FCOS building first and then Fedora Atomic?
<@jlebon:fedora.im>
15:16:27
right, the server side and client side are decoupled. the FCOS work currently to "rebase" to fedora-bootc is pretty invisible to end users. the final artifact is almost identical.
<@rsturla:fedora.im>
15:16:28
Is there anything stopping Atomic Desktops, from switching over to being fedora-bootc based, while still relying on rpm-ostree for the cases where local layering is required?
<@rsturla:fedora.im>
15:16:46
Is there anything stopping Atomic Desktops from switching over to being fedora-bootc based, while still relying on rpm-ostree for the cases where local layering is required?
<@jlebon:fedora.im>
15:17:28
(I put "rebase" in quotes, because FCOS currently already inherits from fedora-bootc, but this moves it from inheriting via git submodules to inheriting implicitly via bootc-base-imagectl.)
<@jlebon:fedora.im>
15:18:00
on the client-side, i think https://github.com/coreos/rpm-ostree/issues/4994 would help a lot
<@jlebon:fedora.im>
15:18:17
but i don't think there's any work being done on that currently
<@jlebon:fedora.im>
15:18:43
but basically yes, you can have the 'server side experience' of bootable containers while still using rpm-ostree client side
<@walters:fedora.im>
15:19:19
Yeah we'll continue to support rpm-ostree client layering for quite a while, though there is ongoing discussions with dnf
<@jbrooks:matrix.org>
15:20:36
OK, so we should probably create a tracking issue for features we expect for f43 -- this will help w/ marketing when the release comes near
<@walters:fedora.im>
15:20:37
That's https://gitlab.com/fedora/bootc/tracker/-/issues/4
<@jbrooks:matrix.org>
15:23:52
I'll follow up on this f43 tracking issue. Do we have other items to discuss?
<@rsturla:fedora.im>
15:23:57
The issue says it would require the rpm-ostree rechunk mechanism to support regular OCI layers, rather than however the ostree chunking currently works.
<@rsturla:fedora.im>
15:23:57
Another potentially large but invisible change proposed for F43 was the removal of /ostree - https://gitlab.com/fedora/bootc/base-images/-/issues/58
<@rsturla:fedora.im>
15:24:06
Another potentially large but invisible change proposed for F43 was the removal of /ostree from the base images - https://gitlab.com/fedora/bootc/base-images/-/issues/58
<@rsturla:fedora.im>
15:24:06
The issue says it would require the rpm-ostree rechunk mechanism to support regular OCI layers, rather than however the ostree chunking currently works.
<@walters:fedora.im>
15:26:27
Yeah, I can't say we'll do that for 43 though
<@walters:fedora.im>
15:26:40
Given current other priority targets
<@jbrooks:matrix.org>
15:29:18
Shall we wrap this one up?
<@jbrooks:matrix.org>
15:30:17
!endmeeting