Jump to content


Photo

zeus vs dunfell

dunfell kodi qt

  • Please log in to reply
67 replies to this topic

#1 WTE

  • Senior Member
  • 821 posts

+36
Good

Posted 17 May 2020 - 20:59

Openpli has now branch sumo, thud and zeus.

I think sumo is dead and zeus can been easy update to long term support branch dunfell. ( https://wiki.yoctopr...g/wiki/Releases )

The preparation in all the previous branches seems to make it possible that the step to dunfell is low.

 

I made a git with dunfell which can been used as start: https://github.com/w...re/tree/dunfell

 

 

The only packages which fails by me is djmount. The AM_LANGINFO_CODESET fails. It's something with iconv and m4 but I do not know what a clean patch  or solution is.

I found the follow patch which seems to work but I think this is more a workaround for the problem: https://github.com/O...04aaa48843c4115

 

 


Mut@nt HD51 STB 4K

   :rolleyes:                :rolleyes:


Re: zeus vs dunfell #2 WanWizard

  • PLi® Core member
  • 70,277 posts

+1,799
Excellent

Posted 17 May 2020 - 21:02

One step at the time please, somewhere in the continuous upgrade cycle we need to release something too.

 

Current goal is to make zeus ready for merge into develop, and just before that is done, branch develop  to 7.3-rc for release.

 

One the release it out of the way, we can move on again...


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: zeus vs dunfell #3 WTE

  • Senior Member
  • 821 posts

+36
Good

Posted 17 May 2020 - 21:31

Your right, sometime a release version must been made first before it can go further :)

I will update the dunfell branch after zeus is more finalized.


Mut@nt HD51 STB 4K

   :rolleyes:                :rolleyes:


Re: zeus vs dunfell #4 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 17 May 2020 - 23:02

Hi,

 

I'm coming back after a while and seeing kodi 18 finally in the zeus branch. Just great, tested yesterday night.

 

There was a minor issue with python-importlib but I see it has been fixed a while ago.

But...the build is full of warnings (malformed patches mostly) so cleaning is needed...and hell...kodi 18 fails to build for vuduo2.

 

| -- Configuring done
| CMake Error at cmake/scripts/common/Macros.cmake:72 (add_library):
|   Cannot find source file:
|
|     EGLNativeTypeSTB.cpp

athoik, maybe some patch has been forgotten?

 

 

Cheers

A.A.



Re: zeus vs dunfell #5 foxbob

  • Senior Member
  • 624 posts

+18
Neutral

Posted 18 May 2020 - 04:24

I collected for duo2 kodi18,there are no errors during the assembly,but the plugin does not start.



Re: zeus vs dunfell #6 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 18 May 2020 - 09:27

Hi,

well, I see the patch has been commented for vuduo2.

There must be some work in progress.

 

diff --git a/meta-openpli/recipes-mediacenter/kodi/kodi_18.bbappend b/meta-openpli/recipes-mediacenter/kodi/kodi_18.bbappend
index 473f2607..a5d1d2e0 100644
--- a/meta-openpli/recipes-mediacenter/kodi/kodi_18.bbappend
+++ b/meta-openpli/recipes-mediacenter/kodi/kodi_18.bbappend
@@ -43,7 +43,7 @@ EXTRA_OECMAKE_append_gbue4k       += " -DWITH_V3D=nxinit"
 
 #Vuplus
 #SRC_URI_append_vusolo2     += " file://egl/EGLNativeTypeV3D-vuplus.patch"
-#SRC_URI_append_vuduo2      += " file://egl/EGLNativeTypeV3D-vuplus.patch"
+SRC_URI_append_vuduo2      += " file://egl/EGLNativeTypeV3D-vuplus.patch"
 #SRC_URI_append_vusolose    += " file://egl/EGLNativeTypeV3D-vuplus.patch"
 SRC_URI_append_vusolo4k    += " file://egl/EGLNativeTypeV3D-vuplus4k.patch"
 SRC_URI_append_vuultimo4k  += " file://egl/EGLNativeTypeV3D-vuplus4k.patch"

I just let it build now.

 

--

 

Ah, I see a nasty Warning about host-contamination issues of gstreamer-1.14.2 .

In oe-core there is  since long a patch for this:

https://git.openembe...on.patch?h=zeus

 

I imagine you have good reasons to keep your copy of gstreamer instead of using the oe-core one.

 

Cheers

A.A.



Re: zeus vs dunfell #7 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 18 May 2020 - 10:02

