126 replies to this topic

[WanWizard]

[Aliraza63]

read somewhere in other forums  in Openspa kodi 18.9  is working fine in mips  (duo2 ) no audio issue at all .

is it true ? 

[A.A.]

#WanWizard

 

I tried to split kodi_18.inc and create the .bbappend in meta-vuplus but it is impossible...purposedly blocked.

 

https://github.com/v...4b4896eb103c243

 

We have two options imho:

 

1- insist with vuplus and revert that commit.  Need to add layer dependencies as well to the openpli layer in this case.

2 -create a bogus kodi-vuplus_18.bb which includes the main .bb. Ofc layer deps should be added.

 

Any idea?

Cheers

A.A.

[A.A.]

read somewhere in other forums  in Openspa kodi 18.9  is working fine in mips  (duo2 ) no audio issue at all .

is it true ? 

Yes, on vuduo2 the OE-A images provide a running kodi for stb. I did not test sound on it yet.

We are now trying to spot the difference making kodi  crash on OpenPli: we are basically sure it builds correctly.

 

I personally don't know kodi internals, I think it tries to open some connection and fails (SIGBUS).

But which one? Linux input? Sound bus? dvb video sink?Networking? ....

 

WIP

 

A.A.

[ntj]

read somewhere in other forums  in Openspa kodi 18.9  is working fine in mips  (duo2 ) no audio issue at all .

is it true ? 

Yes, to answer your question.

 

I have tried Openspa with Kodi 18.9 on both DUO2 (mips) and Ultimo4k. (arm)

Both are working good and with sound.

[Aliraza63]

 

read somewhere in other forums  in Openspa kodi 18.9  is working fine in mips  (duo2 ) no audio issue at all .

is it true ? 

Yes, to answer your question.

 

I have tried Openspa with Kodi 18.9 on both DUO2 (mips) and Ultimo4k. (arm)

Both are working good and with sound.

 

 

Thanks for the reply . I have tested now to . yes its working fine in my duo2 and duo4k to

[WanWizard]

https://github.com/v...4b4896eb103c243

 

We have two options imho:

 

1- insist with vuplus and revert that commit.  Need to add layer dependencies as well to the openpli layer in this case.

2 -create a bogus kodi-vuplus_18.bb which includes the main .bb. Ofc layer deps should be added.

 

What exactly is the issue with this?

 

It only removes bbappend capability from the BSP, which is indeed a good thing, we don't want a BSP appending to recipies outside the BSP.

 

So if kodi for VU+ requires something special, it needs to be addressed in the kodi recipes (there are already exceptions for VU+ present).

[A.A.]

 

https://github.com/v...4b4896eb103c243

 

We have two options imho:

 

1- insist with vuplus and revert that commit.  Need to add layer dependencies as well to the openpli layer in this case.

2 -create a bogus kodi-vuplus_18.bb which includes the main .bb. Ofc layer deps should be added.

 

What exactly is the issue with this?

 

It only removes bbappend capability from the BSP, which is indeed a good thing, we don't want a BSP appending to recipies outside the BSP.

 

So if kodi for VU+ requires something special, it needs to be addressed in the kodi recipes (there are already exceptions for VU+ present).

 

 

 

Nothing really forbids to have .bbappends in the BSP layers...in fact it is the standard in OE/Yocto for the kernels... [1]

 

Anyway the thing is that in an ideal world meta-openpli should not contain machine-specific recipes nor variables with machine-overrides (ie blah_vuduo2).

Ideally it should not even contain a kodi.bb but just a .bbappend pointing to the meta-kodi layer...

 

So that kodi_18.inc should not exist there

 

my 2 cents

A.A.

 

 

[1] https://www.yoctopro...html#bsp-layers

[WanWizard]

I know it is not forbidden, the problem is that they may alter recipes from elsewhere. For the rest, I completely agree with you that all hardware linked recipes should be in the BSP.

 

It is different when, like OE-A, one controls everything, and one can setup the correct structure from scratch. With BSP's not being under our control, it is always going to be difficult.

[A.A.]

One more question: the recipe was imported from meta-kodi and we unconditionally inherit systemd.

 

What are the effects? None?

I'd say it should be first checked against DISTRO_FEATURES.

 

A.A.

[WanWizard]

Where is that? I don't think that has any effect if systemd isn't used, a lot of recipe's have systemd support.

[A.A.]

It should not harm.

 

