NFD

I have the initial RPM for ndn-cxx since NFD depends on it. However, there are a few issues:

a) The project should provide a source (zip or tar.gz) in the following format - %{name}-%{version}.tar.gz

b) The installation currently writes to /usr/local/bin - for Fedora, they should go to /usr/bin and /usr/lib or /usr/lib64. Will this create any issues for NFD?

a) The project should provide a source (zip or tar.gz) in the following format - %{name}-%{version}.tar.gz

We will not provide tar.gz. You should hack the scripts to clone from git and then create .tar.gz. You can check the example of this I did for PPA packaging: https://github.com/named-data/ppa-packaging/blob/master/packaging.mk#L15 (I had a few iterations of this script)

b) The installation currently writes to /usr/local/bin - for Fedora, they should go to /usr/bin and /usr/lib or /usr/lib64. Will this create any issues for NFD?

This is a deployment choice, there is no impact on NFD or anything. Any library and app can be installed and used anywhere. Just in case, on Ubuntu /usr/bin and /usr/lib is used.

Alex Afanasyev wrote:

a) The project should provide a source (zip or tar.gz) in the following format - %{name}-%{version}.tar.gz

We will not provide tar.gz.

err.. what? do you refer to the specific compressed format (.gz) or you won't provide source code archives at all?

Is %{name}-%{version}.tar.gz a prerequisite for building RPM, or is it a requirement for submission to official repository?

See #1973 about tarball creation.

The tarballs referred in #1973 are expected to be released very infrequently, no frequent than the release. I'm expecting that RPMs should be created on more regular basis (this is based on my experience with PPA repository).

We will not provide tar.gz.
err.. what? do you refer to the specific compressed format (.gz) or you won't provide source code archives at all?

I don't really want to provide archives... Especially, when they can be created locally from git repo when needed (RPM building is one of such cases for me).

We will not provide tar.gz.
err.. what? do you refer to the specific compressed format (.gz) or you won't provide source code archives at all?

I don't really want to provide archives... Especially, when they can be created locally from git repo when needed (RPM building is one of such cases for me).

How do we decide when its time for a new RPM? Minor releases? Major releases? Monthly?

Not providing tar.gz is fine, I can create one locally.

How do we decide when its time for a new RPM? Minor releases? Major releases? Monthly?

This needs to be coordinated. Previously (again, I'm basing on PPA experience), package update was triggered by the need of introducing newly developed features on testbed. We definitely should have RPMs for releases (major and minor), plus any manually triggered intermittent releases when necessary.

Not providing tar.gz is fine, I can create one locally.

good :)

Alex Afanasyev wrote:

The tarballs referred in #1973 are expected to be released very infrequently, no frequent than the release. I'm expecting that RPMs should be created on more regular basis (this is based on my experience with PPA repository).

Oh ok, that's fine then. I was worried about the release tarballs.

@susmit shannigrahi, what distro & version is this RPM designed for?

If Emulab has a template for this distro & version, you should be able to test it on Emulab.

Don't upload binaries here. You can build 32-bit version using virtualbox. You can also define vagrant config to do it semi-automatically (example of such vagrantfile is here http://redmine.named-data.net/issues/2436).

What one supposed to do with this RPM? Can fedora be instructed to have custom repository? How such repository should be organized?

@Junxiao: from rpm name, it is for Fedora 21.

We don't need custom repos. One can put this up on a http server and people can do a

yum install http://path\_to\_rpm

if you don't custom repo, then there is no point of this rpm. the whole benefit from rpm, besides installing binary, is automatic updates. For me, this is a required feature for any binary/packaging system.

The repo is here: http://www.cs.colostate.edu/~susmit/ndn/ndn.repo

It needs to be copied in /etc/yum/repos.d.

Once copied, one should be able to do

#yum install ndn-cxx

I have updated the spec and the rpm for F22.

If there is no objection, I will submit it to Fedora for a review and inclusion to Fedora repo.

Spec file: http://www.cs.colostate.edu/~susmit/ndn/ndn-cxx.spec

