195 replies to this topic

[Sjaaky]

git-svn should be able to help. I've got no experience, but there are enough blogs / tutorials around. For example: http://trac.parrot.o...it-svn-tutorial

I was kinda hoping someone could 'watch' a repo and get mails automaticly. That doesn't seem to be the case. Only collaborators or owners get an email when someone commits/comments/... on their repo.

[bacicciosat]

I was kinda hoping someone could 'watch' a repo and get mails automaticly. That doesn't seem to be the case. Only collaborators or owners get an email when someone commits/comments/... on their repo.

Sjaaky all it is easy i think it can be so as following

1) Create @ openpli account in sourceforge the mailinglist: e2openplugin. When procedure will be complete you will have the mailinglist: e2openplugin@lists.sourceforge.net
2) Add to mailinglist the user account: noreply@github.com
3) For each repository we have @github goto: Admin -> Service Hooks -> Email
4) Set:
- Address: e2openplugin@lists.sourceforge.net
- Secret: leave empty
- Send from author: no
- Active: yes

test a commit and look if it is received in the mailinglist.
I think that is all and all should work.

[Sjaaky]

That is simple indeed. But I was looking for a solution from one provider (that might be a bit old fashioned ). Other option is to subscribe to your personal rss feed.
But I guess we can't do without a mailinglist.

[Sjaaky]

@skaman. Just after creating a github repo, you will get the option to import an existing svn repo.

[bacicciosat]

That is simple indeed. But I was looking for a solution from one provider (that might be a bit old fashioned ). Other option is to subscribe to your personal rss feed.
But I guess we can't do without a mailinglist.

I was thinking to a mailing list also to have a place when we can discuss about suggestions or ideas. As for example a new developer that wants to join and ask to create a new git for his plugin can subscribe to the mailing list and propose himself.
But i agree that is not nice to use two providers in such way.

[bacicciosat]

@Sjaaky:

1) After this blackout i think definitively we need a mailing list

2) I tried plugins buildings and i have 2 notes:
- In Vu OE the there is not yet the class: openembedded/classes/gitpkgv.bbclass. So it will be useful to add a README with a note for Vu+ builders to add this class.
- In both cases (dmm oe and Vu+ oe) there is an error in building (invalid object 1) that is caused from missing SCREV
to fix this error i suggest to add in all .bb plugins files the variable:

SRCREV = ""

3) I have two plugins ready to be added but i cannot create gits in E2OpenPlugins organization.
You can find both plugins and .bb files here: https://github.com/o...tions/BlackHole

[Sjaaky]

2) I tried plugins buildings and i have 2 notes:
- In Vu OE the there is not yet the class: openembedded/classes/gitpkgv.bbclass. So it will be useful to add a README with a note for Vu+ builders to add this class.
- In both cases (dmm oe and Vu+ oe) there is an error in building (invalid object 1) that is caused from missing SCREV
to fix this error i suggest to add in all .bb plugins files the variable:

SRCREV = ""

Good catch. I think it should SRCREV?="". As we define it as AUTOREV in a separate global versionnumber bb.

3) I have two plugins ready to be added but i cannot create gits in E2OpenPlugins organization.
You can find both plugins and .bb files here: https://github.com/o...tions/BlackHole

You should have admin right as we speak.

[pieterg]

2) I tried plugins buildings and i have 2 notes:
- In Vu OE the there is not yet the class: openembedded/classes/gitpkgv.bbclass. So it will be useful to add a README with a note for Vu+ builders to add this class.

not sure if just adding the class would work, if you are using an old bitbake, and old bbclasses.

- In both cases (dmm oe and Vu+ oe) there is an error in building (invalid object 1) that is caused from missing SCREV
to fix this error i suggest to add in all .bb plugins files the variable:

SRCREV = ""

rather use
SRCREV ?= "${AUTOREV}"
instead.
However, autorev support is not available in old bitbake(/bbclass) versions.

So I think it's not really possible to provide bitbake recipes which work for everybody, as long as people keep using different bitbake versions.
We should probably just consider the provided bb files as examples.

[bacicciosat]

not sure if just adding the class would work, if you are using an old bitbake, and old bbclasses.

No problem i have tested both official oe dmm and official vu+ oe
In Vu+ oe it is needed only to add the class and the SCREV and the building works fine
In Dmm oe only SCREV is needed

