Unable to run app image on Fedora 42 KDE

[johangwbasson]

Version: v2025.8.10.0

When i run the app image I get this stack trace:

 ./OSCR-x86_64.AppImage       
Traceback (most recent call last):
  File "/tmp/.mount_OSCR-xgjhGCb/opt/python3.13/bin/oscr", line 8, in <module>
    sys.exit(Launcher.launch())
             ~~~~~~~~~~~~~~~^^
  File "/tmp/.mount_OSCR-xgjhGCb/opt/python3.13/lib/python3.13/site-packages/main.py", line 830, in launch
    exit_code = OSCRUI(
                ~~~~~~^
            theme=Launcher.theme, args=args,
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            path=Launcher.base_path(), config=Launcher.app_config(),
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            versions=(Launcher.__version__, Launcher.version)).run()
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/.mount_OSCR-xgjhGCb/opt/python3.13/lib/python3.13/site-packages/OSCRUI/app.py", line 93, in __init__
    self.init_parser()
    ~~~~~~~~~~~~~~~~^^
  File "/tmp/.mount_OSCR-xgjhGCb/opt/python3.13/lib/python3.13/site-packages/OSCRUI/app.py", line 186, in init_parser
    self.parser = OSCR(settings=self.parser_settings)
                  ~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/.mount_OSCR-xgjhGCb/opt/python3.13/lib/python3.13/site-packages/OSCR/main.py", line 50, in __init__
    reset_temp_folder(self._settings['templog_folder_path'])
    ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/.mount_OSCR-xgjhGCb/opt/python3.13/lib/python3.13/site-packages/OSCR/iofunc.py", line 119, in reset_temp_folder
    os.mkdir(path)
    ~~~~~~~~^^^^^^
OSError: [Errno 30] Read-only file system: '/tmp/.mount_OSCR-xgjhGCb/opt/python3.13/lib/python3.13/site-packages/~temp_log_files'

It was run from my home directory in Fedora.
I have checked the SHA and it matches.

[Shinga13]

Sorry for the inactivity here, I don't regularly check the GitHub Issues page. For quicker answers I suggest joining the STOBuilds Discord. https://discord.gg/kxwHxbsqzF

Regarding the issue, I'd have to do some research, because I don't know what could be causing the issue yet.

[PsychedelicShayna]

Hey! So, this is related to an issue that was recently fixed, but AppImage is not out yet, nor has PyPi been updated, but the PR for Python 3.13 compatibility has been merged.

The culprit is Python 3.13 being incompatible with cx_Freeze version 7.1.0-post0 which has recently been bumped to 8.0.0 and works fine now.

By the time you read this, the release will probably be out, but for the moment you can clone the repository yourself, and run pip install . then run oscr from the terminal.

In the case of an externally managed python environment (unsure if Fedora is subject to that, but Arch is)

git clone https://github.com/STOCD/OSCR-UI.git
cd ./OSCR-UI
python -m venv .venv
source .venv/bin/activate # For bash, activate.fish for Fish, or whatever shell you use. 
pip install .
oscr

Caveat being you'll only be able to run oscr if you have the virtual environment sourced.

[johangwbasson]

I can confirm that the 'OSCR-UI-x86_64-LinuxBinary.tgz' version 2025.9.14.1 is working on Fedora 42. Thank you very much

I tried the AppImage, but got this error:

Traceback (most recent call last):
  File "/tmp/.mount_OSCR-xHpGbKL/opt/python3.13/bin/oscr", line 8, in <module>
    sys.exit(Launcher.launch())
             ~~~~~~~~~~~~~~~^^
  File "/tmp/.mount_OSCR-xHpGbKL/opt/python3.13/lib/python3.13/site-packages/main.py", line 830, in launch
    exit_code = OSCRUI(
                ~~~~~~^
            theme=Launcher.theme, args=args,
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            path=Launcher.base_path(), config=Launcher.app_config(),
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            versions=(Launcher.__version__, Launcher.version)).run()
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/.mount_OSCR-xHpGbKL/opt/python3.13/lib/python3.13/site-packages/OSCRUI/app.py", line 93, in __init__
    self.init_parser()
    ~~~~~~~~~~~~~~~~^^
  File "/tmp/.mount_OSCR-xHpGbKL/opt/python3.13/lib/python3.13/site-packages/OSCRUI/app.py", line 186, in init_parser
    self.parser = OSCR(settings=self.parser_settings)
                  ~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/.mount_OSCR-xHpGbKL/opt/python3.13/lib/python3.13/site-packages/OSCR/main.py", line 50, in __init__
    reset_temp_folder(self._settings['templog_folder_path'])
    ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/.mount_OSCR-xHpGbKL/opt/python3.13/lib/python3.13/site-packages/OSCR/iofunc.py", line 119, in reset_temp_folder
    os.mkdir(path)
    ~~~~~~~~^^^^^^
OSError: [Errno 30] Read-only file system: '/tmp/.mount_OSCR-xHpGbKL/opt/python3.13/lib/python3.13/site-packages/~temp_log_files'

[PsychedelicShayna]

Great to hear! It seems the new way of packaging it for Linux has been a resounding success so far! That's another distro I can check off the list.

I could consider this a closed issue, the title is technically still not wrong, AppImages do not work.

Even though we're most likely going to end up moving forward with the precompiled binary + an install script route, I'd like to address the root cause of why the AppImage is not working.

My Train of Thought

---

It seems to be the same issue every time, and it's not like the error does not make sense. AppImages create their own little filesystem in memory, mimicking the host filesystem without actually touching it, and runs whatever it needs to run from within that context.

It's not too dissimilar from a Docker container in principle, just significantly lighter and less complex, and with a different purpose in mind.

So the permissions on the host filesystem are actually irrelevant. It's a permission issue within the virtual filesystem

I just wonder when this started becoming a problem. AppImages of OSCR-UI had to have worked at some point.

Is it merely because it's writing to /tmp where before it didn't? Can you not write to /tmp in an AppImage? How do AppImages that actually function manage to function at all when they need to interact heavily with the host filesystem, including /tmp?

Extracting the AppImage, and running AppRun directly works without any problems, so it's not the contents of the AppImage directly, but rather the contents + the way in which it is being executed when running it as an AppImage.

Looking into historical commits and releases, as well as comparing it with other AppImages and how they're laid out might shine more light on it.

[Shinga13]

Regarding your train-of thought: The AppImage was a work-in-progress that has never been completed, so it's entirely possible it worked only in part.