RPM: http://www.cs.colostate.edu/~susmit/ndn/ndn-cxx-0.3.3-1.fc22.x86_64.rpm

Repo file: http://www.cs.colostate.edu/~susmit/ndn/ndn.repo

susmit shannigrahi wrote:

Spec file: http://www.cs.colostate.edu/~susmit/ndn/ndn-cxx.spec

I don't think ndn-cxx requires libpcap-devel.

Also, you probably want to build and install the shared library as well (will be the default in the next release).

Also, you probably want to build and install the shared library as well (will be the default in the next release).

Do we need both or just the shared?

I'd say both for now, if it's not a problem. We can drop the static library sometime later.

I would only install the shared library. At least this is what I've done with Ubuntu packages.

Can someone pull the rpms and test them?

https://koji.fedoraproject.org/koji/taskinfo?taskID=11110830

Bugzilla link here: https://bugzilla.redhat.com/show_bug.cgi?id=1255973

Any idea how to fix this?

https://fedoraproject.org/wiki/Common_Rpmlint_issues?rd=PackageMaintainers/Common_Rpmlint_Issues#unused-direct-shlib-dependency

I see the example for libtool, not sure how to handle it in waf.

What library is linked on the command line but not used? (I suspect libssl from openssl? we use only libcrypto afaik)

Package has been approve for 0.3.4. It'll be in most RH repos (Fedora/CentOS) in a week or so.

libndn-cxx is in F23 and F22. I'll package NFD next.

$ dnf search libndn
Last metadata expiration check performed 1:44:07 ago on Fri Nov  6 07:31:03 2015.
============================= N/S Matched: libndn ==============================
libndn-cxx-devel.i686 : Development files for libndn-cxx
libndn-cxx-devel.x86_64 : Development files for libndn-cxx
libndn-cxx.i686 : C++ library implementing Named Data Networking primitives
libndn-cxx.x86_64 : C++ library implementing Named Data Networking primitives

congrats! ;)

Thanks.

NFD can't seem to find websocket headers though they are installed from websocketpp rpm. Any suggestions? I have tried with include=/usr/include and got the same result.

/usr/bin/python2 ./waf -v --prefix=/usr --bindir=/usr/bin --sysconfdir=/etc --includedir=/usr/include/websocketpp/ configure

Output:

[1/1] Compiling build/.conf_check_b8ceb3a699f14874d3562659110c87d9/test.cpp

['/bin/g++', '-pedantic', '-Wall', '-O2', '-g', '-std=c++11', '-I/usr/include', '-DNDEBUG', '-DHAVE_IS_DEFAULT_CONSTRUCTIBLE=1', '-DHAVE_IS_MOVE_CONSTRUCTIBLE=1', 
'-DHAVE_CXX_OVERRIDE=1', '-DHAVE_STD_TO_STRING=1', '-DHAVE_LIBRT=1', '-DHAVE_LIBRESOLV=1', '-DHAVE_PRIVILEGE_DROP_AND_ELEVATE=1', '-DHAVE_IFADDRS_H=1', 
'../test.cpp', '-c', '-o', '/home/makerpm/rpmbuild/SOURCES/NFD-NFD-0.3.4/build/.conf_check_b8ceb3a699f14874d3562659110c87d9/testbuild/test.cpp.1.o']
yes
-------------------------------------------------
Checking for WebSocket includes
Not found
from /home/makerpm/rpmbuild/SOURCES/NFD-NFD-0.3.4: The configuration failed

$ ls /usr/include/websocketpp/
base64      common       connection_base.hpp  endpoint.hpp         extensions  impl            processors  server.hpp  uri.hpp             version.hpp
client.hpp  concurrency  connection.hpp       error_container.hpp  frame.hpp   logger          random      sha1        utf8_validator.hpp
close.hpp   config       endpoint_base.hpp    error.hpp            http        message_buffer  roles       transport   utilities.hpp

I think the waf tool assumes that the websocketpp sources and headers are "inside" NFD sources.