It's here

https://github.com/O.../kodi_18.bb#L14

 

Instead, more relevant is perhaps pulseaudio?

https://github.com/o...kodi_18.bb#L142

 

I don't see special reasons for it but maybe there are...

 

Cheers

A.A.

[A.A.]

While the OE-A image is unbuildable atm (samba) I installed OpenSPA and immediately installed kodi on it.

Here the logs: https://pastebin.com/PxY4yPbq

 

BTW we have different directfb versions

 

WIP

A.A.

[WanWizard]

Your last change produced an error in the nightly builds for all Zgemma ARM models (H7 and up):

2021-04-28 11:05:14 ERROR: kodi-1_18.9+gitrAUTOINC+0655c2c718-r0 do_package_qa: QA Issue: /usr/lib/kodi/kodi-stb contained in package kodi requires libEGL.so, but no providers found in RDEPENDS_kodi? [file-rdeps]
2021-04-28 11:05:14 ERROR: kodi-1_18.9+gitrAUTOINC+0655c2c718-r0 do_package_qa: QA Issue: /usr/lib/kodi/kodi-stb contained in package kodi requires libGLESv2.so, but no providers found in RDEPENDS_kodi? [file-rdeps]
2021-04-28 11:05:14 ERROR: kodi-1_18.9+gitrAUTOINC+0655c2c718-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
2021-04-28 11:05:14 ERROR: Logfile of failure stored in: /openpli/oe/develop/build/tmp/work/h10-oe-linux-gnueabi/kodi/1_18.9+gitrAUTOINC+0655c2c718-r0/temp/log.do_package_qa.27315
2021-04-28 11:05:14 ERROR: Task (/openpli/oe/develop/meta-openpli/recipes-mediacenter/kodi/kodi_18.bb:do_package_qa) failed with exit code '1'

 

[A.A.]

Ah, ok,

 probably they have PRIVATE_LIBS ot there isn't the rprovider.

 

Vuplus seems fixed but if you want we can readd the INSANE_SKIP but limiting it to the affected machines.

Something like INSANE_SKIP_${PN}_Zgemma-model

 

A.A.

 

Edit: it does provide the rdepended libs. No private libs.

https://github.com/z...ddriver.inc#L11

 

zgemma-v3ddriver-h7 should be added to _zgemma-model rdeps of kodi then.

Edited by A.A., 28 April 2021 - 13:00.

[WanWizard]

The machines failing are: h7, h9, h10, h11, h9se, h9combo, h9combose, i55se, i55plus

[A.A.]

h7 -> "zgemma-v3ddriver-${MACHINE}"

h9, h9se, h9combo, h9combose, h10, i55se, i55seplus  -> "zgemma-mali-3798mv200"

h11 -> "zgemma-mali-3798mv310"

 

AFAIS we should add that BSP-derived stuff to kodi_18.inc

 

Cheers

A.A.

 

P.S.

Sorry for the mess, I am building for vuduo2 only atm

Edited by A.A., 28 April 2021 - 13:26.

[A.A.]

I am now wondering..is it better to add virtual/egl to RDEPENDS to catch all these cases?

A.A.

[WanWizard]

I don't know, I'm far from a bitbake expect...

 

If you want me to test something, let me know, I have a local build environment for the h9.

[A.A.]

Kodi has virtual/egl in depends and that should be enough for the buildsystem to register [1]

 

The problem seems to be with the recipe dlopen'ing at runtime or with the unversioned shlibs or when libs are declared private_libs: the conclusion is we need libEGL.so and libGLESv2.so

 

 

I think we could add more lines to kodi_18.inc for these Zgemma like:

 

#Zgemma

RDEPENDS_${PN}_append_h7 = " zgemma-v3ddriver-h7"

RDEPENDS_${PN}_append_h9 = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_h9se = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_h9combo = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_h9combose = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_h10 = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_h11 = " zgemma-mali-3798mv310"

RDEPENDS_${PN}_append_i55se = " zgemma-mali-3798mv200"

RDEPENDS_${PN}_append_i55seplus = " zgemma-mali-3798mv200"

 

 

Or maybe adding a generic RDEPENDS_${PN}_append = " virtual/egl virtual/libgles2"

This would be one-liner but need some more thoughts...

 

A.A.

 

 

[1] https://www.yoctopro...me-dependencies

Edited by A.A., 28 April 2021 - 15:23.