OE-Classic recipe migration status

OE-Classic recipe migration status

[Paul Eggleton]

Hi all,

Whilst the OE-Core-based layer landscape has grown quite a bit over the last 
year and we now have a wealth of clean and up-to-date recipes, I've heard a 
few people commenting that we've still lost quite a few recipes along the way. 
Nobody who did make that comment has seemed to be able to be specific about 
what they thought we were missing however, so I figured it would be worth 
trying to determine exactly which recipes are only available in OE-Classic.

With the help of some scripts I've produced a list of the recipes, made some 
notes and categorised some of them. I've published the list on the wiki 
(unfortunately I had to split it into two pages since it was too large to put 
into one):

 http://www.openembedded.org/wiki/OE-Classic_Recipes_A-I
 http://www.openembedded.org/wiki/OE-Classic_Recipes_J-Z

I don't know much about a lot of these recipes, so if you can help to fill in 
the gaps particularly by marking the obsolete ones as such or adding other 
comments, that would be great. Either edit the pages directly or make your 
comments here and I'll merge them.

Using some more hacky scripts to break down the recipes into groups, I've 
produced the following numbers (with the incomplete data as it stands):

   1484 other
    218 BSP
    211 BugLabs
    195 libs
    193 obsolete
    155 obsolete directory (OE-Classic)
    136 PERL
    119 python
     92 distro
     89 tasks
     84 nonworking directory (OE-Classic)
     80 GPE
     79 X11 drivers
     59 images
     59 games
     41 fonts
     23 security
     20 in another layer
     18 pending
     11 EFL

So clearly there are quite a few recipes left that could be brought back, 
assuming there is demand; on the other hand there are a significant number that 
can probably just be discarded. For those that are still of interest, we need 
motivated individuals to do the migration and maintain the recipes going 
forward.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: OE-Classic recipe migration status

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2720 bytes --]

On Sun, Nov 11, 2012 at 07:11:28PM +0000, Paul Eggleton wrote:
> Hi all,
> 
> Whilst the OE-Core-based layer landscape has grown quite a bit over the last 
> year and we now have a wealth of clean and up-to-date recipes, I've heard a 
> few people commenting that we've still lost quite a few recipes along the way. 
> Nobody who did make that comment has seemed to be able to be specific about 
> what they thought we were missing however, so I figured it would be worth 
> trying to determine exactly which recipes are only available in OE-Classic.
> 
> With the help of some scripts I've produced a list of the recipes, made some 
> notes and categorised some of them. I've published the list on the wiki 
> (unfortunately I had to split it into two pages since it was too large to put 
> into one):
> 
>  http://www.openembedded.org/wiki/OE-Classic_Recipes_A-I
>  http://www.openembedded.org/wiki/OE-Classic_Recipes_J-Z
> 
> I don't know much about a lot of these recipes, so if you can help to fill in 
> the gaps particularly by marking the obsolete ones as such or adding other 
> comments, that would be great. Either edit the pages directly or make your 
> comments here and I'll merge them.

I've noticed quite a few recipes listed here, which does exist in some
layer (recipes mostly from meta-fso, meta-aurora, meta-shr), should I
remove them from that wiki page or add layer name in 2nd column?

Cheers,

> Using some more hacky scripts to break down the recipes into groups, I've 
> produced the following numbers (with the incomplete data as it stands):
> 
>    1484 other
>     218 BSP
>     211 BugLabs
>     195 libs
>     193 obsolete
>     155 obsolete directory (OE-Classic)
>     136 PERL
>     119 python
>      92 distro
>      89 tasks
>      84 nonworking directory (OE-Classic)
>      80 GPE
>      79 X11 drivers
>      59 images
>      59 games
>      41 fonts
>      23 security
>      20 in another layer
>      18 pending
>      11 EFL
> 
> So clearly there are quite a few recipes left that could be brought back, 
> assuming there is demand; on the other hand there are a significant number that 
> can probably just be discarded. For those that are still of interest, we need 
> motivated individuals to do the migration and maintain the recipes going 
> forward.
> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [OE-core] OE-Classic recipe migration status

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2720 bytes --]

On Sun, Nov 11, 2012 at 07:11:28PM +0000, Paul Eggleton wrote:
> Hi all,
> 
> Whilst the OE-Core-based layer landscape has grown quite a bit over the last 
> year and we now have a wealth of clean and up-to-date recipes, I've heard a 
> few people commenting that we've still lost quite a few recipes along the way. 
> Nobody who did make that comment has seemed to be able to be specific about 
> what they thought we were missing however, so I figured it would be worth 
> trying to determine exactly which recipes are only available in OE-Classic.
> 
> With the help of some scripts I've produced a list of the recipes, made some 
> notes and categorised some of them. I've published the list on the wiki 
> (unfortunately I had to split it into two pages since it was too large to put 
> into one):
> 
>  http://www.openembedded.org/wiki/OE-Classic_Recipes_A-I
>  http://www.openembedded.org/wiki/OE-Classic_Recipes_J-Z
> 
> I don't know much about a lot of these recipes, so if you can help to fill in 
> the gaps particularly by marking the obsolete ones as such or adding other 
> comments, that would be great. Either edit the pages directly or make your 
> comments here and I'll merge them.

I've noticed quite a few recipes listed here, which does exist in some
layer (recipes mostly from meta-fso, meta-aurora, meta-shr), should I
remove them from that wiki page or add layer name in 2nd column?

Cheers,

> Using some more hacky scripts to break down the recipes into groups, I've 
> produced the following numbers (with the incomplete data as it stands):
> 
>    1484 other
>     218 BSP
>     211 BugLabs
>     195 libs
>     193 obsolete
>     155 obsolete directory (OE-Classic)
>     136 PERL
>     119 python
>      92 distro
>      89 tasks
>      84 nonworking directory (OE-Classic)
>      80 GPE
>      79 X11 drivers
>      59 images
>      59 games
>      41 fonts
>      23 security
>      20 in another layer
>      18 pending
>      11 EFL
> 
> So clearly there are quite a few recipes left that could be brought back, 
> assuming there is demand; on the other hand there are a significant number that 
> can probably just be discarded. For those that are still of interest, we need 
> motivated individuals to do the migration and maintain the recipes going 
> forward.
> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: OE-Classic recipe migration status

[Paul Eggleton]

On Sunday 11 November 2012 20:52:26 Martin Jansa wrote:
> On Sun, Nov 11, 2012 at 07:11:28PM +0000, Paul Eggleton wrote:
> > Hi all,
> > 
> > Whilst the OE-Core-based layer landscape has grown quite a bit over the
> > last year and we now have a wealth of clean and up-to-date recipes, I've
> > heard a few people commenting that we've still lost quite a few recipes
> > along the way. Nobody who did make that comment has seemed to be able to
> > be specific about what they thought we were missing however, so I figured
> > it would be worth trying to determine exactly which recipes are only
> > available in OE-Classic.
> > 
> > With the help of some scripts I've produced a list of the recipes, made
> > some notes and categorised some of them. I've published the list on the
> > wiki (unfortunately I had to split it into two pages since it was too
> > large to put> 
> > into one):
> >  http://www.openembedded.org/wiki/OE-Classic_Recipes_A-I
> >  http://www.openembedded.org/wiki/OE-Classic_Recipes_J-Z
> > 
> > I don't know much about a lot of these recipes, so if you can help to fill
> > in the gaps particularly by marking the obsolete ones as such or adding
> > other comments, that would be great. Either edit the pages directly or
> > make your comments here and I'll merge them.
> 
> I've noticed quite a few recipes listed here, which does exist in some
> layer (recipes mostly from meta-fso, meta-aurora, meta-shr), should I
> remove them from that wiki page or add layer name in 2nd column?