Well, there must be some missing piece...and I have very low knowledge about v3d/egl and so on.

 

Now build stops at:

| /tmp/build/tmp/work/vuduo2-oe-linux/kodi/1_18.5+gitrAUTOINC+e9847bc017-r0/git/xbmc/windowing/egl/EGLNativeTypeSTB.cpp:35:10: fatal error: gles_init.h: No such file or directory
|    35 | #include "gles_init.h"
|       |          ^~~~~~~~~~~~~
| compilation terminated.

I'll better wait for feedback.

Thanks

A.A.



Re: zeus vs dunfell #8 WTE

  • Senior Member
  • 821 posts

+36
Good

Posted 18 May 2020 - 10:27

Hi,

well, I see the patch has been commented for vuduo2.

There must be some work in progress.

 

diff --git a/meta-openpli/recipes-mediacenter/kodi/kodi_18.bbappend b/meta-openpli/recipes-mediacenter/kodi/kodi_18.bbappend
index 473f2607..a5d1d2e0 100644
--- a/meta-openpli/recipes-mediacenter/kodi/kodi_18.bbappend
+++ b/meta-openpli/recipes-mediacenter/kodi/kodi_18.bbappend
@@ -43,7 +43,7 @@ EXTRA_OECMAKE_append_gbue4k       += " -DWITH_V3D=nxinit"
 
 #Vuplus
 #SRC_URI_append_vusolo2     += " file://egl/EGLNativeTypeV3D-vuplus.patch"
-#SRC_URI_append_vuduo2      += " file://egl/EGLNativeTypeV3D-vuplus.patch"
+SRC_URI_append_vuduo2      += " file://egl/EGLNativeTypeV3D-vuplus.patch"
 #SRC_URI_append_vusolose    += " file://egl/EGLNativeTypeV3D-vuplus.patch"
 SRC_URI_append_vusolo4k    += " file://egl/EGLNativeTypeV3D-vuplus4k.patch"
 SRC_URI_append_vuultimo4k  += " file://egl/EGLNativeTypeV3D-vuplus4k.patch"

I just let it build now.

 

--

 

Ah, I see a nasty Warning about host-contamination issues of gstreamer-1.14.2 .

In oe-core there is  since long a patch for this:

https://git.openembe...on.patch?h=zeus

 

I imagine you have good reasons to keep your copy of gstreamer instead of using the oe-core one.

 

Cheers

A.A.

VU+ and certain on an older Mipsel box I doubt it will run well.

I think you miss a second hashtag:

https://github.com/O...18.bbappend#L55

 

Please report if build goes well and that it starts or not.


Mut@nt HD51 STB 4K

   :rolleyes:                :rolleyes:


Re: zeus vs dunfell #9 WanWizard

  • PLi® Core member
  • 70,277 posts

+1,799
Excellent

Posted 18 May 2020 - 11:01

I have a feeling, reading all this, that some believe that zeus is ready for use.

 

It isn't, correctly we're working on the first step, the upgrade from pyro to zeus. None of the other potential issues have been looked at, and that includes gstreamer versions, kodi, hbbtv, etc.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: zeus vs dunfell #10 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 18 May 2020 - 11:20

 

Hi,

well, I see the patch has been commented for vuduo2.

There must be some work in progress.

 

diff --git a/meta-openpli/recipes-mediacenter/kodi/kodi_18.bbappend b/meta-openpli/recipes-mediacenter/kodi/kodi_18.bbappend
index 473f2607..a5d1d2e0 100644
--- a/meta-openpli/recipes-mediacenter/kodi/kodi_18.bbappend
+++ b/meta-openpli/recipes-mediacenter/kodi/kodi_18.bbappend
@@ -43,7 +43,7 @@ EXTRA_OECMAKE_append_gbue4k       += " -DWITH_V3D=nxinit"
 
 #Vuplus
 #SRC_URI_append_vusolo2     += " file://egl/EGLNativeTypeV3D-vuplus.patch"
-#SRC_URI_append_vuduo2      += " file://egl/EGLNativeTypeV3D-vuplus.patch"
+SRC_URI_append_vuduo2      += " file://egl/EGLNativeTypeV3D-vuplus.patch"
 #SRC_URI_append_vusolose    += " file://egl/EGLNativeTypeV3D-vuplus.patch"
 SRC_URI_append_vusolo4k    += " file://egl/EGLNativeTypeV3D-vuplus4k.patch"
 SRC_URI_append_vuultimo4k  += " file://egl/EGLNativeTypeV3D-vuplus4k.patch"

