RThis is where those defs are matched against
Ryeah, so bluefin should have the same issue
Ri think
Rsince osrelease id is "bluefin" for which there is no def
R
Tliterally that
JI just add a manifest on my fork of image builder lol. Seems crazy to have a list per OS in the public version of bib
R
I just add a manifest on my fork of image builder lol.
why didn't i think of this lmao
RI'd open an issue in the osbuild/bootc-image-builder repo. Requiring each distro or image that wants to use BIB to have a file in their repo isn't very scalable
JI did? Or maybe commented. They said they are happy to add more
R
Rsmall world
RCreated this to remind them and start a discussion
https://github.com/osbuild/bootc-image-builder/issues/816
https://github.com/osbuild/bootc-image-builder/issues/816
GitHub
Do we want to add manifests for all custom images? I can imageing the list becoming very long. Or should there be some way to pass it in to the build? Probably a bit of both; I see no real necessit...
JThe base image specifies a bib image it wants to use too, weird that it doesn't specify what OS it is https://gitlab.com/fedora/bootc/base-images/-/blob/main/fedora-bootc-config.json?ref_type=heads
AI ended up just making copies of the manifests locally and bind-mounting them into the container 
but yeah, it's a wild choice. even just being able to pass an option to specify "use this manifest" vs letting it try to auto-detect would be nice
but yeah, it's a wild choice. even just being able to pass an option to specify "use this manifest" vs letting it try to auto-detect would be nice
Othe UTF-8 error is fixed by rechunking with hhd-dev/rechunk
Owhy
Tprobably something changed
Tit does not get fixed specifically because of that tho, bluefin rechunks and it still got that issue
OI mean
Oit fixed it in the case of my image
Oif I remove the rechunk step, ostree deploys will always fail
Tits something in
ublue-os/main that is fucking it upOreally my image is just ublue base kinoite with some regular fedora packages added
OI know, I discussed this yesterday
Owith some of the other folks in here
Othat was when I came up with the hypothesis that the rechunking was the reason why aurora and bluefin weren't building failing isos
Obut like I had no real evidence for that at all
Oexcept, rechunking is the only way to make my ublue-os/main derived image work with ostree deploy
Ostrange stuff
�How do I work around zstd:chunked being borked with rpm-ostree
�is there some argument for rechunker to make it use gzip
�Ah
�I explicitly set it to zstd:chunked in podman push 
Jthat won't work bootc doesn't do zstdchunked yet
Ayoull just make your pushes take forever
L@tulip I saw you added Intel level zero drivers for NPUs to the packages repo. I work on level zero / Intel compiler at work so that was surprising to see that in a ublue repo lol
JOH ledif!
Jthat's the laptop from framework we're taking to SCALE to demo -lts
Jdo you know any demos that will run on that thing? nothing supports it lol
Twe were trying to add it to bluefin LTS but i coudlnt get it to compile for centos 10 :(
LNot sure. I work on Intel GPU enablement (data center, not battlemage) and have no clue about the NPU stuff. Although I probably should lol. I know the repos with the NPU stuff so I'll make a note to look into it on Monday
Jwell anything that helps intel enablement I'm down
JI need to impress arun gupta.
A@j0rge @Niklas 
@ledif i know seeing bazzite on the same chart as as bazzite might make it seem small, but you guys are growing great too
@ledif i know seeing bazzite on the same chart as as bazzite might make it seem small, but you guys are growing great too
Jnice!
Jman we gotta get these charts on the website before scale yo
Jso do we think this is 2.7k machines checking in?