I did have all the layers in meta-smartphone included in the list I used to 
filter this one, so if there are items that somehow didn't get removed I'd like 
to figure out why. Can you list them here so I can look into that?

Thanks,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [OE-core] OE-Classic recipe migration status

[Paul Eggleton]

On Sunday 11 November 2012 20:52:26 Martin Jansa wrote:
> On Sun, Nov 11, 2012 at 07:11:28PM +0000, Paul Eggleton wrote:
> > Hi all,
> > 
> > Whilst the OE-Core-based layer landscape has grown quite a bit over the
> > last year and we now have a wealth of clean and up-to-date recipes, I've
> > heard a few people commenting that we've still lost quite a few recipes
> > along the way. Nobody who did make that comment has seemed to be able to
> > be specific about what they thought we were missing however, so I figured
> > it would be worth trying to determine exactly which recipes are only
> > available in OE-Classic.
> > 
> > With the help of some scripts I've produced a list of the recipes, made
> > some notes and categorised some of them. I've published the list on the
> > wiki (unfortunately I had to split it into two pages since it was too
> > large to put> 
> > into one):
> >  http://www.openembedded.org/wiki/OE-Classic_Recipes_A-I
> >  http://www.openembedded.org/wiki/OE-Classic_Recipes_J-Z
> > 
> > I don't know much about a lot of these recipes, so if you can help to fill
> > in the gaps particularly by marking the obsolete ones as such or adding
> > other comments, that would be great. Either edit the pages directly or
> > make your comments here and I'll merge them.
> 
> I've noticed quite a few recipes listed here, which does exist in some
> layer (recipes mostly from meta-fso, meta-aurora, meta-shr), should I
> remove them from that wiki page or add layer name in 2nd column?

I did have all the layers in meta-smartphone included in the list I used to 
filter this one, so if there are items that somehow didn't get removed I'd like 
to figure out why. Can you list them here so I can look into that?

Thanks,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: OE-Classic recipe migration status

[Paul Eggleton]

On Sunday 11 November 2012 21:16:13 Martin Jansa wrote:
> On Sun, Nov 11, 2012 at 07:58:09PM +0000, Paul Eggleton wrote:
> > On Sunday 11 November 2012 20:52:26 Martin Jansa wrote:
> > > I've noticed quite a few recipes listed here, which does exist in some
> > > layer (recipes mostly from meta-fso, meta-aurora, meta-shr), should I
> > > remove them from that wiki page or add layer name in 2nd column?
> > 
> > I did have all the layers in meta-smartphone included in the list I used
> > to
> > filter this one, so if there are items that somehow didn't get removed I'd
> > like to figure out why. Can you list them here so I can look into that?
>
> Ah sorry, you're probably right
> 
> I've noticed e.g this:
> libfsobasics	[distro]
> libfsoresource	[distro]
> libfsosystem	[distro]
> libfsotransport	[distro]
> but those are now provided by single libfsoframework recipe and I've
> forgot this change
> https://github.com/shr-distribution/meta-smartphone/commit/0298befc97dc5dca2
> a3721fb0ff9d4caf8d24f84
> 
> So I'll just update [distro] flag to something like obsoleted by
> libfsoframework.

Ah ok, sounds good.

> The rest is probably also not 1:1 like qfsodbusxml2cpp-native
> ./meta-fso/recipes-freesmartphone/freesmartphone/qfsodbusxml2cpp_git.bb
> 
> Maybe you can try to update scripts to show matches after "-native"
> suffix strip?

I'd prefer to handle this manually - there are cases when newer recipes 
haven't been BBCLASSEXTENDed to handle -native so I've been checking this by 
hand.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [OE-core] OE-Classic recipe migration status

[Paul Eggleton]

On Sunday 11 November 2012 21:16:13 Martin Jansa wrote:
> On Sun, Nov 11, 2012 at 07:58:09PM +0000, Paul Eggleton wrote:
> > On Sunday 11 November 2012 20:52:26 Martin Jansa wrote:
> > > I've noticed quite a few recipes listed here, which does exist in some
> > > layer (recipes mostly from meta-fso, meta-aurora, meta-shr), should I
> > > remove them from that wiki page or add layer name in 2nd column?
> > 
> > I did have all the layers in meta-smartphone included in the list I used
> > to
> > filter this one, so if there are items that somehow didn't get removed I'd
> > like to figure out why. Can you list them here so I can look into that?
>
> Ah sorry, you're probably right
> 
> I've noticed e.g this:
> libfsobasics	[distro]
> libfsoresource	[distro]
> libfsosystem	[distro]
> libfsotransport	[distro]
> but those are now provided by single libfsoframework recipe and I've
> forgot this change
> https://github.com/shr-distribution/meta-smartphone/commit/0298befc97dc5dca2
> a3721fb0ff9d4caf8d24f84
> 
> So I'll just update [distro] flag to something like obsoleted by
> libfsoframework.

Ah ok, sounds good.

> The rest is probably also not 1:1 like qfsodbusxml2cpp-native
> ./meta-fso/recipes-freesmartphone/freesmartphone/qfsodbusxml2cpp_git.bb
> 
> Maybe you can try to update scripts to show matches after "-native"
> suffix strip?

I'd prefer to handle this manually - there are cases when newer recipes 
haven't been BBCLASSEXTENDed to handle -native so I've been checking this by 
hand.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [oe] OE-Classic recipe migration status

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]

On Sun, Nov 11, 2012 at 6:49 PM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> On Sunday 11 November 2012 21:16:13 Martin Jansa wrote:
> > On Sun, Nov 11, 2012 at 07:58:09PM +0000, Paul Eggleton wrote:
> > > On Sunday 11 November 2012 20:52:26 Martin Jansa wrote:
> > > > I've noticed quite a few recipes listed here, which does exist in
> some
> > > > layer (recipes mostly from meta-fso, meta-aurora, meta-shr), should I
> > > > remove them from that wiki page or add layer name in 2nd column?
> > >
> > > I did have all the layers in meta-smartphone included in the list I
> used
> > > to
> > > filter this one, so if there are items that somehow didn't get removed
> I'd
> > > like to figure out why. Can you list them here so I can look into that?
> >
> > Ah sorry, you're probably right
> >
> > I've noticed e.g this:
> > libfsobasics  [distro]
> > libfsoresource        [distro]
> > libfsosystem  [distro]
> > libfsotransport       [distro]
> > but those are now provided by single libfsoframework recipe and I've
> > forgot this change
> >
> https://github.com/shr-distribution/meta-smartphone/commit/0298befc97dc5dca2
> > a3721fb0ff9d4caf8d24f84
> >
> > So I'll just update [distro] flag to something like obsoleted by
> > libfsoframework.
>
> Ah ok, sounds good.
>
> > The rest is probably also not 1:1 like qfsodbusxml2cpp-native
> > ./meta-fso/recipes-freesmartphone/freesmartphone/qfsodbusxml2cpp_git.bb
> >
> > Maybe you can try to update scripts to show matches after "-native"
> > suffix strip?
>
> I'd prefer to handle this manually - there are cases when newer recipes
> haven't been BBCLASSEXTENDed to handle -native so I've been checking this
> by
> hand.
>

You might grep for it and match it properly. So it drops a manual step.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

