[Bug 1209166] New: Review Request: palo - cell-oriented, multi-dimensional in-memory OLAP server
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1209166
Bug ID: 1209166
Summary: Review Request: palo - cell-oriented,
multi-dimensional in-memory OLAP server
Product: Fedora
Version: rawhide
Component: Package Review
Severity: medium
Priority: medium
Assignee: nobody(a)fedoraproject.org
Reporter: myk321(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: package-review(a)lists.fedoraproject.org
Spec URL: https://myk52348.fedorapeople.org/palo/palo.spec
SRPM URL: https://myk52348.fedorapeople.org/palo/palo-5.1-4.fc21.src.rpm
Description: Palo is a cell-oriented, multi-dimensional in-memory OLAP server
typically used for analysis and data consolidation. Multi-dimensional data can
be queried interactively and written back for further consolidation. The server
stores and manipulates data in memory. Bespoke Java, PHP, C/C++, and .NET
clients can access the palo database via an API or plug-in modules are
available for spreadsheet applications like Calc.
Fedora Account System Username:myk52348
This is my first package, so I am looking for a sponsor.
At this point I am only looking to package the core server, although may
follow-up with client libraries and the ETL(extract-transform-load) server.
The palo code server is written in c and builds using cmake. The c and c++
client code build using the automake tools. The ETL server builds using maven.
At its core this package is a database server so that experience would probably
be most relevant. I have no prior packaging experience so I included a couple
of questions below that I need help with.
Issue 1: on the command line the cmake command
cmake ../5.1
successfully builds the server. But when creating the source RPM, this same
command fails, unless patch0 is applied. Patch0 essentially hard-codes the
paths where the dependency libraries can be located, which is not great. I'm
guessing that the macro:
%global _hardened_build 1
is changing the cmake behavior. Is there a better way to handle this than via
a patch?
Issue 2: when building with koji, I get the error:
svn: E670002: Unable to connect to a repository at URL
'https://svn.code.sf.net/p/palo/code/molap/server/5.1'
svn: E670002: Name or service not known
Since the source is stored in a SVN repo and the packaging guidelines indicate
I should not place the source into the SOURCE folder, but rather access it from
the upstream, how can I resolve this error?
Thanks and regards,
Michael
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
7 years, 5 months