On 01/05/2018 12:20 PM, Mark Asselstine wrote:
On Friday, January 5, 2018 3:17:27 PM EST Cal Sullivan wrote:
This sounds like the right way to go to me.
In the interim, should I take these patches in order to unblock the
conflict and the multilib issue?
Yes, this would help.
Mark
Merged.
Thanks,
Cal
Thanks,
Cal
On 01/04/2018 07:24 AM, Mark Asselstine wrote:
On Wednesday, January 3, 2018 2:02:31 PM EST Cal Sullivan wrote:
In actually testing this patch, I noticed that I was getting a fetcher
warning. After a little investigation I found that
https://github.com/Mellanox/dpdk-dev-libibverbs no longer exists and
we're only getting this thanks to the YP mirroring. Do you know of any
other location we could point to?
Maybe we should actually take this as a signal to revisit things. I am
having to piece things together as some of the history is lost with the
removal of the dpdk-dev-libibverbs repo and newer revisions of Mellanox
DPDK pages but I think we have enough to go on to move forward.
Looking at the history it appears as though dpdk-dev-libibverbs was and
"optimized" version of libibverbs for the ConnectX-3 (reference: https://
community.mellanox.com/docs/DOC-2197). The fact that Mellanox has dropped
the repository and now simply references libibverbs (and not
dpdk-dev-libibverbs) in its latest revision of the Mellanox DPDK
documentation (reference: https:// community.mellanox.com/docs/DOC-1502).
Leads me to believe that we should move on to simply use the latest
release of libibverbs.
So I really think the best solution is to drop dpdk-dev-libibverbs and
simply use libibverbs. This would drop the need to do any of the
'virtual/' do jiggery. We can host the libibverbs recipe here still or
move to oe-core, Bruce can use PREFERRED_VERSION to continue to use the
required version in meta-cloud-services...
Sorry about taking my time in coming to this conclusion. I was short on
time and flush with work before the holiday so didn't dig in enough to
make the right call.
MarkA
Thanks,
Cal
On 01/02/2018 05:27 PM, Chen Qi wrote:
Fix to correctly set SRC_URI and S to avoid do_fetch failure in case of
multilib.
Signed-off-by: Chen Qi <qi.c...@windriver.com>
---
.../dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0.0.0.bb | 8
++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
a/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0
.
0.0.bb
b/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0
.
0.0.bb index e40c63b..9118494 100644
---
a/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0
.
0.0.bb +++
b/recipes-extended/dpdk-dev-libibverbs/dpdk-dev-libibverbs_1.2.1-3.4-2.0
.
0.0.bb @@ -3,7 +3,7 @@ HOMEPAGE =
"https://github.com/Mellanox/dpdk-dev-libibverbs";>
LICENSE = "GPLv2"
LIC_FILES_CHKSUM =
"file://COPYING;md5=7c557f27dd795ba77cc419dddc656b51"
-SRC_URI =
"https://github.com/Mellanox/dpdk-dev-libibverbs/archive/libibverbs-${PV
}
.tar.gz;name=${PN} \ +SRC_URI =
"https://github.com/Mellanox/dpdk-dev-libibverbs/archive/libibverbs-${PV
}
.tar.gz \>
file://init_c.patch \
file://0001-Fix-build-with-clang.patch \
file://0002-typecast-enum-to-int-before-comparison.patch \
@@ -11,8 +11,8 @@ SRC_URI =
"https://github.com/Mellanox/dpdk-dev-libibverbs/archive/libibverbs-${>
file://0004-Fix-clang-warnings.patch \
"
-SRC_URI[dpdk-dev-libibverbs.md5sum] =
"65234ee278eb437a7069326f37cd4d86"
-SRC_URI[dpdk-dev-libibverbs.sha256sum] =
"a6471515556cb8d10ad471bb7efb8cf760b248a28aceb57d4534d50d572f56cd"
+SRC_URI[md5sum] = "65234ee278eb437a7069326f37cd4d86"
+SRC_URI[sha256sum] =
"a6471515556cb8d10ad471bb7efb8cf760b248a28aceb57d4534d50d572f56cd">
# A machine needs to enable this using:
# COMPATIBLE_MACHINE_pn-dpdk-dev-libibverbs = "<machine name>"
@@ -20,7 +20,7 @@ SRC_URI[dpdk-dev-libibverbs.sha256sum] =
"a6471515556cb8d10ad471bb7efb8cf760b248>
COMPATIBLE_MACHINE = "null"
COMPATIBLE_HOST_libc-musl_class-target = "null"
-S = "${WORKDIR}/${PN}-libibverbs-${PV}"
+S = "${WORKDIR}/dpdk-dev-libibverbs-libibverbs-${PV}"
COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
DEPENDS = "libnl"
--
_______________________________________________
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
