Re: [oe] [OE-core] SRC_URI computing order
On Mon, Nov 4, 2013 at 11:13 PM, Andrea Adami andrea.ad...@gmail.com wrote:
On Mon, Nov 4, 2013 at 12:10 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Sun, 2013-11-03 at 23:16 +0100, Andrea Adami wrote:
On Sat, Nov 2, 2013 at 9:47 AM, Eric Bénard e...@eukrea.com wrote:
Hi Richard,
Le Wed, 30 Oct 2013 15:15:12 +,
Richard Purdie richard.pur...@linuxfoundation.org a écrit :
On Tue, 2013-10-29 at 08:28 +0100, Eric Bénard wrote:
Hi Khem,
Le Mon, 28 Oct 2013 20:45:21 -0700,
Khem Raj raj.k...@gmail.com a écrit :
On Mon, Oct 28, 2013 at 7:10 AM, Eric Bénard e...@eukrea.com wrote:
Hi Richard,
I saw your patch fixing FILESPATH's and Kergoth's one fixing
PACKAGECONFIG processing order and I think I'm also facing an order
problem when SRC_URI is computed.
So when building SRC_URI when two layers have bbappend which apply
patches : the SRC_URI seems to be built using an order I fail to
understand somewhere instead of priority or the overrides' order.
The use case is a System on Module and its custom motherboard :
- meta-fsl-arm :
* linux-imx_xyz.bb :
SRC_URI = patchgeneric1 ...
- meta-som-support :
* conf/machine/mysom.conf
* linux-imx_xyz.bbappend :
SRC_URI_append_mysom = patchsom1 patchsom2 ...
- meta-custommotherboard (SOM + Cunstom Motherboard) :
* conf/machine/myproduct.conf
MACHINEOVERRIDES_prepend = mysom:
include conf/machine/mysom.conf
* linux-imx_xyz.bbappend :
SRC_URI_append_myproduct = patchproduct1 patchproduct2 ...
in the end I get :
SRC_URI = patchgeneric1 ... patchsoc1 ... patchproduct1 ...
patchsom1 ...
and of course as patchproduct* are supposed to apply on top of
patchsoc* the patch fail to apply.
I didn't found a way to build SRC_URI in the order I would like (I
tested : changing MACHINEOVERRIDES 's order, changing layers'
priority,
changing machine's name to see if that was an alphabetical order
...).
In the end the only thing which worked was to add an (empty by
default)
variable in som's SRC_URI and filling this variables from the
custommotherboard's bbappend.
Is the behaviour I'm seeing expected or is there something wrong
in my
setup ?
what is your OVERRIDES order.
${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable
so it follows the MACHINEOVERRIDES order (and I tried both append and
prepend to hack MACHINEOVERRIDES without any behaviour change).
I think what Khem is asking is what OVERRIDES expands to?
You mean patchso* and not patchsoc* above, right? Or should patchsom1 be
patchsoc2?
oops :
I expect SRC_URI = patchgeneric1 ... patchsom1 ... patchproduct1 ...
and I get :
SRC_URI = patchgeneric1 ... patchproduct1 ... patchsom1 ...
Its hard to follow and it might be easier if you could share a
simplified test case we could reproduce this with. I don't doubt there
is an issue in there but we need a way to reproduce and debug this.
OK, I'm preparing a simple testcase to reproduce that with oe-core +
meta-fsl-arm + meta-som + meta-baseboard.
Eric
___
Openembedded-core mailing list
openembedded-c...@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
I have to report an undesiderate behavior:
the formfactor files in our .bbappend are not considered :/
DEBUG: Searching for machconfig in paths:
/oe/oe-core/meta/recipes-bsp/formfactor/formfactor-0.0/
/oe/oe-core/meta/recipes-bsp/formfactor/formfactor/
/oe/oe-core/meta/recipes-bsp/formfactor/files/
/oe/meta-handheld/recipes-bsp/formfactor/files/poodle
so we end up with the empty machconfig of
/oe/oe-core/meta/recipes-bsp/formfactor/files/
Surely this didn't happen when we tested the recipe.
With which revision of OE-Core? Was this with the dora release tag,
current dora head or master?
Cheers,
Richard
This was with fresh master:
Build Configuration:
BB_VERSION= 1.21.0
BUILD_SYS = i686-linux
NATIVELSBSTRING = Gentoo
TARGET_SYS= arm-oe-linux-gnueabi
MACHINE = poodle
DISTRO_VERSION= oe-core.0
TUNE_FEATURES = armv5 thumb dsp
TARGET_FPU= soft
meta = master:511b4194165ed7a5645169e09c27db280d5a5316
meta-initramfs= master:4d62e7f575e2a87197c74ab4639561b45eec0e60
meta-handheld = master:55a310666b543e6beca47fa3c197492d5a6cf8ff
Cheers
FYI
In the hurry for a solution for fixing formfactor and ipaq-boot-params
my quick hack was to revert
http://cgit.openembedded.org/openembedded-core/commit/meta?id=92cbf7eeea553bfa24c7081473fa8bc4ebc1f552
That appears to fix the specific issue...
Andrea
Re: [oe] [PATCH] libhugetlbfs: add support for armv7a
On 2013-10-28 18:42, Khem Raj wrote:
On Fri, Oct 18, 2013 at 7:09 AM, Anders Roxell anders.rox...@linaro.org
wrote:
Signed-off-by: Anders Roxell anders.rox...@linaro.org
---
meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
index 24480c3..4f1bfa4 100644
--- a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
+++ b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
@@ -20,10 +20,16 @@ SRC_URI = git://git.code.sf.net/p/libhugetlbfs/code \
S = ${WORKDIR}/git
-COMPATIBLE_HOST = (x86_64|powerpc|powerpc64|aarch64).*-linux*
+COMPATIBLE_HOST = (x86_64|powerpc|powerpc64|arm|aarch64).*-linux*
+python __anonymous() {
+if base_contains('TARGET_ARCH', 'arm', True, False, d):
+d.setVar('ARCH', 'armv7l')
+else:
+d.setVar('ARCH', d.getVar('TARGET_ARCH'))
+}
I'm sorry for the late response.
instead of this fugly anon python you could do
ARCH_arm = armv7l
ARCH ?= ${TARGET_ARCH}
Much better, thanks!
and btw. we support ARM v4,v5,v6 architectures as well. It seems your
patch only cares about armv7,
and if this recipe only works for armv7+ then dont open the floodgates
for all kind of arm architectures.
Agree.
Will send out patch v2.
Cheers,
Anders
-EXTRA_OEMAKE = 'ARCH=${TARGET_ARCH}' 'OPT=${CFLAGS}' 'CC=${CC}'
BUILDTYPE=NATIVEONLY ${LIBARGS}
+EXTRA_OEMAKE = 'ARCH=${ARCH}' 'OPT=${CFLAGS}' 'CC=${CC}'
BUILDTYPE=NATIVEONLY ${LIBARGS}
CFLAGS += -fexpensive-optimizations -frename-registers
-fomit-frame-pointer -g0
TARGET_CC_ARCH += ${LDFLAGS}
--
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
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Still getting gd-2.0.36RC1.tar.gz errors in meta-oe/recipes-support/gd/gd_2.0.35+2.0.36rc1.bb
On Monday 04 November 2013 22:46:36 Martin Jansa wrote: On Mon, Nov 04, 2013 at 04:09:22PM -0500, Brian Hutchinson wrote: This has been going on for the last month or two. Apparently this upstream project name changed and it no longer available at the URL. I looked into it several weeks ago but it didn't look like a simple URL path fix as it looked like other stuff depends on it. I've been coping the file from an earlier build to my downloads directory to get my builds to complete. grab copy from http://ring.u-toyama.ac.jp/archives/graphics/gd/ and put it on your PREMIRROR. Tom, would you be able to grab http://ring.u-toyama.ac.jp/archives/graphics/gd/gd-2.0.36RC1.tar.gz and put it on the OE source mirror? md5sum should be 39ac48e6d5e0012a3bd2248a0102f209. Thanks, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] tcpdump, tcpreplay:relocate tcpdump and add tcpreplay recipe
Please use -M to get smaller diff. On Wed, Nov 6, 2013 at 5:40 AM, zongchun...@freescale.com wrote: From: Zongchun Yu zongchun...@freescale.com *mv tcpdump from meta-oe to meta-networking *add tcpreplay - a suite of GPLv3 licensed tools for UNIX operating systems which gives you the ability to use previously captured traffic in libpcap format to test a variety of network devices. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-networking][PATCH] crda: correct QA issues with sbindir
regdbdump and crda are installed in /sbin/ and still link against stuff in
/usr/lib, causing QA warnings / errors:
WARNING: QA Issue: crda: /sbin/regdbdump, installed in the base_prefix,
requires a shared library under exec_prefix (/usr): libgcrypt.so.11 =
/usr/lib64/libgcrypt.so.11 (0xdead1000)
WARNING: QA Issue: crda: /sbin/regdbdump, installed in the base_prefix,
requires a shared library under exec_prefix (/usr): libgpg-error.so.0 =
/usr/lib64/libgpg-error.so.0 (0xdead3000)
WARNING: QA Issue: crda: /sbin/crda, installed in the base_prefix, requires
a shared library under exec_prefix (/usr): libgcrypt.so.11 =
/usr/lib64/libgcrypt.so.11 (0xdead1000)
WARNING: QA Issue: crda: /sbin/crda, installed in the base_prefix, requires
a shared library under exec_prefix (/usr): libnl-genl-3.so.200 =
/usr/lib64/libnl-genl-3.so.200 (0xdead2000)
WARNING: QA Issue: crda: /sbin/crda, installed in the base_prefix, requires
a shared library under exec_prefix (/usr): libnl-3.so.200 =
/usr/lib64/libnl-3.so.200 (0xdead3000)
WARNING: QA Issue: crda: /sbin/crda, installed in the base_prefix, requires
a shared library under exec_prefix (/usr): libnl-nf-3.so.200 =
/usr/lib64/libnl-nf-3.so.200 (0xdead4000)
WARNING: QA Issue: crda: /sbin/crda, installed in the base_prefix, requires
a shared library under exec_prefix (/usr): libnl-route-3.so.200 =
/usr/lib64/libnl-route-3.so.200 (0xdead5000)
WARNING: QA Issue: crda: /sbin/crda, installed in the base_prefix, requires
a shared library under exec_prefix (/usr): libgpg-error.so.0 =
/usr/lib64/libgpg-error.so.0 (0xdead7000)
relocate them to /usr/sbin to squelch the warning.
Signed-off-by: Joe MacDonald j...@deserted.net
---
The other obvious solution would be to mve these libraries into ${base_libdir}
but that really doesn't seem appropriate in this case.
meta-networking/recipes-connectivity/crda/crda_1.1.3.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-networking/recipes-connectivity/crda/crda_1.1.3.bb
b/meta-networking/recipes-connectivity/crda/crda_1.1.3.bb
index 3ef9210..8339893 100644
--- a/meta-networking/recipes-connectivity/crda/crda_1.1.3.bb
+++ b/meta-networking/recipes-connectivity/crda/crda_1.1.3.bb
@@ -24,7 +24,7 @@ do_compile() {
}
do_install() {
-oe_runmake install
+oe_runmake SBINDIR=${sbindir} install
install -d ${D}${libdir}/crda/
--
1.7.10.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH 2/2] libopus: upgrade to version 1.0.3
Signed-off-by: Carlos Rafael Giani d...@pseudoterminal.org
---
.../libopus/{libopus_0.9.14.bb = libopus_1.0.3.bb} | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
rename meta-oe/recipes-multimedia/libopus/{libopus_0.9.14.bb =
libopus_1.0.3.bb} (72%)
diff --git a/meta-oe/recipes-multimedia/libopus/libopus_0.9.14.bb
b/meta-oe/recipes-multimedia/libopus/libopus_1.0.3.bb
similarity index 72%
rename from meta-oe/recipes-multimedia/libopus/libopus_0.9.14.bb
rename to meta-oe/recipes-multimedia/libopus/libopus_1.0.3.bb
index 7eb9779..1889775 100644
--- a/meta-oe/recipes-multimedia/libopus/libopus_0.9.14.bb
+++ b/meta-oe/recipes-multimedia/libopus/libopus_1.0.3.bb
@@ -6,11 +6,11 @@ technology from Skype's SILK codec and Xiph.Org's CELT codec.
HOMEPAGE = http://www.opus-codec.org/;
SECTION = libs/multimedia
LICENSE = BSD
-LIC_FILES_CHKSUM = file://COPYING;md5=6d9f9b3714db6bbcfb6e42170d9c664d
+LIC_FILES_CHKSUM = file://COPYING;md5=225b2f817ea798b7c705fe1214694891
SRC_URI = http://downloads.xiph.org/releases/opus/opus-${PV}.tar.gz;
-SRC_URI[md5sum] = c7161b247a8437ae6b0f11dd872e69e8
-SRC_URI[sha256sum] =
b1cad6846a8f819a141009fe3f8f10c946e8eff7e9c2339cd517bb136cc59eae
+SRC_URI[md5sum] = 86eedbd3c5a0171d2437850435e6edff
+SRC_URI[sha256sum] =
191a089c92dbc403de6980463dd3604b65beb12d283c607e246c8076363cb49c
S = ${WORKDIR}/opus-${PV}
--
1.8.3.2
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH 1/2] htop: upgrade to version 1.0.2
Signed-off-by: Carlos Rafael Giani d...@pseudoterminal.org
---
meta-oe/recipes-support/htop/{htop_0.9.bb = htop_1.0.2.bb} | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
rename meta-oe/recipes-support/htop/{htop_0.9.bb = htop_1.0.2.bb} (55%)
diff --git a/meta-oe/recipes-support/htop/htop_0.9.bb
b/meta-oe/recipes-support/htop/htop_1.0.2.bb
similarity index 55%
rename from meta-oe/recipes-support/htop/htop_0.9.bb
rename to meta-oe/recipes-support/htop/htop_1.0.2.bb
index 6d12d72..3982f66 100644
--- a/meta-oe/recipes-support/htop/htop_0.9.bb
+++ b/meta-oe/recipes-support/htop/htop_1.0.2.bb
@@ -8,15 +8,12 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=c312653532e8e669f30e5ec8bdc23be3
DEPENDS = ncurses
RDEPENDS_${PN} = ncurses-terminfo
-PR = r1
-
-SRC_URI = ${SOURCEFORGE_MIRROR}/htop/htop-${PV}.tar.gz \
- file://remove-proc-test.patch
+SRC_URI = ${SOURCEFORGE_MIRROR}/htop/htop-${PV}.tar.gz
LDFLAGS_append_libc-uclibc = -lubacktrace
inherit autotools
-SRC_URI[md5sum] = 7c5507f35f363f3f40183a2ba3c561f8
-SRC_URI[sha256sum] =
4de65c38e1886bccd30ed692b30eb9bf195240680781bfe1eaf5faf84ee6fbfd
+SRC_URI[md5sum] = 0d01cca8df3349c74569cefebbd9919e
+SRC_URI[sha256sum] =
ee60657b044ece0df096c053060df7abf3cce3a568ab34d260049e6a37ccd8a1
--
1.8.3.2
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Create meta-sdr
On Wed, Nov 6, 2013 at 4:37 PM, Philip Balister phi...@balister.org wrote: On 11/05/2013 03:23 PM, Philip Balister wrote: Based on earlier discussion, we'd like to go ahead and create meta-ssdr based on this branch: https://github.com/balister/meta-oe/commits/meta-sdr Can someone give me a hand getting this setup in git? Or should I take this silence to suggest I should just host this on github? Personally I like github; I can host it in our code.ossystems.com.br if you want as well. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.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
Re: [oe] [PATCH meta-networking] quagga: backport a patch from 0.99.22 to fix no ip address command
Merged, thanks.
-J.
[[oe] [PATCH meta-networking] quagga: backport a patch from 0.99.22 to fix no
ip address command] On 13.11.04 (Mon 11:31) rongqing...@windriver.com wrote:
From: Roy Li rongqing...@windriver.com
Signed-off-by: Roy Li rongqing...@windriver.com
---
...ingering-IP-address-after-deletion-BZ-486.patch | 64
.../recipes-protocols/quagga/quagga_0.99.21.bb |3 +-
2 files changed, 66 insertions(+), 1 deletion(-)
create mode 100644
meta-networking/recipes-protocols/quagga/files/lingering-IP-address-after-deletion-BZ-486.patch
diff --git
a/meta-networking/recipes-protocols/quagga/files/lingering-IP-address-after-deletion-BZ-486.patch
b/meta-networking/recipes-protocols/quagga/files/lingering-IP-address-after-deletion-BZ-486.patch
new file mode 100644
index 000..42bdc20
--- /dev/null
+++
b/meta-networking/recipes-protocols/quagga/files/lingering-IP-address-after-deletion-BZ-486.patch
@@ -0,0 +1,64 @@
+From 7f062c217b262e362a3362c677dea6c5e820adf1 Mon Sep 17 00:00:00 2001
+From: David Lamparter equi...@diac24.net
+Date: Mon, 1 Feb 2010 16:41:26 +0100
+Subject: [PATCH] zebra: lingering IP address after deletion (BZ#486)
+
+Upstream-status: Backport
+
+zebra address bookkeeping is a mess. this is just a workaround to have
+IPv4 address deletion somewhat working on Linux.
+
+the if_unset_prefix call is synchronous, when it returns success the
+address deletion completed successfully. this is either signaled by a
+netlink ACK or by an OK return value from ioctl().
+
+This version is wrapped by #ifdef HAVE_NETLINK so we don't touch the
+BSDs for now.
+
+* zebra/interface.c: On Linux, update zebra internal state after
+ deleting an address.
+
+Signed-off-by: David Lamparter equi...@opensourcerouting.org
+---
+ zebra/interface.c | 21 ++---
+ 1 file changed, 18 insertions(+), 3 deletions(-)
+
+diff --git a/zebra/interface.c b/zebra/interface.c
+index 2242259..3578b79 100644
+--- a/zebra/interface.c
b/zebra/interface.c
+@@ -1297,13 +1297,28 @@ ip_address_uninstall (struct vty *vty, struct
interface *ifp,
+safe_strerror(errno), VTY_NEWLINE);
+ return CMD_WARNING;
+ }
++ /* success! call returned that the address deletion went through.
++ * this is a synchronous operation, so we know it succeeded and can
++ * now update all internal state. */
++
++ /* the HAVE_NETLINK check is only here because, on BSD, although the
++ * call above is still synchronous, we get a second confirmation later
++ * through the route socket, and we don't want to touch that behaviour
++ * for now. It should work without the #ifdef, but why take the risk...
++ * -- equinox 2012-07-13 */
++#ifdef HAVE_NETLINK
++
++ /* Remove connected route. */
++ connected_down_ipv4 (ifp, ifc);
+
+-#if 0
+ /* Redistribute this information. */
+ zebra_interface_address_delete_update (ifp, ifc);
+
+- /* Remove connected route. */
+- connected_down_ipv4 (ifp, ifc);
++ /* IP address propery set. */
++ UNSET_FLAG (ifc-conf, ZEBRA_IFC_REAL);
++
++ /* remove from interface, remark secondaries */
++ if_subnet_delete (ifp, ifc);
+
+ /* Free address information. */
+ listnode_delete (ifp-connected, ifc);
+--
+1.7.10.4
+
diff --git a/meta-networking/recipes-protocols/quagga/quagga_0.99.21.bb
b/meta-networking/recipes-protocols/quagga/quagga_0.99.21.bb
index 2b46930..10740bc 100644
--- a/meta-networking/recipes-protocols/quagga/quagga_0.99.21.bb
+++ b/meta-networking/recipes-protocols/quagga/quagga_0.99.21.bb
@@ -2,7 +2,8 @@ require quagga.inc
PR = ${INC_PR}.0
-SRC_URI += file://0001-doc-fix-makeinfo-errors-and-one-warning.patch
+SRC_URI += file://0001-doc-fix-makeinfo-errors-and-one-warning.patch \
+file://lingering-IP-address-after-deletion-BZ-486.patch
SRC_URI[quagga-0.99.21.md5sum] = 99840adbe57047c90dfba6b6ed9aec7f
SRC_URI[quagga-0.99.21.sha256sum] =
9b8aea9026b4771a28e254a66cbd854723bcd0d71eebd0201d11838d4eb392ee
--
-Joe MacDonald.
:wq
signature.asc
Description: Digital signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH 0/2]: meta-virtualization derived updates
Merged, thanks. -J. [[meta-networking][PATCH 0/2]: meta-virtualization derived updates] On 13.11.04 (Mon 00:49) Bruce Ashfield wrote: Joe, Here are a couple of changes that I've pulled out of the various layers that I've been testing and looking after. One is an uprev to dnsmasq to 2.63, and the other is a recipe from meta-virtualization that is a better fit in meta-networking. I tweaked both the recipes slightly as part of updating them for submission to meta-networking, and documented the tweaks in the patches themselves. Anyway, have a look, and let me know what additional changes you'd like made to the recipes. Cheers, Bruce Bruce Ashfield (2): dnsmasq: uprev to 2.6.3 netcf: move from meta-virtualization to meta-networking .../recipes-support/dnsmasq/dnsmasq.inc| 8 +++ .../recipes-support/dnsmasq/dnsmasq_2.55.bb| 6 -- .../recipes-support/dnsmasq/dnsmasq_2.63.bb| 4 meta-networking/recipes-support/netcf/netcf_git.bb | 25 ++ 4 files changed, 37 insertions(+), 6 deletions(-) delete mode 100644 meta-networking/recipes-support/dnsmasq/dnsmasq_2.55.bb create mode 100644 meta-networking/recipes-support/dnsmasq/dnsmasq_2.63.bb create mode 100644 meta-networking/recipes-support/netcf/netcf_git.bb -- -Joe MacDonald. :wq signature.asc Description: Digital signature ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH v3 1/3] snort: add recipe
Just FYI. This and the other two are in the queue, I'll look at them later today or tomorrow at the latest. I just didn't want you to be concerned something was lost. -J. [[oe] [meta-networking][PATCH v3 1/3] snort: add recipe] On 13.11.04 (Mon 10:39) b40...@freescale.com wrote: From: Chunrong Guo b40...@freescale.com *snort - a free lightweight network intrusion detection system for UNIX and Windows Signed-off-by: Chunrong Guo b40...@freescale.com --- .../snort/files/disable-dap-address-space-id.patch | 52 + .../snort/files/disable-inaddr-none.patch | 75 ++ .../recipes-connectivity/snort/files/snort.init| 109 .../recipes-connectivity/snort/snort_2.9.4.6.bb| 71 + 4 files changed, 307 insertions(+), 0 deletions(-) create mode 100644 meta-networking/recipes-connectivity/snort/files/disable-dap-address-space-id.patch create mode 100644 meta-networking/recipes-connectivity/snort/files/disable-inaddr-none.patch create mode 100644 meta-networking/recipes-connectivity/snort/files/snort.init create mode 100644 meta-networking/recipes-connectivity/snort/snort_2.9.4.6.bb diff --git a/meta-networking/recipes-connectivity/snort/files/disable-dap-address-space-id.patch b/meta-networking/recipes-connectivity/snort/files/disable-dap-address-space-id.patch new file mode 100644 index 000..39e5c9c --- /dev/null +++ b/meta-networking/recipes-connectivity/snort/files/disable-dap-address-space-id.patch @@ -0,0 +1,52 @@ +Upstream-Status:Inappropriate [embedded specific] + +fix the below error: +checking for dap address space id... configure: +configure: error: cannot run test program while cross compiling + + +Signed-off-by: Chunrong Guo b40...@freescale.com + +--- a/configure.in 2013-08-23 00:06:37.239361932 -0500 b/configure.in 2013-08-23 00:07:32.860266534 -0500 +@@ -679,23 +679,23 @@ + + AC_CHECK_FUNCS([daq_hup_apply] [daq_acquire_with_meta]) + +-AC_MSG_CHECKING([for daq address space ID]) +-AC_RUN_IFELSE( +-[AC_LANG_PROGRAM( +-[[ +-#include daq.h +-]], +-[[ +- DAQ_PktHdr_t hdr; +- hdr.address_space_id = 0; +-]])], +-[have_daq_address_space_id=yes], +-[have_daq_address_space_id=no]) +-AC_MSG_RESULT($have_daq_address_space_id) +-if test x$have_daq_address_space_id = xyes; then +-AC_DEFINE([HAVE_DAQ_ADDRESS_SPACE_ID],[1], +-[DAQ version supports address space ID in header.]) +-fi ++#AC_MSG_CHECKING([for daq address space ID]) ++#AC_RUN_IFELSE( ++#[AC_LANG_PROGRAM( ++#[[ ++##include daq.h ++#]], ++#[[ ++# DAQ_PktHdr_t hdr; ++# hdr.address_space_id = 0; ++#]])], ++have_daq_address_space_id=yes ++#[have_daq_address_space_id=no]) ++#AC_MSG_RESULT($have_daq_address_space_id) ++#if test x$have_daq_address_space_id = xyes; then ++#AC_DEFINE([HAVE_DAQ_ADDRESS_SPACE_ID],[1], ++#[DAQ version supports address space ID in header.]) ++#fi + + # any sparc platform has to have this one defined. + AC_MSG_CHECKING(for sparc) diff --git a/meta-networking/recipes-connectivity/snort/files/disable-inaddr-none.patch b/meta-networking/recipes-connectivity/snort/files/disable-inaddr-none.patch new file mode 100644 index 000..9dafe63 --- /dev/null +++ b/meta-networking/recipes-connectivity/snort/files/disable-inaddr-none.patch @@ -0,0 +1,75 @@ +Upstream-Status: Inappropriate [embedded specific] + +fix the below error: +checking for INADDR_NONE... configure: +configure: error: cannot run test program while cross compiling + +Signed-off-by: Chunrong Guo b40...@freescale.com + + +--- a/configure.in 2013-08-21 03:56:17.197414789 -0500 b/configure.in 2013-08-21 23:19:05.298553560 -0500 +@@ -281,25 +281,7 @@ + AC_CHECK_TYPES([boolean]) + + # In case INADDR_NONE is not defined (like on Solaris) +-have_inaddr_none=no +-AC_MSG_CHECKING([for INADDR_NONE]) +-AC_RUN_IFELSE( +-[AC_LANG_PROGRAM( +-[[ +-#include sys/types.h +-#include netinet/in.h +-#include arpa/inet.h +-]], +-[[ +-if (inet_addr(10,5,2) == INADDR_NONE); +-return 0; +-]])], +-[have_inaddr_none=yes], +-[have_inaddr_none=no]) +-AC_MSG_RESULT($have_inaddr_none) +-if test x$have_inaddr_none = xno; then +-AC_DEFINE([INADDR_NONE],[-1],[For INADDR_NONE definition]) +-fi ++have_inaddr_none=yes + + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[ + #include stdio.h +@@ -397,21 +379,21 @@ + fi + fi + +-AC_MSG_CHECKING([for pcap_lex_destroy]) +-AC_RUN_IFELSE( +-[AC_LANG_PROGRAM( +-[[ +-#include pcap.h +-]], +-[[ +- pcap_lex_destroy(); +-]])], +-[have_pcap_lex_destroy=yes], +-[have_pcap_lex_destroy=no]) +-AC_MSG_RESULT($have_pcap_lex_destroy) +-if test x$have_pcap_lex_destroy = xyes; then +-AC_DEFINE([HAVE_PCAP_LEX_DESTROY],[1],[Can cleanup lex buffer stack created by pcap bpf filter]) +-fi ++#AC_MSG_CHECKING([for pcap_lex_destroy]) ++#AC_RUN_IFELSE(
[oe] [meta-oe][PATCH] orc: version 0.4.18 migrated to oe-core
Signed-off-by: Carlos Rafael Giani d...@pseudoterminal.org
---
meta-oe/recipes-devtools/orc/orc.inc | 25 -
meta-oe/recipes-devtools/orc/orc_0.4.18.bb | 6 --
2 files changed, 31 deletions(-)
delete mode 100644 meta-oe/recipes-devtools/orc/orc.inc
delete mode 100644 meta-oe/recipes-devtools/orc/orc_0.4.18.bb
diff --git a/meta-oe/recipes-devtools/orc/orc.inc
b/meta-oe/recipes-devtools/orc/orc.inc
deleted file mode 100644
index 4a356e4..000
--- a/meta-oe/recipes-devtools/orc/orc.inc
+++ /dev/null
@@ -1,25 +0,0 @@
-DESCRIPTION = orc - The Oil Runtime Compiler
-HOMEPAGE = http://code.entropywave.com/projects/orc/;
-LICENSE = orc
-LIC_FILES_CHKSUM = file://COPYING;md5=1400bd9d09e8af56b9ec982b3d85797e
-
-INC_PR = r1
-
-SRC_URI = http://code.entropywave.com/download/orc/orc-${PV}.tar.gz;name=orc;
-
-inherit autotools pkgconfig
-
-BBCLASSEXTEND = native nativesdk
-
-PACKAGES =+ orc-examples
-FILES_orc-examples = ${libdir}/orc/*
-FILES_${PN} = ${bindir}/*
-
-python populate_packages_prepend () {
-libdir = d.expand('${libdir}')
-do_split_packages(d, libdir, '^lib(.*)\.so\.*', 'lib%s', 'ORC %s library',
extra_depends='', allow_links=True)
-}
-
-do_compile_prepend_virtclass-native () {
-sed -i -e 's#/tmp#.#g' ${S}/orc/orccodemem.c
-}
diff --git a/meta-oe/recipes-devtools/orc/orc_0.4.18.bb
b/meta-oe/recipes-devtools/orc/orc_0.4.18.bb
deleted file mode 100644
index 2375d8c..000
--- a/meta-oe/recipes-devtools/orc/orc_0.4.18.bb
+++ /dev/null
@@ -1,6 +0,0 @@
-require orc.inc
-
-PR = ${INC_PR}.0
-
-SRC_URI[orc.md5sum] = 1a2552e8d127526c48d644fe6437b377
-SRC_URI[orc.sha256sum] =
34d3c8a7259f42bed4dcfbc106c5e3d0cc8e17eeaa73128d1c5eaf92883a6a24
--
1.8.4.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 0/1] accel-ppp: fix qa issue 'found library in wrong location' while multilib enabled on qemux86-64
The following changes since commit ffb5434823195cbdc41c76a110eaa6ae04e2b010: dnsmasq: uprev to 2.6.3 (2013-11-06 15:12:45 -0500) are available in the git repository at: git://git.pokylinux.org/poky-contrib hongxu/fix-accel-ppp http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/fix-accel-ppp Hongxu Jia (1): accel-ppp: fix qa issue 'found library in wrong location' while multilib enabled on qemux86-64 meta-networking/recipes-protocols/accel-ppp/accel-ppp_git.bb | 9 + 1 file changed, 9 insertions(+) -- 1.8.1.2 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH 1/1] accel-ppp: fix qa issue 'found library in wrong location' while multilib enabled on qemux86-64
While multilib enabled on qemux86-64, accel-ppp-lib should be installed to
'${baselib}/accel-ppp', but the accel-ppp's CMakeLists.txt hardcoded
to install to 'lib/accel-ppp', such as:
...
INSTALL(TARGETS log_file
LIBRARY DESTINATION lib/accel-ppp
)
...
Signed-off-by: Hongxu Jia hongxu@windriver.com
---
meta-networking/recipes-protocols/accel-ppp/accel-ppp_git.bb | 9 +
1 file changed, 9 insertions(+)
diff --git a/meta-networking/recipes-protocols/accel-ppp/accel-ppp_git.bb
b/meta-networking/recipes-protocols/accel-ppp/accel-ppp_git.bb
index a7c10f7..dde1f43 100644
--- a/meta-networking/recipes-protocols/accel-ppp/accel-ppp_git.bb
+++ b/meta-networking/recipes-protocols/accel-ppp/accel-ppp_git.bb
@@ -30,3 +30,12 @@ PACKAGES =+ ${PN}-libs
FILES_${PN}-libs = ${libdir}/${BPN}/*.so /usr/lib/${BPN}/*.so
INSANE_SKIP_${PN}-libs = dev-so
RDEPENDS_${PN} += ${PN}-libs
+
+do_install_prepend() {
+cmlist=`find ${S} -name CMakeLists.txt`
+for file in $cmlist; do
+sed -i -e s:LIBRARY DESTINATION lib/accel-ppp:LIBRARY DESTINATION
${baselib}/accel-ppp:g \
+ -e
s:\${CMAKE_INSTALL_PREFIX}/lib/accel-ppp:\${CMAKE_INSTALL_PREFIX}/${baselib}/accel-ppp:g
\
+ $cmlist
+done
+}
--
1.8.1.2
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH] tcpdump, tcpreplay:relocate tcpdump and add tcpreplay recipe
Please use -M to get smaller diff. Hello Martin. Thanks for your reminder. I have send one new patch to you and the mail list. But I don’t know why the patch is rejected by the mail list? It is ok before. If you have suggestion. Please reply to me directly. Best Regards Zongchun ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
