120 replies to this topic

[foxbob]

Look please,corrected meta-gi for gcc 9.0 for gi-et11000-https://github.com/6...gi/commits/zeus.

[athoik]

I think it looks great! Well done foxbob!

 

The meta repo's in the OpenPLi organisation are used by us for development of the next major release, as a place to store WIP in BSPs (we can't use branches, as we have no access to vendor BSPs). We would like to keep those separate from the BSPs we build from.
 
So it is probably the best to create a separate github account for it.

As for its name and description, for me it is ok to show these repo's are meant to be used by OpenPLi, but it must be clear we (as the OpenPLi team) don't maintain them, it is a community effort. So don't call it OpenPLi-BSPs or so...
Note that individual OpenPLi team members, on personal title, are also community members, so obviously they can send in PR's too...

 

The repo is on github.com and on personal account 68foxboris forked on meta-gi. Exactly what @WanWizard mentioned above.

 

 

 

BSPs that need a new home: meta-dream, meta-gi, meta-miraclebox, meta-sab, meta-spycat, meta-xpeedc and meta-xtrend.
 
Anyone else wants to toss their cents on the table?

 

So that means we have a maintainer for meta-gi

 

meta-gi: foxbob

 

[WanWizard]

I'd rather have a central place for all BSP's, instead of scathered over multiple personal repos.

 

If Neo and FoxBob want to share the work, or Neo wants to give FoxBob access, fine by me, they can arrange that by themselfs I think...

[athoik]

So we expect an institution like OpenPLi-Community to appear and people to gather all abandoned BSP's there.

That wasn't clear on me.

[rantanplan]

You also saved the ex locally separately.
Most of them are already fixed.
Why can't you fall back on it?
The work has already been done.

 

https://github.com/O...trend/tree/zeus

[WanWizard]

So we expect an institution like OpenPLi-Community to appear and people to gather all abandoned BSP's there.

 

Not expect, but I think it's handy, and it's what Neo has offered to do.
 

[boki15]

 

Anyone else wants to toss their cents on the table?

 

I checked one of my pockets, if you find it useful, I might look in other pockets too, there are few cents for sure.

 

The meta repo's in the OpenPLi organisation are used by us for development of the next major release, as a place to store WIP in BSPs (we can't use branches, as we have no access to vendor BSPs). We would like to keep those separate from the BSPs we build from.

So it is probably the best to create a separate github account for it.

As for its name and description, for me it is ok to show these repo's are meant to be used by OpenPLi, but it must be clear we (as the OpenPLi team) don't maintain them, it is a community effort. So don't call it OpenPLi-BSPs or so...

BSPs that need a new home: meta-dream, meta-gi, meta-miraclebox, meta-sab, meta-spycat, meta-xpeedc and meta-xtrend.

 

- maybe as subtree's/submodules? Why new account, it makes it only harder to remember, why not with current OpenPli? Users do not need to PR it each time they change it if you want to use their sources and maybe add some changes (or none), same concept could be used for enigma2 and other repositories. Central point for everything should be OpenPli and no other, additionally, if you have some third party repos like from some vendor, then add them as submodules/subtrees as they are not maintenanced by you as well as you do not wish to have any changes, as example leveldb would be something that I would not like any user or contributor to change and if, then it should be PR to maintenancer repo not my as I have none because I do not need to have (from your perspective). For whatever you are not responsible and are not the maintenancer, add it as subtree/submodule.

 

  Your users might get it more complicated to contribute if you use submodules/subtrees, make sure you document the build, release, build and contribution process well if you use them.

 

  Discussion on stackoverflow about when to use git subtree submodule: https://stackoverflo...ubtree#33579069

 

- You should information about project owners and contributors somewhere in your repository, as example, create information document: /share/certs/PrivateKeyNotes.md and place public keys of OpenPli team, like OpenPli.pem, WanWizzard.pem, etc... . Users can use their keys for different type of verification (like release signatures) or even encryption if they want to send you some sensitive information (like some log parts) or simply email communication.

 

- I find no way to verify who of you is who, like if your account gets hijacked (Forum/Github). The information should include basic info of why GPG keys there as well as for what. Like WanWizzard losing his notebook and somebody else maintenancing it. All commits should be signed too as with same GPG.

 

- In theory you could use different tools and ways how you can compile, build images and release them with release notes fully automatic, that can also include some tools and scripts for desktop OS, launchpad, snapcraft etc... all of them would do the job

 

- Pull requests must have signed commits and existing user on github

 

- There must be contribution.md or similar document which explains it all, if there is none, then those overtaking this task need to learn it anyway and document it for themself, this is how the document could be written for first time if it is not existing, as explaining once is easy if you have a link next time.

 

- Discussion about all of this should actually take place on github directly, not here. If the problem is community not using github or not being used to git, then it is a problem you should deal with to change it asap.

[WanWizard]

Not sure I follow you.

 

BSP's are already git submodules, and have been for many years, and we don't want then under the OpenPLi organisation because we don't / won't maintain and support them. We therefore don't need to document them either, they are not ours.

 

The rest of your post isn't really about the task at hand, it is up to Neo.

 

And your last remark is imho completely off, 99.9% of "the community" aren't developers, why should we force end-users to create github accounts?

[boki15]

 

Not sure I follow you.

 

BSP's are already git submodules, and have been for many years, and we don't want then under the OpenPLi organisation because we don't / won't maintain and support them. We therefore don't need to document them either, they are not ours.

 

I guess you are right, you did not follow me or I explained it badly.

 

