Package Details: coolercontrol 1.4.5-1

Git Clone URL: https://aur.archlinux.org/coolercontrol.git (read-only, click to copy)
Package Base: coolercontrol
Description: A program to monitor and control your cooling devices
Upstream URL: https://gitlab.com/coolercontrol/coolercontrol
Licenses: GPL-3.0-or-later
Conflicts: coolercontrol
Provides: coolercontrol
Submitter: codifryed
Maintainer: codifryed (caferen)
Last Packager: caferen
Votes: 34
Popularity: 2.94
First Submitted: 2023-02-07 21:45 (UTC)
Last Updated: 2024-12-15 19:28 (UTC)

Pinned Comments

codifryed commented on 2024-09-22 19:02 (UTC)

With the release of 1.4.1 CoolerControl has now been spit up into several packages. This requires users to uninstall and then reinstall the application.

See: https://gitlab.com/coolercontrol/coolercontrol/-/issues/347

There's an upside, there's now a binary AUR package coolercontrol-bin for less compile time!

codifryed commented on 2023-02-07 22:54 (UTC) (edited on 2024-01-06 23:57 (UTC) by codifryed)

Post-installation steps:

sudo systemctl enable --now coolercontrold

Then open the desktop application.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 12 Next › Last »

Millio commented on 2024-01-08 08:40 (UTC) (edited on 2024-01-08 08:41 (UTC) by Millio)

Failed on build with error

/usr/bin/python: No module named build

which I solved with 'pip install build'

thes1lv3r commented on 2024-01-02 11:03 (UTC)

Upgrading from 0.17.1-3 to 0.17.3-1:

error: failed to determine package fingerprint for build script for coolercontrold v0.17.3 (/home/xxxxxx/.cache/paru/clone/coolercontrol/src/coolercontrol-0.17.3/coolercontrold)

Caused by: failed to determine the most recently modified file in /home/xxxxxx/.cache/paru/clone/coolercontrol/src/coolercontrol-0.17.3/coolercontrold

Caused by: failed to determine list of files in /home/xxxxxx/.cache/paru/clone/coolercontrol/src/coolercontrol-0.17.3/coolercontrold

Caused by: failed to open git index at /home/xxxxxx/.cache/paru/clone/coolercontrol/.git/

Caused by: invalid data in index - calculated checksum does not match expected; class=Index (10)

blackhole commented on 2023-11-29 22:25 (UTC)

OK, removed the content of .npmrc and now installation is fine

codifryed commented on 2023-11-29 22:00 (UTC)

Hi @blackhole,
There is some info in this issue: https://github.com/nvm-sh/nvm/issues/2340
What I understand from that thread is that nvm and global prefixes are not compatible and really shouldn't be used.

If you don't need the prefix setting in your .npmrc, then just remove it.

I assume you get command not found because nvm is not installed. It is only a make dependency for coolercontrol so you probably have to install it before running that command, but I think you can get around it by just editing/removing the file yourself. The pkgbuild is using nvm in accordance with the Arch Wiki and seems to install fine otherwise.

blackhole commented on 2023-11-29 18:27 (UTC)

Cannot update it

Your user’s .npmrc file (${HOME}/.npmrc) has a globalconfig and/or a prefix setting, which are incompatible with nvm. Run nvm use --delete-prefix v18.18.2 to unset it. ==> ERROR: A failure occurred in prepare(). Aborting...

Using nvm use --delete-prefix v18.18.2 the result is command not found

hardfalcon commented on 2023-11-13 17:05 (UTC)

You're welcome :)

codifryed commented on 2023-11-13 17:02 (UTC)

ah, my bad, I misunderstood what any meant. I'll go ahead and adjust that.

Re: python upgrade. That's a good tip on bumping the pkgrel version and that's what I meant with upgrades in the past. It broke but users usually just rebuild the package which installed it in the new /usr/lib/3.xx folder. Not a great UX, but wasn't sure how that should best be handled.

Tested working with 3.12, for whenever it lands. :)

Thanks again for the info, much appreciated.

hardfalcon commented on 2023-11-12 21:07 (UTC) (edited on 2023-11-13 17:04 (UTC) by hardfalcon)

@codifryed: If you set the arch array in the PKGBUILD to any, the resulting package is wrongfully marked as being independent of a specific CPU architecture, although it does contain an ELF binary that can only be executed on the same CPU architecture as the machine on which you built the package. any should only be used for PKGBUILDs where also the resulting packages are completely independent of a specific CPU architecture (things like shell scripts, Python scripts, image/texture/map files for computer games, etc). If you want to make life easier for people using other CPU archirectures than x86_64, you could put multiple CPU architectures into the arch array, for example arch=('x86_64' 'i686' 'i486' 'pentium4' 'aarch64' 'armv7h' 'arm' 'armv6h'). Check here for more information: https://wiki.archlinux.org/title/PKGBUILD#arch

The coolercontrol package will break when the python package moves from Python 3.11.x to Python 3.12.x, because it contains Python libraries in the /usr/lib/python3.11 directory (when built on a system where the python package contains Python 3.11.x), whilst Python 3.12.x would expect them in /usr/lib/python3.12. Simply bumping the pkgrel and rebuilding the package would then (when Archlinux' python package contains Python 3.12.x instead of Python 3.11.x) probably be enough make the package compatible with Python 3.12.x (unless the coolercontrol contains specific code that is incompatible with Python 3.12.x, of course).

codifryed commented on 2023-11-12 19:34 (UTC) (edited on 2023-11-12 19:36 (UTC) by codifryed)

@hardfalcon thanks for the clarification.

Re: CPU Arch, there is no target architecture set in the rust build phase for the binary which means it will automatically build and link for whatever the host machine's architecture is. Even the major dependencies offer more than x86_64 arch, so I don't see why it should be limited to x86_64.

Can you explain what you mean by "the built package would clearly break if the python package was to be upgraded"? I just tried it out on 3.12 in a venv with up-to-date dependencies and every worked. I know that with python updates in the past the package needs to be rebuild anyway to install into the new 3.xx/site-packages folder, but that's not much of a surprise. Is there something I can improve there? ...Perhaps your script is reading the requirements in pyproject.toml, which are not adhered to for the Arch install. (Poetry Env)

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 12 Next › Last »