A daily schedule (and Run workflow) first merges github.com/ublue-os/aurora
main into ours and pushes the merge, then builds and publishes, picking up
upstream's changes and the day's Fedora package updates.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
.forgejo/workflows/build.yml: just build, then push
forge.quinefoundation.com/quine-global-labs/aurora (stable,
stable-<date>, the commit). Its existence also stops Forgejo from running
upstream's .github/workflows.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* 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.
* chore: cleanup systemd services, move to presets
Preset files are cooler [1] and we should be able to get rid of a little
bit of complexity on the ISOs as we simply delete the preset file to
undo things we don't want to have on the ISO (uupd, tailscale ...)
instead of playing catch-up with the image [2].
Also we don't need to enable the *service* of rpm-ostree-countme, we
want to have the *timer* enabled, which is already done by default in
Fedora. The rpm-ostreed-automatic.timer is a leftover from ublue-os/main
days as we enable that for those images but disable it here as we use
uupd.
The Bazaar service got deleted and the need for that got completely
eliminated upstream recently.
[1] https://www.freedesktop.org/software/systemd/man/latest/systemd.preset.html
[2] https://github.com/get-aurora-dev/iso/issues/100
* chore: also do DX
* sunshine
we should make this a seperate thing as we want to still have this
disabled on the live iso
* deal with homebrew nonsense
* prefix with 89
so they can be overriden by others via preset files but still have more
priority over Fedora ones
* split fedora flatpak related services
so we can more easily keep this configuration active
Instead we can define an environment variable for github actions.
For things where we can't, globs/regex is probably good enough.
When we branch/stabilize "stable-f45" then we will delete the old one
anyway, so we shouldn't be in a situation where we'll get spammed with
like 3 PRs.
The only remaining things where it's hardcoded is the pull config and
docs.
* feat: bump testing to Fedora 45
We are using docker from their repo because it usually ships newer
versions faster than Fedora. In the meantime we can just ship Fedora's
docker version which is good enough.
xref: https://github.com/ublue-os/aurora/issues/2758
* renovate
* fix: cleanup hidden files in /tmp
Something specific to the DX build creates a bunch of socket files
(/tmp/.{ICE,X11,XIM,font}-unix) now. I have no idea what it is, it is
not the new docker package.
In the last release [1] I noticed that instead of comparing XX15.2 and
XX15.1 with each other, the tag from last week got resolved because
only the highest index point of that day was kept. So we compared XX15.2 with XX09.1, that resulted in essentially a lot of duplicate information in that release, instead of just a small addition.
The expected output of the test seems like a typo to me.
[1] https://github.com/ublue-os/aurora/releases/tag/stable-20260915.2
