also, if we published the rpm in like, the releases section we wouldn't need the podman command at a
also, if we published the rpm in like, the releases section we wouldn't need the podman command at all right?
Xright now the signing package is only available in that container
JGitHub
Sigstore signed images are now here - Universal Blue Custom Operating System images based on Fedora https://universal-blue.org/blog/2023/07/19/sigstore-signed-images-are-now-here/
Jah ok, adding an emoji was enough to kick off giscus at least
K
AYeah
Xmethod using rpm query instead of grep:
Joh no
Jnow we have another (good) problem
Jremember how I said we're going to hit 1 million pulls on friday?
JWe are, as of now, at
991249
Toh dear god
Tthat's amazing!
Jneed one review and we're good to go!
J@KyleGospo you've been here a long time, do the honors?
KI'd love the honor
KUno moment
J\o/
Jsmoke if you got em!
EJust had a thought. Do we need to change anything in isogenerator now that we have signed images?
Jnot sure
Jlooking but nothing jumps out at me
EI'll give it a sweep
Bworth mentioning somewhere that you have to have the last unverified pull before you can switch to the signed image
BRebooting into signed now
Bhacker voice: I'm inBkudos to everyone on the amazing job getting this shipped. what a team
JI don't want to sound alarming, but i was having issues moving into the signed images https://github.com/orgs/ublue-os/discussions/193#discussioncomment-6499271 and it was preventing me to update images in general, wondering if more ppl are stuck in a version due to this issue and not realizing of it because they are relying on the auto update process.
EOhhhh no. @j0rge the borked images probably made it out to some people
Jlink?
ERight here
Joh the one just posted
EYeah. Same problem we encountered yesterday bringing it up. Not sure of how many people got it
Jyeah let me reply with the one liner
EAwesome
Jhopefully you and I are he only ones, we caught the issue but a few updates might have snuck out in the 30m it took to fix
BI noticed that as of yesterday ( https://github.com/ublue-os/main/pull/278 )
So I'm wondering if we should document and change this use case.
We should be able to re-add the legacy broadcom
Users who need them would need the extra step still, of building their own image to include the
akmods repo can build kmod RPMs, but NOT have them auto-installed into *-main images...So I'm wondering if we should document and change this use case.
We should be able to re-add the legacy broadcom
wl driver for example, which would behave just like the gcadapter_oc and jupiter drivers, which are built, but not included in *-main.Users who need them would need the extra step still, of building their own image to include the
akmods/foo.rpm and to install it and it's dependencies.
EThat sounds like a good idea to me. No reason to hold back now that they can be individually shipped
BI still wouldn't add
xone yet though as i think it will be better to proceed with the xpad-noone plus xone plan as i've already documented in an issueBbtw, thanks @EyeCantCU and @KyleGospo (and others if i missed) for the work on getting the ublue-os COPR setup! looks good!
EYw. Got you added to it
J
Jthe creator of sigstore knows who we are now. 
Dso it is safe rebase to signed image rn?
Jyeah I moved all my stuff yesterday, smooth sailing so far
GYes
JB
bluefin has the benefit of building in ublue-os org and signing with the ublue-os key so no custom policy required Jyeah
Blooks pretty easy for me to add though
