[Thomas Korimort]

Dear Sam!

I am pretty sure that your OSMC is a great piece of Linux master's efforts. My concern about this is that in the build script that was discussed about somewhere above, which can be used to build kodi from OSMC distribution, seemed to have specially compiled packages for OSMC, thus making it incompatible with standard Debian distro. I have Debian 8.0 Jesie only installed on my RPi2 currently on which i found the native xbmc package included in Debian 8.0 Jessie seemingly not working. Maybe this is just like that on Debian Jessie+Rpi(2) and if it is like that the question is why the hardware abstraction layer of Linux kernel and an open-source firmware of RPi2 together are not able to provide a working set of drivers making such standards as OpenGL transparently available without further modifications of the standard distro packages. So, i want to find out about the critical point and by the way it is also interesting to learn about the internals of Linux. To me it seems as if it is counter-productive to fork so many distros apart from the well-established and perfeclty adaptable Debian. Linux should not only be about making it available for the average Windows user uncapable and unknowing of any technical details because of user-friendliness, but to raise responsible users, administrators and programmers who take the power of their computers in their own hands, being able to use the software that is there effectively and in a scalable way. Providing junks of special purpose distros each sitting on an embedded device doubly as expensive as a commercial product for the same purpose using proprietary solutions is not competitive. If there is now a cheap computer like RPi2, the chance of Linux is to use it as an allround-linux machine instead of making it only a non-userfriendly expensive non-competitive Mediacenterstick solution. Having different distros instead of one distro scalable to all purposes easily by an average capable user destroys the pollicy and effort about Unix/Linux scalability (and especially that of Debian) which was once the big plus for Linux. Nowadays Microsoft provides with Windows 10 such feature in a consistent way, even basing there driver system on a consistent concept of hardware abstraction layer, which is endangered to get lost in Linux because of bad marketing policy and enemies in its own rows of the core distro of Debian...

That is my opinion. It would be nice to discuss such issues till they are solved...

Many greetings,

Thomas.

[Sam.Nazarko]

Dear Sam!

I am pretty sure that your OSMC is a great piece of Linux master's efforts. My concern about this is that in the build script that was discussed about somewhere above, which can be used to build kodi from OSMC distribution, seemed to have specially compiled packages for OSMC, thus making it incompatible with standard Debian distro. I have Debian 8.0 Jesie only installed on my RPi2 currently on which i found the native xbmc package included in Debian 8.0 Jessie seemingly not working. Maybe this is just like that on Debian Jessie+Rpi(2) and if it is like that the question is why the hardware abstraction layer of Linux kernel and an open-source firmware of RPi2 together are not able to provide a working set of drivers making such standards as OpenGL transparently available without further modifications of the standard distro packages. So, i want to find out about the critical point and by the way it is also interesting to learn about the internals of Linux. To me it seems as if it is counter-productive to fork so many distros apart from the well-established and perfeclty adaptable Debian. Linux should not only be about making it available for the average Windows user uncapable and unknowing of any technical details because of user-friendliness, but to raise responsible users, administrators and programmers who take the power of their computers in their own hands, being able to use the software that is there effectively and in a scalable way. Providing junks of special purpose distros each sitting on an embedded device doubly as expensive as a commercial product for the same purpose using proprietary solutions is not competitive. If there is now a cheap computer like RPi2, the chance of Linux is to use it as an allround-linux machine instead of making it only a non-userfriendly expensive non-competitive Mediacenterstick solution. Having different distros instead of one distro scalable to all purposes easily by an average capable user destroys the pollicy and effort about Unix/Linux scalability (and especially that of Debian) which was once the big plus for Linux. Nowadays Microsoft provides with Windows 10 such feature in a consistent way, even basing there driver system on a consistent concept of hardware abstraction layer, which is endangered to get lost in Linux because of bad marketing policy and enemies in its own rows of the core distro of Debian...

That is my opinion. It would be nice to discuss such issues till they are solved...

Many greetings,

Thomas.

OSMC is not a fork of Debian, it considers itself a derivative, in the same way Kubuntu /Lubuntu etc are and we are taking efforts to make ourselves recognised as an official Debian derivative. Compiling OSMC packages will not be incompatible with Debian providing that all dependencies are satisfied.

Yes -- the build script builds OSMC versions of these packages, but that's what makes OSMC what it is instead of vanilla Debian. I pointed you towards our tree as a resource, but not as a definitive one neither an end point. You can do with it what you like, and it's quite easy to see what's changed over Debian.

