Created attachment 349098 [details] xbmc-12.1.ebuild -> xbmc-12.2.ebuild with raspberry pi support Here is a modified xbmc-12.1.ebuild which provides support for the raspberry pi. I only added some additional use flags to have control over some more configure options. Question: For the raspberry pi, I wanted to configure xbmc with --disable-x11 --enable-rsxs but the rsxs use flag requires the X use flag, so I had to manually overwrite the --enable-x11 configure option for the raspberry pi. Where does the dependency come from? In reply to https://bugs.gentoo.org/show_bug.cgi?id=468518#c7: > platform-specific USE flags don't really make sense. SpanKY: Do you have an idea how to avoid the raspberry pi use flag?
Created attachment 349104 [details] xbmc-12.patch
Corrected the patch to use tabs instead of spaces, this produces a much more clean patch which is easier to read; as a result the big block of use_enable reduces to just those that you have changed. I think it may be more interesting to create a new xbmc-rbp/rpi package than to add such a drastic change to the existing xbmc package; if the xbmc maintainers agree with this, then please consider to re-assign to maintainer-wanted@g.o. PS: On a side note, you probably meant to do a revision bump instead of .1 -> .2.
(In reply to comment #2) > PS: On a side note, you probably meant to do a revision bump instead of .1 > -> .2. No I didn't want to do a revision bump. The 12.1-r1 aswell as the new 12.2 ebuild in portage use libass AFAIK. This lead to hardmasking issues on the raspberry pi if I remember correctly. The 12.1 ebuild was the perfect base to compile the 12.2 tarball on the raspberry pi.
(In reply to Gerhard Bräunlich from comment #0) > In reply to https://bugs.gentoo.org/show_bug.cgi?id=468518#c7: > > platform-specific USE flags don't really make sense. > SpanKY: Do you have an idea how to avoid the raspberry pi use flag? the diff sounds really hackish, it would make much more sense to add more useflags to xbmc and mask/force them on a rbp profile. the toolchain setup should be handled by gcc-config + crossdev if applicable. if you can submit such a diff to xbmc ebuilds this has chances of being accepted.
> the diff sounds really hackish, it would make much more sense to add more > useflags to xbmc and mask/force them on a rbp profile. the toolchain setup > should be handled by gcc-config + crossdev if applicable. > > > if you can submit such a diff to xbmc ebuilds this has chances of being > accepted. Does that mean, that you propose to create a new rpi profile? Up to now, there is no such profile as far as a I'm informed. For my last build of xbmc, I didn't use crossdev directly. I compiled xbmc on my rpi with distcc. Would you prefer to purely crosscompile xbmc on a host machine?
(In reply to Gerhard Bräunlich from comment #5) > > the diff sounds really hackish, it would make much more sense to add more > > useflags to xbmc and mask/force them on a rbp profile. the toolchain setup > > should be handled by gcc-config + crossdev if applicable. > > > > > > if you can submit such a diff to xbmc ebuilds this has chances of being > > accepted. > > Does that mean, that you propose to create a new rpi profile? Up to now, > there is no such profile as far as a I'm informed. > you can do that in an overlay for a start. there are people doing rbp stuff in gentoo as far as i'm informed, so you might want to contact them. > For my last build of xbmc, I didn't use crossdev directly. I compiled xbmc > on my rpi with distcc. Would you prefer to purely crosscompile xbmc on a > host machine? I would certainly prefer cross compiling (if that were not for python crap) but xbmc ebuild should not be aware of this: it shoud be native or cross-compiling agnostic. for example, you can add an omxplayer useflag; the --platform stuff can be handled better with useflags: as far as I can see only omxlibs stuff cannot be done that way and this should be fixed upstream rather.
Created attachment 355956 [details, diff] xbmc-12.2-r1.patch (In reply to Alexis Ballier from comment #6) No luck with pure cross compiling (but don't giving up). But the new attached patch builds nicely on my raspberry pi with a new rbp profile (and distcc). It is based on the latest ebuild in portage i.e. xbmc-12.2-r1.ebuild. It basically only adds new use flags with the exception of two raspberry pi specific changes in src_prepare and src_configure.
Created attachment 355958 [details] package.use.force package.use.force for rbp profile
Created attachment 355960 [details] package.use.mask package.use.mask for rbp profile
Created attachment 355962 [details] package.use package.use for rbp profile
Comment on attachment 349104 [details] xbmc-12.patch we don't do board USE flags, we do feature based flags. if you're using an armv6, then you should be using a profile that masks out flags like neon.
Created attachment 428188 [details, diff] patch for kodi-16.0 with support for raspberry pi this patch adjust the ebuild so that kodi can be compiled and run on raspberry pi devices. it also adds support for raspberrypi-omxplayer (already in tree). just a note to media-libs/raspberrypi-userland dependency. there is also -bin version but i did not include that one as it is broken and imo it should be removed from the tree. any feedback welcome. i have also kodi-pvr-hds ebuild that is already in tree but cannot add ~arm there as kodi itself is not ~arm yet.
gles? ( - media-libs/mesa[gles2] + raspberry-pi? ( + media-libs/raspberrypi-userland + ) + !raspberry-pi? ( + media-libs/mesa[gles2] + ) ) maybe it'd be worth adding a virtual/gles + raspberry-pi? ( + media-libs/raspberrypi-userland + sys-apps/lsb-release + ) or at least avoid duplication there + if use raspberry-pi ; then + append-ldflags -L/opt/vc/lib + append-cppflags -I/opt/vc/include + fi + this shouldn't be in an ebuild and wont work well when cross-compiling :) at the very least, please prepend ${SYSROOT} I'd say (I don't think anyone wants to build kodi on a pi) I know this is standard path for rpi-ul, but can't we bug upstreams for providing e.g. a .pc file and kodi to use that ? + <flag name="omxplayer">Enable OMXPlayer on Raspberry Pi devices</flag> is it only for the pi or omxplayer can work with any "mmal" implementation ? (this is nitpick: pi is the only device I know implementing mmal)
(In reply to Alexis Ballier from comment #13) > gles? ( > - media-libs/mesa[gles2] > + raspberry-pi? ( > + media-libs/raspberrypi-userland > + ) > + !raspberry-pi? ( > + media-libs/mesa[gles2] > + ) > ) > > maybe it'd be worth adding a virtual/gles atm raspberrypi-userland is not in opengl virtual aswell. idk if it is candidate for virtual/opengl and virtual/gles. on my rpi2 i have both mesa and raspberrypi-userland installed gut i turned gles2 and egl of on mesa because raspberrypi-userland and mesa both provide the same pc files (yes, i added custom pc files to raspberrypi-userland but because we also have raspberrypi-userland-bin which is broken, i could not rely on these). > > > + raspberry-pi? ( > + media-libs/raspberrypi-userland > + sys-apps/lsb-release > + ) > > > or at least avoid duplication there what happens when user enables raspberry-pi but not gles? imo raspberrypi-userland won't end up in the dependencies which is wrong. building kodi without gles would probably make no sense in this case but we have that use flag. > > > + if use raspberry-pi ; then > + append-ldflags -L/opt/vc/lib > + append-cppflags -I/opt/vc/include > + fi > + > > this shouldn't be in an ebuild and wont work well when cross-compiling :) at > the very least, please prepend ${SYSROOT} I'd say (I don't think anyone > wants to build kodi on a pi) i built complete gentoo on my rpi2 and rpi3 is even more capable. but generally you are right. maybe when we get rid of raspberrypi-userland-bin and avoid installing both mesa[egl,gles2] and raspberrypi-userland, we might use pc files for compilation and this could be dropped. > > I know this is standard path for rpi-ul, but can't we bug upstreams for > providing e.g. a .pc file and kodi to use that ? mentioned above. > > > + <flag name="omxplayer">Enable OMXPlayer on Raspberry Pi devices</flag> > > is it only for the pi or omxplayer can work with any "mmal" implementation ? > (this is nitpick: pi is the only device I know implementing mmal) as it currently turns on raspberrypi-omxplayer dependency, i put the information there about rpi so that it's not confusing.
(In reply to Miroslav Šulc from comment #14) > (In reply to Alexis Ballier from comment #13) > > gles? ( > > - media-libs/mesa[gles2] > > + raspberry-pi? ( > > + media-libs/raspberrypi-userland > > + ) > > + !raspberry-pi? ( > > + media-libs/mesa[gles2] > > + ) > > ) > > > > maybe it'd be worth adding a virtual/gles > > atm raspberrypi-userland is not in opengl virtual aswell. I dont think the pi is opengl capable, hence my suggestion of a new virtual :) (but I think this shouldnt prevent merging this, a virtual for 1 or 2 consumers does not make much sense either) > idk if it is > candidate for virtual/opengl and virtual/gles. on my rpi2 i have both mesa > and raspberrypi-userland installed gut i turned gles2 and egl of on mesa > because raspberrypi-userland and mesa both provide the same pc files (yes, i > added custom pc files to raspberrypi-userland but because we also have > raspberrypi-userland-bin which is broken, i could not rely on these). hmm, I don't think you should do that but rather rely on 'eselect opengl' that handles gles only profiles just fine iirc > > > > > > + raspberry-pi? ( > > + media-libs/raspberrypi-userland > > + sys-apps/lsb-release > > + ) > > > > > > or at least avoid duplication there > > what happens when user enables raspberry-pi but not gles? imo > raspberrypi-userland won't end up in the dependencies which is wrong. what I meant is that the 'gles? rpi ? ()' part pulls deps already included in 'rpi? ()' [...] > > > > I know this is standard path for rpi-ul, but can't we bug upstreams for > > providing e.g. a .pc file and kodi to use that ? > > mentioned above. well, you mentionned you provided custom pc files within gentoo, not that those will be included upstream so that kodi's upstream can use them without us needing to patch it :)
here are the packages on my rpi system that depend on mesa: # equery depends mesa * These packages depend on mesa: media-tv/kodi-16.0 (!raspberry-pi ? media-libs/mesa[gles2]) virtual/opengl-7.0-r1 (>=media-libs/mesa-9.1.6[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]) x11-libs/cairo-1.14.6 (gles2 ? >=media-libs/mesa-9.1.6[gles2,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]) (opengl ? >=media-libs/mesa-9.1.6[egl,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]) media-tv/kodi-16.0 should be ignored as raspberry-pi use flag is on. if we add raspberrypi-userland to virtual/opengl and create virtual/gles the same way, mesa could go away on rpi system. that would simplify kodi ebuild. there is also the issue that repoman complains about raspberrypi-userland and raspberrypi-omxplayer are not available for amd64 and x86.
(In reply to Alexis Ballier from comment #15) > I dont think the pi is opengl capable, hence my suggestion of a new virtual > :) > (but I think this shouldnt prevent merging this, a virtual for 1 or 2 > consumers does not make much sense either) well, i guess i'm messing things up. anyway, iirc mesa installs egl.pc and glesv2 files, the same ones that mesa installs when egl and gles2 is enabled. that would result in conflict if both (from mesa and from raspberrypi-userland) would be installed at the same path. > > > idk if it is > > candidate for virtual/opengl and virtual/gles. on my rpi2 i have both mesa > > and raspberrypi-userland installed gut i turned gles2 and egl of on mesa > > because raspberrypi-userland and mesa both provide the same pc files (yes, i > > added custom pc files to raspberrypi-userland but because we also have > > raspberrypi-userland-bin which is broken, i could not rely on these). > > hmm, I don't think you should do that but rather rely on 'eselect opengl' > that handles gles only profiles just fine iirc i used eselect opengl to set it to raspberrypi-userland, but the packages i mentioned above pulled in mesa aswell. > > > > > > > > > > + raspberry-pi? ( > > > + media-libs/raspberrypi-userland > > > + sys-apps/lsb-release > > > + ) > > > > > > > > > or at least avoid duplication there > > > > what happens when user enables raspberry-pi but not gles? imo > > raspberrypi-userland won't end up in the dependencies which is wrong. > > what I meant is that the 'gles? rpi ? ()' part pulls deps already included > in 'rpi? ()' > > [...] ah, the other way around, right :-) > > > > > > I know this is standard path for rpi-ul, but can't we bug upstreams for > > > providing e.g. a .pc file and kodi to use that ? > > > > mentioned above. > > well, you mentionned you provided custom pc files within gentoo, not that > those will be included upstream so that kodi's upstream can use them without > us needing to patch it :) yes, iirc there were two bugs at gentoo with provided pc files and i did not check whether somebody filed that bug upstream too :-) just checked, it's there already for 10 months...
(In reply to Miroslav Šulc from comment #16) > if we add raspberrypi-userland to virtual/opengl again, last I checked rpi-ul didn't provide libGL and rpi hardware wasn't GL capable so this won't work [...] > there is also the issue that repoman complains about raspberrypi-userland > and raspberrypi-omxplayer are not available for amd64 and x86. yes, the rpi useflag should be masked in profiles/base and unmasked in profiles/arch/arm
(In reply to Alexis Ballier from comment #18) > (In reply to Miroslav Šulc from comment #16) > > if we add raspberrypi-userland to virtual/opengl > > again, last I checked rpi-ul didn't provide libGL and rpi hardware wasn't GL > capable so this won't work > yes, that was my confusion about opengl and egl. what i meant to say is that both mesa and raspberrypi-userland install egl.pc (and glesv2.pc) so there would be conflict if both would be installed and mesa would have egl and gles2 turned on.
(In reply to Miroslav Šulc from comment #17) > > > > > > > > > > > > > > + raspberry-pi? ( > > > > + media-libs/raspberrypi-userland > > > > + sys-apps/lsb-release > > > > + ) > > > > > > > > > > > > or at least avoid duplication there > > > > > > what happens when user enables raspberry-pi but not gles? imo > > > raspberrypi-userland won't end up in the dependencies which is wrong. > > > > what I meant is that the 'gles? rpi ? ()' part pulls deps already included > > in 'rpi? ()' > > > > [...] > > ah, the other way around, right :-) In fact, please scrap my comments there; I'm not sure it's cleaner the way I'm suggesting. Let's wait for vapier's comments; I don't particularly like board-specific useflags, but in kodi's case for the rpi, it might actually make sense and I'm not against it.
(In reply to Miroslav Šulc from comment #19) > (In reply to Alexis Ballier from comment #18) > > (In reply to Miroslav Šulc from comment #16) > > > if we add raspberrypi-userland to virtual/opengl > > > > again, last I checked rpi-ul didn't provide libGL and rpi hardware wasn't GL > > capable so this won't work > > > > yes, that was my confusion about opengl and egl. what i meant to say is that > both mesa and raspberrypi-userland install egl.pc (and glesv2.pc) so there > would be conflict if both would be installed and mesa would have egl and > gles2 turned on. from your output, cairo[gles2] could benefit from the virtual too and then you could make rpi-ul block mesa[gles2]
we should also block mesa[egl] because it is installed by raspberrypi-userland too.
any chance we could move on with this bug? there are more people trying to build and use kodi on rpi with gentoo.
I successfully cross-compiled (crossdev) kodi-16.1 for armv6j-hardfloat-linux-gnueabi (see #560196) together with a similar set of changes as Miroslav suggested (also taking into account comment 13). Maybe we could split this bug into the following 3 independent parts: * Adding more useflags * cross-compile support * raspberry-pi support
Another remark: + raspberry-pi? ( + media-libs/raspberrypi-userland + sys-apps/lsb-release + ) + omxplayer? ( + media-video/raspberrypi-omxplayer kodi compiles fine for me, without having media-video/raspberrypi-omxplayer and sys-apps/lsb-release installed (even if --with-omxplayer is passed to configure). Thus in my opinion, at least media-video/raspberrypi-omxplayer, probably also sys-apps/lsb-release should go to RDEPEND and not to COMMON_DEPEND. Miroslav: Could you provide an updated version of your kodi-16.0 patch, taking into account the points of the discussion so far? Vapier: Do you have some comments?
(In reply to Gerhard Bräunlich from comment #25) > Another remark: > + raspberry-pi? ( > + media-libs/raspberrypi-userland > + sys-apps/lsb-release > + ) > + omxplayer? ( > + media-video/raspberrypi-omxplayer > > kodi compiles fine for me, without having > media-video/raspberrypi-omxplayer and sys-apps/lsb-release > installed (even if --with-omxplayer is passed to configure). > > Thus in my opinion, at least media-video/raspberrypi-omxplayer, probably > also sys-apps/lsb-release should go to RDEPEND and not to COMMON_DEPEND. > > Miroslav: Could you provide an updated version of your kodi-16.0 patch, > taking into account the points of the discussion so far? i dropped my idea of running gentoo on rpi completely because i had many issues with running kodi on it. it was unstable, there is some linkage problem that prevents using mmal, it seems there are issues with gcc on arm etc etc. wrt raspberrypi-omxplayer, it's probably not needed at all, i think kodi has an internal copy of omxplayer but i might be wrong.
OK. Thanks for the hint with omxplayer. So far I had no chance to test my cross-compiled kodi 16 an a raspberry pi. But up to now (xbmc/kodi 12,13,14) my system is running stable with gentoo. And somehow, the people from openelec, buildroot,... also manage to provide stable builds. So I will definitely continue to go with gentoo on the pi.
(In reply to Gerhard Bräunlich from comment #27) > OK. Thanks for the hint with omxplayer. > So far I had no chance to test my cross-compiled kodi 16 an a raspberry pi. > But up to now (xbmc/kodi 12,13,14) my system is running stable with gentoo. > And somehow, the people from openelec, buildroot,... also manage to provide > stable builds. So I will definitely continue to go with gentoo on the pi. my instability issues came (probably) mainly from these sources: 1) gcc >= 5 is not working well on arm 2) i used tvheadend plugin which was probably causing some issues too 3) i was using omxplayer instead of mmal because kodi does not correctly use mmal (i filed two bugs about it, one to raspberrypi-userland and another to kodi, without any solution) which caused some crashes too it definitely should be possible to compile everything so that it's stable and does not crash but i was not able to reach this state.
Filed a pull request (raspberry pi support is missing up to now) https://github.com/gentoo/gentoo/pull/2392
https://github.com/gentoo/gentoo/commit/13f6601b599d575f4f43e9620e1b174f9c10b757
