195 replies to this topic

[bacicciosat]

Hm, so how do you design a screen to work on both SD and HD skins?

I stopped to support SD skins form long time.
If you want to mantain relarive position the only solution i see is to prepare a page of the project where to explain perequisites like
gitpkgv.bbclass and e2 skin relative position patch providing files to download and instructions to add class and patch.

[MiLo]

I think we have to be compatible with official e2 repos.

Why? All we need to do is just agree on what we all support... One could even include a patch to add support for it.

[bacicciosat]

Because there are hundred of users with many teams images that are not compatible with your plugins including all the users of the teams here (Bh, Vti, Sif).
We can patch our e2 version to be compatible with your skin par syntax but i don't think that all other teams will do and the users with current or older images version will be always not compatible.

But there is not problem for me. We can do as you want. Use a patch or add a package-patch and include dependency.... The solution you prefer is ok for me.

[babsy98]

good idea ,

babsy98 from AAF DEV TEAM

[skaman]

Hi guys,
last weekend i started to move my main project crossepg from google code to our new repo on github.

When i checked e2openplugins repo i saw all .bb examples but i've a some concerns:
- No SRCREV is provided in any package. It compile the last GIT commit at the time of compilation
- If i recompile my image one week later bitbake doesn't understand what it need to recompile
- The version with the "git commit id" is useful if you need to check the source in the git repo.. but it doesn't permit to understand how many old is the plugin and comparing two version you can't understand what is the newer (you can do it only checking the history on git repo)

Obviously they are only examples.. so i can change it manually as I prefer... but every time i need to update SRCREV and version manually and i'm REALLY REALLY LAZY
In addiction to that many people could find complicate use and maintain that in their images. There is many people who maintain slightly enhanced svn images and not a real customized image.

To solve this i made a python script (attached to the post).
The tar.gz contain:
- e2openplugins-example -> a set of .bb fixed to be used with that script
- e2openplugins.patch -> a patch to fix actual .bb format to the new one
- task-openplugins.bb -> a task to compile all plugins in one shot
- README -> the instructions
- e2openplugins-update.py -> the script

Simply run the script as
python e2openplugins-update.py /output/path/
it download the .bb files from e2openplugins repo.. discover all modules.. download the repo for every module and it check the last commit date, the commit id and the version number (if a file VERSION is provided). After that with some replace add that information inside the .bb files creating a set of .bb with an exact SRCREV SRCDATE SRCVER.

When the plugin will be compiled it look like that: enigma2-plugin-extensions-antilogo_1.0-20110923+git9cdd68-r0_mipsel.ipk
As you can see there is a version and a date.. the git commit id is truncated to only 6 chars. I did that because i retain the file name is more readable. And in association with the date is sufficient to understand the exact source version inside the repo.

What do you think? If it's ok i'll commit that on github. For the script i thought to create a separate repo e2openplugins-script

Attached Files

•  e2openplugins-script.tar.gz   4.38KB   15 downloads

[skaman]

About the "skins problem" i'm seeing pieterg posted about 1 our ago the file "0001-skin-add-support-for-relative-coordinates.patch" .. thanks for that
I've no problem to apply that to sifteam image but i'm also thinking about the people who want use e2openplugins with a dmm svn image.
Do you think there is the possibility to propose this patch directly to dmm so they apply directly on the official enigma2 trunk?

[pieterg]

- No SRCREV is provided in any package. It compile the last GIT commit at the time of compilation

I stumbled upon that as well, yesterday I added a default SRCREV in the inc file to fix that.

- If i recompile my image one week later bitbake doesn't understand what it need to recompile

Depends on which SRCREV you use, if you use AUTOREV, it will recompile if the HEAD has changed.
If you use a fixed git hash, it'll stick to that.

- The version with the "git commit id" is useful if you need to check the source in the git repo.. but it doesn't permit to understand how many old is the plugin and comparing two version you can't understand what is the newer (you can do it only checking the history on git repo)

True, that's why we do not use the git commit id, but GITPKGV, which is a combination of commit hash and sequential number.

I think you should have a look at what nice features more recent bitbake versions have to offer, especially for building from git SRC_URI's.
It's really been improved over the last few years.

[pieterg]

