Building ONe from git versus src.rpm

(Jan "Yenya" Kasprzak) #1


Is OpenNebula buildable from the github source code?

I have decided to build the OpenNebula packages myself (I have been using pre-built CentOS 7 packages before). I tried to start from the opennebula-5.4.1-1.src.rpm from the inside of the opennebula-5.4.1.tar.gz CentOS tarball from It apparently contains a copy of the xmlrpc-c source code, even though it depends on the xmlrpc-c and xmlrpc-c-devel system packages. Which one gets used? The %build part seems to unpack and compile the local copy.

Nevertheless, rpmbuild --rebuild opennebula-5.4.1-1.src.rpm produces working packages of OpenNebula. Good. Let’s compare the source code to the distributed sources:

I cloned the OpenNebula Git repository, and created a new opennebula-5.4.1.tar.gz sources from it using

ONEVERS=5.4.1 ; git archive --format tar.gz --prefix=opennebula-$ONEVERS/ release-$ONEVERS -o opennebula-$ONEVERS.tar.gz

When I copy this tarball to ~/rpmbuild/SOURCES and try to build the CentOS 7 packages using rpmbuild -ba centos7.spec, it compiles, and ONe apparently works with the exception of Sunstone: the Sunstone login screen shows a rotating spinner between the “Keep me logged in” text and the “Login” button, and after entering username and password, it responds with the following page:

Sinatra doesn’t know this ditty.
Try this:

post '/' do
  "Hello World"

Comparing the opennebula-5.4.1.tar.gz tarball from the src.rpm to the one generated from git-archive, the later has lots of missing files: the whole src/sunstone/public/bower_components subtree, src/sunstone/public/css/app.css, src/sunstone/public/css/app.min.css, and the src/sunstone/public/dist/ directory.

So my question is - where are the official source tarballs, and why there are different to what I get via git-archive?



(Anton Todorov) #2

There is a section in the documentation for compiling from sources

I use the info provided in the OpenNebula’s packages project to create a local package building system and repository.

Hope this helps.

Best Regards
Anton Todorov

(Jan "Yenya" Kasprzak) #3

OK, thanks for the pointer.

I nevertheless think that .src.rpm should contain “pristine” sources, i.e. the code which is in git under the release_X tag. Additional data (such as xmlrpc-c source or bower components) should be added to the source RPM as separate SourceN tarballs.

OpenNebula developers - would you accept patch to the spec file and build scripts in this direction?


(Vlastimil Holer) #4

Hi @Yenya,

you are absolutely right. There are tons of legacy and dirty stuff in the packaging scripts, and a refactoring would be much needed. Problem is, the change needs to be done not only for RPMs, but also for DEBs, and also in our building infrastructure (which currently generates for us the “public release” archive). Even if you prepare a change for RPM as a PoC, it will be very helpful. But, the merge won’t be straightforward…

Thank you,