particle-os/particle-os-modules
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

refactor: start using module.yml for module metadata (#116)

Browse source 
* feat: add initial module.yml for rpm-ostree

* chore: add shortdesc to module.yml

* feat: add missing module.ymls

* feat: add website rebuild action for module reference updates

* chore: remove old readme in modules dir

* refactor: switch to a hybrid module.yml + README arrangement

* chore: switch docs to use starlight aside syntax
This commit is contained in:
xyny 2024-02-04 16:05:22 +00:00 • committed by GitHub
parent 3914df391f
commit 5e455a1477
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
25 changed files with 227 additions and 242 deletions
Download patch file Download diff file Expand all files Collapse all files

15
.github/workflows/rebuild-website.yml vendored Normal file
View file

@ -0,0 +1,15 @@
name: rebuild-website
on:
push:
branches:
- main
paths: # only rebuild when related files change
- "**/module.yml"
- modules.json
jobs:
rebuild-website:
name: Trigger build hook for website on Netlify
runs-on: ubuntu-22.04
steps:
- run: curl -X POST -d {} https://api.netlify.com/build_hooks/65bf6b0dd164b64659beafd5

13
modules.json Normal file
View file

@ -0,0 +1,13 @@
[
"https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/akmods/module.yml",
"https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/bling/module.yml",
"https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/default-flatpaks/module.yml",
"https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/files/module.yml",
"https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/fonts/module.yml",
"https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/gschema-overrides/module.yml",
"https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/rpm-ostree/module.yml",
"https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/script/module.yml",
"https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/signing/module.yml",
"https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/systemd/module.yml",
"https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/yafti/module.yml"
]

5
modules/README.md
View file

@ -1,5 +0,0 @@
# Modules for Startingpoint
Here (check the sidebar if you're on the website) is documentation for every default module for [Startingpoint](https://github.com/ublue-os/startingpoint/). Source code is inside the [bling](https://github.com/ublue-os/bling/) repository, which is intended for hosting more static and shared parts of custom images.
For more information about Startingpoint and modules, refer to the README inside the `config/` directory.

34
modules/akmods/README.md
View file

@ -1,40 +1,26 @@
> [!WARNING]
> Only Universal Blue based images are officially supported.
# `akmods`
> [!WARNING]
> Universal Blue builds with Fedora 38 & below are not supported.
:::caution
Only Universal Blue based images are officially supported. Universal Blue builds with Fedora 38 & below are not supported. Custom kernels are not supported.
:::
> [!WARNING]
> Custom kernels are not supported.
The [`akmods`](https://github.com/ublue-os/akmods) module is a tool used for managing and installing kernel modules built by Universal Blue. It simplifies the installation of kernel modules, improving the capabilities of your system.
# `akmods` Module for Startingpoint
The `akmods` module is a tool used for managing and installing kernel modules. It simplifies the installation of kernel modules, improving the capabilities of your system.
List of all available kernel modules & versions/tags are here:
List of all available kernel modules & versions/tags are here:
https://github.com/ublue-os/akmods
Ublue-os-akmods-addons & ublue-os-nvidia-addons are already included when necessary, so they are not needed to install.
To use the `akmods` module, specify the kernel modules you wish to install in the `install:` section of your recipe/configuration file.
## Example configuration
```yaml
type: akmods
install:
- openrazer
- openrgb
- v4l2loopback
- winesync
```
By default, the `akmods` module installs the `main` akmods for `latest` version of Fedora.
`main` akmods are also compatible with other images except `surface(-nvidia)` & `asus(-nvidia)`.
By default, the `akmods` module installs the `main` akmods for the `latest` version of Fedora.
`main` akmods are also compatible with other images, except `surface(-nvidia)` & `asus(-nvidia)`.
If you want to install akmods for `surface(-nvidia)` or `asus(-nvidia)` images, or for `older version of Fedora`, change this part in the Containerfile:
See available tags here: https://github.com/ublue-os/akmods/#how-its-organized
```
# Change this if you want different version/tag of akmods.
COPY --from=ghcr.io/ublue-os/akmods:main-39 /rpms /tmp/rpms
```
See available tags here: https://github.com/ublue-os/akmods/#how-its-organized

10
modules/akmods/module.yml Normal file
View file

@ -0,0 +1,10 @@
name: akmods
shortdesc: The akmods module is a tool used for managing and installing kernel modules built by Universal Blue.
readme: https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/akmods/README.md
example: |
type: akmods
install:
- openrazer
- openrgb
- v4l2loopback
- winesync

20
modules/bling/README.md
View file

@ -1,21 +1,9 @@
# [`bling`](https://github.com/ublue-os/bling) Module for Startingpoint
# `bling`
The `bling` module can be used to pull in small "bling" into your image, stuff that doesn't necessitate being configured at build time.
The `bling` module can be used to pull in small "bling" into your image. Bling is stuff that doesn't necessitate being configured at build time, in the form of configuration files or program installers.
The bling to pull in is declared under `install:`, and the code for installing them is all in simple named scripts under the `installers/` directory. The basic code for the `bling` module is very similar to the code of the `script` module.
## Example configuration
```yaml
type: bling # configure what to pull in from ublue-os/bling
install:
# - ublue-update # https://github.com/ublue-os/ublue-update
# - 1password # install 1Password (stable) and `op` CLI tool
# - dconf-update-service # a service unit that updates the dconf db on boot
# - gnome-vrr # enables gnome-vrr for your image
# - laptop # installs TLP and configures your system for laptop usage
# - flatpaksync # allows synchronization of user-installed flatpaks, see separate documentation section
```
## Submodule documentation
### `flatpaksync` (unmaintained)
@ -29,8 +17,8 @@ Once the submodule is activated, you should create the file `$HOME/.config/flatp
GIT_REPO=<YOUR_REPO>
```
To initialize your Flatpaks from flatpaksync, simply run the `flatpakcheckout` binary to perform the installation and start the synchronization.
To initialize your Flatpaks from flatpaksync, simply run the `flatpakcheckout` command to perform the installation and start the synchronization.
**It is important to note that this submodule will NOT enable Flathub. If your applications come from there, you will need to enable Flathub before running it.**
If you have configured the repository in the `$HOME/.config/flatpaksync/env` file but already have the Flatpaks installed, simply create the `$HOME/.config/flatpaks.user.installed` file to inform the script that the installation is done and start the synchronization.
If you have configured the repository in the `$HOME/.config/flatpaksync/env` file but already have the Flatpaks installed, simply create the `$HOME/.config/flatpaks.user.installed` file to inform the script that the installation is done and start the synchronization.

12
modules/bling/module.yml Normal file
View file

@ -0,0 +1,12 @@
name: bling
shortdesc: The bling module can be used to pull in small "bling" into your image.
readme: https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/bling/README.md
example: |
type: bling
install:
# - ublue-update # https://github.com/ublue-os/ublue-update
# - 1password # install 1Password (stable) and `op` CLI tool
# - dconf-update-service # a service unit that updates the dconf db on boot
# - gnome-vrr # enables gnome-vrr for your image
# - laptop # installs TLP and configures your system for laptop usage
# - flatpaksync # allows synchronization of user-installed flatpaks, see separate documentation section

49
modules/default-flatpaks/README.md
View file

@ -1,8 +1,8 @@
# `default-flatpaks` module for startingpoint
# `default-flatpaks`
The `default-flatpaks` module can be used to install or uninstall flatpaks from a configurable remote on every boot. It skips that operation if no changes are detected. This module first removes the Fedora Flatpaks remote and Flatpaks that come pre-installed in Fedora. A Flatpak remote is configured the first time the module is used, but it can be re-configured in subsequent usages of the module. If no Flatpak remote is specified, the module will default to using Flathub.
The `default-flatpaks` module can be used to install or uninstall Flatpaks from a configurable remote on every boot. It skips that operation if no changes are detected. This module first removes the Fedora Flatpaks remote and Flatpaks that come pre-installed in Fedora. A Flatpak remote is configured the first time the module is used, but it can be re-configured in subsequent usages of the module. If no Flatpak remote is specified, the module will default to using Flathub.
Flatpaks can either be installed system-wide or per-user, though per-user flatpaks will be installed for every user on a system. Previously-installed flatpaks can also be removed.
Flatpaks can either be installed system-wide or per-user. Per-user Flatpaks will be installed separetly for every user on a system. Previously-installed flatpaks can also be removed.
The module uses the following scripts to handle flatpak setup:
@ -14,47 +14,8 @@ The scripts are run on every boot by these services:
- `/usr/lib/systemd/system/system-flatpak-setup.service`
- `/usr/lib/systemd/user/user-flatpak-setup-service`
`system-flatpak-setup` uninstalls Fedora flatpaks, replaces Fedora repos with your repo choice, checks the flatpak install/remove lists created by the module & performs the install/uninstall operation according to that. `user-flatpak-setup` functions the same for user flatpaks.
`system-flatpak-setup` uninstalls Fedora flatpaks, replaces Fedora repos with your repo choice, checks the Flatpak install/remove lists created by the module & performs the install/uninstall operation according to that. `user-flatpak-setup` does the same things for user Flatpaks.
This module stores the Flatpak remote configuration and Flatpak install/remove lists in `/etc/flatpak/`. There are two subdirectories, `user` and `system` corresponding with the install level of the Flatpaks and repositories. Each directory has text files containing the IDs of flatpaks to `install` and `remove`, plus a `repo-info.yml` containing the details of the Flatpak repository.
This module also supports disabling & enabling notifications.
## Example configurations
```yaml
type: default-flatpaks
notify: true # Send notification after install/uninstall is finished (true/false)
system:
# If no repo information is specified, Flathub will be used by default
repo-url: https://dl.flathub.org/repo/flathub.flatpakrepo
repo-name: flathub
repo-title: "Flathub (system-wide)" # Optional; this sets the remote's user-facing name in graphical frontends like GNOME Software
install:
- org.gnome.Loupe
- one.ablaze.floorp//lightning # This is an example of flatpak which has multiple branches in selection (flatpak//branch).
# Flatpak runtimes are not supported (like org.winehq.Wine//stable-23.08).
# Only normal flatpak applications are (like Floorp Lightning web browser in this example).
# Multiple install of same flatpaks with different branches is not supported.
remove:
- org.gnome.eog
# A flatpak repo can also be added without having to install flatpaks,
# as long as one of the repo- fields is present
user:
repo-name: flathub
```
```yaml
# Assuming that the above example is called first in a recipe,
# a subsequent usage might look like this:
type: default-flatpaks
system:
# If the repo-* fields are omitted, the configured repo will
# use the previous configuration. Otherwise, it defaults to Flathub.
install:
- org.kde.kdenlive
user:
# repo-name will overwrite the previously-configured repo-name for the user remote
repo-name: flathub-user
repo-title: "Flathub (User)
```
This module also supports disabling & enabling notifications.

38
modules/default-flatpaks/module.yml Normal file
View file

@ -0,0 +1,38 @@
name: default-flatpaks
shortdesc: The default-flatpaks module can be used to install or uninstall flatpaks from a configurable remote on every boot.
readme: https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/default-flatpaks/README.md
example: |
modules: # configured multiple times to highlight how options are overridden
- type: default-flatpaks
notify: true # Send notification after install/uninstall is finished (true/false)
system:
# If no repo information is specified, Flathub will be used by default
repo-url: https://dl.flathub.org/repo/flathub.flatpakrepo
repo-name: flathub
repo-title: "Flathub (system-wide)" # Optional; this sets the remote's user-facing name in graphical frontends like GNOME Software
install:
- org.gnome.Loupe
- one.ablaze.floorp//lightning # This is an example of flatpak which has multiple branches in selection (flatpak//branch).
# Flatpak runtimes are not supported (like org.winehq.Wine//stable-23.08).
# Only normal flatpak applications are (like Floorp Lightning web browser in this example).
# Multiple install of same flatpaks with different branches is not supported.
remove:
- org.gnome.eog
# A flatpak repo can also be added without having to install flatpaks,
# as long as one of the repo- fields is present
user:
repo-name: flathub
# Assuming that the above example is configured first in a recipe,
# a subsequent usage might look like this:
- type: default-flatpaks
system:
# If the repo-* fields are omitted on the subsequent usage,
# the module will use the previously configured repo.
# Otherwise, it will overwrite the repo configuration.
install:
- org.kde.kdenlive # this Flatpak is appended to the insta llist
user:
# repo-name will overwrite the previously-configured repo-name for the user remote
repo-name: flathub-user
repo-title: "Flathub (User)

17
modules/files/README.md
View file

@ -1,16 +1,7 @@
# `files` Module for Startingpoint
# `files`
The `files` module simplifies the process of copying files to the image during the build time. These files are sourced from the `config/files` directory, which is located at `/tmp/config/files` inside the image.
> **Warning**
> If you want to place anything in `/etc` of the final image, you MUST place them in `/usr/etc` in your repo, so that they're written to `/usr/etc` on the final system. That is the proper directory for "system" configuration templates on OSTree-based Fedora distros, whereas `/etc` is meant for manual overrides and editing by the machine's admin AFTER installation! See issue https://github.com/ublue-os/startingpoint/issues/28.
## Example Configuration
```yaml
type: files
files:
- usr: /usr
```
In the example above, `usr` represents the directory located inside the `config/files` in the repository, while `/usr` designates the corresponding destination within the image.
:::note
If you want to place any files in `/etc/`, you should place them in `/usr/etc/` instead, which will be used to generate `/etc/` on a booted system. That is the proper directory for "system" configuration templates on atomic Fedora distros, whereas `/etc/` is meant for manual overrides and editing by the machine's admin AFTER installation! See issue https://github.com/ublue-os/startingpoint/issues/28.
:::

9
modules/files/module.yml Normal file
View file

@ -0,0 +1,9 @@
name: files
shortdesc: The files module simplifies the process of copying files to the image during the build time.
readme: https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/files/README.md
example: |
type: files
files:
- usr: /usr
# usr: file/folder inside config/files/ to copy (config/files/usr/ in the repository)
# /usr: destination on the final system

21
modules/fonts/README.md
View file

@ -1,20 +1,3 @@
# `fonts` Module for Startingpoint
# `fonts`
The `fonts` module can be used to install [nerd-fonts](https://www.nerdfonts.com/) or [google-fonts](https://fonts.google.com/). This module will always download the latest version and properly configure fonts.
## Example configuration
```yaml
- type: fonts
fonts:
nerd-fonts:
- FiraCode # don't add "Nerd Font" suffix.
- Hack
- SourceCodePro
- Terminus
- JetBrainsMono
- NerdFontsSymbolsOnly
google-fonts:
- Roboto
- Open Sans
```
The `fonts` module can be used to install fonts from [Nerd Fonts](https://www.nerdfonts.com/) or [Google Fonts](https://fonts.google.com/). This module will always download the latest version of a font and properly configure it.

16
modules/fonts/module.yml Normal file
View file

@ -0,0 +1,16 @@
name: fonts
shortdesc: The `fonts` module can be used to install fonts from Nerd Fonts or Google Fonts.
readme: https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/fonts/README.md
example: |
type: fonts
fonts:
nerd-fonts:
- FiraCode # don't add "Nerd Font" suffix.
- Hack
- SourceCodePro
- Terminus
- JetBrainsMono
- NerdFontsSymbolsOnly
google-fonts:
- Roboto
- Open Sans

20
modules/gschema-overrides/README.md
View file

@ -1,4 +1,4 @@
# `gschema-overrides` module for BlueBuild
# `gschema-overrides`
The `gschema-overrides` module can be used for including system-setting overrides for GTK-based desktop environments.
GTK-based desktop environments include Gnome, Cinnamon, MATE, Budgie & such.
@ -27,16 +27,7 @@ It is highly recommended to use `z1-` prefix before your gschema.override name,
Also don't forget to rename your file(s) too with this prefix in `/usr/share/glib-2.0/schemas`.
### Example configuration
```yaml
type: gschema-overrides
include:
- z1-myoverride.gschema.override
- z1-myoverride2.gschema.override
```
## Editing gschema.override files
## Creating gschema.override files
Gschema.override files use `gsettings` keyfile format for settings output.
@ -82,12 +73,13 @@ For that functionality, you should use `dconf-update-service` module.
Relocatable schemas are rare, so most users won't run into this scenario.
### Example of relocatable schemas
```
gsettings format:
```
[org.gnome.desktop.app-folders.folder:/org/gnome/desktop/app-folders/folders/Utilities/]
[org.gnome.settings-daemon.plugins.media-keys.custom-keybinding:/org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/custom0/]
```
dconf format:
```
[org/gnome/desktop/app-folders/folders/Utilities]
[org/gnome/settings-daemon/plugins/media-keys/custom-keybindings/custom0]
```
```

7
modules/gschema-overrides/module.yml Normal file
View file

@ -0,0 +1,7 @@
name: gschema-overrides
shortdesc: The `gschema-overrides` module can be used for including system-setting overrides for GTK-based desktop environments.
readme: https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/gschema-overrides/README.md
example: |
type: gschema-overrides
include:
- z1-myoverride.gschema.override # test & compile the override file /usr/share/glib-2.0/schemas/z1-myoverride.gschema.override

28
modules/rpm-ostree/README.md
View file

@ -1,34 +1,22 @@
# [`rpm-ostree`](https://coreos.github.io/rpm-ostree/) Module for Startingpoint
# `rpm-ostree`
The `rpm-ostree` module offers pseudo-declarative package and repository management using `rpm-ostree`.
The [`rpm-ostree`](https://coreos.github.io/rpm-ostree/) module offers pseudo-declarative package and repository management using `rpm-ostree`.
The module first downloads the repository files from repositories declared under `repos:` into `/etc/yum.repos.d/`. The magic string `%OS_VERSION%` is substituted with the current VERSION_ID (major Fedora version), which can be used, for example, for pulling correct versions of repositories from [Fedora's Copr](https://copr.fedorainfracloud.org/).
Then the module installs the packages declared under `install:` using `rpm-ostree install`, it removes the packages declared under `remove:` using `rpm-ostree override remove`. If there are packages declared under both `install:` and `remove:` a hybrid command `rpm-ostree remove <packages> --install <packages>` is used, which should allow you to switch required packages for other ones.
:::note
[Removed packages are still present in the underlying ostree repository](https://coreos.github.io/rpm-ostree/administrator-handbook/#removing-a-base-package), what `remove` does is kind of like hiding them from the system, it doesn't free up storage space.
:::
Additionally, the `rpm-ostree` module supports a temporary (waiting for `rpm-ostree` issue [#233](https://github.com/coreos/rpm-ostree/issues/233)) fix for packages that install into `/opt/`. Installation for packages that install into folder names declared under `optfix:` are fixed using some symlinks.
## Example Configuration
```yaml
type: rpm-ostree
repos:
- https://copr.fedorainfracloud.org/coprs/atim/starship/repo/fedora-%OS_VERSION%/atim-starship-fedora-%OS_VERSION%.repo # when including COPR repos, use the %OS_VERSION% magic string
- https://pkgs.tailscale.com/stable/fedora/tailscale.repo
install:
- python3-pip
- libadwaita
remove:
- firefox
- firefox-langpacks
```
## Known issues
When removing certain packages, some problem probably in upstream `rpm-ostree` causes a `depsolve` issue similar to below. [Removed packages are still present in the underlying ostree repository](https://coreos.github.io/rpm-ostree/administrator-handbook/#removing-a-base-package), what `remove` does is "hide" them from the system, it doesn't reclaim disk space.
When removing certain packages, some problem probably in upstream `rpm-ostree` causes a `depsolve` issue similar to below.
```
Resolving dependencies...done
error: Could not depsolve transaction; 1 problem detected:
Problem: conflicting requests
```
```

14
modules/rpm-ostree/module.yml Normal file
View file

@ -0,0 +1,14 @@
name: rpm-ostree
shortdesc: The rpm-ostree module offers pseudo-declarative package and repository management using rpm-ostree.
readme: https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/rpm-ostree/README.md
example: |
type: rpm-ostree
repos:
- https://copr.fedorainfracloud.org/coprs/atim/starship/repo/fedora-%OS_VERSION%/atim-starship-fedora-%OS_VERSION%.repo # when including COPR repos, use the %OS_VERSION% magic string
- https://pkgs.tailscale.com/stable/fedora/tailscale.repo
install:
- python3-pip
- libadwaita
remove:
- firefox
- firefox-langpacks

15
modules/script/README.md
View file

@ -1,16 +1,8 @@
# `script` Module for Startingpoint
# `script`
The `script` module can be used to run arbitrary scripts at image build time that take no or minimal external configuration (in the form of command line arguments).
The scripts, which are run from the `config/scripts` directory, are declared under `scripts:`.
## Example Configuration
```yaml
type: script
scripts:
- signing.sh
```
## Creating a Script
Look at `example.sh` for an example shell script. You can rename and copy the file for your own purposes. In order for the script to be executed, declare it in the recipe
@ -19,8 +11,7 @@ When creating a script, please make sure
- ...its filename ends with `.sh`.
- This follows convention for (especially bash) shell scripts.
- `autorun.sh` only executes files that match `*.sh`.
- ...it starts with a [shebang](<https://en.wikipedia.org/wiki/Shebang_(Unix)>) like `#!/usr/bin/env bash`.
- This ensures the script is ran with the correct interpreter / shell.
- ...it contains the command `set -euo pipefail` near the start.
- This will make the image build fail if your script fails. If you do not care if your script works or not, you can omit this line.
- ...it contains the command `set -euo pipefail` right after the shebang.
- This will make the image build fail if your script fails. If you do not care if your script works or not, you can omit this line.

7
modules/script/module.yml Normal file
View file

@ -0,0 +1,7 @@
name: script
shortdesc: The script module can be used to run arbitrary scripts at image build time.
readme: https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/script/README.md
example: |
type: script
scripts:
- myscript.sh # will run config/scripts/myscript.sh

4
modules/signing/README.md
View file

@ -1,3 +1,3 @@
# `signing` Module for Startingpoint
# `signing`
The `signing` module is used to install the required signing policies for cosign image verification with [`rpm-ostree`](https://github.com/coreos/rpm-ostree) and [`bootc`](https://github.com/containers/bootc). This module is the successor to the signing.sh script that previously existed in the template, and it allows for basing off of non-Universal-Blue Fedora base images.
The `signing` module is used to install the required signing policies for cosign image verification with [`rpm-ostree`](https://github.com/coreos/rpm-ostree) and [`bootc`](https://github.com/containers/bootc). This module is the successor to the `signing.sh` script that previously existed in the template. This module also allows for basing off of non-Universal-Blue Fedora base images.

5
modules/signing/module.yml Normal file
View file

@ -0,0 +1,5 @@
name: signing
shortdesc: The signing module is used to install the required signing policies for cosign image verification with rpm-ostree and bootc.
readme: https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/signing/README.md
example: |
type: signing # this sets up the proper policy & signing files for signed images to work fully

64
modules/systemd/README.md
View file

@ -1,63 +1,5 @@
# `systemd` Module for Startingpoint
# `systemd`
The `systemd` module streamlines the management of systemd units during image building. Units are divided into `system` and `user` categories, with `system` units managed directly using `systemctl` and `user` units using `systemctl --user`. You can specify which units to enable/disable or unmask/mask under each category.
The `systemd` module streamlines the management of systemd units during image building. Units are divided into `system` and `user` categories, with `system` units managed directly using `systemctl` and `user` units using `systemctl --global`. You can specify which units to enable/disable or unmask/mask under each category.
## Example Configuration
```yaml
type: systemd
system:
enabled:
- example.service
disabled:
- example.target
unmasked:
- example.service
masked:
- example.service
user:
enabled:
- example.timer
disabled:
- example.service
unmasked:
- example.service
masked:
- example.service
```
In this example:
### System Units
- `example.service`: Enabled (runs on system boot)
- `example.target`: Disabled (does not run on system boot, unless other unit strictly requires it)
- `example.service`: Unmasked (runs on system boot, even if previously masked)
- `example.service`: Masked (does not run on system boot, under any circumstances)
### User Units
- `example.timer`: Enabled (runs for the user)
- `example.service`: Disabled (does not run for the user, unless other unit strictly requires it)
- `example.service`: Unmasked (runs for the user, even if previously masked)
- `example.service`: Masked (does not run for the user, under any circumstances)
This configuration achieves the same results as the following commands:
```sh
# System Units
systemctl enable example.service
systemctl disable example.target
systemctl unmask example.service
systemctl mask example.service
# User Units
systemctl --global enable example.timer
systemctl --global disable example.service
systemctl --global unmask example.service
systemctl --global mask example.service
```
For more information about these systemctl commands, please visit:
https://www.freedesktop.org/software/systemd/man/latest/systemctl.html#enable%20UNIT%E2%80%A6
https://www.freedesktop.org/software/systemd/man/latest/systemctl.html#disable%20UNIT%E2%80%A6
https://www.freedesktop.org/software/systemd/man/latest/systemctl.html#unmask%20UNIT%E2%80%A6
https://www.freedesktop.org/software/systemd/man/latest/systemctl.html#mask%20UNIT%E2%80%A6
Supported operations are [enabling](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html#enable%20UNIT%E2%80%A6), [disabling](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html#disable%20UNIT%E2%80%A6), [masking](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html#mask%20UNIT%E2%80%A6%E2%80%A6) and [unmasking](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html#unmask%20UNIT%E2%80%A6).

23
modules/systemd/module.yml Normal file
View file

@ -0,0 +1,23 @@
name: systemd
shortdesc: The systemd module streamlines the management of systemd units during image building.
readme: https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/systemd/README.md
example: |
type: systemd
system:
enabled:
- example.service # Enabled (runs on system boot)
disabled:
- example.target # Disabled (does not run on system boot, unless other unit strictly requires it)
masked:
- example.service # Masked (does not run on system boot, under any circumstances)
unmasked:
- example.service # Unmasked (runs on system boot, even if previously masked)
user:
enabled:
- example.timer # Enabled (runs for the user)
disabled:
- example.service # Disabled (does not run for the user, unless other unit strictly requires it)
masked:
- example.service # Masked (does not run for the user, under any circumstances)
unmasked:
- example.service # Unmasked (runs for the user, even if previously masked)

15
modules/yafti/README.md
View file

@ -1,16 +1,7 @@
# [`yafti`](https://github.com/ublue-os/yafti) Module for Startingpoint
# `yafti`
The `yafti` module can be used to install `yafti` and set it up to run on first boot. Also `yafti`'s dependencies, `python3-pip` and `libadwaita` are installed.
The [`yafti`](https://github.com/ublue-os/yafti) module can be used to install [`yafti`](https://github.com/ublue-os/yafti) and set it up to run on first boot. Also `yafti`'s dependencies, `python3-pip` and `libadwaita` are installed.
Optionally, a list of Flatpak names and IDs can be included under `custom-flatpaks:`. These will be enabled by default under their own section on the Flatpak installation screen of `yafti`.
A default version of the `yafti` configuration file, `yafti.yml`, is supplied by this module. To make your own, create the file at `/usr/share/ublue-os/firstboot/yafti.yml`. The default version of the file can be found [here](https://github.com/ublue-os/bling/blob/main/modules/yafti/yafti.yml).
## Example configuration
```yaml
type: yafti
custom-flatpaks:
- Celluloid: io.github.celluloid_player.Celluloid
- Krita: org.kde.krita
```
A default version of the `yafti` configuration file, `yafti.yml`, is supplied by this module. To make your own, create the file at `/usr/share/ublue-os/firstboot/yafti.yml`. The default version of the file can be found [here](https://github.com/ublue-os/bling/blob/main/modules/yafti/yafti.yml).

8
modules/yafti/module.yml Normal file
View file

@ -0,0 +1,8 @@
name: yafti
shortdesc: The yafti module can be used to install yafti and set it up to run on first boot.
readme: https://raw.githubusercontent.com/ublue-os/bling/moduleyml/modules/yafti/README.md
example: |
type: yafti
custom-flatpaks:
- Celluloid: io.github.celluloid_player.Celluloid
- Krita: org.kde.krita