About the "skins problem" i'm seeing pieterg posted about 1 our ago the file "0001-skin-add-support-for-relative-coordinates.patch" .. thanks for that
I've no problem to apply that to sifteam image but i'm also thinking about the people who want use e2openplugins with a dmm svn image.
Do you think there is the possibility to propose this patch directly to dmm so they apply directly on the official enigma2 trunk?

I've offered it to them several years ago, but they were not interested.
And nowadays I feel a bit reluctant to offer GPL stuff to them, because strictly speaking that means I remove the GPL license from that piece of code, allowing it to be placed under a custom license, which is incompatibel with GPL.
And although I could do that for something which is my own creation, I cannot do that with code which belongs to a project with a group of people who contributed under the current license.

[pieterg]

And nowadays I feel a bit reluctant to offer GPL stuff to them, because strictly speaking that means I remove the GPL license from that piece of code, allowing it to be placed under a custom license, which is incompatibel with GPL.

And of course my reluctance has gotten a lot bigger lately, when we got a demonstration of what happens when you allow stuff to be published under such weird licenses.
At first the license allowed non-commercial use without limitation, however, it turns out even the PLi team, a group of hobbyists without any commercial interests, has been explicitly denied the right to use certain plugins.

This might not have been the intention of DMM, so I do not directly blame them for what happened, but they did make all this possible with their custom license.

[skaman]

I think you should have a look at what nice features more recent bitbake versions have to offer, especially for building from git SRC_URI's.
It's really been improved over the last few years.

Yeah.. you're right
enigma2-plugin-extensions-antilogo_1.0+git3+9cdd68f-r1_mipsel.ipk
I suppose "git3" mean the third commit inside the git repo
So if i compile it again the next week it auto discover the updates checking from the git HEAD? good to know

I sill also interested to add at least the task and some instructions inside the README

[skaman]

I added crossepg recipe inside the repo... for now crossepg doesn't use auto tools but it use an "home made" makefile. Someday i'll change it to use autotools
I also added the example task and the README

[pieterg]

I think you should have a look at what nice features more recent bitbake versions have to offer, especially for building from git SRC_URI's.
It's really been improved over the last few years.

Yeah.. you're right
enigma2-plugin-extensions-antilogo_1.0+git3+9cdd68f-r1_mipsel.ipk
I suppose "git3" mean the third commit inside the git repo
So if i compile it again the next week it auto discover the updates checking from the git HEAD? good to know

Indeed, that's how it works.
And it also works when you pin the git rev down to an id, the sequential id will remain the same.

I sill also interested to add at least the task and some instructions inside the README

Yeah, good idea.
You intend to add the meta task to the recipes repository I guess?

[skaman]

Yeah, good idea.
You intend to add the meta task to the recipes repository I guess?

Yes.. this https://github.com/E...-openplugins.bb
I left only enigma2-plugin-extensions-snmpagent commented because it require a dependency doesn't provided by dmm

[ambrosa]

Hi guys.

http://openpli.org/f...ive-mounted-rw/ I've made a simple extension plugin to fast umount mass storage device.
I'm happy if you can include in your GitHub repo but ... I'm a bit confused.

I'm only an hobbyist (not an ICT professional) and a newbie in git: I'm starting some days ago to learn it (I've setup my GitHub repo, my GitHub username is 'ambrosa') and I've read ALL posts in this thread.

I've found 2 repo:

https://github.com/OpenPLi/E2-OpenPlugins

and

https://github.com/E2OpenPlugins/

Can someone kindly explain to me how organize my job ?

[nietgiftig]

I've found 2 repo:

https://github.com/OpenPLi/E2-OpenPlugins

and

https://github.com/E2OpenPlugins/

I think the second one is the correct one.

[ambrosa]

Ok. But I'm waiting instructions....

[nietgiftig]

Ok. But I'm waiting instructions....

http://openpli.org/f...post__p__230044

[nietgiftig]

I found an Enigma2-Plugins Git repository from Michel Hartmann
A nice source of forks from a lot of plugins

https://github.com/M...enigma2-plugins

[pieterg]

but the fork is rather old, and only adds two commits

[bacicciosat]

Ok. But I'm waiting instructions....

If you want to join e2openplugins developers to add plugins you can ask to sjaaky to be included in the organization team.

Ps. i have setup a dedicate forum @ vuplus-community for e2OpenPlugins where all the commits are automatically posted via rss agent: HERE
Ps2 i have setup too a mailing list reported commits for OpenWebIf git.

Edited by bacicciosat, 13 November 2011 - 13:01.