Mmm ideally I would get rid of ostree dependency completely on CI
Mmm ideally I would get rid of ostree dependency completely on CI
AThen you eat that on deployment
AEither you make the commit or the client does and it explodes
RHonestly, I'd wait and see how things pan out with composefs.
This will remove ostree dependency throughout the entire stack
This will remove ostree dependency throughout the entire stack
ZWell yeah, still need to figure out how to do rechunking
AOstree is still the backend and there is no proposed replacement
AThey're just trying to obfuscate it
RThe composefs-rs project is a Rust implementation of composefs that is capable of generating composefs images from container images.https://github.com/bootc-dev/bootc/issues/1190
We should integrate it in bootc as an alternative to the ostree backend.
ADamn Colin has been busy
ZAh, right, because it already handles the deduplication
ZNvm then
ANothing here is currently expected to be useful to anybody at all, and probably never will be. If these experiments go well, this code will probably end up merged in other places.
ZWait nvm still need it, otherwise we end up downloading all the layers
ALook all rechunk is is a grouping algorithm for files that wraps ostree RS ext
AIt's not backend dependent but there is no other backend
AIt's also not particularly insightful, it just works
FGitHub
I have created a release beep boop
0.10.2 (2025-04-18)
Bug Fixes
remove GBulb, require PyGObject 3.50.0+ (#328) (650a8c2)
This PR was generated with Release Please. See documentation.
I have created a release beep boop0.10.2 (2025-04-18)
Bug Fixes
remove GBulb, require PyGObject 3.50.0+ (#328) (650a8c2)
This PR was generated with Release Please. See documentation.
ZWait, all files in the rootfs of a container image are just hardlinks to
/ostree rightAYes
ZOk I think I have an idea on how to handle it then
AThere's special logic in bootc for handling ostree commits
AYou don't want bootc doing the conversion on its own
ZMeh, I'm thinking of flattening the entire image beforehand anyways
AIt's untested and not our problem
FThis also needs to be triggered to build
https://copr.fedorainfracloud.org/coprs/ublue-os/staging/package/yafti/
https://copr.fedorainfracloud.org/coprs/ublue-os/staging/package/yafti/
Z
ZSmall sketch of what Im planning
Anot sure if something went wrong with the build but it's still on 0.10.1
Jdunno some rpm person is going to have to look at this
Fafter this is merged, build needs to be rerun again
Mmy laptop switched over to composefs... and i didn't even notice. Desktop where I was trying to do so didn't....
JOMG
J@Robert (p5) you just gave me an idea
Jcould we use renovate to monitor the prior build up the chain in ublue
Jlike
Jok so akmods fires off right
Jcould have a renovate in main that watches for the hash of the things we pull in.
Jand when it notices them, we set that to bump and then automerge
RRIt manages multiple digests in a YAML, Renovate bumps the digest and it can be configured to auto merge
Jright
Joh my god
RSo all base images, and other downstream dependencies in a single file
JRIGHT
Jso in bluefin if silverblue-main gets rebuilt just PR, automerge, and kick off a build.
Jand so on?
RYeah
