2025-03-18 15:00:46 <@jbrooks:matrix.org> !startmeeting fedora_bootc_meeting
2025-03-18 15:00:50 <@meetbot:fedora.im> Meeting started at 2025-03-18 15:00:46 UTC
2025-03-18 15:00:50 <@meetbot:fedora.im> The Meeting name is 'fedora_bootc_meeting'
2025-03-18 15:00:56 <@jbrooks:matrix.org> !topic roll call
2025-03-18 15:01:46 <@walters:fedora.im> !hi
2025-03-18 15:01:49 <@zodbot:fedora.im> Colin Walters (walters)
2025-03-18 15:01:52 <@jeckersb:fedora.im> !hi
2025-03-18 15:01:55 <@zodbot:fedora.im> John Eckersberg (jeckersb)
2025-03-18 15:02:10 <@hricky:fedora.im> !hi
2025-03-18 15:02:12 <@zodbot:fedora.im> Hristo Marinov (hricky) - he / him / his
2025-03-18 15:02:47 <@jlebon:fedora.im> !hi
2025-03-18 15:02:48 <@zodbot:fedora.im> None (jlebon)
2025-03-18 15:03:34 <@jbrooks:matrix.org> How's it going, everyone?
2025-03-18 15:03:37 <@siosm:matrix.org> !hi
2025-03-18 15:03:40 <@zodbot:fedora.im> Timothée Ravier (siosm) - he / him / his
2025-03-18 15:03:50 <@miabbott:fedora.im> !hi
2025-03-18 15:03:52 <@zodbot:fedora.im> Micah Abbott (miabbott)
2025-03-18 15:04:46 <@jmarrero:matrix.org> !hi
2025-03-18 15:04:48 <@zodbot:fedora.im> Joseph Marrero (jmarrero)
2025-03-18 15:05:45 <@jbrooks:matrix.org> I apologize, due to UTC vs non UTC, I have overlapping meetings atm 🙂
2025-03-18 15:05:48 <@mmartinv:matrix.org> !hi
2025-03-18 15:05:49 <@zodbot:fedora.im> Miguel Martin (mmartinv)
2025-03-18 15:05:56 <@jbrooks:matrix.org> What topic do we have today? 
2025-03-18 15:06:30 <@jbrooks:matrix.org> Clement asked that we talk about https://gitlab.com/fedora/bootc/base-images/-/issues/25#note_2402386978
2025-03-18 15:07:04 <@jbrooks:matrix.org> It looks like conversation continued in there
2025-03-18 15:07:54 <@jbrooks:matrix.org> Colin Walters: Do you have items to discuss today?
2025-03-18 15:07:58 <@jlebon:fedora.im> Really great to see the progress there!
2025-03-18 15:08:53 <@walters:fedora.im> I think the async discussion is going ok, overall my feeling is still we'd probably be most effective in having smaller (but still public) video meetings on focused topics
2025-03-18 15:09:10 <@jlebon:fedora.im> one thing that came up while we were discussing this was https://gitlab.com/fedora/bootc/tracker/-/issues/34, which could be a good topic
2025-03-18 15:09:11 <@walters:fedora.im> So the short answer from my side is "no" I guess?
2025-03-18 15:09:57 <@jlebon:fedora.im> basically, people/variants are going to want to pin to images, and that requires tags, which snowballs into having a GC strategy
2025-03-18 15:10:06 <@jlebon:fedora.im> basically, people/variants are going to want to pin to images and bump via CI, and that requires tags, which snowballs into having a GC strategy
2025-03-18 15:10:26 <@rriemann:kde.org> Where is the video stream? Here for the first time ime with the element Android app. 
2025-03-18 15:10:31 <@dustymabe:matrix.org> !hi
2025-03-18 15:10:40 <@dustymabe:matrix.org> sorry I'm late
2025-03-18 15:11:01 <@jbrooks:matrix.org> Robert, at some point we switched to text by default, and video as needed
2025-03-18 15:11:34 <@jbrooks:matrix.org> But I'm happy to do as Colin mentioned, and have video meetings on specific topics -- we just need to program those 
2025-03-18 15:11:52 <@siosm:matrix.org> If Konflux pushes tagged releases and not just latest then that should help us a lot
2025-03-18 15:12:07 <@dustymabe:matrix.org> correct. I'd say we don't do video unless we have a specific topic we want to discuss in that video meeting 
2025-03-18 15:12:30 <@dustymabe:matrix.org> organizing those topics is the extra muscle we need though
2025-03-18 15:12:45 <@siosm:matrix.org> ok, https://quay.io/repository/centos-bootc/centos-bootc?tab=tags is unusable
2025-03-18 15:12:59 <@jlebon:fedora.im> mmartinv: is this something you'd be interested to do as a follow-up to the initial pipeline work?
2025-03-18 15:13:00 <@siosm:matrix.org> so we need to make sure that the tags pushed by Konflux are usable
2025-03-18 15:14:14 <@jlebon:fedora.im> travier: that's just SBOM/attestation stuff, i don't think it's expected to be used by users directly, but rather e.g. cosign AIUI
2025-03-18 15:14:17 <@mmartinv:matrix.org> I am trying to figure out what the release pipepeline is supposed to do
2025-03-18 15:14:32 <@jlebon:fedora.im> i.e. those aren't historical tags
2025-03-18 15:14:36 <@rsturla:fedora.im> A well-known tagging scheme would have been great
2025-03-18 15:14:36 <@rsturla:fedora.im> Just after the base image refactor, we needed to pin to an earlier build while we worked through some issues, which was more difficult than it should have been. You don't know which are Stream9 or Stream10, the arches force us to search through many pages etc.
2025-03-18 15:14:36 <@rsturla:fedora.im> Yeah, this would certainly help out a lot.  
2025-03-18 15:14:36 <@rsturla:fedora.im> 
2025-03-18 15:14:39 <@mmartinv:matrix.org> I am trying to figure out what the release pipeline is supposed to do
2025-03-18 15:14:47 <@siosm:matrix.org> Jonathan Lebon: I don't see any tagged version in the repo beyond the c9s/c10s tags
2025-03-18 15:14:52 <@rsturla:fedora.im> Just after the base image refactor, we needed to pin to an earlier build while we worked through some issues, which was more difficult than it should have been. You don't know which are Stream9 or Stream10, the arches force us to search through many pages etc.
2025-03-18 15:14:52 <@rsturla:fedora.im> Yeah, this would certainly help out a lot.  
2025-03-18 15:14:52 <@rsturla:fedora.im> 
2025-03-18 15:14:52 <@rsturla:fedora.im> A well-known tagging scheme would have been great so we don't _need_ to try and navigate the digests
2025-03-18 15:15:23 <@dustymabe:matrix.org> https://quay.io/repository/fedora/fedora-coreos?tab=tags&tag=latest could be a good example to follow 
2025-03-18 15:15:28 <@siosm:matrix.org> For reference, what this should look like: https://quay.io/repository/fedora/fedora-coreos?tab=tags
2025-03-18 15:15:37 <@mmartinv:matrix.org> We can add a tags based on timestamp I believe
2025-03-18 15:15:39 <@jlebon:fedora.im> yeah, they're missing there too. i thought you maybe thought that those were it but used a sha for a weird reason
2025-03-18 15:16:09 <@walters:fedora.im> It's worth noting here the fedora-coreos one looks pretty by default because it's not sigstore-signed
2025-03-18 15:16:54 <@siosm:matrix.org> the sigstore signatures are hidden by default in quay from memory
2025-03-18 15:16:58 <@jlebon:fedora.im> Right. I think currently that's how it's done until the referrers API stuff is more widespread? (At least that's how I understand it)
2025-03-18 15:17:49 <@siosm:matrix.org> https://quay.io/repository/fedora-ostree-desktops/silverblue?tab=tags (with some signed/some unsigned)
2025-03-18 15:17:58 <@walters:fedora.im> Hmm I think a sub-decision here (was this made already) is whether to have konflux push directly or indirect through that cloud-image-uploader thing
2025-03-18 15:18:06 <@walters:fedora.im> Hmm I think a sub-decision here (was this made already?) is whether to have konflux push directly or indirect through that cloud-image-uploader thing
2025-03-18 15:19:13 <@walters:fedora.im> I personally think it's weird and awkward to wedge containers and disk images into the same tool, though I understand how we got here
2025-03-18 15:19:13 <@siosm:matrix.org> It's probably going to happen in two steps: push to a "ci/testing/Staging" repo first, run the tests, then push to official repo
2025-03-18 15:19:36 <@dustymabe:matrix.org> Colin Walters: are you talking about bootc ? 
2025-03-18 15:20:04 <@dustymabe:matrix.org> Colin Walters: are you talking about bootc ?
2025-03-18 15:20:04 <@dustymabe:matrix.org> 
2025-03-18 15:20:04 <@dustymabe:matrix.org> that was sarcasm, ignore me 
2025-03-18 15:20:06 <@walters:fedora.im> ? bootc doesn't do anything with disk images except `install to-disk` which is just a simple stub reference
2025-03-18 15:20:16 <@mmartinv:matrix.org>               - latest-standard
2025-03-18 15:20:16 <@mmartinv:matrix.org> travier: the current release plan is
2025-03-18 15:20:16 <@mmartinv:matrix.org>  ```        value:
2025-03-18 15:20:16 <@mmartinv:matrix.org>           - name: fedora-bootc-rawhide-minimal
2025-03-18 15:20:16 <@mmartinv:matrix.org>             repository: quay.io/fedora-testing/fedora-bootc
2025-03-18 15:20:16 <@mmartinv:matrix.org>             tags:
2025-03-18 15:20:16 <@mmartinv:matrix.org>               - '{{ git_sha }}'
2025-03-18 15:20:16 <@mmartinv:matrix.org>               - '{{ git_short_sha }}'
2025-03-18 15:20:16 <@mmartinv:matrix.org>               - rawhide-minimal-{{ timestamp }}
2025-03-18 15:20:16 <@mmartinv:matrix.org>               - rawhide-minimal
2025-03-18 15:20:16 <@mmartinv:matrix.org>               - latest-minimal
2025-03-18 15:20:16 <@mmartinv:matrix.org>           - name: fedora-bootc-rawhide-tier-x
2025-03-18 15:20:16 <@mmartinv:matrix.org>             repository: quay.io/fedora-testing/fedora-bootc
2025-03-18 15:20:16 <@mmartinv:matrix.org>             tags:
2025-03-18 15:20:16 <@mmartinv:matrix.org>               - '{{ git_sha }}'
2025-03-18 15:20:16 <@mmartinv:matrix.org>               - '{{ git_short_sha }}'
2025-03-18 15:20:16 <@mmartinv:matrix.org>               - rawhide-tier-x-{{ timestamp }}
2025-03-18 15:20:16 <@mmartinv:matrix.org>               - rawhide-tier-x
2025-03-18 15:20:16 <@mmartinv:matrix.org>               - latest-tier-x
2025-03-18 15:20:16 <@mmartinv:matrix.org>           - name: fedora-bootc-rawhide-standard
2025-03-18 15:20:16 <@mmartinv:matrix.org>             repository: quay.io/fedora-testing/fedora-bootc
2025-03-18 15:20:16 <@mmartinv:matrix.org>             tags:
2025-03-18 15:20:16 <@mmartinv:matrix.org>               - '{{ git_sha }}'
2025-03-18 15:20:16 <@mmartinv:matrix.org>               - '{{ git_short_sha }}'
2025-03-18 15:20:16 <@mmartinv:matrix.org>               - rawhide-standard-{{ timestamp }}
2025-03-18 15:20:16 <@mmartinv:matrix.org>               - rawhide-standard
2025-03-18 15:20:16 <@mmartinv:matrix.org> ```
2025-03-18 15:20:27 <@siosm:matrix.org> Not sure how that would happen in Fedora infra however regarding pushing to official repos
2025-03-18 15:20:47 <@mmartinv:matrix.org> Just a proposal of course
2025-03-18 15:21:24 <@siosm:matrix.org> Each image should have it's own repo
2025-03-18 15:21:59 <@jlebon:fedora.im> travier: i guess this is for staging it first though. maybe it doesn't really matter at that point
2025-03-18 15:22:01 <@siosm:matrix.org> (so no suffix)
2025-03-18 15:22:22 <@siosm:matrix.org> sure, but then you need to map the tags, etc.
2025-03-18 15:22:52 <@siosm:matrix.org> ideally we use a tagging scheme that is similar to the one used for Fedora composes: https://openqa.fedoraproject.org/nightlies.html
2025-03-18 15:23:00 <@jlebon:fedora.im> mmartinv:  what's the timestamp format?
2025-03-18 15:23:15 <@walters:fedora.im> This discussion strongly relates to https://gitlab.com/fedora/bootc/base-images/-/merge_requests/150
2025-03-18 15:23:29 <@jlebon:fedora.im> travier: was thinking that. i think it'd be great if we actually matched the exact compose ID we built from
2025-03-18 15:23:43 <@walters:fedora.im> The argument here is OCI already *has* a standardized timestamp embedded so it's weird to replicate a possibly different timestamp in a version
2025-03-18 15:24:04 <@walters:fedora.im> rpm-md repositories *also* have a timestamp in the XML that's not widely used and the compose datestamps kind of duplicate, but also prefix with a major
2025-03-18 15:24:22 <@jlebon:fedora.im> i wanted to do this for RHCOS/SCOS things actually, but the glue code for it is awkward
2025-03-18 15:25:01 <@walters:fedora.im> We are doing this today in the centos-bootc/rhel-bootc pipelines note
2025-03-18 15:25:21 <@mmartinv:matrix.org> Jonathan Lebon: not sure, I wasn't able to release anything yet
2025-03-18 15:25:47 <@jlebon:fedora.im> sorry, my "this" in my sentence was "use pungi IDs". is that the same as your "this"?
2025-03-18 15:26:58 <@dustymabe:matrix.org> the datestamp we use in FCOS versioning is the datestamp from most recent repo update
2025-03-18 15:27:06 <@dustymabe:matrix.org> the datestamp we use in FCOS versioning is the date from most recent repo update
2025-03-18 15:27:15 <@dustymabe:matrix.org> the datestamp we use in FCOS versioning is the date from most recent repo update for the lockfiles we use as input
2025-03-18 15:27:17 <@walters:fedora.im> Jonathan Lebon: https://gitlab.com/redhat/centos-stream/containers/bootc/-/blame/c10s/Containerfile?ref_type=heads#L24
2025-03-18 15:28:12 <@walters:fedora.im> Though on this whole topic, one thing I hope to do and would transform this whole discussion is https://github.com/rhinstaller/anaconda/discussions/5888 - because it would mean we must build a container as part of a compose, instead of having two different things awkwardly glued together
2025-03-18 15:28:25 <@dustymabe:matrix.org> i.e. https://github.com/coreos/fedora-coreos-config/blob/2b082ce759025195f4e8a090f412479b8cbad6d0/manifest-lock.x86_64.json#L2648 
2025-03-18 15:29:57 <@walters:fedora.im> Does that still make sense in a world where FCOS derives from fedora-bootc?
2025-03-18 15:30:04 <@jlebon:fedora.im> OK nice. I like that actually.
2025-03-18 15:30:04 <@jlebon:fedora.im> (I _don't_ like though the major bot spam that comes with it. Ideally it'd push to a side branch so tests run there, and then directly pushes to the main branch quietly if it passes)
2025-03-18 15:30:42 <@dustymabe:matrix.org> probably.. depends on how we lock the additional content we add on top 
2025-03-18 15:31:36 <@jlebon:fedora.im> i think we should reflect the fedora-bootc version, but yeah, we'd want an extra field for our bits on top
2025-03-18 15:32:44 <@jlebon:fedora.im> did we decide whether we'd use renovate on fedora-bootc too or not yet?
2025-03-18 15:33:15 <@jlebon:fedora.im> because that also ties into this
2025-03-18 15:33:29 <@siosm:matrix.org> Ideally we would not, otherwise that means that we re-add lockfiles?
2025-03-18 15:33:48 <@walters:fedora.im> I feel pretty strongly I want to align fedora-bootc and centos-bootc and not treat them as decoupled
2025-03-18 15:34:21 <@walters:fedora.im> So that would imply using renovate in fedora-bootc yes, unless we come up with something else that can also be deployed in centos-bootc
2025-03-18 15:35:23 <@walters:fedora.im> Yes...though I feel pretty strongly the real solution to this is to do base image builds and "composes" together and not separately
2025-03-18 15:36:16 <@siosm:matrix.org> Do you mean doing bootc image builds during Fedora composes?
2025-03-18 15:36:19 <@jlebon:fedora.im> My hot take on this is that ideally we _don't_ have lockfiles because we have solid gating at the Bodhi level, but until we have that, we kinda need lockfiles.
2025-03-18 15:36:27 <@jlebon:fedora.im> have to drop for another meeting. ttyl!
2025-03-18 15:38:32 <@dustymabe:matrix.org> one of the things CoreOS does today which I feel pretty strongly is a value add is that we don't ship *ANYTHING* unless tests pass. If you bake the bootc image build into the base composes you will lose that.
2025-03-18 15:38:32 <@dustymabe:matrix.org> It's a subtle detail, but I think it's important.
2025-03-18 15:38:32 <@dustymabe:matrix.org> 
2025-03-18 15:39:10 <@rriemann:kde.org> I am new to bootc and still quite new to fedora. For my idea https://eu-os.gitlab.io I use currently blue-build.org which doesn't yet offer bootc. My goal is to build a distro leveraging container pipelines as much as possible. It should have FDE integrating with the TPM and optionally U2F/FIDO.
2025-03-18 15:39:10 <@rriemann:kde.org> If you have any cool bits to share for this work, please let me know.
2025-03-18 15:39:10 <@rriemann:kde.org> 
2025-03-18 15:39:11 <@walters:fedora.im> Not just that but actually making Anaconda (the ISO) *derive* from fedora-bootc so we need to build a chain of containers
2025-03-18 15:40:15 <@siosm:matrix.org> Agree. If bootc-image-builder supported that, we would be using it already :)
2025-03-18 15:40:44 <@siosm:matrix.org> https://github.com/travier/fedora-kinoite/blob/main/fedora-kinoite-live/Containerfile
2025-03-18 15:40:56 <@siosm:matrix.org> (It's how I did the LiveISO using kiwi)
2025-03-18 15:41:17 <@walters:fedora.im> Hi Robert, thanks for sharing! We today have a list of downstream distro/OS only in bootc upstream but we should probably land one somewhere in the https://gitlab.com/fedora/bootc/docs perhaps? If you run into any bugs or issues don't hesitate to reach out!
2025-03-18 15:43:10 <@walters:fedora.im> OK so...a whole lot was discussed here on the releng side. I think we have trackers for *most* of it. I will file one around fedora-bootc and versioning.
2025-03-18 15:43:51 <@walters:fedora.im> mmartinv: Thanks for the work you're doing and I am ready to help too with anything needed on this
2025-03-18 15:44:38 <@walters:fedora.im> Did we have anything else?
2025-03-18 15:45:26 <@jbrooks:matrix.org> Sounds like we can close this one off
2025-03-18 15:45:38 <@jbrooks:matrix.org> Sorry for my divided attn!
2025-03-18 15:46:52 <@rriemann:kde.org> I read that universal blue is more aligned on containers already than the fedora atomic desktops. Is fedora to swith anytime soon?
2025-03-18 15:47:35 <@siosm:matrix.org> Robert: The roadmap is at https://gitlab.com/fedora/ostree/sig/-/issues/26
2025-03-18 15:48:24 <@jbrooks:matrix.org> And all our progress will automatically benefit universal blue 🙂
2025-03-18 15:48:36 <@jbrooks:matrix.org> OK, I'll close it off, thanks everyone!
2025-03-18 15:48:40 <@jbrooks:matrix.org> #endmeeting
2025-03-18 15:49:29 <@dustymabe:matrix.org> !endmeeting