AGo feels like I’m constantly writing the same code over and over again
AIt would but by default VMs use installer media as CD
Gohhhh
Gyeah that would be annoying
AYou’d have to add such image as a usb device
Gso what would break compatibility with a CD?
GJust not using the ISO format?
ACD images use a specific file system with very weird booting records
Ghuh
AISO 9660 (also known as ECMA-119) is a file system for optical disc media. The file system is an international standard available from the International Organization for Standardization (ISO). Since the specification is available for anybody to purchase, implementations have been written for many operating systems.
ISO 9660 traces its roots to t...
ISO 9660 traces its roots to t...
Gso 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
reject to insecureAcceptAnything will fix it... so now i'm trying to figure out another way... maybe setting "localhost" to insecureAcceptAnythingBdoesn'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)
