Arch Linux User Repository

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!

Post-installation steps:

sudo systemctl enable --now coolercontrold

Then open the desktop application.

@texer22 Hmmm. If you open the Access Protection menu in the top right - and if it says "Guest" - try clicking on Log In to see if it then logs you in automatically.

Unfortunately, I can't reproduce your issue. I even fired up a fresh Artix install in a VM and both UIs connect and work fine. (Firefox for the Web UI) Do you have some extra security setup for your loopback interface by any chance?

@codifryed Ok, the alternative works for me! Thanks. Now, I cannot login and add any new profiles. It says "invalid credentials".

@texer22 That looks like the Desktop App coolercontrol isn't able to find a free port on your system to render the UI, and I'm not sure why.

As an alternative, once you have coolercontrol-liqctld and coolercontrold running on Artix you can open the daemon Web UI at http://localhost:11987/

Cleaned up the make deps a bit and tested in a chroot.

I think that you should not add base-devel and maybe some other packages to makedepends

If people is installing coolercontrol with some AUR helper with the option to remove makedepends packages, also archlinux-keyring, appmenu-gtk-module (for Plasma) will be removed.

Ok, I can see that and makes good sense what you're saying, especially for official packages, which is perhaps what you're getting at.

I guess it's a bit confusing as the different docs and pkgbuilds are not very clear, at least to me. (i.e. The nodejs packaging guidelines suggest using nvm, and the package has no runtime node dependency similar to other aur pkgbuilds that also use nvm)

All good, learning never stops, changes pushed.

@codifryed: In that case, just use nodejs>=18 as a dependency, since both nodejs-lts-hydrogen and nodejs-lts-iron provide nodejs as well.

As a general rule, my advice would be to not design a PKGBUILD for building inside a user's regular desktop system, because that's the wrong way to build packages anyway. Packages built that way will often incur unwanted dependencies simply because ./configure scripts will often automatically enable features if they recognize that the dependencies needed for that specific feature is installed/available at compile time (and those unwanted depdencies won't even be listed in the package's metadata, thus making it even more error-prone to re-use the built package on other machines than the one on which it was compiled). The proper way to build a package from a PKGBUILD is to use a clean chroot, and there's a dedicated script to do just that:

https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot

Also, needlessly using AUR packages as build-time dependencies makes it a lot more difficult to build the package using the "clean chroot" method, because with the nvm dependency, the user would need to setup their own package repo on a webserver, create their own config file in /usr/share/devtools/pacman.conf.d/ and their own corresponding symlink to /usr/bin/archbuild (comparable to symlinks like /usr/bin/extra-x86_64-build or /usr/bin/multilib-build).

Thank you both. @hardfalcon @thes1lv3r

One concern that arose when testing this is with the nodejs-lts replacement of nvm, is that it then forces users to downgrade their installed version of nodejs, if it's there, which seems pretty sub-optimal. Originally I used the nvm way, not only because I saw other apps taking advantage of it, but also to help produce consistent builds separate from what nodejs package the user had installed.

That being said, I doesn't Have to be 18.x.x and it will install fine with the latest nodejs at 21.x.x, aka by just having npm as a dependency. It just can't be less than 18.x.x. to build properly.

@codifryed: Oh sorry, I wasn't aware you were actually using those files. In that case, just keeping them should be okay (though I'd still recommend removing the executable bit on both PKGBUILDs since it's not needed). Tbh, I don't know if it is possible to add a custom branch, or what implications/side effects that might have, because I've never tried that.

@thes1lv3r: You're right, for the AUR package, this should be 3 and not 2.1. I routinely use major.minor format pkgrel numbers in my private repo when I modify/update existing packages for release engineering purposed, because this makes it easier to switch back to "official" Archlinux packages when I remove packages again from my repo (for example because the desired changes have been adopted by the respective Archlinux package maintainer). I had simply forgotten to change the 2.1 to 3 before creating the diff that I posted here.