Package Details: kodi-git r67025.2e06c189dd88-1

Git Clone URL: https://aur.archlinux.org/kodi-git.git (read-only, click to copy)
Package Base: kodi-git
Description: A software media player and entertainment hub for digital media (master branch, gles renderer)
Upstream URL: https://kodi.tv
Licenses: GPL2
Conflicts: kodi, kodi-gbm, kodi-gles, kodi-wayland, kodi-x11
Provides: kodi-common, kodi-gbm, kodi-wayland, kodi-x11
Submitter: BlackIkeEagle
Maintainer: graysky
Last Packager: graysky
Votes: 85
Popularity: 0.001119
First Submitted: 2014-10-23 06:38 (UTC)
Last Updated: 2024-11-13 19:34 (UTC)

Pinned Comments

graysky commented on 2022-06-11 11:49 (UTC)

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

Latest Comments

« First ‹ Previous 1 .. 39 40 41 42 43 44 45 46 47 48 49 .. 54 Next › Last »

<deleted-account> commented on 2012-01-14 17:03 (UTC)

Build was failing for me when I had Bluez 4.97 installed, I haven't tried it with 4.98 yet.

Huulivoide commented on 2012-01-05 15:18 (UTC)

But I still don't undestand why isin't the building of debugging symbols disabled, as those get removed anyhow.... as faar as I know one should put --disable-debug into the PKGBUILD, if debugging symbols defined to be built by default or just simply leave it away if the package doesn't build em unless told to.

donvla commented on 2012-01-02 09:10 (UTC)

BTW, here is my namcap output for this (20111226-1) package: http://pastebin.com/US4Zdrkm

donvla commented on 2012-01-02 09:05 (UTC)

@Huulivoide: Sometimes it works, sometimes it doesn't with external ffmpeg. You're on the safe side using xbmc's ffmpeg. You don't need the debug information inside the package once it is successfully built. @B: I´ll reverse the changes later this week. To get it right, only "glew" and "libxrandr" is still needed?

Huulivoide commented on 2012-01-02 01:15 (UTC)

It would aso seem to be working without problems on system ffmpeg....

Huulivoide commented on 2012-01-01 21:21 (UTC)

I don't see the logic of --enable-debug as debugging symbols are removed after packaging....

<deleted-account> commented on 2011-12-31 13:07 (UTC)

It seems glew is still needed in the dependency array as well. Sorry - I guess I messed up on my end with running namcap on my own PKGBUILD :(. On the positive side, I think we can remove the python2 stanza and the feh.sh script - since python2 is now a dependency.

<deleted-account> commented on 2011-12-27 23:24 (UTC)

DonVla, I am sorry, despite namcap happily marking xrandr as a dependency 'already provided for', the build fails if you don't add xrandr to the dependencies. $ grep -i xrandr ~/chroot32/copy/build/xbmc-11.0_beta1-1-i686-build.log checking for main in -lXrandr... no == Could not find libXRandR. SDL will be used for resolution support. == XRandR: No CPP xbmc/windowing/X11/XRandR.o # xbmc-xrandr.c gets picked up by the default make rules excluding xbmc-xrandr Pableu: you are supposed to have the base-devel group installed if you build packages. Pkg-config is part of it, thus not a dependency. Not even a make dependency.

<deleted-account> commented on 2011-12-27 14:28 (UTC)

This sould also depend on pkg-config, since it's necessary to build the package.

<deleted-account> commented on 2011-12-26 00:26 (UTC)

Oi :) I found out the weather service breaks because it is looking for the python-simplejson python module. Maybe worth adding to optdepends? I also ran the PKGBUILD through namcap (hope you don't mind) and that allows filtering out quite a few duplicate dependencies: bzip2, fribidi, glew, libxinerama, and libxrandr. Namcap says hicolor-icon-theme is supposed to be a dep as well...

« First ‹ Previous 1 .. 39 40 41 42 43 44 45 46 47 48 49 .. 54 Next › Last »