* fix(akmods): Xone installs conflicted "akmod-xone" package
This sets higher priority for `akmods repo` compared to `multimedia repo`, which should fix potential issues in the future for other akmods too.
Thanks to the debugging done here:
https://github.com/ublue-os/akmods/pull/116
* fix(akmods): There is no need to revert to default, as it doesn't cause issues
On the other side, enabled multimedia repo afterwards causes issues.
* chore(akmods): Format function spacing same as other 2 functions
* chore(akmods): Make ENABLE_MULTIMEDIA_REPO more readable
* fix(default-flatpaks): Install/uninstall system flatpaks regardless if current user has permissions or not
Fixes: https://github.com/ublue-os/bling/pull/93
To make notify-send working for --system systemd units, I have to thank @gerblesh for his code & idea in ublue-updater.
I tested this in Silverblue & it works.
However, I would like this to be tested in other DEs like Kinoite too, to see if it's working correctly.
Feel free to improve code if you find some space for that.
@lorduskordus
* Use json parser instead as a more reliable solution on fetching values
* There is no need for echo when parsing json
* Fetch DISPLAY environment variable from printenv
* Make functions for notify-sends, to make script clearer
* Whiteline fixes
what we're losing with this:
- distrobox-rocky & distrobox-alpine (could be added to config if wanted)
- emudeck & deckyloader install scripts (unmaintained, undocumented)
- setup-gaming (installs random collection of flatpaks, unmaintained, legacy)
- funnily named nix recipes (nix me up)(unmaintained, exists in config with different names)
* 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>
This is an edge usecase where this happens, I can give an example:
1. User sets that default-flatpaks uninstalls "Telegram" `system` flatpak. Default-flatpak does that job successfully.
2. Afterwards, he installs "Telegram" as `user` flatpak
3. False notification will appear on boot that "Telegram" `system` flatpak is uninstalled (reminder that "Telegram" is already uninstalled successfully in step 1).
I found out that you can set `--user` & `--system` flag when issuing flatpak column list of applications.
This change solves the problem.
* 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>
This allows us to ditch the state file concept, which only allows us to run flatpak-setup once. After that, you need to manually delete the state file (system & user-flatpak-configured) if you want to have new changes from flatpak-setup.
This is not ideal.
We do not have the luxury of Bazzite, which allows you to change the version of the setup in setup service to automatically start it again (that's what they do).
Instead, we will install & uninstall only those flatpaks which are not on the list, ditching the need to have version checking.
I incorporated some shell formatting fixes, thanks to shellcheck.net.
The only thing that doesn't work right now is installing flatpaks from install list when you have some flatpaks installed already. Grep -v doesn't work for some reason when piped with echo, I'm looking in how to fix this.
I'm also looking into potentially bringing automatic version adjustment whenever you change the flatpak list/repo if possible, to ensure that flatpak-setup service exits immediately if there are no changes, compared to running fully checking for updates.
* 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
