include sddm2rpm in recommendations for changing the sddm login screen

[boredsquirrel]

Currently the only thing you can overwrite are RPMs, removing or adding them.

There is a hack for SDDM login screens, this awesome tool. It creates working RPMs that only contain an addition to the exact folder, to place the SDDM theme there.

We could fork that project and add icons, or other changes like that.

Goal is to avoid needing to build the system ourself, as using these tools and local rpm-ostree overwrites, we dont have to provide the service

[iaacornus]

Currently the only thing you can overwrite are RPMs, removing or adding them.

i think we dont have to overwrite anything, we just need to layer things, such as the sddm2rpm in this case, since overwrite <action> is for tasks relating to the base image.

There is a hack for SDDM login screens, this awesome tool. It creates working RPMs that only contain an addition to the exact folder, to place the SDDM theme there.

We could fork that project and add icons, or other changes like that.

im not sure why we should fork it, we can just include it in the options to be installed in the user $PATH, then the user can just use it.

Goal is to avoid needing to build the system ourself, as using these tools and local rpm-ostree overwrites, we dont have to provide the service

[boredsquirrel]

my mistake, install not overwrite.

Fork because the person doesnt use Silverblue anymore I guess? But I wrote with her and she is pretty active. Also told me that you cant apply the sddm fix to other settings, as KDE stores settings differently.

The sddm2rpm is also on https://crates.io/crates/sddm2rpm so we dont need to build it manually.

[iaacornus]

my mistake, install not overwrite.

Fork because the person doesnt use Silverblue anymore I guess? But I wrote with her and she is pretty active. Also told me that you cant apply the sddm fix to other settings, as KDE stores settings differently.

there has been no change about building rpm after all, maybe it still works, if it does, then we dont need to fork it

The sddm2rpm is also on https://crates.io/crates/sddm2rpm so we dont need to build it manually.

[boredsquirrel]

import subprocess

command = "distrobox enter fedora --exec=cargo add sddm2rpm"

try:
    output = subprocess.check_output(command.split())
    print(output.decode())
except subprocess.CalledProcessError as error:
    print(f"Error: {error}")

does this work?

[boredsquirrel]

problem: when installing distrobox, this needs to be ran in the startup script. Maybe we can just add a small Guide on how to use custom SDDM themes manually?

How to use custom SDDM themes on Fedora Kinoite / OpenSuse microOS

Use a Distrobox or Toolbox container for this.

1. Install sddm2rpm

sudo dnf install -y cargo
cargo add sddm2rpm

add "sddm2rpm" and all other cargo packages to your Path, making it directly executeable:

printf """
export PATH=/var/home/user/.cargo/bin/:$PATH""" >> ~/.bashrc

2. Download an SDDM theme you like

Go to The KDE Store or the Pling Store and download and SDDM archive you like.

It has to be a .tar.* archive, not a .zip.

Open a Terminal in the download directory and run

sddm2rpm name-of-theme.tar.gz

Install the Theme

layer the rpm: Open the Terminal in the location of the new created RPM

reboot```

(on openSuse microOS you would use `transactional-update install pkg theme.rpm`)

After rebooting go to the KDE settings, it will appear there.

[boredsquirrel]

we could just open this site with the reboot script.

[iaacornus]

import subprocess

command = "distrobox enter fedora --exec=cargo add sddm2rpm"

try:
    output = subprocess.check_output(command.split())
    print(output.decode())
except subprocess.CalledProcessError as error:
    print(f"Error: {error}")

does this work?

I've provided a module which does execute a system command using subprocess and handles the exceptions and logging

from src.utils.shared.exec import exec_cmd

which provides:

def exec_cmd(
        log: Logger,
        cmd: list[Any],
        verbose: bool = False,
        break_proc: bool = False,
        pipe_: bool = False,
        init_cmd: Optional[list[Any]] = None
    ) -> NoReturn | None | str:
    """For command execution/system calls with error handling

    Args:
        log -- Logger instance
        cmd -- command to execute with arguments
        verbose -- whether to show command output or not
        break_proc -- whether to raise systemexit or not
        pipe_ -- whether to pipe a command or not
        init_cmd -- initial command to be piped to the main command

    Returns:
        None, the output of the command or raise system exit
    """

[iaacornus]

with this you can simply just call the function, provide the command (a list of str e.g., for ls -l the argument is ["ls", "-l"]) to execute, as well as some of the required variables: the instance of logger for log.