I just let it build now.

 

--

 

Ah, I see a nasty Warning about host-contamination issues of gstreamer-1.14.2 .

In oe-core there is  since long a patch for this:

https://git.openembe...on.patch?h=zeus

 

I imagine you have good reasons to keep your copy of gstreamer instead of using the oe-core one.

 

Cheers

A.A.

VU+ and certain on an older Mipsel box I doubt it will run well.

I think you miss a second hashtag:

https://github.com/O...18.bbappend#L55

 

Please report if build goes well and that it starts or not.

 

Uncommenting both

SRC_URI_append_vuduo2 += " file://egl/EGLNativeTypeV3D-vuplus.patch"

and

EXTRA_OECMAKE_append_vuduo2 += " -DWITH_V3D=vumips"

 

leads to immediate failure:

 

Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: VERBOSE=1 cmake --build /tmp/build/tmp/work/vuduo2-oe-linux/kodi/1_18.5+gitrAUTOINC+e9847bc017-r0/build --target all -- -j 8
| ninja: error: '/tmp/build/tmp/work/vuduo2-oe-linux/kodi/1_18.5+gitrAUTOINC+e9847bc017-r0/git/xbmc/windowing/egl/gles_init.a', needed by 'kodi-stb', missing and no known rule to make it

No luck today...

 

In the commits I have spotted "Zeus: kodi: fix type STB->VD3" but really have no idea about video drivers on STB...sorry can't help.

 

On the positive side, I have seen around that other 'distros' do have kodi 18 for vuduo2 so it is possible...

We'l see

 

Thanks

A.A.

 

 

 

A.A.



Re: zeus vs dunfell #11 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 18 May 2020 - 11:31

I have a feeling, reading all this, that some believe that zeus is ready for use.

 

It isn't, correctly we're working on the first step, the upgrade from pyro to zeus. None of the other potential issues have been looked at, and that includes gstreamer versions, kodi, hbbtv, etc.

From the perspective of a developer zeus is practically in sync with -dev branch, at least github shows that.

So I would guess that the new 7.3 release will be based on this.

Apart kodi, all builds just fine here so good news.

 

But as long-time OE developer I am puzzled by the quantity of warnings I spot in the logs.

The zeus/dev branch has a long way to be really clean... :)

 

Ah, while on topic I'd move asap to dunfell.

Many fixes have been implemented there in the OE layers.

 

Finally, a ton of custom recipes...

 

andrea@andrea-ThinkPad-T520:/oe/openpli-oe-core/build$ bitbake-layers show-overlayed
NOTE: Starting bitbake server...
Loading cache: 100% |###################################################################################################################################| Time: 0:00:00
Loaded 4145 entries from dependency cache.
Parsing recipes: 100% |#################################################################################################################################| Time: 0:00:12
Parsing of 3273 .bb files complete (2983 cached, 290 parsed). 4435 targets, 620 skipped, 0 masked, 0 errors.
=== Overlayed recipes ===
cdparanoia:
  meta-openpli         10.2+svnr17289
  meta-multimedia      10.2
gstreamer1.0:
  meta-openpli         1.14.4+gitAUTOINC+3c586dec93
  meta                 1.16.1
gstreamer1.0-libav:
  meta-openpli         1.14.4+gitAUTOINC+1c21e61bc1
  meta                 1.16.1
gstreamer1.0-plugins-bad:
  meta-openpli         1.14.4+gitAUTOINC+566e4ecc22
  meta                 1.16.1
gstreamer1.0-plugins-base:
  meta-openpli         1.14.4+gitAUTOINC+384ff7d026
  meta                 1.16.1
gstreamer1.0-plugins-good:
  meta-openpli         1.14.4+gitAUTOINC+d88d1b0e43
  meta                 1.16.1
gstreamer1.0-plugins-ugly:
  meta-openpli         1.14.4+gitAUTOINC+e1bf2aa184
  meta                 1.16.1
icu:
  meta-openpli         58.2
  meta                 64.2
joe:
  meta-openpli         3.7
  meta-oe              4.6
libdvdnav:
  meta-openpli         5.0.4+gitAUTOINC+0e0ed2a574
  meta-multimedia      5.0.3
libdvdread:
  meta-openpli         5.90.0+gitAUTOINC+5ec4095088
  meta-oe              6.0.1
