Package Details: kodi-git-tools-texturepacker r67077.44376d5e9c74-1

Git Clone URL: https://aur.archlinux.org/kodi-git.git (read-only, click to copy)
Package Base: kodi-git
Description: Kodi Texturepacker tool (master branch)
Upstream URL: https://kodi.tv
Licenses: GPL2
Conflicts: kodi-tools-texturepacker
Provides: kodi-tools-texturepacker
Submitter: BlackIkeEagle
Maintainer: graysky
Last Packager: graysky
Votes: 85
Popularity: 0.000912
First Submitted: 2014-10-23 06:38 (UTC)
Last Updated: 2024-11-23 20:01 (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 »

mrohnstock commented on 2012-01-14 19:06 (UTC)

Won't compile with bluez 4.98, too

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

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