[-- Attachment #2: Type: text/html, Size: 2928 bytes --]

Re: [OE-core] OE-Classic recipe migration status

[Otavio Salvador]

On Sun, Nov 11, 2012 at 6:49 PM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> On Sunday 11 November 2012 21:16:13 Martin Jansa wrote:
> > On Sun, Nov 11, 2012 at 07:58:09PM +0000, Paul Eggleton wrote:
> > > On Sunday 11 November 2012 20:52:26 Martin Jansa wrote:
> > > > I've noticed quite a few recipes listed here, which does exist in
> some
> > > > layer (recipes mostly from meta-fso, meta-aurora, meta-shr), should I
> > > > remove them from that wiki page or add layer name in 2nd column?
> > >
> > > I did have all the layers in meta-smartphone included in the list I
> used
> > > to
> > > filter this one, so if there are items that somehow didn't get removed
> I'd
> > > like to figure out why. Can you list them here so I can look into that?
> >
> > Ah sorry, you're probably right
> >
> > I've noticed e.g this:
> > libfsobasics  [distro]
> > libfsoresource        [distro]
> > libfsosystem  [distro]
> > libfsotransport       [distro]
> > but those are now provided by single libfsoframework recipe and I've
> > forgot this change
> >
> https://github.com/shr-distribution/meta-smartphone/commit/0298befc97dc5dca2
> > a3721fb0ff9d4caf8d24f84
> >
> > So I'll just update [distro] flag to something like obsoleted by
> > libfsoframework.
>
> Ah ok, sounds good.
>
> > The rest is probably also not 1:1 like qfsodbusxml2cpp-native
> > ./meta-fso/recipes-freesmartphone/freesmartphone/qfsodbusxml2cpp_git.bb
> >
> > Maybe you can try to update scripts to show matches after "-native"
> > suffix strip?
>
> I'd prefer to handle this manually - there are cases when newer recipes
> haven't been BBCLASSEXTENDed to handle -native so I've been checking this
> by
> hand.
>

You might grep for it and match it properly. So it drops a manual step.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [oe] OE-Classic recipe migration status

[Paul Eggleton]

On Sunday 11 November 2012 21:24:55 Otavio Salvador wrote:
> On Sun, Nov 11, 2012 at 6:49 PM, Paul Eggleton <
> paul.eggleton@linux.intel.com> wrote:
> > On Sunday 11 November 2012 21:16:13 Martin Jansa wrote:
> > > I've noticed e.g this:
> > > libfsobasics  [distro]
> > > libfsoresource        [distro]
> > > libfsosystem  [distro]
> > > libfsotransport       [distro]
> > > but those are now provided by single libfsoframework recipe and I've
> > > forgot this change
> > 
> > https://github.com/shr-distribution/meta-smartphone/commit/0298befc97dc5dc
> > a2> 
> > > a3721fb0ff9d4caf8d24f84
> > > 
> > > So I'll just update [distro] flag to something like obsoleted by
> > > libfsoframework.
> > 
> > Ah ok, sounds good.

FYI I've updated these entries now.

> > > The rest is probably also not 1:1 like qfsodbusxml2cpp-native
> > > ./meta-fso/recipes-freesmartphone/freesmartphone/qfsodbusxml2cpp_git.bb
> > > 
> > > Maybe you can try to update scripts to show matches after "-native"
> > > suffix strip?
> > 
> > I'd prefer to handle this manually - there are cases when newer recipes
> > haven't been BBCLASSEXTENDed to handle -native so I've been checking this
> > by hand.
> 
> You might grep for it and match it properly. So it drops a manual step.

OK, I've added some script code to check for BBCLASSEXTEND and have added 
notes next to the following items that I had missed:

cup-native
devio-native
jamvm-native
jlex-native
python-pygobject-native
qfsodbusxml2cpp-native
usbpath-native

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [OE-core] OE-Classic recipe migration status

[Paul Eggleton]

On Sunday 11 November 2012 21:24:55 Otavio Salvador wrote:
> On Sun, Nov 11, 2012 at 6:49 PM, Paul Eggleton <
> paul.eggleton@linux.intel.com> wrote:
> > On Sunday 11 November 2012 21:16:13 Martin Jansa wrote:
> > > I've noticed e.g this:
> > > libfsobasics  [distro]
> > > libfsoresource        [distro]
> > > libfsosystem  [distro]
> > > libfsotransport       [distro]
> > > but those are now provided by single libfsoframework recipe and I've
> > > forgot this change
> > 
> > https://github.com/shr-distribution/meta-smartphone/commit/0298befc97dc5dc
> > a2> 
> > > a3721fb0ff9d4caf8d24f84
> > > 
> > > So I'll just update [distro] flag to something like obsoleted by
> > > libfsoframework.
> > 
> > Ah ok, sounds good.

FYI I've updated these entries now.

> > > The rest is probably also not 1:1 like qfsodbusxml2cpp-native
> > > ./meta-fso/recipes-freesmartphone/freesmartphone/qfsodbusxml2cpp_git.bb
> > > 
> > > Maybe you can try to update scripts to show matches after "-native"
> > > suffix strip?
> > 
> > I'd prefer to handle this manually - there are cases when newer recipes
> > haven't been BBCLASSEXTENDed to handle -native so I've been checking this
> > by hand.
> 
> You might grep for it and match it properly. So it drops a manual step.

OK, I've added some script code to check for BBCLASSEXTEND and have added 
notes next to the following items that I had missed:

cup-native
devio-native
jamvm-native
jlex-native
python-pygobject-native
qfsodbusxml2cpp-native
usbpath-native

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: OE-Classic recipe migration status

Hello.

On Sun, 2012-11-11 at 19:11, Paul Eggleton wrote:
> 
>    1484 other
>     218 BSP
>     211 BugLabs

I now longer work for BugLabs but  during my last months there I split
up our bunch of recipes according to what we think was sane at that
time. Think end of last year here.

The BSP layer can be found here:
https://github.com/buglabs/meta-bug

And BugLabs specific recipes here:
https://github.com/buglabs/meta-buglabs

All OpenJDK related stuff was going directly into upstream through
Tarent anyway. This should cover all stuff that was worth bringing
over.

>      11 EFL

I think everything worth working with is in meta-efl in meta-oe.
Martin is doing a great job catching up with everything we do
upstream. If something is really missing it might now longer work or
is just not worth bringing over.

regards
Stefan Schmidt

Re: [OE-core] OE-Classic recipe migration status

[Stefan Schmidt]

Hello.

On Sun, 2012-11-11 at 19:11, Paul Eggleton wrote:
> 
>    1484 other
>     218 BSP
>     211 BugLabs

I now longer work for BugLabs but  during my last months there I split
up our bunch of recipes according to what we think was sane at that
time. Think end of last year here.

The BSP layer can be found here:
https://github.com/buglabs/meta-bug

And BugLabs specific recipes here:
https://github.com/buglabs/meta-buglabs

All OpenJDK related stuff was going directly into upstream through
Tarent anyway. This should cover all stuff that was worth bringing
over.

>      11 EFL

I think everything worth working with is in meta-efl in meta-oe.
Martin is doing a great job catching up with everything we do
upstream. If something is really missing it might now longer work or
is just not worth bringing over.

regards
Stefan Schmidt

Re: [OE-core] OE-Classic recipe migration status

[Paul Eggleton]

On Monday 12 November 2012 18:26:16 Stefan Schmidt wrote:
> On Sun, 2012-11-11 at 19:11, Paul Eggleton wrote:
> >    1484 other
> >     218 BSP
> >     211 BugLabs
> 
> I now longer work for BugLabs but  during my last months there I split
> up our bunch of recipes according to what we think was sane at that
> time. Think end of last year here.
> 
> The BSP layer can be found here:
> https://github.com/buglabs/meta-bug
> 
> And BugLabs specific recipes here:
> https://github.com/buglabs/meta-buglabs
> 
> All OpenJDK related stuff was going directly into upstream through
> Tarent anyway. This should cover all stuff that was worth bringing
> over.

OK, I've removed everything that is now in meta-bug/meta-buglabs and marked 
everything else as obsolete. Thanks!
 
> >      11 EFL
> 
> I think everything worth working with is in meta-efl in meta-oe.
> Martin is doing a great job catching up with everything we do
> upstream. If something is really missing it might now longer work or
> is just not worth bringing over.

Martin, can you look over the EFL marked recipes and confirm this?

Thanks,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [OE-core] OE-Classic recipe migration status

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]

