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/
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 ***