[bacicciosat]

You should have admin right as we speak.

Opps you are right, yes i see now.

Edited by bacicciosat, 29 September 2011 - 12:10.

[Sjaaky]

I meant, "as I speak". Because I just added admins rights to the dev group.

[bacicciosat]

Uhmm i have not tested but it seems to me that this kind of skin syntax cannot work in other images.

position="c+5,e-45"

[plnick]

Shame on me

Sorry for my late reply (I was busy at work)

I see you have done a good job

Furthermore I noticed that you give me write access to e2openplugins organization, thank you. Before I push something to github I have some questions.

At example bb files you use disutils and working with openplugins.inc, for sure this is nice and works fine. But is this a must ? I do it at my build the "old" way with makefiles, configure.ac and so on. Is this also possible ?
Should all plugins named as ...-extensions-... or is it also possible to use systemplugins ?


By the way: good work with your new board

By the way 2: at example bb file for newsreader there is a typo in modul name (Newsreader instead of NewsReader)

[pieterg]

At example bb files you use disutils and working with openplugins.inc, for sure this is nice and works fine. But is this a must ? I do it at my build the "old" way with makefiles, configure.ac and so on. Is this also possible ?

advantage of distutils: you do not need to provide the large aclocal.m4 with PYTHON ac macros.
If every plugin would use gnu autotools (like we've done before), splitting plugins into seperate repositories would mean duplicating the same aclocal.m4 many times (and then maintaining it with new autoconf or python versions for instance).
So we went for distutils, tailormade for python projects.
At least, when the plugin is all python. For plugins with a c(++) part we still use autotools.

Should all plugins named as ...-extensions-... or is it also possible to use systemplugins ?

That's up to the plugin maintainer to decide
What is a system plugin? In my view, something which configures/controls some piece of hardware, and is vital to use whatever features your stb offers.
In the past I've made the choice to make fastscan and cablescan plugins 'system' plugins, for instance.

[Sjaaky]

The plugins which use distutils include openplugins-distutils.inc. The plugins which use another mechanism, such as autotools include openplugins.inc. openplugins.inc defines the src_uri which is common for all plugins.

For an example of autotools look at the bitrate plugin. The bitrate plugin uses a separate binary build from a c++ source. Distutils is not meant to build separate executables from c/c++. Building a c/c++ library is supported by distutils. So the plugin could be rewritten. But keeping it autotools was easier and provides a nice example .

[bacicciosat]

It should be useful to write rules and setup a page for the project (i cannot make because my english is terrilble).
I think we need too a place form where to download the releases in ipk format.
When all will be done it should be nice to setup in all the boards of the joined teams a forum dedicated to e2openplugins where users can report their tests.

[plnick]

advantage of distutils: you do not need to provide the large aclocal.m4 with PYTHON ac macros.
If every plugin would use gnu autotools (like we've done before), splitting plugins into seperate repositories would mean duplicating the same aclocal.m4 many times (and then maintaining it with new autoconf or python versions for instance).
So we went for distutils, tailormade for python projects.
At least, when the plugin is all python. For plugins with a c(++) part we still use autotools.

Yes I know, this is a much more nicer way of building the packages. But I did not work with disutils in the past so I do not know how to setup the localisation part (translations). So I pushed the two plugins with "old" style makefiles (we can change this in future, if I know how to build the needed po/mo files )

Uhmm i have not tested but it seems to me that this kind of skin syntax cannot work in other images.

position="c+5,e-45"

Yes, you are right, this does not work at images which do not use PLI based e2

[pieterg]

Uhmm i have not tested but it seems to me that this kind of skin syntax cannot work in other images.

position="c+5,e-45"

Yes, you are right, this does not work at images which do not use PLI based e2

Did other images implement a different way to use relative coordinates?
Or do we have to convert everything to absolute coordinates?

[bacicciosat]

Uhmm i have not tested but it seems to me that this kind of skin syntax cannot work in other images.

position="c+5,e-45"

Yes, you are right, this does not work at images which do not use PLI based e2

Did other images implement a different way to use relative coordinates?
Or do we have to convert everything to absolute coordinates?

I think we have to be compatible with official e2 repos.
it sems to me that the only relative position available is "center,center".

[pieterg]

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