Bug 230007 - net/ceph: fix missing cmake options
Summary: net/ceph: fix missing cmake options
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Steve Wills
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-24 09:06 UTC by Willem Jan Withagen
Modified: 2018-07-24 16:04 UTC (History)
1 user (show)

See Also:


Attachments
svn diff of Makefile (1.49 KB, patch)
2018-07-24 09:06 UTC, Willem Jan Withagen
no flags Details | Diff
Only fix the Cmake options. (983 bytes, patch)
2018-07-24 11:42 UTC, Willem Jan Withagen
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Willem Jan Withagen 2018-07-24 09:06:07 UTC
Created attachment 195414 [details]
svn diff of Makefile

Building net/ceph is broken...
One way or another not all Cmake options made it into the release.
Comment 1 Jan Beich freebsd_committer freebsd_triage 2018-07-24 11:35:40 UTC
Comment on attachment 195414 [details]
svn diff of Makefile

>Index: Makefile
>===================================================================
>--- Makefile	(revision 475174)
>+++ Makefile	(working copy)
>@@ -19,7 +19,7 @@
> BUILD_DEPENDS=	\
> 	yasm:devel/yasm \
> 	pkgconf:devel/pkgconf \
>-	sphinx-build:textproc/py-sphinx \
>+	sphinx-build:textproc/py-sphinx@${PY_FLAVOR} \
> 	gperf:devel/gperf \
> 	${LOCALBASE}/lib/libatomic_ops.a:devel/libatomic_ops
> LIB_DEPENDS=	\
>@@ -41,7 +41,7 @@
> 	xml:textproc/xmlstarlet \
> 	jq:textproc/jq \
> 	flock:sysutils/flock \
>-	virtualenv:devel/py-virtualenv \
>+	virtualenv:devel/py-virtualenv@${PY_FLAVOR} \

See bug 227260. If you use ${PY_FLAVOR} then unversioned sphinx-build/virtualenv may not be installed thus breaking build.
Comment 2 Willem Jan Withagen 2018-07-24 11:41:43 UTC
(In reply to Jan Beich from comment #1)

Arrrg, sorry about that.
Must be heat around here.
We had the same discussion before, and you fixed it.
I explicitly edited that part out, but then still uploaded the wrong diff.

Will upload the correct one.
Comment 3 Willem Jan Withagen 2018-07-24 11:42:32 UTC
Created attachment 195416 [details]
Only fix the Cmake options.
Comment 4 Jan Beich freebsd_committer freebsd_triage 2018-07-24 11:44:20 UTC
Curiously, when landing bug 229877 it built fine on 12.0-CURRENT amd64 - https://ptpb.pw/hBUF

In file included from src/msg/async/Stack.cc:22:
src/msg/async/rdma/RDMAStack.h:20:10: fatal error: 'sys/eventfd.h' file not found
#include <sys/eventfd.h>
         ^~~~~~~~~~~~~~~
1 error generated.

http://www.ipv6proxy.net/go.php?u=http://beefy12.nyi.freebsd.org/data/head-amd64-default/p475044_s336572/logs/ceph-12.2.7.log
Comment 5 Willem Jan Withagen 2018-07-24 11:51:45 UTC
(In reply to Jan Beich from comment #4)

Yup, I had the same problem....

Poudriere here just gave an A-OKE, so I submitted, even though it was incomplete.
I have to copy my files around, because Jenkins runs on another jail as where I do the package building. And then I tend to fumble things.

But we do not do RDMA with Ceph on FreeBSD. And to make matters even more complex, the CMake var that excludes that code has had already 3 different names....
And then there is code in ./cmake/modules/Findrdmacm.cmake that tries to autodetect stuff. So if for any reason WITH_RDMA is not set, but this Find triggers: RDMA gets included. And that'll give an error.

So the correct options should be set.... (and included in the Makefile)
Comment 6 commit-hook freebsd_committer freebsd_triage 2018-07-24 15:30:26 UTC
A commit references this bug:

Author: swills
Date: Tue Jul 24 15:30:17 UTC 2018
New revision: 475261
URL: https://svnweb.freebsd.org/changeset/ports/475261

Log:
  net/ceph: fix missing cmake options

  PR:		230007
  Submitted by:	Willem Jan Withagen <wjw@digiware.nl> (maintainer)

Changes:
  head/net/ceph/Makefile
Comment 7 Steve Wills freebsd_committer freebsd_triage 2018-07-24 15:31:32 UTC
Committed, thanks!
Comment 8 Willem Jan Withagen 2018-07-24 16:04:56 UTC
(In reply to Steve Wills from comment #7)

Thanx for picking this up.
Let's see what package builder thinks of it this time.