On Tue, Nov 13, 2012 at 10:52:08AM +0000, Paul Eggleton wrote:
> On Monday 12 November 2012 18:26:16 Stefan Schmidt wrote:
> > On Sun, 2012-11-11 at 19:11, Paul Eggleton wrote:
> > >    1484 other
> > >     218 BSP
> > >     211 BugLabs
> > 
> > I now longer work for BugLabs but  during my last months there I split
> > up our bunch of recipes according to what we think was sane at that
> > time. Think end of last year here.
> > 
> > The BSP layer can be found here:
> > https://github.com/buglabs/meta-bug
> > 
> > And BugLabs specific recipes here:
> > https://github.com/buglabs/meta-buglabs
> > 
> > All OpenJDK related stuff was going directly into upstream through
> > Tarent anyway. This should cover all stuff that was worth bringing
> > over.
> 
> OK, I've removed everything that is now in meta-bug/meta-buglabs and marked 
> everything else as obsolete. Thanks!
>  
> > >      11 EFL
> > 
> > I think everything worth working with is in meta-efl in meta-oe.
> > Martin is doing a great job catching up with everything we do
> > upstream. If something is really missing it might now longer work or
> > is just not worth bringing over.
> 
> Martin, can you look over the EFL marked recipes and confirm this?

Yes, some could be usefull for someone:
remoko,
enna,
enotes,
euphony
but all have rather dead upstream and I'm not going to migrate them just
for migration sake (they would probably need a lot of changes/testing to
make them compatible with latest EFL).

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: OE-Classic recipe migration status

[Denis 'GNUtoo' Carikli]

On Mon, 12 Nov 2012 18:26:16 +0000
Stefan Schmidt <stefan@datenfreihafen.org> wrote:
> I now longer work for BugLabs but  during my last months there I split
> up our bunch of recipes according to what we think was sane at that
> time. Think end of last year here.
> 
> The BSP layer can be found here:
> https://github.com/buglabs/meta-bug
However (since my last pull request) it fails to boot and blocks in
systemd with an angstrom image, I'll get the diff and a log soon.
> And BugLabs specific recipes here:
> https://github.com/buglabs/meta-buglabs
Nice, I didn't know about it.

PS: Note that I don't work for Buglabs either, I just happen to have
some buglabs(bug 2.0, bug 1.3 wifi, bug 1.3 + many modules) devices.

Denis.

Re: [OE-core] OE-Classic recipe migration status

[Denis 'GNUtoo' Carikli]

On Mon, 12 Nov 2012 18:26:16 +0000
Stefan Schmidt <stefan@datenfreihafen.org> wrote:
> I now longer work for BugLabs but  during my last months there I split
> up our bunch of recipes according to what we think was sane at that
> time. Think end of last year here.
> 
> The BSP layer can be found here:
> https://github.com/buglabs/meta-bug
However (since my last pull request) it fails to boot and blocks in
systemd with an angstrom image, I'll get the diff and a log soon.
> And BugLabs specific recipes here:
> https://github.com/buglabs/meta-buglabs
Nice, I didn't know about it.

PS: Note that I don't work for Buglabs either, I just happen to have
some buglabs(bug 2.0, bug 1.3 wifi, bug 1.3 + many modules) devices.

Denis.

Re: OE-Classic recipe migration status

[Phil Blundell]

On Sun, 2012-11-11 at 19:11 +0000, Paul Eggleton wrote:
>     136 PERL

I encountered the horror that is the perl modules a few weeks ago while
I was working on mythtv.  At the time it seemed as though there were
more like 13600 recipes but I imagine your figure is probably the
accurate one.  It looks as though I managed to fix up 37 recipes to work
with oe-core before the tedium got too much.

I think this stuff probably wants to go into a dedicated
meta-perl-modules layer since in most cases there is no obvious
functional grouping.  I could publish those 37 as a starting point and
anybody else who wants to add more is welcome to do so.

p.

Re: OE-Classic recipe migration status

[Paul Eggleton]

On Monday 12 November 2012 22:10:35 Phil Blundell wrote:
> On Sun, 2012-11-11 at 19:11 +0000, Paul Eggleton wrote:
> >     136 PERL
> 
> I encountered the horror that is the perl modules a few weeks ago while
> I was working on mythtv.  At the time it seemed as though there were
> more like 13600 recipes but I imagine your figure is probably the
> accurate one.  It looks as though I managed to fix up 37 recipes to work
> with oe-core before the tedium got too much.

I'm only counting recipes with "perl" in the name, there could be others but I 
suspect that has caught most of them.

> I think this stuff probably wants to go into a dedicated
> meta-perl-modules layer since in most cases there is no obvious
> functional grouping.  

Sounds good.

> I could publish those 37 as a starting point and
> anybody else who wants to add more is welcome to do so.

Great, thanks!

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [oe] OE-Classic recipe migration status

[Denis 'GNUtoo' Carikli]

On Sun, 11 Nov 2012 19:11:28 +0000
Paul Eggleton <paul.eggleton@linux.intel.com> wrote:

> Hi all,
> 
> Whilst the OE-Core-based layer landscape has grown quite a bit over
> the last year and we now have a wealth of clean and up-to-date
> recipes, I've heard a few people commenting that we've still lost
> quite a few recipes along the way. Nobody who did make that comment
> has seemed to be able to be specific about what they thought we were
> missing however, so I figured it would be worth trying to determine
> exactly which recipes are only available in OE-Classic.
> 
> With the help of some scripts I've produced a list of the recipes,
> made some notes and categorised some of them. I've published the list
> on the wiki (unfortunately I had to split it into two pages since it
> was too large to put into one):
> 
>  http://www.openembedded.org/wiki/OE-Classic_Recipes_A-I
>  http://www.openembedded.org/wiki/OE-Classic_Recipes_J-Z
> 
> I don't know much about a lot of these recipes, so if you can help to
> fill in the gaps particularly by marking the obsolete ones as such or
> adding other comments, that would be great. Either edit the pages
> directly or make your comments here and I'll merge them.
Having the following software would be nice:
* 0xffff,0xffff-native //used for flashing the n900 and for interacting
  with the n900 NAND partition(decoding what's on an MTD partition such
  as wifi calibration, MAC address etc...)
* abiword plugins
* accelges : gesture recognition for the openmoko freerunner (gta02)
* asterisk recipes? could still be usefull...
* batctl	//for mesh networking
* batmand	//for mesh networking
* wscan,dvb*	//for looking at dvb-t, some of my devices have USB
host.
* ekiga //would be nice for VOIP 
* fennec //renamed to firefox mobile?
* flashrom //could be definitely usefull to flash BIOS from embedded
  devices, I cross compiled it by hand for now, devices that have SPI
  can flash SPI BIOS chips, such as the bug 2.0 or the rasberry pi
