On latest tumbleweed (20250329) quodlibet won’t start anymore
(the last one that i know where the fault was not was 20250103)
This is the fault message:
XX@XX-openSUSE:~> quodlibet
Traceback (most recent call last):
File “/usr/bin/quodlibet”, line 11, in
from quodlibet.main import main
File “/usr/lib/python3.13/site-packages/quodlibet/init.py”, line 21, in
from .util.i18n import , C, N_, ngettext, npgettext
File “/usr/lib/python3.13/site-packages/quodlibet/util/init.py”, line 28, in
from senf import fsnative
ModuleNotFoundError: No module named ‘senf’
Neither quodlibet itself nor this module are provided by the openSUSE Tumbleweed. You apparently installed them from some other source, in which case you need to explain how you did it.
Educated guess - you installed it using the previous Python version and now you need to reinstall it under the current Python 3.13.
And please, use preformatted text to post computer output so it remains properly aligned and readable.
Also python-senf is not available in OpenSuse so you installed that likely using pip.
I had also at least 2 python scripts that were non longer working after the switch to python13. What was new for me is that for python13 pip did not longer want to install packages along the system packages:
$ pip install senf
[notice] A new release of pip is available: 24.3.1 -> 25.0.1
[notice] To update, run: pip install --upgrade pip
error: externally-managed-environment
× This environment is externally managed
╰─> To install Python packages system-wide, try
zypper install python313-xyz, where xyz is the package
you are trying to install.
If you wish to install a non-rpm packaged Python package,
create a virtual environment using python3.13 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip.
If you wish to install a non-rpm packaged Python application,
it may be easiest to use `pipx install xyz`, which will manage a
virtual environment for you. Install pipx via `zypper install python313-pipx` .
note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
So I did what was advised and created a virtual env for each script and installed things there, that works fine. Not sure if I like it that way so I might do something like the last line suggests, overriding things.
Yes, pip3 from a specific Python version installs Python modules for this specific version. You need to remove modules for older version using the old version pip3 and install again using the new version pip3 (unless you want to keep both old and new).
One need to be careful here. Creating a virtual environment must be done using the explicitly versioned Python binary, like python3.13. Using just python3 will result in the environment that points to the /usr/bin/python3 and it will change next time the default Python version is advanced.
You’ve installed from someone’s home: repository - those are generally considered experimental, personal projects. If you want them to fix it, you need to contact the user who created it. It’s not part of the ‘official’ distro packages.
So that will cease working when python3.13 is deprecated leaving this virtual environment non-operation it looks to me. That is why I am so happy with it and considering the override.
I’m now a SuSE / openSUSE user for 21 years.
tumbleweed comes in my life around 8 years now, i’m very interested to make this community great and usefull. my personel life of the last 10 years maked that i’m not able to bug things out.
so i understand this, that it’s better to contact the maintainer of the repo, but where is the spirit of the community. in this topic i get two times the door in front of me.
I have a workaround for my problem (flatpak), but maby with “telling” my problem to other ones will follow a good solution, that showing also on my topic for the moment…
Sure, the community is here to help - but in this particular instance, the maintainer of the repo you chose to use is probably the best person to help. We don’t have the context of what led them to build the code you’re using, if they ever intended to maintain it, or anything.
As a user with so much experience with openSUSE, you should be aware that using packages home: repos comes with risks and potential problems.
My purpose in pointing you in that direction is that (a) I have no way of knowing what your experience is, and (b) getting you to the fastest possible resolution by suggesting you contact the owner of the repo to see if they have a solution in the works, or if they’ve abandoned it altogether.
Another option would be to fork the package and build it in OBS yourself, or to see if someone else is interested in doing that.
What exactly do you expect from the community in this case?
The problem is not quodlibet itself (which still builds and is published) but the senf Python module that is not present in this repository and you still did not tell us where you installed it from nor how. As long as you withhold information from community do not blame community for not being able to do anything.
how can i check this in the correct way?
i don’t see any rpm of senf i both systems
i have a tumbleweed system with working quodlibet and one updated to the latest version where quodlibet is broken.
