You have to make it yourself. to-disk is not meant to be a fully fleshed installer
You have to make it yourself. to-disk is not meant to be a fully fleshed installer
GI see, so the partitioning is done before hand?
ZYep
Gnice
Gso readymade is perfect then
MIt's a demo according to the documentation. It recommends to-filesystem with a bring your own partitioning
CA question for you knowledgable folks; I’m working on figuring out how to get a couple of proprietary system level pieces of software to work nicely on Bluefin. Currently I’m building rpms and layering them for testing with view to build a custom image. In the new bootc world this approach won’t be possible, so what is the best way of tinkering before I commit to a long GitHub actions run?
RIf the components you are adding can be validated in a terminal, you can use podman-bootc to run the image from your local containers storage
https://github.com/containers/podman-bootc
I also tend to run a local OCI registry, push a new image there and bootc switch to it in a VM.
https://github.com/containers/podman-bootc
I also tend to run a local OCI registry, push a new image there and bootc switch to it in a VM.
COk that’s a very cool approach. I’ll be playing with this stuff tomorrow! Thanks!
Z@Robert how is the SBOM stuff with syft/grype going? It seems you've gone back and forth a couple times on it in the repos
RIt's working well in Bluefin LTS - we just need to switch it back on.
Generating the SBOM fails in Bluefin for some reason. I've not had a chance to investigate yet. I think M2 said we need to create a large swap file for it to succeed.
Once Bluefin is fixed, we can copy and paste the code over to main, Aurora and uCore
Generating the SBOM fails in Bluefin for some reason. I've not had a chance to investigate yet. I think M2 said we need to create a large swap file for it to succeed.
Once Bluefin is fixed, we can copy and paste the code over to main, Aurora and uCore
ZThat's interesting but exciting news! I'm looking at doing the same in my repos. I can take a look as well. You think there's any benefit in putting this in the image template as well? So everyone can get them as artifacts?
ROnce the issues are ironed out, it's definitely something we should put in the template!
MIf we're going to use packages repo... we need to actually keep it up to date
RCan we add all approvers as reviewers? I don't get notified about any of these
Jyeah it's our biggest pain point right now, agreed.
Jthe devpod flatpak is almost done
J@Robert this sbom run on lts took like 3 minutes?
Jthat was way slower before
RGDX took 7 minutes... Think this was the main one causing problems
Jah right!
Jwell, other than that this is smoooooooth.
RBut if by "before", you're referring to 6 months ago, when we first tried SBOMs, then yes! It was 30ish minutes
Jheheh
JI think once we have a semi permanent ampere box to ssh to that we should be fine
MRight now attestation is the next challenge. I'm wondering if there is a limit to the sbom size for attaching?
MMy smaller images are working fine. But the larger ones the push to the registry is failing
JCan we start an sbom/attestatoin thread? I got a few nibble at kubecon for people looking to help
RJok so instead of using the github board when I get back I'm going to just write the update in hackmd and we'll put all of those items in there so we can double up
Jthen that will be our transparecy report for the cycle
JJcan I get a review?
J
Tits that damn safe-to-run tag
Tlets just remove that 
Till revert the thing and pr it
Tcuz this is causing more trouble than not
JToh nope
Tthat one was cuz you didnt bump the spec
Jhttps://github.com/ublue-os/packages/pull/300 this one is dangling too
Tso the action didnt know how t obuild it
JI didn't know I had to bump the spec
Tneed to fix the conflict here
Till actually do that right now, lemme just revert the thing
Tno worries its counter intuitive
Tgotta find some automated way of doing it
TTthere ya go
Tall the renovate ones should be fine i think