Bug 612224 - Review Request: opencpn - An open source chart plotter/navigator
Review Request: opencpn - An open source chart plotter/navigator
Status: CLOSED DUPLICATE of bug 859671
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Horák
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2010-07-07 11:44 EDT by Jiri Olsa
Modified: 2013-06-27 05:10 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-27 05:10:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
dan: fedora‑review?


Attachments (Terms of Use)

  None (edit)
Description Jiri Olsa 2010-07-07 11:44:28 EDT
Spec URL: http://people.redhat.com/jolsa/opencpn/opencpn.spec
SRPM URL: http://people.redhat.com/jolsa/opencpn/opencpn-2.1.624a-1.fc13.src.rpm

Description:
OpenCPN is a free software (GPL) project to create a concise chart plotter and
navigation software for use as an underway or planning tool.  OpenCPN is
developed by a team of active sailors using real world conditions for program
testing and refinement.

http://www.opencpn.org/
Comment 1 Dan Horák 2010-07-10 09:04:46 EDT
some issues discovered before doing a formal review:
- use the standard macro for calling cmake - https://fedoraproject.org/wiki/Packaging:Cmake
- explicit Requires are not needed, they will be filled in automatically by rpmbuild
- the %{_datadir}/opencpn directory is not owned by the package, either add %dir %{_datadir}/opencpn or use only %{_datadir}/opencpn as it will include all subdirs into the package
- doesn't build in rawhide, I think the path for gdk-pixbuf2 includes is not set, probably related to the recent move of gdk-pixbuf2 to its own package
- builds its own copy of bzip2 library, you must add BR: bzip2-devel
- includes (outdated) zlib headers, I would rather remove them before build to be sure they are not used
- I would prefer to see each BR: on its own line, it's easier to track their changes
- includes GDAL library (or parts only?) - a system copy must be used
- you probably want to add BR: gpsd-devel
Comment 2 Jean-Eudes ONFRAY 2010-10-07 10:18:23 EDT
FYI rawhide failure to build is related to a bug in cmake. See
https://bugzilla.redhat.com/show_bug.cgi?id=639058
Comment 3 Jean-Eudes ONFRAY 2012-02-18 19:07:47 EST
Hi,

I'd like to followup on this to see OpenCPN packaged in Fedora.
If possible, I'd like to co-maintain this package. I'm part of the upstream team and already providing Fedora rpm there.

Here's updated spec & srpm for latest 2.5.0
http://je.onfray.fr/dl/opencpn.spec
http://je.onfray.fr/dl/opencpn-2.5.0-1.fc16.src.rpm

As you'll see, I added a rule to remove embedded bzip2 & zlib to ensure they are not used. I wanted to do the same for tinyxml but they're including tinystr.h that's not provided in Fedora (unnecessary include: it's only required if tinyxml is built without stl) This would require a patch to include/gpxdocument.h
Please tell me if I should do it. I'll open a bug upstream to have it removed from future release.

gdal library has lots of changes from upstream. Changes heavily related to internal use. Would probably not fit to upstream for inclusion.

nmea0183 does not exist as a lib. There are two different versions: one for core OpenCPN, one for the dashboard plugin. Both are different. It's required by lead OpenCPN dev to ensure plugins doesn't rely on any special version from core.

Please comment.

Regards,
Jean-Eudes
Comment 4 Christopher Meng 2013-05-24 05:06:19 EDT
I'm packaging it now, is the submmiter still interested in it?

If not I'll close this and submit mine.
Comment 5 Jiri Olsa 2013-05-24 06:38:27 EDT
(In reply to Christopher Meng from comment #4)
> I'm packaging it now, is the submmiter still interested in it?
> 
> If not I'll close this and submit mine.

please go ahead with yours, thanks
Comment 6 Jean-Eudes ONFRAY 2013-05-24 11:30:15 EDT
Hi guys,

As you can see in http://opencpn.org/ocpn/download
I maintain and package opencpn for Fedora i386 & x86_64

I've created a repo for that purpose (until it's included in Fedora)

You can try it:

yum install http://je.onfray.fr/repo/fedora/18/x86_64/jeo-release-1.0-1.fc18.noarch.rpm
yum install opencpn

The current stable is 3.2.2. Here's my latest spec and srpm:
http://je.onfray.fr/dl/opencpn.spec
http://je.onfray.fr/dl/opencpn-3.2.2-1.fc18.src.rpm

