In the past we have moved away from doing big dnf transactions spanning
multiple rpm repositories [1] because of the associated risk of third
party repos injecting packages we expect to get from Fedora. With this
we explicitly set which packages are allowed to be installed from each
repo. This means we still get to do big transactions which are generally
faster.
The downside of this is that if subpackages or dependencies from a
3rd-party repo get introduced/change then our builds will break, I think
this is fine as the ones I'm changing here have been unchanging for a
while.
This should only touch repositories with a very specific purpose/single
projects.
This purposefully doesn't touch any ublue-os coprs or negativo (also
they are difficult to handle as we use them in the nvidia script [2]),
those are the only mono-repos so outright excluding the packages is not
an easy option as we would make custom image builds (and usr-overlays
for testing) more annoying.
[1] https://github.com/ublue-os/aurora/issues/1115
[2] 1e4d10b9ac/build_files/nvidia/nvidia-install.sh
We can get rid of the copr-helper wrapper script as we are no longer
enabling and then disabling the repo, which is explained in [1] as we
are configuring them to be off by default and then very purposefully
enabling it for that one dnf transaction where we actually need it
enabled.
The files in yum.repos.d were copied from my local /usr/etc directory.
[1] https://github.com/ublue-os/aurora/issues/1115
* feat: add ZFS deprecation notifier
This will spawn a one-time notification that has to be dismissed by the
user if ZFS is being used.
xref: https://github.com/ublue-os/aurora/issues/1765
resolves: https://github.com/ublue-os/aurora/issues/2210
* fix typo
* be more explicit in msg
Co-authored-by: Adam Fidel <ledif@users.noreply.github.com>
* run it always every week
The chance that people will see it are way bigger this way.
* only actually enable on systems that have ship zfs
---------
Co-authored-by: Adam Fidel <ledif@users.noreply.github.com>
* feat: delete /run leftovers from the image
This is to make bootc container lint happy.
We should probably make warnings fatal so we fix new offenders.
Related: https://github.com/bootc-dev/bootc/pull/2051
* chore: remove unused rm
No idea why this is here, probably some super old leftover.
* do dx specific things as well
The libdnf5 package owns various files under /usr/lib/sysimage/libdnf5
that are getting generated during the build, for instance, the
transaction history (dnf history list), which changes with every build
due to timestamps and package versions.
This means that every single image build has a unique libdnf5 package,
which results in every update unnecessarily downloading it, although
nothing that we care about changed.
dnf history is not useful here; you can look in the build logs if you
really wanted to see what transactions are being done. On the client
side, things like dnf history undo don't work or are largely not the
right tool for the job in custom image builds.
xref: https://github.com/ublue-os/aurora/issues/2579
taken from blue-build[1], this also happens to make updates smaller by
100MB. Might fix the following issues like [2] and [3]. I could not
reproduce these issues myself and just using chunkah made it possible
for me to overlay firefox with rpm-ostree.
[1]: b6f36bd9a2
[2]: https://github.com/ublue-os/aurora/issues/2209
[3]: https://github.com/ublue-os/aurora/issues/2492
Co-authored-by: Daniel Hast <32797673+HastD@users.noreply.github.com>
The default is 30s, let's see if this is already enough. Most packages
should usually be cached, it's the retrieval of metadata that is often
the reason for the network related flakes.
xref: https://github.com/ublue-os/aurora/issues/2337
This causes certain characters to not be displayed properly, on my
system this was the case for system applications like dolphin and
konsole as well as flatpak applications like firefox and discord.
for example: 처형박수
This was originally introduced in [1] because of [2].
I'm not 100% sure if this doesn't break something else, but I tested
this by setting Steam (Flatpak) to chinese and I didn't see any
misrendered characters like described in [3]. It seems like this got
resolved at some point by something(?)
[1]: https://github.com/ublue-os/main/pull/334
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=2188765
[3]: https://github.com/ValveSoftware/steam-for-linux/issues/9418
There have been quite a couple changes in the last couple years that
were bootloader related in Fedora, namely switching to bootupd [1] with
F41 which allows updating the bootloader. Maybe this happenend to
resolve the issue because it got changed to fedora at some point?
Originally needed because fwupd looks for EFI/our_ID/**.
The only change we make to our package is hardcoding efi_os_dir=fedora
with a build option.
New installs have the directory set to fedora.
Introduced in 78671f2.
I have no idea if we still need this, this is a scream test.
[1]: https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd
* chore: cleanup packages.sh
We will not be building different major fedora versions from the same
branch anymore.
* chore: move flathub to fetch.sh
We don't need the flatpak command, it doesn't do anything.
`/etc/flatpak/remotes.d` is always present in the image due to flatpak
package creating this directory.
* chore: don't remove fedora plasma theme
We shouldn't be working around potential issues this way.
* test: check for flathub
To avoid us adding *all* 100+ packages to the image (each one is a
couple MiB) I only added the most popular languages according to
Flathub. See: https://flathub.org/statistics
If one is missing then people can just request it, at least it's getting
used then.
Supersedes: https://github.com/ublue-os/aurora/pull/1798
When rebasing from our kinoite base image to aurora:beta the ostree
deployment will fail with this error:
```
libsemanage.semanage_direct_get_module_info: Unable to open
mariadb-plugin-cracklib-password-check module lang ext file at
/etc/selinux/targeted/tmp/modules/200/mariadb-plugin-cracklib-password-check/lang_ext.
(No such file or directory).
```
Adding mariadb-cracklib-password-check back to our image resolves this
issue.
* feat(nvidia): add service to sync Flatpak driver version (#1983)
Co-authored-by: inffy <10782843+inffy@users.noreply.github.com>
* chore(ci): replace retry action (#1995)
* ci: replace extractions/setup-just with brew install (#2000)
* chore(deps): update ghcr.io/ublue-os/brew:latest docker digest to 1a058eb (#2002)
Co-authored-by: ubot-7274[bot] <217212047+ubot-7274[bot]@users.noreply.github.com>
* fix: move dracut configs to files instead of flags (#2003)
While this doesn't make a difference to our image build itself, it will
make the life easier for derived images as they will inherit all the
modules from us that we set anyway. This undoes some of the changes made
in 32a66fc719. These are specific to the things we install here so it
doesn't make sense to go into common.
---------
Co-authored-by: Adam Fidel <ledif@users.noreply.github.com>
Co-authored-by: inffy <10782843+inffy@users.noreply.github.com>
Co-authored-by: Dylan M. Taylor <dylan@dylanmtaylor.com>
Co-authored-by: ubot-7274[bot] <217212047+ubot-7274[bot]@users.noreply.github.com>
While this doesn't make a difference to our image build itself, it will
make the life easier for derived images as they will inherit all the
modules from us that we set anyway. This undoes some of the changes made
in 32a66fc719. These are specific to the things we install here so it
doesn't make sense to go into common.
