This is a requirement for using bootc with Anaconda or else we don't
enforce signed images for subsequent updates.
In the past we have used bootc switch --mutate-in-place (in combination
with ostree-container which is what we are currently using for the
installation media), but this no longer works with bootc for whatever
reason.
This doesn't seem to matter for local builds, so this is fine to just
add here on the image.
xref: https://github.com/get-aurora-dev/iso/pull/93
We are not using that right now in Justfiles, we should be using
image-versions.yaml from the org-renovate config [1]
[1] 915bbf3a9a/org-inherited-config.json
* chore: add autoclose of issues without requested info
Same as ba6f78b1af
- autocloses issues 14 days after the issue was labeled with NEEDSINFO label and now update (comment)
example of it can be seen here: https://github.com/get-aurora-dev/common/issues/281
* concurrency and properly named job
* make zizmor happy
---------
Co-authored-by: renner <renner0@posteo.de>
If we are using the exact same ublue-os/akmods image and the same inputs
for the initramfs, then it should be stable between builds, make updates
smaller and allow soft-rebooting between deployments (as long as all the
requirements for soft-reboot are met of course).
Thanks secureblue!
xref: https://github.com/ublue-os/aurora/issues/2568
* refactor: simplify checking for enabled 3rd party repos
We are generally no longer doing the dnf enable/disable dance (except
for the nvidia install script) because we are vendoring the .repo files
which simplifies things a bit.
Also I think that the move to checking what is allowed instead of
checking what is not allowed makes more sense anyway.
resolves: https://github.com/ublue-os/aurora/issues/2854
[1] 1e4d10b9ac/build_files/nvidia/nvidia-install.sh
* get openh264 from negativo
Our base image [1] can't legally include this from fedora-cisco-openh264
repo. Comparing the spec files for Fedora [2] and Negativo [3], they
seem to be built with the same build flags, so they should not have any
differing functionality. The fedora-cisco-openh264 repo is currently
enabled (which is not the case for F44 images) because our repo
validation script broke due to the move to /usr [4].
We are already shipping various other codecs on the system, including
mesa, they get more irrelevant each day but we should have this.
I don't know why exactly but for some reason we now have a stray
/var/log/dnf5.log which makes bootc container lint fail.
[1] 54e811f17a/common.yaml (L144)
[2] cd15228484/f/openh264.spec
[3] dfac89f533/openh264.spec
[4] https://fedoraproject.org/wiki/Changes/RelocateRpmRepoConfigsToUsr
This is taken from [1]. We were for no good reason regenerating the initramfs
here. We can also install the kmods with the kernel in one step so I
don't see why we shouldn't just do that. It reduces the amount of time
needed to run this script (on my machine) from 49s to 28s.
I'm not sure if this is an oversight in rpm-ostree, we could technically
use the initramfs that is built during this stage, however, we lose
quite a bit of control, which we definitively want to have.
Also it should generally be noticable when the v4l2 and xone kmods fail
to install. There also haven't been problem regarding that in quite a
while.
[1] 5441c76f1f
We are currently getting this from Fedora anyway, also the negativo package is
unmaintained, Fedora ships a newer version.
It's packaged the same and doesn't actually include any more features
Fedora can't legally ship from the looks of it.
This is faster and less resource intensive. It usually takes a couple
seconds on my machine.
We only care about the label on that one image, and not the 3000 other
images in the ublue-os/akmods namespace.
