OpenCPN Build on Debian

[idpnd]

Originally Posted by antonm

One of proposals was to have those dependencies distributed as a separate archive. Than it will just look like extracting it to some predefined "ext" folder within the OpenCPN.

I think on the modern linuxes the required dependencies are just added transparently, whilst windows users just get the pre-compiled package anyway.. I do believe the debian policy is there for good reason

[antonm]

Originally Posted by HamishB

more mature code ta boot. It will take some work to replace, but the end result will give us a more much robust product.

as far as I can see nothing actually uses include/gcp.h, so it doesn't need to be there.

Great news. Proj4 is available in Debian and is wider used. Again we can ship it in externals for Windows if needed, but still have ability to link with shared library.

Would you please than open bugs in SourceForge bug tracker on those issues with your comments? As there are a lot of hopefully small issues and we need to track them somewhere.

[antonm]

Originally Posted by idpnd

I think on the modern linuxes the required dependencies are just added transparently, whilst windows users just get the pre-compiled package anyway.. I do believe the debian policy is there for good reason

Here is the link to corresponding policy section:

Debian Policy Manual - Source packages

And the reason for that is explained in footnotes:

Having multiple copies of the same code in Debian is inefficient, often creates either static linking or shared library conflicts, and, most importantly, increases the difficulty of handling security vulnerabilities in the duplicated code.

Altough I also think that distributing well-known and mantained externals in the same tarball is not a good (better have those as a separate pak if needed). In least case we can keep distributing them, but need to support the way of building with existing libraries in Makefile as an option. If OpenCPN will not have such support natively, the packager (me in this case) will have to implement it anyway and then apply and mantain patches to original sources before building:

If the included code is already in the Debian archive in the form of a library, the Debian packaging should ensure that binary packages reference the libraries already in Debian and the convenience copy is not used.

[Psyches]

Originally Posted by antonm

One of proposals was to have those dependencies distributed as a separate archive. Than it will just look like extracting it to some predefined "ext" folder within the OpenCPN.

In least case we may just adjust Makefiles to support building with external libraries, based on some switch value or whatever.

Any concerns against those proposals?

No concern from me - I think separating as suggested would be a fine thing to do. I'll be interested to see Dave's thoughts on all this.

Mark

[manimaul]

Great work going on here prepping OpenCPN for Debian packaging. This should raise the quality bar of the project. It is a shame the Debian peer review caught the spam on opencpn.org. I think it was only there for a number of hours before we got a chance to clean it up. BTW, thanks Hammish for the captcha suggestion...works!

[idpnd]

Alarm or Siren | public domain sounds How about this for an alarm? The sounds are all officially in the public domain (most liberal license really).

[antonm]

Well. Current Debian folder is on Alioth:

[pkg-grass] Index of /packages/opencpn/trunk/debian

Now it's time to revise the patches, submit them to sourceforge tracker and add more patches ;-)

[HamishB]

Nice. Is it your intention to package 1.3.6+patches or package CVS?

re. patches, it would be good to use dpatch, create a file called "00list" with all the active patch files names then

#! /bin/sh /usr/share/dpatch/dpatch-run
## 01-make.dpatch by your name <you@example.com>
##
## DP: come comments here
## DP: Remove some SUBDIRS from Makefile.am
## DP: Remove perl checks from configure.ac
## DP: Remove map-icons from Makefile.am
## DP: call pod2man on debian/scripts/gpsfetchmap.pl

@DPATCH@
... patch ...

see `man dpatch` and other projects on alioth for examples.

also those two .wav files can just be removed. they are not called by the code or even installed by the Makefile AFAICT.


cheers,
Hamsih

[Psyches]

Originally Posted by HamishB

also those two .wav files can just be removed. they are not called by the code or even installed by the Makefile AFAICT.

Nothing wrong with removing them from the debian pkg for now. I added some comments to the sf.net bug though - they can't just go away in cvs or (at least) win32 install, they'll need to be replaced with open versions of equivalent duration and freq range.

Mark

[antonm]

Originally Posted by HamishB

Nice. Is it your intention to package 1.3.6+patches or package CVS?

I expect to package upstream releases from release tarballs untill there will be a strong reason to package from CVS.

Current version is done for 1.3.6 tarball.

Originally Posted by HamishB

re. patches, it would be good to use dpatch, create a file called "00list" with all the active patch files names then

I am using quilt for patches:

Projects/DebSrc3.0 - Debian Wiki

[antonm]

Please note that the patch to Makefile.am made during packaging is submitted to SourceForge:

SourceForge.net: OpenCPN: Detail: 2970919 - Fix Makefile to be FHS and --prefix compatible

1. It fixes hardcoded "/usr/local/share" and "/usr/share" in the Makefile.am that make the build ignorant of the "--prefix" setting at few places (even for opencpn.desktop and opencpn.png I would let user decide using --prefix instead of trying to install to system /usr directory directly. This also breaks autobuilding systems).
2. "cp -p" is replaced to "install -p -m 644" that fixes permissions of the files during install no matter how they where saved to the tarball.
3. png icon is installed to $(DESTDIR)$(pkgdatadir)/icons/hicolor/48x48/apps and since there is also svg icon it is also installed to $(DESTDIR)$(pkgdatadir)/icons/hicolor/scalable/apps.
4. Note that changes to Makefile.in is there just for the Debian build (since it does not run automake for now). This file was simply auto generated as usual and can be regenerated as much times as needed.

I also plan to send an updated opencpn.desktop file with icon related to the icon path specified above.

Let me know if any questions or concerns.

[antonm]

Originally Posted by antonm

$(DESTDIR)$(pkgdatadir)/icons/hicolor/48x48/apps

There was a small and obvious error. The icons, locales and desktop staff needs to go to $(datadir), not $(pkgdatadir). Noted this today after having a sleep. Fixed version is submitted to the tracker.

Now it looks to be installing everything to the proper places.

[HamishB]

Just to ping on this one. The license issues are not limited to use in Debian, are important to distribute this software at all, and will not go away. aka don't make yourself a target for triple damages / they see your boat and they want it.


regards,
mr. scare tactics

[bdbcat]

HamishB

Exactly which modules/functions are you concerned about?

Dave

[antonm]

Originally Posted by bdbcat

Exactly which modules/functions are you concerned about?

Currently identified items are posted as SourceForge bugs:

1. src/georef.c has non free license not compatible with GPL - ID: 2948014
2. includes/gpc.h has non-free license incompatible with GPL - ID: 2948022 (this one appears to be fixed)
3. A couple of files with unclear license - ID: 2948024 (macsercomm.cpp macsercomm.h macutils.c macutils.h routeprop.cpp routeprop.h scrollingdialog.cpp scrollingdialog.h sercomm.cpp sercomm.h triangulate.h)
4. data/s57data/* has unclear source and license - ID: 2948026
5. Sounds have unclear license - ID: 2948031
6. src/nmea0183 license does not allow distribution rights - ID: 2948034
7. Ambigous license headers in OpenCPN source file - ID: 2948038 (Copyright (C) $YEAR$ by $AUTHOR$ * * $EMAIL$ *)

It is better to browse on SourceForge as most of those items have corresponding ideas in the comments.