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.

I tried again, still working on my end. Lets see if anyone else will have this issue over time.

Just to note: if you ran yay -Sc while coolercontrol was installed, then that wouldn't clear coolercontrol's cached packages. You should either run yay -Scc (this would clear all packages' cache, installed or not) or uninstall coolercontrol before running yay -Sc.

Also, it looks like your error is related to DNS resolution. If you can access gitlab.com on your browser, I suggest trying to curl it on the terminal. Your browser might be using a different DNS resolver.

@caferen Thank you for the extremely timely response. I am using an aur helper, i was using yay to install the package, and I just did yay -Sc and tried to rebuild it but it ended up in the same error. I really am not sure what the issue is, but as I previously mentioned I simply commented out the "appstream-util validate-relax "packaging/metadata/$_app_id.metainfo.xml"" check and it compiled and built fine. I guess its just one of those works for me, but not for you bits haha. In any case, I could just add this to ignorePkg and manually update it with new releases. Btw, props on the project guys, it really is a cool app, and the issue made me look at the gitlab, cctv seems like a very cute utility add to a rice!

hi @aequilibrium, the url is accessible on my end too and I can't reproduce the issue.

How are you installing the package? If you're using an AUR helper, it sometimes helps to clear the cache.

I suggest first trying to install the application manually and if that also does not work, opening an issue on the repository so we can have a look at the full output.

Im having the following issue, I commented out the relevant appstream check or whatever and compiled it, but I dunno how'd fix it, might be some ddos mitigation on the part of gitlab thats causing it? Because the url is valid and accessible afaik. ==> Starting check()... packaging/metadata/org.coolercontrol.CoolerControl.metainfo.xml: FAILED: • url-not-found : <screenshot> url not valid [https://gitlab.com/coolercontrol/coolercontrol/raw/main/screenshots/coolercontrol-overview.png]: Resolving timed out after 5001 milliseconds Validation of files failed ==> ERROR: A failure occurred in check(). Aborting... -> error making: coolercontrol-exit status 4 -> Failed to install the following packages. Manual intervention is required:

Thanks for the report @starquake. After some internal discussion and analyzing other packages, we've decided not to add qt6-wayland as an explicit dependency for three reasons:

1- The need for qt6-wayland is documented in the wiki as part of setting up Wayland:

https://wiki.archlinux.org/title/Wayland#Qt

2- It is a completely useless package for many X11 users.

3- qt6-base, which we already depend on, already optionally depends on it.

I will instead document the need in our installation guidelines.

I had to install qt6-wayland to make it start:

2025-04-09T18:56:10 coolercontrol WARN [qt.qpa.plugin]: Could not find the Qt platform plugin "wayland" in ""

2025-04-09T18:56:10 coolercontrol WARN [default]: GBM is not supported with the current configuration. Fallback to Vulkan rendering in Chromium.

2025-04-09T18:56:10 coolercontrol FATAL [default]: GLX: Failed to find frame buffer configuration.

I'm using GNOME so it doesn't come with my DE.

Maybe add it as a dependency?

gosh, cannot wait for this to land in extra.

Please keep comments restricted to packaging issues and report bugs on the repository.

It still does not recognize the LEDs on the Nvidia video card or the LEDs on the Cosair RAM memory

1) to reduce build times and 2) allow independent installation of the daemon which will officially only optionally depend on the other two packages as of v2.0. AFAICT, split packages serve neither of these purposes, please correct me if I'm wrong.

For the first point, it will reduce build time only for the people that don't want the full program, otherwise it would slightly increase it. As for the second, instead of makepkg -Ccfi, using simply makepkg -Ccf and selectively installing with makepkg -U achieves the same result as splitting it into multiple PKGBUILDs. Most AUR helpers can also do it this way if instructed to install only one package from a single split PGKBUILD. That being said, the a split PKGBUILD will take longer to build indeed.

Isn't it possible to clear an existing chroot and build another package in it? I am not familiar with paru.

The way makepkg chroots work, is that there is a "pristine" chroot, which serves as a base system with only base-devel installed normally. This is also referred to as the root chroot in the wiki. When makechrootpkg is invoked, the root chroot is cloned into a working chroot and the working chroot gets updated and the PKGBUILDs dependencies are installed into it. In in the case of multiple PKGBUILDs, this process of copying, updating and installing dependency packages in the working chroot, happens for each PKGBUILD individually.

This is also a little self-serving from my part, as I build packages in Arch linux docker containers through GH Actions, a single split PKGBUILD would require only a single instance instead multiple.