libnss-mdns:
  meta-openpli         0.14.1
  meta                 0.10
libsdl2:
  meta-openpli         2.0.10
  meta                 2.0.10
libupnp:
  meta-openpli         1.6.22
  meta-multimedia      1.8.4+gitAUTOINC+d5a01fc989
minidlna:
  meta-openpli         1.2.2+gitAUTOINC+c3e3b3ff49
  meta-multimedia      1.2.1
mmc-utils:
  meta                 0.1+gitAUTOINC+aef913e31b
  ?                    0.2 (skipped)
mtd-utils:
  meta-openpli         2.0.0
  meta                 2.1.1
openvpn:
  meta-openpli         2.4.7
  meta-networking      2.4.7
p8platform:
  meta-openpli         2.2.0
  meta-oe              2.1.0.1
sysvinit-inittab:
  meta-openpli         2.88dsf
  meta                 2.88dsf
tzdata:
  meta-openpli         2019c
  meta                 2019c
udev-extraconf:
  meta-openpli         1.1
  meta                 1.1
wireguard-module:
  meta-openpli         1.0.20200413
  meta-networking      0.0.20190913
wireguard-tools:
  meta-openpli         1.0.20200319
  meta-networking      0.0.20190913
wireless-regdb:
  meta                 2019.06.03
  ?                    2018.10.24
=== Overlayed classes ===
machine_kernel_pr.bbclass:
  meta-oe
  meta-openpli
andrea@andrea-ThinkPad-T520:/oe/openpli-oe-core/build$
 

 

 

 

I'll help where I can

Cheers

A.A.



Re: zeus vs dunfell #12 WTE

  • Senior Member
  • 821 posts

+36
Good

Posted 18 May 2020 - 11:39

Vu+ made a bit of mess and don't add the right stuff in BSP layer.

 

For quick fix add follow file in your zeus branch

https://github.com/O...kodi-vuplus.inc

https://github.com/O.../kodi-empty.inc

 

I think follow is enough for your build in https://github.com/O...odi_18.bbappend

EXTRA_KODI_empty ?= " "

EXTRA_KODI_vuduo2 = "vuplus"
require kodi-${EXTRA_KODI}.inc


Mut@nt HD51 STB 4K

   :rolleyes:                :rolleyes:


Re: zeus vs dunfell #13 WanWizard

  • PLi® Core member
  • 70,277 posts

+1,799
Excellent

Posted 18 May 2020 - 12:23

I haven't seen so many warnings in my test build, apart from the VU+ ones.

 

As to the overlays, some are needed (for example cdparanoia and tremor), some might be left-overs from develop/Pyro and may no longer be needed.

 

And gstreamer hasn't been looked at at all, afaik.

 

Currently, the focus in on getting zeus ready for merge back into develop, so we can make a final Pyro release (7.3) and move on to OpenPLi 8.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: zeus vs dunfell #14 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+541
Excellent

Posted 18 May 2020 - 14:13

It seems developers are well to eager to have the all-latest stuff, but we have to remember we're doing this for the users, not for ourselves. The user frankly won't care if he's running an image on thud, zeus or dunfell. The user cares whether there are frequent releases that fixes their bug reports and introduces some nice new features. So let's not get carry away and for now focus on a zeus release. Remember we already skipped sumo and thud in releases, the 7.0 version has been quite some time ago now and it means most users are still running pyro!


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: zeus vs dunfell #15 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 19 May 2020 - 09:25

Vu+ made a bit of mess and don't add the right stuff in BSP layer.

 

For quick fix add follow file in your zeus branch

https://github.com/O...kodi-vuplus.inc

https://github.com/O.../kodi-empty.inc

 

I think follow is enough for your build in https://github.com/O...odi_18.bbappend

EXTRA_KODI_empty ?= " "

EXTRA_KODI_vuduo2 = "vuplus"
require kodi-${EXTRA_KODI}.inc

 

 

Ah ok, the vuplus package provides the missing bits.

However, in that vuplus.inc there is a patch for a missing Makefile.in ...that was before 18 I think...

 

Well, using the private stuff the build proceeds but errors out at EGLUtils.cpp and GLUtils.cpp. Here the headers do not define some stuff...I see in the sources there are the same missing bits for Raspberry PI so I did comment out the code. See first example:

 

