Arch Linux User Repository

@laichiaheng - kodi is bound to a specific version of ffmpeg which is generally older than Arch's package. We avoid incompatibilities by using that specific version (ie internal ffmpeg). Recommend that you build kodi in clean chroot. See: https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot

I wrote a script that automates much of that called clean-chroot-manager offered here in the AUR.

So I should change this line: source=('kodi-addon-inputstream-adaptive-git::git+https://github.com/peak3d/inputstream.adaptive.git#branch=Krypton')

to

source=('kodi-addon-inputstream-adaptive-git::git+https://github.com/peak3d/inputstream.adaptive.git#branch=Leia') ?

@chuck123 Look at the PKGBUILD of the AUR package you linked - you have to modify the source link to build it for Kodi 18.

Why isn't inputsream-adaptive included? On Windows and for example Ubuntu inputsream-adaptive is always included in the latest Kodi 18 builds. How can I add it? The one which is available in the aur is only for Kodi 17+ https://aur.archlinux.org/packages/kodi-addon-inputstream-adaptive-git/. Could soneone help me out here. I need it for addons like DAZN and Eurosport Player. Thanks.

libfmt-git doesn't build for me, however fmt does and it seems to fill the dependency. Also, rapidjson in the repos has a high enough version number.

@Throne3d I thought about it, but I don't really like this solution. The way how I understand it, to prevent a warning of downgrading, now and in the future, I would have to maintain the "epoch" (removal will restore the value to 0) - what I'm not really up to ;)

You should not use epoch for AUR packages, the mention of the maintainer is sufficient, you should read the comments anyway when using packages from AUR

I've noticed other packages use the "epoch" variable in the PKGBUILD file to prevent warnings about downgrades. The wiki mentions it – https://wiki.archlinux.org/index.php/PKGBUILD#epoch – but gives a warning that "epoch should only be used when absolutely required to do so", and I'm not sure if this is in fact one such situation. It might be worth looking into? Edit: also, though you may not care about such a minor thing: in the pkgver function, the echo line seems to have a trailing space (i.e. it's currently written 'echo "$_major.$_minor.$_revision" ', with the space at the end), which shows up rather noticeably when using git diff.

The version format has changed, ignore the warning about downgrading package. The new format is recommended by ArchWiki [1] and is following: RELEASE.rREVISION where REVISION is a number of revisions since beginning of the history. [1] https://wiki.archlinux.org/index.php/VCS_package_guidelines#The_pkgver.28.29_function

My pkgver uses this for kodi-git printf "%s.%s.r%s.%s\n" "$(grep 'VERSION_MAJOR' version.txt | sed 's/[^0-9\.]*//g')" "$(grep 'VERSION_MINOR' version.txt | sed 's/[^0-9\.]*//g')" "$(git describe --tags --long | cut -d '-' -f 3)" "$(git rev-parse --short HEAD)" result: 18.0.r4271.75bddb4e05

First of all, I'd like to thank BlackIkeEagle for all the work. I'll do my best to keep it on track. Second, I wonder if there's a specific reason why we don't use recommended version format: RELEASE.rREVISION? [1]. Git tags won't work, but we can easily use version.txt [2]. It may look like this: _major=$(cat version.txt | grep "VERSION_MAJOR" | sed 's/VERSION_MAJOR //') _minor=$(cat version.txt | grep "VERSION_MINOR" | sed 's/VERSION_MINOR //') _revision=$(printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)") echo "$_major.$_minor.$_revision" And last but not least: @graysky Thanks for pointing it out - it's already updated. [1] https://wiki.archlinux.org/index.php/VCS_package_guidelines#The_pkgver.28.29_function [2] https://github.com/xbmc/xbmc/blob/master/version.txt