Project

General

Profile

Task #1587

binaries: Make RPM packages

Added by Alex Afanasyev almost 7 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Category:
Build
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

openSUSE Build Service provides a platform for building RPM packages for many different platforms.

We should make binaries at least for Fedora 20 and CentOS 7.

#1

Updated by Junxiao Shi almost 7 years ago

  • Category changed from Tools to Build
  • Start date deleted (05/09/2014)
#2

Updated by Junxiao Shi over 6 years ago

  • Target version changed from v0.2 to v0.3

20140609 conference call decides to defer this task sometime after release.

#3

Updated by Junxiao Shi about 6 years ago

  • Subject changed from binaries: Make .rpm packages to binaries: Make RPM packages
  • Description updated (diff)
#4

Updated by Junxiao Shi about 6 years ago

  • Assignee set to susmit shannigrahi
#5

Updated by susmit shannigrahi about 6 years ago

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?

#6

Updated by Alex Afanasyev about 6 years ago

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.

#7

Updated by Davide Pesavento about 6 years ago

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?

#8

Updated by Junxiao Shi about 6 years ago

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.

#9

Updated by Alex Afanasyev about 6 years ago

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).

#10

Updated by Alex Afanasyev about 6 years ago

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).

#11

Updated by susmit shannigrahi about 6 years ago

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.

#12

Updated by Alex Afanasyev about 6 years ago

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 :)

#13

Updated by Davide Pesavento about 6 years ago

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.

#14

Updated by susmit shannigrahi about 6 years ago

  • File ndn-cxx-0.3.0-1.fc21.x86_64.rpm added
  • File ndn-cxx.spec added

Here is the cxx rpm that needs testing. Using a VM is preferred. I don't have a 32 bit machine, so no i686 rpm yet.

#15

Updated by Junxiao Shi about 6 years ago

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.

#16

Updated by Alex Afanasyev about 6 years ago

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.

#17

Updated by susmit shannigrahi about 6 years ago

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

#18

Updated by Alex Afanasyev about 6 years ago

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.

#19

Updated by susmit shannigrahi about 6 years ago

  • File deleted (ndn-cxx-0.3.0-1.fc21.x86_64.rpm)
#20

Updated by susmit shannigrahi about 6 years ago

  • File deleted (ndn-cxx.spec)
#21

Updated by susmit shannigrahi about 6 years ago

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

#22

Updated by susmit shannigrahi over 5 years ago

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

#23

Updated by Davide Pesavento over 5 years ago

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).

#24

Updated by susmit shannigrahi over 5 years ago

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?

#25

Updated by Davide Pesavento over 5 years ago

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

#26

Updated by Alex Afanasyev over 5 years ago

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

#27

Updated by Alex Afanasyev over 5 years ago

  • Target version changed from v0.3 to v0.4
#30

Updated by susmit shannigrahi over 5 years ago

  • Status changed from New to In Progress
#31

Updated by susmit shannigrahi over 5 years ago

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.

#32

Updated by Davide Pesavento over 5 years ago

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

#33

Updated by susmit shannigrahi over 5 years ago

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

#34

Updated by susmit shannigrahi over 5 years ago

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

#35

Updated by Davide Pesavento over 5 years ago

congrats! ;)

#36

Updated by susmit shannigrahi over 5 years ago

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

#37

Updated by Davide Pesavento over 5 years ago

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
#38

Updated by susmit shannigrahi over 5 years ago

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.

#39

Updated by Davide Pesavento over 5 years ago

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...

#40

Updated by susmit shannigrahi over 5 years ago

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

#41

Updated by Davide Pesavento over 5 years ago

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.

#42

Updated by Alex Afanasyev over 5 years ago

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.

#43

Updated by susmit shannigrahi over 5 years ago

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.

#44

Updated by Alex Afanasyev over 5 years ago

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

#45

Updated by Alex Afanasyev about 5 years ago

  • Target version changed from v0.4 to Unsupported
#46

Updated by susmit shannigrahi about 5 years ago

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.

#47

Updated by susmit shannigrahi about 5 years ago

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

#48

Updated by Davide Pesavento about 5 years ago

  • % Done changed from 0 to 50

libndn-cxx is updated to 0.4.0 in Fedora repo.

Thanks. Any plans for packaging NFD as well?

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 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)

#49

Updated by susmit shannigrahi about 5 years ago

  • % Done changed from 50 to 0

Davide Pesavento wrote:

libndn-cxx is updated to 0.4.0 in Fedora repo.

Thanks. Any plans for packaging NFD as well?

Yes, see note 46 above. It's already packaged, it just needs to go through Fedora package review process.

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 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.

#50

Updated by susmit shannigrahi about 5 years ago

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

#51

Updated by susmit shannigrahi over 3 years ago

  • Status changed from In Progress to Closed

This is done, we should find a maintainer for updating RPMs for each release.

Also available in: Atom PDF