[oe] [meta-networking] ntp: enable systemd-timedated control for ntp.service

[Andreas Müller]

Signed-off-by: Andreas Müller schnitzelt...@googlemail.com
---
 meta-networking/recipes-support/ntp/ntp.inc   |5 +
 meta-networking/recipes-support/ntp/ntp/ntpd.list |1 +
 2 files changed, 6 insertions(+), 0 deletions(-)
 create mode 100644 meta-networking/recipes-support/ntp/ntp/ntpd.list

diff --git a/meta-networking/recipes-support/ntp/ntp.inc 
b/meta-networking/recipes-support/ntp/ntp.inc
index 79e7401..ebfa222 100644
--- a/meta-networking/recipes-support/ntp/ntp.inc
+++ b/meta-networking/recipes-support/ntp/ntp.inc
@@ -22,6 +22,7 @@ SRC_URI = 
http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-${PV}.tar.g
file://ntpd.service \
file://sntp.service \
file://sntp \
+   file://ntpd.list \
 
 
 inherit autotools update-rc.d systemd
@@ -63,6 +64,10 @@ do_install_append() {
 install -m 0644 ${WORKDIR}/ntpdate.service ${D}${systemd_unitdir}/system/
 install -m 0644 ${WORKDIR}/ntpd.service ${D}${systemd_unitdir}/system/
 install -m 0644 ${WORKDIR}/sntp.service ${D}${systemd_unitdir}/system/
+
+# see http://www.freedesktop.org/wiki/Software/systemd/timedated/
+install -d ${D}${libdir}/systemd/ntp-units.d
+install -m 0644 ${WORKDIR}/ntpd.list 
${D}${libdir}/systemd/ntp-units.d/60-ntpd.list
 }
 
 PACKAGES += ntpdate sntp ${PN}-tickadj ${PN}-utils
diff --git a/meta-networking/recipes-support/ntp/ntp/ntpd.list 
b/meta-networking/recipes-support/ntp/ntp/ntpd.list
new file mode 100644
index 000..d1fe6b7
--- /dev/null
+++ b/meta-networking/recipes-support/ntp/ntp/ntpd.list
@@ -0,0 +1 @@
+ntpd.service
-- 
1.7.6.5

___
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

[Bruce Ashfield]

On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp lp...@kde.org wrote:
 On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield 
 bruce.ashfi...@gmail.comwrote:

 On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp lp...@kde.org 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

[Laszlo Papp]

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 bruce.ashfi...@gmail.comwrote:

 On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp lp...@kde.org wrote:
  On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield bruce.ashfi...@gmail.com
 wrote:
 
  On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp lp...@kde.org 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. 

Re: [oe] [meta-networking][PATCH] openflow: Add latest from git

[Bruce Ashfield]

On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp lp...@kde.org 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 
 bruce.ashfi...@gmail.comwrote:

 On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp lp...@kde.org wrote:
  On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield bruce.ashfi...@gmail.com
 wrote:
 
  On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp lp...@kde.org 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 

Re: [oe] [meta-networking][PATCH] openflow: Add latest from git

[Laszlo Papp]

On Tue, Sep 3, 2013 at 2:38 PM, Bruce Ashfield bruce.ashfi...@gmail.comwrote:

 On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp lp...@kde.org 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] [PATCH] libcarp-perl: added

[Emil R. Petersen]

I suppose? I'll do that if you want.
If you're putting it to me as a question - No idea!
As a request, then sure.

On 03/09/13 16:55, Laszlo Papp wrote:

Hmm, shouldn't you mention in the commit message which version just in case?


On Tue, Sep 3, 2013 at 3:53 PM, Emil Petersene...@movis.dk  wrote:


Carp recipe added

Signed-off-by: Emil Petersene...@movis.dk
---
  .../recipes-perl/libcarp-perl/libcarp-perl_1.26.bb | 25
++
  1 file changed, 25 insertions(+)
  create mode 100644 meta-perl/recipes-perl/libcarp-perl/
libcarp-perl_1.26.bb

diff --git 
a/meta-perl/recipes-perl/libcarp-perl/libcarp-perl_1.26.bbb/meta-perl/recipes-perl/libcarp-perl/
libcarp-perl_1.26.bb
new file mode 100644
index 000..0ae7bf3
--- /dev/null
+++ b/meta-perl/recipes-perl/libcarp-perl/libcarp-perl_1.26.bb
@@ -0,0 +1,25 @@
+SUMMARY = Carp - alternative warn and die for modules
+AUTHOR = Andrew Mainzef...@fysk.org
+HOMEPAGE = https://metacpan.org/module/Carp;
+SECTION = libs
+LICENSE = Artistic-1.0 | GPL-1.0+
+LIC_FILES_CHKSUM = file://README;md5=d613c00d4cb8d48c01f09fca2a7873a0
+
+RPROVIDES_${PN} = libcarp-heavy-perl
+
+RDEPENDS_${PN} += perl-module-strict \
+   perl-module-warnings \
+   libexporter-perl \
+   libtest-more-perl \
+  
+
+SRC_URI = 
http://cpan.metacpan.org/authors/id/Z/ZE/ZEFRAM/Carp-${PV}.tar.gz;
+SRC_URI[md5sum] = 86229a6f0dc44e0730f96c1909bb346d
+SRC_URI[sha256sum] =
0a310222a9a52eca9425bca19e6d8e04faa8bb4f64d5c16f2f6cce8190c0a99b
+
+S = ${WORKDIR}/Carp-${PV}
+
+inherit cpan
+
+BBCLASSEXTEND = native
+
--
1.8.4.rc3

___
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

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [PATCH] libtest-perl_1.26: added

[Emil Petersen]

Test recipe added

Signed-off-by: Emil Petersen e...@movis.dk
---
 .../recipes-perl/libtest-perl/libtest-perl_1.26.bb  | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 meta-perl/recipes-perl/libtest-perl/libtest-perl_1.26.bb

diff --git a/meta-perl/recipes-perl/libtest-perl/libtest-perl_1.26.bb 
b/meta-perl/recipes-perl/libtest-perl/libtest-perl_1.26.bb
new file mode 100644
index 000..5596ffe
--- /dev/null
+++ b/meta-perl/recipes-perl/libtest-perl/libtest-perl_1.26.bb
@@ -0,0 +1,21 @@
+SUMMARY = Test - provides a simple framework for writing test scripts
+AUTHOR = Jesse Vincent jesse+c...@fsck.com
+HOMEPAGE = https://metacpan.org/module/Test;
+SECTION = libs
+LICENSE = Artistic-1.0 | GPL-1.0+
+LIC_FILES_CHKSUM = file://README;md5=82da57b253d95f830de58fae58c3af4e
+
+RDEPEND_${PN} = libfile-spec-perl \
+ libtest-harness-perl \
+
+
+SRC_URI = http://cpan.metacpan.org/authors/id/J/JE/JESSE/Test-${PV}.tar.gz;
+SRC_URI[md5sum] = 6ec6583c34be3770edd466876546fb50
+SRC_URI[sha256sum] = 
f7701bd28e05e7f82fe9a181bbab38f53fa6aeae48d2a810da74d1b981d4f392
+
+S = ${WORKDIR}/Test-${PV}
+
+inherit cpan
+
+BBCLASSEXTEND = native
+
-- 
1.8.4.rc3

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH] libcarp-perl: added

[Laszlo Papp]

I was doing like this before, but I have been told to mention the version,
too. I have no strong opinion about it. :-)


