* feat: Add kmods installer module
Credits: @C0dePlayer
This is not ideal as it does not support custom kernels & it involves editing Containerfile.
I believe there is no other way but to make users edit Containerfile for those files to be even pulled of.
I would like this to be through the recipe only, so I will put this as a draft until some better ideas come.
* Rename kmods installer to akmods
* Update README
Address:
https://github.com/ublue-os/startingpoint/pull/212#issuecomment-1870156327https://github.com/ublue-os/bling/pull/89#discussion_r1436890002
* Fix README typo
* Remove non-needed space for yml in README
* Add support for Surface & Asus images
* Clarify tagged base image warning better
* Clarify tagged base image warning better pt.2
* There is no need to fetch main-nvidia build for now
* Use simpler =~ for conditioning instead of grep & sed
This finally fixes akmods module
* Install kernel-devel-matched for all builds
* Assure that Surface installs their version of kernel-devel-matched
* Mention that framework images can be used as a base
* Delete duplicate warning message
* Remove non-needed explanation on why only Universal Blue builds are supported
* Clarify 1st warning better
* Clarify `main` akmods compatibility better
This would avoid editing README if some other compatible image gets announced or discontinued.
* docs(akmods): grammar fixes
* docs: add link to akmod tag matrix
---------
Co-authored-by: xyny <60004820+xynydev@users.noreply.github.com>
* fix:(default-flatpaks): Missing notification for system flatpaks
This approach, while more fragmented, it's cleaner, as there is a clearer separation of root & non-root operations done by flatpak-setup service. This should probably increase security too (but I'm not the expert to talk seriously about that). It also gets rid of some non-harming error for /var data, can't remember it fully.
While it may be confusing for users that they have to type:
`systemctl status --user system-flatpak-setup`
instead of previous:
`systemctl status system-flatpak-setup`
It is something worth sacrificing for the important user-experience fix.
* feat(default-flatpaks): Add info about which flatpaks are installed & uninstalled in notification. Also implement notification enable/disable config support.
* feat(default-flatpaks): Add support for configuring notifications in recipe file
* fix(default-flatpaks): Formatting fixes
* fix(default-flatpaks): Fix "enabling" typo instead of "configuring" notifications
* chore(default-flatpaks): Remove unused yq command
* fix(default-flatpaks): There is no need for 2 double quotes
I switched my custom ublue image from using
"ublue-os/silverblue-nvidia" to "ublue-os/bazzite-gnome-nvidia" and
received the following error when the build action kicked off:
`ln: failed to create symbolic link '/usr/etc/profile.d/ublue-firstboot.sh': File exists`
The yafti module should be the only thing creating this symlink, so it
should be safe to use the `-f` flag to force creating it.
Signed-off-by: Micah Abbott <miabbott@redhat.com>
* fix(default-flatpaks): Always enable systemd services
Ensures that the module always removes Fedora Flatpaks, even if a
system-wide flatpak remote isn't configured for the module.
* chore(default-flatpaks): Add output for result of repo config
* fix(default-flatpaks): Better handle multiple uses of module
* chore(default-flatpaks): Add label to output of existing config
* docs(default-flatpaks): Mention that Flatpak remote can be re-configured
* docs(default-flatpaks): Add second example to README
* docs(default-flatpaks): Clarify repo config in second example
* docs(default-flatpaks): Make example config match other modules
* docs(default-flatpaks): Indent list items in example config
Does seem to work if they aren't indented, but this way matches other
modules and seems to be best practice
There's a lot of bling "submodules" that might require documentation. Including them inside the same README is beneficial, because it makes the appear on the ublue website too, and their documentation is often not that long.
* fix: terminology
* docs: mention ostree
this is *not* the case on all fedora distros, only the "immutable" / ostree ones
---------
Co-authored-by: xyny <60004820+xynydev@users.noreply.github.com>