99 {
100 //! @todo remove when Raspberry Pi updates their EGL headers
101 #if !defined(TARGET_RASPBERRY_PI)
102 X(EGL_DEBUG_MSG_CRITICAL_KHR),
103 X(EGL_DEBUG_MSG_ERROR_KHR),
104 X(EGL_DEBUG_MSG_WARN_KHR),
105 X(EGL_DEBUG_MSG_INFO_KHR),

 

After this change both files compile but the build crashes again:

 

| /tmp/build/tmp/work/vuduo2-oe-linux/kodi/1_18.5+gitrAUTOINC+71ada2cd24-r0/git/xbmc/cores/VideoPlayer/VideoRenderers/VideoShaders/VideoFilterShaderGLES.cpp:101:24: error: 'GL_RGBA_EXT' was not declared in this scope; did you mean 'GL_BGRA_EXT'?
|   101 |     m_internalformat = GL_RGBA_EXT;
|       |                        ^~~~~~~~~~~
|       |                        GL_BGRA_EXT

 

I am pretty sure I must apply the changes as in the  Makefile-vuplus.patch but the sources are huge. Any pointer?

Thanks

A.A.


Edited by A.A., 19 May 2020 - 09:27.


Re: zeus vs dunfell #16 WTE

  • Senior Member
  • 821 posts

+36
Good

Posted 19 May 2020 - 15:33

That are probably the OpenGL header files. You need to manual replace it with latest one.

File from VU: BSP: http://archive.vuplu...90429.r0.tar.gz

Replace the include files with newer version like https://github.com/K...tree/master/api   https://github.com/K...tree/master/api

 

Use the file and not http in: https://github.com/v...ers/libgles.inc

 

Then I think your a step further again.


Edited by WTE, 19 May 2020 - 15:36.

Mut@nt HD51 STB 4K

   :rolleyes:                :rolleyes:


Re: zeus vs dunfell #17 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 19 May 2020 - 18:12

Hi,

 

I have rebuilt the libgles-vuduo2 with the latest headers.

These are now pulling in x11...

 

| /tmp/build/tmp/work/vuduo2-oe-linux/kodi/1_18.5+gitrAUTOINC+cccfc560be-r0/recipe-sysroot/usr/include/EGL/eglplatform.h:128:10: fatal error: X11/Xlib.h: No such file or directory
|   128 | #include <X11/Xlib.h>

Is there any 'working' headers-release?

Cheers

A.A.



Re: zeus vs dunfell #18 WTE

  • Senior Member
  • 821 posts

+36
Good

Posted 19 May 2020 - 18:31

add in machine config file: DISTRO_FEATURES_remove = "x11"


Mut@nt HD51 STB 4K

   :rolleyes:                :rolleyes:


Re: zeus vs dunfell #19 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 19 May 2020 - 23:33

add in machine config file: DISTRO_FEATURES_remove = "x11"

No, it's not that.

I updated all the headers apart eglplatform.h which seems just needing EGL_CAST()

 

/* C++ / C typecast macros for special EGL handle values */
#if defined(__cplusplus)
#define EGL_CAST(type, value) (static_cast<type>(value))
#else
#define EGL_CAST(type, value) ((type) (value))
#endif

With these changes the build goes up 99%....then linker error

 

 

| /tmp/build/tmp/work/vuduo2-oe-linux/kodi/1_18.5+gitrAUTOINC+cccfc560be-r0/recipe-sysroot-native/usr/bin/mipsel-oe-linux/../../libexec/mipsel-oe-linux/gcc/mipsel-oe-linux/9.2.0/ld.gold: error: cannot find -lxbmc_base
| gles_init.cpp:145: error: undefined reference to 'NEXUS_Platform_Allow'
| collect2: error: ld returned 1 exit status

 

I suppose the fixes for kodi 17 Makefile.in would do the trick

 

https://github.com/O...le-vuplus.patch

 

OFC these must be adapted to the new sources...these are huge and I need more time/help...

 

Cheers

A.A.



Re: zeus vs dunfell #20 A.A.

  • Senior Member
  • 391 posts

+8
Neutral

Posted 20 May 2020 - 21:20

Kodi_18 built fine (lib added by hand)!

 

I suppose that this .inc has some issues.

 

https://github.com/O...kodi-vuplus.inc

 

FYI I have commented

#SRC_URI_append = " file://egl/EGLNativeTypeV3D-vuplus.patch file://egl/Makefile-vuplus.patch"

and now I retry commenting

#PRIVATE_LIBS_${PN}_append = " libxbmc_base.so"

Just a bit more work..

Cheers

A.A.




2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users