* geoclue // could be usefull if it can uses gpsd
* gnash //usefull to see flash animations even if now there is html5
  for youtube
* gnuchess //nice chess engine but a bit too hard.
* gnumeric //should be very nice. like ooo/libreoffice calc.
* gst-ducati // would be really usefull for omap4.
* gst-player? //isn't it gst-123 or something like that in the new oe?
* intone-video //would be nice, like intone which is an efl music
  player but for video.
* irssi //nice command line IRC client.
* linphone //VOIP client, no VOIP client seem present in the new oe.
* mpd-alsa, mpc, // do we have mpd in the new oe? if so that's nice.
  what about graphical clients?
* mumudvb //would be nice, for straming dvb.
* nmap //nice for nmap -sP (for finding IP of local computers).
* openbmap-logger //same kind of softwaer than cellhunter(see below)
* privoxy //a proxy that can filter request, usefull for anonimizing
  the connection or with tor.
* sflphone-common  //is slfphone in the new oe?
* tesseract //could be usefull for making apps that uses a camera and
  recognize text?
* totem
* tor //anonymity network.
* tshark,wireshark //usefull for debugging modem protocol in some
phones.

Games(All the free games that don't require 3d if possible):
* abuse (arcade game)
* bzflag? doesn't it require 3d acceleration?
* bzflag-server? is it required for bzflag?
* cellhunter //not really a game, it's rather a tool for mapping cell
* crimsonfields
  towers with the freerunner, would be nice to have.
* freedoom // free software data (.wad) for the game named doom.
* frozen-bubble
* openttd* //train simulation
* opentryan
* rocksndiamonds
* supertux,supertux-qvga
* wordwarvi //great game
* xboard //also need a chess engine such as gnuchess or another one
* prboom  ??? //not in the list, but probably not in the newer oe
  either. doom game.


Misc comments:
* Aurora is in meta-smartphone I think.
* Eukrea uses barebox in its layers.
* We have a generic compat wireless that has almost all modules in the
  new oe.
* concierge is an osgi implementation that was used in the buglabs bug
  1.x and not used anymore in the buglabs bug 2.x
* emacs-x11 is already in the new oe, under the name of emacs(yes it
  works with X11).
* fso2-demo-image //obsolete, probably doesn't work anymore because of
zhone
* fso2-console-image //available in meta-fso
* fso-console-image //replaced by fso2-console-image
* gnuradio-image //probably in meta-ettus?
* gpsd-device-config //obsolete?
* linux-bug //kernel too old but no replacement, a 2.6.30 exist without
  display and only serial is in mainline.
* linux-leviathan //obsolete, was for htc dream but got renamed.
* lowpan-tools //seem usefull for the nanonote and it's lowpan sdio
  card. what's the status of the nanonote in the new oe? was there a
  layer somewhere on some git hosting websites?
* madwifi-ng //obsoleted by the ath5k driver
* mokonnect //obsoleted by iliwi
* msmcomm-specs, palmpre-audio-scripts  //palm pre got dropped by
freesmartphone and msmcommd was the deamon that talked to its modem
* remoko* // uses bluez3, bluetooth mouse,keyboard,etc...
  implementation.
* sms-sentry //don't work anymore, need to be updated to the new
  freesmartphone API, usefull for finding the position of your lost
  phone.
* tichy // not tested but may be really old...for the openmoko
* wesnoth-wvga // wesnoth-wvga is the equivalent of wesnoth in the new
  oe, and the old "wesnoth" is a sub wvga version, which is dropped
  upstream.
* xfce46-image,xfce-image there is an xfce image in angstrom in the
  newer oe.

Denis.

Re: OE-Classic recipe migration status

[Denis 'GNUtoo' Carikli]

On Sun, 11 Nov 2012 19:11:28 +0000
Paul Eggleton <paul.eggleton@linux.intel.com> wrote:

> Hi all,
> 
> Whilst the OE-Core-based layer landscape has grown quite a bit over
> the last year and we now have a wealth of clean and up-to-date
> recipes, I've heard a few people commenting that we've still lost
> quite a few recipes along the way. Nobody who did make that comment
> has seemed to be able to be specific about what they thought we were
> missing however, so I figured it would be worth trying to determine
> exactly which recipes are only available in OE-Classic.
> 
> With the help of some scripts I've produced a list of the recipes,
> made some notes and categorised some of them. I've published the list
> on the wiki (unfortunately I had to split it into two pages since it
> was too large to put into one):
> 
>  http://www.openembedded.org/wiki/OE-Classic_Recipes_A-I
>  http://www.openembedded.org/wiki/OE-Classic_Recipes_J-Z
> 
> I don't know much about a lot of these recipes, so if you can help to
> fill in the gaps particularly by marking the obsolete ones as such or
> adding other comments, that would be great. Either edit the pages
> directly or make your comments here and I'll merge them.
Having the following software would be nice:
* 0xffff,0xffff-native //used for flashing the n900 and for interacting
  with the n900 NAND partition(decoding what's on an MTD partition such
  as wifi calibration, MAC address etc...)
* abiword plugins
* accelges : gesture recognition for the openmoko freerunner (gta02)
* asterisk recipes? could still be usefull...
* batctl	//for mesh networking
* batmand	//for mesh networking
* wscan,dvb*	//for looking at dvb-t, some of my devices have USB
host.
* ekiga //would be nice for VOIP 
* fennec //renamed to firefox mobile?
* flashrom //could be definitely usefull to flash BIOS from embedded
  devices, I cross compiled it by hand for now, devices that have SPI
  can flash SPI BIOS chips, such as the bug 2.0 or the rasberry pi
* geoclue // could be usefull if it can uses gpsd
* gnash //usefull to see flash animations even if now there is html5
  for youtube
* gnuchess //nice chess engine but a bit too hard.
* gnumeric //should be very nice. like ooo/libreoffice calc.
* gst-ducati // would be really usefull for omap4.
* gst-player? //isn't it gst-123 or something like that in the new oe?
* intone-video //would be nice, like intone which is an efl music
  player but for video.
* irssi //nice command line IRC client.
* linphone //VOIP client, no VOIP client seem present in the new oe.
* mpd-alsa, mpc, // do we have mpd in the new oe? if so that's nice.
  what about graphical clients?
* mumudvb //would be nice, for straming dvb.
* nmap //nice for nmap -sP (for finding IP of local computers).
* openbmap-logger //same kind of softwaer than cellhunter(see below)
* privoxy //a proxy that can filter request, usefull for anonimizing
  the connection or with tor.
* sflphone-common  //is slfphone in the new oe?
* tesseract //could be usefull for making apps that uses a camera and
  recognize text?
* totem
* tor //anonymity network.
* tshark,wireshark //usefull for debugging modem protocol in some
phones.

Games(All the free games that don't require 3d if possible):
* abuse (arcade game)
* bzflag? doesn't it require 3d acceleration?
* bzflag-server? is it required for bzflag?
* cellhunter //not really a game, it's rather a tool for mapping cell
* crimsonfields
  towers with the freerunner, would be nice to have.
* freedoom // free software data (.wad) for the game named doom.
* frozen-bubble
* openttd* //train simulation
* opentryan
* rocksndiamonds
* supertux,supertux-qvga
* wordwarvi //great game
* xboard //also need a chess engine such as gnuchess or another one
* prboom  ??? //not in the list, but probably not in the newer oe
  either. doom game.


Misc comments:
* Aurora is in meta-smartphone I think.
* Eukrea uses barebox in its layers.
* We have a generic compat wireless that has almost all modules in the
  new oe.
* concierge is an osgi implementation that was used in the buglabs bug
  1.x and not used anymore in the buglabs bug 2.x
* emacs-x11 is already in the new oe, under the name of emacs(yes it
  works with X11).
* fso2-demo-image //obsolete, probably doesn't work anymore because of
zhone
* fso2-console-image //available in meta-fso
* fso-console-image //replaced by fso2-console-image
* gnuradio-image //probably in meta-ettus?
* gpsd-device-config //obsolete?
* linux-bug //kernel too old but no replacement, a 2.6.30 exist without
  display and only serial is in mainline.
* linux-leviathan //obsolete, was for htc dream but got renamed.
* lowpan-tools //seem usefull for the nanonote and it's lowpan sdio
  card. what's the status of the nanonote in the new oe? was there a
  layer somewhere on some git hosting websites?
* madwifi-ng //obsoleted by the ath5k driver
* mokonnect //obsoleted by iliwi
* msmcomm-specs, palmpre-audio-scripts  //palm pre got dropped by
freesmartphone and msmcommd was the deamon that talked to its modem
* remoko* // uses bluez3, bluetooth mouse,keyboard,etc...
  implementation.
* sms-sentry //don't work anymore, need to be updated to the new
  freesmartphone API, usefull for finding the position of your lost
  phone.
* tichy // not tested but may be really old...for the openmoko
* wesnoth-wvga // wesnoth-wvga is the equivalent of wesnoth in the new
  oe, and the old "wesnoth" is a sub wvga version, which is dropped
  upstream.
* xfce46-image,xfce-image there is an xfce image in angstrom in the
  newer oe.

Denis.

Re: [oe] OE-Classic recipe migration status

[Philip Balister]

On 11/19/2012 09:56 AM, Denis 'GNUtoo' Carikli wrote:
> On Sun, 11 Nov 2012 19:11:28 +0000
> Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
>
>> Hi all,
>>
>> Whilst the OE-Core-based layer landscape has grown quite a bit over
>> the last year and we now have a wealth of clean and up-to-date
>> recipes, I've heard a few people commenting that we've still lost
>> quite a few recipes along the way. Nobody who did make that comment
>> has seemed to be able to be specific about what they thought we were
>> missing however, so I figured it would be worth trying to determine
>> exactly which recipes are only available in OE-Classic.
>>
>> With the help of some scripts I've produced a list of the recipes,
>> made some notes and categorised some of them. I've published the list
>> on the wiki (unfortunately I had to split it into two pages since it
>> was too large to put into one):
>>
>>   http://www.openembedded.org/wiki/OE-Classic_Recipes_A-I
>>   http://www.openembedded.org/wiki/OE-Classic_Recipes_J-Z
>>
>> I don't know much about a lot of these recipes, so if you can help to
>> fill in the gaps particularly by marking the obsolete ones as such or
>> adding other comments, that would be great. Either edit the pages
>> directly or make your comments here and I'll merge them.
> Having the following software would be nice:
> * 0xffff,0xffff-native //used for flashing the n900 and for interacting
>    with the n900 NAND partition(decoding what's on an MTD partition such
>    as wifi calibration, MAC address etc...)
> * abiword plugins
> * accelges : gesture recognition for the openmoko freerunner (gta02)
> * asterisk recipes? could still be usefull...
> * batctl	//for mesh networking
> * batmand	//for mesh networking
> * wscan,dvb*	//for looking at dvb-t, some of my devices have USB
> host.
> * ekiga //would be nice for VOIP
> * fennec //renamed to firefox mobile?
> * flashrom //could be definitely usefull to flash BIOS from embedded
>    devices, I cross compiled it by hand for now, devices that have SPI
>    can flash SPI BIOS chips, such as the bug 2.0 or the rasberry pi
> * geoclue // could be usefull if it can uses gpsd
> * gnash //usefull to see flash animations even if now there is html5
>    for youtube
> * gnuchess //nice chess engine but a bit too hard.
> * gnumeric //should be very nice. like ooo/libreoffice calc.
> * gst-ducati // would be really usefull for omap4.
> * gst-player? //isn't it gst-123 or something like that in the new oe?
> * intone-video //would be nice, like intone which is an efl music
>    player but for video.
> * irssi //nice command line IRC client.
> * linphone //VOIP client, no VOIP client seem present in the new oe.
> * mpd-alsa, mpc, // do we have mpd in the new oe? if so that's nice.
>    what about graphical clients?
> * mumudvb //would be nice, for straming dvb.
> * nmap //nice for nmap -sP (for finding IP of local computers).
> * openbmap-logger //same kind of softwaer than cellhunter(see below)
> * privoxy //a proxy that can filter request, usefull for anonimizing
>    the connection or with tor.
> * sflphone-common  //is slfphone in the new oe?
> * tesseract //could be usefull for making apps that uses a camera and
>    recognize text?
> * totem
> * tor //anonymity network.
> * tshark,wireshark //usefull for debugging modem protocol in some
> phones.
>
> Games(All the free games that don't require 3d if possible):
> * abuse (arcade game)
> * bzflag? doesn't it require 3d acceleration?
> * bzflag-server? is it required for bzflag?
> * cellhunter //not really a game, it's rather a tool for mapping cell
> * crimsonfields
>    towers with the freerunner, would be nice to have.
> * freedoom // free software data (.wad) for the game named doom.
> * frozen-bubble
> * openttd* //train simulation
> * opentryan
> * rocksndiamonds
> * supertux,supertux-qvga
> * wordwarvi //great game
> * xboard //also need a chess engine such as gnuchess or another one
> * prboom  ??? //not in the list, but probably not in the newer oe
>    either. doom game.
>
>
> Misc comments:
> * Aurora is in meta-smartphone I think.
> * Eukrea uses barebox in its layers.
> * We have a generic compat wireless that has almost all modules in the
>    new oe.
> * concierge is an osgi implementation that was used in the buglabs bug
>    1.x and not used anymore in the buglabs bug 2.x
> * emacs-x11 is already in the new oe, under the name of emacs(yes it
>    works with X11).
> * fso2-demo-image //obsolete, probably doesn't work anymore because of
> zhone
> * fso2-console-image //available in meta-fso
> * fso-console-image //replaced by fso2-console-image
> * gnuradio-image //probably in meta-ettus?


Images should be kept out or to a minimum of mete-oe. Unless they really 
work on a number of machines.

Philip

> * gpsd-device-config //obsolete?
> * linux-bug //kernel too old but no replacement, a 2.6.30 exist without
>    display and only serial is in mainline.
> * linux-leviathan //obsolete, was for htc dream but got renamed.
> * lowpan-tools //seem usefull for the nanonote and it's lowpan sdio
>    card. what's the status of the nanonote in the new oe? was there a
>    layer somewhere on some git hosting websites?
> * madwifi-ng //obsoleted by the ath5k driver
> * mokonnect //obsoleted by iliwi
> * msmcomm-specs, palmpre-audio-scripts  //palm pre got dropped by
> freesmartphone and msmcommd was the deamon that talked to its modem
> * remoko* // uses bluez3, bluetooth mouse,keyboard,etc...
>    implementation.
> * sms-sentry //don't work anymore, need to be updated to the new
>    freesmartphone API, usefull for finding the position of your lost
>    phone.
> * tichy // not tested but may be really old...for the openmoko
> * wesnoth-wvga // wesnoth-wvga is the equivalent of wesnoth in the new
>    oe, and the old "wesnoth" is a sub wvga version, which is dropped
>    upstream.
> * xfce46-image,xfce-image there is an xfce image in angstrom in the
>    newer oe.
>
> Denis.
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: OE-Classic recipe migration status

[Philip Balister]

On 11/19/2012 09:56 AM, Denis 'GNUtoo' Carikli wrote:
> On Sun, 11 Nov 2012 19:11:28 +0000
> Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
>
>> Hi all,
>>
>> Whilst the OE-Core-based layer landscape has grown quite a bit over
>> the last year and we now have a wealth of clean and up-to-date
>> recipes, I've heard a few people commenting that we've still lost
>> quite a few recipes along the way. Nobody who did make that comment
>> has seemed to be able to be specific about what they thought we were
>> missing however, so I figured it would be worth trying to determine
>> exactly which recipes are only available in OE-Classic.
>>
>> With the help of some scripts I've produced a list of the recipes,
>> made some notes and categorised some of them. I've published the list
>> on the wiki (unfortunately I had to split it into two pages since it
>> was too large to put into one):
>>
>>   http://www.openembedded.org/wiki/OE-Classic_Recipes_A-I
>>   http://www.openembedded.org/wiki/OE-Classic_Recipes_J-Z
>>
>> I don't know much about a lot of these recipes, so if you can help to
>> fill in the gaps particularly by marking the obsolete ones as such or
>> adding other comments, that would be great. Either edit the pages
>> directly or make your comments here and I'll merge them.
> Having the following software would be nice:
> * 0xffff,0xffff-native //used for flashing the n900 and for interacting
>    with the n900 NAND partition(decoding what's on an MTD partition such
>    as wifi calibration, MAC address etc...)
> * abiword plugins
> * accelges : gesture recognition for the openmoko freerunner (gta02)
> * asterisk recipes? could still be usefull...
> * batctl	//for mesh networking
> * batmand	//for mesh networking
> * wscan,dvb*	//for looking at dvb-t, some of my devices have USB
> host.
> * ekiga //would be nice for VOIP
> * fennec //renamed to firefox mobile?
> * flashrom //could be definitely usefull to flash BIOS from embedded
>    devices, I cross compiled it by hand for now, devices that have SPI
>    can flash SPI BIOS chips, such as the bug 2.0 or the rasberry pi
> * geoclue // could be usefull if it can uses gpsd
> * gnash //usefull to see flash animations even if now there is html5
>    for youtube
> * gnuchess //nice chess engine but a bit too hard.
> * gnumeric //should be very nice. like ooo/libreoffice calc.
> * gst-ducati // would be really usefull for omap4.
> * gst-player? //isn't it gst-123 or something like that in the new oe?
> * intone-video //would be nice, like intone which is an efl music
>    player but for video.
> * irssi //nice command line IRC client.
> * linphone //VOIP client, no VOIP client seem present in the new oe.
> * mpd-alsa, mpc, // do we have mpd in the new oe? if so that's nice.
>    what about graphical clients?
> * mumudvb //would be nice, for straming dvb.
> * nmap //nice for nmap -sP (for finding IP of local computers).
> * openbmap-logger //same kind of softwaer than cellhunter(see below)
> * privoxy //a proxy that can filter request, usefull for anonimizing
>    the connection or with tor.
> * sflphone-common  //is slfphone in the new oe?
> * tesseract //could be usefull for making apps that uses a camera and
>    recognize text?
> * totem
> * tor //anonymity network.
> * tshark,wireshark //usefull for debugging modem protocol in some
> phones.
>
> Games(All the free games that don't require 3d if possible):
> * abuse (arcade game)
> * bzflag? doesn't it require 3d acceleration?
> * bzflag-server? is it required for bzflag?
> * cellhunter //not really a game, it's rather a tool for mapping cell
> * crimsonfields
>    towers with the freerunner, would be nice to have.
> * freedoom // free software data (.wad) for the game named doom.
> * frozen-bubble
> * openttd* //train simulation
> * opentryan
> * rocksndiamonds
> * supertux,supertux-qvga
> * wordwarvi //great game
> * xboard //also need a chess engine such as gnuchess or another one
> * prboom  ??? //not in the list, but probably not in the newer oe
>    either. doom game.
>
>
> Misc comments:
> * Aurora is in meta-smartphone I think.
> * Eukrea uses barebox in its layers.
> * We have a generic compat wireless that has almost all modules in the
>    new oe.
> * concierge is an osgi implementation that was used in the buglabs bug
>    1.x and not used anymore in the buglabs bug 2.x
> * emacs-x11 is already in the new oe, under the name of emacs(yes it
>    works with X11).
> * fso2-demo-image //obsolete, probably doesn't work anymore because of
> zhone
> * fso2-console-image //available in meta-fso
> * fso-console-image //replaced by fso2-console-image
> * gnuradio-image //probably in meta-ettus?


Images should be kept out or to a minimum of mete-oe. Unless they really 
work on a number of machines.

Philip

> * gpsd-device-config //obsolete?
> * linux-bug //kernel too old but no replacement, a 2.6.30 exist without
>    display and only serial is in mainline.
> * linux-leviathan //obsolete, was for htc dream but got renamed.
> * lowpan-tools //seem usefull for the nanonote and it's lowpan sdio
>    card. what's the status of the nanonote in the new oe? was there a
>    layer somewhere on some git hosting websites?
> * madwifi-ng //obsoleted by the ath5k driver
> * mokonnect //obsoleted by iliwi
> * msmcomm-specs, palmpre-audio-scripts  //palm pre got dropped by
> freesmartphone and msmcommd was the deamon that talked to its modem
> * remoko* // uses bluez3, bluetooth mouse,keyboard,etc...
>    implementation.
> * sms-sentry //don't work anymore, need to be updated to the new
>    freesmartphone API, usefull for finding the position of your lost
>    phone.
> * tichy // not tested but may be really old...for the openmoko
> * wesnoth-wvga // wesnoth-wvga is the equivalent of wesnoth in the new
>    oe, and the old "wesnoth" is a sub wvga version, which is dropped
>    upstream.
> * xfce46-image,xfce-image there is an xfce image in angstrom in the
>    newer oe.
>
> Denis.
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [OE-core] OE-Classic recipe migration status

[Paul Eggleton]

Hi Denis,

Just commenting on the ones you've asked about or I know something about:

On Monday 19 November 2012 15:56:57 Denis 'GNUtoo' Carikli wrote:
> Having the following software would be nice:
> * 0xffff,0xffff-native //used for flashing the n900 and for interacting
>   with the n900 NAND partition(decoding what's on an MTD partition such
>   as wifi calibration, MAC address etc...)
> * abiword plugins
> * accelges : gesture recognition for the openmoko freerunner (gta02)
> * asterisk recipes? could still be usefull...

There is asterisk in meta-telephony - the remaining recipes are just 
additional sounds AFAICT. 

> * batctl	//for mesh networking
> * batmand	//for mesh networking
> * wscan,dvb*	//for looking at dvb-t, some of my devices have USB
> host.
> * ekiga //would be nice for VOIP
> * fennec //renamed to firefox mobile?

I guess so, I think the rename to Firefox Mobile happened a while ago though 
so anything still named "fennec" is pretty old by now.

> * flashrom //could be definitely usefull to flash BIOS from embedded
>   devices, I cross compiled it by hand for now, devices that have SPI
>   can flash SPI BIOS chips, such as the bug 2.0 or the rasberry pi
> * geoclue // could be usefull if it can uses gpsd
> * gnash //usefull to see flash animations even if now there is html5
>   for youtube

If it works, last I heard it hasn't been particularly successful. My 
information could be out of date however.

> * gnuchess //nice chess engine but a bit too hard.
> * gnumeric //should be very nice. like ooo/libreoffice calc.
> * gst-ducati // would be really usefull for omap4.
> * gst-player? //isn't it gst-123 or something like that in the new oe?

There's a patch, there was feedback that hasn't yet been addressed IIRC and 
thus it has not yet been merged.

> * intone-video //would be nice, like intone which is an efl music
>   player but for video.
> * irssi //nice command line IRC client.
> * linphone //VOIP client, no VOIP client seem present in the new oe.

Perhaps not, I've seen people asking for linphone though.

> * mpd-alsa, mpc, // do we have mpd in the new oe? if so that's nice.
>   what about graphical clients?

We do have mpd and libmpd, but nothing else that I know of.

> * mumudvb //would be nice, for straming dvb.
> * nmap //nice for nmap -sP (for finding IP of local computers).

I have the beginnings of a recipe for nmap, I just need someone to help me get 
past the build issues (some issue with definitions from network headers 
clashing, probably triggered by some autotools breakage).

> * openbmap-logger //same kind of softwaer than cellhunter(see below)
> * privoxy //a proxy that can filter request, usefull for anonimizing
>   the connection or with tor.
> * sflphone-common  //is slfphone in the new oe?

If it is it's not in any of the fairly long list of layers I'd expect to find 
recipes in.

> * tesseract //could be usefull for making apps that uses a camera and
>   recognize text?
> * totem
> * tor //anonymity network.
> * tshark,wireshark //usefull for debugging modem protocol in some
> phones.
> 
> Games(All the free games that don't require 3d if possible):
> * abuse (arcade game)
> * bzflag? doesn't it require 3d acceleration?
> * bzflag-server? is it required for bzflag?
> * cellhunter //not really a game, it's rather a tool for mapping cell
>   towers with the freerunner, would be nice to have.

OK I've removed the [game] tag from this one.

> * crimsonfields
> * freedoom // free software data (.wad) for the game named doom.
> * frozen-bubble

I'd like to see frozen-bubble also; it would necessitate bringing over sdl-
perl as well though.

> * openttd* //train simulation
> * opentryan
> * rocksndiamonds
> * supertux,supertux-qvga
> * wordwarvi //great game
> * xboard //also need a chess engine such as gnuchess or another one
> * prboom  ??? //not in the list, but probably not in the newer oe
>   either. doom game.

prboom should really be in the list, but was excluded because some (unbuilt) 
recipes are in meta-opie since one or two of them were configured to build with 
libsdl-qpe. Someone could use those as a starting point though.

> Misc comments:
> * Aurora is in meta-smartphone I think.

There is aurora-daemon and aurora-systemmanager - do these replace the single 
aurora recipe?

> * Eukrea uses barebox in its layers.

Ah, I see it is in meta-eukrea. Would it be worth making it available in some 
more central location or should this layer be added to the layer index? The 
layer doesn't seem to fall into an obvious category though...

> * We have a generic compat wireless that has almost all modules in the
>   new oe.

Do you mean compat-wireless-all ?

> * concierge is an osgi implementation that was used in the buglabs bug
>   1.x and not used anymore in the buglabs bug 2.x
> * emacs-x11 is already in the new oe, under the name of emacs(yes it
>   works with X11).
> * fso2-demo-image //obsolete, probably doesn't work anymore because of
> zhone
> * fso2-console-image //available in meta-fso
> * fso-console-image //replaced by fso2-console-image

Noted these, thanks.

> * gnuradio-image //probably in meta-ettus?

Ah, I see there is console-gnuradio-image and gnome-gnuradio-image in meta-
ettus, noted.

> * linux-bug //kernel too old but no replacement, a 2.6.30 exist without
>   display and only serial is in mainline.

So what about linux-bug20-linaro_2.6.35.bb in meta-bug? Or is this the kernel 
you're referring to?

> * gpsd-device-config //obsolete?
> * linux-leviathan //obsolete, was for htc dream but got renamed.
> * madwifi-ng //obsoleted by the ath5k driver
> * mokonnect //obsoleted by iliwi

Noted.

> * lowpan-tools //seem usefull for the nanonote and it's lowpan sdio
>   card. what's the status of the nanonote in the new oe? was there a
>   layer somewhere on some git hosting websites?

I don't know of any layer supporting nanonote, no. Wouldn't be difficult to 
create one though.

> * msmcomm-specs, palmpre-audio-scripts  //palm pre got dropped by
> freesmartphone and msmcommd was the deamon that talked to its modem

Presumably these could be picked up by someone else if desired?

> * remoko* // uses bluez3, bluetooth mouse,keyboard,etc...
>   implementation.
> * sms-sentry //don't work anymore, need to be updated to the new
>   freesmartphone API, usefull for finding the position of your lost
>   phone.
> * tichy // not tested but may be really old...for the openmoko
> * wesnoth-wvga // wesnoth-wvga is the equivalent of wesnoth in the new
>   oe, and the old "wesnoth" is a sub wvga version, which is dropped
>   upstream.
> * xfce46-image,xfce-image there is an xfce image in angstrom in the
>   newer oe.

Made notes for most of these, thanks.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: OE-Classic recipe migration status

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

 good work Paul

On Sun, Nov 11, 2012 at 11:11 AM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

>    1484 other
>     218 BSP
>     211 BugLabs
>     195 libs
>     193 obsolete
>     155 obsolete directory (OE-Classic)
>


I think obsolete can be ignored.


>      136 PERL
>     119 python
>      92 distro
>      89 tasks
>      84 nonworking directory (OE-Classic)
>


non working too.


>      80 GPE
>      79 X11 drivers
>      59 images
>      59 games
>      41 fonts
>      23 security
>      20 in another layer
>      18 pending
>      11 EFL
>

[-- Attachment #2: Type: text/html, Size: 1299 bytes --]

Re: [OE-core] OE-Classic recipe migration status

[Khem Raj]

 good work Paul

On Sun, Nov 11, 2012 at 11:11 AM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

>    1484 other
>     218 BSP
>     211 BugLabs
>     195 libs
>     193 obsolete
>     155 obsolete directory (OE-Classic)
>


I think obsolete can be ignored.


>      136 PERL
>     119 python
>      92 distro
>      89 tasks
>      84 nonworking directory (OE-Classic)
>


non working too.


>      80 GPE
>      79 X11 drivers
>      59 images
>      59 games
>      41 fonts
>      23 security
>      20 in another layer
>      18 pending
>      11 EFL
>

Re: [OE-core] OE-Classic recipe migration status

[Paul Eggleton]

On Monday 19 November 2012 09:15:35 Khem Raj wrote:
> On Sun, Nov 11, 2012 at 11:11 AM, Paul Eggleton <
> paul.eggleton@linux.intel.com> wrote:
> >     155 obsolete directory (OE-Classic)
> 
> I think obsolete can be ignored.

Almost all of these yes - depends why they were moved there.

> >      84 nonworking directory (OE-Classic)
> 
> non working too.

Not sure - if they are just broken someone could presumably come along and fix 
them if they're interested in doing so.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre