Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
I still do not follow why you are not waiting patiently for an update. I have already written that I would send one soon (this thread demoralized me and "motivated" though for a bit of delay). All the discussion would have been spared in here, as the issues were addressed before I even sent the wrong version. How about reviewing other pending changes for weeks like stunnel? On Thu, Sep 5, 2013 at 2:04 PM, Joe MacDonald wrote: > [Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On > 13.09.05 (Thu 10:01) Burton, Ross wrote: > > > On 5 September 2013 05:39, Bruce Ashfield > wrote: > > > The meta-virt recipe had the same _1.0.bb extension, and it's SRCREV > lines up > > > with the openflow-1.0.0 tag in the repository: > > > > > > > > > > > > commit 5ccca75a69f99791659bcfbcf35353ab1921320a > > > Author: Glen Gibb > > > Date: Thu Dec 31 16:00:53 2009 -0800 > > > > > > docs: Update ChangeLog to include 1.0.0 information > > > > > > :100644 100644 2f13dd7... aa0e92e... M ChangeLog > > > > > > --- > > > > > > So it's definitely an option to keep that recipe around as the tagged > 1.0, and > > > create a _git that tracks newer changes (where "newer" is relative, > 2011 is > > > the latest commit in that repo). > > > > FWIW, I massively prefer "releases that are taken from git" like this > > (where its a git fetch on a hash that is the tag of the releases) to > > be versioned correctly like _1.0.bb instead of _git.bb for clarity and > > future alternatives such as true git snapshot or multiple versions. > > Yeah, since the SRCREV in the _1.0.bb recipe actually corresponds to the > 1.0 release tag, I'm in agreement. The proposed update from Laszlo also > now seems to justify having a _git.bb version, since it's pointing at a > (relatively) newer version of the recipe. > > -- > -Joe MacDonald. > :wq > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > > ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
[Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.05 (Thu 10:01) Burton, Ross wrote: > On 5 September 2013 05:39, Bruce Ashfield wrote: > > The meta-virt recipe had the same _1.0.bb extension, and it's SRCREV lines > > up > > with the openflow-1.0.0 tag in the repository: > > > > > > > > commit 5ccca75a69f99791659bcfbcf35353ab1921320a > > Author: Glen Gibb > > Date: Thu Dec 31 16:00:53 2009 -0800 > > > > docs: Update ChangeLog to include 1.0.0 information > > > > :100644 100644 2f13dd7... aa0e92e... M ChangeLog > > > > --- > > > > So it's definitely an option to keep that recipe around as the tagged 1.0, > > and > > create a _git that tracks newer changes (where "newer" is relative, 2011 is > > the latest commit in that repo). > > FWIW, I massively prefer "releases that are taken from git" like this > (where its a git fetch on a hash that is the tag of the releases) to > be versioned correctly like _1.0.bb instead of _git.bb for clarity and > future alternatives such as true git snapshot or multiple versions. Yeah, since the SRCREV in the _1.0.bb recipe actually corresponds to the 1.0 release tag, I'm in agreement. The proposed update from Laszlo also now seems to justify having a _git.bb version, since it's pointing at a (relatively) newer version of the recipe. -- -Joe MacDonald. :wq signature.asc Description: Digital signature ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
[Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.05
(Thu 00:39) Bruce Ashfield wrote:
> On Wed, Sep 4, 2013 at 5:14 PM, Joe MacDonald wrote:
> > Actually, after all of that, I do have a couple of additional requests
> > (beyond just the tweak to the commit log).
> >
> >Explicitly cc:ing Bruce here since I'm intentionally not adding
> >meta-virt@. I've gotten bounced from it in the past as I'm not a
> >subscriber and it's subscriber-only.
>
> :) I can't blame you for that, I share the pain (after bouncing off of
> oe-devel
> just a few days ago myself). Thanks for the cc.
*sigh* I mean well. I need to be a little less quick on sending an
email to ensure I've actually done (eg. added a cc) what I've claimed in
it.
> > [[oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.02
> > (Mon 09:20) Laszlo Papp wrote:
> >
> >> 1) The version in meta-virtualization is quite old. It is basically from
> >> 2009,
> >> and a lot of things has changed since then.
> >>
> >> 2) More importantly, this software is more like for networking rather than
> >> virtualization, so I think it was misplaced.
> >
> > SOB please?
> >
> >> ---
> >> .../recipes-support/openflow/openflow_1.0.bb | 32
> >> ++
> >
> > Is this actually based on an OpenFlow 1.0 release, or has it always been
> > 1.0+git? I don't have a copy of meta-virt around to check myself. If
> > there was a real 1.0 recipe around, can we keep it as is and make this
> > openflow_git.bb, more in line with the other +git... recipes?
>
> The meta-virt recipe had the same _1.0.bb extension, and it's SRCREV lines up
> with the openflow-1.0.0 tag in the repository:
I didn't know that. In that case, the recipe naming makes sense to me.
I'm ambivalent when it comes to source tarballs versus git repos and
tags. What I'm looking at makes sense though. Thanks for the
clarification.
-J.
>
>
>
> commit 5ccca75a69f99791659bcfbcf35353ab1921320a
> Author: Glen Gibb
> Date: Thu Dec 31 16:00:53 2009 -0800
>
> docs: Update ChangeLog to include 1.0.0 information
>
> :100644 100644 2f13dd7... aa0e92e... M ChangeLog
>
> ---
>
> So it's definitely an option to keep that recipe around as the tagged 1.0, and
> create a _git that tracks newer changes (where "newer" is relative, 2011 is
> the latest commit in that repo).
>
> Maybe someday, we'll get a working 1.x openflow to play with! :)
>
> Thanks for holding on this briefly, it did help.
>
> Bruce
>
> >
> >> 1 file changed, 32 insertions(+)
> >> create mode 100644
> >> meta-networking/recipes-support/openflow/openflow_1.0.bb
> >>
> >> diff --git a/meta-networking/recipes-support/openflow/openflow_1.0.bb
> >> b/meta-networking/recipes-support/openflow/openflow_1.0.bb
> >> new file mode 100644
> >> index 000..eb7770e
> >> --- /dev/null
> >> +++ b/meta-networking/recipes-support/openflow/openflow_1.0.bb
> >> @@ -0,0 +1,32 @@
> >> +SUMMARY = "OpenFlow"
> >> +DESCRIPTION = "Open standard that enables researchers to run experimental
> >> protocols in the campus networks"
> >> +HOMEPAGE = "http://www.openflow.org";
> >> +SECTION = "networking"
> >> +LICENSE = "GPLv2"
> >> +
> >> +LIC_FILES_CHKSUM = "file://COPYING;md5=e870c934e2c3d6ccf085fd7cf0a1e2e2"
> >> +
> >> +SRCREV = "c84f33f09d5dbcfc9b489f64cb30475bf36f653a"
> >> +PV = "1.0+git${SRCPV}"
> >> +SRC_URI = "git://gitosis.stanford.edu/openflow.git;protocol=git"
> >> +
> >> +DEPENDS = "virtual/libc"
> >> +
> >> +EXTRA_OECONF += "KARCH=${TARGET_ARCH}"
> >> +
> >> +PACKAGECONFIG ??= "libssl"
> >> +PACKAGECONFIG[libssl] = "--enable-ssl,--disable-ssl, openssl, libssl"
> >> +
> >> +S = "${WORKDIR}/git"
> >> +
> >> +inherit autotools
> >> +
> >> +do_configure() {
> >> +./boot.sh
> >> +oe_runconf
> >> +}
> >> +
> >> +do_install_append() {
> >> + # Remove /var/run as it is created on startup
> >> +rm -rf ${D}${localstatedir}/run
> >> +}
> >
> > And while we're in the neighbourhood, can we also clean up the
> > inconsistent spacing?
> >
> > Thanks.
> >
> > --
> > -Joe MacDonald.
> > :wq
> >
> > ___
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> >
>
>
>
--
-Joe MacDonald.
:wq
signature.asc
Description: Digital signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
On Thu, Sep 5, 2013 at 10:01 AM, Burton, Ross wrote: > On 5 September 2013 05:39, Bruce Ashfield > wrote: > > The meta-virt recipe had the same _1.0.bb extension, and it's SRCREV > lines up > > with the openflow-1.0.0 tag in the repository: > > > > > > > > commit 5ccca75a69f99791659bcfbcf35353ab1921320a > > Author: Glen Gibb > > Date: Thu Dec 31 16:00:53 2009 -0800 > > > > docs: Update ChangeLog to include 1.0.0 information > > > > :100644 100644 2f13dd7... aa0e92e... M ChangeLog > > > > --- > > > > So it's definitely an option to keep that recipe around as the tagged > 1.0, and > > create a _git that tracks newer changes (where "newer" is relative, 2011 > is > > the latest commit in that repo). > > FWIW, I massively prefer "releases that are taken from git" like this > (where its a git fetch on a hash that is the tag of the releases) to > be versioned correctly like _1.0.bb instead of _git.bb for clarity and > future alternatives such as true git snapshot or multiple versions. > ... and I massively prefer "released not to be taken from git". So if 1.0 has to be *really* supported which I do not think so, it should get the release tarball. Moreover, there have not been new git commits for about two years now because the standard was taken over by a different organization which seems to work behind the scenes. Too bad, they have not released the latest before that change. Hopefully, this will not mislead anyone that this software is still actively developed in public. That is another very reason IMHO which it would not fit the core layer at all. -- Laszlo > > Ross > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
On 5 September 2013 05:39, Bruce Ashfield wrote: > The meta-virt recipe had the same _1.0.bb extension, and it's SRCREV lines up > with the openflow-1.0.0 tag in the repository: > > > > commit 5ccca75a69f99791659bcfbcf35353ab1921320a > Author: Glen Gibb > Date: Thu Dec 31 16:00:53 2009 -0800 > > docs: Update ChangeLog to include 1.0.0 information > > :100644 100644 2f13dd7... aa0e92e... M ChangeLog > > --- > > So it's definitely an option to keep that recipe around as the tagged 1.0, and > create a _git that tracks newer changes (where "newer" is relative, 2011 is > the latest commit in that repo). FWIW, I massively prefer "releases that are taken from git" like this (where its a git fetch on a hash that is the tag of the releases) to be versioned correctly like _1.0.bb instead of _git.bb for clarity and future alternatives such as true git snapshot or multiple versions. Ross ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
As I wrote, I have not uploaded the newest revision, so please do not
review the old.
Anyway, Bruce managed to demotivate me to contribute. I am currently not in
a mood after all this for sending the update.
On Wed, Sep 4, 2013 at 10:14 PM, Joe MacDonald wrote:
> Actually, after all of that, I do have a couple of additional requests
> (beyond just the tweak to the commit log).
>
>Explicitly cc:ing Bruce here since I'm intentionally not adding
>meta-virt@. I've gotten bounced from it in the past as I'm not a
>subscriber and it's subscriber-only.
>
> [[oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.02
> (Mon 09:20) Laszlo Papp wrote:
>
> > 1) The version in meta-virtualization is quite old. It is basically from
> 2009,
> > and a lot of things has changed since then.
> >
> > 2) More importantly, this software is more like for networking rather
> than
> > virtualization, so I think it was misplaced.
>
> SOB please?
>
> > ---
> > .../recipes-support/openflow/openflow_1.0.bb | 32
> ++
>
> Is this actually based on an OpenFlow 1.0 release, or has it always been
> 1.0+git? I don't have a copy of meta-virt around to check myself. If
> there was a real 1.0 recipe around, can we keep it as is and make this
> openflow_git.bb, more in line with the other +git... recipes?
>
> > 1 file changed, 32 insertions(+)
> > create mode 100644 meta-networking/recipes-support/openflow/
> openflow_1.0.bb
> >
> > diff --git
> > a/meta-networking/recipes-support/openflow/openflow_1.0.bbb/meta-networking/recipes-support/openflow/
> openflow_1.0.bb
> > new file mode 100644
> > index 000..eb7770e
> > --- /dev/null
> > +++ b/meta-networking/recipes-support/openflow/openflow_1.0.bb
> > @@ -0,0 +1,32 @@
> > +SUMMARY = "OpenFlow"
> > +DESCRIPTION = "Open standard that enables researchers to run
> experimental protocols in the campus networks"
> > +HOMEPAGE = "http://www.openflow.org";
> > +SECTION = "networking"
> > +LICENSE = "GPLv2"
> > +
> > +LIC_FILES_CHKSUM = "file://COPYING;md5=e870c934e2c3d6ccf085fd7cf0a1e2e2"
> > +
> > +SRCREV = "c84f33f09d5dbcfc9b489f64cb30475bf36f653a"
> > +PV = "1.0+git${SRCPV}"
> > +SRC_URI = "git://gitosis.stanford.edu/openflow.git;protocol=git"
> > +
> > +DEPENDS = "virtual/libc"
> > +
> > +EXTRA_OECONF += "KARCH=${TARGET_ARCH}"
> > +
> > +PACKAGECONFIG ??= "libssl"
> > +PACKAGECONFIG[libssl] = "--enable-ssl,--disable-ssl, openssl, libssl"
> > +
> > +S = "${WORKDIR}/git"
> > +
> > +inherit autotools
> > +
> > +do_configure() {
> > +./boot.sh
> > +oe_runconf
> > +}
> > +
> > +do_install_append() {
> > + # Remove /var/run as it is created on startup
> > +rm -rf ${D}${localstatedir}/run
> > +}
>
> And while we're in the neighbourhood, can we also clean up the
> inconsistent spacing?
>
> Thanks.
>
> --
> -Joe MacDonald.
> :wq
>
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
On Wed, Sep 4, 2013 at 5:14 PM, Joe MacDonald wrote:
> Actually, after all of that, I do have a couple of additional requests
> (beyond just the tweak to the commit log).
>
>Explicitly cc:ing Bruce here since I'm intentionally not adding
>meta-virt@. I've gotten bounced from it in the past as I'm not a
>subscriber and it's subscriber-only.
:) I can't blame you for that, I share the pain (after bouncing off of oe-devel
just a few days ago myself). Thanks for the cc.
>
> [[oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.02
> (Mon 09:20) Laszlo Papp wrote:
>
>> 1) The version in meta-virtualization is quite old. It is basically from
>> 2009,
>> and a lot of things has changed since then.
>>
>> 2) More importantly, this software is more like for networking rather than
>> virtualization, so I think it was misplaced.
>
> SOB please?
>
>> ---
>> .../recipes-support/openflow/openflow_1.0.bb | 32
>> ++
>
> Is this actually based on an OpenFlow 1.0 release, or has it always been
> 1.0+git? I don't have a copy of meta-virt around to check myself. If
> there was a real 1.0 recipe around, can we keep it as is and make this
> openflow_git.bb, more in line with the other +git... recipes?
The meta-virt recipe had the same _1.0.bb extension, and it's SRCREV lines up
with the openflow-1.0.0 tag in the repository:
commit 5ccca75a69f99791659bcfbcf35353ab1921320a
Author: Glen Gibb
Date: Thu Dec 31 16:00:53 2009 -0800
docs: Update ChangeLog to include 1.0.0 information
:100644 100644 2f13dd7... aa0e92e... M ChangeLog
---
So it's definitely an option to keep that recipe around as the tagged 1.0, and
create a _git that tracks newer changes (where "newer" is relative, 2011 is
the latest commit in that repo).
Maybe someday, we'll get a working 1.x openflow to play with! :)
Thanks for holding on this briefly, it did help.
Bruce
>
>> 1 file changed, 32 insertions(+)
>> create mode 100644 meta-networking/recipes-support/openflow/openflow_1.0.bb
>>
>> diff --git a/meta-networking/recipes-support/openflow/openflow_1.0.bb
>> b/meta-networking/recipes-support/openflow/openflow_1.0.bb
>> new file mode 100644
>> index 000..eb7770e
>> --- /dev/null
>> +++ b/meta-networking/recipes-support/openflow/openflow_1.0.bb
>> @@ -0,0 +1,32 @@
>> +SUMMARY = "OpenFlow"
>> +DESCRIPTION = "Open standard that enables researchers to run experimental
>> protocols in the campus networks"
>> +HOMEPAGE = "http://www.openflow.org";
>> +SECTION = "networking"
>> +LICENSE = "GPLv2"
>> +
>> +LIC_FILES_CHKSUM = "file://COPYING;md5=e870c934e2c3d6ccf085fd7cf0a1e2e2"
>> +
>> +SRCREV = "c84f33f09d5dbcfc9b489f64cb30475bf36f653a"
>> +PV = "1.0+git${SRCPV}"
>> +SRC_URI = "git://gitosis.stanford.edu/openflow.git;protocol=git"
>> +
>> +DEPENDS = "virtual/libc"
>> +
>> +EXTRA_OECONF += "KARCH=${TARGET_ARCH}"
>> +
>> +PACKAGECONFIG ??= "libssl"
>> +PACKAGECONFIG[libssl] = "--enable-ssl,--disable-ssl, openssl, libssl"
>> +
>> +S = "${WORKDIR}/git"
>> +
>> +inherit autotools
>> +
>> +do_configure() {
>> +./boot.sh
>> +oe_runconf
>> +}
>> +
>> +do_install_append() {
>> + # Remove /var/run as it is created on startup
>> +rm -rf ${D}${localstatedir}/run
>> +}
>
> And while we're in the neighbourhood, can we also clean up the
> inconsistent spacing?
>
> Thanks.
>
> --
> -Joe MacDonald.
> :wq
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
On Wed, Sep 4, 2013 at 5:04 PM, Joe MacDonald wrote: > [Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.04 > (Wed 08:22) Bruce Ashfield wrote: > >> On Tue, Sep 3, 2013 at 11:27 PM, Joe MacDonald wrote: >> > On Tue, Sep 3, 2013 at 6:39 PM, Bruce Ashfield >> > wrote: >> >> > ... >> >> - We run some tests against meta-virt and give you the thumbs up when it >> >>is safe to merge, and the meta-virt copy can be deleted. I definitely >> >> don't >> >>want two of these running around. >> > >> > I don't mind delaying a merge a bit while waiting for more feedback on >> > testing, provided we're talking about a reasonable timeframe. >> > Otherwise, if the submitted OpenFlow is working well enough in >> > meta-net, I'm inclined to merge it and take patches from you guys if >> > you find issues down the road. That'll be how it will work anyway in >> > three month's time, for example, when meta-virt has dropped their >> > copy. >> > >> > How long do you think you'll need on this? >> >> I can test the new SRCREV and recipe by the end of the day, assuming >> that you have the slightly edited version by the time I'm done, there >> shouldn't be any incurred delay. > > Great, thanks. Let me know how it goes. My cherry-picked version of the patch looks sane, the newer hash worked ok in my tests. Which isn't surprising, since the number of changes between the old and new SRCREV isn't that big. So from that front, we are fine to keep chugging along. Bruce > > -- > -Joe MacDonald. > :wq -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
[Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.04 (Wed 08:22) Bruce Ashfield wrote: > On Tue, Sep 3, 2013 at 11:27 PM, Joe MacDonald wrote: > > On Tue, Sep 3, 2013 at 6:39 PM, Bruce Ashfield > > wrote: > >> ... > >> - We run some tests against meta-virt and give you the thumbs up when it > >>is safe to merge, and the meta-virt copy can be deleted. I definitely > >> don't > >>want two of these running around. > > > > I don't mind delaying a merge a bit while waiting for more feedback on > > testing, provided we're talking about a reasonable timeframe. > > Otherwise, if the submitted OpenFlow is working well enough in > > meta-net, I'm inclined to merge it and take patches from you guys if > > you find issues down the road. That'll be how it will work anyway in > > three month's time, for example, when meta-virt has dropped their > > copy. > > > > How long do you think you'll need on this? > > I can test the new SRCREV and recipe by the end of the day, assuming > that you have the slightly edited version by the time I'm done, there > shouldn't be any incurred delay. Great, thanks. Let me know how it goes. -- -Joe MacDonald. :wq signature.asc Description: Digital signature ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
Actually, after all of that, I do have a couple of additional requests
(beyond just the tweak to the commit log).
Explicitly cc:ing Bruce here since I'm intentionally not adding
meta-virt@. I've gotten bounced from it in the past as I'm not a
subscriber and it's subscriber-only.
[[oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.02 (Mon
09:20) Laszlo Papp wrote:
> 1) The version in meta-virtualization is quite old. It is basically from 2009,
> and a lot of things has changed since then.
>
> 2) More importantly, this software is more like for networking rather than
> virtualization, so I think it was misplaced.
SOB please?
> ---
> .../recipes-support/openflow/openflow_1.0.bb | 32
> ++
Is this actually based on an OpenFlow 1.0 release, or has it always been
1.0+git? I don't have a copy of meta-virt around to check myself. If
there was a real 1.0 recipe around, can we keep it as is and make this
openflow_git.bb, more in line with the other +git... recipes?
> 1 file changed, 32 insertions(+)
> create mode 100644 meta-networking/recipes-support/openflow/openflow_1.0.bb
>
> diff --git a/meta-networking/recipes-support/openflow/openflow_1.0.bb
> b/meta-networking/recipes-support/openflow/openflow_1.0.bb
> new file mode 100644
> index 000..eb7770e
> --- /dev/null
> +++ b/meta-networking/recipes-support/openflow/openflow_1.0.bb
> @@ -0,0 +1,32 @@
> +SUMMARY = "OpenFlow"
> +DESCRIPTION = "Open standard that enables researchers to run experimental
> protocols in the campus networks"
> +HOMEPAGE = "http://www.openflow.org";
> +SECTION = "networking"
> +LICENSE = "GPLv2"
> +
> +LIC_FILES_CHKSUM = "file://COPYING;md5=e870c934e2c3d6ccf085fd7cf0a1e2e2"
> +
> +SRCREV = "c84f33f09d5dbcfc9b489f64cb30475bf36f653a"
> +PV = "1.0+git${SRCPV}"
> +SRC_URI = "git://gitosis.stanford.edu/openflow.git;protocol=git"
> +
> +DEPENDS = "virtual/libc"
> +
> +EXTRA_OECONF += "KARCH=${TARGET_ARCH}"
> +
> +PACKAGECONFIG ??= "libssl"
> +PACKAGECONFIG[libssl] = "--enable-ssl,--disable-ssl, openssl, libssl"
> +
> +S = "${WORKDIR}/git"
> +
> +inherit autotools
> +
> +do_configure() {
> +./boot.sh
> +oe_runconf
> +}
> +
> +do_install_append() {
> + # Remove /var/run as it is created on startup
> +rm -rf ${D}${localstatedir}/run
> +}
And while we're in the neighbourhood, can we also clean up the
inconsistent spacing?
Thanks.
--
-Joe MacDonald.
:wq
signature.asc
Description: Digital signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
[Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.03 (Tue 17:18) Joe MacDonald wrote: > [Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.03 > (Tue 14:47) Laszlo Papp wrote: > > > On Tue, Sep 3, 2013 at 2:38 PM, Bruce Ashfield > > wrote: > > > > On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp wrote: > > > IMO, most of this email is red herring, and the main topic is a > > networking > > > specification should be in meta-networking. Why would I (or anyone for > > that > > > matter) need *any* virtualization layer when I am working on a network > > > device? > > > > Ah, so I see we won't address the fact that the mailing list should have > > been consulted and that the goals of the oe-layers should be to reduce > > duplication and get everyone working together. I promise, I won't > > mention > > this again, but it is a key point I want to make. > > > > > > Frankly, you have mentioned the credit so strongly in this thread for a few > > lines which is not even copyright'd, I will rewrite this stuff from scratch > > today. > > It may be that that's an appropriate approach at this juncture, I don't > know. I'd like to see us not lose any work that's already been done and > would be disappointed if something turns out to be a regression in the > meta-networking version of openflow from the meta-virtualization version > purely due to a communications breakdown. I'll trust you guys to sort > that out. > > My only comment on what I've seen so far is maybe in the commit log > remove the 2) comment as it borders on editorializing and update the log > to match more of the style of recipes ported from "the world" (mostly OE > Classic, so far, for meta-networking). See 2cde4a, 8fec90, or 413a9 for > something I think is a good way to reference history. Hey Laszlo, Just to close on this, if Bruce (or someone working with meta-virtualization) is nearing completion of testing with the recipe you've already submitted, is that the one you want me to consider for merging, or are you going to have a v2 coming out soon? FYI: I expect to be done merging your other patch (the stunnel one) later on today. It didn't get lost, I just didn't get to merge it yesterday. -J. > > Thanks, > -J. > > > I am sad to see this discussion is going into "credit debate" rather > > than technical stuff. > > > > Actually, I even had a recipe before looking into virtualization, but that > > probably does not matter for you... > > > > > > > I am sorry for your historical misplacement, but it is not an excuse > > for > > > future mistakes IMHO. If your virtualization depends on network stuff, > > you > > > should *not* force others for virtualization whatever that is. If you > > need > > > that, build on top of networking or use own recipes maintained by you. > > > > I don't agree with that characterization, since it is very black and > > white. > > > > Having a binding to the larger meta-oe universe (at least for some > > recipes), > > isn't always a good thing, and having self contained layers is also > > something > > that is a goal at times. I'm not saying this is the case here, just that > > what > > you describe above about networking devices not wanting virtualization, > > is at times flipped around from other layers when looking at meta-oe. > > > > meta-virt and meta-networking are very similar in age and the group of > > recipes to start meta-virt were a merging of two existing layers (a good > > collaboration) and a lot contributed by ENEA, it was a good effort and I > > don't think it's right to drop all traces of that effort or describe it > > as > > a > > mistake. > > > > Again, opinions vary, that's part of the fun. > > > > > > The problem is not that opinions matter, but *your* opinion about black > > being > > white IMHO. Did you even bother to read what the openflow standard is for? > > It > > is for networking devices, come on, and you still think it is not a > > meta-networking material? > > > > Please come up with a *rebruttal* and bother substantiating it. > > > > > > > I fail to see how it is a problem. Even more, the recipe was > > completely > > > broken like virtual/libc, *a
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
[Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.04 (Wed 09:13) Philip Balister wrote: > On 09/03/2013 11:27 PM, Joe MacDonald wrote: > > On Tue, Sep 3, 2013 at 6:39 PM, Bruce Ashfield > > wrote: > >> > >> On Tue, Sep 3, 2013 at 5:08 PM, Joe MacDonald wrote: > >>> Little late coming to this party, I guess. Sorry all. In my defense > >>> I'll just say that I was less connected than I expected to be over my > >>> vacation and there's been considerable catching up to do. > >>> > >>> [Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On > >>> 13.09.03 (Tue 09:38) Bruce Ashfield wrote: > >>> > >>>> On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp wrote: > >>>>> IMO, most of this email is red herring, and the main topic is a > >>>>> networking > >>>>> specification should be in meta-networking. Why would I (or anyone for > >>>>> that > >>>>> matter) need *any* virtualization layer when I am working on a network > >>>>> device? > >>>> > >>>> Ah, so I see we won't address the fact that the mailing list should have > >>>> been consulted and that the goals of the oe-layers should be to reduce > >>>> duplication and get everyone working together. I promise, I won't mention > >>>> this again, but it is a key point I want to make. > >>>> > >>>> I understand where this is going, and I'll try to engage at a technical > >>>> level, it's all that I can do. > >>>> > >>>>> > >>>>> I am sorry for your historical misplacement, but it is not an excuse for > >>>>> future mistakes IMHO. If your virtualization depends on network stuff, > >>>>> you > >>>>> should *not* force others for virtualization whatever that is. If you > >>>>> need > >>>>> that, build on top of networking or use own recipes maintained by you. > >>>> > >>>> I don't agree with that characterization, since it is very black and > >>>> white. > >>>> > >>>> Having a binding to the larger meta-oe universe (at least for some > >>>> recipes), > >>>> isn't always a good thing, and having self contained layers is also > >>>> something > >>>> that is a goal at times. I'm not saying this is the case here, just that > >>>> what > >>>> you describe above about networking devices not wanting virtualization, > >>>> is at times flipped around from other layers when looking at meta-oe. > >>> > >>> The archives contain my response to this and I did say I won't be going > >>> back to this particular topic again, so I'll just say that if you really > >>> feel that a dis-incentive to contributing something to meta-networking > >>> (or to using meta-networking in your project) is an implicit dependency > >>> on the larger meta-oe world, we should talk about that sometime. > >> > >> Ha. My bad on this front, I honestly didn't check the archives for what you > >> had said before, I was just responding to the appearance of the recipe. > >> > >> As for the larger meta-oe being required to get at meta-networking, I'm not > >> sure that you and I can solve that. The concern about being able to get an > >> updated package from meta-networking, and not other packages from the > >> other layers, i.e. the granularity of the one big chunk is hard to deal > >> with > >> if you only want to get a specific layer updated. > > > > That is exactly the topic I was suggesting we can talk about if that's > > an issue you're trying to work around in meta-virtualization. This > > isn't really the place for it, though, and I don't want to confuse > > anyone or subvert the thread. Let me say that I'll leave it with you. > > I'd be happy to try to understand what the concerns are you have with > > depending on meta-networking and whether they're inherent in meta-net > > or if they're due to meta-net being part of the larger meta-oe. > > > > The same applies to anyone else working on a layer with clearly > > networking components that may be reluctant to incorporate it into > > meta-net. I'm welcoming submissions of useful components an
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
On Wed, Sep 4, 2013 at 2:13 PM, Philip Balister wrote: > > > The same applies to anyone else working on a layer with clearly > > networking components that may be reluctant to incorporate it into > > meta-net. I'm welcoming submissions of useful components and I'd be > > really disappointed if we ended up having the same (or similar) > > recipes in multiple public layers purely due to reticence and > > (perceived?) extra dependencies. I'll be other meta-oe maintainers > > feel the same, too. Balkanisation benefits no one. > > > > Back on topic, then. > > I am really late to the game ... > > If you are having trouble figuring out what layer a recipe belongs in > due to it being needed for several layers, maybe the package in question > belongs in oe-core. You are not just late, but also quite off IMHO ... ;-) As written already, and if you had taken the time to look into the software in question, you would have realized that from more than one point of view that this standard is definitely a domain specific network material. It is *far* away from being a core component. Off-topic: I do not understand why meta-virtualization is this messy. That seems to cause the whole annoyance in here on top of the "give me the credit for a few lines which can only be written in one way" other argument. Anyway, this seems to be an appropriate trigger for meta-virtualization to get some stabilization. Past mistakes are no excuse for introducing more, in my book. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
On 09/03/2013 11:27 PM, Joe MacDonald wrote: > On Tue, Sep 3, 2013 at 6:39 PM, Bruce Ashfield > wrote: >> >> On Tue, Sep 3, 2013 at 5:08 PM, Joe MacDonald wrote: >>> Little late coming to this party, I guess. Sorry all. In my defense >>> I'll just say that I was less connected than I expected to be over my >>> vacation and there's been considerable catching up to do. >>> >>> [Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On >>> 13.09.03 (Tue 09:38) Bruce Ashfield wrote: >>> >>>> On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp wrote: >>>>> IMO, most of this email is red herring, and the main topic is a networking >>>>> specification should be in meta-networking. Why would I (or anyone for >>>>> that >>>>> matter) need *any* virtualization layer when I am working on a network >>>>> device? >>>> >>>> Ah, so I see we won't address the fact that the mailing list should have >>>> been consulted and that the goals of the oe-layers should be to reduce >>>> duplication and get everyone working together. I promise, I won't mention >>>> this again, but it is a key point I want to make. >>>> >>>> I understand where this is going, and I'll try to engage at a technical >>>> level, it's all that I can do. >>>> >>>>> >>>>> I am sorry for your historical misplacement, but it is not an excuse for >>>>> future mistakes IMHO. If your virtualization depends on network stuff, you >>>>> should *not* force others for virtualization whatever that is. If you need >>>>> that, build on top of networking or use own recipes maintained by you. >>>> >>>> I don't agree with that characterization, since it is very black and white. >>>> >>>> Having a binding to the larger meta-oe universe (at least for some >>>> recipes), >>>> isn't always a good thing, and having self contained layers is also >>>> something >>>> that is a goal at times. I'm not saying this is the case here, just that >>>> what >>>> you describe above about networking devices not wanting virtualization, >>>> is at times flipped around from other layers when looking at meta-oe. >>> >>> The archives contain my response to this and I did say I won't be going >>> back to this particular topic again, so I'll just say that if you really >>> feel that a dis-incentive to contributing something to meta-networking >>> (or to using meta-networking in your project) is an implicit dependency >>> on the larger meta-oe world, we should talk about that sometime. >> >> Ha. My bad on this front, I honestly didn't check the archives for what you >> had said before, I was just responding to the appearance of the recipe. >> >> As for the larger meta-oe being required to get at meta-networking, I'm not >> sure that you and I can solve that. The concern about being able to get an >> updated package from meta-networking, and not other packages from the >> other layers, i.e. the granularity of the one big chunk is hard to deal with >> if you only want to get a specific layer updated. > > That is exactly the topic I was suggesting we can talk about if that's > an issue you're trying to work around in meta-virtualization. This > isn't really the place for it, though, and I don't want to confuse > anyone or subvert the thread. Let me say that I'll leave it with you. > I'd be happy to try to understand what the concerns are you have with > depending on meta-networking and whether they're inherent in meta-net > or if they're due to meta-net being part of the larger meta-oe. > > The same applies to anyone else working on a layer with clearly > networking components that may be reluctant to incorporate it into > meta-net. I'm welcoming submissions of useful components and I'd be > really disappointed if we ended up having the same (or similar) > recipes in multiple public layers purely due to reticence and > (perceived?) extra dependencies. I'll be other meta-oe maintainers > feel the same, too. Balkanisation benefits no one. > > Back on topic, then. I am really late to the game ... If you are having trouble figuring out what layer a recipe belongs in due to it being needed for several layers, maybe the package in question belongs in oe-core. Philip > >> >> Does anyone else have a good suggestion
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
On Tue, Sep 3, 2013 at 11:27 PM, Joe MacDonald wrote: > On Tue, Sep 3, 2013 at 6:39 PM, Bruce Ashfield > wrote: >> >> On Tue, Sep 3, 2013 at 5:08 PM, Joe MacDonald wrote: >> > Little late coming to this party, I guess. Sorry all. In my defense >> > I'll just say that I was less connected than I expected to be over my >> > vacation and there's been considerable catching up to do. >> > >> > [Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On >> > 13.09.03 (Tue 09:38) Bruce Ashfield wrote: >> > >> >> On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp wrote: >> >> > IMO, most of this email is red herring, and the main topic is a >> >> > networking >> >> > specification should be in meta-networking. Why would I (or anyone for >> >> > that >> >> > matter) need *any* virtualization layer when I am working on a network >> >> > device? >> >> >> >> Ah, so I see we won't address the fact that the mailing list should have >> >> been consulted and that the goals of the oe-layers should be to reduce >> >> duplication and get everyone working together. I promise, I won't mention >> >> this again, but it is a key point I want to make. >> >> >> >> I understand where this is going, and I'll try to engage at a technical >> >> level, it's all that I can do. >> >> >> >> > >> >> > I am sorry for your historical misplacement, but it is not an excuse for >> >> > future mistakes IMHO. If your virtualization depends on network stuff, >> >> > you >> >> > should *not* force others for virtualization whatever that is. If you >> >> > need >> >> > that, build on top of networking or use own recipes maintained by you. >> >> >> >> I don't agree with that characterization, since it is very black and >> >> white. >> >> >> >> Having a binding to the larger meta-oe universe (at least for some >> >> recipes), >> >> isn't always a good thing, and having self contained layers is also >> >> something >> >> that is a goal at times. I'm not saying this is the case here, just that >> >> what >> >> you describe above about networking devices not wanting virtualization, >> >> is at times flipped around from other layers when looking at meta-oe. >> > >> > The archives contain my response to this and I did say I won't be going >> > back to this particular topic again, so I'll just say that if you really >> > feel that a dis-incentive to contributing something to meta-networking >> > (or to using meta-networking in your project) is an implicit dependency >> > on the larger meta-oe world, we should talk about that sometime. >> >> Ha. My bad on this front, I honestly didn't check the archives for what you >> had said before, I was just responding to the appearance of the recipe. >> >> As for the larger meta-oe being required to get at meta-networking, I'm not >> sure that you and I can solve that. The concern about being able to get an >> updated package from meta-networking, and not other packages from the >> other layers, i.e. the granularity of the one big chunk is hard to deal with >> if you only want to get a specific layer updated. > > That is exactly the topic I was suggesting we can talk about if that's > an issue you're trying to work around in meta-virtualization. This > isn't really the place for it, though, and I don't want to confuse > anyone or subvert the thread. Let me say that I'll leave it with you. > I'd be happy to try to understand what the concerns are you have with > depending on meta-networking and whether they're inherent in meta-net > or if they're due to meta-net being part of the larger meta-oe. I won't go on a tangent either .. but yes, I can't control individual SRCREVs of the layers, so I'm either cherry picking .. or taking everything. meta-net causes no pain for me, and I have no complaints at all. > > The same applies to anyone else working on a layer with clearly > networking components that may be reluctant to incorporate it into > meta-net. I'm welcoming submissions of useful components and I'd be > really disappointed if we ended up having the same (or similar) > recipes in multiple public layers purely due to reticence and +1. I completely agree, that's why I wanted to get s
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
On Tue, Sep 3, 2013 at 6:39 PM, Bruce Ashfield wrote: > > On Tue, Sep 3, 2013 at 5:08 PM, Joe MacDonald wrote: > > Little late coming to this party, I guess. Sorry all. In my defense > > I'll just say that I was less connected than I expected to be over my > > vacation and there's been considerable catching up to do. > > > > [Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On > > 13.09.03 (Tue 09:38) Bruce Ashfield wrote: > > > >> On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp wrote: > >> > IMO, most of this email is red herring, and the main topic is a > >> > networking > >> > specification should be in meta-networking. Why would I (or anyone for > >> > that > >> > matter) need *any* virtualization layer when I am working on a network > >> > device? > >> > >> Ah, so I see we won't address the fact that the mailing list should have > >> been consulted and that the goals of the oe-layers should be to reduce > >> duplication and get everyone working together. I promise, I won't mention > >> this again, but it is a key point I want to make. > >> > >> I understand where this is going, and I'll try to engage at a technical > >> level, it's all that I can do. > >> > >> > > >> > I am sorry for your historical misplacement, but it is not an excuse for > >> > future mistakes IMHO. If your virtualization depends on network stuff, > >> > you > >> > should *not* force others for virtualization whatever that is. If you > >> > need > >> > that, build on top of networking or use own recipes maintained by you. > >> > >> I don't agree with that characterization, since it is very black and white. > >> > >> Having a binding to the larger meta-oe universe (at least for some > >> recipes), > >> isn't always a good thing, and having self contained layers is also > >> something > >> that is a goal at times. I'm not saying this is the case here, just that > >> what > >> you describe above about networking devices not wanting virtualization, > >> is at times flipped around from other layers when looking at meta-oe. > > > > The archives contain my response to this and I did say I won't be going > > back to this particular topic again, so I'll just say that if you really > > feel that a dis-incentive to contributing something to meta-networking > > (or to using meta-networking in your project) is an implicit dependency > > on the larger meta-oe world, we should talk about that sometime. > > Ha. My bad on this front, I honestly didn't check the archives for what you > had said before, I was just responding to the appearance of the recipe. > > As for the larger meta-oe being required to get at meta-networking, I'm not > sure that you and I can solve that. The concern about being able to get an > updated package from meta-networking, and not other packages from the > other layers, i.e. the granularity of the one big chunk is hard to deal with > if you only want to get a specific layer updated. That is exactly the topic I was suggesting we can talk about if that's an issue you're trying to work around in meta-virtualization. This isn't really the place for it, though, and I don't want to confuse anyone or subvert the thread. Let me say that I'll leave it with you. I'd be happy to try to understand what the concerns are you have with depending on meta-networking and whether they're inherent in meta-net or if they're due to meta-net being part of the larger meta-oe. The same applies to anyone else working on a layer with clearly networking components that may be reluctant to incorporate it into meta-net. I'm welcoming submissions of useful components and I'd be really disappointed if we ended up having the same (or similar) recipes in multiple public layers purely due to reticence and (perceived?) extra dependencies. I'll be other meta-oe maintainers feel the same, too. Balkanisation benefits no one. Back on topic, then. > > Does anyone else have a good suggestion on how to deal with that ? > > > > >> meta-virt and meta-networking are very similar in age and the group of > >> recipes to start meta-virt were a merging of two existing layers (a good > >> collaboration) and a lot contributed by ENEA, it was a good effort and I > >> don't think it's right to drop all traces of that effort or describe it as > >> a > >> mistake. > >> > >> Agai
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
On Tue, Sep 3, 2013 at 5:08 PM, Joe MacDonald wrote: > Little late coming to this party, I guess. Sorry all. In my defense > I'll just say that I was less connected than I expected to be over my > vacation and there's been considerable catching up to do. > > [Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.03 > (Tue 09:38) Bruce Ashfield wrote: > >> On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp wrote: >> > IMO, most of this email is red herring, and the main topic is a networking >> > specification should be in meta-networking. Why would I (or anyone for that >> > matter) need *any* virtualization layer when I am working on a network >> > device? >> >> Ah, so I see we won't address the fact that the mailing list should have >> been consulted and that the goals of the oe-layers should be to reduce >> duplication and get everyone working together. I promise, I won't mention >> this again, but it is a key point I want to make. >> >> I understand where this is going, and I'll try to engage at a technical >> level, it's all that I can do. >> >> > >> > I am sorry for your historical misplacement, but it is not an excuse for >> > future mistakes IMHO. If your virtualization depends on network stuff, you >> > should *not* force others for virtualization whatever that is. If you need >> > that, build on top of networking or use own recipes maintained by you. >> >> I don't agree with that characterization, since it is very black and white. >> >> Having a binding to the larger meta-oe universe (at least for some recipes), >> isn't always a good thing, and having self contained layers is also something >> that is a goal at times. I'm not saying this is the case here, just that what >> you describe above about networking devices not wanting virtualization, >> is at times flipped around from other layers when looking at meta-oe. > > The archives contain my response to this and I did say I won't be going > back to this particular topic again, so I'll just say that if you really > feel that a dis-incentive to contributing something to meta-networking > (or to using meta-networking in your project) is an implicit dependency > on the larger meta-oe world, we should talk about that sometime. Ha. My bad on this front, I honestly didn't check the archives for what you had said before, I was just responding to the appearance of the recipe. As for the larger meta-oe being required to get at meta-networking, I'm not sure that you and I can solve that. The concern about being able to get an updated package from meta-networking, and not other packages from the other layers, i.e. the granularity of the one big chunk is hard to deal with if you only want to get a specific layer updated. Does anyone else have a good suggestion on how to deal with that ? > >> meta-virt and meta-networking are very similar in age and the group of >> recipes to start meta-virt were a merging of two existing layers (a good >> collaboration) and a lot contributed by ENEA, it was a good effort and I >> don't think it's right to drop all traces of that effort or describe it as a >> mistake. >> >> Again, opinions vary, that's part of the fun. >> >> > >> > I fail to see how it is a problem. Even more, the recipe was completely >> > broken like virtual/libc, *ancient* version, wrong rm'f stuff, bad >> > description IMHO, etc for meta-networking. >> >> Patches would have been accepted :) >> >> > >> > I do not personally mind if you keep your clone because it is your >> > business, but surely, networking devices should use a network layer, and >> > that is exactly the point of meta-networking. >> >> I'll agree to disagree, I've tried to say that we should look at what the two >> layers need, come up with a plan, keep the credit to the original authors >> and then decide how to move forward. i.e. if there are multiple users of the >> recipe, maybe see about getting it into oe-core, etc. But I see that isn't on >> the menu today. >> >> I'll ping Joe and we'll see what we can figure out as timing for a path >> forward. > > At this point I'm inclined to agree that OpenFlow is a reasonable fit > for meta-networking, it's something I think I may have even referenced FWIW, I agree as well. > in my original proposal for creating meta-networking. But if Laszlo is > going to propose a new recipe for inclusion, I'll wait to see it before > trying out any of the existing stuff in
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
Little late coming to this party, I guess. Sorry all. In my defense I'll just say that I was less connected than I expected to be over my vacation and there's been considerable catching up to do. [Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.03 (Tue 09:38) Bruce Ashfield wrote: > On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp wrote: > > IMO, most of this email is red herring, and the main topic is a networking > > specification should be in meta-networking. Why would I (or anyone for that > > matter) need *any* virtualization layer when I am working on a network > > device? > > Ah, so I see we won't address the fact that the mailing list should have > been consulted and that the goals of the oe-layers should be to reduce > duplication and get everyone working together. I promise, I won't mention > this again, but it is a key point I want to make. > > I understand where this is going, and I'll try to engage at a technical > level, it's all that I can do. > > > > > I am sorry for your historical misplacement, but it is not an excuse for > > future mistakes IMHO. If your virtualization depends on network stuff, you > > should *not* force others for virtualization whatever that is. If you need > > that, build on top of networking or use own recipes maintained by you. > > I don't agree with that characterization, since it is very black and white. > > Having a binding to the larger meta-oe universe (at least for some recipes), > isn't always a good thing, and having self contained layers is also something > that is a goal at times. I'm not saying this is the case here, just that what > you describe above about networking devices not wanting virtualization, > is at times flipped around from other layers when looking at meta-oe. The archives contain my response to this and I did say I won't be going back to this particular topic again, so I'll just say that if you really feel that a dis-incentive to contributing something to meta-networking (or to using meta-networking in your project) is an implicit dependency on the larger meta-oe world, we should talk about that sometime. > meta-virt and meta-networking are very similar in age and the group of > recipes to start meta-virt were a merging of two existing layers (a good > collaboration) and a lot contributed by ENEA, it was a good effort and I > don't think it's right to drop all traces of that effort or describe it as a > mistake. > > Again, opinions vary, that's part of the fun. > > > > > I fail to see how it is a problem. Even more, the recipe was completely > > broken like virtual/libc, *ancient* version, wrong rm'f stuff, bad > > description IMHO, etc for meta-networking. > > Patches would have been accepted :) > > > > > I do not personally mind if you keep your clone because it is your > > business, but surely, networking devices should use a network layer, and > > that is exactly the point of meta-networking. > > I'll agree to disagree, I've tried to say that we should look at what the two > layers need, come up with a plan, keep the credit to the original authors > and then decide how to move forward. i.e. if there are multiple users of the > recipe, maybe see about getting it into oe-core, etc. But I see that isn't on > the menu today. > > I'll ping Joe and we'll see what we can figure out as timing for a path > forward. At this point I'm inclined to agree that OpenFlow is a reasonable fit for meta-networking, it's something I think I may have even referenced in my original proposal for creating meta-networking. But if Laszlo is going to propose a new recipe for inclusion, I'll wait to see it before trying out any of the existing stuff in my tree. I certainly don't want to invalidate or break any of the work in meta-virtualization and I appreciate hearing that this is a concern, but hopefully you understand that if that did happen, it'd be by accident as I'm not on the meta-virtualization list and I don't know what you guys are doing over there. That is to say feel free to pipe up on any stuff like this in the future and if you have any specific requests on how this merge happens, please let me know. -J. > > Cheers, > > Bruce > > > > > > > On Tue, Sep 3, 2013 at 2:04 PM, Bruce Ashfield > > wrote: > > > >> On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp wrote: > >> > On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield >> >wrote: > >> > > >> >> On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp wrote: > >> >> > 1) The version in meta-virtualizatio
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
[Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.03 (Tue 14:47) Laszlo Papp wrote: > On Tue, Sep 3, 2013 at 2:38 PM, Bruce Ashfield > wrote: > > On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp wrote: > > IMO, most of this email is red herring, and the main topic is a > networking > > specification should be in meta-networking. Why would I (or anyone for > that > > matter) need *any* virtualization layer when I am working on a network > > device? > > Ah, so I see we won't address the fact that the mailing list should have > been consulted and that the goals of the oe-layers should be to reduce > duplication and get everyone working together. I promise, I won't mention > this again, but it is a key point I want to make. > > > Frankly, you have mentioned the credit so strongly in this thread for a few > lines which is not even copyright'd, I will rewrite this stuff from scratch > today. It may be that that's an appropriate approach at this juncture, I don't know. I'd like to see us not lose any work that's already been done and would be disappointed if something turns out to be a regression in the meta-networking version of openflow from the meta-virtualization version purely due to a communications breakdown. I'll trust you guys to sort that out. My only comment on what I've seen so far is maybe in the commit log remove the 2) comment as it borders on editorializing and update the log to match more of the style of recipes ported from "the world" (mostly OE Classic, so far, for meta-networking). See 2cde4a, 8fec90, or 413a9 for something I think is a good way to reference history. Thanks, -J. > I am sad to see this discussion is going into "credit debate" rather > than technical stuff. > > Actually, I even had a recipe before looking into virtualization, but that > probably does not matter for you... > > > > I am sorry for your historical misplacement, but it is not an excuse for > > future mistakes IMHO. If your virtualization depends on network stuff, > you > > should *not* force others for virtualization whatever that is. If you > need > > that, build on top of networking or use own recipes maintained by you. > > I don't agree with that characterization, since it is very black and > white. > > Having a binding to the larger meta-oe universe (at least for some > recipes), > isn't always a good thing, and having self contained layers is also > something > that is a goal at times. I'm not saying this is the case here, just that > what > you describe above about networking devices not wanting virtualization, > is at times flipped around from other layers when looking at meta-oe. > > meta-virt and meta-networking are very similar in age and the group of > recipes to start meta-virt were a merging of two existing layers (a good > collaboration) and a lot contributed by ENEA, it was a good effort and I > don't think it's right to drop all traces of that effort or describe it as > a > mistake. > > Again, opinions vary, that's part of the fun. > > > The problem is not that opinions matter, but *your* opinion about black being > white IMHO. Did you even bother to read what the openflow standard is for? It > is for networking devices, come on, and you still think it is not a > meta-networking material? > > Please come up with a *rebruttal* and bother substantiating it. > > > > I fail to see how it is a problem. Even more, the recipe was completely > > broken like virtual/libc, *ancient* version, wrong rm'f stuff, bad > > description IMHO, etc for meta-networking. > > Patches would have been accepted :) > > > Here is the patch, so what is your argument again? That it should remain in > your beloved meta-virtualization while disregarding the fact it is a > networking > standard? > > I do not seem to have pushed the latest version of the change though. > > > > I do not personally mind if you keep your clone because it is your > > business, but surely, networking devices should use a network layer, and > > that is exactly the point of meta-networking. > > I'll agree to disagree, I've tried to say that we should look at what the > two > layers need, come up with a plan, keep the credit to the original authors > and then decide how to move forward. i.e. if there are multiple users of > the > recipe, maybe see about getting it into oe-core, etc. But I see that isn't
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
On Tue, Sep 3, 2013 at 2:38 PM, Bruce Ashfield wrote: > On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp wrote: > > IMO, most of this email is red herring, and the main topic is a > networking > > specification should be in meta-networking. Why would I (or anyone for > that > > matter) need *any* virtualization layer when I am working on a network > > device? > > Ah, so I see we won't address the fact that the mailing list should have > been consulted and that the goals of the oe-layers should be to reduce > duplication and get everyone working together. I promise, I won't mention > this again, but it is a key point I want to make. > Frankly, you have mentioned the credit so strongly in this thread for a few lines which is not even copyright'd, I will rewrite this stuff from scratch today. I am sad to see this discussion is going into "credit debate" rather than technical stuff. Actually, I even had a recipe before looking into virtualization, but that probably does not matter for you... > I am sorry for your historical misplacement, but it is not an excuse for > > future mistakes IMHO. If your virtualization depends on network stuff, > you > > should *not* force others for virtualization whatever that is. If you > need > > that, build on top of networking or use own recipes maintained by you. > > I don't agree with that characterization, since it is very black and white. > > Having a binding to the larger meta-oe universe (at least for some > recipes), > isn't always a good thing, and having self contained layers is also > something > that is a goal at times. I'm not saying this is the case here, just that > what > you describe above about networking devices not wanting virtualization, > is at times flipped around from other layers when looking at meta-oe. > > meta-virt and meta-networking are very similar in age and the group of > recipes to start meta-virt were a merging of two existing layers (a good > collaboration) and a lot contributed by ENEA, it was a good effort and I > don't think it's right to drop all traces of that effort or describe it as > a > mistake. > > Again, opinions vary, that's part of the fun. > The problem is not that opinions matter, but *your* opinion about black being white IMHO. Did you even bother to read what the openflow standard is for? It is for networking devices, come on, and you still think it is not a meta-networking material? Please come up with a *rebruttal* and bother substantiating it. > > I fail to see how it is a problem. Even more, the recipe was completely > > broken like virtual/libc, *ancient* version, wrong rm'f stuff, bad > > description IMHO, etc for meta-networking. > > Patches would have been accepted :) > Here is the patch, so what is your argument again? That it should remain in your beloved meta-virtualization while disregarding the fact it is a networking standard? I do not seem to have pushed the latest version of the change though. > I do not personally mind if you keep your clone because it is your > > business, but surely, networking devices should use a network layer, and > > that is exactly the point of meta-networking. > > I'll agree to disagree, I've tried to say that we should look at what the > two > layers need, come up with a plan, keep the credit to the original authors > and then decide how to move forward. i.e. if there are multiple users of > the > recipe, maybe see about getting it into oe-core, etc. But I see that isn't > on > the menu today. > oe-core would not make sense for this. It is *far* from being that core component. It is actually a very domain specific networking component. > I'll ping Joe and we'll see what we can figure out as timing for a path > forward. > There is no *any* need to ping him. This change was sent to the mailing list as instructed by the meta-networking layer manual, hence he will see it. Please keep this "ping" in public, and do not hide this behind the scenes in private. The more eyes, the better. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp wrote: > IMO, most of this email is red herring, and the main topic is a networking > specification should be in meta-networking. Why would I (or anyone for that > matter) need *any* virtualization layer when I am working on a network > device? Ah, so I see we won't address the fact that the mailing list should have been consulted and that the goals of the oe-layers should be to reduce duplication and get everyone working together. I promise, I won't mention this again, but it is a key point I want to make. I understand where this is going, and I'll try to engage at a technical level, it's all that I can do. > > I am sorry for your historical misplacement, but it is not an excuse for > future mistakes IMHO. If your virtualization depends on network stuff, you > should *not* force others for virtualization whatever that is. If you need > that, build on top of networking or use own recipes maintained by you. I don't agree with that characterization, since it is very black and white. Having a binding to the larger meta-oe universe (at least for some recipes), isn't always a good thing, and having self contained layers is also something that is a goal at times. I'm not saying this is the case here, just that what you describe above about networking devices not wanting virtualization, is at times flipped around from other layers when looking at meta-oe. meta-virt and meta-networking are very similar in age and the group of recipes to start meta-virt were a merging of two existing layers (a good collaboration) and a lot contributed by ENEA, it was a good effort and I don't think it's right to drop all traces of that effort or describe it as a mistake. Again, opinions vary, that's part of the fun. > > I fail to see how it is a problem. Even more, the recipe was completely > broken like virtual/libc, *ancient* version, wrong rm'f stuff, bad > description IMHO, etc for meta-networking. Patches would have been accepted :) > > I do not personally mind if you keep your clone because it is your > business, but surely, networking devices should use a network layer, and > that is exactly the point of meta-networking. I'll agree to disagree, I've tried to say that we should look at what the two layers need, come up with a plan, keep the credit to the original authors and then decide how to move forward. i.e. if there are multiple users of the recipe, maybe see about getting it into oe-core, etc. But I see that isn't on the menu today. I'll ping Joe and we'll see what we can figure out as timing for a path forward. Cheers, Bruce > > > On Tue, Sep 3, 2013 at 2:04 PM, Bruce Ashfield > wrote: > >> On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp wrote: >> > On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield > >wrote: >> > >> >> On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp wrote: >> >> > 1) The version in meta-virtualization is quite old. It is basically >> from >> >> 2009, >> >> > and a lot of things has changed since then. >> >> >> >> And that was on purpose, there are some tight bindings to SDN and hence >> why >> >> it is in meta-virtualization, and not a valid reason to not contact the >> >> layer >> >> maintainers directly, have a discussion and not set the update to the >> >> current >> >> layer. >> >> >> > >> > I do not understand why I would need to contact a foo layer maintainer >> when >> > I think a recipe has not much to do with foo. >> >> really ? I honestly don't know what to say about that logic. >> >> There's a recipe in another public layer, that is being updated, and was >> put there for a reason. You grab a copy, send it to another layer and >> don't even bother to cc' the originating layer's mailing list ? >> >> You don't think the right thing to do would be to ask a few questions, >> and agree to the path forward ? >> >> > >> > >> >> If you would have asked, you would have been told that updates are >> pending >> >> with bindings that need to stay in lock step with other parts of >> meta-virt. >> >> >> > >> > Sorry, but how is this relevant? It is an extremely old recipe, and >> should >> > not be used. Moreover, this should not block the non-ancient users at >> all, >> > which is probably the majority. >> >> The only difference between your recipe is a new SRCREV, of which there >> was one already pending. And perhaps, if you asked, you would have found >> out that there were dependent other layers and recipes on some particular >> SRCREV. >> >> In such a situation, we could have updated the recipe to create a new one >> and kept the old revision around. >> >> Instead, you copied it, updated the SRCREV with no reference to the >> original >> layer, the authors and their contributions. So we have two copies in the >> ecosystem. >> >> > >> > >> >> > 2) More importantly, this software is more like for networking rather >> >> than >> >> > virtualization, so I think it was misplaced. >> >> >> >> I disagree, so for now meta-virt is going to keep it's varian
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
IMO, most of this email is red herring, and the main topic is a networking specification should be in meta-networking. Why would I (or anyone for that matter) need *any* virtualization layer when I am working on a network device? I am sorry for your historical misplacement, but it is not an excuse for future mistakes IMHO. If your virtualization depends on network stuff, you should *not* force others for virtualization whatever that is. If you need that, build on top of networking or use own recipes maintained by you. I fail to see how it is a problem. Even more, the recipe was completely broken like virtual/libc, *ancient* version, wrong rm'f stuff, bad description IMHO, etc for meta-networking. I do not personally mind if you keep your clone because it is your business, but surely, networking devices should use a network layer, and that is exactly the point of meta-networking. On Tue, Sep 3, 2013 at 2:04 PM, Bruce Ashfield wrote: > On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp wrote: > > On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield >wrote: > > > >> On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp wrote: > >> > 1) The version in meta-virtualization is quite old. It is basically > from > >> 2009, > >> > and a lot of things has changed since then. > >> > >> And that was on purpose, there are some tight bindings to SDN and hence > why > >> it is in meta-virtualization, and not a valid reason to not contact the > >> layer > >> maintainers directly, have a discussion and not set the update to the > >> current > >> layer. > >> > > > > I do not understand why I would need to contact a foo layer maintainer > when > > I think a recipe has not much to do with foo. > > really ? I honestly don't know what to say about that logic. > > There's a recipe in another public layer, that is being updated, and was > put there for a reason. You grab a copy, send it to another layer and > don't even bother to cc' the originating layer's mailing list ? > > You don't think the right thing to do would be to ask a few questions, > and agree to the path forward ? > > > > > > >> If you would have asked, you would have been told that updates are > pending > >> with bindings that need to stay in lock step with other parts of > meta-virt. > >> > > > > Sorry, but how is this relevant? It is an extremely old recipe, and > should > > not be used. Moreover, this should not block the non-ancient users at > all, > > which is probably the majority. > > The only difference between your recipe is a new SRCREV, of which there > was one already pending. And perhaps, if you asked, you would have found > out that there were dependent other layers and recipes on some particular > SRCREV. > > In such a situation, we could have updated the recipe to create a new one > and kept the old revision around. > > Instead, you copied it, updated the SRCREV with no reference to the > original > layer, the authors and their contributions. So we have two copies in the > ecosystem. > > > > > > >> > 2) More importantly, this software is more like for networking rather > >> than > >> > virtualization, so I think it was misplaced. > >> > >> I disagree, so for now meta-virt is going to keep it's variants of the > >> recipes and > >> we need to have an actual discussion to figure out the best way forward. > >> > > > > ,,, and I disagree with you. Read the specification for openflow, > please. I > > I've read the specification, but I don't understand why I'm being talked > down > to here. > > See above, there's enough reason to have a discussion or at least > follow some etiquette. > > > fail to understand how it has anything to do with virtualization. > > Seriously, this is a software for networking devices. That is, exactly > the > > main purpose what meta-networking is trying to achieve: aiding the > > development for networking devices. As for me, it is totally > > non-comprehensive why a networking specification and the relevant > > implementation would be in meta-virtualization rather than > meta-networking. > > There are different opinions on many things, that's the way things work. > I don't think branding those alternate opinions as invalid and "non > comprehensive" > is productive .. do you ? > > openflow has control channels to openvswitch, openvswitch is tightly > coupled > to the cloud and infrastructure work that happens in meta-virt. > OpenDayLight > also has bindings to openvswitch, virtualization and more SDN components. > Having them all move in lockstep and not introduce incompatible SRCREVs > as they all update has proven tricky in the past, and will do so. Spreading > out across multiple layers will only make it more difficult. > > I'm not arguing that openflow isn't networking, that wouldn't be logical. > I'm > saying that it is where it is for a reason, there are multiple uses and we > can't > simply wave a wand and invalidate those other uses because we don't agree > with them. > > > > > Not to mention, I do not understand why you are trying
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp wrote: > On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield > wrote: > >> On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp wrote: >> > 1) The version in meta-virtualization is quite old. It is basically from >> 2009, >> > and a lot of things has changed since then. >> >> And that was on purpose, there are some tight bindings to SDN and hence why >> it is in meta-virtualization, and not a valid reason to not contact the >> layer >> maintainers directly, have a discussion and not set the update to the >> current >> layer. >> > > I do not understand why I would need to contact a foo layer maintainer when > I think a recipe has not much to do with foo. really ? I honestly don't know what to say about that logic. There's a recipe in another public layer, that is being updated, and was put there for a reason. You grab a copy, send it to another layer and don't even bother to cc' the originating layer's mailing list ? You don't think the right thing to do would be to ask a few questions, and agree to the path forward ? > > >> If you would have asked, you would have been told that updates are pending >> with bindings that need to stay in lock step with other parts of meta-virt. >> > > Sorry, but how is this relevant? It is an extremely old recipe, and should > not be used. Moreover, this should not block the non-ancient users at all, > which is probably the majority. The only difference between your recipe is a new SRCREV, of which there was one already pending. And perhaps, if you asked, you would have found out that there were dependent other layers and recipes on some particular SRCREV. In such a situation, we could have updated the recipe to create a new one and kept the old revision around. Instead, you copied it, updated the SRCREV with no reference to the original layer, the authors and their contributions. So we have two copies in the ecosystem. > > >> > 2) More importantly, this software is more like for networking rather >> than >> > virtualization, so I think it was misplaced. >> >> I disagree, so for now meta-virt is going to keep it's variants of the >> recipes and >> we need to have an actual discussion to figure out the best way forward. >> > > ,,, and I disagree with you. Read the specification for openflow, please. I I've read the specification, but I don't understand why I'm being talked down to here. See above, there's enough reason to have a discussion or at least follow some etiquette. > fail to understand how it has anything to do with virtualization. > Seriously, this is a software for networking devices. That is, exactly the > main purpose what meta-networking is trying to achieve: aiding the > development for networking devices. As for me, it is totally > non-comprehensive why a networking specification and the relevant > implementation would be in meta-virtualization rather than meta-networking. There are different opinions on many things, that's the way things work. I don't think branding those alternate opinions as invalid and "non comprehensive" is productive .. do you ? openflow has control channels to openvswitch, openvswitch is tightly coupled to the cloud and infrastructure work that happens in meta-virt. OpenDayLight also has bindings to openvswitch, virtualization and more SDN components. Having them all move in lockstep and not introduce incompatible SRCREVs as they all update has proven tricky in the past, and will do so. Spreading out across multiple layers will only make it more difficult. I'm not arguing that openflow isn't networking, that wouldn't be logical. I'm saying that it is where it is for a reason, there are multiple uses and we can't simply wave a wand and invalidate those other uses because we don't agree with them. > > Not to mention, I do not understand why you are trying to set a straw man > in here. The discussion you are "requesting" is exactly what this thread is > meant to be. So, I think you are simply incorrect IMHO. :-) You didn't cc' the meta-vitualization mailing list. I happen to be on both, and by chance this is happening, and shouldn't replace a more reasonable workflow. Cheers, Bruce > > Cheers, > Laszlo > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield wrote: > On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp wrote: > > 1) The version in meta-virtualization is quite old. It is basically from > 2009, > > and a lot of things has changed since then. > > And that was on purpose, there are some tight bindings to SDN and hence why > it is in meta-virtualization, and not a valid reason to not contact the > layer > maintainers directly, have a discussion and not set the update to the > current > layer. > I do not understand why I would need to contact a foo layer maintainer when I think a recipe has not much to do with foo. > If you would have asked, you would have been told that updates are pending > with bindings that need to stay in lock step with other parts of meta-virt. > Sorry, but how is this relevant? It is an extremely old recipe, and should not be used. Moreover, this should not block the non-ancient users at all, which is probably the majority. > > 2) More importantly, this software is more like for networking rather > than > > virtualization, so I think it was misplaced. > > I disagree, so for now meta-virt is going to keep it's variants of the > recipes and > we need to have an actual discussion to figure out the best way forward. > ,,, and I disagree with you. Read the specification for openflow, please. I fail to understand how it has anything to do with virtualization. Seriously, this is a software for networking devices. That is, exactly the main purpose what meta-networking is trying to achieve: aiding the development for networking devices. As for me, it is totally non-comprehensive why a networking specification and the relevant implementation would be in meta-virtualization rather than meta-networking. Not to mention, I do not understand why you are trying to set a straw man in here. The discussion you are "requesting" is exactly what this thread is meant to be. So, I think you are simply incorrect IMHO. :-) Cheers, Laszlo ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp wrote:
> 1) The version in meta-virtualization is quite old. It is basically from 2009,
> and a lot of things has changed since then.
And that was on purpose, there are some tight bindings to SDN and hence why
it is in meta-virtualization, and not a valid reason to not contact the layer
maintainers directly, have a discussion and not set the update to the current
layer.
If you would have asked, you would have been told that updates are pending
with bindings that need to stay in lock step with other parts of meta-virt.
>
> 2) More importantly, this software is more like for networking rather than
> virtualization, so I think it was misplaced.
I disagree, so for now meta-virt is going to keep it's variants of the
recipes and
we need to have an actual discussion to figure out the best way forward.
Cheers,
Bruce
> ---
> .../recipes-support/openflow/openflow_1.0.bb | 32
> ++
> 1 file changed, 32 insertions(+)
> create mode 100644 meta-networking/recipes-support/openflow/openflow_1.0.bb
>
> diff --git a/meta-networking/recipes-support/openflow/openflow_1.0.bb
> b/meta-networking/recipes-support/openflow/openflow_1.0.bb
> new file mode 100644
> index 000..eb7770e
> --- /dev/null
> +++ b/meta-networking/recipes-support/openflow/openflow_1.0.bb
> @@ -0,0 +1,32 @@
> +SUMMARY = "OpenFlow"
> +DESCRIPTION = "Open standard that enables researchers to run experimental
> protocols in the campus networks"
> +HOMEPAGE = "http://www.openflow.org";
> +SECTION = "networking"
> +LICENSE = "GPLv2"
> +
> +LIC_FILES_CHKSUM = "file://COPYING;md5=e870c934e2c3d6ccf085fd7cf0a1e2e2"
> +
> +SRCREV = "c84f33f09d5dbcfc9b489f64cb30475bf36f653a"
> +PV = "1.0+git${SRCPV}"
> +SRC_URI = "git://gitosis.stanford.edu/openflow.git;protocol=git"
> +
> +DEPENDS = "virtual/libc"
> +
> +EXTRA_OECONF += "KARCH=${TARGET_ARCH}"
> +
> +PACKAGECONFIG ??= "libssl"
> +PACKAGECONFIG[libssl] = "--enable-ssl,--disable-ssl, openssl, libssl"
> +
> +S = "${WORKDIR}/git"
> +
> +inherit autotools
> +
> +do_configure() {
> +./boot.sh
> +oe_runconf
> +}
> +
> +do_install_append() {
> + # Remove /var/run as it is created on startup
> +rm -rf ${D}${localstatedir}/run
> +}
> --
> 1.8.4
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-networking][PATCH] openflow: Add latest from git
1) The version in meta-virtualization is quite old. It is basically from 2009,
and a lot of things has changed since then.
2) More importantly, this software is more like for networking rather than
virtualization, so I think it was misplaced.
---
.../recipes-support/openflow/openflow_1.0.bb | 32 ++
1 file changed, 32 insertions(+)
create mode 100644 meta-networking/recipes-support/openflow/openflow_1.0.bb
diff --git a/meta-networking/recipes-support/openflow/openflow_1.0.bb
b/meta-networking/recipes-support/openflow/openflow_1.0.bb
new file mode 100644
index 000..eb7770e
--- /dev/null
+++ b/meta-networking/recipes-support/openflow/openflow_1.0.bb
@@ -0,0 +1,32 @@
+SUMMARY = "OpenFlow"
+DESCRIPTION = "Open standard that enables researchers to run experimental
protocols in the campus networks"
+HOMEPAGE = "http://www.openflow.org";
+SECTION = "networking"
+LICENSE = "GPLv2"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=e870c934e2c3d6ccf085fd7cf0a1e2e2"
+
+SRCREV = "c84f33f09d5dbcfc9b489f64cb30475bf36f653a"
+PV = "1.0+git${SRCPV}"
+SRC_URI = "git://gitosis.stanford.edu/openflow.git;protocol=git"
+
+DEPENDS = "virtual/libc"
+
+EXTRA_OECONF += "KARCH=${TARGET_ARCH}"
+
+PACKAGECONFIG ??= "libssl"
+PACKAGECONFIG[libssl] = "--enable-ssl,--disable-ssl, openssl, libssl"
+
+S = "${WORKDIR}/git"
+
+inherit autotools
+
+do_configure() {
+./boot.sh
+oe_runconf
+}
+
+do_install_append() {
+ # Remove /var/run as it is created on startup
+rm -rf ${D}${localstatedir}/run
+}
--
1.8.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
