Jump to content


Member Since 10 Jun 2015
Offline Last Active 10 Jul 2022 10:16

Topics I've Started

DEFAULTTUNE for arm devices

12 November 2021 - 23:16



I was planning to verify the optimizations for kodi [1] but it seems that the same devices have different DEFAULTTUNE in OE-A.


Looking i.e. at meta-edison PLi has "armv7vehf-neon-vfpv4" and OE-A has  DEFAULTTUNE = "cortexa15hf-neon-vfpv4".

Now, is it possible to update/unify?


Sorry but I don't know the 'recent' arm incarnations :)







[1]  https://github.com/O...kodi_18.bb#L203



devel: OE recipes missing pkgconfig inherit

24 September 2021 - 19:10

Right these days on the OE mailing lists are flowing a number of big changes for master (next release after hardknott, honister).


Amongst these the one in topic: it appears that many recipes were missing that inherit.


See for oe-core



and meta-openembedded



I am pretty sure we should double check the recipes in meta-openpli as well.




necessary BSP adjustments for kodi 18 / CMake

22 September 2021 - 21:14

The final target is to have just a kodi_git.bbappend in OpenPLi.

To do this we have first to add meta-kodi layer and wait/work to have that in OE one day.


Immediate steps are:

 1 - more logic in the kodi recipe to add specific patches

 2-  move the EXTRA_OECMAKE_append_pn-kodi to the BSP layer.


This second step should be done possibly in parallel and sourcing from OpenPLi.

Now the problem: we have different definitions between OpenPLi and OE-A.


What here is


EXTRA_OECMAKE_append_pn-kodi = " -DWITH_V3D=nxcl"

there is


EXTRA_OECMAKE_append_pn-kodi = " -DWITH_V3D=nxclient"


and so on (more fiffs)


What is the right way to put that in the BSP? Mimic OE-A?



The final step is to actually build kodi for the machines having it in MACHINE_FEATURES and this is another round of BSP updates.


Please let me know, thx


develop: python3 transition

22 September 2021 - 15:27

I start this topic because I'd like to hear all developers voices about the transition towards python3.


Talking about OE/Yocto as of today meta-python2 layer is updated up to honister 3.4 (the next OE release, after hardknott 3.3) so enigma2 can be built and can run.


As for other recipes like samba, these can use python2 in hardknott but not in honister where the version is updated.


Kodi recipe is needing an upgrade to 18>19, this will be done soon after last finishes. We'll need a meta-kodi layer until the recipe flows in OE (if).


My feelings at the moment are mixed: I see many commits referring to the OE-A repository, where most commits are debatable.


I honestly would prefer to follow OE as much as possible and add less .bbappend(s) as possible.



devel-next: hardknott or honister

26 August 2021 - 10:18



just to start a discussion about the issues with the migration to recent OE:



+ we can keep samba with a minimal patch to use python2

+ we can keep the old _override operator

- kodi is stuck to 18.x



- newer samba: we must upgrade to python3

- tune-files have moved

- we must convert the override operator


As for the necessaries BSP changes, it could be done in one or two steps (overrides now, tune-files later).


Finally I see OE-A is using python3 for enigma images.

What is the status here?