Skip to contentSkip to conversation

Bring over change from meta-openembedded

PATCH New Mark Hatle 2 participants 4 messages Sep 6, 2017 – Sep 11, 2017

lore
Share & tools
lore

Mark Hatle

author
#0 lore raw

PATCH 1/1 Bring over change from meta-openembedded

This is the change required for the problem discussed in the email w/ the subject:
iproute2 - meta-openembedded/libmnl and Yocto Project compat

I could find no other way to remedy the Yocto Project compat checker against meta-openembedded without moving this change from there to here. A corresponding patch has been sent to the meta-openembedded mailing list.

Mark Hatle (1):
iproute2: Default to tipc enabled, and include libmnl dependency

 meta/recipes-connectivity/iproute2/iproute2.inc |  2 +-
 meta/recipes-extended/libmnl/libmnl_1.0.4.bb    | 13 +++++++++++++
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-extended/libmnl/libmnl_1.0.4.bb
Signature · 1 line
1.8.3.1
author
#1 lore raw

PATCH 1/1 iproute2: Default to tipc enabled, and include libmnl dependency

iproute2 has the ability to include a tipc tool. When enabled this requires the libmnl package (formerly supplied by meta-openembedded). So both are needed at the same time.

The change itself is needed because of the tipc-utils package (in meta-openembedded) which RDEPENDS on iproute2-tipc. Without this package the yocto-compat-layer script indicates there is no way for me to have meta-openembedded pass the checker. This is because meta-openembedded is not allowed to just enable 'tipc' on it's own. (A layer may not make distro wide changes without a user saying to do it.) The checker script invokes bitbake -S none world, which will fail on dependency resolution due to there being no iproute2-tipc package. The tipc-utils package does not have a way to check the PACKAGECONFIG of the iproute2 package so disable itself if the dependency can not be met. So the default system behavior needs to be:

iproute2 w/ tipc enabled
tipc-utils RDEPENDS on iproute2-tipc

---
 meta/recipes-connectivity/iproute2/iproute2.inc |  2 +-
 meta/recipes-extended/libmnl/libmnl_1.0.4.bb    | 13 +++++++++++++
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-extended/libmnl/libmnl_1.0.4.bb
meta/recipes-connectivity/iproute2/iproute2.inc +1 -1
index 57309b7..a578eb3 100644
@@ -13,7 +13,7 @@ DEPENDS = "flex-native bison-native iptables elfutils"
 
 inherit update-alternatives bash-completion pkgconfig
 
-PACKAGECONFIG ??= ""
+PACKAGECONFIG ??= "tipc"
 PACKAGECONFIG[tipc] = ",,libmnl,"
 
 EXTRA_OEMAKE = "CC='${CC}' KERNEL_INCLUDE=${STAGING_INCDIR} DOCDIR=${docdir}/iproute2 SUBDIRS='lib tc ip bridge misc genl ${@bb.utils.contains('PACKAGECONFIG', 'tipc', 'tipc', '', d)}' SBINDIR='${base_sbindir}' LIBDIR='${libdir}'"
meta/recipes-extended/libmnl/libmnl_1.0.4.bb new file +13 -0
new file mode 100644
index 0000000..b458799
@@ -0,0 +1,13 @@
+SUMMARY = "Minimalistic user-space Netlink utility library"
+DESCRIPTION = "Minimalistic user-space library oriented to Netlink developers, providing \
+    functions for common tasks in parsing, validating, and constructing both the Netlink header and TLVs."
+HOMEPAGE = "http://www.netfilter.org/projects/libmnl/index.html"
+SECTION = "libs"
+LICENSE = "LGPLv2.1+"
+LIC_FILES_CHKSUM = "file://COPYING;md5=4fbd65380cdd255951079008b364516c"
+
+SRC_URI = "http://www.netfilter.org/projects/libmnl/files/libmnl-${PV}.tar.bz2;name=tar"
+SRC_URI[tar.md5sum] = "be9b4b5328c6da1bda565ac5dffadb2d"
+SRC_URI[tar.sha256sum] = "171f89699f286a5854b72b91d06e8f8e3683064c5901fb09d954a9ab6f551f81"
+
+inherit autotools pkgconfig
Signature · 1 line
1.8.3.1
author
#3 lore raw

Re: [PATCH] iproute2: Default to tipc enabled, and include libmnl dependency

Quoted 1 line · Trevor Woerner

https://www.mail-archive.com/[email protected]/msg101002.html

Yes, but I feel this needs to be re-considered. At present we can't pass the Yocto Project compliant test (with meta-openembedded included) without enabling tipc for iproute2. This justification is hopefully enough to conclude moving libmnl into oe-core is 'acceptable risk' at this point in the system.

--Mark