| 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: | 36 |
| Popularity: | 2.89 |
| First Submitted: | 2023-02-07 21:45 (UTC) |
| Last Updated: | 2024-12-15 19:28 (UTC) |
@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.
The release number. This is usually a positive integer number that allows to differentiate between consecutive builds of the same version of a package. As fixes and additional features are added to the PKGBUILD that influence the resulting package, the pkgrel should be incremented by 1. When a new version of the software is released, this value must be reset to 1. In exceptional cases other formats can be found in use, such as major.minor.
@hardfalcon Would it be more correct to use pkgrel=3 here, instead of pkgrel=2.1?
Thanks @hardfalcon !
I'll patch it up. The makefile and test-pkgbuild are very helpful for me for pre-release testing. Do you think it's ok if I move them to test branch in the repo?
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-binfor 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:
Then open the desktop application.