2057 replies to this topic

[WanWizard]

Thanks, I also got them via betacentauri .

[WanWizard]

I've passed it on to Neo.

 

I've briefly looked at the first one, apart from the obvious ones, I see differences in "platform" and "friendlyfamily" (we don't use oem brand mapping) and rc information (missing from ours).

And differences because we use different machine names ( "alphatriple" vs "alfatriplehd", "h9" vs "zgemmah9s", etc)

 

I can't judge whether or not this is a problem, probably only if these values are used in code somewhere...

[WanWizard]

I already see an issue with the boxlogo repo, which uses OE-A's MACHINEBUILD variable (which we don't have), and OE-A's specific naming which deviates from the manufacturer.

 

This is going to be another hard-coded nightmare, like we have for OWIF...

 

edit:

 

The recipe also installs py files, which we don't do. This is far from a simple copy job...

[WanWizard]

Anyone have any suggestions how to deal with this boxlogo mess?

 

This is another area where the assumption is made that the link box - MACHINE - image is always one on one, which isn't the case in OpenPLi (we don't know at build type whether the box is a zgemma h9s or h9t).

 

For the moment I'll simply skip them, it will probably mean complicated postinst code...

[Huevos]

I already see an issue with the boxlogo repo, which uses OE-A's MACHINEBUILD variable (which we don't have), and OE-A's specific naming which deviates from the manufacturer.

 

This is going to be another hard-coded nightmare, like we have for OWIF...

 

edit:

 

The recipe also installs py files, which we don't do. This is far from a simple copy job...

We talked about boxlogo yesterday. Littlesat agreed that the py code should be in the package because it is the package that uses it. That was before it was added. But PLi can do as it pleases. You can install the py file in core and not fetch it in the boxlogo recipe/package.

 

And as far as machine names, we can add logos to the repo where the box names don't match.
 

Edited by Huevos, 22 December 2023 - 19:41.

[littlesat]

Sorry to say… as actually you somehow twisting my words. I suppose this is not on purpose.
First the design of skinning is bad.
Therefore a py file in a skin should be avoided.
As this py code may also be used for other skins I think the best location is having it into the image
But dimararCC managed other images need to be convinced aswell.
So I drafty compromise to put it in this package. This is different from agreeing it. I prefered to have it in the image.
Afterwards this package seem to be complicated due to the build environment differences and boxnames.

I made for cross image flashing a big Json file thing on github. I hope it is maintained and not forked and then maintained. It has/had all possible box models for openpli aswell oe-a. So please yes add the openpli box names and in between also ask owif 2.0 or see that they also adapt to our names.

Edited by littlesat, 22 December 2023 - 20:43.

[WanWizard]

We talked about boxlogo yesterday. Littlesat agreed that the py code should be in the package because it is the package that uses it. That was before it was added. But PLi can do as it pleases. You can install the py file in core and not fetch it in the boxlogo recipe/package.

 

That was not what I wrote. I wasn't commenting on code being present at all (I already did that, we've passed that station).

 

I was talking about installing py files, and running compileall in the doinstall. We only install pyc files.

 

Which means our bb recipe's are signifiicantly different from OE-A's and not simply a copy/paste.

[littlesat]

One of the reasons why our images are smaller as we do not install py files by default?

[DimitarCC]

I am not sure, but i think the recipe doesnt install plain py... I think it install pyc...

Regarding the package... Yes there are complications for the names. So as @Huevos said we have to add aditional logos with PLi names as well.

The recipe however have to be adapted for PLi due to the missing env variables.

About renderer.... Well renderer is useless without the logos. So i think its strait forward to be in that package.

If it is added as a dependency of a skin it will be installed only by skins that want logos...

[WanWizard]

Regarding the package... Yes there are complications for the names. So as @Huevos said we have to add aditional logos with PLi names as well.

 

Please don't do anything until Neo and I are finished with our work relating boxinfo, and we can see what gaps still remain. And then decide where and how to address those...

[littlesat]

@wanwizard… good plan… step by step.
@DimitarCC, just hold on…

Edited by littlesat, 22 December 2023 - 22:06.

[Huevos]

 

We talked about boxlogo yesterday. Littlesat agreed that the py code should be in the package because it is the package that uses it. That was before it was added. But PLi can do as it pleases. You can install the py file in core and not fetch it in the boxlogo recipe/package.

 

That was not what I wrote. I wasn't commenting on code being present at all (I already did that, we've passed that station).

 

I was talking about installing py files, and running compileall in the doinstall. We only install pyc files.

 

Which means our bb recipe's are signifiicantly different from OE-A's and not simply a copy/paste.

 

Well if you read the recipe you will see it only installs .pyc files.

https://github.com/o...boxlogos.bb#L39

[Huevos]

Sorry to say… as actually you somehow twisting my words. I suppose this is not on purpose.
First the design of skinning is bad.
Therefore a py file in a skin should be avoided.
As this py code may also be used for other skins I think the best location is having it into the image
But dimararCC managed other images need to be convinced aswell.
So I drafty compromise to put it in this package. This is different from agreeing it. I prefered to have it in the image.
Afterwards this package seem to be complicated due to the build environment differences and boxnames.

I made for cross image flashing a big Json file thing on github. I hope it is maintained and not forked and then maintained. It has/had all possible box models for openpli aswell oe-a. So please yes add the openpli box names and in between also ask owif 2.0 or see that they also adapt to our names.

Like I already said, you can do what you like in PLi. Using your own recipe you can decide what files go in the package.

Edited by Huevos, 22 December 2023 - 22:20.

[Huevos]

One of the reasons why our images are smaller as we do not install py files by default?

OE-A images don't include .py files in the main package either.

[littlesat]

And you can also install the py files with installing a -src package when you want that all on the last two lines.

Edited by littlesat, 22 December 2023 - 22:50.

[WanWizard]

Like I already said, you can do what you like in PLi. Using your own recipe you can decide what files go in the package.

 

Which is the only thing I said, that we can't copy/paste it. Don't make it bigger than it is....

[neo]

BSP's have been updated again based on the comparison with OE-A data. I've taken the liberty not to take over the errors in the OE-A data (of which there are quite a few).

[Huevos]

Which errors?

[neo]

I didn't keep them, but for example incorrect SOC_FAMILY values.

[neo]

BTW, what is the point of adding all those environment specific data to is, like imagedir for example? Or ubi  arguments?

 

Also, there are several values that aren't trimmed, so there is leading or trailing whitespace in the file.

 

Oh, and while we're at it, what is the difference between transcoding and multitranscoding (apart from it appears OE-A has different plugins for both)?

Edited by neo, 23 December 2023 - 18:32.