Bug 612224

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

FYI rawhide failure to build is related to a bug in cmake. See
https://bugzilla.redhat.com/show_bug.cgi?id=639058

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

I'm packaging it now, is the submmiter still interested in it?

If not I'll close this and submit mine.

(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

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

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