Every nightly rebuilds all 33 targets even when nothing changed. Each
rebuild is another chance to hit a mirror flake, and published images
record nothing about what they were built from.
Label each image with a fingerprint of its inputs: the kernel release,
the git objects that feed the build, the target config, and overrides.
The build job skips test, build, and push when the published image
matches, is signed, and is under AKMODS_MAX_AGE_DAYS old (default 7).
The manifest job likewise skips regenerating indexes that are already
current and signed, but attestation still runs every time. Any doubt
means build. PR runs and the new force input bypass the guard.
NVIDIA builds pin akmod-nvidia to the fingerprinted version, and the
userspace packages to the same driver version, so the label describes
what was actually built.
* fix(build): retry dnf installs with fresh metadata
Fedora updates pushes leave mirrors briefly inconsistent. dnf rejects the
new repomd, accepts an older one, then 404s on RPMs that have already been
removed. A plain retry reuses that metadata, especially with the persistent
libdnf5 cache, so refresh it between attempts.
* fix(zfs): pin ZFS release instead of querying the GitHub API
Unauthenticated api.github.com calls from shared runner IPs get rate-limited,
and short curl retries cannot outlast an hourly limit. Pinning the full
release removes that call and makes version bumps show up as PRs.
BREAKING: ZFS_MINOR_VERSION and zfs.*.minor_version are no longer read.
Use ZFS_VERSION and zfs.*.version (full X.Y.Z). Renovate manages the pin.
* fix(just): resolve CoreOS kernel without pulling the image
cache-kernel pulls the full fedora-coreos image on every arch just to run
rpm -q kernel, and a quay.io CDN EOF fails the job. Read the build id from
the image index and the kernel from commitmeta.json instead.
An empty or invalid cache.json was also published, so the later step failed
with "Input required and not supplied: path". Write the cache only after
the fields check out, and drop a restored cache that does not match.
* fix(just): retry koji kernel lookups
A transient curl error was treated as "not found" because the check matched
the string "200 OK" with no retry. That dropped the release number by 100
and could select the wrong kernel or none. Retry transport failures, and
only use the fallback after a successful request that returns 404.
* docs: document RPMFUSION_MIRROR build override
The variable already changes where the build fetches RPM Fusion packages,
but it was not listed with the other Justfile environment variables.
* chore: remove centos and centos-kmodsig akmods support
CentOS Stream 10 builds are no longer needed. This change removes:
- The centos kernel flavor from images.yaml and its generated workflow
- The centos-kmodsig dead code from Justfile and fetch-kernel.sh
- All centos-specific branches in build scripts (prep, test, nvidia, dual-sign)
- The #ifndef CENTOS preprocessor guard in Containerfile.in
- CentOS references from README.md badges and examples
- CentOS from artifacthub package keywords
* docs: update akmods example version to 44
* chore: drop Fedora 43 builds
Fedora 43 akmods are no longer needed by the maintained downstreams.
Retire their build matrix alongside the removal of GTS support in
ublue-os/main to stop producing unused kernel and module caches.
* fix: preserve Fedora 43 CoreOS stable builds
Bluefin LTS HWE and GDX still consume coreos-stable-43 akmods, so retain that flavor while dropping the other Fedora 43 builds.
* chore(deps): update ghcr.io/ublue-os/devcontainer:latest docker digest to ba4c0e5
* fix(build): enable just list support
The refreshed devcontainer's just version requires list support for which(). Enable it so CI can evaluate build recipes.
---------
Co-authored-by: ubot-7274[bot] <217212047+ubot-7274[bot]@users.noreply.github.com>
Co-authored-by: Benjamin Sherman <benjamin@holyarmy.org>
ubuntu-latest will soon migrate to 26.04. Update in advance to verify
behavior. Pin every job in the build, cache, and publish path to 26.04
explicitly so the runner OS is deterministic there. Housekeeping
workflows (cleanup, scorecard) stay on ubuntu-latest.
* chore(nvidia): move negativo nvidia repos to /usr
This PR should do the following things:
On Fedora 45 and higher, move .repo files from /etc/yum.repos.d to
/usr/share/dnf5/repos.d.
On Fedora 44 and centos/rhel, don't touch anything, package should be
identical after this change and keep the
/usr/share/ublue-os/etc/yum.repos.d for everything for now.
As discussed in: https://github.com/ublue-os/akmods/issues/591#issuecomment-5742188994
* debug package contents
* rm /usr/share/ublue-os/etc/yum.repos.d from F45 and higher
* remove more redundant leading slashes
or else this results in /usr/share/ublue-os//etc/yum.repos.d with 2
slashes as %{_sysconfdir} resolves to /etc which already has a slash
character
* add check to prevent shipping enabled repos
* changelog
* make test check for True and yes as well
These are also valid options in dnf5, however at least Fedora sticks
with 0/1.
See: https://dnf5.readthedocs.io/en/stable/dnf5.conf.5.html#boolean-label
See: https://dnf5.readthedocs.io/en/stable/dnf5.conf.5.html#repo-options
This gets rid of one occurence of the hardcoded yum.repos.d, also we
should be using the standard COPR naming scheme, nothing in the org, for
this particular dnf repo at least, relies this non-standard naming
convention.
The dnf copr plugin seems to create a new .repo file in /etc/yum.repos.d
even though it is already present and disabled in
/usr/share/dnf5/repos.d (which is what we want to do in Aurora [1])
So if you rely on this script to add/enable ublue-os/staging then this
shouldn't affect anything, however, if you are vendoring the repo files
and putting them in /usr/share/dnf5/repos.d then you won't have this
specific COPR repo anymore in /etc/yum.repos.d.
This is a step towards [2].
[1] https://github.com/ublue-os/aurora/issues/2854
[2] https://github.com/ublue-os/akmods/issues/591
* bringup f45
* update the workflow
* do-not-test
* use dnf repo commands instead of sed
* gate openrazer on f45
* add notice for temp workaround for openrazer
* fix: Fail the build when a common or nvidia kmod script fails
The RUN blocks that call build-kmod-*.sh for the common and nvidia
targets ran `bash <<'RUNEOF'` without `set -euo pipefail`, unlike every
other block in the Containerfile. When a script exited non-zero, the
remaining scripts still ran and the build went on to RPM caching and
signing with a partial set of modules.
That is how the Terra openrazer change broke aarch64 builds. openrazer
aborted before removing its repo file, and the later kmod scripts kept
running with that repo still enabled, pulling in x86_64 RPMs.
Add `set ${CI+-x} -euo pipefail` to the common kmod block and the three
nvidia blocks so any failure stops the job. The extra block already has
it and intentionally keeps going on per-kmod failures via
`|| echo "SKIPPED: ..."`, so it is unchanged.
* fix: Retry the ZFS release downloads and fail on bad responses
`build-kmod-zfs.sh` fetched the OpenZFS release list from the
unauthenticated GitHub API with a bare `curl`, no retry and no `--fail`.
When GitHub throttled the runner it wrote the rate-limit page to
`data.json`, `jq` then died with "Invalid numeric literal", and the
build stopped with no hint of the real cause. The release tarball and
signature downloads had the same exposure to a transient github.com
error.
Route all four through a shared `curl --fail --show-error --location
--retry 5 --retry-delay 5 --retry-all-errors`, so a throttle or 5xx is
retried and a persistent bad response aborts the script at the curl
call.
* don't attempt vhba for aarch64
* feat: Switch to terra package for openrazer, now auto-updates and no longer requires manual ublue intervention for updates
* fix: Skip openrazer build on aarch64
Terra only publishes openrazer for x86_64. On aarch64 the build script
fails at `dnf install akmod-openrazer` (no arch match) before reaching
its `rm -f /etc/yum.repos.d/terra.repo` cleanup.
The leaked Terra repo then stays enabled for every later script in the
same layer, so `dnf download` pulls x86_64 builds of v4l2loopback and
xpadneo into the shared /var/cache/rpms/common set. The final aarch64
test install then fails on the incompatible-arch RPMs.
Exit early on aarch64 so the Terra repo is never added, matching the
existing wl build script.
---------
Co-authored-by: Benjamin Sherman <benjamin@holyarmy.org>
ZFS failing on a too-new CoreOS stable kernel turns the whole
coreos-stable check red and blocks nvidia and CVE updates. The
Justfile pin exists for that hold, but it was only a comment, so
the 7.1 incident went to local ZFS backports instead.
Document the pin policy in the README and point the ZFS configure
failure path at it when the kernel looks newer than OpenZFS
declares supported.
