Arch Linux User Repository

@dalu you need Kodi 20 to build it.

Build errors galore with the 20.6.0-1 package https://pastebin.com/WDsT40Zz

Currently outdated / not yet updated to Nexus (v20)

pamac install kodi-addon-pvr-hts

would be much easier to install the addon.

Just want to leave these instructions for anyone (like me) new to AUR Packages:

To install "kodi-addon-pvr-hts 19.0.6-1" I had Kodi 19.4.0 that I installed from Add/Remove Software in Manjaro (pamac)

From command line I created a working directory in my home folder then...

cd /home/flex/kodi

git clone https://aur.archlinux.org/kodi-addon-pvr-hts.git

makepkg

At this point I was told that I was missing the dependencies: cmake, kodi-platform and kodi-dev

I installed these again using the Add/Remove Software utility in Manjaro (you could also use pamac or pacman)

If the make (compilation) is successful you will get a bunch of files in that directory you git cloned to. One such file is: kodi-addon-pvr-hts-19.0.6-1-x86_64.pkg.tar.zst

I right clicked on that from Manjaro Dolphin File Explorer and selected: "Open with Software Installer" and this installed the package into /home/flex/.kodi/addons/packages/

I then rebooted the computer and when I restarted Kodi it asked me if I wanted to enable the HTSP Client Add-on to which I said yes and then could configure it and it works!

well not with starting kodi, though takes long, starts but keeps crashing after a while

Anyone else having issues starting kodi with this package installed?

I still have kodi version 18.9 installed and the latest version 8.2.2 of this addon fails to build against kodi 18.9 obviously. So the dependencies should be extended to contain a version if kodi 19.0 is required at minimum.

@willemw: It's not a problem to use VCS sources if you guarantee to actually fetch that version (usually by targetting the specific release tag). The official kernel package actually does just that. However it's usually preferred to use tarballs, because these a) can be checksummed easily and b) are often signed contrary to (often) unsigned git tags. And also, you don't fetch the entire development history when downloading a tarball (which is especially relevant for large projects, not so much this addon).

@AlD: Two issues with that.

1. You're targetting the current branch tip, which will change whenever upstream releases something and thus does not fit the above criteria (i.e. #branch=Leia always refers to the newest version of the package, not what is defined by $pkgver). This behaviour is only desired in VCS packages.
2. This has led to $pkgver and the upstream version drifting out of sync, which is against Arch's packaging standards. That isn't really an immediate problem just in terms of pacman detecting upgrades, but it will probably lead to confusion if anyone wants to make a bug report ("I have v4.4.21 installed from the AUR" - "But the current version is v4.4.20 ..." -- and that's the harmless case).

I suggest that, when upstream releases the next version (assuming that is going to be 4.4.21), you only bump $pkgrel to get $pkgver back in sync, and in that same commit change the source=() to refer to something like #tag=$pkgver-$_kodi_branch, with $_kodi_branch=Leia replacing the (now obsolete) $_gitver. (Alternatively change the git source to use the Github-generated tarballs, but that's mainly a thing of package maintainer's preference.)

I can prepare a patch to the PKGBUILD tomorrow if I wasn't clear enough on what I meant. :)