The right thing to do would be to add a --with-websocketpp=<path> option to waf configure, the same as libpcap etc...

A quick and dirty workaround (untested) is to symlink the system headers where NFD expects them:

mkdir -p websocketpp
ln -s /usr/include/websocketpp websocketpp/websocketpp

Davide Pesavento wrote:
I think the waf tool assumes that the websocketpp sources and headers are "inside" NFD sources.

The right thing to do would be to add a --with-websocketpp=<path> option to waf configure, the same as libpcap etc...

I looked at the wscript, didn't see an option. Is this an easy patch?

A quick and dirty workaround (untested) is to symlink the system headers where NFD expects them:

mkdir -p websocketpp
ln -s /usr/include/websocketpp websocketpp/websocketpp

This is very fragile and won't pass review. The location changes depending on architecture.

susmit shannigrahi wrote:

Davide Pesavento wrote:
I think the waf tool assumes that the websocketpp sources and headers are "inside" NFD sources.

The right thing to do would be to add a --with-websocketpp=<path> option to waf configure, the same as libpcap etc...

I looked at the wscript, didn't see an option. Is this an easy patch?

It has to be added. It shouldn't be hard, but Alex is the waf expert...

The rest of the package builds fine. I should be able to submit it for review as soon as we have the patch and fix the unit-test errors.

The SPEC file is here: http://www.cs.colostate.edu/~susmit/ndn/nfd.spec

The SRPM is here : http://www.cs.colostate.edu/~susmit/ndn/nfd-0.3.4-1.fc22.src.rpm

I'll review the spec file here for lack of a better place.

License: LGPLv3+ and (BSD or LGPLv3+) and (GPLv3+ or LGPLv3+)

I'm not sure what this means exactly, but AFAIK we don't use the BSD license.

URL: https://github.com/named-data/NFD

I don't think we want to put github as the official website of the project

Source0: https://github.com/named-data/NFD/archive/NFD-%{version}.tar.gz

This should be fine, but the official tarballs are here: http://named-data.net/downloads/

BuildRequires: sqlite-devel cryptopp-devel boost-devel pkgconfig openssl-devel libndn-cxx-devel websocketpp-devel
BuildRequires: boost-python-devel python-devel python2-devel

NFD does not directly use sqlite, cryptopp, openssl. They are used through ndn-cxx. Are you supposed to list transitive dependencies too?

NFD does not use boost-python, but it does use other boost libraries. It does not use python development packages either, but a python interpreter is required at build time in order to run waf.

libpcap is missing.

%description
nfd is a Named Data Networking (NDN) forwarder

nfd -> NFD

--includedir="/usr/include/websocketpp"

This is not the purpose of --includedir. Delete it.

I would disagree with adding websocket as a configuration option. It simply needs to be downloaded from git (or directly taken from the .tar.gz). The main reason is to keep control over which specific version is used. Websocket library is header-only.

Alex Afanasyev wrote:

I would disagree with adding websocket as a configuration option. It simply needs to be downloaded from git (or directly taken from the .tar.gz). The main reason is to keep control over which specific version is used. Websocket library is header-only.

Downloaded websocket library might conflict with installed websocketpp library from Fedora repo.

There cannot (should not) be any conflicts. Websockets library is header-only, the code doesn't link to anything else.

New rpm and spec file here:

http://www.cs.colostate.edu/~susmit/ndn/NFD.spec

http://www.cs.colostate.edu/~susmit/ndn/NFD-0.4.0-1.fc23.src.rpm

Unit tests don't work without sudo, not sure how to use them in Fedora buildsystem. I'll ask the Fedora packaging list, everything else work.

I'll also open a package review request on bugzilla.

libndn-cxx is updated to 0.4.0 in Fedora repo.
EL6/7 will not work until we fix the Endian bug #3294.

Davide Pesavento wrote:
I think we should skip those unit tests that require root privileges when running without sudo... Can you open a ticket for that please? (if there isn't one already)

Ok, I'll open a ticket.

Ticket here: #3418