This is straight opencpn source with one single patch to fix a linking problem when using mock. This patch should be included in the next beta. Here's my message to opencpn devel team to describe the problem:
----
[...]
some rpm built have wrong dependencies. Eg.:
--
$ rpm -qpR opencpn-3.1.1405-1.fc18.x86_64.rpm
/bin/sh
/bin/sh
/bin/sh
bzip2
gettext
libGARMINHOST.so()(64bit)
libGL.so.1()(64bit)
libGLU.so.1()(64bit)
libNMEA0183.so()(64bit)
libS57ENC.so()(64bit)
libX11.so.6()(64bit)
libXext.so.6()(64bit)
libatk-1.0.so.0()(64bit)
libbz2.so.1()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.11)(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.15)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libcairo.so.2()(64bit)
libdl.so.2()(64bit)
libfreetype.so.6()(64bit)
libgcc_s.so.1()(64bit)
libgcc_s.so.1(GCC_3.0)(64bit)
libgdk-x11-2.0.so.0()(64bit)
libgdk_pixbuf-2.0.so.0()(64bit)
libglib-2.0.so.0()(64bit)
libgobject-2.0.so.0()(64bit)
libgtk-x11-2.0.so.0()(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libpango-1.0.so.0()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(GLIBCXX_3.4)(64bit)
libstdc++.so.6(GLIBCXX_3.4.11)(64bit)
libstdc++.so.6(GLIBCXX_3.4.15)(64bit)
libstdc++.so.6(GLIBCXX_3.4.9)(64bit)
libtinyxml.so.0()(64bit)
libwx_baseu-2.8.so.0()(64bit)
libwx_baseu-2.8.so.0(WXU_2.8)(64bit)
libwx_baseu_net-2.8.so.0()(64bit)
libwx_baseu_net-2.8.so.0(WXU_2.8)(64bit)
libwx_baseu_xml-2.8.so.0()(64bit)
libwx_baseu_xml-2.8.so.0(WXU_2.8)(64bit)
libwx_gtk2u_adv-2.8.so.0()(64bit)
libwx_gtk2u_adv-2.8.so.0(WXU_2.8)(64bit)
libwx_gtk2u_adv-2.8.so.0(WXU_2.8.11)(64bit)
libwx_gtk2u_aui-2.8.so.0()(64bit)
libwx_gtk2u_aui-2.8.so.0(WXU_2.8)(64bit)
libwx_gtk2u_core-2.8.so.0()(64bit)
libwx_gtk2u_core-2.8.so.0(WXU_2.8)(64bit)
libwx_gtk2u_core-2.8.so.0(WXU_2.8.1)(64bit)
libwx_gtk2u_gl-2.8.so.0()(64bit)
libwx_gtk2u_gl-2.8.so.0(WXU_2.8)(64bit)
libwx_gtk2u_html-2.8.so.0()(64bit)
libwx_gtk2u_html-2.8.so.0(WXU_2.8)(64bit)
libz.so.1()(64bit)
libz.so.1(ZLIB_1.2.3.3)(64bit)
mesa-libGL
mesa-libGLU
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rtld(GNU_HASH)
wxGTK
zlib
rpmlib(PayloadIsXz) <= 5.2-1
--

Did you spot libGARMINHOST.so, libNMEA0183.so and libS57ENC.so above? They are
internal libs built with opencpn then embedded in our main prog. They are only
built as libXXX.a, not meant to be .so dynamically linked libs.

Unfortunately an rpm-build feature, named Automatic Dependency Processing
(http://www.rpm.org/max-rpm/s1-rpm-depend-auto-depend.html) find these libs and
add them as dependencies. As you may guess, it breaks package installation as
such libs doesn't exist and are not provided by any package.

I found that page
http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library
describing the problem we're facing (bottom of §Motivation). Here's an excerpt:
--
The drawback to the approach is that it creates a separate library file on disk
for each group. In this case library files such as libbig.a, libA.a, and libB.a
will be created instead of one large libbig.a. The additional files may not be
desirable for packaging, distribution, or use externally by other build systems.

CMake's OBJECT library type provides a way to avoid this drawback and get the
best of both above approaches. 
--

I'd like to push the attached patch to address this. It follows the tutorial
above and is IMHO the correct way to do. The changes should not break any
platform. The problem is... it requires cmake >= 2.8.8 (released 2012-04-19,
latest is 2.8.10)
Is it reasonable to expect this version for all our builders? Can I push this to
master? If not, I can keep a local branch with these changes to build rpms, it
may be a problem for some builders but Fedora & OpenSuSE doesn't look to be very
popular among our users.
-----
Comment 7 Volker Fröhlich 2013-06-27 05:10:59 EDT

*** This bug has been marked as a duplicate of bug 859671 ***

Note You need to log in before you can comment on or make changes to this bug.