so why not make a tool for creating CD images? Is it just a lot harder?
so why not make a tool for creating CD images? Is it just a lot harder?
AThere is such tool,
xorrisoAIt is quite complex
AThat’s how isogenerator works
Git uses xorriso and modifies the ISO accordingly?
AWe unpack fedora’s iso and then repack it with our own files
Gohhhh
Gthat's a bit hacky
Gbut if it works 
Aduring this process we are introducing some slight differences which causes the problems booting 
Gyeah maybe we should try lorax
Gwould it work with signed OCI images?
AIt would be a lot better
ABut I don’t know how to use it and looks like there’s no documentation short of asking to fedora people 
AYeah
GFedora people are scary lol
GI would feel very bad for hounding them about lorax
Gis there any examples of how fedora uses lorax?
AThe script you posted earlier
AGhuh
Galr i'll try loading up my fedora VM and start messing around
Bhmmm
Bi'm seeing a weird error doing podman builds locally and it's... and it's referencing invalid policy
Jyeah when you said you were some of it was over your head, that's why I call people in here explorers, we're the first ones trying to use existing stuff in a new way and running into the classic onboarding problem
Jand fixing problems like that interest me.
Bi'm pretty sure this /etc/containers/policy.json is breaking some "normal" podman behavior
specifically the default reject
specifically the default reject
Jso I will take every opportunity to talk to people on those teams, I just ain't got time for a bugzilla discussion, it needs to be a real convo
Gwhat's erroring?
Gare you pulling from ghcr.io/ublue-os?
Jand this feels like the evolution of my role here. Since I have to talk to these people for work related stuff anyway and I get to have those high bandwidth conversations then it's a no brainer to just apply that to what we do here
Bif i do a local
the build succeeds, and results in an image being created, but then,...
if I do
I get:
podman build -t Containerfile build-configthe build succeeds, and results in an image being created, but then,...
if I do
podman build -t Containerfile build-config2I get:
Jlike, I can attack the problem from a different angle when I can talk to someone who is a program manager or something. For example, container diffs would be a huge thing, and it can totally be implemented, we just need to be able to pitch the feature as a cloud native one. This will also save you a ton of money on your cloud bill. Everyone wins.
Bi confirmed that reverting the default policy from
rejectinsecureAcceptAnythinginsecureAcceptAnythingdoesn't work just adding
Bif i'm correctly reading the skopeo/rpm-ostree bugs which necessitated the current complex config, hopefully those bugfixes will allow us to go back to a simple config...
was that your understanding @j0rge ?
was that your understanding @j0rge ?
Bi fixed it!
Burgent PR 
GI'm gonna try to PR some changes to the image signing in startingpoint, I realized that the configs are already there if one has ublue-os-signing installed (make it easier so one doesn't have to manually update the signing configs)
BBGitHub
Fixes the bug by adding to the containers/policy.json.
Incidentally fixes typos in dates on spec files which were found during testing.
closes #82
Incidentally fixes typos in dates on spec files which were found during testing.
closes #82
GGitHub
We can assume that the image signing configs are already installed from the config layer, so all we need is a couple of sed commands to change them to work with the user's repo.
Gbasically making it rely on the upstream signing configs
Bthe trick here is that startingpoint itself is signed with ublue-os key, but it's meant for users to make their own (eg, my own image is signed with a personal key)...
so the policy file needs to be managed by downstream user builds and have their own bits injected
so the policy file needs to be managed by downstream user builds and have their own bits injected
Gbasically I just replace the instances of ghcr.io/ublue-os with the user's repo eg: ghcr.io/gerblesh, replace ublue-os.pub with cosign.pub, you get the idea
Git's just 3 sed commands
Band probably we don't want to remove (sed replace) the ublue-os info since doing so would prevent those users from rebasing back to a signed ublue-os image
Goh true
Ghm
Gis it possible to use jq to wrirte to it