On Tue, Sep 3, 2013 at 3:56 PM, Emil R. Petersen e...@movis.dk wrote:

 I suppose? I'll do that if you want.
 If you're putting it to me as a question - No idea!
 As a request, then sure.


 On 03/09/13 16:55, Laszlo Papp wrote:

 Hmm, shouldn't you mention in the commit message which version just in
 case?


 On Tue, Sep 3, 2013 at 3:53 PM, Emil Petersene...@movis.dk  wrote:

  Carp recipe added

 Signed-off-by: Emil Petersene...@movis.dk
 ---
   
 .../recipes-perl/libcarp-perl/**libcarp-perl_1.26.bbhttp://libcarp-perl_1.26.bb|
  25
 ++
   1 file changed, 25 insertions(+)
   create mode 100644 meta-perl/recipes-perl/**libcarp-perl/
 libcarp-perl_1.26.bb

 diff --git a/meta-perl/recipes-perl/**libcarp-perl/libcarp-perl_1.**
 26.bbb/meta-perl/recipes-perl/**libcarp-perl/
 libcarp-perl_1.26.bb
 new file mode 100644
 index 000..0ae7bf3
 --- /dev/null
 +++ 
 b/meta-perl/recipes-perl/**libcarp-perl/libcarp-perl_1.**26.bbhttp://libcarp-perl_1.26.bb
 @@ -0,0 +1,25 @@
 +SUMMARY = Carp - alternative warn and die for modules
 +AUTHOR = Andrew Mainzef...@fysk.org
 +HOMEPAGE = 
 https://metacpan.org/module/**Carphttps://metacpan.org/module/Carp
 
 +SECTION = libs
 +LICENSE = Artistic-1.0 | GPL-1.0+
 +LIC_FILES_CHKSUM = file://README;md5=**d613c00d4cb8d48c01f09fca2a7873*
 *a0
 +
 +RPROVIDES_${PN} = libcarp-heavy-perl
 +
 +RDEPENDS_${PN} += perl-module-strict \
 +   perl-module-warnings \
 +   libexporter-perl \
 +   libtest-more-perl \
 +  
 +
 +SRC_URI = 
 http://cpan.metacpan.org/**authors/id/Z/ZE/ZEFRAM/Carp-${**PV}.tar.gzhttp://cpan.metacpan.org/authors/id/Z/ZE/ZEFRAM/Carp-$%7BPV%7D.tar.gz
 
 +SRC_URI[md5sum] = **86229a6f0dc44e0730f96c1909bb34**6d
 +SRC_URI[sha256sum] =
 **0a310222a9a52eca9425bca19e6d8e**04faa8bb4f64d5c16f2f6cce8190c0**a99b
 +
 +S = ${WORKDIR}/Carp-${PV}
 +
 +inherit cpan
 +
 +BBCLASSEXTEND = native
 +
 --
 1.8.4.rc3

 __**_
 Openembedded-devel mailing list
 Openembedded-devel@lists.**openembedded.orgOpenembedded-devel@lists.openembedded.org
 http://lists.openembedded.org/**mailman/listinfo/openembedded-**develhttp://lists.openembedded.org/mailman/listinfo/openembedded-devel

  __**_
 Openembedded-devel mailing list
 Openembedded-devel@lists.**openembedded.orgOpenembedded-devel@lists.openembedded.org
 http://lists.openembedded.org/**mailman/listinfo/openembedded-**develhttp://lists.openembedded.org/mailman/listinfo/openembedded-devel

 __**_
 Openembedded-devel mailing list
 Openembedded-devel@lists.**openembedded.orgOpenembedded-devel@lists.openembedded.org
 http://lists.openembedded.org/**mailman/listinfo/openembedded-**develhttp://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] [PATCH] libtest-harness-perl: added

[Olof Johansson]

Awesome, thanks for your efforts.


On 13-09-03 16:44 +0200, Emil Petersen wrote:
 +LICENSE = GPLv1+

This is actually artistic or GPLv1, just like in the other
recipes you posted.

LICENSE = Artistic-1.0 | GPL-1.0+

From Test::Harness POD:
 This module is free software; you can redistribute it and/or
 modify it under the same terms as Perl itself. See perlartistic.

Regards,
-- 
olofjn
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-perl] libtest-harness-perl_3.28: added

[Emil Petersen]

Added Test::Harness

Signed-off-by: Emil Petersen e...@movis.dk
---
 .../libtest-harness-perl_3.28.bb   | 53 +-
 1 file changed, 51 insertions(+), 2 deletions(-)

diff --git 
a/meta-perl/recipes-perl/libtest-harness-perl/libtest-harness-perl_3.28.bb 
b/meta-perl/recipes-perl/libtest-harness-perl/libtest-harness-perl_3.28.bb
index 881f5a6..62e6386 100644
--- a/meta-perl/recipes-perl/libtest-harness-perl/libtest-harness-perl_3.28.bb
+++ b/meta-perl/recipes-perl/libtest-harness-perl/libtest-harness-perl_3.28.bb
@@ -1,10 +1,59 @@
 SUMMARY = Test::Harness - Run Perl standard test scripts with statistics
 AUTHOR = Curis \Ovid\ Poe o...@cpan.org
 HOMEPAGE = https://metacpan.org/module/Test::Harness;
-SECTION = devtools
-LICENSE = GPLv1+
+SECTION = libs
+LICENSE = GPL-1.0+
 LIC_FILES_CHKSUM = file://README;md5=37947a7c4fbd4a63c41d1bfa385e0c1e
 
+RPROVIDES_${PN} = libapp-prove-perl \
+  libapp-prove-state-perl \
+  libapp-prove-state-result-perl \
+  libapp-prove-state-result-test-perl \
+  libtap-base-perl \
+  libtap-formatter-base-perl \
+  libtap-formatter-color-perl \
+  libtap-formatter-console-perl \
+  libtap-formatter-console-parallelsession-perl \  

+  libtap-formatter-console-session-perl \
+  libtap-formatter-file-perl \
+  libtap-formatter-file-session-perl \
+  libtap-formatter-session-perl \
+  libtap-harness-perl \
+  libtap-object-perl \
+  libtap-parser-perl \
+  libtap-parser-aggregator-perl \
+  libtap-parser-grammar-perl \
+  libtap-parser-iterator-perl \
+  libtap-parser-iterator-array-perl \
+  libtap-parser-iterator-process-perl \
+  libtap-parser-iterator-stream-perl \
+  libtap-parser-iteratorfactory-perl \
+  libtap-parser-multiplexer-perl \
+  libtap-parser-result-perl \
+  libtap-parsser-result-bailout-perl \
+  libtap-parser-result-comment-perl \
+  libtap-parser-result-plan-perl \
+  libtap-parser-result-pragma-perl \
+  libtap-parser-result-test-perl \
+  libtap-parser-result-unknown-perl \
+  libtap-parser-result-version-perl \
+  libtap-parser-result-yaml-perl \
+  libtap-parser-resultfactory-perl \
+  libtap-parser-scheduler-perl \
+  libtap-parser-scheduler-job-perl \
+  libtap-parser-scheduler-spinner-perl \
+  libtap-parser-source-perl \
+  libtap-parser-sourcehandler-perl \
+  libtap-parser-sourcehandler-executable-perl \
+  libtap-parser-sourcehandler-file-perl \
+  libtap-parser-sourcehandler-handle-perl \
+  libtap-parser-sourcehandler-perl-perl \
+  libtap-parser-sourcehandler-rawtap-perl \
+  libtap-parser-utils-perl \
+  libtap-parser-yamlish-reader-perl \
+  libtap-parser-yamlish-writer-perl \
+  
+  
 SRC_URI = 
http://cpan.metacpan.org/authors/id/O/OV/OVID/Test-Harness-${PV}.tar.gz;
 SRC_URI[md5sum] = e71faf73830f249e2eb569a52362c106
 SRC_URI[sha256sum] = 
209d538a7809935967c2c148a36c75a2959a3c3432e1d406288662632870a07c
-- 
1.8.4.rc3

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [PATCH] libcarp-perl: added

[Emil Petersen]

Carp recipe added

Signed-off-by: Emil Petersen e...@movis.dk
---
 .../recipes-perl/libcarp-perl/libcarp-perl_1.26.bb | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 meta-perl/recipes-perl/libcarp-perl/libcarp-perl_1.26.bb

diff --git a/meta-perl/recipes-perl/libcarp-perl/libcarp-perl_1.26.bb 
b/meta-perl/recipes-perl/libcarp-perl/libcarp-perl_1.26.bb
new file mode 100644
index 000..0ae7bf3
--- /dev/null
+++ b/meta-perl/recipes-perl/libcarp-perl/libcarp-perl_1.26.bb
@@ -0,0 +1,25 @@
+SUMMARY = Carp - alternative warn and die for modules
+AUTHOR = Andrew Main zef...@fysk.org
+HOMEPAGE = https://metacpan.org/module/Carp;
+SECTION = libs
+LICENSE = Artistic-1.0 | GPL-1.0+
+LIC_FILES_CHKSUM = file://README;md5=d613c00d4cb8d48c01f09fca2a7873a0
+
+RPROVIDES_${PN} = libcarp-heavy-perl
+
+RDEPENDS_${PN} += perl-module-strict \
+   perl-module-warnings \
+   libexporter-perl \
+   libtest-more-perl \
+  
+
+SRC_URI = http://cpan.metacpan.org/authors/id/Z/ZE/ZEFRAM/Carp-${PV}.tar.gz;
+SRC_URI[md5sum] = 86229a6f0dc44e0730f96c1909bb346d
+SRC_URI[sha256sum] = 
0a310222a9a52eca9425bca19e6d8e04faa8bb4f64d5c16f2f6cce8190c0a99b
+
+S = ${WORKDIR}/Carp-${PV}
+
+inherit cpan
+
+BBCLASSEXTEND = native
+
-- 
1.8.4.rc3

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH] libcarp-perl: added

[Laszlo Papp]

Hmm, shouldn't you mention in the commit message which version just in case?


On Tue, Sep 3, 2013 at 3:53 PM, Emil Petersen e...@movis.dk wrote:

 Carp recipe added

 Signed-off-by: Emil Petersen e...@movis.dk
 ---
  .../recipes-perl/libcarp-perl/libcarp-perl_1.26.bb | 25
 ++
  1 file changed, 25 insertions(+)
  create mode 100644 meta-perl/recipes-perl/libcarp-perl/
 libcarp-perl_1.26.bb

 diff --git 
 a/meta-perl/recipes-perl/libcarp-perl/libcarp-perl_1.26.bbb/meta-perl/recipes-perl/libcarp-perl/
 libcarp-perl_1.26.bb
 new file mode 100644
 index 000..0ae7bf3
 --- /dev/null
 +++ b/meta-perl/recipes-perl/libcarp-perl/libcarp-perl_1.26.bb
 @@ -0,0 +1,25 @@
 +SUMMARY = Carp - alternative warn and die for modules
 +AUTHOR = Andrew Main zef...@fysk.org
 +HOMEPAGE = https://metacpan.org/module/Carp;
 +SECTION = libs
 +LICENSE = Artistic-1.0 | GPL-1.0+
 +LIC_FILES_CHKSUM = file://README;md5=d613c00d4cb8d48c01f09fca2a7873a0
 +
 +RPROVIDES_${PN} = libcarp-heavy-perl
 +
 +RDEPENDS_${PN} += perl-module-strict \
 +   perl-module-warnings \
 +   libexporter-perl \
 +   libtest-more-perl \
 +  
 +
 +SRC_URI = 
 http://cpan.metacpan.org/authors/id/Z/ZE/ZEFRAM/Carp-${PV}.tar.gz;
 +SRC_URI[md5sum] = 86229a6f0dc44e0730f96c1909bb346d
 +SRC_URI[sha256sum] =
 0a310222a9a52eca9425bca19e6d8e04faa8bb4f64d5c16f2f6cce8190c0a99b
 +
 +S = ${WORKDIR}/Carp-${PV}
 +
 +inherit cpan
 +
 +BBCLASSEXTEND = native
 +
 --
 1.8.4.rc3

 ___
 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

[oe] OE Changelog since 2013-08-25 until 2013-09-01

[cliff . brake]

Changelog since 2013-08-25 until 2013-09-01.  Projects included in this report:

bitbake: git://git.openembedded.org/bitbake
openembedded-core: git://git.openembedded.org/openembedded-core
meta-openembedded: git://git.openembedded.org/meta-openembedded
meta-angstrom: git://github.com/Angstrom-distribution/meta-angstrom.git
meta-arago: git://arago-project.org/git/meta-arago.git
meta-beagleboard: git://github.com/beagleboard/meta-beagleboard.git
meta-browser: git://github.com/OSSystems/meta-browser.git
meta-bug: git://github.com/buglabs/meta-bug.git
meta-chicken: git://github.com/OSSystems/meta-chicken
meta-efikamx: git://github.com/kraj/meta-efikamx.git
meta-ettus: http://github.com/koenkooi/meta-ettus.git
meta-fsl-arm: git://git.yoctoproject.org/meta-fsl-arm
meta-fsl-arm-extra: git://github.com/Freescale/meta-fsl-arm-extra.git
meta-fsl-ppc: git://git.yoctoproject.org/meta-fsl-ppc
meta-guacamayo: git://github.com/Guacamayo/meta-guacamayo.git
meta-gumstix: git://github.com/gumstix/meta-gumstix.git
meta-gumstix-community: 
git://gitorious.org/schnitzeltony-oe-meta/meta-gumstix-community.git
meta-handheld: git://git.openembedded.org/meta-handheld
meta-igep: http://github.com/ebutera/meta-igep.git
meta-intel: git://git.yoctoproject.org/meta-intel
meta-ivi: git://git.yoctoproject.org/meta-ivi
meta-java: git://github.com/woglinde/meta-java
meta-kde: git://gitorious.org/openembedded-core-layers/meta-kde.git
meta-micro: git://git.openembedded.org/meta-micro
meta-mono: git://git.yoctoproject.org/meta-mono.git
meta-netbookpro: git://github.com/tworaz/meta-netbookpro
meta-nslu2: git://github.com/kraj/meta-nslu2
meta-opie: git://git.openembedded.org/meta-opie
meta-qt3: git://git.yoctoproject.org/meta-qt3
meta-qt5: git://github.com/meta-qt5/meta-qt5.git
meta-slugos: git://github.com/kraj/meta-slugos
meta-systemd: git://git.yoctoproject.org/meta-systemd
meta-raspberrypi: git://github.com/djwillis/meta-raspberrypi.git
meta-smartphone: http://git.shr-project.org/repo/meta-smartphone.git
meta-ti: git://git.yoctoproject.org/meta-ti
meta-webos: git://github.com/openwebos/meta-webos.git
meta-xilinx: git://git.yoctoproject.org/meta-xilinx
meta-yocto: git://git.yoctoproject.org/meta-yocto
openembedded: git://git.openembedded.org/openembedded


Changelog for bitbake:

Alexandru DAMIAN (1):
  server/xmlrpc: stop server on client exit

Christopher Larson (2):
  data_smart: use a split/filter/rejoin for _remove
  data_smart: allow removal of multiple words at once with _remove

Cristiana Voicu (3):
  bitbake/event.py: UIhandler filter should work without a mask
  hob: add event handlers filtering in Hob
  hob: fixes for image combo box

Jason Wessel (2):
  serv.py: Fix hang when spawned dynamically with bitbake
  serv.py: Fix regression from 972bc43e6d5b

Richard Purdie (17):
  process: Improve exit handling and hangs
  server/xmlrpc/prserv: Add sane timeout to default xmlrpc server
  bitbake: Add ui event handlers filtering
  data_smart: Add _remove operator
  command.py: Call updateCache for all states != running
  prserv/db: Threading fixes
  prserv/serv: Multithread the server
  cookerdata: Set TOPDIR when using bblayers.conf
  cookerdata: Allow bblayers.conf to be found using BBPATH
  server/xmlrpc: Increase timeout to 60s
  prserv: Allow 'table is locked' matching for retry loop
  server/process, server/xmlrpc, runqueue: Use select.select() on fds, not tim
  serv/db: Fix looping upon database locked issues
  serv/db: Take an excluside lock on the database
  serv/db: Don't use BEGIN/COMMIT
  build: Fix profile file names
  prserv/serv: Settle on two threads for optimal performance


Changelog for openembedded-core:

Alexandru Georgescu (1):
  lib/oeqa/runtime: add basic test for x32 images

Alexandru Palalau (4):
  lib/oeqa/runtime: add new logrotate test
  lib/oeqa/runtime: add new skeletoninit test
  lib/oeqa/runtime: add new PAM support test
  lib/oeqa/runtime: add new scp test

Andrea Adami (2):
  image_types.bbclass: use mkfs.cramfs instead of makecramfs
  util-linux: package mkfs.cramfs and fsck.cramfs

Bruce Ashfield (12):
  kern-tools: usability, bug fixes and no guilt
  guilt: update to latest git version
  linux-libc-headers: update to v3.10
  linux-libc-headers: ptrace.h: remove ptrace_peeksiginfo_args
  gst-plugins-good: fix 3.10 libc-headers build failure
  linux-yocto: introduce v3.10
  bc: add bc-native
  kern-tools: fix patch series to git tree validation
  linux-yocto: add bc-native dependency, and move to linux-yocto.inc
  linux-yocto-rt: add qemumips and qemuppc to COMPATIBLE_MACHINES
  linux-yocto/3.10: fix ssh login and restore CC_OPTIMIZE_FOR_SIZE
  linux-yocto/3.4: v3.4.59, mohonpeak

Chen Qi (6):
  checkroot.sh: check for conflicting configurations
  read-only-rootfs-hook.sh: check before bind mounting /var/lib
  busybox: configure system user id to range from 100 to 999
  runqemu-internal: don't 

[oe] [meta-perl] libtest-simple-perl_0.98.bb: added

[Emil Petersen]

Test::Simple recipe

Signed-off-by: Emil Petersen e...@movis.dk
---
 .../libtest-simple-perl_0.98.bb| 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 
meta-perl/recipes-perl/libtest-simple-perl/libtest-simple-perl_0.98.bb

diff --git 
a/meta-perl/recipes-perl/libtest-simple-perl/libtest-simple-perl_0.98.bb 
b/meta-perl/recipes-perl/libtest-simple-perl/libtest-simple-perl_0.98.bb
new file mode 100644
index 000..5e76181
--- /dev/null
+++ b/meta-perl/recipes-perl/libtest-simple-perl/libtest-simple-perl_0.98.bb
@@ -0,0 +1,25 @@
+SUMMARY = Test::Builder - Backend for building test libraries
+AUTHOR = Michael G. Schwern mschw...@cpan.org
+HOMEPAGE = https://metacpan.org/module/Test::Builder;
+SECTION = libs
+LICENSE = Artistic-1.0 | GPL-1.0+
+LIC_FILES_CHKSUM = file://README;md5=23e939b09e39c1a3069cf98c7f04500e
+
+RPROVIDES_${PN} += libtest-builder-perl \
+libbuilder-io-scalar-perl \
+libbuilder-module-perl \
+libtest-builder-tester-perl \
+libbuilder-tester-color-perl \
+libtest-more-perl \
+libtest-simple-perl \
+
+
+SRC_URI = 
http://cpan.metacpan.org/authors/id/M/MS/MSCHWERN/Test-Simple-${PV}.tar.gz;
+SRC_URI[md5sum] = a8b26c97440269b33dd79fd847c521d8
+SRC_URI[sha256sum] = 
2fb203e2cb75e72c6f70af71c6b01998f2c0ec2afba6c38cc5053c6107cd12a8
+
+S = ${WORKDIR}/Test-Simple-${PV}
+
+inherit cpan
+
+BBCLASSEXTEND = native
-- 
1.8.4.rc3

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [PATCH] libtest-harness-perl: added

[Emil Petersen]

Added Test::Harness recipe

Signed-off-by: Emil Petersen e...@movis.dk
---
 .../libtest-harness-perl/libtest-harness-perl_3.28.bb  | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 
meta-perl/recipes-perl/libtest-harness-perl/libtest-harness-perl_3.28.bb

diff --git 
a/meta-perl/recipes-perl/libtest-harness-perl/libtest-harness-perl_3.28.bb 
b/meta-perl/recipes-perl/libtest-harness-perl/libtest-harness-perl_3.28.bb
new file mode 100644
index 000..881f5a6
--- /dev/null
+++ b/meta-perl/recipes-perl/libtest-harness-perl/libtest-harness-perl_3.28.bb
@@ -0,0 +1,18 @@
+SUMMARY = Test::Harness - Run Perl standard test scripts with statistics
+AUTHOR = Curis \Ovid\ Poe o...@cpan.org
+HOMEPAGE = https://metacpan.org/module/Test::Harness;
+SECTION = devtools
+LICENSE = GPLv1+
+LIC_FILES_CHKSUM = file://README;md5=37947a7c4fbd4a63c41d1bfa385e0c1e
+
+SRC_URI = 
http://cpan.metacpan.org/authors/id/O/OV/OVID/Test-Harness-${PV}.tar.gz;
+SRC_URI[md5sum] = e71faf73830f249e2eb569a52362c106
+SRC_URI[sha256sum] = 
209d538a7809935967c2c148a36c75a2959a3c3432e1d406288662632870a07c
+
+S = ${WORKDIR}/Test-Harness-${PV}/
+
+inherit cpan
+
+BBCLASSEXTEND = native
+
+
-- 
1.8.4.rc3

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH] libtest-harness-perl: added

[Olof Johansson]

On 13-09-03 17:09 +0200, Olof Johansson wrote:
 Awesome, thanks for your efforts.
 
 
 On 13-09-03 16:44 +0200, Emil Petersen wrote:
  +LICENSE = GPLv1+
 
 This is actually artistic or GPLv1, just like in the other
 recipes you posted.
 
 LICENSE = Artistic-1.0 | GPL-1.0+
 
 From Test::Harness POD:
  This module is free software; you can redistribute it and/or
  modify it under the same terms as Perl itself. See perlartistic.


This is a core module as well come to think of it. Very core :).

-- 
olofjn
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-perl][PATCH] libhtml-parser-perl_3.71.bb: added

[Emil Petersen]

HTML::Parser and RPROVIDES added

Signed-off-by: Emil Petersen e...@movis.dk
---
 .../libhtml-parser-perl_3.71.bb| 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 
meta-perl/recipes-perl/libhtml-parser-perl/libhtml-parser-perl_3.71.bb

diff --git 
a/meta-perl/recipes-perl/libhtml-parser-perl/libhtml-parser-perl_3.71.bb 
b/meta-perl/recipes-perl/libhtml-parser-perl/libhtml-parser-perl_3.71.bb
new file mode 100644
index 000..ad8c57a
--- /dev/null
+++ b/meta-perl/recipes-perl/libhtml-parser-perl/libhtml-parser-perl_3.71.bb
@@ -0,0 +1,29 @@
+SUMARRY = This package contains the Parser.pm module with friends.
+AUTHOR = Gisle Aas gi...@activestate.com
+HOMEPAGE = https://metacpan.org/release/HTML-Parser;
+SECTION = libs
+LICENSE = Artistic-1.0 | GPL-1.0+
+LIC_FILES_CHKSUM = file://README;md5=6c3dacf9f405c7483870ab5f148770c3
+
+SRC_URI = 
http://search.cpan.org/CPAN/authors/id/G/GA/GAAS/HTML-Parser-${PV}.tar.gz;
+SRC_URI[md5sum] = 9128a45893097dfa3bf03301b19c5efe
+SRC_URI[sha256sum] = 
be918b3749d3ff93627f72ee4b825683332ecb4c81c67a3a8d72b0435ffbd802
+
+RDEPENDS_${PN} += 'libhtml-tagset-perl libxsloader-perl'
+
+RPROVIDES_${PN} += libhtml-entities-perl \
+libhtml-filter-perl \
+libhtml-headparser-perl \
+libhtml-linkextor-perl \
+libhtml-parser-perl \
+libhtml-pullparser-perl \
+libhtml-tokeparser-perl \
+
+
+S = ${WORKDIR}/HTML-Parser-${PV}
+
+EXTRA_CPANFLAGS = EXPATLIBPATH=${STAGING_LIBDIR} 
EXPATINCPATH=${STAGING_INCDIR}
+
+inherit cpan
+
+BBCLASSEXTEND = native
-- 
1.8.4.rc3

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-perl] libwww-perl_5.834: added

[Olof Johansson]

On 13-09-03 17:48 +0200, Emil R. Petersen wrote:
 Oh? Well I wouldn't have added them if I thought they were core modules.
 
 MIME::Base64 has it's own CPAN entry: 
 https://metacpan.org/release/MIME-Base64

Many of the core modules have a dual life, both in core and on
CPAN.

 And does not appear, immediately, to be part of the core distribution?

There's a command called corelist that is really useful to
determine if a module is core or not. Not only does it say if its
core or not, but also what perl version introduced it as a core
module.

$ corelist MIME::Base64

MIME::Base64 was first released with perl v5.7.3


Regards,
-- 
olofjn
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-perl][PATCH] libencode-perl_2.52: added

[Olof Johansson]

On 13-09-03 17:39 +0200, Emil Petersen wrote:
 Encode recipe added

This module is part of the perl distribution itself.

-- 
olofjn
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-perl] libwww-perl_5.834: added

[Olof Johansson]

On 13-09-03 17:33 +0200, Emil Petersen wrote:
 +RDEPENDS_${PN} += libdigest-md5-perl \
 +   libencode-perl \
 +   libio-select-perl \
 +   libio-socket-perl \
 +   libmime-base64-perl \
 +   libnet-ftp-perl \
 +   

I notice that some of these modules are core modules
(specifically the ones left in the quote), and I guess it would
be better to depend on the perl-modules package instead (the
package containing all core modules)? Otherwise this may require
a great deal of maintenance when upgrading to newer releases.

-- 
olofjn
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-perl][PATCH] libfile-listing-perl_6.04: added

[Emil Petersen]

File::Listing added

Signed-off-by: Emil Petersen e...@movis.dk
---
 .../libfile-listing-perl_6.04.bb   | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 
meta-perl/recipes-perl/libfile-listing-perl/libfile-listing-perl_6.04.bb

diff --git 
a/meta-perl/recipes-perl/libfile-listing-perl/libfile-listing-perl_6.04.bb 
b/meta-perl/recipes-perl/libfile-listing-perl/libfile-listing-perl_6.04.bb
new file mode 100644
index 000..991de44
--- /dev/null
+++ b/meta-perl/recipes-perl/libfile-listing-perl/libfile-listing-perl_6.04.bb
@@ -0,0 +1,26 @@
+SUMMARY = File::Listing - parse directory listing
+AUTHOR = Gisle Aas gi...@activestate.com
+HOMEPAGE = https://metacpan.org/module/File::Listing;
+SECTION = libs
+LICENSE = Artistic-1.0 | GPL-1.0+
+LIC_FILES_CHKSUM = file://README;md5=b797097ead2abb910a9b40c0393742c3
+
+SRC_URI = 
http://cpan.metacpan.org/authors/id/G/GA/GAAS/File-Listing-${PV}.tar.gz;
+SRC_URI[md5sum] = 83f636b477741f3a014585bb9cc079a6
+SRC_URI[sha256sum] = 
1e0050fcd6789a2179ec0db282bf1e90fb92be35d1171588bd9c47d52d959cf5
+
+RDEPENDS_${PN} += 'libhttp-date-perl'
+
+RPROVIDES_${PN} += libfile-listing-perl \
+libfile-listing-apache-perl \
+libfile-listing-dosftp-perl \
+libfile-listing-netware-perl \
+libfile-listing-unix-perl \
+libfile-listing-vms-perl \
+
+
+S = ${WORKDIR}/File-Listing-${PV}
+
+inherit cpan
+
+BBCLASSEXTEND = native
-- 
1.8.4.rc3

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-perl] libwww-perl_5.834: added

[Emil R. Petersen]

Oh? Well I wouldn't have added them if I thought they were core modules.

MIME::Base64 has it's own CPAN entry: 
https://metacpan.org/release/MIME-Base64


And does not appear, immediately, to be part of the core distribution?

Or am I missing something?

On 03/09/13 17:44, Olof Johansson wrote:

On 13-09-03 17:33 +0200, Emil Petersen wrote:

+RDEPENDS_${PN} += libdigest-md5-perl \
+   libencode-perl \
+   libio-select-perl \
+   libio-socket-perl \
+   libmime-base64-perl \
+   libnet-ftp-perl \
+   

I notice that some of these modules are core modules
(specifically the ones left in the quote), and I guess it would
be better to depend on the perl-modules package instead (the
package containing all core modules)? Otherwise this may require
a great deal of maintenance when upgrading to newer releases.


___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-perl] libwww-perl_5.834: added

[Emil R. Petersen]

Hmm alright, I will do this from now. And my other patch was send in 
before your reply reached me.


On 03/09/13 17:54, Olof Johansson wrote:

On 13-09-03 17:48 +0200, Emil R. Petersen wrote:

Oh? Well I wouldn't have added them if I thought they were core modules.

MIME::Base64 has it's own CPAN entry:
https://metacpan.org/release/MIME-Base64

Many of the core modules have a dual life, both in core and on
CPAN.


And does not appear, immediately, to be part of the core distribution?

There's a command called corelist that is really useful to
determine if a module is core or not. Not only does it say if its
core or not, but also what perl version introduced it as a core
module.

$ corelist MIME::Base64

MIME::Base64 was first released with perl v5.7.3


Regards,

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-perl] libwww-perl_5.834: added

[Emil Petersen]

libwww which provides most of LWP::* added

Signed-off-by: Emil Petersen e...@movis.dk
---
 .../recipes-perl/libwww-perl/libwww-perl_5.834.bb  | 68 ++
 1 file changed, 68 insertions(+)
 create mode 100644 meta-perl/recipes-perl/libwww-perl/libwww-perl_5.834.bb

diff --git a/meta-perl/recipes-perl/libwww-perl/libwww-perl_5.834.bb 
b/meta-perl/recipes-perl/libwww-perl/libwww-perl_5.834.bb
new file mode 100644
index 000..f1a77d5
--- /dev/null
+++ b/meta-perl/recipes-perl/libwww-perl/libwww-perl_5.834.bb
@@ -0,0 +1,68 @@
+SUMMARY = libwww-perl provides a simple and consistent API to the World Wide 
Web
+AUTHOR = Gisle Aas gi...@activestate.com
+HOMEPAGE = https://metacpan.org/release/libwww-perl;
+SECTION = libs
+LICENSE = Artistic-1.0 | GPL-1.0+
+LIC_FILES_CHKSUM = file://README;md5=b7d978c7767cb9fb392f80103af8ca0a
+
+RDEPENDS_${PN} += libdigest-md5-perl \
+   libencode-perl \
+   libencode-locale-perl \
+   libfile-listing-perl \
+   libhtml-entities-perl \
+   libhtml-headparser-perl \
+   libhttp-date-perl \
+   libhttp-cookies-perl \
+   libhttp-daemon-perl \
+   libhttp-negotiate-perl \
+   libhttp-request-perl \
+   libhttp-request-common-perl \
+   libhttp-response-perl \
+   libhttp-status-perl \
+   libio-select-perl \
+   libio-socket-perl \
+   liblwp-mediatypes-perl \
+   libmime-base64-perl \
+   libnet-ftp-perl \
+   libnet-http-perl \
+   liburi-perl \
+   liburi-escape-perl \
+   libwww-robotrules-perl \
+   
+
+RPROVIDES_${PN} += liblwp-perl \
+liblwp-authen-ntlm-perl \
+liblwp-conncache-perl \
+liblwp-debug-perl \
+liblwp-membermixin-perl \
+liblwp-protocol-perl \
+liblwp-robotua-perl \
+liblwp-simple-perl \
+liblwp-useragent-perl \
+liblwp-authen-basic-perl \
+liblwp-authen-digest-perl \
+liblwp-protocol-cpan-perl \
+liblwp-protocol-data-perl \
+liblwp-protocol-file-perl \
+liblwp-protocol-ftp-perl \
+liblwp-protocol-ghttp-perl \
+liblwp-protocol-gopher-perl \
+liblwp-protocol-http-perl \
+liblwp-protocol-http-socket-perl \
+liblwp-protocol-http-socketmethods-perl \  
  
+liblwp-protocol-loopback-perl \
+liblwp-protocol-mailto-perl \
+liblwp-protocol-myftp-perl \
+liblwp-protocol-nntp-perl \
+liblwp-protocol-nogo-perl \
+
+
+SRC_URI = 
http://search.cpan.org/CPAN/authors/id/G/GA/GAAS/libwww-perl-${PV}.tar.gz;name=libwww-perl-${PV};
+SRC_URI[libwww-perl-5.834.md5sum] = f2ed8a461f76556c9caed9087f47c86c
+SRC_URI[libwww-perl-5.834.sha256sum] = 
1a50eb91d1deeca3be10982e129e786809ad6f0f8049b156e91e889e5a7288ff
+
+S = ${WORKDIR}/libwww-perl-${PV}
+
+inherit cpan
+
+BBCLASSEXTEND = native
-- 
1.8.4.rc3

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-perl][PATCH] libencode-locale-perl_1.03: added

[Emil Petersen]

Encode::Locale added

Signed-off-by: Emil Petersen e...@movis.dk
---
 .../libencode-locale-perl_1.03.bb| 20 
 1 file changed, 20 insertions(+)
 create mode 100644 
meta-perl/recipes-perl/libencode-locale-perl/libencode-locale-perl_1.03.bb

diff --git 
a/meta-perl/recipes-perl/libencode-locale-perl/libencode-locale-perl_1.03.bb 
b/meta-perl/recipes-perl/libencode-locale-perl/libencode-locale-perl_1.03.bb
new file mode 100644
index 000..1919488
--- /dev/null
+++ b/meta-perl/recipes-perl/libencode-locale-perl/libencode-locale-perl_1.03.bb
@@ -0,0 +1,20 @@
+SUMMARY = Encode::Locale - Determine the locale encoding
+AUTHOR = Gisle Aas gi...@activestate.com
+HOMEPAGE = https://metacpan.org/module/Encode::Locale;
+SECTION = libs
+LICENSE = Artistic-1.0 | GPL-1.0+
+LIC_FILES_CHKSUM = file://README;md5=14e8006c2134045725fd81292a323d24
+
+RDEPENDS_${PN} = libencode-perl \
+ libencode-alias-perl \
+ 
+
+SRC_URI = 
http://cpan.metacpan.org/authors/id/G/GA/GAAS/Encode-Locale-${PV}.tar.gz;
+SRC_URI[md5sum] = de8422d068634e7c1068dab4e18b452f
+SRC_URI[sha256sum] = 
f76337e0933225914111fcc3319ff4db359b1abfd1aa56dff2df5378db0e2d55
+
+S = ${WORKDIR}/Encode-Locale-${PV}
+
+inherit cpan
+
+BBCLASSEXTEND = native
-- 
1.8.4.rc3

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-filesystems][PATCH] cramfs: remove, we use mkfs.cramfs from util-linux

[Andrea Adami]

On Fri, Aug 30, 2013 at 1:39 AM, Andrea Adami andrea.ad...@gmail.com wrote:
 Signed-off-by: Andrea Adami andrea.ad...@gmail.com
 ---
  .../recipes-filesystems/cramfs/cramfs_1.1.bb   | 29 
 --
  1 file changed, 29 deletions(-)
  delete mode 100644 meta-filesystems/recipes-filesystems/cramfs/cramfs_1.1.bb

 diff --git a/meta-filesystems/recipes-filesystems/cramfs/cramfs_1.1.bb 
 b/meta-filesystems/recipes-filesystems/cramfs/cramfs_1.1.bb
 deleted file mode 100644
 index 0bca0e1..000
 --- a/meta-filesystems/recipes-filesystems/cramfs/cramfs_1.1.bb
 +++ /dev/null
 @@ -1,29 +0,0 @@
 -DESCRIPTION = Builds cramfs filesystems for embedded systems
 -LICENSE = GPLv2
 -LIC_FILES_CHKSUM = file://COPYING;md5=393a5ca445f6965873eca0259a17f833
 -DEPENDS = zlib
 -
 -PE = 1
 -
 -SRC_URI = 
 http://sourceforge.net/projects/cramfs/files/cramfs/1.1/${BPN}-${PV}.tar.gz;
 -
 -SRC_URI[md5sum] = d3912b9f7bf745fbfea68f6a9b9de30f
 -SRC_URI[sha256sum] = 
 133caca2c4e7c64106555154ee0ff693f5cf5beb9421ce2eb86baee997d22368
 -
 -EXTRA_OEMAKE = \
 -'CC=${CC}' \
 -'CFLAGS=${CFLAGS}' \
 -'LDFLAGS=${LDFLAGS}' \
 -
 -
 -do_compile_prepend() {
 -ln -sf GNUmakefile Makefile
 -}
 -
 -do_install() {
 -install -d ${D}${bindir}
 -install mkcramfs ${D}${bindir}
 -install cramfsck ${D}${bindir}
 -}
 -
 -BBCLASSEXTEND = native
 --
 1.8.1.5


PING

mkfs.cramfs is now packaged by util-linux in oe-core and the
necessaries changes to image_types.bbclass committed as well.

BTW, who is the layer maintainer ?
Please add it clearly to the README, thx.

Cheers

Andrea
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-perl][PATCH] libencode-perl_2.52: added

[Emil Petersen]

Encode recipe added

Signed-off-by: Emil Petersen e...@movis.dk
---
 .../libencode-perl/libencode-perl_2.52.bb  | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 meta-perl/recipes-perl/libencode-perl/libencode-perl_2.52.bb

diff --git a/meta-perl/recipes-perl/libencode-perl/libencode-perl_2.52.bb 
b/meta-perl/recipes-perl/libencode-perl/libencode-perl_2.52.bb
new file mode 100644
index 000..b2e261a
--- /dev/null
+++ b/meta-perl/recipes-perl/libencode-perl/libencode-perl_2.52.bb
@@ -0,0 +1,49 @@
+SUMMARY = Encode - character encodings
+DESCRIPTION = The \Encode\ module provides the interfaces between Perl's 
strings and the rest of the system.  Perl strings are \
+   sequences of characters. \ 
+   See \perldoc Encode\ for the rest of the story
+AUTHOR = Dan Kogai dankogai+c...@gmail.com
+HOMEPAGE = https://metacpan.org/release/Encode;
+SECTION = lib
+LICENSE = Artistic-1.0 | GPL-1.0+
+LIC_FILES_CHKSUM = file://META.json;md5=f335275cdfe14e39d59aee6a883b78cd
+
+RPROVIDES_${PN} += libencode-perl \
+libencode-alias-perl \
+libencode-byte-perl \
+libencode-cjkconstants-perl \
+libencode-cn-perl \
+libencode-cn-hz-perl \
+libencode-config-perl \
+libencode-ebcdic-perl \
+libencode-encoder-perl \
+libencode-encoding-perl \
+libencode-gsm0338-perl \
+libencode-guess-perl \
+libencode-jp-perl \
+libencode-jp-h2z-perl \
+libencode-jp-jis7-perl \
+libencode-kr-perl \
+libencode-kr-2022_kr-perl \
+libencode-mime-header-perl \
+libencode-mime-name-perl \
+libencode-symbol-perl \
+libencode-tw-perl \
+libencode-unicode--perl \
+libencode-unicode-utf7-perl \
+libencoding-perl \
+libencode-internal-perl \
+libencode-mime-header-iso_2022_jp-perl \
+libencode-utf8-perl \
+libencode-utf_ebcdic-perl \
+
+ 
+SRC_URI = 
http://cpan.metacpan.org/authors/id/D/DA/DANKOGAI/Encode-${PV}.tar.gz;
+SRC_URI[md5sum] = bf26ef62725b1938181d71d1127f22d8
+SRC_URI[sha256sum] = 
2411a2027195b684065339abb1286dd540ca3ca32d546bd682c4964579ad3c60
+
+S = ${WORKDIR}/Encode-${PV}
+
+inherit cpan
+
+BBCLASSEXTEND = native
-- 
1.8.4.rc3

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-perl][PATCH] libdigest-md5-perl_2.53: added

[Emil Petersen]

Signed-off-by: Emil Petersen e...@movis.dk
---
 .../libdigest-md5-perl/libdigest-md5-perl_2.53.bb  | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 
meta-perl/recipes-perl/libdigest-md5-perl/libdigest-md5-perl_2.53.bb

diff --git 
a/meta-perl/recipes-perl/libdigest-md5-perl/libdigest-md5-perl_2.53.bb 
b/meta-perl/recipes-perl/libdigest-md5-perl/libdigest-md5-perl_2.53.bb
new file mode 100644
index 000..bbbaf2d
--- /dev/null
+++ b/meta-perl/recipes-perl/libdigest-md5-perl/libdigest-md5-perl_2.53.bb
@@ -0,0 +1,18 @@
+SUMMARY = Digest::MD5 - Perl interface to the MD5 Algorithm
+AUTHOR = Gisle Aas gi...@activestate.com
+HOMEPAGE = https://metacpan.org/module/Digest::MD5;
+SECTION = libs
+LICENSE = Artistic-1.0 | GPL-1.0+
+LIC_FILES_CHKSUM = file://README;md5=2f93400875dbb56f36691d5f69f3eba5
+
+RDEPENDS_${PN} = libdigest-base-perl
+
+SRC_URI = 
http://cpan.metacpan.org/authors/id/G/GA/GAAS/Digest-MD5-${PV}.tar.gz;
+SRC_URI[md5sum] = affc629d05c4c7b3efe4b3b874bce528
+SRC_URI[sha256sum] = 
cde667c0c0c8a4d819d332ba9a4cad7e9f75fc7cabd490aae405ce7bc54d5152
+
+S = ${WORKDIR}/Digest-MD5-${PV}
+
+inherit cpan
+
+BBCLASSEXTEND = native
-- 
1.8.4.rc3

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH] omgps: add libcap dependency

[Martin Jansa]

On Fri, Aug 23, 2013 at 05:41:52PM +0300, Eren Türkay wrote:
 http://lists.openembedded.org/pipermail/openembedded-core/2013-August/082530.html
 
 Omgps links against libcap without checking the library. If it cannot
 find it as in the minimal build, it emits an error in the linking stage.
 Add the dependency explicitly.

Applied, thanks!

 
 Signed-off-by: Eren Türkay e...@hambedded.org
 ---
  meta-oe/recipes-navigation/omgps/omgps_svn.bb |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/meta-oe/recipes-navigation/omgps/omgps_svn.bb 
 b/meta-oe/recipes-navigation/omgps/omgps_svn.bb
 index 1a79df4..625377d 100644
 --- a/meta-oe/recipes-navigation/omgps/omgps_svn.bb
 +++ b/meta-oe/recipes-navigation/omgps/omgps_svn.bb
 @@ -3,7 +3,7 @@ HOMEPAGE = http://omgps.googlecode.com;
  SECTION = openmoko/applications
  LICENSE = GPLv2
  LIC_FILES_CHKSUM = file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552
 -DEPENDS = gtk+ python-pygobject dbus-glib
 +DEPENDS = gtk+ python-pygobject dbus-glib libcap
  SRCREV = 109
  PV = 0.1+svnr${SRCPV}
  PR = r2
 -- 
 1.7.9.5
 
 ___
 Openembedded-devel mailing list
 Openembedded-devel@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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


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-oe][PATCH] xf86-video-nouveau: new recipe

[Martin Jansa]

On Fri, Aug 23, 2013 at 11:38:44PM +1000, Jonathan Liu wrote:
 Signed-off-by: Jonathan Liu net...@gmail.com

Both xf86-video applied, thanks!

 ---
  .../xorg-driver/xf86-video-nouveau_1.0.9.bb  | 16 
 
  1 file changed, 16 insertions(+)
  create mode 100644 
 meta-oe/recipes-graphics/xorg-driver/xf86-video-nouveau_1.0.9.bb
 
 diff --git a/meta-oe/recipes-graphics/xorg-driver/xf86-video-nouveau_1.0.9.bb 
 b/meta-oe/recipes-graphics/xorg-driver/xf86-video-nouveau_1.0.9.bb
 new file mode 100644
 index 000..7b52de0
 --- /dev/null
 +++ b/meta-oe/recipes-graphics/xorg-driver/xf86-video-nouveau_1.0.9.bb
 @@ -0,0 +1,16 @@
 +require recipes-graphics/xorg-driver/xorg-driver-video.inc
 +
 +LIC_FILES_CHKSUM = file://COPYING;md5=4641deddaa80fe7ca88e944e1fd94a94
 +
 +SUMMARY = X.Org X server -- nouveau video driver
 +
 +DESCRIPTION = Open-source X.org graphics driver for NVIDIA graphics
 +
 +DEPENDS += virtual/libx11 libxvmc drm xf86driproto glproto \
 +virtual/libgl xineramaproto libpciaccess
 +RDEPENDS_${PN} += xserver-xorg-module-exa
 +
 +COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
 +
 +SRC_URI[md5sum] = 8b2c0df5de3929597ade8c5ddb489a44
 +SRC_URI[sha256sum] = 
 b247c800e532fad1c80a5666d8ca0d4e5712064b6d7a3b030b32206a8de04482
 -- 
 1.8.3.4
 
 ___
 Openembedded-devel mailing list
 Openembedded-devel@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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


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-oe][PATCH 1/1] busybox: remove bbappend

[Martin Jansa]

On Fri, Aug 23, 2013 at 12:33:37PM +0100, Paul Eggleton wrote:
 This bbappend has effectively been merged into OE-Core, although the
 log buffer size is the busybox default rather than 64K - layers may
 change this either by providing their own /etc/default/busybox-syslog
 file (when using systemd) or modifying the
 CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE option in busybox's build time
 config.

Applied, thanks!

 
 Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com
 ---
  meta-oe/recipes-core/busybox/busybox/busybox-syslog.default |  1 -
  meta-oe/recipes-core/busybox/busybox_1.21.1.bbappend| 11 ---
  2 files changed, 12 deletions(-)
  delete mode 100644 
 meta-oe/recipes-core/busybox/busybox/busybox-syslog.default
  delete mode 100644 meta-oe/recipes-core/busybox/busybox_1.21.1.bbappend
 
 diff --git a/meta-oe/recipes-core/busybox/busybox/busybox-syslog.default 
 b/meta-oe/recipes-core/busybox/busybox/busybox-syslog.default
 deleted file mode 100644
 index 8a21e6d..000
 --- a/meta-oe/recipes-core/busybox/busybox/busybox-syslog.default
 +++ /dev/null
 @@ -1 +0,0 @@
 -OPTIONS=-C64
 diff --git a/meta-oe/recipes-core/busybox/busybox_1.21.1.bbappend 
 b/meta-oe/recipes-core/busybox/busybox_1.21.1.bbappend
 deleted file mode 100644
 index 7a2f0c3..000
 --- a/meta-oe/recipes-core/busybox/busybox_1.21.1.bbappend
 +++ /dev/null
 @@ -1,11 +0,0 @@
 -# look for files in the layer first
 -FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
 -
 -SRC_URI += file://busybox-syslog.default
 -
 -do_install_append() {
 -install -d ${D}${sysconfdir}/default
 -install -m 0644 ${WORKDIR}/busybox-syslog.default 
 ${D}${sysconfdir}/default/busybox-syslog
 -}
 -
 -FILES_${PN}-syslog += ${sysconfdir}/default/busybox-syslog
 -- 
 1.8.1.2
 
 ___
 Openembedded-devel mailing list
 Openembedded-devel@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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


signature.asc
Description: Digital signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [toolchain-layer][PATCH] gcc-4.6: Update to match gcc restructing in OE-Core

[Martin Jansa]

On Tue, Aug 27, 2013 at 11:34:10PM -0700, Khem Raj wrote:
 The include file infra in gcc recipes recieved an overhaul
 on OE-Core. This patch matches the toolchain layer recipes
 to use the new include files

Applied, thanks!

 
 Signed-off-by: Khem Raj raj.k...@gmail.com
 ---
  .../recipes-devtools/gcc/gcc-cross-canadian_4.6.bb| 19 
 ---
  toolchain-layer/recipes-devtools/gcc/gcc-cross_4.6.bb |  8 +---
  .../recipes-devtools/gcc/gcc-runtime_4.6.bb   |  8 +---
  toolchain-layer/recipes-devtools/gcc/gcc_4.6.bb   |  5 +
  4 files changed, 3 insertions(+), 37 deletions(-)
 
 diff --git a/toolchain-layer/recipes-devtools/gcc/gcc-cross-canadian_4.6.bb 
 b/toolchain-layer/recipes-devtools/gcc/gcc-cross-canadian_4.6.bb
 index 5c2435f..29ddd67 100644
 --- a/toolchain-layer/recipes-devtools/gcc/gcc-cross-canadian_4.6.bb
 +++ b/toolchain-layer/recipes-devtools/gcc/gcc-cross-canadian_4.6.bb
 @@ -2,22 +2,3 @@ inherit cross-canadian
  
  require recipes-devtools/gcc/gcc-${PV}.inc
  require recipes-devtools/gcc/gcc-cross-canadian.inc
 -require recipes-devtools/gcc/gcc-configure-sdk.inc
 -require recipes-devtools/gcc/gcc-package-sdk.inc
 -
 -DEPENDS += nativesdk-gmp nativesdk-mpfr nativesdk-libmpc nativesdk-elfutils
 -RDEPENDS_${PN} += nativesdk-mpfr nativesdk-libmpc nativesdk-elfutils
 -
 -SYSTEMHEADERS = /usr/include
 -SYSTEMLIBS = /lib/
 -SYSTEMLIBS1 = /usr/lib/
 -
 -EXTRA_OECONF += --disable-libunwind-exceptions --disable-libssp \
 ---disable-libgomp --disable-libmudflap \
 ---with-mpfr=${STAGING_DIR_HOST}${layout_exec_prefix} \
 ---with-mpc=${STAGING_DIR_HOST}${layout_exec_prefix}
 -
 -# to find libmpfr
 -# export LD_LIBRARY_PATH = {STAGING_DIR_HOST}${layout_exec_prefix}
 -
 -PARALLEL_MAKE = 
 diff --git a/toolchain-layer/recipes-devtools/gcc/gcc-cross_4.6.bb 
 b/toolchain-layer/recipes-devtools/gcc/gcc-cross_4.6.bb
 index eb8896c..cdaa7e8 100644
 --- a/toolchain-layer/recipes-devtools/gcc/gcc-cross_4.6.bb
 +++ b/toolchain-layer/recipes-devtools/gcc/gcc-cross_4.6.bb
 @@ -1,8 +1,2 @@
  require recipes-devtools/gcc/gcc-${PV}.inc
 -require recipes-devtools/gcc/gcc-cross4.inc
 -
 -EXTRA_OECONF += --disable-libunwind-exceptions \
 - --with-mpfr=${STAGING_DIR_NATIVE}${prefix_native} \
 - --with-system-zlib 
 -
 -ARCH_FLAGS_FOR_TARGET += -isystem${STAGING_DIR_TARGET}${target_includedir}
 +require recipes-devtools/gcc/gcc-cross.inc
 diff --git a/toolchain-layer/recipes-devtools/gcc/gcc-runtime_4.6.bb 
 b/toolchain-layer/recipes-devtools/gcc/gcc-runtime_4.6.bb
 index 13431c8..b755f55 100644
 --- a/toolchain-layer/recipes-devtools/gcc/gcc-runtime_4.6.bb
 +++ b/toolchain-layer/recipes-devtools/gcc/gcc-runtime_4.6.bb
 @@ -1,8 +1,2 @@
  require recipes-devtools/gcc/gcc-${PV}.inc
 -require recipes-devtools/gcc/gcc-configure-runtime.inc
 -require recipes-devtools/gcc/gcc-package-runtime.inc
 -
 -ARCH_FLAGS_FOR_TARGET += -isystem${STAGING_INCDIR}
 -
 -EXTRA_OECONF += --disable-libunwind-exceptions
 -EXTRA_OECONF_append_linuxstdbase =  --enable-clocale=gnu
 +require recipes-devtools/gcc/gcc-runtime.inc
 diff --git a/toolchain-layer/recipes-devtools/gcc/gcc_4.6.bb 
 b/toolchain-layer/recipes-devtools/gcc/gcc_4.6.bb
 index 97e6c32..6ad8973 100644
 --- a/toolchain-layer/recipes-devtools/gcc/gcc_4.6.bb
 +++ b/toolchain-layer/recipes-devtools/gcc/gcc_4.6.bb
 @@ -1,5 +1,2 @@
  require recipes-devtools/gcc/gcc-${PV}.inc
 -require recipes-devtools/gcc/gcc-configure-target.inc
 -require recipes-devtools/gcc/gcc-package-target.inc
 -
 -ARCH_FLAGS_FOR_TARGET += -isystem${STAGING_INCDIR}
 +require recipes-devtools/gcc/gcc-target.inc
 -- 
 1.8.4
 
 ___
 Openembedded-devel mailing list
 Openembedded-devel@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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


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-oe][PATCH] mpg123: add PACKAGECONFIG for pulseaudio and alsa

[Martin Jansa]

On Fri, Aug 23, 2013 at 05:18:03PM +0300, Eren Türkay wrote:
 The default DISTRO_FEATURES include alsa and pulseaudio at the same
 time. Hence, both of the options are enabled in mpg123 configuration
 without adding related dependencies, which causes build error.
 
 Make the options mutually exclusive through PACKAGECONFIG.  If both alsa
 and pulseaudio are specified, pulseaudio takes precedence.

Applied, thanks!

 
 Signed-off-by: Eren Türkay e...@hambedded.org
 ---
  .../recipes-multimedia/mpg123/mpg123_1.15.3.bb |   10 --
  1 file changed, 8 insertions(+), 2 deletions(-)
 
 diff --git a/meta-multimedia/recipes-multimedia/mpg123/mpg123_1.15.3.bb 
 b/meta-multimedia/recipes-multimedia/mpg123/mpg123_1.15.3.bb
 index 595235c..0075427 100644
 --- a/meta-multimedia/recipes-multimedia/mpg123/mpg123_1.15.3.bb
 +++ b/meta-multimedia/recipes-multimedia/mpg123/mpg123_1.15.3.bb
 @@ -6,6 +6,14 @@ HOMEPAGE = http://mpg123.de/;
  BUGTRACKER = http://sourceforge.net/p/mpg123/bugs/;
  SECTION = multimedia
  
 +# The options should be mutually exclusive for configuration script.
 +# If both alsa and pulseaudio are specified (as in the default distro 
 features)
 +# pulseaudio takes precedence.
 +PACKAGECONFIG_ALSA = ${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', 
 '', d)}
 +PACKAGECONFIG ??= ${@base_contains('DISTRO_FEATURES', 'pulseaudio', 
 'pulseaudio', '${PACKAGECONFIG_ALSA}', d)}
 +PACKAGECONFIG[pulseaudio] = --with-default-audio=pulse,,pulseaudio
 +PACKAGECONFIG[alsa] = --with-default-audio=alsa,,alsa-lib
 +
  LICENSE = LGPLv2.1
  LICENSE_FLAGS = commercial
  LIC_FILES_CHKSUM = file://COPYING;md5=a7aa23a2b646eca38ad4eeb7a853761c
 @@ -23,7 +31,5 @@ EXTRA_OECONF =  \
  --enable-shared \
  ${@bb.utils.contains('TUNE_FEATURES', 'neon', '--with-cpu=neon', '', d)} 
 \
  ${@bb.utils.contains('TUNE_FEATURES', 'altivec', '--with-cpu=altivec', 
 '', d)} \
 -${@bb.utils.contains('DISTRO_FEATURES', 'alsa', 
 '--with-default-audio=alsa', '', d)} \
 -${@bb.utils.contains('DISTRO_FEATURES', 'pulseaudio', 
 '--with-default-audio=pulse', '', d)} \
  
  
 -- 
 1.7.9.5
 
 ___
 Openembedded-devel mailing list
 Openembedded-devel@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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


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-filesystems][PATCH] cramfs: remove, we use mkfs.cramfs from util-linux

[Martin Jansa]

On Fri, Aug 30, 2013 at 01:39:54AM +0200, Andrea Adami wrote:
 Signed-off-by: Andrea Adami andrea.ad...@gmail.com

Applied, thanks

 ---
  .../recipes-filesystems/cramfs/cramfs_1.1.bb   | 29 
 --
  1 file changed, 29 deletions(-)
  delete mode 100644 meta-filesystems/recipes-filesystems/cramfs/cramfs_1.1.bb
 
 diff --git a/meta-filesystems/recipes-filesystems/cramfs/cramfs_1.1.bb 
 b/meta-filesystems/recipes-filesystems/cramfs/cramfs_1.1.bb
 deleted file mode 100644
 index 0bca0e1..000
 --- a/meta-filesystems/recipes-filesystems/cramfs/cramfs_1.1.bb
 +++ /dev/null
 @@ -1,29 +0,0 @@
 -DESCRIPTION = Builds cramfs filesystems for embedded systems
 -LICENSE = GPLv2
 -LIC_FILES_CHKSUM = file://COPYING;md5=393a5ca445f6965873eca0259a17f833
 -DEPENDS = zlib
 -
 -PE = 1
 -
 -SRC_URI = 
 http://sourceforge.net/projects/cramfs/files/cramfs/1.1/${BPN}-${PV}.tar.gz;
 -
 -SRC_URI[md5sum] = d3912b9f7bf745fbfea68f6a9b9de30f
 -SRC_URI[sha256sum] = 
 133caca2c4e7c64106555154ee0ff693f5cf5beb9421ce2eb86baee997d22368
 -
 -EXTRA_OEMAKE = \
 -'CC=${CC}' \
 -'CFLAGS=${CFLAGS}' \
 -'LDFLAGS=${LDFLAGS}' \
 -
 -
 -do_compile_prepend() {
 -ln -sf GNUmakefile Makefile
 -}
 -
 -do_install() {
 -install -d ${D}${bindir}
 -install mkcramfs ${D}${bindir}
 -install cramfsck ${D}${bindir}
 -}
 -
 -BBCLASSEXTEND = native
 -- 
 1.8.1.5
 
 ___
 Openembedded-devel mailing list
 Openembedded-devel@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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


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-oe, meta-gnome][PATCH 0/6] Removals of recipes/classes now in OE-Core

[Martin Jansa]

On Wed, Aug 28, 2013 at 11:43:22AM +0100, Paul Eggleton wrote:
 The following changes since commit 72e23c12296fbc77193898c38426add58d0c2d71:
 
   mysql5: replace with mariadb 5.1.67 and tweak (2013-08-27 16:39:31 +0100)

All applied, thanks!

 
 are available in the git repository at:
 
   git://git.openembedded.org/meta-openembedded-contrib paule/oecore-moves2
   
 http://cgit.openembedded.org/cgit.cgi/meta-openembedded-contrib/log/?h=paule/oecore-moves2
 
 Paul Eggleton (6):
   midori: remove
   vala: remove
   classes/vala: remove
   python-docutils: remove
   libnotify: remove
   ca-certificates: remove
 
  .../recipes-connectivity/midori/midori_0.5.2.bb| 42 
  .../recipes-gnome/libnotify/libnotify_0.6.0.bb | 17 ---
  meta-oe/classes/vala.bbclass   | 18 ---
  .../recipes-devtools/python/python-docutils_0.5.bb | 19 
  ...-gen-don-t-append-dirty-if-we-re-not-in-g.patch | 53 
  meta-oe/recipes-devtools/vala/vala.inc | 20 
  meta-oe/recipes-devtools/vala/vala_0.16.0.bb   |  8 
  .../ca-certificates/ca-certificates-20130119.inc   | 15 --
  .../ca-certificates-cross_20130119.bb  | 12 -
  ...01-update-ca-certificates-remove-c-rehash.patch | 45 -
  .../0002-update-ca-certificates-use-SYSROOT.patch  | 56 
 --
  .../ca-certificates/ca-certificates_20130119.bb| 30 
  12 files changed, 335 deletions(-)
  delete mode 100644 meta-gnome/recipes-connectivity/midori/midori_0.5.2.bb
  delete mode 100644 meta-gnome/recipes-gnome/libnotify/libnotify_0.6.0.bb
  delete mode 100644 meta-oe/classes/vala.bbclass
  delete mode 100644 meta-oe/recipes-devtools/python/python-docutils_0.5.bb
  delete mode 100644 
 meta-oe/recipes-devtools/vala/vala-0.16.0/0001-git-version-gen-don-t-append-dirty-if-we-re-not-in-g.patch
  delete mode 100644 meta-oe/recipes-devtools/vala/vala.inc
  delete mode 100644 meta-oe/recipes-devtools/vala/vala_0.16.0.bb
  delete mode 100644 
 meta-oe/recipes-support/ca-certificates/ca-certificates-20130119.inc
  delete mode 100644 
 meta-oe/recipes-support/ca-certificates/ca-certificates-cross_20130119.bb
  delete mode 100644 
 meta-oe/recipes-support/ca-certificates/ca-certificates/0001-update-ca-certificates-remove-c-rehash.patch
  delete mode 100644 
 meta-oe/recipes-support/ca-certificates/ca-certificates/0002-update-ca-certificates-use-SYSROOT.patch
  delete mode 100644 
 meta-oe/recipes-support/ca-certificates/ca-certificates_20130119.bb
 
 -- 
 1.8.1.2
 
 ___
 Openembedded-devel mailing list
 Openembedded-devel@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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


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-filesystems][PATCH] cramfs: remove, we use mkfs.cramfs from util-linux

[Koen Kooi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Op 30-08-13 01:39, Andrea Adami schreef:
 Signed-off-by: Andrea Adami andrea.ad...@gmail.com

Acked-by: Koen Kooi k...@dominion.thruhere.net


 --- .../recipes-filesystems/cramfs/cramfs_1.1.bb   | 29
 -- 1 file changed, 29 deletions(-) delete mode 100644
 meta-filesystems/recipes-filesystems/cramfs/cramfs_1.1.bb
 
 diff --git a/meta-filesystems/recipes-filesystems/cramfs/cramfs_1.1.bb
 b/meta-filesystems/recipes-filesystems/cramfs/cramfs_1.1.bb deleted file
 mode 100644 index 0bca0e1..000 ---
 a/meta-filesystems/recipes-filesystems/cramfs/cramfs_1.1.bb +++
 /dev/null @@ -1,29 +0,0 @@ -DESCRIPTION = Builds cramfs filesystems for
 embedded systems -LICENSE = GPLv2 -LIC_FILES_CHKSUM =
 file://COPYING;md5=393a5ca445f6965873eca0259a17f833 -DEPENDS = zlib 
 - -PE = 1 - -SRC_URI =
 http://sourceforge.net/projects/cramfs/files/cramfs/1.1/${BPN}-${PV}.tar.gz;

 
- -
 -SRC_URI[md5sum] = d3912b9f7bf745fbfea68f6a9b9de30f -SRC_URI[sha256sum]
 = 133caca2c4e7c64106555154ee0ff693f5cf5beb9421ce2eb86baee997d22368 - 
 -EXTRA_OEMAKE = \ -'CC=${CC}' \ -'CFLAGS=${CFLAGS}' \ -
 'LDFLAGS=${LDFLAGS}' \ - - -do_compile_prepend() { -ln -sf
 GNUmakefile Makefile -} - -do_install() { -install -d ${D}${bindir} -
 install mkcramfs ${D}${bindir} -install cramfsck ${D}${bindir} -} - 
 -BBCLASSEXTEND = native
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFSJh84MkyGM64RGpERAs7AAJ9ceR1ppWyopNzCingmWLRgy066YwCbBJz7
Fa5PcIAU6K/+bjJVOQBT16Y=
=SMq9
-END PGP SIGNATURE-

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH 0/3] ACPICA updates

[Martin Jansa]

On Mon, Aug 26, 2013 at 01:33:12PM +0300, Fathi Boudra wrote:
 Fathi Boudra (3):
   acpica: fix parallel build
   acpica: fix recipe to be OE compliant with spacing
   acpica: bump to version 20130823

All 3 applied, thanks!

 
  meta-oe/recipes-extended/acpica/acpica_20130626.bb | 37 --
  meta-oe/recipes-extended/acpica/acpica_20130823.bb | 37 ++
  .../acpica/files/fix-parallel-build.patch  | 80 
 ++
  3 files changed, 117 insertions(+), 37 deletions(-)
  delete mode 100644 meta-oe/recipes-extended/acpica/acpica_20130626.bb
  create mode 100644 meta-oe/recipes-extended/acpica/acpica_20130823.bb
  create mode 100644 
 meta-oe/recipes-extended/acpica/files/fix-parallel-build.patch
 
 -- 
 1.8.1.2
 

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


signature.asc
Description: Digital signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-oe][PATCH] vim: workaround nawk dependency problem with RPM

[Peter A. Bigot]

One of the examples has a #!/usr/bin/nawk which tells RPM to add that as a
dep, which we don't want.

Signed-off-by: Peter A. Bigot p...@pabigot.com
---
 meta-oe/recipes-support/vim/vim.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta-oe/recipes-support/vim/vim.inc 
b/meta-oe/recipes-support/vim/vim.inc
index d7336c2..991ba74 100644
--- a/meta-oe/recipes-support/vim/vim.inc
+++ b/meta-oe/recipes-support/vim/vim.inc
@@ -54,8 +54,9 @@ EXTRA_OECONF =  \
 
 
 do_install_append() {
-# Work around rpm picking up csh as a dep
+# Work around rpm picking up csh or awk as a dep
 chmod -x ${D}${datadir}/${PN}/${VIMDIR}/tools/vim132
+chmod -x ${D}${datadir}/${PN}/${VIMDIR}/tools/mve.awk
 
 # Install example vimrc from runtime files
 install -m 0644 ../runtime/vimrc_example.vim ${D}/${datadir}/${PN}/vimrc
-- 
1.8.4

___
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

[Joe MacDonald]

[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 bruce.ashfi...@gmail.com
 wrote:
 
 On Tue, Sep 3, 2013 at 9:13 AM, Laszlo Papp lp...@kde.org 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
 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 

Re: [oe] [meta-networking][PATCH] openflow: Add latest from git

[Joe MacDonald]

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 lp...@kde.org 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 
  bruce.ashfi...@gmail.comwrote:
 
  On Mon, Sep 2, 2013 at 11:55 PM, Laszlo Papp lp...@kde.org wrote:
   On Tue, Sep 3, 2013 at 2:56 AM, Bruce Ashfield bruce.ashfi...@gmail.com
  wrote:
  
   On Mon, Sep 2, 2013 at 4:20 AM, Laszlo Papp lp...@kde.org 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.
 
  

Re: [oe] [meta-networking][PATCH] openflow: Add latest from git

[Bruce Ashfield]

On Tue, Sep 3, 2013 at 5:08 PM, Joe MacDonald j...@deserted.net 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 lp...@kde.org 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 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.

What about the following:

  - We at least give reference to the other recipe, either in the git commit
message or the recipe itself ? Regardless if this was a clean room
implementation or not .. they are nearly identical (of course that means
there is one right way to do this), and at least maintaining the paper trail
if the recipe migrates is 

Re: [oe] [meta-networking][PATCH] openflow: Add latest from git

[Joe MacDonald]

On Tue, Sep 3, 2013 at 6:39 PM, Bruce Ashfield bruce.ashfi...@gmail.com wrote:

 On Tue, Sep 3, 2013 at 5:08 PM, Joe MacDonald j...@deserted.net 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 lp...@kde.org 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.
 
  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