What you ask for, an apt-get installable version of Kodi on ARM is beyond the scope of Debian or any distribution. The necessary EGL libs must be linked against at build time, which is highly dependent on the platform you are targetting.

S

[Thomas Korimort]

Dear Sam,

OSMC is not a fork of Debian, it considers itself a derivative, in the same way Kubuntu /Lubuntu etc are and we are taking efforts to make ourselves recognised as an official Debian derivative. Compiling OSMC packages will not be incompatible with Debian providing that all dependencies are satisfied.

Yes -- the build script builds OSMC versions of these packages, but that's what makes OSMC what it is instead of vanilla Debian. I pointed you towards our tree as a resource, but not as a definitive one neither an end point. You can do with it what you like, and it's quite easy to see what's changed over Debian.

What you ask for, an apt-get installable version of Kodi on ARM is beyond the scope of Debian or any distribution. The necessary EGL libs must be linked against at build time, which is highly dependent on the platform you are targetting.

S

Ok. If EGL libs need to be linked wouldnt they need to be linked against the kernel as built-in modules? And in such a case couldnt simply such a kernel and bootimage be included as Debian Jessie package providing native support for Pi2 or any other embedded or non-PC device? Wouldn't that be much more efficient than making an own distro for every new embedded device? If a clear philosophy of bootstrapping process is there Linux should be flexible enough to use one standard distro for every possible case of scalability and special hardware, thereby making it possible to concentrate the ressources of Linux community on the essentials instead of unnecessary competitive projects?

Greetings, Thomas.

[Sam.Nazarko]

Ok. If EGL libs need to be linked wouldnt they need to be linked against the kernel as built-in modules?

Sometimes, there are kernel changes. But you always need userland interface for Kodi or any other EGL consuming backend. You also have hardware video acceleration changes to consider.

And in such a case couldnt simply such a kernel and bootimage be included as Debian Jessie package providing native support for Pi2 or any other embedded or non-PC device?

Not that easy, but Pi is making efforts to upstream its support as much as possible.

if you want a (fairly) universal Kodi binary, you'll need X11 or Wayland. Which is not an efficient way of displaying your GUI on ARM, and then you have hardware acceleration issues.

essentials instead of unnecessary competitive projects?

Put it this way, if it could've been done in a unified manner, it would've been done already. The last thing I / OpenELEC or any distributor wants to do is release multiple images. But we do it because it's the only way to properly support hardware. Everything you are proposing is beyond that of what a Linux distribution can achieve. We are effectively 'downstream'. We'd either need a Kodi that can dynamically load appropriate EGL libraries (remove all the #ifdefs), link against all EGL libraries for every platform supported (gross and bloated), or X11/Wayland

Please research a little before making any further questions

[m_o_d]

At the beginning of this beautiful day i want to thanks you all for help, so eeeeeee it works

What Next?
* backup data from SD
* create new clean image
* build kodi through shell script

Sam regarding your question "why not OSMC"?
I'm not saying that I will not use OSMC, but every day I use debian. if i need to spend time learning howto use OSMC with:
* mount custom sshfs
* instaling custom VPN
* creating routing script
* accessing bare system
* disabling autoupdate

i would prefer to spend that time learing how to compile kodi on ARM, especially since this is my first encounter with this platform andand I do not think that the last.
In other words, that experience gained here I can use at work everyday.

[Thomas Korimort]

Dear m_o_d,

please provide me with a short instruction on how you managed to do it. Please, could you list all the steps you did until it worked. E.G. compiler configruation, options for configure scripts, firmware updates,....

[m_o_d]

Edit 2015-06-15: better script here: http://forum.kodi.tv/showthread.php?tid=...pid2027416
original message below

@Thomas
* update firmware (rpi-update script)
* install libraspberrypi-dev package

I do not know if it's necessary but still done the following things:
* link files from /opt/vc to /usr, use the script below

Code:

#! /bin/bash


for level1 in `ls /opt/vc`; do

  for level2  in `ls $level1`; do

    ln -s  /opt/vc/$level1/$level2 /usr/$level1/$level2;

  done;

* compile, use the script below

Code:

#!/bin/bash -x

git clone https://github.com/xbmc/xbmc.git kodi;


cd kodi;
./bootstrap
#make clean;

CFLAGS="-I/opt/vc/include/ -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include/interface/vmcs_host/linux -mfloat-abi=hard -mcpu=cortex-a7 -mfpu=neon-vfpv4";

CXXFLAGS="-I/opt/vc/include/ -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include/interface/vmcs_host/linux -mfloat-abi=hard -mcpu=cortex-a7 -mfpu=neon-vfpv4";

LDFLAGS="-L/opt/vc/lib";

FFMPEG_OPTS="--cpu=cortex-a7";


#reset
#sleep 10

./configure --prefix=/usr/local/kodi/git-20150608  --disable-gl --enable-gles --with-platform=raspberry-pi --disable-x11 --disable-vaapi --disable-vdpau --disable-avahi --disable-libcec \
    --disable-projectm --disable-optical-drive --disable-dvdcss --disable-vtbdecoder --enable-alsa --enable-player=omxplayer

make

i will do fresh install, so if something else is needed i will write you

[Thomas Korimort]

@m_o_d: thanks.. looks pretty easy after your long path of suffering ;-) I did not know that Debian provides a libraspberrrypi-dev package. The files you linked you should link in a clean way using "ldconfig" otherwise the dynamic linker might get confused later on. Did you install also the xbmc package from Debian Jessie 8.0 ? Did you also install the dependency packages from Debian jessie that are listed in README.linux and README.raspberypi in the xbmc doc directory on git? One instruction that i read suggested to install the xbmc package shipping with Debian jessie in order to get fulfilled package dependencies. Did your configure script build the ffmpeg libraries itself?

