[oe] [meta-systemd][PATCH] dropbear: Rename bbappend to match new version from oe-core
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
.../dropbear/{dropbear_2013.58.bbappend = dropbear_2013.60.bbappend} | 2 --
1 file changed, 2 deletions(-)
rename meta-systemd/oe-core/recipes-core/dropbear/{dropbear_2013.58.bbappend
= dropbear_2013.60.bbappend} (95%)
diff --git
a/meta-systemd/oe-core/recipes-core/dropbear/dropbear_2013.58.bbappend
b/meta-systemd/oe-core/recipes-core/dropbear/dropbear_2013.60.bbappend
similarity index 95%
rename from meta-systemd/oe-core/recipes-core/dropbear/dropbear_2013.58.bbappend
rename to meta-systemd/oe-core/recipes-core/dropbear/dropbear_2013.60.bbappend
index edaa66e..fc18ea8 100644
--- a/meta-systemd/oe-core/recipes-core/dropbear/dropbear_2013.58.bbappend
+++ b/meta-systemd/oe-core/recipes-core/dropbear/dropbear_2013.60.bbappend
@@ -1,7 +1,5 @@
inherit systemd
-PRINC := ${@int(PRINC) + 4}
-
# look for files in the layer first
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
--
1.8.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH meta-networking v2] lowpan-tools: configure python files installation path
From: Roy Li rongqing...@windriver.com
configure python files installation path or else it will use the
default value /usr/lib/python*, which is wrong on 64bit and multilibs
enabled system
Signed-off-by: Roy Li rongqing...@windriver.com
---
meta-networking/recipes-support/lowpan-tools/lowpan-tools_git.bb |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta-networking/recipes-support/lowpan-tools/lowpan-tools_git.bb
b/meta-networking/recipes-support/lowpan-tools/lowpan-tools_git.bb
index cf78b45..152ee49 100644
--- a/meta-networking/recipes-support/lowpan-tools/lowpan-tools_git.bb
+++ b/meta-networking/recipes-support/lowpan-tools/lowpan-tools_git.bb
@@ -13,7 +13,9 @@ SRCREV = a1d9615adde6d1a568813c24a128273ed755af04
S = ${WORKDIR}/git
-inherit autotools
+inherit autotools python-dir
+
+CACHED_CONFIGUREVARS +=
am_cv_python_pythondir=${PYTHON_SITEPACKAGES_DIR}/lowpan-tools
do_install_append() {
rmdir ${D}${localstatedir}/run
--
1.7.10.4
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-networking][PATCH v2 1/3] snort : add recipe
pings -Original Message- From: Guo Chunrong-B40290 Sent: Friday, October 18, 2013 4:22 PM To: openembedded-devel@lists.openembedded.org Cc: Liu Ting-B28495; Luo Zhenhua-B19537; Guo Chunrong-B40290 Subject: [meta-networking][PATCH v2 1/3] snort : add recipe 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/snort_2.9.4.6.bb| 64 + 3 files changed, 191 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/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-addre +++ ss-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-no +++ ne.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( ++#[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
Re: [oe] [OE] [PATCH meta-networking] quagga/ripd: Fix two bugs after received SIGHUP signal
On 10/25/2013 09:31 PM, Joe MacDonald wrote: [Re: [oe] [OE] [PATCH meta-networking] quagga/ripd: Fix two bugs after received SIGHUP signal] On 13.10.25 (Fri 09:47) Xufeng Zhang wrote: On 10/25/2013 01:44 AM, Joe MacDonald wrote: [[oe] [OE] [PATCH meta-networking] quagga/ripd: Fix two bugs after received SIGHUP signal] On 13.10.24 (Thu 17:48) Xufeng Zhang wrote: There are two problems for ripd implementation after received SIGHUP signal: 1). ripd didn't clean up ifp-connected list before reload configuration file which makes the same advertise packet being sent multiple times(depends on how many SIGHUP was recieved). 2). ripd reset ri-split_horizon flag to RIP_NO_SPLIT_HORIZON during restart which is different from the flag when ripd is firstly started up, leading to unnecessary route to be advertised. [YOCTO #5266] Hey Xufeng, Normally I wouldn't go this deep into the detail but since you referenced the Yocto bug and the Quagga discussion in the commit log and the bug itself, I thought I'd try to understand what's going on here. The last thing I saw from the Quagga maintainer is this: The ifp-connected list contains connected prefixes of a given interface. These exist regardless of particular routing protocols and emptying the list during ripd reconfiguration would be plain wrong. I allow for a chance there is a bug that is related to ifp-connected and SIGHUP handling at once, but not in this specific way. What he said is that this ifp-connected list is exist in all routing protocols, and if it needs cleanup, it should be done in a more general way, such as in zebra client which is independent of routing protocol. I'm not sure that's the interpretation I would have taken from the quoted text, but if what you indicate is what the maintainer meant, then is he not saying that the SIGHUP handling issue also exists for other routing daemons in the suite? quoted the sentence: The ifp-connected list contains connected prefixes of a given interface. These exist regardless of particular routing protocols and emptying the list during ripd reconfiguration would be plain wrong. All the other daemons also refer to the ifp-connected list, and I have checked the SIGHUP handler code of all daemons, except ospfd and ospf6d(they only print a log when SIGHUP is received), all the other daemons suffer the same problem as ripd since they reload the configuration file. Are you saying a similar patch would then be required for potentially all daemons in quagga? Not all. Don't get me wrong, repairing one is better than repairing none, but on my first read of his comments it didn't seem like the maintainer even agreed that there was a bug at all and your interpretation suggests that the same bug likely impacts all quagga daemons. Any sense on whether that's the case? I allow for a chance there is a bug that is related to ifp-connected and SIGHUP handling at once, but not in this specific way. My understanding is that if there is a bug related to ifp-connected, we should not fix in such specific way. Yes, the maintainer didn't agree that there is really a bug here, but this is really a abnormal behavior: every time when SIGHUP is received, the same address is appended to ifp-connected list over and over again, so if too much SIGHUP are received, there will be a flood for the advertised packets. Thanks, Xufeng -J. But I have specified the reasons in the above email that why it's not easy to implement this general way: # More comments: Generally this connected interface address stuff is cleaned up in rip_interface_address_delete() which is triggered by zsend_interface_address(), but just as the annotation said above zsend_interface_address() function in zebra/zserv.c, ZEBRA_INTERFACE_ADDRESS_DELETE message could only happens in two cases: 1). ip address uninstall 2). RTM_NEWADDR on routing/netlink socket It didn't take the SIGHUP signal into consideration, but since the SIGHUP is handled by every daemon independently, this cleanup is not easy to be implemented commonly, so I think this is a proper way to do this. # So it needs to redesign a lot of stuff to implement this. and it looks like the patch here is the same as the one that the maintainer indicated is plain wrong. Can you help me get some confidence that this isn't going to have negative side-effects if we integrate it? Yes, there should be no side-effects: 1. This modification is only going into ripd daemon and it only takes effect when ripd is restarting. 2. The fix for problem 1). just remove the previously connected addresses of the interface, and these connected addresses list will be reconstructed when ripd read the configuration during restarting. 3. The fix for problem 2). definitely has not any side-effect because I just
