Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#55130 - [kodi] libass should be added as a dep or optdep

Attached to Project: Community Packages
Opened by John (graysky) - Sunday, 13 August 2017, 19:06 GMT
Last edited by Ike Devolder (BlackEagle) - Wednesday, 25 October 2017, 16:55 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Ike Devolder (BlackEagle)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


In order to render subtitles correctly, kodi needs /usr/lib/ which is provided by extra/libass. At a minimum, this should be an optdep since kodi will run without it present, hoewever, the log will record errors relating to this but the video will play.

For example:

ERROR: OpenStream - Unable to init overlay codec
ERROR: Unable to load, reason: cannot open shared object file: No such file or directory
This task depends upon

Closed by  Ike Devolder (BlackEagle)
Wednesday, 25 October 2017, 16:55 GMT
Reason for closing:  Fixed
Additional comments about closing:  is fixed in 17.5-2
Comment by Doug Newgard (Scimmia) - Monday, 14 August 2017, 14:26 GMT
I'm thinking the dep should be somewhere else. Nothing in the kodi package is linked to libass, and grep doesn't reveal anything that looks like it's dlopen'ing it. Try setting LD_DEBUG=files, see what's actually trying to use libass.
Comment by John (graysky) - Monday, 14 August 2017, 18:47 GMT
Hello Doug. I get the following when executing `LD_DEBUG=file kodi` and then play a file with subs:
14485: [0]; dynamically loaded by /usr/lib/kodi/kodi.bin [0]
14485: [0]; dynamically loaded by /usr/lib/kodi/kodi.bin [0]
14485: [0]; dynamically loaded by /usr/lib/kodi/kodi.bin [0]
Comment by Doug Newgard (Scimmia) - Monday, 14 August 2017, 19:13 GMT
It would appear I missed something, then.
Comment by John (graysky) - Thursday, 24 August 2017, 19:31 GMT
@ike - One can remove the builddep of libcrossguid with the following in the cmake step:

I also believe you may want to add:

I didn't want to open a new FS so I thought I would suggest/mention here.
Comment by Ike Devolder (BlackEagle) - Saturday, 02 September 2017, 08:34 GMT
@graysky , why should I add these C{,XX}FLAGS? if I do checksec all is ok
Comment by John (graysky) - Saturday, 02 September 2017, 11:37 GMT
It doesn't build for me with them. Try it.
Comment by Eli Schwartz (eschwartz) - Sunday, 03 September 2017, 03:13 GMT
We build hardened by default, and you say we should add those flags, and then say if the flags are added as you suggest then it won't build?
Comment by John (graysky) - Sunday, 03 September 2017, 12:12 GMT
Sorry about that... typed from phone. I meant to say that if I built the package without the modified cflags, it would throw an error related to the internal libcross needing that flag. I just repeated in a clean-cheroot on another machine and was unable to reproduce. In summary, remove the dep from the PKGBUILD, add the cake option to use the internal and it should be without an issue. I also think removing the dep would be sufficient since the default is to use the internal. Please try and let me know.