Many greetings, Thomas

[popcornmix]

* add missing files to /opt/vc//include: /opt/vc/include/GLES2 and /opt/vc/include/KHR (download from https://github.com/raspberrypi/firmware/...vc/include)

What was missing? All include files from https://github.com/raspberrypi/firmware/...vc/include should be installed by rpi-update (and probably be there by default).

[m_o_d]

* add missing files to /opt/vc//include: /opt/vc/include/GLES2 and /opt/vc/include/KHR (download from https://github.com/raspberrypi/firmware/...vc/include)

What was missing? All include files from https://github.com/raspberrypi/firmware/...vc/include should be installed by rpi-update (and probably be there by default).

These directories were empt. But now everything is fine, except wrong location of some files:
* ln -s /opt/vc/include/interface/vcos/pthreads/vcos_platform.h /opt/vc/include/interface/vcos/vcos_platform.h
* ln -s /opt/vc/include/interface/vcos/pthreads/vcos_platform_types.h /opt/vc/include/interface/vcos/vcos_platform_types.h
* ln -s /opt/vc/include/interface/vmcs_host/linux/vchost_config.h /opt/vc/include/interface/vmcs_host/vchost_config.h

[m_o_d]

* add missing files to /opt/vc//include: /opt/vc/include/GLES2 and /opt/vc/include/KHR (download from https://github.com/raspberrypi/firmware/...vc/include)

What was missing? All include files from https://github.com/raspberrypi/firmware/...vc/include should be installed by rpi-update (and probably be there by default).

These directories were empt.

This was my mistake, i linked files to /usr/include and then i removed mesa package from system. Result of this was deleting files

[popcornmix]

This was my mistake, i linked files to /usr/include and then i removed mesa package from system. Result of this was deleting files

Could you edit your original post to remove that line?
There's useful information in there, and would be good to make sure the information is accurate.

[Thomas Korimort]

@popcornmix and @m_o_d: that also happened to me. I got mixed up completely which files should be installed and are in proper place or not. As for my current installation with most recent rpi-update all the include directories like GLES ... are present and contain some include files. Thus my question was, whether there is other dependencies that you - m_o_d - had to satisfy and to install. Just one question aside: The make tools and all the compilers? Is there a metapackage or a task package in Debian that installs a complete set of developers tools?

Please, m_o_d provide complete information on how you arrived at your successful solution...

[navy1978_1]

Guy it is really a shame I bought a raspberry pi2 just to have a server tomcat and to install kodi...
At the moment I have a problem with the only plugin I use in Kodi and I need to build a version for Raspberry applying a patch, but this is not possible apparently with raspbian... I hope that this will be possible in the future... Because now all the distribution OpenElec and so on have the same issue for iptv plug in a tremendous delay, that in previous versions of kodi was not there apparently... :
this is the ticked: http://trac.kodi.tv/ticket/15918

So without the possibility to compile Kodi on raspberry with the correct patch for me all these distributions are not ok...

[popcornmix]

Just one question aside: The make tools and all the compilers? Is there a metapackage or a task package in Debian that installs a complete set of developers tools?

"sudo apt-get install build-essential" should get you the default make tools and gcc.