Arch Linux User Repository

@qubit Good find. Yes, /usr/lib/python3/dist-packages is a Debian/Ubuntu specific path. Python packages built for Arch Linux should be installing into /usr/lib/python3.14/site-packages (Python version changed as appropriate). I forgot our meson.build makes this assumption.

So yes, that's something the maintainer of that package should consider addressing. I haven't looked deeper into their package, but the package can't be integrating well if Python doesn't pick up that path:

python -c "import sys; print(sys.path)"

@lah7 Thanks for the quick reply. I think I found the root cause of my issue in one of the comments on the polychromatic repo, specifically here: https://github.com/polychromatic/polychromatic/issues/543#issuecomment-2748325367

I have one other package from the AUR (https://aur.archlinux.org/packages/timekpr-next) that installs in /usr/lib/python3/dist-packages and this is causing the meson build to also install in that directory. Should I flag this as an issue with the maintainer of the timekpr-next package?

@qubit Most likely: your Python environment is contaminated with paths pointing to the wrong places or a non-system version of Python is installed. These will interfere with building the package and running the program. Check your PATH, PYTHONPATH, home and /usr/local folder for any local installations of Python and delete them.

There's closed issues on the polychromatic repo investigating issues like that which may provide some clues. Likewise, the Polychromatic release notes provide a copy of a working tar.zst package, but it still won't run (ImportError, ModuleNotFound) if your Python environment is polluted with Python installations outside of pacman.

I'm getting the same errors as @patri9ck . I have already tried a full rebuild but that does not solve the issue. It seems like the package gets installed in /usr/lib/python3/dist-packages which does not seem to be part of the default sys.path of the latest python release on Arch (3.14.4-1). Not sure if this is something that changed recently or if has been broken for a while since I don't use the program frequently. Is anyone else experiencing this?

@Roken Looks like Python 3.12 rebuilds are in the testing repositories: https://gitlab.archlinux.org/archlinux/packaging/packages/python-colour/-/commit/41c52d5de453725bb84f0d945dd594c769567a33

If you are using the '-testing' repos, see if all three are enabled in /etc/pacman.conf and placed before the stable repos. I was able to upgrade, clean build and start the app using the Python 3.12 (testing) packages just fine.

python-colour 1.5-13 breaks this. Downgrade to 1.5-12 fixes. Rebuilding the package didn't help.

@polyzen Dependencies updated. It was around v0.7.0 when 'python-openrazer' became optional as the project prepared to be more vendor-agnostic. Makes sense to put it back as a hard dependency until such development is done.

The software can still start without 'python-openrazer' present, although those scenarios may be less likely now that OpenRazer packages are in the official Arch repos!

Seems python-openrazer should be a hard dep and not just an optdep.

@patri9ck Python has been recently updated in the repositories (3.10 => 3.11). You must perform a clean rebuild of the package so it installs inside the correct Python modules folder.

Repeat this for any other Python-based AUR packages (like OpenRazer):

pacman -Qo /usr/lib/python3.10

Getting this when launching polychromatic-cli or polychromatic-controller:

$ polychromatic-cli           
Traceback (most recent call last):
  File "/usr/bin/polychromatic-cli", line 30, in <module>
    import polychromatic.base as base_class
ModuleNotFoundError: No module named 'polychromatic'

Installed via paru, reinstalling did not help.