Arch Linux User Repository

Post-installation steps:

sudo systemctl enable --now coolercontrold

Then open the desktop application.

No, it says Admin Access and "Login" is inactive, only "Set New Password" is active. I have two errors

(WARN  coolercontrold::api] Failed to bind to loopback ipv6 address: Address family not supported by protocol (os error 97) because I blocked IPv6.

Second error

[2024-02-01T18:00:03Z ERROR coolercontrold::repositories::liquidctl::liqctld_client] Could not establish socket connection to coolercontrol-liqctld, retry #1 - No such file or directory (os error 2)
[2024-02-01T18:00:04Z ERROR coolercontrold::repositories::liquidctl::liqctld_client] Could not establish socket connection to coolercontrol-liqctld, retry #2 - No such file or directory (os error 2)
[2024-02-01T18:00:05Z ERROR coolercontrold::repositories::liquidctl::liqctld_client] Could not establish socket connection to coolercontrol-liqctld, retry #3 - No such file or directory (os error 2)
[2024-02-01T18:00:06Z ERROR coolercontrold::repositories::liquidctl::liqctld_client] Could not establish socket connection to coolercontrol-liqctld, retry #4 - No such file or directory (os error 2)
[2024-02-01T18:00:07Z ERROR coolercontrold::repositories::liquidctl::liqctld_client] Could not establish socket connection to coolercontrol-liqctld, retry #5 - No such file or directory (os error 2)
[2024-02-01T18:00:08Z ERROR coolercontrold] Error initializing LIQUIDCTL Repo: Failed to connect to coolercontrol-liqctld after 5 tries

I tried on VM and I get warning that connection to a CoolerControl daemon could not be established. Why there are openrc service files for Coolero on the flathub but not here?
Coolercontrold
Coolercontrol-liquidctl-daemon

I use portmaster so maybe there is some more security toward loopback but I haven't found any settings.

@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.