[oe] [meta-oe][PATCH v2] Add uthash recipe
From: Laszlo Papp lp...@kde.org
Signed-off-by: Laszlo Papp lp...@kde.org
---
meta-oe/recipes-support/uthash_1.9.7.bb | 14 ++
1 file changed, 14 insertions(+)
create mode 100644 meta-oe/recipes-support/uthash_1.9.7.bb
diff --git a/meta-oe/recipes-support/uthash_1.9.7.bb
b/meta-oe/recipes-support/uthash_1.9.7.bb
new file mode 100644
index 000..e5dde1a
--- /dev/null
+++ b/meta-oe/recipes-support/uthash_1.9.7.bb
@@ -0,0 +1,14 @@
+SUMMARY = Hash table for C structures
+SECTION = base
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://LICENSE;md5=564f9c44927f6247dc810bf557e2b240
+
+SRC_URI = ${SOURCEFORGE_MIRROR}/${BPN}/${BP}.tar.bz2
+
+SRC_URI[md5sum] = 1f14bbee7ee73ed0ceb3549f8cf378b4
+SRC_URI[sha256sum] =
956f5c99798349c413275fe4c9ff128d72e280655dadbe4365f8e9fbda91393f
+
+do_install () {
+install -dm755 ${D}${includedir}
+install -m 0644 ${S}/src/*.h ${D}${includedir}
+}
--
2.3.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] Add uthash recipe
Signed-off-by: Laszlo Papp laszlo.p...@polatis.com
---
meta-oe/recipes-support/uthash_1.9.7.bb | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 meta-oe/recipes-support/uthash_1.9.7.bb
diff --git a/meta-oe/recipes-support/uthash_1.9.7.bb
b/meta-oe/recipes-support/uthash_1.9.7.bb
new file mode 100644
index 000..4504dfe
--- /dev/null
+++ b/meta-oe/recipes-support/uthash_1.9.7.bb
@@ -0,0 +1,15 @@
+DESCRIPTION = Hash table for C structures
+SECTION = base
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://LICENSE;md5=564f9c44927f6247dc810bf557e2b240
+PR = r1
+
+SRC_URI = http://downloads.sourceforge.net/uthash/${PN}-${PV}.tar.bz2;
+
+SRC_URI[md5sum] = 1f14bbee7ee73ed0ceb3549f8cf378b4
+SRC_URI[sha256sum] =
956f5c99798349c413275fe4c9ff128d72e280655dadbe4365f8e9fbda91393f
+
+do_install () {
+install -dm755 ${D}${includedir}
+install -m 0644 ${S}/src/*.h ${D}${includedir}
+}
--
2.3.0
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-qt5][PATCH] Added module qtquickcontrols
Were you able to run an example after adding this?
On Wed, Sep 11, 2013 at 12:19 PM, Erik Botö erik.b...@pelagicore.comwrote:
Signed-off-by: Erik Botö erik.b...@pelagicore.com
---
recipes-qt/qt5/qtquickcontrols.inc | 3 +++
recipes-qt/qt5/qtquickcontrols_5.1.0.bb | 5 +
2 files changed, 8 insertions(+)
create mode 100644 recipes-qt/qt5/qtquickcontrols.inc
create mode 100644 recipes-qt/qt5/qtquickcontrols_5.1.0.bb
diff --git a/recipes-qt/qt5/qtquickcontrols.inc
b/recipes-qt/qt5/qtquickcontrols.inc
new file mode 100644
index 000..63e884e
--- /dev/null
+++ b/recipes-qt/qt5/qtquickcontrols.inc
@@ -0,0 +1,3 @@
+require qt5.inc
+
+DEPENDS += qtdeclarative
diff --git a/recipes-qt/qt5/qtquickcontrols_5.1.0.bb b/recipes-qt/qt5/
qtquickcontrols_5.1.0.bb
new file mode 100644
index 000..fc880d7
--- /dev/null
+++ b/recipes-qt/qt5/qtquickcontrols_5.1.0.bb
@@ -0,0 +1,5 @@
+require qt5-${PV}.inc
+require ${PN}.inc
+
+SRC_URI[md5sum] = b3825124a173a36f63c2f8380dc61e81
+SRC_URI[sha256sum] =
88d39421d78464c3900c37616e8369fc8d998c1b0f611980e6e082f46569646b
--
1.8.1.2
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-qt5][PATCH] Added module qtquickcontrols
Very nice, thanks.
On Wed, Sep 11, 2013 at 12:27 PM, Erik Botö erik.b...@pelagicore.comwrote:
Yes, I have a project that uses QtQuick.Layouts 1.0 and
QtQuick.Controls 1.0. I haven't done extensive testing, but after
adding this module the GUI starts and seems to be working as intended.
Cheers,
Erik
On Wed, Sep 11, 2013 at 1:22 PM, Laszlo Papp lp...@kde.org wrote:
Were you able to run an example after adding this?
On Wed, Sep 11, 2013 at 12:19 PM, Erik Botö erik.b...@pelagicore.com
wrote:
Signed-off-by: Erik Botö erik.b...@pelagicore.com
---
recipes-qt/qt5/qtquickcontrols.inc | 3 +++
recipes-qt/qt5/qtquickcontrols_5.1.0.bb | 5 +
2 files changed, 8 insertions(+)
create mode 100644 recipes-qt/qt5/qtquickcontrols.inc
create mode 100644 recipes-qt/qt5/qtquickcontrols_5.1.0.bb
diff --git a/recipes-qt/qt5/qtquickcontrols.inc
b/recipes-qt/qt5/qtquickcontrols.inc
new file mode 100644
index 000..63e884e
--- /dev/null
+++ b/recipes-qt/qt5/qtquickcontrols.inc
@@ -0,0 +1,3 @@
+require qt5.inc
+
+DEPENDS += qtdeclarative
diff --git a/recipes-qt/qt5/qtquickcontrols_5.1.0.bb b/recipes-qt/qt5/
qtquickcontrols_5.1.0.bb
new file mode 100644
index 000..fc880d7
--- /dev/null
+++ b/recipes-qt/qt5/qtquickcontrols_5.1.0.bb
@@ -0,0 +1,5 @@
+require qt5-${PV}.inc
+require ${PN}.inc
+
+SRC_URI[md5sum] = b3825124a173a36f63c2f8380dc61e81
+SRC_URI[sha256sum] =
88d39421d78464c3900c37616e8369fc8d998c1b0f611980e6e082f46569646b
--
1.8.1.2
___
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
--
=
Erik Botö
Senior Software Engineer
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)76 881 72 03
E-Mail: erik.b...@pelagicore.com
=
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
On Thu, Sep 5, 2013 at 10:01 AM, Burton, Ross ross.bur...@intel.com wrote: On 5 September 2013 05:39, Bruce Ashfield bruce.ashfi...@gmail.com wrote: The meta-virt recipe had the same _1.0.bb extension, and it's SRCREV lines up with the openflow-1.0.0 tag in the repository: commit 5ccca75a69f99791659bcfbcf35353ab1921320a Author: Glen Gibb g...@stanford.edu Date: Thu Dec 31 16:00:53 2009 -0800 docs: Update ChangeLog to include 1.0.0 information :100644 100644 2f13dd7... aa0e92e... M ChangeLog --- So it's definitely an option to keep that recipe around as the tagged 1.0, and create a _git that tracks newer changes (where newer is relative, 2011 is the latest commit in that repo). FWIW, I massively prefer releases that are taken from git like this (where its a git fetch on a hash that is the tag of the releases) to be versioned correctly like _1.0.bb instead of _git.bb for clarity and future alternatives such as true git snapshot or multiple versions. ... and I massively prefer released not to be taken from git. So if 1.0 has to be *really* supported which I do not think so, it should get the release tarball. Moreover, there have not been new git commits for about two years now because the standard was taken over by a different organization which seems to work behind the scenes. Too bad, they have not released the latest before that change. Hopefully, this will not mislead anyone that this software is still actively developed in public. That is another very reason IMHO which it would not fit the core layer at all. -- Laszlo Ross ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
I still do not follow why you are not waiting patiently for an update. I have already written that I would send one soon (this thread demoralized me and motivated though for a bit of delay). All the discussion would have been spared in here, as the issues were addressed before I even sent the wrong version. How about reviewing other pending changes for weeks like stunnel? On Thu, Sep 5, 2013 at 2:04 PM, Joe MacDonald j...@deserted.net wrote: [Re: [oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.05 (Thu 10:01) Burton, Ross wrote: On 5 September 2013 05:39, Bruce Ashfield bruce.ashfi...@gmail.com wrote: The meta-virt recipe had the same _1.0.bb extension, and it's SRCREV lines up with the openflow-1.0.0 tag in the repository: commit 5ccca75a69f99791659bcfbcf35353ab1921320a Author: Glen Gibb g...@stanford.edu Date: Thu Dec 31 16:00:53 2009 -0800 docs: Update ChangeLog to include 1.0.0 information :100644 100644 2f13dd7... aa0e92e... M ChangeLog --- So it's definitely an option to keep that recipe around as the tagged 1.0, and create a _git that tracks newer changes (where newer is relative, 2011 is the latest commit in that repo). FWIW, I massively prefer releases that are taken from git like this (where its a git fetch on a hash that is the tag of the releases) to be versioned correctly like _1.0.bb instead of _git.bb for clarity and future alternatives such as true git snapshot or multiple versions. Yeah, since the SRCREV in the _1.0.bb recipe actually corresponds to the 1.0 release tag, I'm in agreement. The proposed update from Laszlo also now seems to justify having a _git.bb version, since it's pointing at a (relatively) newer version of the recipe. -- -Joe MacDonald. :wq ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] stunnel: Add 4.56 version
Thanks.
On Thu, Sep 5, 2013 at 2:09 PM, Joe MacDonald j...@deserted.net wrote:
[Re: [meta-networking][PATCH] stunnel: Add 4.56 version] On 13.09.05 (Thu
06:06) Laszlo Papp wrote:
Seriously: ping?
I guess I should've replied directly to this rather than burying my
follow-up on it in another thread. Sorry. It's been merged and is in a
small queue of other fixes and updates I'm about to push.
-J.
On Wed, Sep 4, 2013 at 8:47 AM, Laszlo Papp lp...@kde.org wrote:
Ping?
On Thu, Aug 22, 2013 at 8:07 PM, Laszlo Papp lp...@kde.org wrote:
Signed-off-by: Laszlo Papp lp...@kde.org
---
meta-networking/recipes-support/stunnel/stunnel_4.56.bb | 14
++
1 file changed, 14 insertions(+)
create mode 100644 meta-networking/recipes-support/stunnel/
stunnel_4.56.bb
diff --git a/meta-networking/recipes-support/stunnel/
stunnel_4.56.bb b/
meta-networking/recipes-support/stunnel/stunnel_4.56.bb
new file mode 100644
index 000..0ee8cc8
--- /dev/null
+++ b/meta-networking/recipes-support/stunnel/stunnel_4.56.bb
@@ -0,0 +1,14 @@
+SUMMARY = SSL encryption wrapper between remote client and
local
(inetd-startable) or remote server.
+SECTION = net
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=
f41ebed8571077706fee0b860c4d
+DEPENDS = openssl
+
+SRC_URI = https://www.stunnel.org/downloads/${BP}.tar.gz;
+
+SRC_URI[md5sum] = ac4c4a30bd7a55b6687cbd62d864054c
+SRC_URI[sha256sum] =
9cae2cfbe26d87443398ce50d7d5db54e5ea363889d5d2ec8d2778a01c871293
+
+inherit autotools
+
+EXTRA_OECONF += --with-ssl='${STAGING_INCDIR}' --disable-fips
--
1.8.3.4
--
-Joe MacDonald.
:wq
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] Dropped libnl fix for net-snmp: Why?
Hi Joe and co, what exactly is the reason for this patch having been dropped? http://patches.openembedded.org/patch/20563/ This was not so thoughtful decision. The current net-snmp version will not build against denzil, and in fact, this patch should be even upstreamed. I will take care about that one, but is there any objection against me submitting this change for net-snmp in meta-networking? Cheers, Laszlo ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Dropped libnl fix for net-snmp: Why?
OK, thanks. I am just trying to make sure not to break anything for libnl 3.x. Here is the old upstream report: https://sourceforge.net/p/net-snmp/bugs/2238/ On Thu, Sep 5, 2013 at 6:22 PM, Joe MacDonald j...@deserted.net wrote: [Dropped libnl fix for net-snmp: Why?] On 13.09.05 (Thu 16:43) Laszlo Papp wrote: Hi Joe and co, what exactly is the reason for this patch having been dropped? http://patches.openembedded.org/patch/20563/ This was not so thoughtful decision. The current net-snmp version will not build against denzil, and in fact, this patch should be even upstreamed. I will take care about that one, but is there any objection against me submitting this change for net-snmp in meta-networking? Nope, no objection from me. It appears to be reasonable. I think the only reason it doesn't appear in meta-net today is it was sent against OE Classic and perhaps never sent for inclusion in meta-openembedded. That's just a wild guess, though, it looks like the whole thing may pre-date my involvement with the project. -- -Joe MacDonald. :wq ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] stunnel: Add 4.56 version
Ping?
On Thu, Aug 22, 2013 at 8:07 PM, Laszlo Papp lp...@kde.org wrote:
Signed-off-by: Laszlo Papp lp...@kde.org
---
meta-networking/recipes-support/stunnel/stunnel_4.56.bb | 14
++
1 file changed, 14 insertions(+)
create mode 100644 meta-networking/recipes-support/stunnel/
stunnel_4.56.bb
diff --git
a/meta-networking/recipes-support/stunnel/stunnel_4.56.bbb/meta-networking/recipes-support/stunnel/
stunnel_4.56.bb
new file mode 100644
index 000..0ee8cc8
--- /dev/null
+++ b/meta-networking/recipes-support/stunnel/stunnel_4.56.bb
@@ -0,0 +1,14 @@
+SUMMARY = SSL encryption wrapper between remote client and local
(inetd-startable) or remote server.
+SECTION = net
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=f41ebed8571077706fee0b860c4d
+DEPENDS = openssl
+
+SRC_URI = https://www.stunnel.org/downloads/${BP}.tar.gz;
+
+SRC_URI[md5sum] = ac4c4a30bd7a55b6687cbd62d864054c
+SRC_URI[sha256sum] =
9cae2cfbe26d87443398ce50d7d5db54e5ea363889d5d2ec8d2778a01c871293
+
+inherit autotools
+
+EXTRA_OECONF += --with-ssl='${STAGING_INCDIR}' --disable-fips
--
1.8.3.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
On Wed, Sep 4, 2013 at 2:13 PM, Philip Balister phi...@balister.org wrote: snip The same applies to anyone else working on a layer with clearly networking components that may be reluctant to incorporate it into meta-net. I'm welcoming submissions of useful components and I'd be really disappointed if we ended up having the same (or similar) recipes in multiple public layers purely due to reticence and (perceived?) extra dependencies. I'll be other meta-oe maintainers feel the same, too. Balkanisation benefits no one. Back on topic, then. I am really late to the game ... If you are having trouble figuring out what layer a recipe belongs in due to it being needed for several layers, maybe the package in question belongs in oe-core. You are not just late, but also quite off IMHO ... ;-) As written already, and if you had taken the time to look into the software in question, you would have realized that from more than one point of view that this standard is definitely a domain specific network material. It is *far* away from being a core component. Off-topic: I do not understand why meta-virtualization is this messy. That seems to cause the whole annoyance in here on top of the give me the credit for a few lines which can only be written in one way other argument. Anyway, this seems to be an appropriate trigger for meta-virtualization to get some stabilization. Past mistakes are no excuse for introducing more, in my book. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
As I wrote, I have not uploaded the newest revision, so please do not
review the old.
Anyway, Bruce managed to demotivate me to contribute. I am currently not in
a mood after all this for sending the update.
On Wed, Sep 4, 2013 at 10:14 PM, Joe MacDonald j...@deserted.net wrote:
Actually, after all of that, I do have a couple of additional requests
(beyond just the tweak to the commit log).
Explicitly cc:ing Bruce here since I'm intentionally not adding
meta-virt@. I've gotten bounced from it in the past as I'm not a
subscriber and it's subscriber-only.
[[oe] [meta-networking][PATCH] openflow: Add latest from git] On 13.09.02
(Mon 09:20) Laszlo Papp wrote:
1) The version in meta-virtualization is quite old. It is basically from
2009,
and a lot of things has changed since then.
2) More importantly, this software is more like for networking rather
than
virtualization, so I think it was misplaced.
SOB please?
---
.../recipes-support/openflow/openflow_1.0.bb | 32
++
Is this actually based on an OpenFlow 1.0 release, or has it always been
1.0+git? I don't have a copy of meta-virt around to check myself. If
there was a real 1.0 recipe around, can we keep it as is and make this
openflow_git.bb, more in line with the other +git... recipes?
1 file changed, 32 insertions(+)
create mode 100644 meta-networking/recipes-support/openflow/
openflow_1.0.bb
diff --git
a/meta-networking/recipes-support/openflow/openflow_1.0.bbb/meta-networking/recipes-support/openflow/
openflow_1.0.bb
new file mode 100644
index 000..eb7770e
--- /dev/null
+++ b/meta-networking/recipes-support/openflow/openflow_1.0.bb
@@ -0,0 +1,32 @@
+SUMMARY = OpenFlow
+DESCRIPTION = Open standard that enables researchers to run
experimental protocols in the campus networks
+HOMEPAGE = http://www.openflow.org;
+SECTION = networking
+LICENSE = GPLv2
+
+LIC_FILES_CHKSUM = file://COPYING;md5=e870c934e2c3d6ccf085fd7cf0a1e2e2
+
+SRCREV = c84f33f09d5dbcfc9b489f64cb30475bf36f653a
+PV = 1.0+git${SRCPV}
+SRC_URI = git://gitosis.stanford.edu/openflow.git;protocol=git
+
+DEPENDS = virtual/libc
+
+EXTRA_OECONF += KARCH=${TARGET_ARCH}
+
+PACKAGECONFIG ??= libssl
+PACKAGECONFIG[libssl] = --enable-ssl,--disable-ssl, openssl, libssl
+
+S = ${WORKDIR}/git
+
+inherit autotools
+
+do_configure() {
+./boot.sh
+oe_runconf
+}
+
+do_install_append() {
+ # Remove /var/run as it is created on startup
+rm -rf ${D}${localstatedir}/run
+}
And while we're in the neighbourhood, can we also clean up the
inconsistent spacing?
Thanks.
--
-Joe MacDonald.
:wq
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] stunnel: Add 4.56 version
Seriously: ping?
On Wed, Sep 4, 2013 at 8:47 AM, Laszlo Papp lp...@kde.org wrote:
Ping?
On Thu, Aug 22, 2013 at 8:07 PM, Laszlo Papp lp...@kde.org wrote:
Signed-off-by: Laszlo Papp lp...@kde.org
---
meta-networking/recipes-support/stunnel/stunnel_4.56.bb | 14
++
1 file changed, 14 insertions(+)
create mode 100644 meta-networking/recipes-support/stunnel/
stunnel_4.56.bb
diff --git
a/meta-networking/recipes-support/stunnel/stunnel_4.56.bbb/meta-networking/recipes-support/stunnel/
stunnel_4.56.bb
new file mode 100644
index 000..0ee8cc8
--- /dev/null
+++ b/meta-networking/recipes-support/stunnel/stunnel_4.56.bb
@@ -0,0 +1,14 @@
+SUMMARY = SSL encryption wrapper between remote client and local
(inetd-startable) or remote server.
+SECTION = net
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=f41ebed8571077706fee0b860c4d
+DEPENDS = openssl
+
+SRC_URI = https://www.stunnel.org/downloads/${BP}.tar.gz;
+
+SRC_URI[md5sum] = ac4c4a30bd7a55b6687cbd62d864054c
+SRC_URI[sha256sum] =
9cae2cfbe26d87443398ce50d7d5db54e5ea363889d5d2ec8d2778a01c871293
+
+inherit autotools
+
+EXTRA_OECONF += --with-ssl='${STAGING_INCDIR}' --disable-fips
--
1.8.3.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
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
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
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
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] libcarp-perl: added
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] [meta-networking][PATCH] openflow: Add latest from git
1) The version in meta-virtualization is quite old. It is basically from 2009,
and a lot of things has changed since then.
2) More importantly, this software is more like for networking rather than
virtualization, so I think it was misplaced.
---
.../recipes-support/openflow/openflow_1.0.bb | 32 ++
1 file changed, 32 insertions(+)
create mode 100644 meta-networking/recipes-support/openflow/openflow_1.0.bb
diff --git a/meta-networking/recipes-support/openflow/openflow_1.0.bb
b/meta-networking/recipes-support/openflow/openflow_1.0.bb
new file mode 100644
index 000..eb7770e
--- /dev/null
+++ b/meta-networking/recipes-support/openflow/openflow_1.0.bb
@@ -0,0 +1,32 @@
+SUMMARY = OpenFlow
+DESCRIPTION = Open standard that enables researchers to run experimental
protocols in the campus networks
+HOMEPAGE = http://www.openflow.org;
+SECTION = networking
+LICENSE = GPLv2
+
+LIC_FILES_CHKSUM = file://COPYING;md5=e870c934e2c3d6ccf085fd7cf0a1e2e2
+
+SRCREV = c84f33f09d5dbcfc9b489f64cb30475bf36f653a
+PV = 1.0+git${SRCPV}
+SRC_URI = git://gitosis.stanford.edu/openflow.git;protocol=git
+
+DEPENDS = virtual/libc
+
+EXTRA_OECONF += KARCH=${TARGET_ARCH}
+
+PACKAGECONFIG ??= libssl
+PACKAGECONFIG[libssl] = --enable-ssl,--disable-ssl, openssl, libssl
+
+S = ${WORKDIR}/git
+
+inherit autotools
+
+do_configure() {
+./boot.sh
+oe_runconf
+}
+
+do_install_append() {
+ # Remove /var/run as it is created on startup
+rm -rf ${D}${localstatedir}/run
+}
--
1.8.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] openflow: Add latest from git
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. If you would have asked, you would have been told that updates are pending with bindings that need to stay in lock step with other parts of meta-virt. Sorry, but how is this relevant? It is an extremely old recipe, and should not be used. Moreover, this should not block the non-ancient users at all, which is probably the majority. 2) More importantly, this software is more like for networking rather than virtualization, so I think it was misplaced. I disagree, so for now meta-virt is going to keep it's variants of the recipes and we need to have an actual discussion to figure out the best way forward. ,,, and I disagree with you. Read the specification for openflow, please. I fail to understand how it has anything to do with virtualization. Seriously, this is a software for networking devices. That is, exactly the main purpose what meta-networking is trying to achieve: aiding the development for networking devices. As for me, it is totally non-comprehensive why a networking specification and the relevant implementation would be in meta-virtualization rather than meta-networking. Not to mention, I do not understand why you are trying to set a straw man in here. The discussion you are requesting is exactly what this thread is meant to be. So, I think you are simply incorrect IMHO. :-) Cheers, Laszlo ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-qt5][PATCH] QtSerialPort: Add 5.1.0 version
Signed-off-by: Laszlo Papp lp...@kde.org
---
recipes-qt/qt5/qtserialport.inc | 3 +++
recipes-qt/qt5/qtserialport_5.1.0.bb | 10 ++
2 files changed, 13 insertions(+)
create mode 100644 recipes-qt/qt5/qtserialport.inc
create mode 100644 recipes-qt/qt5/qtserialport_5.1.0.bb
diff --git a/recipes-qt/qt5/qtserialport.inc b/recipes-qt/qt5/qtserialport.inc
new file mode 100644
index 000..bbb05a6
--- /dev/null
+++ b/recipes-qt/qt5/qtserialport.inc
@@ -0,0 +1,3 @@
+require qt5.inc
+
+DEPENDS += qtbase
diff --git a/recipes-qt/qt5/qtserialport_5.1.0.bb
b/recipes-qt/qt5/qtserialport_5.1.0.bb
new file mode 100644
index 000..11b5346
--- /dev/null
+++ b/recipes-qt/qt5/qtserialport_5.1.0.bb
@@ -0,0 +1,10 @@
+require qt5-${PV}.inc
+require ${PN}.inc
+
+LIC_FILES_CHKSUM = file://LICENSE.LGPL;md5=4fbd65380cdd255951079008b364516c \
+file://LICENSE.FDL;md5=3801d7932fdc07fd9efe89f9854a6caa \
+
file://LGPL_EXCEPTION.txt;md5=eb6c371255e1262c55ae9b652a90b528\
+
+
+SRC_URI[md5sum] = 1f70621ae40cbda948106b070c6c37d2
+SRC_URI[sha256sum] =
0f36803c480b2b7111b343e9dd871ffab1b4fd53147bd564125ef2994b09cfb9
--
1.8.3.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-networking][PATCH] stunnel: Add 4.56 version
Signed-off-by: Laszlo Papp lp...@kde.org
---
meta-networking/recipes-support/stunnel/stunnel_4.56.bb | 14 ++
1 file changed, 14 insertions(+)
create mode 100644 meta-networking/recipes-support/stunnel/stunnel_4.56.bb
diff --git a/meta-networking/recipes-support/stunnel/stunnel_4.56.bb
b/meta-networking/recipes-support/stunnel/stunnel_4.56.bb
new file mode 100644
index 000..0ee8cc8
--- /dev/null
+++ b/meta-networking/recipes-support/stunnel/stunnel_4.56.bb
@@ -0,0 +1,14 @@
+SUMMARY = SSL encryption wrapper between remote client and local
(inetd-startable) or remote server.
+SECTION = net
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=f41ebed8571077706fee0b860c4d
+DEPENDS = openssl
+
+SRC_URI = https://www.stunnel.org/downloads/${BP}.tar.gz;
+
+SRC_URI[md5sum] = ac4c4a30bd7a55b6687cbd62d864054c
+SRC_URI[sha256sum] =
9cae2cfbe26d87443398ce50d7d5db54e5ea363889d5d2ec8d2778a01c871293
+
+inherit autotools
+
+EXTRA_OECONF += --with-ssl='${STAGING_INCDIR}' --disable-fips
--
1.8.3.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-qt5][PATCH] Add QtSerialPort
Signed-off-by: Laszlo Papp lp...@kde.org
---
recipes-qt/qt5/qtserialport.inc | 3 +++
recipes-qt/qt5/qtserialport_5.1.0.bb | 5 +
2 files changed, 8 insertions(+)
create mode 100644 recipes-qt/qt5/qtserialport.inc
create mode 100644 recipes-qt/qt5/qtserialport_5.1.0.bb
diff --git a/recipes-qt/qt5/qtserialport.inc b/recipes-qt/qt5/qtserialport.inc
new file mode 100644
index 000..bbb05a6
--- /dev/null
+++ b/recipes-qt/qt5/qtserialport.inc
@@ -0,0 +1,3 @@
+require qt5.inc
+
+DEPENDS += qtbase
diff --git a/recipes-qt/qt5/qtserialport_5.1.0.bb
b/recipes-qt/qt5/qtserialport_5.1.0.bb
new file mode 100644
index 000..9b6f7da
--- /dev/null
+++ b/recipes-qt/qt5/qtserialport_5.1.0.bb
@@ -0,0 +1,5 @@
+require qt5-${PV}.inc
+require ${PN}.inc
+
+SRC_URI[md5sum] = 1f70621ae40cbda948106b070c6c37d2
+SRC_URI[sha256sum] =
0f36803c480b2b7111b343e9dd871ffab1b4fd53147bd564125ef2994b09cfb9
--
1.8.3.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] Add QtSerialPort
If you check the second email carefully, it already contains the right subject... On Sat, Aug 3, 2013 at 6:50 PM, Otavio Salvador ota...@ossystems.com.brwrote: On Sat, Aug 3, 2013 at 7:38 AM, Laszlo Papp lp...@kde.org wrote: Signed-off-by: Laszlo Papp lp...@kde.org Please use the meta-qt5 prefix and rewrite the commit log as: qtserialport: Add 5.1.0 version We always put the recipe in question as this makes easier to find it later. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://projetos.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ 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
