Cruisers Forum
 


Join CruisersForum Today

Reply
 
Thread Tools Rate Thread Display Modes
Old 10-02-2010, 08:48   #46
Senior Cruiser
 
idpnd's Avatar

Cruisers Forum Supporter

Join Date: Sep 2007
Location: Almería, ES
Boat: Chiquita 46 - Libertalia
Posts: 1,551
Quote:
Originally Posted by antonm View Post
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
__________________

__________________
sv Libertalia
idpnd is offline   Reply With Quote
Old 10-02-2010, 08:51   #47
Registered User
 
antonm's Avatar

Join Date: Feb 2010
Location: Saint Petersburg, Russia
Posts: 66
Quote:
Originally Posted by HamishB View Post
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 is offline   Reply With Quote
Old 10-02-2010, 10:11   #48
Registered User
 
antonm's Avatar

Join Date: Feb 2010
Location: Saint Petersburg, Russia
Posts: 66
Quote:
Originally Posted by idpnd View Post
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:

Quote:
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:

Quote:
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.
__________________
antonm is offline   Reply With Quote
Old 10-02-2010, 10:29   #49
Registered User
 
Psyches's Avatar

Join Date: Apr 2008
Location: SF Bay Area
Boat: Tartan 30 - Bluegrass
Posts: 187
Send a message via Yahoo to Psyches Send a message via Skype™ to Psyches
Quote:
Originally Posted by antonm View Post
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
__________________
Psyches is offline   Reply With Quote
Old 14-02-2010, 20:10   #50
Registered User
 
manimaul's Avatar

Join Date: Feb 2008
Location: Seattle, WA
Posts: 416
Debian

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!
__________________
Marine Navigation for Android:
http://mxmariner.com
manimaul is offline   Reply With Quote
Old 15-02-2010, 10:19   #51
Senior Cruiser
 
idpnd's Avatar

Cruisers Forum Supporter

Join Date: Sep 2007
Location: Almería, ES
Boat: Chiquita 46 - Libertalia
Posts: 1,551
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).
__________________
sv Libertalia
idpnd is offline   Reply With Quote
Old 24-02-2010, 13:08   #52
Registered User
 
antonm's Avatar

Join Date: Feb 2010
Location: Saint Petersburg, Russia
Posts: 66
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 ;-)
__________________
antonm is offline   Reply With Quote
Old 24-02-2010, 14:47   #53
Registered User
 
HamishB's Avatar

Join Date: Jan 2010
Location: New Zealand
Posts: 286
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

Code:
#! /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
__________________
HamishB is offline   Reply With Quote
Old 24-02-2010, 14:53   #54
Registered User
 
Psyches's Avatar

Join Date: Apr 2008
Location: SF Bay Area
Boat: Tartan 30 - Bluegrass
Posts: 187
Send a message via Yahoo to Psyches Send a message via Skype™ to Psyches
Quote:
Originally Posted by HamishB View Post
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
__________________
Psyches is offline   Reply With Quote
Old 25-02-2010, 05:02   #55
Registered User
 
antonm's Avatar

Join Date: Feb 2010
Location: Saint Petersburg, Russia
Posts: 66
Quote:
Originally Posted by HamishB View Post
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.

Quote:
Originally Posted by HamishB View Post
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 is offline   Reply With Quote
Old 15-03-2010, 17:11   #56
Registered User
 
antonm's Avatar

Join Date: Feb 2010
Location: Saint Petersburg, Russia
Posts: 66
Patch "Fix Makefile to be FHS and --prefix compatible"

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 is offline   Reply With Quote
Old 16-03-2010, 13:59   #57
Registered User
 
antonm's Avatar

Join Date: Feb 2010
Location: Saint Petersburg, Russia
Posts: 66
Quote:
Originally Posted by antonm View Post
$(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.
__________________
antonm is offline   Reply With Quote
Old 19-04-2010, 08:17   #58
Registered User
 
HamishB's Avatar

Join Date: Jan 2010
Location: New Zealand
Posts: 286
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
__________________
HamishB is offline   Reply With Quote
Old 19-04-2010, 17:21   #59
Marine Service Provider
 
bdbcat's Avatar

Join Date: Mar 2008
Posts: 4,884
Licensing

HamishB

Exactly which modules/functions are you concerned about?

Dave
__________________
bdbcat is offline   Reply With Quote
Old 20-04-2010, 05:06   #60
Registered User
 
antonm's Avatar

Join Date: Feb 2010
Location: Saint Petersburg, Russia
Posts: 66
Quote:
Originally Posted by bdbcat View Post
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.
__________________

__________________
antonm is offline   Reply With Quote
Reply

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
OpenCPN Build on Win32 Thorac OpenCPN 108 13-06-2011 06:56
OpenCPN bdbcat OpenCPN 1343 19-09-2009 16:59
OpenCPN with BSB v4 selkie Navigation 4 03-08-2009 12:32



Copyright 2002- Social Knowledge, LLC All Rights Reserved.

All times are GMT -7. The time now is 00:22.


Google+
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Social Knowledge Networks
Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.

ShowCase vBulletin Plugins by Drive Thru Online, Inc.