Branch usage

[WanWizard]

@atvcaptain @Schimmelreiter @LraiZer @andyblac @plnick @jbleyel

Gents,

Who exactly is using the recipes from the repo, and who is still using the master branch? If no one, I would suggest to do a bit of housekeeping, and get rid of the current master, and rename upstream to master.

Any objections?

[LraiZer]

No objections from me.

It's also OK for me.

[WanWizard]

Thanks for the feedback.

I can see that OpenWebIf is very active, and a handful of others had commits this year to, but others? Any of you still using this repo or any of the other repo's? Or do your projects work with own forks?

[Schimmelreiter]

All oe-a images (OpenATV, OpenHDF, OpenViX, ...) get their OpenWebif built from a fork of the OpenWebif master branch (Though I managed to keep it identical except for one file and some deletions).

I have no clue about the rest of the E2OpenPlugins.
I think they are built directly from E2OpenPlugins, but I would have to check which branch.

[WanWizard]

Ok, if you want to, please. I hate to break something for one of you...

[WanWizard]

@Schimmelreiter if everyone else uses a fork, isn't it better if OpenPLi uses the same fork, so it saves you the trouble of keeping the repo's in sync? We commit in the E2OpenPlugins, and bi-directional syncing is a nightmare you would want to avoid...

[Schimmelreiter]

The main difference between E2OpenPlugins' OWIF and that of oe-a is the removal of box and remote control images and the box detection quirks as oe-a has a proper boxbranding module.
In oe-a images, we can use just one OWIF ipk for all boxes, as the boxbranding module provides the box & remote images.
The boxbranding module makes it much easier to implement new boxes, as it concentrates all the diffs between boxes (Kernel partition name, rootfs partition name, flash file system used, box image, remote image, remote button map, ...) in just one file/ipk, from where it can be used everywhere (GUI help, OWIF, image backup/restore, ...).

That one diff is bearable, I just pull the changes from here and keep deleting those files on oe-a.
And as far as I know, OpenPLi refuses to use something as simple as boxbranding, which for example made porting multiboot for OpenPLi a nightmare.

Only one file really differs beyond "exists here and doesn't there":
The py doing the interaction with the transcoding settings, but it rarely ever gets changed at all.

It actually was a nightmare to get the forks in sync again due to previous white-space and other "no-change" diffs, but now it's a one-way sync. All changes get applied here and merged to oe-a fork.

And there are actually two more teams using the E2OpenPlugins repo for OWIF: VTI and Black Hole (But only for Black Hole, not OpenBH).

[WanWizard]

Ok, clear. Are VTI and BH included in this topic, or do we need to invite them to sort this out (I don't know who is "in charge" of which image)?

I would like to go back to a single version of OWIF and get rid of the fork. Not sure why OpenPLi has a bbappend that removes images, perhaps something from the past, to save space? I honestly don't see the point.

As to the boxbranding, I would like to have an all-image-builders discussion about that as well, because all different solutions are a pain for anyone wanting to develop generically, across images. We would like to propose to create a driver, that creates unified and standardized nodes in "/proc/image", which could be set and determined at compile time. With things like the boxname (vuduo2), boxdesc ("Vu+ Duo2"), nodes about features (OSD size (720/1080), Transcode yes/no, ...) and so on.

It would greatly reduce all detection code, sniffing for diffs between boxes, panicking about boxes that don't have any diffs (like the Miracblebox Premium Twin+ and the new SAB Alpha Triple HD), etc.

Is this worth having a chat about?

[Schimmelreiter]

plnick is from VTi, dunno about BH.

Image removal probably happens due to space considerations. The more boxes E2 supports, the more images get added and a universal IPK would become huge.

All that you suggest for that driver is already done inside the boxbranding module. It's set at image build time and contains human readable vendor and box names, short names (procmodel), the distro name and version, ... and an image of the box and the original remote. All the silly code in owibranding.py of OWIF is unneeded on oe-a images as there is a clean API to get the desired information. It even allows customized builds for identical hardware in different cases/with different remotes, e.g. there are different builds of OpenATV for the Mut@nt HD2400 as well as the AX Quadbox HD2400, which are in fact OEM builds of the same box.

There is no need to re-invent the wheel:
https://github.com/oe-alliance/branding-module

[WanWizard]

You absolutely have a point. I don't know where the aversion against OE-A comes from, that was from before my time, but I am happy to discuss it again. After all, double effort is effort lost.

The main issue I have with the OE-A branding module as it is at the moment, is that its functionality is limited to Python only. If would have been better if it was a lib with both C/C++ and Python bindings, so it can be used anywhere in the codebase. For example, streamproxy needs exactly the same info. It would be great if it could be unified.

[WanWizard]

After a bit further digging into OE-A sources, I bumped apon boxinput, a kernel driver which adds some missing proc nodes for certain VU+ models. This is very similar to my original suggestion.

I have discussed this issue with some of the team members: the general consensus is that if the current OE-A boxbranding could be converted to a lib with C/C++ and Python bindings, the current Python API would remain unchanged, and access from the C code could be guaranteed in a unified way, with the same API.

[WanWizard]

@E2OpenPlugins/devs Coming back to this topic.

Is there anyone that uses this repo in it's current form, as-is, in his own project? I see that OE-A uses a fork of this repo, and hasn't done a merge since 2014. What do other projects do?

For OpenPLi using this repo and have publicly maintained recipes is turning out to be more and more of a nightmare, now that we have different image versions and a requirement to have different recipes with different SRCREV's for each of them.

So we're going to stop using this repo. If nobody else is using it, maybe it is better to simply remove if, and save everyone the time updating it?

[WanWizard]

@plnick @Schimmelreiter @andyblac @arn354 @atvcaptain ping?

[atvcaptain]

you have answer self oe.a teams use oe-a fork

vti no infos

[WanWizard]

Yeah, just checking to make sure I don't break something for someone. Thanks for the response.