You do have somewhere a guide how to build? I did not look for one and so did not find any and would guess that if one is not being found easily, you actually do not want your users to build images, right? Since when does a user need to be developer to run one script? Including the other part about GPG, every user could/should have ability to verify your builds as well as users, that is normally done by rebuilding whole image and all dependencies. For that case, you need to build your images verifyable (different way how you can achieve it). This way anybody could verify the build as well as check the signature. Gitian would come to my mind, but it can be achieved easier. If all of that is existing, your users would have ability to verify your builds which is today quite important, many people run Enigma on devices which are not meant to be most secure and I saw in past many people installing some images which were never officially released. Very nasty things could be included in such images (before and after the release).

 

 

And your last remark is imho completely off, 99.9% of "the community" aren't developers, why should we force end-users to create github accounts?

 

This is nonsense, a myth pushed many years ago like if github would be for developers only?? Oh no, that is not only for developers and yes it offers you tools to make your users life easier. However, no, users do not need new account to read the info or download, by that your argument fails into the watter. If you dislike for some reason the default view on github you always can activate gitpages which would show you those md's as html too, making it pretty for your users and according to your needs.

 

On other side, if somebody wants to contribute, the person is then forced to create here account to talk, then github account to contribute???  Makes no sense at all what you say, especially taken in mind that this forum is totaly outdated in all meanings. Visiting this forum is a security threat as well as having account here. Well, to confirm it once again, to enter your development area here a user needs account here where the user has no proper security offered here.

 

Those links to development, as well as donation, they are all dead! You still pretend it but, yes you actually have huge overhead in running this forum and getting information from here to github, You actually shoot in your foot by saying that github is just for developers, it clearly is not the case.

 

There is a saying "Cat licks his balls and says tastes are different". I agree on that, I only suggested and you replied to it again by stating some myth's instead really valid factors, by that you make discussion about it impossible, however, I respect everybody pushing their "taste" as the only valid .

 

How can I build same image as your team to get my checksums and verify it by comparing it with your releases, for that you require fakeroot and few other things, but yeah, your repository could build on each commit for all available images automaticly (and for free) by that you simply need to decide when/which channels are release channels and which are update channels, you still can release them where they are.

 

Now that sounds nice for a non dev user, isn't it:

1. ability to check builds for validity

2. ability to test image of each commit (especially useful for devs and checks alongside travis)

3. no need for any account actually (even not of this forum)

4. choose a build from each commit

 

I could list more, but then I unsure if my thoughs get lost like so much on this forum.

[neo]

Allow me to ignore the non-topic posts here.

 

I have created https://github.com/neo-pli-bsps, and forked the repo's meta-gi, meta-miraclebox, meta-sab, meta-spycat, meta-xpeedc and meta-xtrend as currently used in OpenPLi OE.

 

I guess next up is change the submodule references, and send me PR's? Anything else I need to do now?

 

Tom.

[boki15]

 

I guess next up is change the submodule references, and send me PR's? Anything else I need to do now?

Maybe that all of this should be done automaticly

 

 

Allow me to ignore the non-topic posts here.

You did not ignore it by writting about it, you also did not specify who you asked.

 

I understand, testing images is not the same as building them. But building them can be 100% automated, you would only need to test when you got time. What is offtopic on that if we talk about models running out of life where the team struggles to keep it in hope to move it to community?

[neo]

Ehr...

I see that the xtrend BSP uses files downloaded from dropbox. Should that stay that way, looks a bit amateuristic to me? Should I try to come up with a better solution?

 

Tom.

[boki15]

 

Should I try to come up with a better solution?

 

Which should be what? You could have suggested it in last reply, ie. to add it.

 

Why do you change it at all, no need to do it, especially if you can patch it during the build process.

 

@WanWizzard

Changing sources? There is no license attached in those Xtrend repos, I see there none (did not look up further). Under which license is it released and are you allowed to change it at all?

 

Exactly those things make it less trustable.

[neo]

My question wasn't directed to you.

[WanWizard]

@neo,

 

Great, thanks.

 

As to dropbox, it does seem to work, but I'm not sure about the reliability. The question is what the alternative is going to be, especially for the files to large to be stored in the repo.

 

All I can see is that git LFS isn't an option, as that has unwanted client side dependencies.

[sjlouis]

If we can keep downloading the old Pli version for old boxes, it's good for me.

 

I have 1 ET9000 and 1 ET9100 and 2 Vu+ Ultimo 4k and I can say that the Xtrend drivers are much better than Vu+ drivers .

[WanWizard]

The idea is that with these BSP's we can continue building OpenPLi images for these boxes, for as long as the build succeeds and the hardware allows.

 

There will be some for which no OpenPLi 8 will be release, simply because of lack of flash space.

[sjlouis]

Yes I've understood, I only wanted to say that the existing versions are already very good. When we buy a smartphone, there is not new version very quickly . So, it's unexpected to have new versions so long for our boxes   .

[neo]

As to dropbox, it does seem to work, but I'm not sure about the reliability. The question is what the alternative is going to be, especially for the files to large to be stored in the repo.

 

All I can see is that git LFS isn't an option, as that has unwanted client side dependencies.

 

I've had some time to mull this over.

 

Not looking forward to setup (and maintain) an ftp or http server, only for this purpose, or creating a dependency on my own personal stuff.

 

Github doesn't allow files larger than 100MB in a repo (something you don't want anyway, as manipulations will take forever), but it does allow binaries in the releases section, max 2GB each.

 

So that would work fine I think (we don't expect any more kernel or driver updates for these BSP's do we?), and we can keep everything together. It is probably not a bad idea to do this for the other repo's too, we don't know how long the FTP server of those vendors remain operational (the one from Xtrend has also disappeared).
 

Tom.

[neo]

I've moved all binaries from dropbox to github, and updated the SRC_URI's. Haven't tried a build yet, so please wait with any changes in PLi-OE.